Subject: [lp-wan] Ticket #14: Legacy Devices

From: Ana Minaburo <[email-masked]>
Date: Mon, 26 Feb 2018 21:52:46 +0100

---Nicolas---

You have already defined a set of rules, rules are identified by a ruleID.

We could very simply have a new rule type which is executed at the
beginning of the processing of a frame(let’s call it an introduction rule)
(if this rule exists in the device’s rule set)

And another rule type that may be executed every time the device’s
over-the-air payload has been fully processed by the decompressor (a
conclusion rule)

Those rules would never be called in the compressed payload. But if they
exist they would be executed by the decompressor.

In short, Nicolas asks whether it is possible to have a LoRa?
<https://trac.ietf.org/trac/lpwan/wiki/LoRa> Frame encapsulated in
IPv6/UDP/CoAP even if there is no rule ID at all, e.g. for devices that are
not SCHC-aware.

My take is that it should be possible, that was something we discussed
early in the process. There should be a default rule that does not expect a
ruleID in the LPWAN data. I could not find where that is specified in the
document; since the spec is for the air protocol, it can be OK that it is
not even mentioned, but I’d rather it be. When we talk data model for the
rules, we’ll have to be able to configure a default ruleID for a device in
any case.

---Pascal----

Also, Nicolas indicates that rules must be based on DevEUI, not DevAddr?
<https://trac.ietf.org/trac/lpwan/wiki/DevAddr>, and appears to have an
issue with the timers we put in place for the fragmentation process, maybe
use the frame-counter, to be discussed.

Additional notes from a F2F talk we had:

   - CoAP rules should be able to place into the CoAP payload information
   from the NS (e.g. link quality) as well as information from the end device.

   - Rules should have rewritable fields (e.g. a DNS name or an address),
   and methods to rewrite them may be triggered by either a management console
   or the end device itself.

Ana: The draft- SCHC defines the way to compress/decompress the header and
the fragmentation process. The Rule ID and Rule size are out of the scope
of this document, and I think a new document with this ideas and with other
may be written to complete the need to define the usage of Rule ID.

Ana: A Rule ID section has been created and there we say:
The Rule ID the SCHC identifies are:

In the SCHC C/D context the Rule used to keep the Field Description of the
header packet.

In SCHC Fragmentation the specific modes and settings.

And at least one Rule ID may be reserved to the case where no SCHC C/D nor
SCHC fragmentation were possible.

Is this answer the input?