< draft-ietf-lpwan-schc-over-lorawan-01.txt   draft-ietf-lpwan-schc-over-lorawan-02.txt >
lpwan Working Group O. Gimenez, Ed. lpwan Working Group O. Gimenez, Ed.
Internet-Draft Semtech Internet-Draft Semtech
Intended status: Informational I. Petrov, Ed. Intended status: Informational I. Petrov, Ed.
Expires: December 28, 2019 Acklio Expires: January 9, 2020 Acklio
June 26, 2019 July 08, 2019
Static Context Header Compression (SCHC) over LoRaWAN Static Context Header Compression (SCHC) over LoRaWAN
draft-ietf-lpwan-schc-over-lorawan-01 draft-ietf-lpwan-schc-over-lorawan-02
Abstract Abstract
The Static Context Header Compression (SCHC) specification describes The Static Context Header Compression (SCHC) specification describes
generic header compression and fragmentation techniques for LPWAN generic header compression and fragmentation techniques for LPWAN
(Low Power Wide Area Networks) technologies. SCHC is a generic (Low Power Wide Area Networks) technologies. SCHC is a generic
mechanism designed for great flexibility, so that it can be adapted mechanism designed for great flexibility, so that it can be adapted
for any of the LPWAN technologies. for any of the LPWAN technologies.
This document provides the adaptation of SCHC for use in LoRaWAN This document provides the adaptation of SCHC for use in LoRaWAN
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
6. Security considerations . . . . . . . . . . . . . . . . . . . 16 6. Security considerations . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Uplink - Compression example - No fragmentation . . . . . 18 A.1. Uplink - Compression example - No fragmentation . . . . . 18
A.2. Uplink - Compression and fragmentation example . . . . . 19 A.2. Uplink - Compression and fragmentation example . . . . . 19
A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 20 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The Static Context Header Compression (SCHC) specification The Static Context Header Compression (SCHC) specification
[I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header [I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header
compression and fragmentation techniques that can be used on all compression and fragmentation techniques that can be used on all
LPWAN (Low Power Wide Area Networks) technologies defined in LPWAN (Low Power Wide Area Networks) technologies defined in
[RFC8376]. Even though those technologies share a great number of [RFC8376]. Even though those technologies share a great number of
common features like star-oriented topologies, network architecture, common features like star-oriented topologies, network architecture,
devices with mostly quite predictable communications, etc; they do devices with mostly quite predictable communications, etc; they do
skipping to change at page 11, line 36 skipping to change at page 11, line 36
| DTag | FCN | Payload | | DTag | FCN | Payload |
+ ----- + ------ + ------- + + ----- + ------ + ------- +
| 1 bit | 7 bits | | | 1 bit | 7 bits | |
Figure 5: All fragment except the last one. Header size is 8 bits (1 Figure 5: All fragment except the last one. Header size is 8 bits (1
byte). byte).
*SCHC ACK* *SCHC ACK*
| RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) | | DTag | C | Encoded bitmap (if C = 0) | Padding (0s) |
+ ------ + ----- + ----- + ----- + ------------------------- + ------------ + + ----- + ----- + ------------------------- + ------------ +
| 6 bits | 1 bit | 2 bit | 1 bit | 0 to 127 bits | 7 or 0 bits | | 1 bit | 1 bit | 0 to 127 bits | 7 or 0 bits |
Figure 6: SCHC ACK format, failed mic check. Figure 6: SCHC ACK format, failed mic check.
5.5.1.2. FPortUpDefault - 2 bytes header 5.5.1.2. FPortUpDefault - 2 bytes header
o *RuleID*: size is 6 bits (64 possible rules, 62 available for o *RuleID*: size is 6 bits (64 possible rules, 62 available for
compression) compression)
o *Window index*: encoded on W = 2 bits. So 4 windows are o *Window index*: encoded on W = 2 bits. So 4 windows are
available. available.
skipping to change at page 18, line 31 skipping to change at page 18, line 31
February 2014, <https://www.rfc-editor.org/info/rfc7136>. February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>. <https://www.rfc-editor.org/info/rfc8376>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-lpwan-ipv6-static-context-hc] [I-D.ietf-lpwan-ipv6-static-context-hc]
Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J. Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
Zuniga, "LPWAN Static Context Header Compression (SCHC) Zuniga, "Static Context Header Compression (SCHC) and
and fragmentation for IPv6 and UDP", draft-ietf-lpwan- fragmentation for LPWAN, application to UDP/IPv6", draft-
ipv6-static-context-hc-18 (work in progress), December ietf-lpwan-ipv6-static-context-hc-19 (work in progress),
2018. July 2019.
[lora-alliance-spec] [lora-alliance-spec]
Alliance, L., "LoRaWAN Specification Version V1.0.3", Alliance, L., "LoRaWAN Specification Version V1.0.3",
<https://lora-alliance.org/sites/default/files/2018-07/ <https://lora-alliance.org/sites/default/files/2018-07/
lorawan1.0.3.pdf>. lorawan1.0.3.pdf>.
Appendix A. Examples Appendix A. Examples
A.1. Uplink - Compression example - No fragmentation A.1. Uplink - Compression example - No fragmentation
Figure 16 is representing an applicative payload going through SCHC, Figure 16 is representing an applicative payload going through SCHC,
no fragmentation required no fragmentation required
An applicative payload of 78 bytes is passed to SCHC compression layer using An applicative payload of 78 bytes is passed to SCHC compression layer using
rule 1, allowing to compress it to 40 bytes: 2 bytes residue + 38 bytes rule 1, allowing to compress it to 40 bytes and 5 bits: 21 bits residue + 38 bytes
payload. payload.
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload | Padding=0b000 |
+ ------ + ------------------- + --------- + + ------ + ------------------- + --------- + ------------- +
| 1 | 18 bits | 38 bytes | | 1 | 21 bits | 38 bytes | 3 bits |
The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by
LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for
fragmentation. The payload will be transmitted through FPortUpDefault fragmentation. The payload will be transmitted through FPortUpDefault
| LoRaWAN Header | RuleID | Compression residue | Payload | | LoRaWAN Header | RuleID | Compression residue | Payload | Padding=b'000 |
+ -------------- + ------ + ------------------- + --------- + + -------------- + ------ + ------------------- + --------- + ------------- +
| XXXX | 1 | 18 bits | 38 bytes | | XXXX | 1 | 21 bits | 38 bytes | 3 bits |
Figure 16: Uplink example: compression without fragmentation Figure 16: Uplink example: compression without fragmentation
A.2. Uplink - Compression and fragmentation example A.2. Uplink - Compression and fragmentation example
Figure 17 is representing an applicative payload going through SCHC, Figure 17 is representing an applicative payload going through SCHC,
with fragmentation. with fragmentation.
An applicative payload of 478 bytes is passed to SCHC compression layer using An applicative payload of 478 bytes is passed to SCHC compression layer using
rule 1, allowing to compress it to 440 bytes: 18 bits residue + 138 bytes rule 1, allowing to compress it to 440 bytes: 21 bits residue + 138 bytes
payload. payload.
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- + + ------ + ------------------- + --------- +
| 1 | 18 bits | 138 bytes | | 1 | 21 bits | 138 bytes |
Given the size of the payload, FPortUpDefault will be used. Given the size of the payload, FPortUpDefault will be used.
The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by
LoRaWAN protocol: 9 bytes are available for SCHC payload. LoRaWAN protocol: 9 bytes are available for SCHC payload.
SCHC header is 2 bytes so 2 tiles are send in first fragment. SCHC header is 2 bytes so 2 tiles are send in first fragment.
| LoRaWAN Header | FOpts | RuleID | DTag | W | FCN | 2 tiles | | LoRaWAN Header | FOpts | RuleID | DTag | W | FCN | 2 tiles |
+ -------------- + ------- + ------ + ----- + ------ + ------ + ------- + + -------------- + ------- + ------ + ----- + ------ + ------ + ------- +
| XXXX | 2 bytes | 0 | 0 | 0 | 126 | 6 bytes | | XXXX | 2 bytes | 0 | 0 | 0 | 126 | 6 bytes |
Content of the two tiles is: Content of the two tiles is:
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- + + ------ + ------------------- + ------------------ +
| 1 | 18 bits | 3 bytes | | 1 | 21 bits | 2 bytes + 5 bits |
Next transmission MTU is 242 bytes, no FOpts. 80 tiles are transmitted: Next transmission MTU is 242 bytes, no FOpts. 80 tiles are transmitted:
| LoRaWAN Header | RuleID | DTag | W | FCN | 80 tiles | | LoRaWAN Header | RuleID | DTag | W | FCN | 80 tiles |
+ -------------- + ------ + ----- + ------ + ------ + --------- + + -------------- + ------ + ----- + ------ + ------ + --------- +
| XXXX | 0 | 0 | 0 | 124 | 240 bytes | | XXXX | 0 | 0 | 0 | 124 | 240 bytes |
Next transmission MTU is 242 bytes, no FOpts. All 65 remaining tiles are Next transmission MTU is 242 bytes, no FOpts. All 65 remaining tiles are
transmitted, last tile is only 2 bytes. transmitted, last tile is only 2 bytes. Padding is added for the remaining 6 bits.
| LoRaWAN Header | RuleID | DTag | W | FCN | MIC | 65 tiles | | LoRaWAN Header | RuleID | DTag | W | FCN | MIC | 65 tiles | Padding=b'000 |
+ -------------- + ------ + ----- + ------ + ------ + ----- + --------- + + -------------- + ------ + ----- + ------ + ------ + ----- + --------- + ---------------- +
| XXXX | 0 | 0 | 0 | 127 | CRC32 | 194 bytes | | XXXX | 0 | 0 | 0 | 127 | CRC32 | 194 bytes | 3 bits |
All packets have been received by the SCHC gateway, computed MIC is correct so All packets have been received by the SCHC gateway, computed MIC is correct so
the following ACK is send to the device: the following ACK is send to the device:
| LoRaWAN Header | RuleID | DTag | W | C | | LoRaWAN Header | RuleID | DTag | W | C |
+ -------------- + ------ + ----- + ------ + --- + + -------------- + ------ + ----- + ------ + --- +
| XXXX | 0 | 0 | 0 | 1 | | XXXX | 0 | 0 | 0 | 1 |
Figure 17: Uplink example: compression and fragmentation Figure 17: Uplink example: compression and fragmentation
A.3. Downlink A.3. Downlink
TODO An applicative payload of 43 bytes is passed to SCHC compression layer using
rule 1, allowing to compress it to 24 bytes and 5 bits: 21 bits residue + 22 bytes
payload.
| RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- +
| 1 | 21 bits | 18 bytes |
The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by
LoRaWAN protocol: 9 bytes are available for SCHC payload => it has to be fragmented.
| LoRaWAN Header | FOpts | RuleID | W | FCN | 1 tile |
+ -------------- + ------- + ------ + ------ + ------ + ------- +
| XXXX | 2 bytes | 0 | 0 | 0 | 8 bytes |
Content of the two tiles is:
| RuleID | Compression residue | Payload |
+ ------ + ------------------- + ------------------ +
| 1 | 21 bits | 2 bytes + 5 bits |
The receiver answers with an SCHC ACK
| RuleID | W = 0 | C = b'1 |
+ ------ + ----- + ------- +
| 6 bits | 1 bit | 1 bit |
The second downlink is send, no FOpts:
| LoRaWAN Header | RuleID | W | FCN | 1 tile |
+ -------------- + ------ + ------ + ------ + -------- +
| XXXX | 0 | 1 | 0 | 10 bytes |
The receiver answers with an SCHC ACK
| RuleID | W = 1 | C = b'1 |
+ ------ + ----- + ------- +
| 6 bits | 1 bit | 1 bit |
The third downlink is send, no FOpts:
| LoRaWAN Header | RuleID | W | FCN | 1 tile |
+ -------------- + ------ + ------ + ------ + -------- +
| XXXX | 0 | 0 | 0 | 10 bytes |
The receiver answers with an SCHC ACK
| RuleID | W = 0 | C = 1 |
+ ------ + ----- + ------- +
| 6 bits | 1 bit | 1 bit |
The last downlink is send, no FOpts:
| LoRaWAN Header | RuleID | W | FCN | 1 tile |
+ -------------- + ------ + ------ + ------ + -------- +
| XXXX | 0 | 1 | 1 | 2 bytes |
The receiver answers with an SCHC ACK
| RuleID | W = 1 | C = 1 |
+ ------ + ----- + ------- +
| 6 bits | 1 bit | 1 bit |
Figure 18: Downlink example: compression and fragmentation
Appendix B. Note Appendix B. Note
Authors' Addresses Authors' Addresses
Olivier Gimenez (editor) Olivier Gimenez (editor)
Semtech Semtech
14 Chemin des Clos 14 Chemin des Clos
Meylan Meylan
France France
 End of changes. 15 change blocks. 
30 lines changed or deleted 91 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/