From 00414d36535f10c35e6a51e726838af2851a0525 Mon Sep 17 00:00:00 2001 From: dbarthel-ol Date: Thu, 7 May 2020 12:24:09 +0200 Subject: [PATCH 01/42] a few more nit fixes --- draft-ietf-lpwan-schc-over-lorawan.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index e93aef5..57c28e9 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -120,8 +120,8 @@ This section contains a short overview of Static Context Header Compression It defines: -1. Compression mechanisms to avoid transport of known data by both - sender and receiver over the air. Known data are part of the "context" +1. Compression mechanisms to avoid transporting information known by both + sender and receiver over the air. Known information are part of the "context" 2. Fragmentation mechanisms to allow SCHC Packet transportation on small, and potentially variable, MTU @@ -150,8 +150,8 @@ using IPv6 or IPv6/UDP protocols. These flows might be compressed by an Static Context Header Compression Compressor/Decompressor (SCHC C/D) to reduce headers size and fragmented (SCHC F/R). The resulting information is sent on a layer two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the frame to a Network -Gateway (NGW). The NGW sends the data to a SCHC F/R for defragmentation, if -required, then C/D for decompression which shares the same rules with the +Gateway (NGW). The NGW sends the data to a SCHC F/R for reassembly, if +required, then to C/D for decompression, which shares the same rules with the device. The SCHC F/R and C/D can be located on the Network Gateway (NGW) or in another place as long as a tunnel is established between the NGW and the SCHC F/R, then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share the same @@ -493,7 +493,7 @@ Packet, as per {{lorawan-schc-payload}}. driven by application requirements and MAY be changed by the application. * Penultimate tile MUST be equal to the regular size. * Last tile: it can be carried in a Regular SCHC Fragment, alone in an All-1 SCHC - Fragment or with any of these two methods: implementation must ensure that: + Fragment or with any of these two methods. Implementation must ensure that: * The sender MUST ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment. * If last tile is in All-1 message: current L2 MTU MUST be big enough to fit @@ -753,13 +753,13 @@ RECOMMENDED value is 12 hours for both Class B and Class C end-devices. # Security considerations -This document is only providing parameters that are expected to be better +This document is only providing parameters that are expected to be best suited for LoRaWAN networks for [RFC8724]. IID security is discussed in {{IID}}. As such, this document does not contribute to any new security issues in addition to those identified in [RFC8724]. -Moreover SCHC data (LoRaWAN payload) are protected on LoRaWAN level by an AES-128 -encryption with key shared by device and SCHC gateway. Those keys are renew each +Moreover, SCHC data (LoRaWAN payload) are protected on LoRaWAN level by an AES-128 +encryption with key shared by device and SCHC gateway. Those keys are renewed at each LoRaWAN session (ie: each join or rejoin to the network) # Acknowledgements @@ -999,7 +999,7 @@ The last downlink is sent, no FOpts: + ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- + | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes + 1 bits | 5 bits | ~~~~ -{: #Fig-example-downlink-fragmentation-lorawan-packet-5 title='Uplink example: LoRaWAN packet 5 - All-1 message'} +{: #Fig-example-downlink-fragmentation-lorawan-packet-5 title='Downlink example: LoRaWAN packet 5 - All-1 message'} The receiver answers to the sender with an SCHC ACK: @@ -1010,5 +1010,5 @@ The receiver answers to the sender with an SCHC ACK: + ---- + --------- + ----- + ----- + ---------------- + | XXXX | 1 byte | 1 bit | 1 bit | 6 bits | ~~~~ -{: #Fig-example-downlink-fragmentation-lorawan-packet-6 title='Uplink example: LoRaWAN packet 6 - SCHC ACK'} +{: #Fig-example-downlink-fragmentation-lorawan-packet-6 title='Downlink example: LoRaWAN packet 6 - SCHC ACK'} From 20832d764bc83bd47918fe6fa633b13eb0586d5e Mon Sep 17 00:00:00 2001 From: Ivaylo Petrov Date: Thu, 7 May 2020 17:02:05 +0200 Subject: [PATCH 02/42] Fix a new minor nits --- draft-ietf-lpwan-schc-over-lorawan.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index e93aef5..99e9f04 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -78,9 +78,9 @@ LPWAN (Low Power Wide Area Networks) technologies defined in {{RFC8376}}. Even though those technologies share a great number of common features like star-oriented topologies, network architecture, devices with mostly quite predictable communications, etc; they do have some -slight differences in respect of payload sizes, reactiveness, etc. +slight differences in respect to payload sizes, reactiveness, etc. -SCHC gives a generic framework that enables those devices to communicate with +SCHC provides a generic framework that enables those devices to communicate with other Internet networks. However, for efficient performance, some parameters and modes of operation need to be set appropriately for each of the LPWAN technologies. @@ -108,8 +108,6 @@ all other definitions, please look up the SCHC specification o RCS: Reassembly Check Sequence. Used to verify the integrity of the fragmentation-reassembly process - o TBD: all significant LoRaWAN-related terms. - o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI # Static Context Header Compression Overview @@ -120,8 +118,8 @@ This section contains a short overview of Static Context Header Compression It defines: -1. Compression mechanisms to avoid transport of known data by both - sender and receiver over the air. Known data are part of the "context" +1. Compression mechanisms to avoid transport over the air of known data by both + sender and receiver. Known data is part of the "context". 2. Fragmentation mechanisms to allow SCHC Packet transportation on small, and potentially variable, MTU @@ -146,12 +144,12 @@ Context exchange or pre-provisioning is out of scope of this document. {{Fig-archi}} represents the architecture for compression/decompression, it is based on {{RFC8376}} terminology. The Device is sending applications flows -using IPv6 or IPv6/UDP protocols. These flows might be compressed by an Static +using IPv6 or IPv6/UDP protocols. These flows might be compressed by a Static Context Header Compression Compressor/Decompressor (SCHC C/D) to reduce headers size and fragmented (SCHC F/R). The resulting information is sent on a layer two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the frame to a Network Gateway (NGW). The NGW sends the data to a SCHC F/R for defragmentation, if -required, then C/D for decompression which shares the same rules with the +required, then to C/D for decompression. The C/D shares the same rules with the device. The SCHC F/R and C/D can be located on the Network Gateway (NGW) or in another place as long as a tunnel is established between the NGW and the SCHC F/R, then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share the same @@ -357,7 +355,7 @@ server to device, is called downlink fragmentation session. It uses another FPort for data downlink and its associated SCHC control uplinks, named FPortDown in this document. -All ruleId can use arbitrary values inside the FPort range allowed by LoRaWAN +All ruleID can use arbitrary values inside the FPort range allowed by LoRaWAN specification and MUST be shared by the end-device and SCHC gateway prior to the communication with the selected rule. The uplink and downlink fragmentation FPorts MUST be different. From 885d4c9d43f8dd791f617ceb2585ba175cbab77d Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 14 May 2020 14:30:54 +0200 Subject: [PATCH 03/42] Add All-1 example with last tile --- draft-ietf-lpwan-schc-over-lorawan.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 57c28e9..236203e 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -545,7 +545,18 @@ a part of the rule context. | 8 bits | 2 bits | 6 bits | 32 bits | ~~~~ -{: #Fig-fragmentation-header-all1 title='All-1 fragment detailed format for the last fragment.'} +{: #Fig-fragmentation-header-all1-no-tile title='All-1 SCHC Message: the last fragment without last tile.'} + +~~~~ + +| FPort | LoRaWAN payload | ++ ------ + ------------------------------------------- + +| RuleID | W | FCN=All-1 | RCS | Last tile | ++ ------ + ------ + --------- + ------- + ------------ + +| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | + +~~~~ +{: #Fig-fragmentation-header-all1-last-tile title='All-1 SCHC Message: the last fragment with last tile.'} #### SCHC ACK From cc72a08c7083a0a323f5f69463201a0d43ae92ac Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 14 May 2020 18:00:12 +0200 Subject: [PATCH 04/42] Fixed IID example (linked to wrong formating input) --- draft-ietf-lpwan-schc-over-lorawan.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 236203e..908aaf9 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -424,8 +424,8 @@ Example with: ~~~~ 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB -2. cmac: 0x4E822D9775B2649928F82066AF804FEC -3. IID: 0x28F82066AF804FEC +2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A +3. IID: 0xBA59F4B196C6C343 ~~~~ {: #Fig-iid-computation-example title='Example of IID computation.'} From 9e300f780c92bc1b27a89922c721513a1cd278d6 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 14 May 2020 18:17:12 +0200 Subject: [PATCH 05/42] Use term from RFC8376 for end device --- draft-ietf-lpwan-schc-over-lorawan.md | 106 +++++++++++++------------- 1 file changed, 53 insertions(+), 53 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 908aaf9..ff326ab 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -99,10 +99,10 @@ This section defines the terminology and acronyms used in this document. For all other definitions, please look up the SCHC specification [RFC8724]. - o DevEUI: an IEEE EUI-64 identifier used to identify the end-device during the + o DevEUI: an IEEE EUI-64 identifier used to identify the device during the procedure while joining the network (Join Procedure) - o DevAddr: a 32-bit non-unique identifier assigned to an end-device statically or + o DevAddr: a 32-bit non-unique identifier assigned to an device statically or dynamically after a Join Procedure (depending on the activation mode) o RCS: Reassembly Check Sequence. Used to verify the integrity of the @@ -128,7 +128,7 @@ It defines: Context exchange or pre-provisioning is out of scope of this document. ~~~~ - Dev App + Device App +----------------+ +----+ +----+ +----+ | App1 App2 App3 | |App1| |App2| |App3| | | | | | | | | @@ -145,7 +145,7 @@ Context exchange or pre-provisioning is out of scope of this document. {: #Fig-archi title='Architecture'} {{Fig-archi}} represents the architecture for compression/decompression, it is -based on {{RFC8376}} terminology. The Device is sending applications flows +based on {{RFC8376}} terminology. The device is sending applications flows using IPv6 or IPv6/UDP protocols. These flows might be compressed by an Static Context Header Compression Compressor/Decompressor (SCHC C/D) to reduce headers size and fragmented (SCHC F/R). The resulting information is sent on a layer two @@ -167,7 +167,7 @@ Server or any third party software. {{Fig-archi}} can be mapped in LoRaWAN terminology to: ~~~~ - Dev App + End Device App +--------------+ +----+ +----+ +----+ |App1 App2 App3| |App1| |App2| |App3| | | | | | | | | @@ -192,9 +192,9 @@ described in {{RFC8376}}. The mapping between the LPWAN architecture entities as described in [RFC8724] and the ones in {{lora-alliance-spec}} is as follows: - o Devices (Dev) are the end-devices or hosts (e.g. sensors, + o Devices are LoRaWAN End Devices (e.g. sensors, actuators, etc.). There can be a very high density of devices per - radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN End-Device. + radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN device. o The Radio Gateway (RGW), which is the endpoint of the constrained link. This entity maps to the LoRaWAN Gateway. @@ -215,60 +215,60 @@ and the ones in {{lora-alliance-spec}} is as follows: () () () | | <--|--> | +------+ |Application| () () () () / \==========| v |=============| Server | () () () / \ +---------+ +-----------+ - End-Devices Gateways Network Server + End Devices Gateways Network Server ~~~~ {: #Fig-LPWANarchi title='LPWAN Architecture'} SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/Reassembly) - are performed on the LoRaWAN End-Device and the Application Server (called - SCHC gateway). While the point-to-point link between the End-Device and the + are performed on the LoRaWAN device and the Application Server (called + SCHC gateway). While the point-to-point link between the device and the Application Server constitutes single IP hop, the ultimate end-point of the IP communication may be an Internet node beyond the Application Server. In other words, the LoRaWAN Application Server (SCHC gateway) acts as the - first hop IP router for the End-Device. The Application Server and Network + first hop IP router for the device. The Application Server and Network Server may be co-located, which effectively turns the Network/Application Server into the first hop IP router. -## End-Device classes (A, B, C) and interactions +## Device classes (A, B, C) and interactions -The LoRaWAN MAC layer supports 3 classes of end-devices named A, B and C. All -end-devices implement the Class A, some end-devices may implement Class B or +The LoRaWAN MAC layer supports 3 classes of devices named A, B and C. All +devices implement the Class A, some devices may implement Class B or Class C. Class B and Class C are mutually exclusive. -* Class A: The Class A is the simplest class of end-devices. The end-device is +* Class A: The Class A is the simplest class of devices. The device is allowed to transmit at any time, randomly selecting a communication channel. The network may reply with a downlink in one of the 2 receive windows immediately following the uplinks. Therefore, the network cannot initiate a - downlink, it has to wait for the next uplink from the end-device to get a - downlink opportunity. The Class A is the lowest power end-device class. -* Class B: Class B end-devices implement all the functionalities of Class A - end-devices, but also schedule periodic listen windows. Therefore, opposed to the - Class A end-devices, Class B end-devices can receive downlinks that are initiated by the + downlink, it has to wait for the next uplink from the device to get a + downlink opportunity. The Class A is the lowest power device class. +* Class B: Class B devices implement all the functionalities of Class A + devices, but also schedule periodic listen windows. Therefore, opposed to the + Class A devices, Class B devices can receive downlinks that are initiated by the network and not following an uplink. There is a trade-off between the periodicity of those scheduled Class B listen windows and the power - consumption of the end-device. The lower the downlink latency, the higher the + consumption of the device. The lower the downlink latency, the higher the power consumption. -* Class C: Class C end-devices implement all the functionalities of Class A - end-devices, but keep their receiver open whenever they are not transmitting. - Class C end-devices can receive downlinks at any time at the expense of a higher - power consumption. Battery-powered end-devices can only operate in Class C for a +* Class C: Class C devices implement all the functionalities of Class A + devices, but keep their receiver open whenever they are not transmitting. + Class C devices can receive downlinks at any time at the expense of a higher + power consumption. Battery-powered devices can only operate in Class C for a limited amount of time (for example for a firmware upgrade over-the-air). - Most of the Class C end-devices are grid powered (for example Smart Plugs). + Most of the Class C devices are grid powered (for example Smart Plugs). -## End-Device addressing +## Device addressing -LoRaWAN end-devices use a 32-bit network address (devAddr) to communicate with +LoRaWAN devices use a 32-bit network address (devAddr) to communicate with the network over-the-air, this address might not be unique in a LoRaWAN -network; end-devices using the same devAddr are distinguished by the Network +network; devices using the same devAddr are distinguished by the Network Server based on the cryptographic signature appended to every LoRaWAN frame. To communicate with the SCHC gateway the Network Server MUST identify the -end-devices by a unique 64-bit device identifier called the devEUI. +devices by a unique 64-bit device identifier called the devEUI. -The devEUI is assigned to the end-device during the manufacturing process by the -end-device's manufacturer. It is built like an Ethernet MAC address by +The devEUI is assigned to the device during the manufacturing process by the +device's manufacturer. It is built like an Ethernet MAC address by concatenating the manufacturer's IEEE OUI field with a vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit serial number. The Network Server translates the devAddr into a devEUI in the uplink @@ -277,8 +277,8 @@ direction and reciprocally on the downlink direction. ~~~~ +--------+ +----------+ +---------+ +----------+ -| End- | <=====> | Network | <====> | SCHC | <========> | Internet | -| Device | devAddr | Server | devEUI | Gateway | IPv6/UDP | | +| Device | <=====> | Network | <====> | SCHC | <========> | Internet | +| | devAddr | Server | devEUI | Gateway | IPv6/UDP | | +--------+ +----------+ +---------+ +----------+ ~~~~ @@ -297,13 +297,13 @@ confirmed messages. ## LoRaWAN MAC Frames * JoinRequest: - This message is used by an end-device to join a network. It contains the end-device's + This message is used by an device to join a network. It contains the device's unique identifier devEUI and a random nonce that will be used for session key derivation. * JoinAccept: - To on-board an end-device, the Network Server responds to the JoinRequest - issued by an end-device with a JoinAccept message. That message is - encrypted with the end-device's AppKey and contains (amongst other fields) + To on-board an device, the Network Server responds to the JoinRequest + issued by an device with a JoinAccept message. That message is + encrypted with the device's AppKey and contains (amongst other fields) the major network's settings and a network random nonce used to derive the session keys. * Data: @@ -314,7 +314,7 @@ confirmed messages. 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 +useful to address many 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 can be used to address a group of devices. @@ -358,7 +358,7 @@ FPort for data downlink and its associated SCHC control uplinks, named FPortDown in this document. All ruleId can use arbitrary values inside the FPort range allowed by LoRaWAN -specification and MUST be shared by the end-device and SCHC gateway prior to +specification and MUST be shared by the device and SCHC gateway prior to the communication with the selected rule. The uplink and downlink fragmentation FPorts MUST be different. @@ -451,7 +451,7 @@ RuleIDs matching FPortUp and FPortDown are reserved for SCHC Fragmentation. The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink fragmentation and Ack-Always mode for downlink fragmentation. A LoRaWAN -end-device cannot support simultaneous interleaved fragmentation sessions in +device cannot support simultaneous interleaved fragmentation sessions in the same direction (uplink or downlink). The fragmentation parameters are different for uplink and downlink @@ -482,7 +482,7 @@ Packet, as per {{lorawan-schc-payload}}. * RCS: Use recommended calculation algorithm in [RFC8724]. * MAX_ACK_REQUESTS: 8 * Tile: size is 10 bytes -* Retransmission timer: LoRaWAN end-devices MUST NOT implement a +* Retransmission timer: LoRaWAN devices MUST NOT implement a "retransmission timer", this changes the specification of [RFC8724], see {{uplink-class-a}}. It must transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own timing; ie the @@ -686,15 +686,15 @@ purposes but not SCHC needs. {: #Fig-fragmentation-downlink-header-abort title='Receiver-Abort packet (following an All-1 SCHC Fragment with incorrect RCS).'} -Class A and Class B or Class C end-devices do not manage retransmissions and +Class A and Class B or Class C devices do not manage retransmissions and timers in the same way. -#### Class A end-devices {#uplink-class-a} +#### Class A devices {#uplink-class-a} -Class A end-devices can only receive in an RX slot following the transmission of an +Class A devices can only receive in an RX slot following the transmission of an uplink. Therefore there cannot be a concept of "retransmission timer" for an SCHC gateway. The SCHC gateway cannot initiate communication to a Class A -end-device. +device. The device replies with an ACK message to every single fragment received from the SCHC gateway (because the window size is 1). Following the reception of a @@ -723,9 +723,9 @@ fragmentation context. For devices with very low transmission rates but this is application specific. -#### Class B or Class C end-devices +#### Class B or Class C devices -Class B and Class C end-devices can receive in scheduled RX slots or in RX +Class B and Class C devices can receive in scheduled RX slots or in RX slots following the transmission of an uplink. The device replies with an ACK message to every single fragment received from the SCHC gateway (because the window size is 1). Following the reception of an FCN=0 fragment (fragment that @@ -753,14 +753,14 @@ datagram), if all fragments have been received and if the RCS is NOT correct, the device SHALL transmit a Receiver-Abort fragment. The retransmission timer is used by the SCHC gateway (the sender), the optimal value is very much application specific but here are some recommended default values. -For Class B end-devices, this timer trigger is a function of the periodicity of the +For Class B devices, this timer trigger is a function of the periodicity of the Class B ping slots. The RECOMMENDED value is equal to 3 times the Class B ping -slot periodicity. For Class C end-devices which are nearly constantly receiving, -the RECOMMENDED value is 30 seconds. This means that the end-device shall try to +slot periodicity. For Class C devices which are nearly constantly receiving, +the RECOMMENDED value is 30 seconds. This means that the device shall try to transmit the ACK within 30 seconds of the reception of each fragment. The -inactivity timer is implemented by the end-device to flush the context in case +inactivity timer is implemented by the device to flush the context in case it 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. +RECOMMENDED value is 12 hours for both Class B and Class C devices. # Security considerations From 0bb8dbd133b7717a4066b952c1026c9a49415ea7 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 14 May 2020 18:41:00 +0200 Subject: [PATCH 06/42] Use term from RFC8376 for NGW/App --- draft-ietf-lpwan-schc-over-lorawan.md | 35 +++++++++++++-------------- 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index ff326ab..ebaac4e 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -162,9 +162,9 @@ The SCHC F/R and SCHC C/D process is bidirectional, so the same principles can be applied in the other direction. In a LoRaWAN network, the RG is called a Gateway, the NGW is Network Server, -and the SCHC C/D is an Application Server. It can be provided by the Network -Server or any third party software. {{Fig-archi}} can be mapped in LoRaWAN -terminology to: +and the SCHC C/D and SCHC F/R are an Application Server. It can be provided by +the Network Gateway or any third party software. {{Fig-archi}} can be mapped in +LoRaWAN terminology to: ~~~~ End Device App @@ -203,9 +203,8 @@ and the ones in {{lora-alliance-spec}} is as follows: Radio Gateway and the Internet. This entity maps to the LoRaWAN Network Server. - o Application Server (App). The same terminology is used in LoRaWAN. - In that case, the application server will be the SCHC gateway, doing - C/D and F/R. + o SCHC F/R and SCHC C/D are LoRaWAN Application Server; ie the LoRaWAN + application server will do the C/D and F/R. ~~~~ @@ -262,24 +261,24 @@ Class C. Class B and Class C are mutually exclusive. LoRaWAN devices use a 32-bit network address (devAddr) to communicate with the network over-the-air, this address might not be unique in a LoRaWAN network; devices using the same devAddr are distinguished by the Network -Server based on the cryptographic signature appended to every LoRaWAN frame. +Gateway based on the cryptographic signature appended to every LoRaWAN frame. -To communicate with the SCHC gateway the Network Server MUST identify the +To communicate with the SCHC gateway the Network Gateway MUST identify the devices by a unique 64-bit device identifier called the devEUI. The devEUI is assigned to the device during the manufacturing process by the device's manufacturer. It is built like an Ethernet MAC address by concatenating the manufacturer's IEEE OUI field with a vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit serial number. -The Network Server translates the devAddr into a devEUI in the uplink +The Network Gateway translates the devAddr into a devEUI in the uplink direction and reciprocally on the downlink direction. ~~~~ -+--------+ +----------+ +---------+ +----------+ -| Device | <=====> | Network | <====> | SCHC | <========> | Internet | -| | devAddr | Server | devEUI | Gateway | IPv6/UDP | | -+--------+ +----------+ +---------+ +----------+ ++--------+ +---------+ +---------+ +----------+ +| Device | <=====> | Network | <====> | SCHC | <========> | Internet | +| | devAddr | Gateway | devEUI | Gateway | IPv6/UDP | | ++--------+ +---------+ +---------+ +----------+ ~~~~ {: #Fig-LoRaWANaddresses title='LoRaWAN addresses'} @@ -301,7 +300,7 @@ confirmed messages. unique identifier devEUI and a random nonce that will be used for session key derivation. * JoinAccept: - To on-board an device, the Network Server responds to the JoinRequest + To on-board an device, the Network Gateway responds to the JoinRequest issued by an device with a JoinAccept message. That message is encrypted with the device's AppKey and contains (amongst other fields) the major network's settings and a network random nonce used to derive the @@ -320,7 +319,7 @@ As IPv6 is also a multicast technology this feature can 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 +multicast group definition in a Network Gateway 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 @@ -350,10 +349,10 @@ as a part of the RuleID field. {: #Fig-lorawan-schc-payload title='SCHC Message in LoRaWAN'} A fragmentation session with application payload transferred from device to -server, is called uplink fragmentation session. It uses an FPort for data uplink +Network Gateway, is called uplink fragmentation session. It uses an FPort for data uplink and its associated SCHC control downlinks, named FPortUp in this document. The other way, a fragmentation session with application payload transferred from -server to device, is called downlink fragmentation session. It uses another +Network Gateway to device, is called downlink fragmentation session. It uses another FPort for data downlink and its associated SCHC control uplinks, named FPortDown in this document. @@ -626,7 +625,7 @@ As only 1 tile is used, its size can change for each downlink, and will be maximum available MTU. _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 +SCHC-over-LoRaWAN protocol. It might be set by the Network Gateway for other purposes but not SCHC needs. #### Regular fragments From f915cc2b2ea3ecb0029928f5b514369401cb8974 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 15 May 2020 15:23:20 +0200 Subject: [PATCH 07/42] Clarified that the SCHC sender is a device in uplink chapter --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index ebaac4e..eb12e9b 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -502,7 +502,7 @@ 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 * 63 tiles * 10 bytes per tile = 2520 bytes_ -For battery powered SCHC sender, it is RECOMMENDED to use ACK mechanism at the +For battery powered devices, it is RECOMMENDED to use ACK mechanism at the end of each window instead of waiting the end of all windows: * SCHC receiver SHOULD send a SCHC ACK after every window even if there is no From 04e976c580cdb07d22262b4941c513c8c8c9171a Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 15 May 2020 15:27:24 +0200 Subject: [PATCH 08/42] List all bitmap possibilities in SCHC ACK example --- draft-ietf-lpwan-schc-over-lorawan.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index eb12e9b..ed18e61 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -561,16 +561,20 @@ a part of the rule context. ~~~~ -| FPort | LoRaWAN payload | -+ ------ + ----------------------------------------- + -| RuleID | W | C | Encoded bitmap (if C = 0) | -+ ------ + ----- + ----- + ------------------------- + -| 8 bits | 2 bit | 1 bit | 0 to 63 bits | +| FPort | LoRaWAN payload | ++ ------ + ------------------------------------------------------------------------- + +| RuleID | W | C | Compressed bitmap (if C = 0) | Optional padding (b'0...0) | ++ ------ + ----- + ----- + ---------------------------- + -------------------------- + +| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits | ~~~~ {: #Fig-fragmentation-header-long-schc-ack title='SCHC ACK format, failed RCS check.'} +Note: Because of the bitmap compression mechanism and L2 byte alignment only +few discrete values are possible: 5, 13, 21, 29, 37, 45, 53, 61. Bitmaps of 63 +bits will require 6 bits of padding. + #### Receiver-Abort ~~~~ From a000cf1a71678e98fb995a4103d2f18e55301c47 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 15 May 2020 15:28:20 +0200 Subject: [PATCH 09/42] Fixed SCHC ACK term --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index ed18e61..1771888 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -659,7 +659,7 @@ purposes but not SCHC needs. ~~~~ {: #Fig-fragmentation-downlink-header-all1 title='All-1 SCHC Message: the last fragment.'} -#### SCHC acknowledge +#### SCHC ACK ~~~~ From 04cb13d4da81f811a0f48cfe564f5e661243fa33 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 15 May 2020 15:33:28 +0200 Subject: [PATCH 10/42] Add payload to downlink All-1 --- draft-ietf-lpwan-schc-over-lorawan.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1771888..a4ee3ca 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -650,11 +650,11 @@ purposes but not SCHC needs. ~~~~ -| FPort | LoRaWAN payload | -+ ------ + --------------------------- + -| RuleID | W | FCN = b'1 | RCS | -+ ------ + ----- + --------- + ------- + -| 8 bits | 1 bit | 1 bit | 32 bits | +| FPort | LoRaWAN payload | ++ ------ + --------------------------- + ----------------- + +| RuleID | W | FCN = b'1 | RCS | Payload | ++ ------ + ----- + --------- + ------- + ----------------- + +| 8 bits | 1 bit | 1 bit | 32 bits | 6 bits to X bytes | ~~~~ {: #Fig-fragmentation-downlink-header-all1 title='All-1 SCHC Message: the last fragment.'} From ccb3aea8b36148be3c1ebf156dbdedb92888741f Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 15 May 2020 15:38:07 +0200 Subject: [PATCH 11/42] Fixed typos in uplink/ACK behavior Replaces PR #29 --- draft-ietf-lpwan-schc-over-lorawan.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index a4ee3ca..98708f3 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -502,14 +502,14 @@ 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 * 63 tiles * 10 bytes per tile = 2520 bytes_ -For battery powered devices, it is RECOMMENDED to use ACK mechanism at the -end of each window instead of waiting the end of all windows: +For battery powered devices, it is RECOMMENDED to use the ACK mechanism at the +end of each window instead of waiting until the end of all windows: * SCHC receiver SHOULD send a SCHC ACK after every window even if there is no - missing tiles. + missing tile. * SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver before sending -tiles from next window. If the SCHC ACK is not received, it SHOULD send an SCHC -ACK REQ up to MAX_ACK_REQUESTS time as described previously. +tiles from the next window. If the SCHC ACK is not received, it SHOULD send an SCHC +ACK REQ up to MAX_ACK_REQUESTS, time as described previously. For non-battery powered devices, SCHC receiver MAY also choose to send a SCHC ACK only at the end of all windows. It will reduce downlink load on the network, From d83600a8babcb291b0ddb8989f307e8ab2e9dea2 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 18 May 2020 08:25:16 +0200 Subject: [PATCH 12/42] Update Figure 5 term --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 70a255f..2488433 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -341,7 +341,7 @@ as a part of the RuleID field. | FPort | LoRaWAN payload | + ------------------------ + -| SCHC payload | +| SCHC packet | ~~~~ {: #Fig-lorawan-schc-payload title='SCHC Message in LoRaWAN'} From c21cc3ab8bd890da2e97ffc37eddc9ba204ace16 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 18 May 2020 08:26:23 +0200 Subject: [PATCH 13/42] Fixed RuleID case --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 2488433..17018b5 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -354,7 +354,7 @@ Network Gateway to device, is called downlink fragmentation session. It uses ano FPort for data downlink and its associated SCHC control uplinks, named FPortDown in this document. -All ruleID can use arbitrary values inside the FPort range allowed by LoRaWAN +All RuleID can use arbitrary values inside the FPort range allowed by LoRaWAN specification and MUST be shared by the device and SCHC gateway prior to the communication with the selected rule. The uplink and downlink fragmentation FPorts MUST be different. From a51051e158b1c3763dc980317839d83227f36d94 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 19 May 2020 23:13:27 +0200 Subject: [PATCH 14/42] Change fragmentation session to fragmentation datagram --- draft-ietf-lpwan-schc-over-lorawan.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 17018b5..fc1f224 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -346,11 +346,11 @@ as a part of the RuleID field. ~~~~ {: #Fig-lorawan-schc-payload title='SCHC Message in LoRaWAN'} -A fragmentation session with application payload transferred from device to -Network Gateway, is called uplink fragmentation session. It uses an FPort for data uplink +A fragmentation datagram with application payload transferred from device to +Network Gateway, is called uplink fragmentation datagram. It uses an FPort for data uplink and its associated SCHC control downlinks, named FPortUp in this document. The -other way, a fragmentation session with application payload transferred from -Network Gateway to device, is called downlink fragmentation session. It uses another +other way, a fragmentation datagram with application payload transferred from +Network Gateway to device, is called downlink fragmentation datagram. It uses another FPort for data downlink and its associated SCHC control uplinks, named FPortDown in this document. @@ -380,11 +380,11 @@ means that the fragmentation is not used, thus, on reception, the SCHC Message MUST be sent to the C/D layer. The only uplink messages using the FPortDown port are the fragmentation SCHC -control messages of a downlink fragmentation session (for example, SCHC ACKs). +control messages of a downlink fragmentation datagram (for example, SCHC ACKs). Similarly, the only downlink messages using the FPortUp port are the -fragmentation SCHC control messages of an uplink fragmentation session. +fragmentation SCHC control messages of an uplink fragmentation datagram. -An application can have multiple fragmentation sessions between a device and one +An application can have multiple fragmentation datagrams between a device and one or several SCHC gateways. A set of FPort values is REQUIRED for each SCHC gateway instance the device is required to communicate with. @@ -448,18 +448,18 @@ RuleIDs matching FPortUp and FPortDown are reserved for SCHC Fragmentation. The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink fragmentation and Ack-Always mode for downlink fragmentation. A LoRaWAN -device cannot support simultaneous interleaved fragmentation sessions in +device cannot support simultaneous interleaved fragmentation datagrams in the same direction (uplink or downlink). The fragmentation parameters are different for uplink and downlink -fragmentation sessions and are successively described in the next sections. +fragmentation datagrams and are successively described in the next sections. ### DTag A LoRaWAN device cannot interleave several fragmented SCHC datagrams on the same FPort. This field is not used and its size is 0. -Note: The device can still have several parallel fragmentation sessions with one +Note: The device can still have several parallel fragmentation datagrams with one or more SCHC gateway(s) thanks to distinct sets of FPorts, cf {{rule-id-management}} ### Uplink fragmentation: From device to SCHC gateway @@ -705,7 +705,7 @@ fragment until it receives the fragment of the next window. The device SHALL transmit up to MAX_ACK_REQUESTS ACK messages before aborting. The device should transmit those ACK as soon as possible while taking into consideration potential local radio regulation on duty-cycle, to progress the fragmentation -session as quickly as possible. The ACK bitmap is 1 bit long and is always 1. +datagram as quickly as possible. The ACK bitmap is 1 bit long and is always 1. Following the reception of an FCN=All-1 fragment (the last fragment of a datagram) and if the RCS is correct, the device SHALL transmit the ACK with @@ -716,7 +716,7 @@ a downlink, on SCHC FPortDown from the SCHC gateway different from an SCHC ACK REQ: it indicates that the SCHC gateway has received the ACK message. The fragmentation sender (the SCHC gateway) implements an inactivity timer with -a default duration of 12 hours. Once a fragmentation session is started, if the +a default duration of 12 hours. Once a fragmentation datagram is started, if the SCHC gateway has not received any ACK or Receiver-Abort message 12 hours after the last message from the device was received, the SCHC gateway MAY flush the fragmentation context. For devices with very low transmission rates @@ -742,7 +742,7 @@ MAX_ACK_REQUESTS times before aborting. Following the reception of an FCN=All-1 fragment (the last fragment of a datagram) and if the RCS is correct, the device SHALL transmit the ACK with the "RCS is correct" indicator bit set. If the SCHC gateway receives this ACK, the -current fragmentation session has succeeded and its context can be cleared. +current fragmentation datagram has succeeded and its context can be cleared. If the retransmission timer elapses and the SCHC gateway has not received the SCHC ACK it retransmits the last fragment with the payload (not an SCHC ACK REQ From 3fc2360077e5a5a790502be79c649423a9d47652 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 08:13:28 +0200 Subject: [PATCH 15/42] Explicit that other frag param can be used --- draft-ietf-lpwan-schc-over-lorawan.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index fc1f224..51ad270 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -386,7 +386,9 @@ fragmentation SCHC control messages of an uplink fragmentation datagram. An application can have multiple fragmentation datagrams between a device and one or several SCHC gateways. A set of FPort values is REQUIRED for each SCHC gateway -instance the device is required to communicate with. +instance the device is required to communicate with. The application can use +additional uplinks or downlink fragmentation parameters but SHALL implement at +least the parameters defined in this document. The mechanism for sharing those RuleID values is outside the scope of this document. From f3b7077138bb0dccede00f43d78e49f819e8ef3e Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 08:13:56 +0200 Subject: [PATCH 16/42] Change uplink uplink retransmission timer to "set by the application" --- draft-ietf-lpwan-schc-over-lorawan.md | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 51ad270..10835bb 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -481,12 +481,8 @@ Packet, as per {{lorawan-schc-payload}}. * RCS: Use recommended calculation algorithm in [RFC8724]. * MAX_ACK_REQUESTS: 8 * Tile: size is 10 bytes -* Retransmission timer: LoRaWAN devices MUST NOT implement a - "retransmission timer", this changes the specification of - [RFC8724], see {{uplink-class-a}}. It must - transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own timing; ie the - periodicity between retransmission of SCHC ACK REQs is device specific and - can vary depending on other application uplinks and regulations. +* Retransmission timer: Set by the implementation depending on the application + requirements. * Inactivity timer: The SCHC gateway implements an "inactivity timer". The default RECOMMENDED duration of this timer is 12 hours; this value is mainly driven by application requirements and MAY be changed by the application. From 1161fb168bdc19dc5c387cbf21f4442d596c9937 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 08:15:24 +0200 Subject: [PATCH 17/42] Specify that additionnal delay is not used --- draft-ietf-lpwan-schc-over-lorawan.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 10835bb..58945bf 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -761,6 +761,13 @@ inactivity timer is implemented by the device to flush the context in case it 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 devices. +## SCHC Fragment Format + +### Delay after each message to respect local regulation + +This profile does not define a delay to be added after each SCHC message, local +regulation compliance will be enforced by LoRaWAN stack. + # Security considerations This document is only providing parameters that are expected to be best From d2b1abd8fe531969337f29f1019cc74482c06d4b Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 08:16:34 +0200 Subject: [PATCH 18/42] Specify why All-1 and Sender-Abort can be distinguished --- draft-ietf-lpwan-schc-over-lorawan.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 58945bf..5b85fa6 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -763,6 +763,12 @@ RECOMMENDED value is 12 hours for both Class B and Class C devices. ## SCHC Fragment Format +### All-1 SCHC fragment + +All-1 is distinguishable from a SCHC Sender-Abort as [RFC8724] states *This +condition is met if the RCS is present and is at least the size of an L2 Word*; +this condition met: RCS is 4 bytes. + ### Delay after each message to respect local regulation This profile does not define a delay to be added after each SCHC message, local From 2fff4e002ac6a4c9b76bc9672a77d898c84617ca Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 08:18:20 +0200 Subject: [PATCH 19/42] Specify why uplink All-0 and SCHC ACK REQ can be distinguished --- draft-ietf-lpwan-schc-over-lorawan.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 5b85fa6..d1e4a5f 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -763,6 +763,18 @@ RECOMMENDED value is 12 hours for both Class B and Class C devices. ## SCHC Fragment Format +### All-0 SCHC fragment + +**Uplink fragmentation (Ack-On-Error)**: + +All-0 is distinguishable from a SCHC ACK REQ as [RFC8724] states *This condition +is also met if the SCHC Fragment Header is a multiple of L2 Words*; this +condition met: SCHC header is 2 bytes. + +**Downlink fragmentation (Ack-always)**: + +TBC + ### All-1 SCHC fragment All-1 is distinguishable from a SCHC Sender-Abort as [RFC8724] states *This From d51b3efb3ec2ff2e9bcd727c304316d0c50336f1 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 16:59:50 +0200 Subject: [PATCH 20/42] Described downlink All-0 vs SCHC ACK REQ --- draft-ietf-lpwan-schc-over-lorawan.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index d1e4a5f..ae9c830 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -773,7 +773,9 @@ condition met: SCHC header is 2 bytes. **Downlink fragmentation (Ack-always)**: -TBC +In order to distinguish an All-0 from SCHC ACK REQ, implementation must ensure +that payload length without padding in the All-0 SCHC fragment will be strictly +greater than 6 bits, ie All-0 SCHC message will be longer than SCHC ACK REQ. ### All-1 SCHC fragment From bcd3993b5b26f05c1425aa8472e35b57a74965db Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 17:22:54 +0200 Subject: [PATCH 21/42] Rephrase regulation compliance --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index ae9c830..1636605 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -786,7 +786,7 @@ this condition met: RCS is 4 bytes. ### Delay after each message to respect local regulation This profile does not define a delay to be added after each SCHC message, local -regulation compliance will be enforced by LoRaWAN stack. +regulation compliance is expected to be enforced by LoRaWAN stack. # Security considerations From 854268a843f402e9d3f672fdd6c7e6cb6937796b Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 2 Jun 2020 18:17:28 +0200 Subject: [PATCH 22/42] Fixed typo --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1636605..73f3341 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -602,7 +602,7 @@ bits will require 6 bits of padding. -### Downlink fragmentation: From SCHC gateway to a device +### Downlink fragmentation: From SCHC gateway to device In that case the device is the fragmentation receiver, and the SCHC gateway the fragmentation transmitter. The following fields are common to all devices. From 7fa3fea9de3aca8c61256dc4994d84651b33bbeb Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 16 Jun 2020 00:48:46 +0200 Subject: [PATCH 23/42] Add heartbeat and update retransmission timer --- draft-ietf-lpwan-schc-over-lorawan.md | 124 ++++++++++++-------------- 1 file changed, 55 insertions(+), 69 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 73f3341..30b8628 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -371,7 +371,8 @@ 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 (no matching +* RuleID = 22 (8-bit) for heartbeat, named FPortCommandControl +* RuleID = 23 (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 @@ -620,6 +621,16 @@ Packet as described in {{lorawan-schc-payload}}. (FCN=All-1 is reserved for SCHC). * RCS: Use recommended calculation algorithm in [RFC8724]. * MAX_ACK_REQUESTS: 8 +* Retransmission timer: Set by the implementation depending on the application + requirements. As LoRaWAN class A devices can only receive a message after an + uplink the retransmission timer might expire before the SCHC ACK REQ is send + by the NGW. In this case implementation SHALL ensure that only one SCHC ACK REQ + is queued. If the NGW is not able to provide queue status, implementation MAY + disable retransmission timer or set it to a value greater than the inactivity + timer +* Inactivity timer: The default RECOMMENDED duration of this timer is 12 hours; + this value is mainly driven by application requirements and MAY be changed by + the application. As only 1 tile is used, its size can change for each downlink, and will be maximum available MTU. @@ -684,82 +695,57 @@ purposes but not SCHC needs. ~~~~ {: #Fig-fragmentation-downlink-header-abort title='Receiver-Abort packet (following an All-1 SCHC Fragment with incorrect RCS).'} +#### Retransmission timer +Class A and Class B or Class C devices do not manage retransmissions and timers +in the same way. -Class A and Class B or Class C devices do not manage retransmissions and -timers in the same way. - -#### Class A devices {#uplink-class-a} +##### Class A devices {#uplink-class-a} Class A devices can only receive in an RX slot following the transmission of an -uplink. Therefore there cannot be a concept of "retransmission timer" for an -SCHC gateway. The SCHC gateway cannot initiate communication to a Class A +uplink. Therefore the SCHC gateway cannot initiate communication to a Class A device. +Class A devices SHALL implement an heartbeat sending uplink on port +FPortCommandControl with an empty payload. It will create a downlink +opportunity for the SCHC gateway to start a SCHC session or send the SCHC ACK +REQ if the retransmission timer expires. Timing is application specific, +RECOMMENDED value is one heartbeat every 12h. + +The device replies with an SCHC ACK message to every single fragment received +from the SCHC gateway: + +* FCN=0: All fragment but the last have an FCN=0 (because window size is 1). + Following it the device SHALL transmit the SCHC ACK. It SHALL transmit up to + MAX_ACK_REQUESTS ACK messages before aborting. The device should transmit + those ACK as soon as possible while taking into consideration potential local + radio regulation on duty-cycle, to progress the fragmentation datagram as + quickly as possible. The ACK bitmap is 1 bit long and is always 1. + +* FCN=1: The last fragment of a datagram. If the RCS is correct, the device + SHALL transmit the ACK with the bit C=1. This message might be lost + therefore the SCHC gateway MUST request a retransmission of this ACK in the + next downlink when the retransmission timer expires. The device SHALL keep + this ACK message in memory until it receives a downlink, on SCHC FPortDown + different from an SCHC ACK REQ: it indicates that the SCHC gateway has + received the ACK message. + +The SCHC gateway implements an inactivity timer with a RECOMMENDED duration +of 48 hours. For devices with very low transmission rates (example 1 packet a +day in normal operation), that duration may be extended, but this is application +specific. -The device replies with an ACK message to every single fragment received from -the SCHC gateway (because the window size is 1). Following the reception of a -FCN=0 fragment (fragment that is not the last fragment of the packet or -SCHC ACK REQ, but the end of a window), the device MUST transmit the SCHC ACK -fragment until it receives the fragment of the next window. The device SHALL -transmit up to MAX_ACK_REQUESTS ACK messages before aborting. The device -should transmit those ACK as soon as possible while taking into consideration -potential local radio regulation on duty-cycle, to progress the fragmentation -datagram as quickly as possible. The ACK bitmap is 1 bit long and is always 1. - -Following the reception of an FCN=All-1 fragment (the last fragment of a -datagram) and if the RCS is correct, the device SHALL transmit the ACK with -the "RCS is correct" indicator bit set (C=1). This message might be lost -therefore the SCHC gateway MAY request a retransmission of this ACK in the next -downlink. The device SHALL keep this ACK message in memory until it receives -a downlink, on SCHC FPortDown from the SCHC gateway different from an -SCHC ACK REQ: it indicates that the SCHC gateway has received the ACK message. - -The fragmentation sender (the SCHC gateway) implements an inactivity timer with -a default duration of 12 hours. Once a fragmentation datagram is started, if the -SCHC gateway has not received any ACK or Receiver-Abort message 12 hours after -the last message from the device was received, the SCHC gateway MAY flush the -fragmentation context. For devices with very low transmission rates -(example 1 packet a day in normal operation) , that duration may be extended, -but this is application specific. +#### Class B or Class C devices +Class B devices can receive in scheduled RX slots or in RX slots following the +transmission of an uplink. Class C devices are almost in constant reception. +For those classes there is no need of an heartbeat to open RX window. -#### Class B or Class C devices +RECOMMENDED retransmission timer value: + +* Class B: 3 times the ping slot periodicity. +* Class C: 30 seconds -Class B and Class C devices can receive in scheduled RX slots or in RX -slots following the transmission of an uplink. The device replies with an ACK -message to every single fragment received from the SCHC gateway (because the -window size is 1). Following the reception of an FCN=0 fragment (fragment that -is not the last fragment of the packet or SCHC ACK REQ), the device MUST always -transmit the corresponding SCHC ACK message even if that fragment has already -been received. -The ACK bitmap is 1 bit long and is always 1. If the SCHC gateway receives this -ACK, it proceeds to send the next window fragment. If the retransmission timer -elapses and the SCHC gateway has not received the ACK of the current window it -retransmits the last fragment. The SCHC gateway tries retransmitting up to -MAX_ACK_REQUESTS times before aborting. - -Following the reception of an FCN=All-1 fragment (the last fragment of a -datagram) and if the RCS is correct, the device SHALL transmit the ACK with the -"RCS is correct" indicator bit set. If the SCHC gateway receives this ACK, the -current fragmentation datagram has succeeded and its context can be cleared. - -If the retransmission timer elapses and the SCHC gateway has not received the -SCHC ACK it retransmits the last fragment with the payload (not an SCHC ACK REQ -without payload). The SCHC gateway tries retransmitting up to MAX_ACK_REQUESTS -times before aborting. - -Following the reception of an FCN=All-1 fragment (the last fragment of a -datagram), if all fragments have been received and if the RCS is NOT correct, -the device SHALL transmit a Receiver-Abort fragment. The retransmission -timer is used by the SCHC gateway (the sender), the optimal value is very much -application specific but here are some recommended default values. -For Class B devices, this timer trigger is a function of the periodicity of the -Class B ping slots. The RECOMMENDED value is equal to 3 times the Class B ping -slot periodicity. For Class C devices which are nearly constantly receiving, -the RECOMMENDED value is 30 seconds. This means that the device shall try to -transmit the ACK within 30 seconds of the reception of each fragment. The -inactivity timer is implemented by the device to flush the context in case -it 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 devices. +The RECOMMENDED transmission timer value is 12 hours for both Class B and Class +C devices. ## SCHC Fragment Format From fdaf5655622f6c7c9c146470646c74fde2b615f9 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 16 Jun 2020 10:14:00 +0200 Subject: [PATCH 24/42] Update dn retrans. timer following Pascal review --- draft-ietf-lpwan-schc-over-lorawan.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 30b8628..435afab 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -696,6 +696,7 @@ purposes but not SCHC needs. {: #Fig-fragmentation-downlink-header-abort title='Receiver-Abort packet (following an All-1 SCHC Fragment with incorrect RCS).'} #### Retransmission timer + Class A and Class B or Class C devices do not manage retransmissions and timers in the same way. @@ -704,26 +705,25 @@ in the same way. Class A devices can only receive in an RX slot following the transmission of an uplink. Therefore the SCHC gateway cannot initiate communication to a Class A device. -Class A devices SHALL implement an heartbeat sending uplink on port +Class A devices MUST implement an heartbeat sending uplink on port FPortCommandControl with an empty payload. It will create a downlink opportunity for the SCHC gateway to start a SCHC session or send the SCHC ACK REQ if the retransmission timer expires. Timing is application specific, RECOMMENDED value is one heartbeat every 12h. -The device replies with an SCHC ACK message to every single fragment received +The device replies with a SCHC ACK message to every single fragment received from the SCHC gateway: * FCN=0: All fragment but the last have an FCN=0 (because window size is 1). - Following it the device SHALL transmit the SCHC ACK. It SHALL transmit up to + Following it the device MUST transmit the SCHC ACK. It MUST transmit up to MAX_ACK_REQUESTS ACK messages before aborting. The device should transmit - those ACK as soon as possible while taking into consideration potential local - radio regulation on duty-cycle, to progress the fragmentation datagram as + those ACK as soon as possible to progress the fragmentation datagram as quickly as possible. The ACK bitmap is 1 bit long and is always 1. * FCN=1: The last fragment of a datagram. If the RCS is correct, the device SHALL transmit the ACK with the bit C=1. This message might be lost therefore the SCHC gateway MUST request a retransmission of this ACK in the - next downlink when the retransmission timer expires. The device SHALL keep + next downlink when the retransmission timer expires. The device MUST keep this ACK message in memory until it receives a downlink, on SCHC FPortDown different from an SCHC ACK REQ: it indicates that the SCHC gateway has received the ACK message. From 832285bb85c5d469b4cbef3dce41667c87c0e568 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 16 Jun 2020 11:47:26 +0200 Subject: [PATCH 25/42] Clarified retransmission timer in downlink description --- draft-ietf-lpwan-schc-over-lorawan.md | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 435afab..1b002b9 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -618,16 +618,9 @@ Packet as described in {{lorawan-schc-payload}}. * Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. * 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). * RCS: Use recommended calculation algorithm in [RFC8724]. * MAX_ACK_REQUESTS: 8 -* Retransmission timer: Set by the implementation depending on the application - requirements. As LoRaWAN class A devices can only receive a message after an - uplink the retransmission timer might expire before the SCHC ACK REQ is send - by the NGW. In this case implementation SHALL ensure that only one SCHC ACK REQ - is queued. If the NGW is not able to provide queue status, implementation MAY - disable retransmission timer or set it to a value greater than the inactivity - timer +* Retransmission timer: See {{downlink-retransmission-timer}} * Inactivity timer: The default RECOMMENDED duration of this timer is 12 hours; this value is mainly driven by application requirements and MAY be changed by the application. @@ -695,12 +688,12 @@ purposes but not SCHC needs. ~~~~ {: #Fig-fragmentation-downlink-header-abort title='Receiver-Abort packet (following an All-1 SCHC Fragment with incorrect RCS).'} -#### Retransmission timer +#### Retransmission timer {#downlink-retransmission-timer} Class A and Class B or Class C devices do not manage retransmissions and timers in the same way. -##### Class A devices {#uplink-class-a} +##### Class A devices Class A devices can only receive in an RX slot following the transmission of an uplink. Therefore the SCHC gateway cannot initiate communication to a Class A From 1415dabce27b404118643238f83909f61c4b19d6 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 16 Jun 2020 11:48:04 +0200 Subject: [PATCH 26/42] Update downlink All-0 vs SCHC ACK REQ --- draft-ietf-lpwan-schc-over-lorawan.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1b002b9..b3ab036 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -752,9 +752,8 @@ condition met: SCHC header is 2 bytes. **Downlink fragmentation (Ack-always)**: -In order to distinguish an All-0 from SCHC ACK REQ, implementation must ensure -that payload length without padding in the All-0 SCHC fragment will be strictly -greater than 6 bits, ie All-0 SCHC message will be longer than SCHC ACK REQ. +As per [RFC8724] the SCHC All-1 MUST contain the last tile, implementation must +ensure that All-0 message Payload will be at least the size of an L2 Word. ### All-1 SCHC fragment From 5ad91fb7e35b9d9a5ad4427d2535382f9e268f31 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Tue, 16 Jun 2020 12:07:52 +0200 Subject: [PATCH 27/42] Clarified downlink ACK timing --- draft-ietf-lpwan-schc-over-lorawan.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index b3ab036..b6c465b 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -709,9 +709,10 @@ from the SCHC gateway: * FCN=0: All fragment but the last have an FCN=0 (because window size is 1). Following it the device MUST transmit the SCHC ACK. It MUST transmit up to - MAX_ACK_REQUESTS ACK messages before aborting. The device should transmit - those ACK as soon as possible to progress the fragmentation datagram as - quickly as possible. The ACK bitmap is 1 bit long and is always 1. + MAX_ACK_REQUESTS ACK messages before aborting. In order to progress the + fragmentation datagram as quickly as possible, the device should immediately + transmit those ACK if no SCHC downlink have been received during RX1 and RX2 + window. The ACK bitmap is 1 bit long and is always 1. * FCN=1: The last fragment of a datagram. If the RCS is correct, the device SHALL transmit the ACK with the bit C=1. This message might be lost From 139bc6c3a2cf6f239a06ff2de38d224e763d3841 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 22 Jun 2020 11:00:47 +0200 Subject: [PATCH 28/42] Fix class B/C inactivity timer typo --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index b6c465b..dd74f66 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -738,7 +738,7 @@ RECOMMENDED retransmission timer value: * Class B: 3 times the ping slot periodicity. * Class C: 30 seconds -The RECOMMENDED transmission timer value is 12 hours for both Class B and Class +The RECOMMENDED inactivity timer value is 12 hours for both Class B and Class C devices. ## SCHC Fragment Format From 8fe5f0d22493b85e334e675f07ac02001334ec41 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 22 Jun 2020 14:45:15 +0200 Subject: [PATCH 29/42] Remove FPortCommandControl --- 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 dd74f66..983ff01 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -371,8 +371,7 @@ 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 heartbeat, named FPortCommandControl -* RuleID = 23 (8-bit) for which SCHC compression was not possible (no matching +* 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 From 24b8d2299ebd7e5b02ef08ee61a8753627268def Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 22 Jun 2020 16:24:03 +0200 Subject: [PATCH 30/42] Remove heartbeat term, change its behavior --- draft-ietf-lpwan-schc-over-lorawan.md | 66 +++++++++++++++------------ 1 file changed, 37 insertions(+), 29 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 983ff01..121cc52 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -627,6 +627,13 @@ Packet as described in {{lorawan-schc-payload}}. As only 1 tile is used, its size can change for each downlink, and will be maximum available MTU. +Class A devices can only receive in an RX slot following the transmission of an +uplink. Therefore the SCHC gateway cannot initiate communication (ex: new SCHC +session); in order to create a downlink opportunity it is RECOMMENDED for +Class A devices to send an uplink every 24 hours when no SCHC session is +started, this is is application specific and can be disabled. RECOMMENDED uplink +is a LoRaWAN message without FPort and FRM payload. + _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for SCHC-over-LoRaWAN protocol. It might be set by the Network Gateway for other purposes but not SCHC needs. @@ -687,7 +694,7 @@ purposes but not SCHC needs. ~~~~ {: #Fig-fragmentation-downlink-header-abort title='Receiver-Abort packet (following an All-1 SCHC Fragment with incorrect RCS).'} -#### Retransmission timer {#downlink-retransmission-timer} +#### Downlink retransmission timer {#downlink-retransmission-timer} Class A and Class B or Class C devices do not manage retransmissions and timers in the same way. @@ -695,42 +702,43 @@ in the same way. ##### Class A devices Class A devices can only receive in an RX slot following the transmission of an -uplink. Therefore the SCHC gateway cannot initiate communication to a Class A -device. -Class A devices MUST implement an heartbeat sending uplink on port -FPortCommandControl with an empty payload. It will create a downlink -opportunity for the SCHC gateway to start a SCHC session or send the SCHC ACK -REQ if the retransmission timer expires. Timing is application specific, -RECOMMENDED value is one heartbeat every 12h. - -The device replies with a SCHC ACK message to every single fragment received -from the SCHC gateway: - -* FCN=0: All fragment but the last have an FCN=0 (because window size is 1). - Following it the device MUST transmit the SCHC ACK. It MUST transmit up to - MAX_ACK_REQUESTS ACK messages before aborting. In order to progress the - fragmentation datagram as quickly as possible, the device should immediately - transmit those ACK if no SCHC downlink have been received during RX1 and RX2 - window. The ACK bitmap is 1 bit long and is always 1. - -* FCN=1: The last fragment of a datagram. If the RCS is correct, the device - SHALL transmit the ACK with the bit C=1. This message might be lost - therefore the SCHC gateway MUST request a retransmission of this ACK in the - next downlink when the retransmission timer expires. The device MUST keep - this ACK message in memory until it receives a downlink, on SCHC FPortDown - different from an SCHC ACK REQ: it indicates that the SCHC gateway has - received the ACK message. +uplink. The SCHC gateway implements an inactivity timer with a RECOMMENDED duration -of 48 hours. For devices with very low transmission rates (example 1 packet a -day in normal operation), that duration may be extended, but this is application +of 36 hours. For devices with very low transmission rates (example 1 packet a +day in normal operation), that duration may be extended: it is application specific. +RETRANSMISSION_TIMER is application specific and its RECOMMENDED value is +INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1). + +**SCHC All-0 (FCN=0)** +All fragment but the last have an FCN=0 (because window size is 1). Following +it the device MUST transmit the SCHC ACK message. It MUST transmit up to +MAX_ACK_REQUESTS SCHC ACK messages before aborting. In order to progress the +fragmentation datagram as quickly as possible, the device should immediately +transmit those SCHC ACK if no SCHC downlink have been received during RX1 and +RX2 window. + +_Note_: The ACK bitmap is 1 bit long and is always 1. + +**SCHC All-1 (FCN=1)** +The last fragment of a datagram, the corresponding SCHC ACK message might be +lost; therefore the SCHC gateway MUST request a retransmission of this ACK when +the retransmission timer expires. To open a downlink opportunity the device +MUST transmit an uplink every RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 2) hours. +The format of this uplink is application specific. It is RECOMMENDED for a +device to send an empty uplink (no FPort and FRMPayload) but it is application +specific and will be used by the NGW to transmit a potential SCHC ACK REQ. + +_Note_: The device MUST keep this SCHC ACK message in memory until it receives +a downlink, on SCHC FPortDown different from an SCHC ACK REQ: it indicates that +the SCHC gateway has received the ACK message. + #### Class B or Class C devices Class B devices can receive in scheduled RX slots or in RX slots following the transmission of an uplink. Class C devices are almost in constant reception. -For those classes there is no need of an heartbeat to open RX window. RECOMMENDED retransmission timer value: From 4f883db91d04726b9f4c2557259e79d1c3ac8f62 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:00:57 +0200 Subject: [PATCH 31/42] Clarify restrans. timer All-1 description --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 121cc52..6137bc5 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -723,7 +723,7 @@ RX2 window. _Note_: The ACK bitmap is 1 bit long and is always 1. **SCHC All-1 (FCN=1)** -The last fragment of a datagram, the corresponding SCHC ACK message might be +SCHC All-1 is the last fragment of a datagram, the corresponding SCHC ACK message might be lost; therefore the SCHC gateway MUST request a retransmission of this ACK when the retransmission timer expires. To open a downlink opportunity the device MUST transmit an uplink every RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 2) hours. From ff8a821ca855c029a0949abc257e22166ccbbe70 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:01:37 +0200 Subject: [PATCH 32/42] Remove useless unit --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 6137bc5..fe6b449 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -726,7 +726,7 @@ _Note_: The ACK bitmap is 1 bit long and is always 1. SCHC All-1 is the last fragment of a datagram, the corresponding SCHC ACK message might be lost; therefore the SCHC gateway MUST request a retransmission of this ACK when the retransmission timer expires. To open a downlink opportunity the device -MUST transmit an uplink every RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 2) hours. +MUST transmit an uplink every RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 2). The format of this uplink is application specific. It is RECOMMENDED for a device to send an empty uplink (no FPort and FRMPayload) but it is application specific and will be used by the NGW to transmit a potential SCHC ACK REQ. From bd7c7e39da565fa7b46fcbaba19784164290f814 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:10:33 +0200 Subject: [PATCH 33/42] Make number of RX windows for ACK REQ customizable --- draft-ietf-lpwan-schc-over-lorawan.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index fe6b449..5f69095 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -723,13 +723,17 @@ RX2 window. _Note_: The ACK bitmap is 1 bit long and is always 1. **SCHC All-1 (FCN=1)** -SCHC All-1 is the last fragment of a datagram, the corresponding SCHC ACK message might be -lost; therefore the SCHC gateway MUST request a retransmission of this ACK when -the retransmission timer expires. To open a downlink opportunity the device -MUST transmit an uplink every RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * 2). +SCHC All-1 is the last fragment of a datagram, the corresponding SCHC ACK +message might be lost; therefore the SCHC gateway MUST request a retransmission +of this ACK when the retransmission timer expires. To open a downlink +opportunity the device MUST transmit an uplink every +RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is application specific. It is RECOMMENDED for a device to send an empty uplink (no FPort and FRMPayload) but it is application -specific and will be used by the NGW to transmit a potential SCHC ACK REQ. +specific and will be used by the NGW to transmit a potential SCHC ACK REQ. +SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its recommended value +is 2, it MUST be greater than 1. This allows to open downlink opportunity to other +eventual downlink with higher priority than SCHC ACK REQ message. _Note_: The device MUST keep this SCHC ACK message in memory until it receives a downlink, on SCHC FPortDown different from an SCHC ACK REQ: it indicates that From 7e18006f5a09f8ff86aa09c6cb506cba3e7a0b68 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:21:22 +0200 Subject: [PATCH 34/42] Fix typo reported by Julien 01/07 --- draft-ietf-lpwan-schc-over-lorawan.md | 40 +++++++++++++-------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 5f69095..0d6b410 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -102,7 +102,7 @@ all other definitions, please look up the SCHC specification o DevEUI: an IEEE EUI-64 identifier used to identify the device during the procedure while joining the network (Join Procedure) - o DevAddr: a 32-bit non-unique identifier assigned to an device statically or + o DevAddr: a 32-bit non-unique identifier assigned to a device statically or dynamically after a Join Procedure (depending on the activation mode) o RCS: Reassembly Check Sequence. Used to verify the integrity of the @@ -262,20 +262,20 @@ network; devices using the same devAddr are distinguished by the Network Gateway based on the cryptographic signature appended to every LoRaWAN frame. To communicate with the SCHC gateway the Network Gateway MUST identify the -devices by a unique 64-bit device identifier called the devEUI. +devices by a unique 64-bit device identifier called the DevEUI. -The devEUI is assigned to the device during the manufacturing process by the +The DevEUI is assigned to the device during the manufacturing process by the device's manufacturer. It is built like an Ethernet MAC address by concatenating the manufacturer's IEEE OUI field with a vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit serial number. -The Network Gateway translates the devAddr into a devEUI in the uplink +The Network Gateway translates the devAddr into a DevEUI in the uplink direction and reciprocally on the downlink direction. ~~~~ +--------+ +---------+ +---------+ +----------+ | Device | <=====> | Network | <====> | SCHC | <========> | Internet | -| | devAddr | Gateway | devEUI | Gateway | IPv6/UDP | | +| | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | | +--------+ +---------+ +---------+ +----------+ ~~~~ @@ -294,12 +294,12 @@ confirmed messages. ## LoRaWAN MAC Frames * JoinRequest: - This message is used by an device to join a network. It contains the device's - unique identifier devEUI and a random nonce that will be used for session key + This message is used by a device to join a network. It contains the device's + unique identifier DevEUI and a random nonce that will be used for session key derivation. * JoinAccept: - To on-board an device, the Network Gateway responds to the JoinRequest - issued by an device with a JoinAccept message. That message is + To on-board a device, the Network Gateway responds to the JoinRequest + issued by a device with a JoinAccept message. That message is encrypted with the device's AppKey and contains (amongst other fields) the major network's settings and a network random nonce used to derive the session keys. @@ -341,7 +341,7 @@ as a part of the RuleID field. | FPort | LoRaWAN payload | + ------------------------ + -| SCHC packet | +| SCHC packet | ~~~~ {: #Fig-lorawan-schc-payload title='SCHC Message in LoRaWAN'} @@ -398,7 +398,7 @@ In order to mitigate risks described in [rfc8064] and [rfc8065] IID MUST be created regarding the following algorithm: 1. key = LoRaWAN AppSKey -2. cmac = aes128_cmac(key, devEui) +2. cmac = aes128_cmac(key, DevEUI) 3. IID = cmac[0..7] aes128_cmac algorithm is described in [rfc4493]. It has been chosen as it is @@ -413,12 +413,12 @@ Address scan risk is mitigated thanks to AES-128, which provides enough entropy bits of the IID. Using this algorithm will also ensure that there is no correlation between the -hardware identifier (IEEE-64 devEUI) and the IID, so an attacker cannot use +hardware identifier (IEEE-64 DevEUI) and the IID, so an attacker cannot use manufacturer OUI to target devices. Example with: -* devEui: 0x1122334455667788 +* DevEUI: 0x1122334455667788 * appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB ~~~~ @@ -557,19 +557,19 @@ a part of the rule context. ~~~~ -| FPort | LoRaWAN payload | -+ ------ + ------------------------------------------------------------------------- + -| RuleID | W | C | Compressed bitmap (if C = 0) | Optional padding (b'0...0) | -+ ------ + ----- + ----- + ---------------------------- + -------------------------- + -| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits | +| FPort | LoRaWAN payload | ++ ------ + -------------------------------------------------------------------- + +| RuleID | W | C | Compressed bitmap(C = 0) | Optional padding(b'0...0) | ++ ------ + ----- + ----- + ------------------------ + ------------------------- + +| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits | ~~~~ {: #Fig-fragmentation-header-long-schc-ack title='SCHC ACK format, failed RCS check.'} Note: Because of the bitmap compression mechanism and L2 byte alignment only -few discrete values are possible: 5, 13, 21, 29, 37, 45, 53, 61. Bitmaps of 63 -bits will require 6 bits of padding. +few discrete values are possible: 5, 13, 21, 29, 37, 45, 53, 61, 62, 63. +Bitmaps of 63 bits will require 6 bits of padding. #### Receiver-Abort From 362f813b2b88ac1f91111d6d3f200670d15fae09 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:24:08 +0200 Subject: [PATCH 35/42] Clarify LoRaWAN device --- draft-ietf-lpwan-schc-over-lorawan.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 0d6b410..4117dff 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -192,7 +192,7 @@ and the ones in {{lora-alliance-spec}} is as follows: o Devices are LoRaWAN End Devices (e.g. sensors, actuators, etc.). There can be a very high density of devices per - radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN device. + radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN end-device. o The Radio Gateway (RGW), which is the endpoint of the constrained link. This entity maps to the LoRaWAN Gateway. @@ -218,7 +218,7 @@ and the ones in {{lora-alliance-spec}} is as follows: {: #Fig-LPWANarchi title='LPWAN Architecture'} SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/Reassembly) - are performed on the LoRaWAN device and the Application Server (called + are performed on the LoRaWAN end-device and the Application Server (called SCHC gateway). While the point-to-point link between the device and the Application Server constitutes single IP hop, the ultimate end-point of the IP communication may be an Internet node beyond the Application Server. @@ -256,7 +256,7 @@ Class C. Class B and Class C are mutually exclusive. ## Device addressing -LoRaWAN devices use a 32-bit network address (devAddr) to communicate with +LoRaWAN end-devices use a 32-bit network address (devAddr) to communicate with the network over-the-air, this address might not be unique in a LoRaWAN network; devices using the same devAddr are distinguished by the Network Gateway based on the cryptographic signature appended to every LoRaWAN frame. @@ -458,7 +458,7 @@ fragmentation datagrams and are successively described in the next sections. ### DTag -A LoRaWAN device cannot interleave several fragmented SCHC datagrams on the same +A Device cannot interleave several fragmented SCHC datagrams on the same FPort. This field is not used and its size is 0. Note: The device can still have several parallel fragmentation datagrams with one From e980ddcd6f4b21de4450cb2a71e50b371902c242 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:28:24 +0200 Subject: [PATCH 36/42] Fix poorly defined network term --- draft-ietf-lpwan-schc-over-lorawan.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 4117dff..de2b650 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -236,14 +236,14 @@ Class C. Class B and Class C are mutually exclusive. * Class A: The Class A is the simplest class of devices. The device is allowed to transmit at any time, randomly selecting a communication channel. - The network may reply with a downlink in one of the 2 receive windows - immediately following the uplinks. Therefore, the network cannot initiate a + The Network Gateway may reply with a downlink in one of the 2 receive windows + immediately following the uplinks. Therefore, the Network Gateway cannot initiate a downlink, it has to wait for the next uplink from the device to get a downlink opportunity. The Class A is the lowest power device class. * Class B: Class B devices implement all the functionalities of Class A devices, but also schedule periodic listen windows. Therefore, opposed to the Class A devices, Class B devices can receive downlinks that are initiated by the - network and not following an uplink. There is a trade-off between the + Network Gateway and not following an uplink. There is a trade-off between the periodicity of those scheduled Class B listen windows and the power consumption of the device. The lower the downlink latency, the higher the power consumption. @@ -257,7 +257,7 @@ Class C. Class B and Class C are mutually exclusive. ## Device addressing LoRaWAN end-devices use a 32-bit network address (devAddr) to communicate with -the network over-the-air, this address might not be unique in a LoRaWAN +the Network Gateway over-the-air, this address might not be unique in a LoRaWAN network; devices using the same devAddr are distinguished by the Network Gateway based on the cryptographic signature appended to every LoRaWAN frame. @@ -301,8 +301,8 @@ confirmed messages. To on-board a device, the Network Gateway responds to the JoinRequest issued by a device with a JoinAccept message. That message is encrypted with the device's AppKey and contains (amongst other fields) - the major network's settings and a network random nonce used to derive the - session keys. + the major network's settings and a random nonce used to derive the session + keys. * Data: MAC and application data. Application data are protected with AES-128 encryption, MAC related data are AES-128 encrypted with another key. @@ -404,8 +404,8 @@ created regarding the following algorithm: aes128_cmac algorithm is described in [rfc4493]. It has been chosen as it is already used by devices for LoRaWAN protocol. -As AppSKey is renewed each time a device joins or rejoins a network, the IID -will change over time; this mitigates privacy, location tracking and +As AppSKey is renewed each time a device joins or rejoins a LoRaWAN network, +the IID will change over time; this mitigates privacy, location tracking and correlation over time risks. Join periodicity is defined at the application level. @@ -428,7 +428,7 @@ Example with: ~~~~ {: #Fig-iid-computation-example title='Example of IID computation.'} -There is a small probability of IID collision in a network, if such event occurs +There is a small probability of IID collision in a LoRaWAN network, if such event occurs the IID can be changed by rekeying the device on L2 level (ie: trigger a LoRaWAN join). The way the device is rekeyed is out of scope of this document and left to the @@ -508,8 +508,8 @@ tiles from the next window. If the SCHC ACK is not received, it SHOULD send an S ACK REQ up to MAX_ACK_REQUESTS, time as described previously. For non-battery powered devices, SCHC receiver MAY also choose to send a SCHC -ACK only at the end of all windows. It will reduce downlink load on the network, -by reducing the number of downlinks. +ACK only at the end of all windows. It will reduce downlink load on the LoRaWAN +network, by reducing the number of downlinks. SCHC implementations MUST be compatible with both behavior, and selection is a part of the rule context. @@ -787,7 +787,7 @@ any new security issues in addition to those identified in [RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected on LoRaWAN level by an AES-128 encryption with key shared by device and SCHC gateway. Those keys are renewed at each -LoRaWAN session (ie: each join or rejoin to the network) +LoRaWAN session (ie: each join or rejoin to the LoRaWAN network) # Acknowledgements {:numbered="false"} From bf19fa6cbcd2f29b18ec1302da732567831a63b8 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:33:21 +0200 Subject: [PATCH 37/42] Add define SCHC gateway term --- draft-ietf-lpwan-schc-over-lorawan.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index de2b650..abcd942 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -110,6 +110,10 @@ all other definitions, please look up the SCHC specification o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI + o SCHC gateway: It corresponds to the LoRaWAN Application Server. It manages + translation between IPv6 network and the Network Gateway (LoRaWAN Network + Server) + # Static Context Header Compression Overview This section contains a short overview of Static Context Header Compression From 3d18df081095ab821bf2dd9977410d990007b1e3 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:39:58 +0200 Subject: [PATCH 38/42] Add LoRaWAN empty frame chapter --- draft-ietf-lpwan-schc-over-lorawan.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index abcd942..b174734 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -311,6 +311,10 @@ confirmed messages. MAC and application data. Application data are protected with AES-128 encryption, MAC related data are AES-128 encrypted with another key. +## LoRaWAN empty frame {#lorawan-empty-frame} + +A LoRaWAN empty frame is a LoRaWAN message without FPort and FRM payload. + ## Unicast and multicast technology LoRaWAN technology supports unicast downlinks, but also multicast: a packet @@ -636,7 +640,7 @@ uplink. Therefore the SCHC gateway cannot initiate communication (ex: new SCHC session); in order to create a downlink opportunity it is RECOMMENDED for Class A devices to send an uplink every 24 hours when no SCHC session is started, this is is application specific and can be disabled. RECOMMENDED uplink -is a LoRaWAN message without FPort and FRM payload. +is a LoRaWAN empty frame as defined {{lorawan-empty-frame}}. _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for SCHC-over-LoRaWAN protocol. It might be set by the Network Gateway for other @@ -733,7 +737,7 @@ of this ACK when the retransmission timer expires. To open a downlink opportunity the device MUST transmit an uplink every RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is application specific. It is RECOMMENDED for a -device to send an empty uplink (no FPort and FRMPayload) but it is application +device to send an empty frame (see {{lorawan-empty-frame}}) but it is application specific and will be used by the NGW to transmit a potential SCHC ACK REQ. SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its recommended value is 2, it MUST be greater than 1. This allows to open downlink opportunity to other From dc12dc97155851d9537fbd491165ef77625bc024 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 17:41:36 +0200 Subject: [PATCH 39/42] Fix LoRaWAN frame types --- draft-ietf-lpwan-schc-over-lorawan.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index b174734..500d96d 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -285,15 +285,15 @@ direction and reciprocally on the downlink direction. ~~~~ {: #Fig-LoRaWANaddresses title='LoRaWAN addresses'} -## General Message Types +## General Frame Types -* Confirmed messages: +* LoRaWAN Confirmed message: The sender asks the receiver to acknowledge the message. -* Unconfirmed messages: +* LoRaWAN Unconfirmed message: The sender does not ask the receiver to acknowledge the message. As SCHC defines its own acknowledgment mechanisms, SCHC does not require to use -confirmed messages. +LoRaWAN Confirmed messages. ## LoRaWAN MAC Frames From 774ec3991adfadffd6422b512e71603e69789ffd Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 21:52:33 +0200 Subject: [PATCH 40/42] Clarify downlink oppotunity following interim --- draft-ietf-lpwan-schc-over-lorawan.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 500d96d..98851a0 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -635,12 +635,14 @@ Packet as described in {{lorawan-schc-payload}}. As only 1 tile is used, its size can change for each downlink, and will be maximum available MTU. -Class A devices can only receive in an RX slot following the transmission of an +Class A devices can only receive during an RX slot, following the transmission of an uplink. Therefore the SCHC gateway cannot initiate communication (ex: new SCHC session); in order to create a downlink opportunity it is RECOMMENDED for Class A devices to send an uplink every 24 hours when no SCHC session is -started, this is is application specific and can be disabled. RECOMMENDED uplink +started, this is application specific and can be disabled. RECOMMENDED uplink is a LoRaWAN empty frame as defined {{lorawan-empty-frame}}. +As this uplink is to open an RX window any applicative uplink MAY reset this +counter. _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be used for SCHC-over-LoRaWAN protocol. It might be set by the Network Gateway for other From 713dd4eb82e96743c2317e43d55309aa2ec0cdc3 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Thu, 2 Jul 2020 21:54:21 +0200 Subject: [PATCH 41/42] Clarified All-0 restrans. timer following interim --- draft-ietf-lpwan-schc-over-lorawan.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 98851a0..066d600 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -726,9 +726,9 @@ INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1). All fragment but the last have an FCN=0 (because window size is 1). Following it the device MUST transmit the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC ACK messages before aborting. In order to progress the -fragmentation datagram as quickly as possible, the device should immediately -transmit those SCHC ACK if no SCHC downlink have been received during RX1 and -RX2 window. +fragmentation datagram, the SCHC layer should immediately queue for transmission +those SCHC ACK if no SCHC downlink have been received during RX1 and RX2 window. +LoRaWAN layer will respect the regulation if required. _Note_: The ACK bitmap is 1 bit long and is always 1. From a03d622bc9b2322920a8f26f78d8393300539378 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 3 Jul 2020 17:05:37 +0200 Subject: [PATCH 42/42] Fix FRMPayload typo --- draft-ietf-lpwan-schc-over-lorawan.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 066d600..5d9f93b 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -313,7 +313,7 @@ LoRaWAN Confirmed messages. ## LoRaWAN empty frame {#lorawan-empty-frame} -A LoRaWAN empty frame is a LoRaWAN message without FPort and FRM payload. +A LoRaWAN empty frame is a LoRaWAN message without FPort and FRMPayload. ## Unicast and multicast technology