Subject: [lp-wan] Presentation slots for today's interim meeting; Re: Re-chartering and SCHC-Minimal

From: <[email-masked]>
Date: Wed, 3 Oct 2018 13:30:26 +0000

Hello Alex,

I think you raise good questions in the mail below.
Don't you want to put them on the agenda today for the interim meeting
(time permitting)?
Regarding the questions themselves, I originally assumed Option 1, but I
have come to recognise the value of some form of option 2.
Having some form of basic communication could allow to bootstrap
over-the-air provisioning of the SCHC context.
One would need a rule for no-compression (easy), and a leat one basic
fragmentation mode (this becomes tricky since now we need to agree on
which mode, window size, etc.)
Best regards

Dominique 

Le 20/09/18 13:52, « lp-wan on behalf of Alexander Pelov »
<[email-masked] on behalf of [email-masked]> a écrit :

>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
>
>
>_______________________________________________
>lp-wan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lp-wan

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alexander Pelov <[email-masked]>
Date: Wed, 3 Oct 2018 15:33:12 +0200

Hi Dominique,

(chair hat off)

Sure, I was assuming there is no desire to discuss these questions for the moment.
I'll add a couple of slides for that and talk them over if time permits.

Cheers
Alex

> On 3 Oct 2018, at 15:30, <[email-masked]> <[email-masked]> wrote:
> 
> Hello Alex,
>