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:

quoted

quoted

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

quoted

quoted

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.

quoted

quoted

3) Only the transmit path is partially implemented

already.

quoted

quoted

The assumption
   is that the devices should go into receive mode by

default

quoted

quoted

and only
   interrupt that when asked to transmit.

4) Some hardware settings need to be supplied

externally,

quoted

quoted

such as the radio
   frequency for some modules, but many others can be
runtime-configured,
   such as Spreading Factor, Bandwidth, Sync Word, or

which

quoted

quoted

antenna to use.
   What settings should be implemented as socket option

vs.

quoted

quoted

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

quoted

quoted

with that properly?

  a) Is there any precedence from the Wifi world for
dynamically selecting
     between our own trusted Open Source

implementation

quoted

quoted

vs. hardware/firmware
     accelerated and/or certified implementations?

  b) Would a proof of concept for FSK (non-LoRa) modes

be

quoted

quoted

required for
     merging any LoRa driver for chipsets that support

both?

quoted

quoted

Or is there any
     facility or design guidelines that would allow us to

focus

quoted

quoted

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 rather than duplicating.
There would need a bit of additional information to capture duty-cycle requirements, 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 duty-cycle.
I am unsure if 802.15.4 uses this database, most of the naming seems geared towards 80211, nl80211, cfg80211 so perhaps we need our own versions of these with a common component, I hope the maintainers can give some guidance 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 regulatory 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 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

quoted

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)

quoted

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)