From f13e3199a9f9cd0f943ae550eb217d761ecaab07 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Wed, 30 Oct 2019 19:03:45 +0100 Subject: [PATCH 1/8] Add first draft multicast --- draft-ietf-lpwan-schc-over-lorawan.md | 50 ++++++++++++++++++++++++--- 1 file changed, 45 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 30394b5..a9e1c64 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -53,6 +53,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 @@ -351,14 +358,13 @@ 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) +* RuleID = 23 (8-bit) for multicast downlink fragementation The remaining RuleIDs are available for compression. RuleIDs are shared between uplink and downlink sessions. A RuleID different from FPortUp or FPortDown @@ -695,6 +701,40 @@ inactivity timer is implemented by the end-device to flush the context in-case i receives nothing from the SCHC gateway over an extended period of time. The RECOMMENDED value is 12 hours for both Class B and Class C end-devices. +## Multicast + +LoRaWAN technology supports multicast for downlink communications: a packet +send over LoRaWAN radio link can be received by several devices. It can be +usefull, for example, in case of large binary transfer like firmware upgrade +over the air. +As IPv6 is also a multicast technology this feature MAY be used to address a +group of devices. For those multicasts communications the SCHC No-ACK mode is +used, it the respnsability to the upper layer to ensure data integrity, if +required. + +This feature is optionnal and MAY not be implemented by SCHC gateways. + +Profile parameters are: + +- RuleID: RECOMMENDED value is 23 (8-bit rule size). +- DTag: Size is 0 bit, not used. +- 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}}. +- Inactivity timer: The default RECOMMENDED duration is 12 hours. This value is + mainly driven by application requirements and MAY be changed by the + application. +- FCN: The FCN field is encoded on N = 1 bits, as recommended in + {{I-D.ietf-lpwan-ipv6-static-context-hc}}. + +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: LoRa Alliance defined {{lora-alliance-remote-multicast-set}} as +RECOMMENDED way to setup multicast groups on devices and create a synchronized +reception window. + # Security considerations This document is only providing parameters that are expected to be better From ec38bc018ba64da7b6e52881a463e001b57c8d52 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 4 Nov 2019 18:18:23 +0100 Subject: [PATCH 2/8] Update multicast proposition after Julien and N. Sornin review --- draft-ietf-lpwan-schc-over-lorawan.md | 64 +++++++++++---------------- 1 file changed, 25 insertions(+), 39 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index a9e1c64..59462c6 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -314,6 +314,15 @@ confirmed messages. settings and a network random nonce used to derive the session keys. * Data +## Unicast and multicast technology + +LoRaWAN technology supports unicast for uplink and downlink communications, but +also multicast for downlink data: a packet send over LoRaWAN radio link can be +received by several devices. It can be useful, for example, in case of large +binary transfer like firmware upgrade over the air. +As IPv6 is also a multicast technology this feature MAY be used to address a +group of devices. + # SCHC-over-LoRaWAN ## LoRaWAN FPort {#lorawan-schc-payload} @@ -364,7 +373,6 @@ In order to improve interoperability RECOMMENDED fragmentation RuleID values are * RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown * RuleID = 22 (8-bit) for which SCHC compression was not possible (no matching rule was found) -* RuleID = 23 (8-bit) for multicast downlink fragementation The remaining RuleIDs are available for compression. RuleIDs are shared between uplink and downlink sessions. A RuleID different from FPortUp or FPortDown @@ -542,9 +550,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. +* 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: 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}}. +* 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). @@ -554,12 +565,21 @@ fragment as described in {{lorawan-schc-payload}}. * MAX_ACK_REQUESTS: 8 As only 1 tile is used, its size can change for each downlink, and will be -maximum available MTU. +maximum available MTU for unicast. For multicast, it has to be the minimum MTU +of all devices, RECOMMENDED value is 51. -_Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for +_Note 1_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for SCHC-over-LoRaWAN protocol. It might be set by the Network Server for other purposes but not SCHC needs. +_Note 2_: 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 3_: LoRa Alliance defined {{lora-alliance-remote-multicast-set}} as +RECOMMENDED way to setup multicast groups on devices and create a synchronized +reception window. + #### Regular fragments ~~~~ @@ -701,40 +721,6 @@ inactivity timer is implemented by the end-device to flush the context in-case i receives nothing from the SCHC gateway over an extended period of time. The RECOMMENDED value is 12 hours for both Class B and Class C end-devices. -## Multicast - -LoRaWAN technology supports multicast for downlink communications: a packet -send over LoRaWAN radio link can be received by several devices. It can be -usefull, for example, in case of large binary transfer like firmware upgrade -over the air. -As IPv6 is also a multicast technology this feature MAY be used to address a -group of devices. For those multicasts communications the SCHC No-ACK mode is -used, it the respnsability to the upper layer to ensure data integrity, if -required. - -This feature is optionnal and MAY not be implemented by SCHC gateways. - -Profile parameters are: - -- RuleID: RECOMMENDED value is 23 (8-bit rule size). -- DTag: Size is 0 bit, not used. -- 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}}. -- Inactivity timer: The default RECOMMENDED duration is 12 hours. This value is - mainly driven by application requirements and MAY be changed by the - application. -- FCN: The FCN field is encoded on N = 1 bits, as recommended in - {{I-D.ietf-lpwan-ipv6-static-context-hc}}. - -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: LoRa Alliance defined {{lora-alliance-remote-multicast-set}} as -RECOMMENDED way to setup multicast groups on devices and create a synchronized -reception window. - # Security considerations This document is only providing parameters that are expected to be better From dcac177fa1841bd7ac2b23539b8e656ed7debe77 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 4 Nov 2019 15:23:42 +0100 Subject: [PATCH 3/8] Fix ruleId size: 8 bits --- draft-ietf-lpwan-schc-over-lorawan.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 30394b5..2678ead 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -312,7 +312,7 @@ confirmed messages. ## 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,8 +343,7 @@ 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 @@ -394,8 +393,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} @@ -427,7 +425,7 @@ 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. +* 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 @@ -537,7 +535,7 @@ 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. +* RuleID: 8 bits stored in LoRaWAN FPort. * Window index: 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 From ed911b6748964bf8859678ce9ca4f111145b4c7e Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 4 Nov 2019 15:49:41 +0100 Subject: [PATCH 4/8] Switch to 10 bytes tiles to respect IPv6 1280 bytes MTU --- draft-ietf-lpwan-schc-over-lorawan.md | 58 ++++++++++++++++----------- 1 file changed, 34 insertions(+), 24 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 2678ead..15033c9 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -428,14 +428,14 @@ fragment as per {{lorawan-schc-payload}}. * 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) @@ -453,7 +453,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 @@ -799,42 +799,52 @@ 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) | ++ ------------------------------------- + -------------------------- + +| | FOpts | RuleID=20 | W | FCN | 1 tile | ++ -------------- + ------- + ---------- + ----- + ------ + --------- + +| XXXX | 2 bytes | 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. +| LoRaWAN Header | ++ ------------------------------------- + +| | FOpts | FPort=20 | ++ -------------- + ------- + ---------- + +| XXXX | 2 bytes | 1 byte | -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 From 058bdd8f446d1439b71df7567ff4181f93348b5e Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 4 Nov 2019 15:54:20 +0100 Subject: [PATCH 5/8] Move J. Catalano from author to contributor --- draft-ietf-lpwan-schc-over-lorawan.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 15033c9..931d9f8 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -29,13 +29,6 @@ author: country: France email: ivaylo@ackl.io role: editor -- ins: J. Catalano - name: Julien Catalano - org: Kerlink - street: 1 rue Jacqueline Auriol - city: 35235 Thorigné-Fouillard - country: France - email: j.catalano@kerlink.fr normative: RFC2119: RFC8174: @@ -718,6 +711,13 @@ Contributors ordered by family name. city: 91120 PALAISEAU country: FRANCE email: vincent.audebert@edf.fr +- ins: J. Catalano + name: Julien Catalano + org: Kerlink + street: 1 rue Jacqueline Auriol + city: 35235 Thorigné-Fouillard + country: France + email: j.catalano@kerlink.fr - ins: M. Coracin name: Michael Coracin org: Semtech From 2182be1ef0f61610e8b8e979c716a4ae9a2bb916 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 4 Nov 2019 22:18:17 +0100 Subject: [PATCH 6/8] Update multicast with Julien comments --- draft-ietf-lpwan-schc-over-lorawan.md | 31 +++++++++++++-------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 59462c6..8d0f449 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -316,13 +316,21 @@ confirmed messages. ## Unicast and multicast technology -LoRaWAN technology supports unicast for uplink and downlink communications, but -also multicast for downlink data: a packet send over LoRaWAN radio link can be -received by several devices. It can be useful, for example, in case of large -binary transfer like firmware upgrade over the air. +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} @@ -553,7 +561,7 @@ fragment as described in {{lorawan-schc-payload}}. * 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. + layer. This feature is OPTIONAL and may not be implemented by SCHC gateway. * RuleID: Recommended size is 8 bits in SCHC header. * 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 @@ -565,21 +573,12 @@ fragment as described in {{lorawan-schc-payload}}. * MAX_ACK_REQUESTS: 8 As only 1 tile is used, its size can change for each downlink, and will be -maximum available MTU for unicast. For multicast, it has to be the minimum MTU -of all devices, RECOMMENDED value is 51. +maximum available MTU. -_Note 1_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for +_Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for SCHC-over-LoRaWAN protocol. It might be set by the Network Server for other purposes but not SCHC needs. -_Note 2_: 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 3_: LoRa Alliance defined {{lora-alliance-remote-multicast-set}} as -RECOMMENDED way to setup multicast groups on devices and create a synchronized -reception window. - #### Regular fragments ~~~~ From 275a6a668ea678db4a56d7cc7145a2e2a7e88138 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 4 Nov 2019 22:25:58 +0100 Subject: [PATCH 7/8] Update examples after Julien review --- draft-ietf-lpwan-schc-over-lorawan.md | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 931d9f8..b4d988c 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -804,11 +804,11 @@ 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 (11 bytes) | -+ ------------------------------------- + -------------------------- + -| | FOpts | RuleID=20 | W | FCN | 1 tile | -+ -------------- + ------- + ---------- + ----- + ------ + --------- + -| XXXX | 2 bytes | 1 byte | 0 0 | 62 | 10 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: @@ -821,12 +821,6 @@ 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. -| LoRaWAN Header | -+ ------------------------------------- + -| | FOpts | FPort=20 | -+ -------------- + ------- + ---------- + -| XXXX | 2 bytes | 1 byte | - Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are transmitted: | LoRaWAN Header | LoRaWAN payload (231 bytes) | From 3b62257a37001413a24342e8f2991ac13fe58971 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 4 Nov 2019 22:51:53 +0100 Subject: [PATCH 8/8] Fix fixed header size --- draft-ietf-lpwan-schc-over-lorawan.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1d86543..0887548 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -438,8 +438,7 @@ 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. +* 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