Subject: [lp-wan] Re-chartering and SCHC-Minimal

From: Alexander Pelov <[email-masked]>
Date: Thu, 20 Sep 2018 13:52:22 +0200

Dear all,

During yesterday's meeting we had a short discussion on the ways to handle interoperability / avoid conflicts between two SCHC end-points. 
The issue of the moment being Fragmentation, but not limited to it.

How do we ensure that SCHC end-point A talks to SCHC end-point B without any troubles? If there is a mismatch (e.g. for A RuleID=1 is compression, whereas for B RuleID=1 is fragmentation), things will go west pretty fast. 

I like what Pascal said - A and B MUST know each other before initiating communication. They need to have their respective SCHC contexts (out-of-band). Otherwise, we may end having weird corner-case bugs.. or systems that don't work at all.
We may imagine that one of them is a limited device with one hard-coded context, and the other - a server talking to millions of devices. So, we'll have to see how the server discovers the context of the device. 
However, what if A and B know something about each other that allows them to just establish basic communication? (which in turn can enable capability discovery later on)

I'd like to capture the sense of what Pascal said and get a feeling of what you think of the following options.
For a communication to be possible, A and B need to share a context, which we may call the "link context".

We can then order by the level of constraints we put on the level of knowledge necessary for a communication to start: 
1) Strong coupling: A and B MUST know the full link context before engaging in any communication. 
  -> A way to work this out is to consider that a device assumes the network knows its context, and the network has a way of discovering the context of the device (which becomes the link context)

2) Weak coupling: A and B MUST know the semantics of any RuleID before using it. A and B know a subset of the link context. This basically means having a couple of preset rules. This leads to a SCHC-Minimal type of context.
  2.1) Baseline SCHC-Minimal: all technologies agree a set of several RuleIDs / behaviors, which allow for anyone to have working connectivity. A generic SCHC Server can then talk to any SCHC device (be it on LoRaWAN, Sigfox, NB-IoT, WI-SUN, etc.), without any device or technology specific knowledge.
  2.2) Technology-specific SCHC-Minimal: each technology defines its own set of RuleIDs. A technology-specific SCHC server can then talk to any device from that technology.

If we device that 2.1) is a really good thing, then 2.2) can also exist, e.g. there is SCHC-Minimal, and SCHC-LoRaWAN-Minimal (which extends SCHC-Minimal), and SCHC-Sigfox-Minimal (which extends SCHC-Minimal), and SCHC-NBIoT-Minimal, ... well, you got the gist.

Also 2) implies that there is a minimal set of capabilities that is imposed on ANY device that claims compatibility with SCHC-Minimal. I'd imagine that at least a Rule for sending a raw packet ("no compress") should be there. Also, a rule for ACK-Always, probably NO-ACK as well.

What do you think?

Alex