Date:   Wed, 18 Jul 2018 11:28:41 +0000
From:   Ben Whitten <Ben.Whitten@...rdtech.com>
To:     Andreas Färber <afaerber@...e.de>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jian-Hong Pan <starnight@...cu.edu.tw>,
        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>,
        Brian Ray <brian.ray@...k-labs.com>,
        "lora@...balsat.com.tw" <lora@...balsat.com.tw>,
        Alexander Graf <agraf@...e.de>,
        Michal Kubeček <mkubecek@...e.cz>,
        Rob Herring <robh@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Steve deRosier <derosier@...il.com>,
        Mark Brown <broonie@...nel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        Hasnain Virk <Hasnain.Virk@....com>,
        Stefan Schmidt <stefan@...enfreihafen.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "seth.forshee@...onical.com" <seth.forshee@...onical.com>
Subject: RE: [RFC net-next 00/15] net: A socket API for LoRa

> 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 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
> 
> > 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)

Powered by blists - more mailing lists