Subject: [lp-wan] Ticket #5 Decoupled Fragmentation and SCHC Compression

From: ana minaburo <[email-masked]>
Date: Tue, 17 Apr 2018 11:07:10 +0200

Hello,

Here you will find the link to the Ticket:

https://trac.ietf.org/trac/lpwan/ticket/5

The question was: Maybe it is possible to mention that the fragmentation
can be decoupled and located near the NGW since for some LPWAN technologies
there may be timing constraints?

- We have improved the overall description of the Compression and
Fragmentation

- Section 6  the first part, explains where in the Architecture the
different instances of the Compression and Fragmentation are performed.
" The NGW sends the data to an SCHC Fragmentation and then to the SCHC C/D
for decompression.  The SCHC C/D in the Network side can be located in the
Network Gateway (NGW) or somewhere else as long as a tunnel is established
between the NGW and the SCHC Compression / Fragmentation.  Note that, for
some LPWAN technologies, it MAY be suitable to locate SCHC Fragmentation
and reassembly functionality nearer the NGW, in order to better deal with
time constraints of such technologies. "

Do we need to add something else? Do we answer your question?

Ana

---

From: <[email-masked]>
Date: Tue, 24 Apr 2018 14:50:48 +0000

Speaking for myself, I'm happy with the way this issue has been addressed.

The text could be polished even a bit more, I'll provide suggestions.
One example : "The NGW sends the data to an SCHC Fragmentation and then to the SCHC C/D for decompression."
Since we are talking about the Dev to Infrastructure transmission, this should be "the HGW send the data to the SCHC Reassembly and from there to the SCHC C/D for decompression" of something similar.
I think I suggested some time ago that we create the "SCHC F/R" term to describe the Fragmentation/Reassembly functionnality, mimicking SCHC C/D.
Also, we need to decide if SCHC is pronouced esss-seeee-heych-seeee or shiiiic, and therefore make a final decision about "an SCHC whatever" vs. "a SCHC whatever".
Best

Dominique

De : lp-wan <[email-masked]<mailto:[email-masked]>> on behalf of ana minaburo <[email-masked]<mailto:[email-masked]>>
Date : Tuesday 17 April 2018 11:07
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : [lp-wan] Ticket #5 Decoupled Fragmentation and SCHC Compression

Hello,

The question was: Maybe it is possible to mention that the fragmentation can be decoupled and located near the NGW since for some LPWAN technologies there may be timing constraints?

- We have improved the overall description of the Compression and Fragmentation

- Section 6  the first part, explains where in the Architecture the different instances of the Compression and Fragmentation are performed.
" The NGW sends the data to an SCHC Fragmentation and then to the SCHC C/D for decompression.  The SCHC C/D in the Network side can be located in the Network Gateway (NGW) or somewhere else as long as a tunnel is established between the NGW and the SCHC Compression / Fragmentation.  Note that, for some LPWAN technologies, it MAY be suitable to locate SCHC Fragmentation and reassembly functionality nearer the NGW, in order to better deal with time constraints of such technologies. "

Ana

_________________________________________________________________________________________________________________________

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.