Re: [RFC net-next 00/15] net: A socket API for LoRa

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

+ linux-wireless + Stefan + Seth

Am 11.07.2018 um 17:21 schrieb Ben Whitten:
>> This patchset is clearly not ready for merging, but is being
>> submitted for
>> discussion, as requested by Jiri, in particular of the design
>> choices:
>>
>> 1) PF_LORA/AF_LORA and associated identifiers are
>> proposed to represent
>>    this technology. While for an SX1276 - case a) above - it
>> might work to
>>    layer LoRaWAN as a protocol option for PF_LORA and add
>> LoRaWAN address
>>    fields to the union in my sockaddr_lora, how would that
>> work for devices
>>    that only support LoRaWAN but not pure LoRa? Do we
>> need both AF_LORA and
>>    AF_LORAWAN, or just a separate ETH_P_LORAWAN or
>> ARPHRD_LORAWAN?
>>
>> 2) PF_LORA is used with SOCK_DGRAM here. The
>> assumption is that RAW mode
>>    would be DGRAM plus preamble plus optional checksum.
>>
>> 3) Only the transmit path is partially implemented already.
>> The assumption
>>    is that the devices should go into receive mode by default
>> and only
>>    interrupt that when asked to transmit.
>>
>> 4) Some hardware settings need to be supplied externally,
>> such as the radio
>>    frequency for some modules, but many others can be
>> runtime-configured,
>>    such as Spreading Factor, Bandwidth, Sync Word, or which
>> antenna to use.
>>    What settings should be implemented as socket option vs.
>> netlink layer
>>    vs. ioctl vs. sysfs? What are the criteria to apply?
>>
>> 5) Many of the modules support multiple modes, such as
>> LoRa, LoRaWAN and FSK.
>>    Lacking a LoRaWAN implementation, I am currently
>> switching them into LoRa
>>    mode at probe time wherever possible. How do we deal
>> with that properly?
>>
>>   a) Is there any precedence from the Wifi world for
>> dynamically selecting
>>      between our own trusted Open Source implementation
>> vs. hardware/firmware
>>      accelerated and/or certified implementations?
>>
>>   b) Would a proof of concept for FSK (non-LoRa) modes be
>> required for
>>      merging any LoRa driver for chipsets that support both?
>> Or is there any
>>      facility or design guidelines that would allow us to focus
>> on LoRa and
>>      LoRaWAN and leave non-LoRa radio modes to later
>> contributors?
> 
> Down the line I think we should also plan for a CRDA style regdb somewhere in the path for raw LoRa transceivers operating as softMAC, much like with WiFi.

Yes, I had raised the topic of wireless-regdb for Stefan's conference -
currently it seems to only cover 2.4 GHz, 5 GHz and 60 GHz. Not sure if
we can easily extend that to cover 433 MHz, 868 MHz, 915 MHz and 923 MHz
bands or whether we'd just need something similar... Is 802.15.4 able to
share this database with Wifi?

An argument to share with Wifi might be that Semtech's SX1280 and SX1281
2.4 GHz transceivers claim to support LoRa modulation, too. Having two
different regulatory DBs interact with LoRa drivers seems a bad idea,
and duplicating 2.4 GHz into a new DB doesn't sound appealing either.

https://www.semtech.com/products/wireless-rf/24-ghz-transceivers

Meanwhile my attempt to play with netlink during SUSE Hackweek has been
going slow and I could use some guidance or a volunteer to contribute: I
have a bare skeleton of registration, commands, attributes and multicast
groups, but no plan yet how to connect that to the actual drivers to
query or apply the settings...

https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/net/lora/netlink.c?h=lora-next

> LoRa radios used in Gateway devices are typically relatively high power (capable of 27dBm) and operate in bands with certain restrictions, eg the EU has keep out areas within 868MHz for alarms and SRD devices must abide by certain duty cycle restrictions, there are also maximum powers to consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K, L, M, N, P, Q)

> The certified AT style modules will (should) already have this regulatory data baked in so it only applied to situations where we drive the transceivers directly, but it wouldn't hurt to check that the frequency being asked to transmit on doesn't spill into a restricted band.

Some do have configuration options that will need to be set or checked.

Regards,
Andreas

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

RE: [RFC net-next 00/15] net: A socket API for LoRa

[Ben Whitten]

PiBTdWJqZWN0OiBSZTogW1JGQyBuZXQtbmV4dCAwMC8xNV0gbmV0OiBBIHNvY2tldCBBUEkgZm9y
IExvUmENCj4gDQo+ICsgbGludXgtd2lyZWxlc3MgKyBTdGVmYW4gKyBTZXRoDQo+IA0KPiBBbSAx
MS4wNy4yMDE4IHVtIDE3OjIxIHNjaHJpZWIgQmVuIFdoaXR0ZW46DQo+ID4+IFRoaXMgcGF0Y2hz
ZXQgaXMgY2xlYXJseSBub3QgcmVhZHkgZm9yIG1lcmdpbmcsIGJ1dCBpcyBiZWluZw0KPiA+PiBz
dWJtaXR0ZWQgZm9yDQo+ID4+IGRpc2N1c3Npb24sIGFzIHJlcXVlc3RlZCBieSBKaXJpLCBpbiBw
YXJ0aWN1bGFyIG9mIHRoZSBkZXNpZ24NCj4gPj4gY2hvaWNlczoNCj4gPj4NCj4gPj4gMSkgUEZf
TE9SQS9BRl9MT1JBIGFuZCBhc3NvY2lhdGVkIGlkZW50aWZpZXJzIGFyZQ0KPiA+PiBwcm9wb3Nl
ZCB0byByZXByZXNlbnQNCj4gPj4gICAgdGhpcyB0ZWNobm9sb2d5LiBXaGlsZSBmb3IgYW4gU1gx
Mjc2IC0gY2FzZSBhKSBhYm92ZSAtIGl0DQo+ID4+IG1pZ2h0IHdvcmsgdG8NCj4gPj4gICAgbGF5
ZXIgTG9SYVdBTiBhcyBhIHByb3RvY29sIG9wdGlvbiBmb3IgUEZfTE9SQSBhbmQNCj4gYWRkDQo+
ID4+IExvUmFXQU4gYWRkcmVzcw0KPiA+PiAgICBmaWVsZHMgdG8gdGhlIHVuaW9uIGluIG15IHNv
Y2thZGRyX2xvcmEsIGhvdyB3b3VsZCB0aGF0DQo+ID4+IHdvcmsgZm9yIGRldmljZXMNCj4gPj4g
ICAgdGhhdCBvbmx5IHN1cHBvcnQgTG9SYVdBTiBidXQgbm90IHB1cmUgTG9SYT8gRG8gd2UNCj4g
Pj4gbmVlZCBib3RoIEFGX0xPUkEgYW5kDQo+ID4+ICAgIEFGX0xPUkFXQU4sIG9yIGp1c3QgYSBz
ZXBhcmF0ZSBFVEhfUF9MT1JBV0FOIG9yDQo+ID4+IEFSUEhSRF9MT1JBV0FOPw0KPiA+Pg0KPiA+
PiAyKSBQRl9MT1JBIGlzIHVzZWQgd2l0aCBTT0NLX0RHUkFNIGhlcmUuIFRoZQ0KPiA+PiBhc3N1
bXB0aW9uIGlzIHRoYXQgUkFXIG1vZGUNCj4gPj4gICAgd291bGQgYmUgREdSQU0gcGx1cyBwcmVh
bWJsZSBwbHVzIG9wdGlvbmFsDQo+IGNoZWNrc3VtLg0KPiA+Pg0KPiA+PiAzKSBPbmx5IHRoZSB0
cmFuc21pdCBwYXRoIGlzIHBhcnRpYWxseSBpbXBsZW1lbnRlZA0KPiBhbHJlYWR5Lg0KPiA+PiBU
aGUgYXNzdW1wdGlvbg0KPiA+PiAgICBpcyB0aGF0IHRoZSBkZXZpY2VzIHNob3VsZCBnbyBpbnRv
IHJlY2VpdmUgbW9kZSBieQ0KPiBkZWZhdWx0DQo+ID4+IGFuZCBvbmx5DQo+ID4+ICAgIGludGVy
cnVwdCB0aGF0IHdoZW4gYXNrZWQgdG8gdHJhbnNtaXQuDQo+ID4+DQo+ID4+IDQpIFNvbWUgaGFy
ZHdhcmUgc2V0dGluZ3MgbmVlZCB0byBiZSBzdXBwbGllZA0KPiBleHRlcm5hbGx5LA0KPiA+PiBz
dWNoIGFzIHRoZSByYWRpbw0KPiA+PiAgICBmcmVxdWVuY3kgZm9yIHNvbWUgbW9kdWxlcywgYnV0
IG1hbnkgb3RoZXJzIGNhbiBiZQ0KPiA+PiBydW50aW1lLWNvbmZpZ3VyZWQsDQo+ID4+ICAgIHN1
Y2ggYXMgU3ByZWFkaW5nIEZhY3RvciwgQmFuZHdpZHRoLCBTeW5jIFdvcmQsIG9yDQo+IHdoaWNo
DQo+ID4+IGFudGVubmEgdG8gdXNlLg0KPiA+PiAgICBXaGF0IHNldHRpbmdzIHNob3VsZCBiZSBp
bXBsZW1lbnRlZCBhcyBzb2NrZXQgb3B0aW9uDQo+IHZzLg0KPiA+PiBuZXRsaW5rIGxheWVyDQo+
ID4+ICAgIHZzLiBpb2N0bCB2cy4gc3lzZnM/IFdoYXQgYXJlIHRoZSBjcml0ZXJpYSB0byBhcHBs
eT8NCj4gPj4NCj4gPj4gNSkgTWFueSBvZiB0aGUgbW9kdWxlcyBzdXBwb3J0IG11bHRpcGxlIG1v
ZGVzLCBzdWNoIGFzDQo+ID4+IExvUmEsIExvUmFXQU4gYW5kIEZTSy4NCj4gPj4gICAgTGFja2lu
ZyBhIExvUmFXQU4gaW1wbGVtZW50YXRpb24sIEkgYW0gY3VycmVudGx5DQo+ID4+IHN3aXRjaGlu
ZyB0aGVtIGludG8gTG9SYQ0KPiA+PiAgICBtb2RlIGF0IHByb2JlIHRpbWUgd2hlcmV2ZXIgcG9z
c2libGUuIEhvdyBkbyB3ZQ0KPiBkZWFsDQo+ID4+IHdpdGggdGhhdCBwcm9wZXJseT8NCj4gPj4N
Cj4gPj4gICBhKSBJcyB0aGVyZSBhbnkgcHJlY2VkZW5jZSBmcm9tIHRoZSBXaWZpIHdvcmxkIGZv
cg0KPiA+PiBkeW5hbWljYWxseSBzZWxlY3RpbmcNCj4gPj4gICAgICBiZXR3ZWVuIG91ciBvd24g
dHJ1c3RlZCBPcGVuIFNvdXJjZQ0KPiBpbXBsZW1lbnRhdGlvbg0KPiA+PiB2cy4gaGFyZHdhcmUv
ZmlybXdhcmUNCj4gPj4gICAgICBhY2NlbGVyYXRlZCBhbmQvb3IgY2VydGlmaWVkIGltcGxlbWVu
dGF0aW9ucz8NCj4gPj4NCj4gPj4gICBiKSBXb3VsZCBhIHByb29mIG9mIGNvbmNlcHQgZm9yIEZT
SyAobm9uLUxvUmEpIG1vZGVzDQo+IGJlDQo+ID4+IHJlcXVpcmVkIGZvcg0KPiA+PiAgICAgIG1l
cmdpbmcgYW55IExvUmEgZHJpdmVyIGZvciBjaGlwc2V0cyB0aGF0IHN1cHBvcnQNCj4gYm90aD8N
Cj4gPj4gT3IgaXMgdGhlcmUgYW55DQo+ID4+ICAgICAgZmFjaWxpdHkgb3IgZGVzaWduIGd1aWRl
bGluZXMgdGhhdCB3b3VsZCBhbGxvdyB1cyB0bw0KPiBmb2N1cw0KPiA+PiBvbiBMb1JhIGFuZA0K
PiA+PiAgICAgIExvUmFXQU4gYW5kIGxlYXZlIG5vbi1Mb1JhIHJhZGlvIG1vZGVzIHRvIGxhdGVy
DQo+ID4+IGNvbnRyaWJ1dG9ycz8NCj4gPg0KPiA+IERvd24gdGhlIGxpbmUgSSB0aGluayB3ZSBz
aG91bGQgYWxzbyBwbGFuIGZvciBhIENSREEgc3R5bGUNCj4gcmVnZGIgc29tZXdoZXJlIGluIHRo
ZSBwYXRoIGZvciByYXcgTG9SYSB0cmFuc2NlaXZlcnMNCj4gb3BlcmF0aW5nIGFzIHNvZnRNQUMs
IG11Y2ggbGlrZSB3aXRoIFdpRmkuDQo+IA0KPiBZZXMsIEkgaGFkIHJhaXNlZCB0aGUgdG9waWMg
b2Ygd2lyZWxlc3MtcmVnZGIgZm9yIFN0ZWZhbidzDQo+IGNvbmZlcmVuY2UgLQ0KPiBjdXJyZW50
bHkgaXQgc2VlbXMgdG8gb25seSBjb3ZlciAyLjQgR0h6LCA1IEdIeiBhbmQgNjAgR0h6Lg0KPiBO
b3Qgc3VyZSBpZg0KPiB3ZSBjYW4gZWFzaWx5IGV4dGVuZCB0aGF0IHRvIGNvdmVyIDQzMyBNSHos
IDg2OCBNSHosIDkxNQ0KPiBNSHogYW5kIDkyMyBNSHoNCj4gYmFuZHMgb3Igd2hldGhlciB3ZSdk
IGp1c3QgbmVlZCBzb21ldGhpbmcgc2ltaWxhci4uLiBJcw0KPiA4MDIuMTUuNCBhYmxlIHRvDQo+
IHNoYXJlIHRoaXMgZGF0YWJhc2Ugd2l0aCBXaWZpPw0KDQpXZWxsIHRoZSBSRUFETUUgaW4gdGhl
IHdpcmVsZXNzLXJlZ2RiIGRvZXNuJ3QgYmluZCBpdHNlbGYgdG8gODAyMTEsIHRoZXJlIGFyZSBy
ZWZlcmVuY2VzIHRvIHRoZSBvdGhlciBFVFNJIEVOIHNwZWNzIHNvIHRoaXMgd291bGQgYmUgdGhl
IHBsYWNlIHJhdGhlciB0aGFuIGR1cGxpY2F0aW5nLg0KVGhlcmUgd291bGQgbmVlZCBhIGJpdCBv
ZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIGNhcHR1cmUgZHV0eS1jeWNsZSByZXF1aXJlbWVu
dHMsIGhvd2V2ZXIgdGhlIFNSRCBzcGVjIHN0YXRlcyB0aGUgbWF4aW11bSBiYW5kd2lkdGhzIGNh
biBiZSAnVGhlIHdob2xlIGJhbmQnLCBzbyB3aXRoIGEgZmxhZyBzZXQgd2UgY291bGQgaGlqYWNr
IHRoaXMgYmFuZCBpbmZvcm1hdGlvbiBmb3IgZHV0eS1jeWNsZS4NCkkgYW0gdW5zdXJlIGlmIDgw
Mi4xNS40IHVzZXMgdGhpcyBkYXRhYmFzZSwgbW9zdCBvZiB0aGUgbmFtaW5nIHNlZW1zIGdlYXJl
ZCB0b3dhcmRzIDgwMjExLCBubDgwMjExLCBjZmc4MDIxMSBzbyBwZXJoYXBzIHdlIG5lZWQgb3Vy
IG93biB2ZXJzaW9ucyBvZiB0aGVzZSB3aXRoIGEgY29tbW9uIGNvbXBvbmVudCwgSSBob3BlIHRo
ZSBtYWludGFpbmVycyBjYW4gZ2l2ZSBzb21lIGd1aWRhbmNlIGhlcmUuDQoNCj4gQW4gYXJndW1l
bnQgdG8gc2hhcmUgd2l0aCBXaWZpIG1pZ2h0IGJlIHRoYXQgU2VtdGVjaCdzDQo+IFNYMTI4MCBh
bmQgU1gxMjgxDQo+IDIuNCBHSHogdHJhbnNjZWl2ZXJzIGNsYWltIHRvIHN1cHBvcnQgTG9SYSBt
b2R1bGF0aW9uLCB0b28uDQo+IEhhdmluZyB0d28NCj4gZGlmZmVyZW50IHJlZ3VsYXRvcnkgREJz
IGludGVyYWN0IHdpdGggTG9SYSBkcml2ZXJzIHNlZW1zIGENCj4gYmFkIGlkZWEsDQo+IGFuZCBk
dXBsaWNhdGluZyAyLjQgR0h6IGludG8gYSBuZXcgREIgZG9lc24ndCBzb3VuZA0KPiBhcHBlYWxp
bmcgZWl0aGVyLg0KDQpXZWxsIEknbSBub3Qgc3VyZSBpZiB0aGUgbW9kdWxhdGlvbiBhZmZlY3Rz
IHJlZ3VsYXRvcnkgaW5mb3JtYXRpb24sIGp1c3QgYmFuZHMsIHBvd2VyLCBhbmQgdGVjaG5pcXVl
cyBsaWtlIERGUy4NCkFzIHRoZXNlIGNoaXBzIGFyZSAyLjRHSHogb25seSBJIGV4cGVjdCB0aGV5
IGFyZSBib3VuZCBieSB0aGUgZXhpc3RpbmcgcmVndWxhdG9yeSBpbmZvcm1hdGlvbiB3ZSB3b3Vs
ZCBqdXN0IG5lZWQgYSBwYXRoIHRvIGFjY2VzcyBpdC4NCiANCj4gaHR0cHM6Ly93d3cuc2VtdGVj
aC5jb20vcHJvZHVjdHMvd2lyZWxlc3MtcmYvMjQtZ2h6LQ0KPiB0cmFuc2NlaXZlcnMNCj4gDQo+
IE1lYW53aGlsZSBteSBhdHRlbXB0IHRvIHBsYXkgd2l0aCBuZXRsaW5rIGR1cmluZyBTVVNFDQo+
IEhhY2t3ZWVrIGhhcyBiZWVuDQo+IGdvaW5nIHNsb3cgYW5kIEkgY291bGQgdXNlIHNvbWUgZ3Vp
ZGFuY2Ugb3IgYSB2b2x1bnRlZXIgdG8NCj4gY29udHJpYnV0ZTogSQ0KPiBoYXZlIGEgYmFyZSBz
a2VsZXRvbiBvZiByZWdpc3RyYXRpb24sIGNvbW1hbmRzLCBhdHRyaWJ1dGVzDQo+IGFuZCBtdWx0
aWNhc3QNCj4gZ3JvdXBzLCBidXQgbm8gcGxhbiB5ZXQgaG93IHRvIGNvbm5lY3QgdGhhdCB0byB0
aGUgYWN0dWFsDQo+IGRyaXZlcnMgdG8NCj4gcXVlcnkgb3IgYXBwbHkgdGhlIHNldHRpbmdzLi4u
DQoNCkhhcHB5IHRvIGhlbHAsIEkgd2lsbCBiZSBzdGFydGluZyBmcm9tIHplcm8gb24gbmV0bGlu
ayBidXQgSSBjYW4gY29udHJpYnV0ZSBteSBleGlzdGluZyB3b3JrIGluY29ycG9yYXRpbmcgTWFy
a3MgY29tbWVudHMgZm9yIHN4MTMwMSBldGFsLg0KDQo+IGh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcv
cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L2FmYWVyYmVyL2xpDQo+IG51eC1sb3JhLmdpdC90cmVl
L25ldC9sb3JhL25ldGxpbmsuYz9oPWxvcmEtbmV4dA0KPiANCj4gPiBMb1JhIHJhZGlvcyB1c2Vk
IGluIEdhdGV3YXkgZGV2aWNlcyBhcmUgdHlwaWNhbGx5IHJlbGF0aXZlbHkNCj4gaGlnaCBwb3dl
ciAoY2FwYWJsZSBvZiAyN2RCbSkgYW5kIG9wZXJhdGUgaW4gYmFuZHMgd2l0aA0KPiBjZXJ0YWlu
IHJlc3RyaWN0aW9ucywgZWcgdGhlIEVVIGhhcyBrZWVwIG91dCBhcmVhcyB3aXRoaW4NCj4gODY4
TUh6IGZvciBhbGFybXMgYW5kIFNSRCBkZXZpY2VzIG11c3QgYWJpZGUgYnkgY2VydGFpbg0KPiBk
dXR5IGN5Y2xlIHJlc3RyaWN0aW9ucywgdGhlcmUgYXJlIGFsc28gbWF4aW11bSBwb3dlcnMgdG8N
Cj4gY29uc2lkZXIgZm9yIHN1Yi1iYW5kcy4gKEVUU0kgRU4gMzAwIDIyMC0yIFYzLjIuMSwgQmFu
ZHMgSywNCj4gTCwgTSwgTiwgUCwgUSkNCj4gDQo+ID4gVGhlIGNlcnRpZmllZCBBVCBzdHlsZSBt
b2R1bGVzIHdpbGwgKHNob3VsZCkgYWxyZWFkeSBoYXZlDQo+IHRoaXMgcmVndWxhdG9yeSBkYXRh
IGJha2VkIGluIHNvIGl0IG9ubHkgYXBwbGllZCB0byBzaXR1YXRpb25zDQo+IHdoZXJlIHdlIGRy
aXZlIHRoZSB0cmFuc2NlaXZlcnMgZGlyZWN0bHksIGJ1dCBpdCB3b3VsZG4ndA0KPiBodXJ0IHRv
IGNoZWNrIHRoYXQgdGhlIGZyZXF1ZW5jeSBiZWluZyBhc2tlZCB0byB0cmFuc21pdCBvbg0KPiBk
b2Vzbid0IHNwaWxsIGludG8gYSByZXN0cmljdGVkIGJhbmQuDQo+IA0KPiBTb21lIGRvIGhhdmUg
Y29uZmlndXJhdGlvbiBvcHRpb25zIHRoYXQgd2lsbCBuZWVkIHRvIGJlIHNldA0KPiBvciBjaGVj
a2VkLg0KPiANCj4gUmVnYXJkcywNCj4gQW5kcmVhcw0KPiANCj4gLS0NCj4gU1VTRSBMaW51eCBH
bWJILCBNYXhmZWxkc3RyLiA1LCA5MDQwOSBOw7xybmJlcmcsIEdlcm1hbnkNCj4gR0Y6IEZlbGl4
IEltZW5kw7ZyZmZlciwgSmFuZSBTbWl0aGFyZCwgR3JhaGFtIE5vcnRvbg0KPiBIUkIgMjEyODQg
KEFHIE7DvHJuYmVyZykNCg==

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Jian-Hong Pan]

2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten@lairdtech.com>:
>> Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa
>>
>> + linux-wireless + Stefan + Seth
>>
>> Am 11.07.2018 um 17:21 schrieb Ben Whitten:
>> >> This patchset is clearly not ready for merging, but is being
>> >> submitted for
>> >> discussion, as requested by Jiri, in particular of the design
>> >> choices:
>> >>
>> >> 1) PF_LORA/AF_LORA and associated identifiers are
>> >> proposed to represent
>> >>    this technology. While for an SX1276 - case a) above - it
>> >> might work to
>> >>    layer LoRaWAN as a protocol option for PF_LORA and
>> add
>> >> LoRaWAN address
>> >>    fields to the union in my sockaddr_lora, how would that
>> >> work for devices
>> >>    that only support LoRaWAN but not pure LoRa? Do we
>> >> need both AF_LORA and
>> >>    AF_LORAWAN, or just a separate ETH_P_LORAWAN or
>> >> ARPHRD_LORAWAN?
>> >>
>> >> 2) PF_LORA is used with SOCK_DGRAM here. The
>> >> assumption is that RAW mode
>> >>    would be DGRAM plus preamble plus optional
>> checksum.
>> >>
>> >> 3) Only the transmit path is partially implemented
>> already.
>> >> The assumption
>> >>    is that the devices should go into receive mode by
>> default
>> >> and only
>> >>    interrupt that when asked to transmit.
>> >>
>> >> 4) Some hardware settings need to be supplied
>> externally,
>> >> such as the radio
>> >>    frequency for some modules, but many others can be
>> >> runtime-configured,
>> >>    such as Spreading Factor, Bandwidth, Sync Word, or
>> which
>> >> antenna to use.
>> >>    What settings should be implemented as socket option
>> vs.
>> >> netlink layer
>> >>    vs. ioctl vs. sysfs? What are the criteria to apply?
>> >>
>> >> 5) Many of the modules support multiple modes, such as
>> >> LoRa, LoRaWAN and FSK.
>> >>    Lacking a LoRaWAN implementation, I am currently
>> >> switching them into LoRa
>> >>    mode at probe time wherever possible. How do we
>> deal
>> >> with that properly?
>> >>
>> >>   a) Is there any precedence from the Wifi world for
>> >> dynamically selecting
>> >>      between our own trusted Open Source
>> implementation
>> >> vs. hardware/firmware
>> >>      accelerated and/or certified implementations?
>> >>
>> >>   b) Would a proof of concept for FSK (non-LoRa) modes
>> be
>> >> required for
>> >>      merging any LoRa driver for chipsets that support
>> both?
>> >> Or is there any
>> >>      facility or design guidelines that would allow us to
>> focus
>> >> on LoRa and
>> >>      LoRaWAN and leave non-LoRa radio modes to later
>> >> contributors?
>> >
>> > Down the line I think we should also plan for a CRDA style
>> regdb somewhere in the path for raw LoRa transceivers
>> operating as softMAC, much like with WiFi.
>>
>> Yes, I had raised the topic of wireless-regdb for Stefan's
>> conference -
>> currently it seems to only cover 2.4 GHz, 5 GHz and 60 GHz.
>> Not sure if
>> we can easily extend that to cover 433 MHz, 868 MHz, 915
>> MHz and 923 MHz
>> bands or whether we'd just need something similar... Is
>> 802.15.4 able to
>> share this database with Wifi?
>
> Well the README in the wireless-regdb doesn't bind itself to 80211, there=
 are references to the other ETSI EN specs so this would be the place rathe=
r than duplicating.
> There would need a bit of additional information to capture duty-cycle re=
quirements, however the SRD spec states the maximum bandwidths can be 'The =
whole band', so with a flag set we could hijack this band information for d=
uty-cycle.
> I am unsure if 802.15.4 uses this database, most of the naming seems gear=
ed towards 80211, nl80211, cfg80211 so perhaps we need our own versions of =
these with a common component, I hope the maintainers can give some guidanc=
e here.
>
>> An argument to share with Wifi might be that Semtech's
>> SX1280 and SX1281
>> 2.4 GHz transceivers claim to support LoRa modulation, too.
>> Having two
>> different regulatory DBs interact with LoRa drivers seems a
>> bad idea,
>> and duplicating 2.4 GHz into a new DB doesn't sound
>> appealing either.
>
> Well I'm not sure if the modulation affects regulatory information, just =
bands, power, and techniques like DFS.
> As these chips are 2.4GHz only I expect they are bound by the existing re=
gulatory information we would just need a path to access it.
>
>> https://www.semtech.com/products/wireless-rf/24-ghz-
>> transceivers
>>
>> Meanwhile my attempt to play with netlink during SUSE
>> Hackweek has been
>> going slow and I could use some guidance or a volunteer to
>> contribute: I
>> have a bare skeleton of registration, commands, attributes
>> and multicast
>> groups, but no plan yet how to connect that to the actual
>> drivers to
>> query or apply the settings...
>
> Happy to help, I will be starting from zero on netlink but I can contribu=
te my existing work incorporating Marks comments for sx1301 etal.
>
>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li
>> nux-lora.git/tree/net/lora/netlink.c?h=3Dlora-next

Is this the repository used for the LoRa subsystem now?!!!
If it is, than great!

As the previous mails, I am trying to implement the LoRaWAN
specification as the soft MAC as the MAC layer over LoRa PHY.
This is the the talk about LoRaWAN class module I gave in Netdev Conf
https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsystem

The expectation is:

socket APIs:
send and receive the data
------------------------------------------------------------
LoRaWAN class module implements MAC:
append the header/footer, encryption/decryption, timing slot and MAC comman=
ds
------------------------------------------------------------
LoRa device drivers:
send and receive the messages for MAC layer
------------------------------------------------------------
LoRa devices

Is it possible that combine the LoRaWAN class module I implemented?
I start from the simplest class A end device's behavior, especially
the timing slot.
Also the encryption/decryption for uplink/downlink data messages.
I can send it as patches.

However, I have 2 problems right now.
1. Which Address and Protocol Family should we use?  PF_LORA or PF_LORAWAN?
2. To test the LoRaWAN class module, adding more procedures in LoRa
device drivers to register as a LoRaWAN device is needed.

Regards,
Jian-Hong Pan

>> > LoRa radios used in Gateway devices are typically relatively
>> high power (capable of 27dBm) and operate in bands with
>> certain restrictions, eg the EU has keep out areas within
>> 868MHz for alarms and SRD devices must abide by certain
>> duty cycle restrictions, there are also maximum powers to
>> consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K,
>> L, M, N, P, Q)
>>
>> > The certified AT style modules will (should) already have
>> this regulatory data baked in so it only applied to situations
>> where we drive the transceivers directly, but it wouldn't
>> hurt to check that the frequency being asked to transmit on
>> doesn't spill into a restricted band.
>>
>> Some do have configuration options that will need to be set
>> or checked.
>>
>> Regards,
>> Andreas
>>
>> --
>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany
>> GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton
>> HRB 21284 (AG N=C3=BCrnberg)

linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)

[Andreas Färber]

Hi Jian-Hong,

Am 02.08.2018 um 09:52 schrieb Jian-Hong Pan:
> 2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten@lairdtech.com>:
>>> 1) PF_LORA/AF_LORA and associated identifiers are
>>> proposed to represent
>>>    this technology. While for an SX1276 [...] it
>>> might work to
>>>    layer LoRaWAN as a protocol option for PF_LORA and
> add
>>> LoRaWAN address
>>>    fields to the union in my sockaddr_lora, how would that
>>> work for devices
>>>    that only support LoRaWAN but not pure LoRa? Do we
>>> need both AF_LORA and
>>>    AF_LORAWAN, or just a separate ETH_P_LORAWAN or
>>> ARPHRD_LORAWAN?
[...]
>>> Meanwhile my attempt to play with netlink during SUSE
>>> Hackweek has been
>>> going slow and I could use some guidance or a volunteer to
>>> contribute: I
>>> have a bare skeleton of registration, commands, attributes
>>> and multicast
>>> groups, but no plan yet how to connect that to the actual
>>> drivers to
>>> query or apply the settings...
>>
>> Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal.
>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li
>>> nux-lora.git/tree/net/lora/netlink.c?h=lora-next
> 
> Is this the repository used for the LoRa subsystem now?!!!
> If it is, than great!

Yes, my linux-lora.git contains this RFC patchset (modulo SX1276 fixes
spotted by kbuild bot) plus a new serdev driver for another module and
ongoing work by Ben and me for refactoring SX1301. It's monitored by the
0-day test service (kbuild bot).

As this patchset was an RFC and does not have any Acked-bys from
maintainers, the tree does not have a for-next branch integrated into
linux-next on basis of 4.18-rc1, but instead (like my personal GitHub
tree before) has a lora-next branch that rebases as patch queue on top
of linux-next for now.

The intent is to allow collaboration on getting things into a state that
I can later submit a clean (squashed) RFC v2 for review, with all issues
raised for this v1 addressed.

For contributing patches to my linux-lora.git I suggest to use
--subject-prefix="PATCH lora-next" to distinguish from net-next.
And I just realize I should add a MAINTAINERS entry in my tree to make
sure patches CC me, too. (I do monitor netdev for patches with subject
"lora", but chances are someone might omit that.)

> As the previous mails, I am trying to implement the LoRaWAN
> specification as the soft MAC as the MAC layer over LoRa PHY.
> This is the the talk about LoRaWAN class module I gave in Netdev Conf
> https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsystem
> 
> The expectation is:
> 
> socket APIs:
> send and receive the data
> ------------------------------------------------------------
> LoRaWAN class module implements MAC:
> append the header/footer, encryption/decryption, timing slot and MAC commands
> ------------------------------------------------------------
> LoRa device drivers:
> send and receive the messages for MAC layer
> ------------------------------------------------------------
> LoRa devices

Thanks for sharing your slides. We seem to be in alignment for the
abstract concept above. The devil is in the implementation details. ^.-

> Is it possible that combine the LoRaWAN class module I implemented?

Yes, as stated in this cover letter, I would love if you could help
merge your LoRaWAN implementation with my driver framework. Comparing
802.15.4 and 802.11, I think MAC code should go into net/maclorawan/ and
then is a fairly independent module, with you as maintainer.

> I start from the simplest class A end device's behavior, especially
> the timing slot.
> Also the encryption/decryption for uplink/downlink data messages.
> I can send it as patches.
> 
> However, I have 2 problems right now.
> 1. Which Address and Protocol Family should we use?  PF_LORA or PF_LORAWAN?

That was one of the questions I raised above. I now think we need both.
I'm not yet too deep into LoRaWAN, but from the AT command interfaces
I've seen there's confirmed and unconfirmed transmission modes that with
PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see
a way of doing both on a single PF_LORA SOCK_LORAWAN socket?

> 2. To test the LoRaWAN class module, adding more procedures in LoRa
> device drivers to register as a LoRaWAN device is needed.

No, I don't think so. There are (at least) two types of devices, LoRaWAN
and LoRa devices. The SX1276 is a pure LoRa device and thus should only
expose a LoRa network device. It'll be the task of the maclorawan module
to translate between the two layers, not the business of the device
driver; SX1276 should receive a ready-to-send LoRa skb. For Ethernet,
PF_INET and PF_INET6 don't need separate devices either, both use eth0.

What I do think we need is your struct lora_hw, maybe renamed to
lora_phy. That could be the missing piece for registration of the device
drivers with nllora module?
Note that similarly we'll also need an nllorawan module that needs to
work both with your maclorawan and with some of my device drivers that
implement the MAC in an MCU.

Additionally I've been looking into socket options at PF_LORA dgram
layer for some radio options, but discarded that again for lack of
precedence. Basically I wondered whether we could allow to choose SF,
bandwidth, etc. on socket level and then apply those settings before
sending one packet rather than expecting a global netlink operation that
affects all sockets for that interface.

Regards,
Andreas

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

Re: linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)

[Jian-Hong Pan]

Hi Andreas,

2018-08-03 16:44 GMT+08:00 Andreas F=C3=A4rber <afaerber@suse.de>:
> Hi Jian-Hong,
>
> Am 02.08.2018 um 09:52 schrieb Jian-Hong Pan:
>> 2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten@lairdtech.com>:
>>>> 1) PF_LORA/AF_LORA and associated identifiers are
>>>> proposed to represent
>>>>    this technology. While for an SX1276 [...] it
>>>> might work to
>>>>    layer LoRaWAN as a protocol option for PF_LORA and
>> add
>>>> LoRaWAN address
>>>>    fields to the union in my sockaddr_lora, how would that
>>>> work for devices
>>>>    that only support LoRaWAN but not pure LoRa? Do we
>>>> need both AF_LORA and
>>>>    AF_LORAWAN, or just a separate ETH_P_LORAWAN or
>>>> ARPHRD_LORAWAN?
> [...]
>>>> Meanwhile my attempt to play with netlink during SUSE
>>>> Hackweek has been
>>>> going slow and I could use some guidance or a volunteer to
>>>> contribute: I
>>>> have a bare skeleton of registration, commands, attributes
>>>> and multicast
>>>> groups, but no plan yet how to connect that to the actual
>>>> drivers to
>>>> query or apply the settings...
>>>
>>> Happy to help, I will be starting from zero on netlink but I can contri=
bute my existing work incorporating Marks comments for sx1301 etal.
>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li
>>>> nux-lora.git/tree/net/lora/netlink.c?h=3Dlora-next
>>
>> Is this the repository used for the LoRa subsystem now?!!!
>> If it is, than great!
>
> Yes, my linux-lora.git contains this RFC patchset (modulo SX1276 fixes
> spotted by kbuild bot) plus a new serdev driver for another module and
> ongoing work by Ben and me for refactoring SX1301. It's monitored by the
> 0-day test service (kbuild bot).
>
> As this patchset was an RFC and does not have any Acked-bys from
> maintainers, the tree does not have a for-next branch integrated into
> linux-next on basis of 4.18-rc1, but instead (like my personal GitHub
> tree before) has a lora-next branch that rebases as patch queue on top
> of linux-next for now.
>
> The intent is to allow collaboration on getting things into a state that
> I can later submit a clean (squashed) RFC v2 for review, with all issues
> raised for this v1 addressed.
>
> For contributing patches to my linux-lora.git I suggest to use
> --subject-prefix=3D"PATCH lora-next" to distinguish from net-next.
> And I just realize I should add a MAINTAINERS entry in my tree to make
> sure patches CC me, too. (I do monitor netdev for patches with subject
> "lora", but chances are someone might omit that.)
>
>> As the previous mails, I am trying to implement the LoRaWAN
>> specification as the soft MAC as the MAC layer over LoRa PHY.
>> This is the the talk about LoRaWAN class module I gave in Netdev Conf
>> https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsyst=
em
>>
>> The expectation is:
>>
>> socket APIs:
>> send and receive the data
>> ------------------------------------------------------------
>> LoRaWAN class module implements MAC:
>> append the header/footer, encryption/decryption, timing slot and MAC com=
mands
>> ------------------------------------------------------------
>> LoRa device drivers:
>> send and receive the messages for MAC layer
>> ------------------------------------------------------------
>> LoRa devices
>
> Thanks for sharing your slides. We seem to be in alignment for the
> abstract concept above. The devil is in the implementation details. ^.-
>
>> Is it possible that combine the LoRaWAN class module I implemented?
>
> Yes, as stated in this cover letter, I would love if you could help
> merge your LoRaWAN implementation with my driver framework. Comparing
> 802.15.4 and 802.11, I think MAC code should go into net/maclorawan/ and
> then is a fairly independent module, with you as maintainer.
>
>> I start from the simplest class A end device's behavior, especially
>> the timing slot.
>> Also the encryption/decryption for uplink/downlink data messages.
>> I can send it as patches.
>>
>> However, I have 2 problems right now.
>> 1. Which Address and Protocol Family should we use?  PF_LORA or PF_LORAW=
AN?
>
> That was one of the questions I raised above. I now think we need both.
> I'm not yet too deep into LoRaWAN, but from the AT command interfaces
> I've seen there's confirmed and unconfirmed transmission modes that with
> PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see
> a way of doing both on a single PF_LORA SOCK_LORAWAN socket?
>
>> 2. To test the LoRaWAN class module, adding more procedures in LoRa
>> device drivers to register as a LoRaWAN device is needed.
>
> No, I don't think so. There are (at least) two types of devices, LoRaWAN
> and LoRa devices. The SX1276 is a pure LoRa device and thus should only
> expose a LoRa network device. It'll be the task of the maclorawan module
> to translate between the two layers, not the business of the device
> driver; SX1276 should receive a ready-to-send LoRa skb. For Ethernet,
> PF_INET and PF_INET6 don't need separate devices either, both use eth0.
>
> What I do think we need is your struct lora_hw, maybe renamed to
> lora_phy. That could be the missing piece for registration of the device
> drivers with nllora module?
> Note that similarly we'll also need an nllorawan module that needs to
> work both with your maclorawan and with some of my device drivers that
> implement the MAC in an MCU.

Let me think these twice.

> Additionally I've been looking into socket options at PF_LORA dgram
> layer for some radio options, but discarded that again for lack of
> precedence. Basically I wondered whether we could allow to choose SF,
> bandwidth, etc. on socket level and then apply those settings before
> sending one packet rather than expecting a global netlink operation that
> affects all sockets for that interface.

According to the LoRaWAN Regional Parameters, we should have the APIs
to set the SF, frequency, bandwidth ...
The idea is: LoRaWAN class module gets the region of this device and
the device's abilities.  Then LoRaWAN class module calls the callback
functions to set the related parameters: SF, frequency, bandwidth ...
And of course, the setting actions only happen in the idle, standby or
stop status.
1. Interface is being startup.
2. Requested by MAC command.

But let start from simple case and add more features and complexity in
the future.

By the way, I am rearranging the module's code and try to make it
could be patches.

Regards,
Jian-Hong Pan

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

Hi Ben and Jian-Hong,

[- SPI - devicetree]

Am 18.07.2018 um 13:28 schrieb Ben Whitten:
>> Meanwhile my attempt to play with netlink during SUSE
>> Hackweek has been
>> going slow and I could use some guidance or a volunteer to
>> contribute: I
>> have a bare skeleton of registration, commands, attributes
>> and multicast
>> groups, but no plan yet how to connect that to the actual
>> drivers to
>> query or apply the settings...
> 
> Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal.

I've figured out a way to retrieve a frequency value via netlink:
By passing the lora0 ifindex in as attribute, nllora can look up the
net_device by index, and then via struct lora_dev_priv call into hooks
that the device drivers can optionally implement. :)

https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/net/lora/netlink.c?h=lora-next

Tested with HIMO-01M module.
The command might need an additional channel attribute for SX130x.

The corresponding nltest program (using libnl-genl) is here:
https://github.com/afaerber/lora-modules/blob/master/nltest.c

Cheers,
Andreas

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