Date:   Sun, 12 Aug 2018 19:59:35 +0200
From:   Andreas Färber <afaerber@...e.de>
To:     Jian-Hong Pan <starnight@...cu.edu.tw>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>,
        Marcel Holtmann <marcel@...tmann.org>,
        "David S. Miller" <davem@...emloft.net>,
        Matthias Brugger <mbrugger@...e.com>,
        Janus Piwek <jpiwek@...oweurope.com>,
        Michael Röder <michael.roeder@...et.eu>,
        Dollar Chen <dollar.chen@...ec.com>,
        Ken Yu <ken.yu@...wireless.com>,
        Konstantin Böhm <konstantin.boehm@...ud.de>,
        Jan Jongboom <jan.jongboom@....com>,
        Jon Ortego <Jon.Ortego@...t.de>,
        "contact@...otlab.com" <contact@...otlab.com>,
        Ben Whitten <ben.whitten@...rdtech.com>,
        Brian Ray <brian.ray@...k-labs.com>, lora@...balsat.com.tw,
        Alexander Graf <agraf@...e.de>,
        Michal Kubeček <mkubecek@...e.cz>,
        Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
        Steve deRosier <derosier@...il.com>,
        Mark Brown <broonie@...nel.org>, linux-spi@...r.kernel.org,
        Pieter ROBYNS <pieter.robyns@...sselt.be>,
        Hasnain Virk <Hasnain.Virk@....com>,
        linux-wpan - ML <linux-wpan@...r.kernel.org>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        Daniele Comel <dcomel@...ot.com>, shess@...sware.de,
        Xue Liu <liuxuenetmail@...il.com>
Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa

Am 12.08.2018 um 18:37 schrieb Jian-Hong Pan:
> Alan Cox <gnomes@...rguk.ukuu.org.uk> 於 2018年8月10日 週五 下午11:57寫道：
>>
>>> The sleep/idle/stop mitigate the unconcerned RF signals or messages.
>>
>> At the physical level it's irrelevant. If we are receiving then we might
>> hear more things we later discard. It's not running on a tiny
>> microcontroller so the extra CPU cycles are not going to kill us.
> 
> According different power resource, LoRaWAN defines Class A, B and C.
> Class A is the basic and both Class B and C devices must also
> implement the feature of Class A.
[...]
> So, yes!  Class C opens the RX windows almost all the time, except the TX time.
> And uses different channel to avoid the reflection noise (*).
> 
> However, Class C must also implements Class A and C is more complex than A.
> I think starting from the simpler one and adding more features and
> complexity in the future will be a better practice.

Jian-Hong, you've failed to come up with any practical proposal or patch
how to implement what you are saying LoRaWAN requires. Doing the
impossible is never simpler!

Implementing a simple back-off timer sounds doable by comparison.

May I remind you, LoRa is the simpler step before LoRaWAN - if our
layering is done right, someone else might choose to implement LoRaWAN
in userspace based on PF_LORA. There is absolutely no reason to hardcode
any LoRaWAN settings at device driver level for e.g. SX1276.

>>>> How do you plan to deal with routing if you've got multiple devices ?
>>>
>>> For LoRaWAN, it is a star topology.
>>
>> No the question was much more how you plan to deal with it in the OS. If
>> for example I want to open a LORA connection to something, then there
>> needs to be a proper process to figure out where the target is and how to
>> get traffic to them.
>>
>> I guess it's best phrased as
>>
>> - What does a struct sockaddr_lora look like
> 
> According to LoRaWAN spec, the Data Message only has the device's
> DevAddr (the device's address in 4 bytes) field related to "address".
> The device just sends the uplink Data Message through the interface
> and does not know the destination.  Then, a LoRaWAN gateway receives
> the uplink Data Message and forwards to the designated network server.
> So, end device does not care about the destination.  It only knows
> there is a gateway will forward its message to some where.
> Therefore, only the DevAddr as the source address will be meaningful
> for uplink Data Message.

Note that he was asking about sockaddr_lora, not LoRaWAN.

The simple answer is that, inspired by CAN, it uses an ifindex to select
the interface the user asked to use. That then also answers Alan's next
question: This ifindex determines which interface it goes out to.

sockaddr_lora was in patch 02/15, latest code here:
https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/include/uapi/linux/lora.h?h=lora-next

>> - How does the kernel decide which interface it goes out of (if any), and
>>   if it loops back
> 
> There is the MAC Header in the Data Message which is one byte.
> Bits 5 to 7 indicate which kind of type the message is.
> 000: Join Request
> 001: Join Accept
> 010: Unconfirmed Data Up
> 011: Unconfirmed Data Down
> 100: Confirmed Data Up
> 101: Confirmed Data Down
> 110: RFU
> 111: Proprietary
> 
> So, end device only accepts the types of downlink and the matched
> DevAddr (the device's address) in downlink Data Message for RX.

LoRaWAN is an entirely different story, therefore my agreement that we
need a separate PF_LORAWAN and sockaddr_lorawan for EUI addressing.

I still think the user will need to explicitly say which interface they
want to bind their socket to. AFAIU the device EUI is more comparable to
an Ethernet MAC address than to an IP address that the user would
configure routes for. If you have e.g. four SX1301 devices then they may
be configured for different frequencies, bandwidths, etc. but unlikely
for certain destination/source addresses. So either all that data comes
via sockaddr (which I was discussing in the FSK/OOK part of this thread)
or the user needs to make the interface choice for us.

Loopback mode would require a separate virtual device driver such as
fakelr or vlora.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Powered by blists - more mailing lists