From 535e82f823321614fccd74c073ab884758711de3 Mon Sep 17 00:00:00 2001 From: Oliv4945 Date: Fri, 2 Apr 2021 18:14:41 +0200 Subject: [PATCH] Add 2nd revision from RFC editors --- rfc9011.xml | 494 +++++++--------------------------------------------- 1 file changed, 61 insertions(+), 433 deletions(-) diff --git a/rfc9011.xml b/rfc9011.xml index 22a1488..3c6d6a7 100644 --- a/rfc9011.xml +++ b/rfc9011.xml @@ -1,15 +1,15 @@ - + - + - Static Context Header Compression and fragementation (SCHC) over LoRaWAN + Static Context Header Compression and Fragementation (SCHC) over LoRaWAN Semtech @@ -37,13 +37,6 @@ lpwan Working Group - - header compression compression fragmentation @@ -75,27 +68,6 @@ Author (OGZ) designed for great flexibility so that it can be adapted for any of the LPWAN technologies. - This document specifies a profile of RFC 8724 to use SCHC in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation. @@ -174,21 +146,7 @@ provisioned on the Network Gateway. - -
Downlink: @@ -283,6 +243,9 @@ sectionFormat="of" section="8.2.2.1" format="default"/>. SCHC Compressor/Decompressor is called SCHC Compression/Decompression in RFC 8704 Moreover changing it to SCHC "Compression/Decompression" is be more consistent with "SCHC Fragmentation/Reassembly" + +ask for AD approval - probably okay + -->
  1. Compression mechanisms to avoid transporting information known by both sender and receiver over the @@ -299,13 +262,11 @@ Moreover changing it to SCHC "Compression/Decompression" is be more consistent w In a LoRaWAN network, the RGW is called a "Gateway", the NGW is a "Network Server", and the SCHC C/D and SCHC F/R are one or more - "Application Server". Application servers can be provided by the NGW or any third-party + "Application Servers". + + Application servers can be provided by the NGW or any third-party software. can be mapped in LoRaWAN terminology to: -
    SCHC Architecture Mapped to LoRaWAN -
  2. The RGW is the endpoint of the constrained link. This entity maps to the LoRaWAN Gateway.
    3. @@ -423,20 +360,6 @@ the LoRaWAN Network Server.
  3. The SCHC C/D and SCHC F/R are handled by the LoRaWAN Application Server.
    4. -
  4. The LPWAN-AAA Server is the LoRaWAN Join Server. Its role is to manage and deliver security keys in a secure way so that the devices root key is never @@ -473,20 +396,6 @@ exposed.
    Device Classes (A, B, C) and Interactions - The LoRaWAN Medium Access Control (MAC) layer supports three classes of devices named A, B, and C. All devices implement Class A, and some devices may implement Class B or Class C. Class B and Class C @@ -506,34 +415,39 @@ opportunity. Class A is the lowest power consumption class.
    Class B:
    -
    Class B devices implement all the functionalities of Class A devices but +
    Class B devices implement all the functionalities of Class A devices but also schedule periodic listen windows. Therefore, as opposed to Class A devices, Class B devices can receive downlinks that are initiated by 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: -
    +consumption of the device:     + + +
    +
    High periodicity:
    -
    Downlinks from the NGW will be sent faster but the -device wakes up more often and power consumption is increased.
    +
    Downlinks from the NGW will be sent faster but the device wakes up more +often and power consumption is increased.
    Low periodicity:
    -
    Higher latency but lower power consumption.
    +
    Downlinks from the NGW will have higher latency but lower power consumption.
    +
    -
    Class C: @@ -583,7 +509,6 @@ Class C devices are grid powered (for example, Smart Plugs). | Device | <=====> | Network | <====> | SCHC | <======> | Internet | | | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | | +--------+ +---------+ +---------+ +----------+ - ]]>
    5. @@ -604,22 +529,7 @@ Class C devices are grid powered (for example, Smart Plugs). - As SCHC defines its own acknowledgment mechanisms, SCHC does not require the use of LoRaWAN Confirmed frames (FType = 0b100 as per ). @@ -666,49 +576,10 @@ LoRaWAN networks and applications to identify data. target="lorawan-schc-payload" format="default"/>) and FRMPayload. - - - - -
    Unicast and Multicast Technology LoRaWAN technology supports unicast downlinks but also multicast; a - multical packet sent over a LoRaWAN radio link can be received by several + multicast packet sent over a LoRaWAN radio link can be received by several devices. It is useful to address many devices with the same content: either a large binary file (firmware upgrade) or the same command (e.g., lighting control). As IPv6 is also a multicast technology, this @@ -741,7 +612,6 @@ the FPort field with the LoRaWAN payload to recompose the SCHC Message. | FPort | LoRaWAN payload | + ------------------------ + | SCHC Message | - ]]> @@ -752,22 +622,7 @@ other way, a fragmented datagram with application payload transferred from Network Gateway to device is called a "downlink-fragmented datagram". It uses another FPort for data downlink and its associated SCHC control uplinks, named "FPortDown" in this document. - All RuleIDs can use arbitrary values inside the FPort range allowed by the LoRaWAN specification [LORA-SPEC] and MUST be shared by the device and SCHC gateway prior to the communication with the selected @@ -780,22 +635,6 @@ Author (OGZ) FPort as described in . - LoRaWAN supports up to 223 application FPorts in @@ -811,17 +650,7 @@ Author (OGZ)
  5. RuleID = 22 (8-bit) for which SCHC compression was not possible (i.e., no matching compression Rule was found), as described in .
    6. - The FPortUp value MUST be different from the FPortDown value. The remaining RuleIDs are available for compression. RuleIDs are shared @@ -856,31 +685,10 @@ implementations MUST implement the following algorithm and The aes128_cmac algorithm is described in . It has been chosen as it is already used by devices for the LoRaWAN protocol. - - - - + As AppSKey is renewed each time a device joins or rejoins a LoRaWAN network, the IID will change over time; this - mitigates privacy concerns, for example location tracking or correlation + mitigates privacy concerns, for example, location tracking or correlation over time. Join periodicity is defined at the application level. Address-scan risk is mitigated thanks to AES-128, which provides enough entropy in the IID. @@ -903,6 +711,8 @@ Address-scan risk is mitigated thanks to AES-128, which provides There is a small probability of IID collision in a LoRaWAN network. If this occurs, the IID can be changed by rekeying the device @@ -1198,16 +1008,17 @@ Bitmaps of 63 bits will require 6 bits of padding.
    Multicast downlinks:
    No-ACK; reliability has to be ensured by the upper layer. This feature is OPTIONAL for the SCHC gateway and REQUIRED for the device. @@ -1285,23 +1096,24 @@ be changed by the application. session is started; this is application specific and can be disabled. The RECOMMENDED uplink is a LoRaWAN empty frame as defined in . As this uplink is send only to open an RX window, any + format="default"/>. As this uplink is sent only to open an RX window, any LoRaWAN uplink frame from the device MAY reset this counter.
    Downlink Retransmission Timer - - Class A, Class B, and Class C devices do not manage retransmissions and timers the same way. @@ -1418,43 +1216,34 @@ Author (OGZ) MUST transmit up to MAX_ACK_REQUESTS SCHC ACK messages before aborting. In order to progress the fragmented datagram, the SCHC layer should immediately queue for - transmission those SCHC ACK messages if no SCHC downlinks have been + transmission those SCHC ACK messages if no SCHC downlink has been received during the RX1 and RX2 windows. The LoRaWAN layer will respect the applicable local spectrum regulation. - - SCHC All-1 (FCN = 1) - + + SCHC All-1 (FCN = 1) + SCHC All-1 is the last fragment of a datagram, and the corresponding SCHC ACK message might be lost; therefore, the SCHC @@ -1582,20 +1371,6 @@ LoRaWAN session (i.e., each join or rejoin to the LoRaWAN network). - LoRaWAN Remote Multicast Setup Specification v1.0.0 @@ -1635,25 +1410,6 @@ Author (OGZ) need for fragmentation. The payload will be transmitted through FPort = 1. -
    Uplink Example: LoRaWAN Packet
    The current LoRaWAN MTU is 51 bytes; no FOpts are used by the LoRaWAN protocol: 51 bytes are available for SCHC payload + FPort - field; The applicative data has to be fragmented. + field; the applicative data has to be fragmented. -
    Downlink Example: LoRaWAN Packet 1 - SCHC Fragment 1 @@ -1809,122 +1546,13 @@ Author (OGZ) - - -