* [RFC] net: Add new LoRaWAN subsystem @ 2018-05-08 15:33 Jian-Hong Pan 2018-05-11 8:16 ` Jiri Pirko 2018-05-11 15:39 ` Marcel Holtmann 0 siblings, 2 replies; 6+ messages in thread From: Jian-Hong Pan @ 2018-05-08 15:33 UTC (permalink / raw) To: David S. Miller, Alexander Aring, Stefan Schmidt, linux-wpan - ML, netdev, linux-kernel A Low-Power Wide-Area Network (LPWAN) is a type of wireless telecommunication wide area network designed to allow long range communications at a low bit rate among things (connected objects), such as sensors operated on a battery. It can be used widely in IoT area. LoRaWAN, which is one kind of implementation of LPWAN, is a medium access control (MAC) layer protocol for managing communication between LPWAN gateways and end-node devices, maintained by the LoRa Alliance. LoRaWAN™ Specification could be downloaded at: https://lora-alliance.org/lorawan-for-developers However, LoRaWAN is not implemented in Linux kernel right now, so I am trying to develop it. Here is my repository: https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN Because it is a kind of network, the ideal usage in an user space program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with other socket APIs. Therefore, the definitions like AF_LORAWAN, PF_LORAWAN ..., must be listed in the header files of glibc. For the driver in kernel space, the definitions also must be listed in the corresponding Linux socket header files. Especially, both are for the testing programs. Back to the mentioned "LoRaWAN is not implemented in Linux kernel now". Could or should we add the definitions into corresponding kernel header files now, if LoRaWAN will be accepted as a subsystem in Linux? Thanks, Jian-Hong Pan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net: Add new LoRaWAN subsystem 2018-05-08 15:33 [RFC] net: Add new LoRaWAN subsystem Jian-Hong Pan @ 2018-05-11 8:16 ` Jiri Pirko 2018-05-11 15:39 ` Marcel Holtmann 1 sibling, 0 replies; 6+ messages in thread From: Jiri Pirko @ 2018-05-11 8:16 UTC (permalink / raw) To: Jian-Hong Pan Cc: David S. Miller, Alexander Aring, Stefan Schmidt, linux-wpan - ML, netdev, linux-kernel Tue, May 08, 2018 at 05:33:01PM CEST, starnight@g.ncu.edu.tw wrote: >A Low-Power Wide-Area Network (LPWAN) is a type of wireless >telecommunication wide area network designed to allow long range >communications at a low bit rate among things (connected objects), such >as sensors operated on a battery. It can be used widely in IoT area. >LoRaWAN, which is one kind of implementation of LPWAN, is a medium >access control (MAC) layer protocol for managing communication between >LPWAN gateways and end-node devices, maintained by the LoRa Alliance. >LoRaWAN™ Specification could be downloaded at: >https://lora-alliance.org/lorawan-for-developers > >However, LoRaWAN is not implemented in Linux kernel right now, so I am >trying to develop it. Here is my repository: >https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN Link to some out-of-tree module is not enough. If you want anyone to look at this and comment, you need to base your work on top of kernel git (net-next for example) and send a patch/patchset. > >Because it is a kind of network, the ideal usage in an user space >program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with >other socket APIs. Therefore, the definitions like AF_LORAWAN, >PF_LORAWAN ..., must be listed in the header files of glibc. >For the driver in kernel space, the definitions also must be listed in >the corresponding Linux socket header files. >Especially, both are for the testing programs. > >Back to the mentioned "LoRaWAN is not implemented in Linux kernel now". >Could or should we add the definitions into corresponding kernel header >files now, if LoRaWAN will be accepted as a subsystem in Linux? > >Thanks, >Jian-Hong Pan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net: Add new LoRaWAN subsystem 2018-05-08 15:33 [RFC] net: Add new LoRaWAN subsystem Jian-Hong Pan 2018-05-11 8:16 ` Jiri Pirko @ 2018-05-11 15:39 ` Marcel Holtmann 2018-05-13 2:42 ` Jian-Hong Pan 1 sibling, 1 reply; 6+ messages in thread From: Marcel Holtmann @ 2018-05-11 15:39 UTC (permalink / raw) To: Jian-Hong Pan Cc: David S. Miller, Alexander Aring, Stefan Schmidt, linux-wpan - ML, netdev, linux-kernel Hi Jian-Hong, > A Low-Power Wide-Area Network (LPWAN) is a type of wireless > telecommunication wide area network designed to allow long range > communications at a low bit rate among things (connected objects), such > as sensors operated on a battery. It can be used widely in IoT area. > LoRaWAN, which is one kind of implementation of LPWAN, is a medium > access control (MAC) layer protocol for managing communication between > LPWAN gateways and end-node devices, maintained by the LoRa Alliance. > LoRaWAN™ Specification could be downloaded at: > https://lora-alliance.org/lorawan-for-developers > > However, LoRaWAN is not implemented in Linux kernel right now, so I am > trying to develop it. Here is my repository: > https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN > > Because it is a kind of network, the ideal usage in an user space > program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with > other socket APIs. Therefore, the definitions like AF_LORAWAN, > PF_LORAWAN ..., must be listed in the header files of glibc. > For the driver in kernel space, the definitions also must be listed in > the corresponding Linux socket header files. > Especially, both are for the testing programs. > > Back to the mentioned "LoRaWAN is not implemented in Linux kernel now". > Could or should we add the definitions into corresponding kernel header > files now, if LoRaWAN will be accepted as a subsystem in Linux? when you submit your LoRaWAN subsystem to netdev for review, include a patch that adds these new address family definitions. Just pick the next one available. There will be no pre-allocation of numbers until your work has been accepted upstream. Meaning, that the number might change if other address families get merged before yours. So you have to keep updating. glibc will eventually follow the number assigned by the kernel. Regards Marcel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net: Add new LoRaWAN subsystem 2018-05-11 15:39 ` Marcel Holtmann @ 2018-05-13 2:42 ` Jian-Hong Pan 2018-06-24 15:49 ` Andreas Färber 0 siblings, 1 reply; 6+ messages in thread From: Jian-Hong Pan @ 2018-05-13 2:42 UTC (permalink / raw) To: Marcel Holtmann Cc: David S. Miller, Alexander Aring, Stefan Schmidt, linux-wpan - ML, netdev, linux-kernel Hi Jiri and Marcel, 2018-05-11 23:39 GMT+08:00 Marcel Holtmann <marcel@holtmann.org>: > Hi Jian-Hong, > >> A Low-Power Wide-Area Network (LPWAN) is a type of wireless >> telecommunication wide area network designed to allow long range >> communications at a low bit rate among things (connected objects), such >> as sensors operated on a battery. It can be used widely in IoT area. >> LoRaWAN, which is one kind of implementation of LPWAN, is a medium >> access control (MAC) layer protocol for managing communication between >> LPWAN gateways and end-node devices, maintained by the LoRa Alliance. >> LoRaWAN™ Specification could be downloaded at: >> https://lora-alliance.org/lorawan-for-developers >> >> However, LoRaWAN is not implemented in Linux kernel right now, so I am >> trying to develop it. Here is my repository: >> https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN >> >> Because it is a kind of network, the ideal usage in an user space >> program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with >> other socket APIs. Therefore, the definitions like AF_LORAWAN, >> PF_LORAWAN ..., must be listed in the header files of glibc. >> For the driver in kernel space, the definitions also must be listed in >> the corresponding Linux socket header files. >> Especially, both are for the testing programs. >> >> Back to the mentioned "LoRaWAN is not implemented in Linux kernel now". >> Could or should we add the definitions into corresponding kernel header >> files now, if LoRaWAN will be accepted as a subsystem in Linux? > > when you submit your LoRaWAN subsystem to netdev for review, include a patch that adds these new address family definitions. Just pick the next one available. There will be no pre-allocation of numbers until your work has been accepted upstream. Meaning, that the number might change if other address families get merged before yours. So you have to keep updating. glibc will eventually follow the number assigned by the kernel. Thanks for your guidance. I will follow the steps. Thanks a lot, Jian-Hong Pan > Regards > > Marcel > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net: Add new LoRaWAN subsystem 2018-05-13 2:42 ` Jian-Hong Pan @ 2018-06-24 15:49 ` Andreas Färber 2018-06-26 16:02 ` Jian-Hong Pan 0 siblings, 1 reply; 6+ messages in thread From: Andreas Färber @ 2018-06-24 15:49 UTC (permalink / raw) To: Jian-Hong Pan Cc: Marcel Holtmann, David S. Miller, Alexander Aring, Stefan Schmidt, linux-wpan - ML, netdev, linux-kernel Hi Jian-Hong Pan, Am 13.05.2018 um 04:42 schrieb Jian-Hong Pan: > Hi Jiri and Marcel, > > 2018-05-11 23:39 GMT+08:00 Marcel Holtmann <marcel@holtmann.org>: >> Hi Jian-Hong, >> >>> A Low-Power Wide-Area Network (LPWAN) is a type of wireless >>> telecommunication wide area network designed to allow long range >>> communications at a low bit rate among things (connected objects), such >>> as sensors operated on a battery. It can be used widely in IoT area. >>> LoRaWAN, which is one kind of implementation of LPWAN, is a medium >>> access control (MAC) layer protocol for managing communication between >>> LPWAN gateways and end-node devices, maintained by the LoRa Alliance. >>> LoRaWAN™ Specification could be downloaded at: >>> https://lora-alliance.org/lorawan-for-developers >>> >>> However, LoRaWAN is not implemented in Linux kernel right now, so I am >>> trying to develop it. Here is my repository: >>> https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN >>> >>> Because it is a kind of network, the ideal usage in an user space >>> program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with >>> other socket APIs. Therefore, the definitions like AF_LORAWAN, >>> PF_LORAWAN ..., must be listed in the header files of glibc. >>> For the driver in kernel space, the definitions also must be listed in >>> the corresponding Linux socket header files. >>> Especially, both are for the testing programs. >>> >>> Back to the mentioned "LoRaWAN is not implemented in Linux kernel now". >>> Could or should we add the definitions into corresponding kernel header >>> files now, if LoRaWAN will be accepted as a subsystem in Linux? >> >> when you submit your LoRaWAN subsystem to netdev for review, include a patch that adds these new address family definitions. Just pick the next one available. There will be no pre-allocation of numbers until your work has been accepted upstream. Meaning, that the number might change if other address families get merged before yours. So you have to keep updating. glibc will eventually follow the number assigned by the kernel. > > Thanks for your guidance. I will follow the steps. I have been working on a similar thing on and off since proposing it at FOSDEM 2017: At https://github.com/afaerber/lora-modules you will find my proof of concept of PF_LORA with SOCK_DGRAM and stub drivers for various modules. My idea was to layer LoRaWAN on top of LoRa later. The way I have developed this was to simply reuse numbers unused in our distro kernel and built my modules against the distro kernel, to avoid frequent reboots and full kernel builds. Not having looked at your code yet, do you think our implementations are fairly independent at this point, or do you see conflicts apart from number allocation? Like, I am currently using lora0 as name - are you planning to use lorawan0 or rather something more generic like lpwan0? We might place your code in net/lora/lorawan/ and mine in net/lora/? More problematic would be the actual device drivers, where some devices would support both modes - some with soft MAC, others with full MAC. Do you have any ideas how to handle that in a sane way? Please keep me CC'ed on any follow-ups. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] net: Add new LoRaWAN subsystem 2018-06-24 15:49 ` Andreas Färber @ 2018-06-26 16:02 ` Jian-Hong Pan 0 siblings, 0 replies; 6+ messages in thread From: Jian-Hong Pan @ 2018-06-26 16:02 UTC (permalink / raw) To: Andreas Färber Cc: Marcel Holtmann, David S. Miller, Alexander Aring, Stefan Schmidt, linux-wpan - ML, netdev, linux-kernel Hi Andreas, 2018-06-24 23:49 GMT+08:00 Andreas Färber <afaerber@suse.de>: > Hi Jian-Hong Pan, > > Am 13.05.2018 um 04:42 schrieb Jian-Hong Pan: >> Hi Jiri and Marcel, >> >> 2018-05-11 23:39 GMT+08:00 Marcel Holtmann <marcel@holtmann.org>: >>> Hi Jian-Hong, >>> >>>> A Low-Power Wide-Area Network (LPWAN) is a type of wireless >>>> telecommunication wide area network designed to allow long range >>>> communications at a low bit rate among things (connected objects), such >>>> as sensors operated on a battery. It can be used widely in IoT area. >>>> LoRaWAN, which is one kind of implementation of LPWAN, is a medium >>>> access control (MAC) layer protocol for managing communication between >>>> LPWAN gateways and end-node devices, maintained by the LoRa Alliance. >>>> LoRaWAN™ Specification could be downloaded at: >>>> https://lora-alliance.org/lorawan-for-developers >>>> >>>> However, LoRaWAN is not implemented in Linux kernel right now, so I am >>>> trying to develop it. Here is my repository: >>>> https://github.com/starnight/LoRa/tree/lorawan-ndo/LoRaWAN >>>> >>>> Because it is a kind of network, the ideal usage in an user space >>>> program should be like "socket(PF_LORAWAN, SOCK_DGRAM, 0)" and with >>>> other socket APIs. Therefore, the definitions like AF_LORAWAN, >>>> PF_LORAWAN ..., must be listed in the header files of glibc. >>>> For the driver in kernel space, the definitions also must be listed in >>>> the corresponding Linux socket header files. >>>> Especially, both are for the testing programs. >>>> >>>> Back to the mentioned "LoRaWAN is not implemented in Linux kernel now". >>>> Could or should we add the definitions into corresponding kernel header >>>> files now, if LoRaWAN will be accepted as a subsystem in Linux? >>> >>> when you submit your LoRaWAN subsystem to netdev for review, include a patch that adds these new address family definitions. Just pick the next one available. There will be no pre-allocation of numbers until your work has been accepted upstream. Meaning, that the number might change if other address families get merged before yours. So you have to keep updating. glibc will eventually follow the number assigned by the kernel. >> >> Thanks for your guidance. I will follow the steps. > > I have been working on a similar thing on and off since proposing it at > FOSDEM 2017: Wow! Great! I get new friends :) > At https://github.com/afaerber/lora-modules you will find my proof of > concept of PF_LORA with SOCK_DGRAM and stub drivers for various modules. > My idea was to layer LoRaWAN on top of LoRa later. We have the same idea here. > The way I have developed this was to simply reuse numbers unused in our > distro kernel and built my modules against the distro kernel, to avoid > frequent reboots and full kernel builds. I use the the AF_MAX number as AF_LORAWAN and the new AF_MAX will be the old AF_MAX + 1 And so on ... > Not having looked at your code yet, do you think our implementations are > fairly independent at this point, or do you see conflicts apart from > number allocation? Like, I am currently using lora0 as name - are you > planning to use lorawan0 or rather something more generic like lpwan0? The interface name I created is loraX, X will be 0, 1, 2 ... 4: lora0: <NOARP,UP,LOWER_UP> mtu 20 qdisc noqueue state UNKNOWN group default qlen 1000 link/[830] 01:02:03:04 brd ff:ff:ff:ff > We might place your code in net/lora/lorawan/ and mine in net/lora/? My implementation is: LoRaWAN class module: net/lorawan/ LoRa device drivers: drivers/net/lorawan/sx127X ... > More problematic would be the actual device drivers, where some devices > would support both modes - some with soft MAC, others with full MAC. Do > you have any ideas how to handle that in a sane way? Let me guess! You have the LoRa "chips" and "modules", am I correct? If I am right, here is my opinion: Most of the LoRa chips go with the SPI interface. These are okay. However, the LoRa modules go with their own protocols (like AT commands) over the serial port. The modules also are the combination of an MCU and a LoRa chip. Users can flash the firmware of the MCU on their own directly. I prefer having user space applications deal with these modules, until there is a formal spec for these kind of modules. Regards, Jian-Hong Pan > Please keep me CC'ed on any follow-ups. > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-06-26 16:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-08 15:33 [RFC] net: Add new LoRaWAN subsystem Jian-Hong Pan 2018-05-11 8:16 ` Jiri Pirko 2018-05-11 15:39 ` Marcel Holtmann 2018-05-13 2:42 ` Jian-Hong Pan 2018-06-24 15:49 ` Andreas Färber 2018-06-26 16:02 ` Jian-Hong Pan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.