-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #20 from Acklio/draft-ietf-lpwan-schc-over-lorawan-04
Draft ietf lpwan schc over lorawan 04
- Loading branch information
Showing
1 changed file
with
73 additions
and
47 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -29,13 +29,6 @@ author: | |
country: France | ||
email: [email protected] | ||
role: editor | ||
- ins: J. Catalano | ||
name: Julien Catalano | ||
org: Kerlink | ||
street: 1 rue Jacqueline Auriol | ||
city: 35235 Thorigné-Fouillard | ||
country: France | ||
email: [email protected] | ||
normative: | ||
RFC2119: | ||
RFC8174: | ||
|
@@ -53,6 +46,13 @@ informative: | |
name: LoRa Alliance | ||
date: 07.2018 | ||
target: https://lora-alliance.org/sites/default/files/2018-07/lorawan1.0.3.pdf | ||
I-D.ietf-lpwan-ipv6-static-context-hc: | ||
lora-alliance-remote-multicast-set: | ||
title: LoRaWAN Remote Multicast Setup Specification Version 1.0.0 | ||
author: | ||
name: LoRa Alliance | ||
date: 09.2018 | ||
target: https://lora-alliance.org/sites/default/files/2018-09/remote_multicast_setup_v1.0.0.pdf | ||
|
||
--- abstract | ||
|
||
|
@@ -307,12 +307,29 @@ confirmed messages. | |
settings and a network random nonce used to derive the session keys. | ||
* Data | ||
|
||
## Unicast and multicast technology | ||
|
||
LoRaWAN technology supports unicast downlinks, but also multicast: a packet | ||
send over LoRaWAN radio link can be received by several devices. It is | ||
useful to address many end-devices with same content, either a large binary | ||
file (firmware upgrade), or same command (e.g: lighting control). | ||
As IPv6 is also a multicast technology this feature MAY be used to address a | ||
group of devices. | ||
|
||
_Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. LoRaWAN | ||
multicast group definition in a network server and the relation between those | ||
groups and IPv6 groupID are out of scope of this document. | ||
|
||
_Note 2_: LoRa Alliance defined {{lora-alliance-remote-multicast-set}} as | ||
RECOMMENDED way to setup multicast groups on devices and create a synchronized | ||
reception window. | ||
|
||
# SCHC-over-LoRaWAN | ||
|
||
## LoRaWAN FPort {#lorawan-schc-payload} | ||
|
||
The LoRaWAN MAC layer features a frame port field in all frames. This field | ||
(FPort) is 8-bit long and the values from 1 to 223 can be used. It allows | ||
(FPort) is 8 bits long and the values from 1 to 223 can be used. It allows | ||
LoRaWAN networks and applications to identify data. | ||
|
||
The FPort field is part of the SCHC Packet or the SCHC Fragment, as shown in | ||
|
@@ -343,22 +360,19 @@ communication. The uplink and downlink fragmentation FPorts MUST be different. | |
|
||
## Rule ID management {#rule-id-management} | ||
|
||
RuleID minimum length MUST be 8 bits, and RECOMMENDED length is 8 bits. | ||
RuleID MSB is encoded in the LoRaWAN FPort as described in | ||
RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in | ||
{{lorawan-schc-payload}}. LoRaWAN supports up to 223 application FPorts in | ||
the range \[1;223\] as defined in section 4.3.2 of {{lora-alliance-spec}}, it implies | ||
that RuleID MSB SHOULD be inside this range. An application MAY reserve some | ||
FPort values for other needs as long as they don't conflict with FPorts used | ||
for SCHC C/D and SCHC F/R. | ||
|
||
A RuleID SHOULD be reserved to tag packets for which SCHC compression was not | ||
possible (no matching Rule was found). RuleIDs FPortUp and FPortDown are | ||
reserved for fragmentation, in order to improve interoperability RECOMMENDED | ||
values are: | ||
In order to improve interoperability RECOMMENDED fragmentation RuleID values are: | ||
|
||
* RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp | ||
* RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown | ||
* RuleID = 22 (8-bit) for which SCHC compression was not possible | ||
* RuleID = 22 (8-bit) for which SCHC compression was not possible (no matching | ||
rule was found) | ||
|
||
The remaining RuleIDs are available for compression. RuleIDs are shared between | ||
uplink and downlink sessions. A RuleID different from FPortUp or FPortDown | ||
|
@@ -394,8 +408,7 @@ All padding bits MUST be 0. | |
SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC packet | ||
as per {{lorawan-schc-payload}}. | ||
|
||
SCHC C/D RuleID size SHOULD be 8 bits to fit the LoRaWAN FPort field. RuleIDs | ||
matching FPortUp and FPortDown are reserved for SCHC Fragmentation. | ||
RuleIDs matching FPortUp and FPortDown are reserved for SCHC Fragmentation. | ||
|
||
## Fragmentation {#Frag} | ||
|
||
|
@@ -425,19 +438,18 @@ the fragmentation receiver. A single fragmentation rule is defined. | |
SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC | ||
fragment as per {{lorawan-schc-payload}}. | ||
|
||
* Minimum SCHC header is two bytes (the FPort byte + 1 additional byte) and the | ||
RECOMMENDED header size is two bytes. | ||
* RuleID: Recommended size is 8 bits in SCHC header. | ||
* SCHC header size is two bytes (the FPort byte + 1 additional byte). | ||
* RuleID: 8 bits stored in LoRaWAN FPort. | ||
* SCHC fragmentation reliability mode: `ACK-on-Error` | ||
* DTag: Size is 0 bit, not used | ||
* FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 64 tiles | ||
* FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 tiles | ||
are allowed in a window | ||
* Window index: encoded on W = 2 bits. So 4 windows are available. | ||
* RCS calculation algorithm: CRC32 using 0xEDB88320 (i.e. the reverse | ||
representation of the polynomial used e.g. in the Ethernet standard | ||
[RFC3385]) as suggested in {{I-D.ietf-lpwan-ipv6-static-context-hc}}. | ||
* MAX_ACK_REQUESTS: 8 | ||
* Tile: size is 5 bytes | ||
* Tile: size is 10 bytes | ||
* Retransmission and inactivity timers: | ||
LoRaWAN end-devices do not implement a "retransmission timer". At the end of | ||
a window or a fragmentation session, corresponding ACK(s) is (are) | ||
|
@@ -455,7 +467,7 @@ fragment as per {{lorawan-schc-payload}}. | |
|
||
With this set of parameters, the SCHC fragment header is 16 bits, | ||
including FPort; payload overhead will be 8 bits as FPort is already a part of | ||
LoRaWAN payload. MTU is: _4 windows * 64 tiles * 5 bytes per tile = 1280 bytes_ | ||
LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes per tile = 2520 bytes_ | ||
|
||
#### Regular fragments | ||
|
||
|
@@ -536,9 +548,12 @@ fragmentation transmitter. The following fields are common to all devices. | |
SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC | ||
fragment as described in {{lorawan-schc-payload}}. | ||
|
||
* SCHC fragmentation reliability mode: ACK-Always. | ||
* RuleID: Recommended size is 8 bits in SCHC header. | ||
* Window index: encoded on W=1 bit, as per {{I-D.ietf-lpwan-ipv6-static-context-hc}}. | ||
* SCHC fragmentation reliability mode: | ||
* Unicast downlinks: ACK-Always. | ||
* Multicast downlinks: No-ACK, reliability has be be ensured by the upper | ||
layer. This feature is OPTIONAL and may not be implemented by SCHC gateway. | ||
* RuleID: 8 bits stored in LoRaWAN FPort. | ||
* Window index (unicast only): encoded on W=1 bit, as per {{I-D.ietf-lpwan-ipv6-static-context-hc}}. | ||
* DTag: Size is 0 bit, not used | ||
* FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile | ||
(FCN=All-1 is reserved for SCHC). | ||
|
@@ -720,6 +735,13 @@ Contributors ordered by family name. | |
city: 91120 PALAISEAU | ||
country: FRANCE | ||
email: [email protected] | ||
- ins: J. Catalano | ||
name: Julien Catalano | ||
org: Kerlink | ||
street: 1 rue Jacqueline Auriol | ||
city: 35235 Thorigné-Fouillard | ||
country: France | ||
email: [email protected] | ||
- ins: M. Coracin | ||
name: Michael Coracin | ||
org: Semtech | ||
|
@@ -801,42 +823,46 @@ ruleID, 21 bits residue + 279 bytes payload. | |
| 1 | 21 bits | 279 bytes | | ||
|
||
|
||
The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by | ||
LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte FPort | ||
field. SCHC header is 2 bytes (including FPort) so 1 tile is sent in | ||
first fragment. | ||
The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by LoRaWAN | ||
protocol: 11 bytes are available for SCHC payload + 1 byte FPort field. | ||
SCHC header is 2 bytes (including FPort) so 1 tile is sent in first | ||
fragment. | ||
|
||
| LoRaWAN Header | LoRaWAN payload (6 bytes) | | ||
+ ------------------------------------- + ------------------------- + | ||
| | FOpts | RuleID=20 | W | FCN | 1 tile | | ||
+ -------------- + ------- + ---------- + ----- + ------ + -------- + | ||
| XXXX | 2 bytes | 1 byte | 0 0 | 62 | 5 bytes | | ||
| LoRaWAN Header | LoRaWAN payload (11 bytes) | | ||
+ -------------------------- + -------------------------- + | ||
| | RuleID=20 | W | FCN | 1 tile | | ||
+ -------------- + --------- + ----- + ------ + --------- + | ||
| XXXX | 1 byte | 0 0 | 62 | 10 bytes | | ||
|
||
|
||
Content of the tile is: | ||
| RuleID | Compression residue | Payload | | ||
+ ------ + ------------------- + ----------------- + | ||
| 1 | 21 bits | 1 byte + 3 bits | | ||
| 1 | 21 bits | 6 byte + 3 bits | | ||
|
||
|
||
Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by | ||
LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte FPort | ||
field, a tile does not fit inside so LoRaWAN stack will send only FOpts. | ||
|
||
Next transmission MTU is 242 bytes, no FOpts. 48 tiles are transmitted: | ||
Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are transmitted: | ||
|
||
| LoRaWAN Header | LoRaWAN payload (241 bytes) | | ||
+ -------------- + -----------+ --------------------------- + | ||
| | RuleID=20 | W | FCN | 48 tiles | | ||
+ -------------- + ---------- + ----- + ------ + ---------- + | ||
| XXXX | 1 byte | 0 0 | 61 | 240 bytes | | ||
| LoRaWAN Header | LoRaWAN payload (231 bytes) | | ||
+ --------------------------------------+ --------------------------- + | ||
| | FOpts | RuleID=20 | W | FCN | 23 tiles | | ||
+ -------------- + ------- + ---------- + ----- + ----- + ----------- + | ||
| XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | | ||
|
||
|
||
Next transmission MTU is 242 bytes, no FOpts. All 8 remaining tiles are | ||
Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles are | ||
transmitted, the last tile is only 2 bytes + 5 bits. Padding is added for | ||
the remaining 3 bits. | ||
|
||
| LoRaWAN Header | LoRaWAN payload (39 bytes) | | ||
| LoRaWAN Header | LoRaWAN payload (44 bytes) | | ||
+ ---- + -----------+ ----------------------------------------------- + | ||
| | RuleID=20 | W | FCN | 8 tiles | Padding=b'000 | | ||
+ ---- + ---------- + -- + ------ + ----------------- + ------------- + | ||
| XXXX | 1 byte | 00 | 13 | 37 bytes + 5 bits | 3 bits | | ||
| | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | | ||
+ ---- + ---------- + ----- + ----- + ----------------- + ------------- + | ||
| XXXX | 1 byte | 0 0 | 38 | 42 bytes + 5 bits | 3 bits | | ||
|
||
|
||
All packets have been received by the SCHC gateway, computed RCS is | ||
|