From: Jian-Hong Pan <starnight@g.ncu.edu.tw>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: "Andreas Färber" <afaerber@suse.de>,
netdev@vger.kernel.org,
"<linux-arm-kernel@lists.infradead.org\\"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org>," <linux-kernel@vger.kernel.org>,
"Jiri Pirko" <jiri@resnulli.us>,
"Marcel Holtmann" <marcel@holtmann.org>,
"David S. Miller" <davem@davemloft.net>,
"Matthias Brugger" <mbrugger@suse.com>,
"Janus Piwek" <jpiwek@arroweurope.com>,
"Michael Röder" <michael.roeder@avnet.eu>,
"Dollar Chen" <dollar.chen@wtmec.com>,
"Ken Yu" <ken.yu@rakwireless.com>,
"Konstantin Böhm" <konstantin.boehm@ancud.de>,
"Jan Jongboom" <jan.jongboom@arm.com>,
"Jon Ortego" <Jon.Ortego@imst.de>,
"linux-kernel@vger.kernel.org>," <contact@snootlab.com>,
"Ben Whitten" <ben.whitten@lairdtech.com>,
"Brian Ray" <brian.ray@link-labs.com>,
lora@globalsat.com.tw, "Alexander Graf" <agraf@suse.de>,
"Michal Kubeček" <mkubecek@suse.cz>,
"Rob Herring" <robh@kernel.org>,
devicetree@vger.kernel.org, "Steve deRosier" <derosier@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
linux-spi@vger.kernel.org,
"Pieter ROBYNS" <pieter.robyns@uhasselt.be>,
"Hasnain Virk" <Hasnain.Virk@arm.com>,
"linux-wpan - ML" <linux-wpan@vger.kernel.org>,
"Stefan Schmidt" <stefan@datenfreihafen.org>,
"Daniele Comel" <dcomel@mipot.com>,
shess@hessware.de, "Xue Liu" <liuxuenetmail@gmail.com>
Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa
Date: Mon, 13 Aug 2018 00:37:24 +0800 [thread overview]
Message-ID: <CAC=mGzhaLiSj5-+euM-YTRLwNDi8QJY0fAbiZbUadkPhZGRh_Q@mail.gmail.com> (raw)
In-Reply-To: <20180810165711.59bf26f7@alans-desktop>
Alan Cox <gnomes@lxorguk.ukuu.org.uk> 於 2018年8月10日 週五 下午11:57寫道:
>
> > Except saving power, mitigating the wireless signal conflict on the
> > air is one of the reasons.
>
> If the device level is always receiving when not transmitting it has no
> effect on this. The act of listening does not harm other traffic.
My friend had tested practically:
If he changes the LoRa interface to RX mode after TX completes
immediately, he will receive the signals like reflection echo some
times.
That is interesting!
There is a paper "Exploring LoRa and LoRaWAN A suitable protocol for
IoT weather stations?" by Kristoffer Olsson & Sveinn Finnsson
http://publications.lib.chalmers.se/records/fulltext/252610/252610.pdf
In chapter 3.2 Chirp Spread Spectrum, it describes the reflection echo
phenomenon.
I think that is why LoRaWAN places the RX delay time which avoids
receiving the reflection noise.
> > 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.
If the end device has sufficient power available, it can also
implement the Class C: Continuously listening end-device.
Here are the descriptions in LoRaWAN spec. for Class C:
- The Class C end-device will listen with RX2 windows parameters as
often as possible.
- The end-device listens on RX2 when it is not either (a) sending or
(b) receiving on RX1, according to Class A definition.
- 1. It will open a short window on RX2 parameters between the end of
the uplink transmission and the beginning of the RX1 reception window.
(*)
2. It will switch to RX2 reception parameters as soon as the RX1
reception window is closed; the RX2 reception window will remain open
until the end-device has to send another message.
According to the LoRaWAN Regional Parameters, the DataRate (including
spreading factor and bandwidth) and frequency channel of RX1 and RX2
windows may be different.(*)
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.
> > > 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.
> - 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.
> remembering we might only be talking to a hub, or we might even be a
> virtualized LORA interface where we are pretending to be some kind of
> sensor and feeding it back.
>
> Long term yes I think Alexander is right the inevitable fate of all
> networks is to become a link layer in order to transmit IP frames 8)
Yeah, maybe. It will be easier for life.
But I have not seen the formal standard for that yet or I missed it.
If the standard appears, we can try to implement it.
Jian-Hong Pan
next prev parent reply other threads:[~2018-08-12 19:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180701110804.32415-1-afaerber@suse.de>
[not found] ` <CAC=mGzgUCopz2xTOA0R-WD8a1DOaOOUn=YpfdMiJ33y3hnh6kg@mail.gmail.com>
2018-08-05 0:11 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber
2018-08-08 20:36 ` Alan Cox
2018-08-08 22:42 ` Andreas Färber
2018-08-09 11:59 ` Alan Cox
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:21 ` Alexander Aring
2018-08-10 15:57 ` Alan Cox
2018-08-11 18:30 ` Stefan Schmidt
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:37 ` Jian-Hong Pan [this message]
2018-08-12 17:59 ` Andreas Färber
2018-08-13 12:36 ` Alan Cox
2018-08-09 15:12 ` Alexander Aring
2018-08-09 0:50 ` Andreas Färber
[not found] ` <BY1PR02MB11147C7443AB9623D6B65798E75A0@BY1PR02MB1114.namprd02.prod.outlook.com>
[not found] ` <e08cdcfb-207f-bd73-2afd-f775810b72b7@suse.de>
[not found] ` <BY1PR02MB11143134B9ABAC9C9929A9C4E7530@BY1PR02MB1114.namprd02.prod.outlook.com>
2018-08-05 13:49 ` Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAC=mGzhaLiSj5-+euM-YTRLwNDi8QJY0fAbiZbUadkPhZGRh_Q@mail.gmail.com' \
--to=starnight@g.ncu.edu.tw \
--cc=Hasnain.Virk@arm.com \
--cc=Jon.Ortego@imst.de \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=ben.whitten@lairdtech.com \
--cc=brian.ray@link-labs.com \
--cc=broonie@kernel.org \
--cc=contact@snootlab.com \
--cc=davem@davemloft.net \
--cc=dcomel@mipot.com \
--cc=derosier@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dollar.chen@wtmec.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=jan.jongboom@arm.com \
--cc=jiri@resnulli.us \
--cc=jpiwek@arroweurope.com \
--cc=ken.yu@rakwireless.com \
--cc=konstantin.boehm@ancud.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-wpan@vger.kernel.org \
--cc=liuxuenetmail@gmail.com \
--cc=lora@globalsat.com.tw \
--cc=marcel@holtmann.org \
--cc=mbrugger@suse.com \
--cc=michael.roeder@avnet.eu \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=pieter.robyns@uhasselt.be \
--cc=robh@kernel.org \
--cc=shess@hessware.de \
--cc=stefan@datenfreihafen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).