From 95c16781940e682c836d0f66a45348fd922ff29a Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 13:51:34 +0200 Subject: [PATCH 01/17] Removed unused RFC references --- draft-ietf-lpwan-schc-over-lorawan.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 5d9f93b..ca7fcd1 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -32,10 +32,6 @@ author: normative: RFC2119: RFC8174: - RFC4944: - RFC5795: - RFC7136: - RFC3385: RFC4291: RFC8064: RFC8065: From efa281cf0f56c961b7033b81de2637eb3f740b76 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 13:55:41 +0200 Subject: [PATCH 02/17] Add IANA considerations --- 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 ca7fcd1..66fc1eb 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -795,6 +795,10 @@ Moreover, SCHC data (LoRaWAN payload) are protected on LoRaWAN level by an AES-1 encryption with key shared by device and SCHC gateway. Those keys are renewed at each LoRaWAN session (ie: each join or rejoin to the LoRaWAN network) +# IANA Considerations + +This document has no IANA actions. + # Acknowledgements {:numbered="false"} From 5470d8b1cf3e5fc1b69a8b2619c9750ad4de681c Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:01:26 +0200 Subject: [PATCH 03/17] Expand accronyms before defintion --- 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 66fc1eb..32833a5 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -55,8 +55,8 @@ informative: --- abstract The Static Context Header Compression (SCHC) specification describes generic -header compression and fragmentation techniques for LPWAN (Low Power Wide Area -Networks) technologies. SCHC is a generic mechanism designed for great +header compression and fragmentation techniques for Low Power Wide Area +Networks (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies. This document provides the adaptation of SCHC for use in LoRaWAN networks, and @@ -67,10 +67,9 @@ This is called a profile. # Introduction {#Introduction} -The Static Context Header Compression (SCHC) specification -[RFC8724] describes +SCHC specification [RFC8724] describes generic header compression and fragmentation techniques that can be used on all -LPWAN (Low Power Wide Area Networks) technologies defined in +LPWAN 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 @@ -112,9 +111,8 @@ all other definitions, please look up the SCHC specification # Static Context Header Compression Overview -This section contains a short overview of Static Context Header Compression -(SCHC). For a detailed description, refer to the full specification -[RFC8724]. +This section contains a short overview of SCHC. For a detailed description, +refer to the full specification [RFC8724]. It defines: @@ -217,7 +215,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) + SCHC Compressor/Decompressor (SCHC C/D) and SCHC Fragmentation/Reassembly (SCHC F/R) 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 From 288b7193226d924fb387937a2e1caf8c4f6a2302 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:07:05 +0200 Subject: [PATCH 04/17] Add mising period for lists --- 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 32833a5..1654bb3 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -95,19 +95,19 @@ all other definitions, please look up the SCHC specification [RFC8724]. o DevEUI: an IEEE EUI-64 identifier used to identify the device during the - procedure while joining the network (Join Procedure) + procedure while joining the network (Join Procedure). o DevAddr: a 32-bit non-unique identifier assigned to a device statically or - dynamically after a Join Procedure (depending on the activation mode) + dynamically after a Join Procedure (depending on the activation mode). o RCS: Reassembly Check Sequence. Used to verify the integrity of the - fragmentation-reassembly process + fragmentation-reassembly process. - o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI + 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) + Server). # Static Context Header Compression Overview @@ -117,9 +117,9 @@ refer to the full specification [RFC8724]. It defines: 1. Compression mechanisms to avoid transporting information known by both - sender and receiver over the air. Known information are part of the "context" + 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 + potentially variable, MTU. Context exchange or pre-provisioning is out of scope of this document. @@ -371,10 +371,10 @@ traffic by using FPort values different from the ones used for SCHC. 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 = 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 -rule was found) +rule was found). The remaining RuleIDs are available for compression. RuleIDs are shared between uplink and downlink sessions. A RuleID not in the set(s) of FPortUp or FPortDown @@ -475,14 +475,14 @@ Packet, as per {{lorawan-schc-payload}}. * SCHC header size is two bytes (the FPort byte + 1 additional byte). * RuleID: 8 bits stored in LoRaWAN FPort. -* SCHC fragmentation reliability mode: `ACK-on-Error` -* DTag: Size is 0 bit, not used +* SCHC fragmentation reliability mode: `ACK-on-Error`. +* DTag: Size is 0 bit, not used. * FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 tiles - are allowed in a window + are allowed in a window. * Window index: encoded on W = 2 bits. So 4 windows are available. * RCS: Use recommended calculation algorithm in [RFC8724]. -* MAX_ACK_REQUESTS: 8 -* Tile: size is 10 bytes +* MAX_ACK_REQUESTS: 8. +* Tile: size is 10 bytes. * Retransmission timer: Set by the implementation depending on the application requirements. * Inactivity timer: The SCHC gateway implements an "inactivity timer". The @@ -617,11 +617,11 @@ Packet as described in {{lorawan-schc-payload}}. layer. This feature is OPTIONAL and may not be implemented by SCHC gateway. * RuleID: 8 bits stored in LoRaWAN FPort. * Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. -* DTag: Size is 0 bit, not used -* FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile +* DTag: Size is 0 bit, not used. +* FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile. * RCS: Use recommended calculation algorithm in [RFC8724]. -* MAX_ACK_REQUESTS: 8 -* Retransmission timer: See {{downlink-retransmission-timer}} +* MAX_ACK_REQUESTS: 8. +* 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. @@ -751,7 +751,7 @@ transmission of an uplink. Class C devices are almost in constant reception. RECOMMENDED retransmission timer value: * Class B: 3 times the ping slot periodicity. -* Class C: 30 seconds +* Class C: 30 seconds. The RECOMMENDED inactivity timer value is 12 hours for both Class B and Class C devices. From 602a5c0718d91b65c580a8e70f32bf233799da01 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:29:12 +0200 Subject: [PATCH 05/17] Add uplink/downlink term. Sort the list --- draft-ietf-lpwan-schc-over-lorawan.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1654bb3..f0b9c71 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -100,15 +100,21 @@ all other definitions, please look up the SCHC specification 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 - fragmentation-reassembly process. + o Downlink: LoRaWAN term for a message transmitted by the network and + received by the device. o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI. + o RCS: Reassembly Check Sequence. Used to verify the integrity of the + fragmentation-reassembly process. + o SCHC gateway: It corresponds to the LoRaWAN Application Server. It manages translation between IPv6 network and the Network Gateway (LoRaWAN Network Server). + o Uplink: LoRaWAN term for a message transmitted by the device and received + by the network. + # Static Context Header Compression Overview This section contains a short overview of SCHC. For a detailed description, From 9d94fce6314b2f063f29d5c84ccce3e30903e6b0 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:41:13 +0200 Subject: [PATCH 06/17] Defined SCHC C/D and F/R in the overview --- 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 f0b9c71..2248ab3 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -123,9 +123,11 @@ refer to the full specification [RFC8724]. It defines: 1. Compression mechanisms to avoid transporting information known by both - sender and receiver over the air. Known information are part of the "context". + sender and receiver over the air. Known information are part of the + "context". This component is called SCHC Compressor/Decompressor (SCHC C/D) 2. Fragmentation mechanisms to allow SCHC Packet transportation on small, and - potentially variable, MTU. + potentially variable, MTU. This component called SCHC Fragmentation/Reassembly + (SCHC F/R) Context exchange or pre-provisioning is out of scope of this document. From 88b294e3c10344e9e0c868fbbcd19981483c95e3 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:42:15 +0200 Subject: [PATCH 07/17] Use SCHC before C/R or F/R --- draft-ietf-lpwan-schc-over-lorawan.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 2248ab3..3e57d00 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -155,18 +155,18 @@ 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 reassembly, if -required, then to SCHC 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 +required, then to SCHC C/D for decompression. The SCHC C/D shares the same rules with the +device. The SCHC C/D and F/R 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 +F/R, then SCHC F/R and C/D. The SCHC C/D in both sides MUST share the same set of rules. After decompression, the packet can be sent on the Internet to one or several LPWAN Application Servers (App). -The SCHC F/R and SCHC C/D process is bidirectional, so the same principles can +The SCHC C/D and F/R 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 and SCHC F/R are an Application Server. It can be provided by +and the SCHC C/D and 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: @@ -207,8 +207,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 SCHC F/R and SCHC C/D are LoRaWAN Application Server; ie the LoRaWAN - application server will do the C/D and F/R. + o SCHC C/D and F/R are LoRaWAN Application Server; ie the LoRaWAN + application server will do the SCHC C/D and F/R. ~~~~ @@ -387,7 +387,7 @@ rule was found). The remaining RuleIDs are available for compression. RuleIDs are shared between uplink and downlink sessions. A RuleID not in the set(s) of FPortUp or FPortDown means that the fragmentation is not used, thus, on reception, the SCHC Message -MUST be sent to the C/D layer. +MUST be sent to the SCHC C/D layer. The only uplink messages using the FPortDown port are the fragmentation SCHC control messages of a downlink fragmentation datagram (for example, SCHC ACKs). @@ -852,7 +852,7 @@ This example represents an applicative payload going through SCHC over LoRaWAN, no fragmentation required An applicative payload of 78 bytes is passed to SCHC compression layer. Rule 1 -is used by C/D layer, allowing to compress it to 40 bytes and 5 bits: 1 byte +is used by SCHC C/D layer, allowing to compress it to 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. ~~~~ @@ -882,7 +882,7 @@ This example represents an applicative payload going through SCHC, with fragmentation. An applicative payload of 478 bytes is passed to SCHC compression layer. Rule 1 -is used by C/D layer, allowing to compress it to 282 bytes and 5 bits: 1 byte +is used by SCHC C/D layer, allowing to compress it to 282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. ~~~~ @@ -968,7 +968,7 @@ correct so the following ACK is sent to the device by the SCHC receiver: ## Downlink An applicative payload of 443 bytes is passed to SCHC compression layer. Rule 1 -is used by C/D layer, allowing to compress it to 130 bytes and 5 bits: 1 byte +is used by SCHC C/D layer, allowing to compress it to 130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. ~~~~ From 15681ce716e4c79afafc307159d7e486200ace3e Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:48:30 +0200 Subject: [PATCH 08/17] Changed tunnel to communication --- 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 3e57d00..edd0768 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -157,7 +157,7 @@ size and fragmented (SCHC F/R). The resulting information is sent on a layer tw Gateway (NGW). The NGW sends the data to a SCHC F/R for reassembly, if required, then to SCHC C/D for decompression. The SCHC C/D shares the same rules with the device. The SCHC C/D and F/R 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 +another place as long as a communication is established between the NGW and the SCHC F/R, then SCHC F/R and C/D. The SCHC C/D in both sides MUST share the same set of rules. After decompression, the packet can be sent on the Internet to one or several LPWAN Application Servers (App). From f9e89b7324eb6350150f5a052860fb47656d9912 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:51:55 +0200 Subject: [PATCH 09/17] Explained C/D rules in both side --- 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 edd0768..2fc4bdd 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -158,8 +158,8 @@ Gateway (NGW). The NGW sends the data to a SCHC F/R for reassembly, if required, then to SCHC C/D for decompression. The SCHC C/D shares the same rules with the device. The SCHC C/D and F/R can be located on the Network Gateway (NGW) or in another place as long as a communication is established between the NGW and the SCHC -F/R, then SCHC F/R and C/D. The SCHC C/D in both sides MUST share the same -set of rules. After decompression, the packet can be sent on the Internet to +F/R, then SCHC F/R and C/D. The SCHC C/D and F/R in the device and the SCHC gateway MUST +share the same set of rules. After decompression, the packet can be sent on the Internet to one or several LPWAN Application Servers (App). The SCHC C/D and F/R process is bidirectional, so the same principles can From 019475333270ee25b63614e7322cfadd4c983637 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 14:54:16 +0200 Subject: [PATCH 10/17] Fixed class A power consumption wording --- 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 2fc4bdd..8ad0f96 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -245,7 +245,7 @@ Class C. Class B and Class C are mutually exclusive. 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. + downlink opportunity. The Class A is the lowest power consumption 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 From d73f1fa8a605309041d7b490ab0bd09dc0a7979c Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 16:04:46 +0200 Subject: [PATCH 11/17] Detail devEui/DevAddr origin --- 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 8ad0f96..0e9ba01 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -94,26 +94,26 @@ 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 device during the - procedure while joining the network (Join Procedure). - - 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 Downlink: LoRaWAN term for a message transmitted by the network and - received by the device. - - o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI. - - o RCS: Reassembly Check Sequence. Used to verify the integrity of the - fragmentation-reassembly process. - - o SCHC gateway: It corresponds to the LoRaWAN Application Server. It manages - translation between IPv6 network and the Network Gateway (LoRaWAN Network - Server). - - o Uplink: LoRaWAN term for a message transmitted by the device and received - by the network. +- DevEUI: an IEEE EUI-64 identifier used to identify the device during the + procedure while joining the network (Join Procedure). It is assigned by the + manufacturer or the device owner and provisioned on the Network Gateway. +- DevAddr: a 32-bit non-unique identifier assigned to a device wether: + + - Statically: by the device manufacturer in *Activation by Personalization* + mode. + - Dynamically: after a Join Procedure by the Network Gateway in *Over The + Air Activation* mode. + +- Downlink: LoRaWAN term for a message transmitted by the network and + received by the device. +- OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI. +- RCS: Reassembly Check Sequence. Used to verify the integrity of the + fragmentation-reassembly process. +- SCHC gateway: It corresponds to the LoRaWAN Application Server. It manages + translation between IPv6 network and the Network Gateway (LoRaWAN Network + Server). +- Uplink: LoRaWAN term for a message transmitted by the device and received + by the network. # Static Context Header Compression Overview From 834b1800a9c80750d1f5461ad63a9067618a1d7a Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 19:06:58 +0200 Subject: [PATCH 12/17] Introduce sections 4.3 and 4.4 --- draft-ietf-lpwan-schc-over-lorawan.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 0e9ba01..abfd854 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -289,9 +289,11 @@ direction and reciprocally on the downlink direction. ## General Frame Types -* LoRaWAN Confirmed message: +LoRaWAN implements the possibility to send confirmed or unconfirmed messages: + +* Confirmed message: The sender asks the receiver to acknowledge the message. -* LoRaWAN Unconfirmed message: +* 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 @@ -299,6 +301,9 @@ LoRaWAN Confirmed messages. ## LoRaWAN MAC Frames +In addition to regular data frames LoRaWAN implements JoinRequest and JoinAccept +frame types, used by a device to join a network: + * JoinRequest: 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 From a6de0cd000a28d95e6a55027fd8b6c5424de4fbc Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 19:12:12 +0200 Subject: [PATCH 13/17] Move FPort definition --- draft-ietf-lpwan-schc-over-lorawan.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index abfd854..12d193b 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -318,9 +318,16 @@ frame types, used by a device to join a network: MAC and application data. Application data are protected with AES-128 encryption, MAC related data are AES-128 encrypted with another key. +## LoRaWAN FPort + +The LoRaWAN MAC layer features a frame port field in all frames. This field +(FPort) is 8 bits long and the values from 1 to 223 can be used. It allows +LoRaWAN networks and applications to identify data. + ## LoRaWAN empty frame {#lorawan-empty-frame} -A LoRaWAN empty frame is a LoRaWAN message without FPort and FRMPayload. +A LoRaWAN empty frame is a LoRaWAN message without FPort (cf {{lorawan-schc-payload}}) +and FRMPayload. ## Unicast and multicast technology @@ -341,11 +348,7 @@ reception window. # SCHC-over-LoRaWAN -## LoRaWAN FPort {#lorawan-schc-payload} - -The LoRaWAN MAC layer features a frame port field in all frames. This field -(FPort) is 8 bits long and the values from 1 to 223 can be used. It allows -LoRaWAN networks and applications to identify data. +## LoRaWAN FPort and RuleID {#lorawan-schc-payload} The FPort field is part of the SCHC Message, as shown in {{Fig-lorawan-schc-payload}}. The SCHC C/D and the SCHC F/R SHALL concatenate From 0f1f194b512814809812c88783d1e8aebe16240f Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 19:14:00 +0200 Subject: [PATCH 14/17] Exanf IDD before first use --- 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 12d193b..c57e228 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -410,7 +410,7 @@ least the parameters defined in this document. The mechanism for sharing those RuleID values is outside the scope of this document. -## IID computation {#IID} +## Interface IDentifier (IID) computation {#IID} In order to mitigate risks described in [rfc8064] and [rfc8065] IID MUST be created regarding the following algorithm: From 4db521ac3d03f5ec94c059ffad9c2606cc11ad32 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 4 Sep 2020 19:14:53 +0200 Subject: [PATCH 15/17] Fix typos --- 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 c57e228..1916325 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -733,7 +733,7 @@ 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 +All fragments 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, the SCHC layer should immediately queue for transmission @@ -918,7 +918,7 @@ fragment. Content of the tile is: | RuleID | Compression residue | Payload | + ------ + ------------------- + ----------------- + -| 1 | 21 bits | 6 byte + 3 bits | +| 1 | 21 bits | 6 bytes + 3 bits | ~~~~ {: #Fig-example-uplink-fragmentation-lorawan-packet-1-tile-content title='Uplink example: LoRaWAN packet 1 - Tile content'} From 94558b6b3551115d35e28635be38063ccd36f143 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Mon, 7 Sep 2020 17:47:23 +0200 Subject: [PATCH 16/17] Express SCHC F/R as C/D in Section 3 --- draft-ietf-lpwan-schc-over-lorawan.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lpwan-schc-over-lorawan.md b/draft-ietf-lpwan-schc-over-lorawan.md index 1916325..5dce469 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -152,7 +152,8 @@ Context exchange or pre-provisioning is out of scope of this document. based on {{RFC8376}} terminology. The device is sending applications flows 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 +size and fragmented by the SCHC Fragmentation/Reassembly (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 reassembly, if required, then to SCHC C/D for decompression. The SCHC C/D shares the same rules with the From de5458d21920f870e5fe8716bf615c6df548c585 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 11 Sep 2020 07:40:16 +0200 Subject: [PATCH 17/17] Fix 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 5dce469..69b96ee 100644 --- a/draft-ietf-lpwan-schc-over-lorawan.md +++ b/draft-ietf-lpwan-schc-over-lorawan.md @@ -97,7 +97,7 @@ all other definitions, please look up the SCHC specification - DevEUI: an IEEE EUI-64 identifier used to identify the device during the procedure while joining the network (Join Procedure). It is assigned by the manufacturer or the device owner and provisioned on the Network Gateway. -- DevAddr: a 32-bit non-unique identifier assigned to a device wether: +- DevAddr: a 32-bit non-unique identifier assigned to a device either: - Statically: by the device manufacturer in *Activation by Personalization* mode.