Date:   Thu, 2 Aug 2018 15:52:21 +0800
From:   Jian-Hong Pan <starnight@...cu.edu.tw>
To:     Ben Whitten <Ben.Whitten@...rdtech.com>
Cc:     Andreas Färber <afaerber@...e.de>,
        "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>,
        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

2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten@...rdtech.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 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

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 commands
------------------------------------------------------------
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ürnberg, Germany
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton
>> HRB 21284 (AG Nürnberg)

Powered by blists - more mailing lists