lpwan Working Group A. Minaburo Internet-Draft Acklio Intended status: Standards Track L. Toutain Expires:December 31, 2018April 25, 2019 IMT-Atlantique C. Gomez Universitat Politecnica de Catalunya D. Barthel Orange LabsJune 29,JC. Zuniga SIGFOX October 22, 2018 LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDPdraft-ietf-lpwan-ipv6-static-context-hc-16draft-ietf-lpwan-ipv6-static-context-hc-17 Abstract This document defines the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities. SCHC has beentailoreddesigned for Low Power Wide Area Networks (LPWAN). SCHC compression is based on a common static context stored in both the LPWANdevicesdevice and the network side. This document defines a header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed thelayer twolayer-2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used.Note that thisThis document defines generic functionalities andadvisedlyoffers flexibility with regard to parameter settings and mechanism choices.SuchTechnology-specific and product-specific settings and choices are expected to bemadegrouped into Profiles specified in othertechnology-specificdocuments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onDecember 31, 2018.April 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . .98 5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10 5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 11 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . .1312 7.Static Context Header CompressionCompression/Decompression . . . . . . . . . . . . . . . . .13. 12 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . .1412 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . .1614 7.3. Packet processing . . . . . . . . . . . . . . . . . . . .1615 7.4. Matching operators . . . . . . . . . . . . . . . . . . .1816 7.5. Compression Decompression Actions (CDA) . . . . . . . . .1817 7.5.1. processing variable-length fields . . . . . . . . . . 17 7.5.2. not-sent CDA . . . . . . . . . . . . . . . . . . . .20 7.5.2.18 7.5.3. value-sent CDA . . . . . . . . . . . . . . . . . . .20 7.5.3.18 7.5.4. mapping-sent CDA . . . . . . . . . . . . . . . . . .20 7.5.4.18 7.5.5. LSB CDA . . . . . . . . . . . . . . . . . . . . . . .20 7.5.5.19 7.5.6. DevIID, AppIID CDA . . . . . . . . . . . . . . . . .21 7.5.6.19 7.5.7. Compute-* . . . . . . . . . . . . . . . . . . . . . .2119 8.FragmentationFragmentation/Reassembly . . . . . . . . . . . . . . . . . . 20 8.1. Overview . . . . . . . . . .21 8.1. Overview. . . . . . . . . . . . . . 20 8.2. SCHC F/R Tools . . . . . . . . . .21 8.2. Fragmentation Tools. . . . . . . . . . . 20 8.2.1. Messages . . . . . . . .22 8.3. Reliability modes. . . . . . . . . . . . . . 20 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . .25 8.4. Fragmentation Formats21 8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 23 8.2.4. Header Fields . . . . . .27 8.4.1. Fragments that are not the last one. . . . . . . . .27 8.4.2. All-1 fragment. . . . . 24 8.3. SCHC F/R Message Formats . . . . . . . . . . . . . .29 8.4.3.. . 26 8.3.1. SCHCACKFragment format . . . . . . . . . . . . . . . . 26 8.3.2. SCHC ACK format . . .31 8.4.4. Abort formats. . . . . . . . . . . . . . . . 27 8.3.3. SCHC ACK REQ format . . . .33 8.5. Baseline mechanism. . . . . . . . . . . . . 30 8.3.4. SCHC Abort formats . . . . . .35 8.5.1. No-ACK. . . . . . . . . . . 31 8.4. SCHC F/R modes . . . . . . . . . . . .36 8.5.2. ACK-Always. . . . . . . . . 33 8.4.1. No-ACK mode . . . . . . . . . . . .36 8.5.3. ACK-on-Error. . . . . . . . . 33 8.4.2. ACK-Always . . . . . . . . . . .39 8.6. Supporting multiple window sizes. . . . . . . . . . 36 8.4.3. ACK-on-Error . . . . . . .40 8.7. Downlink SCHC Fragment transmission. . . . . . . . . . .41. . 42 9. Padding management . . . . . . . . . . . . . . . . . . . . .4249 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . .4350 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . .4350 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . .4351 10.3. Flow label field . . . . . . . . . . . . . . . . . . . .4451 10.4. Payload Length field . . . . . . . . . . . . . . . . . .4451 10.5. Next Header field . . . . . . . . . . . . . . . . . . .4452 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . .4552 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . .4552 10.7.1. IPv6 source and destination prefixes . . . . . . . .4552 10.7.2. IPv6 source and destination IID . . . . . . . . . .4653 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . .4653 10.9. UDP source and destination port . . . . . . . . . . . .4653 10.10. UDP length field . . . . . . . . . . . . . . . . . . . .4754 10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . .4754 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .4855 12. Security considerations . . . . . . . . . . . . . . . . . . .4855 12.1. Security considerations for SCHC Compression/Decompression . . . . . . . . . . . . . . .4855 12.2. Security considerations for SCHC Fragmentation/Reassembly . . . . . . . . . . . . . . . .4855 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .4956 14. References . . . . . . . . . . . . . . . . . . . . . . . . .5057 14.1. Normative References . . . . . . . . . . . . . . . . . .5057 14.2. Informative References . . . . . . . . . . . . . . . . .5057 Appendix A. SCHC Compression Examples . . . . . . . . . . . . .5158 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . .5461 Appendix C. Fragmentation State Machines . . . . . . . . . . . .6068 Appendix D. SCHC Parameters- Ticket #15. . . . . . . . . . . .67. . . . . . 75 Appendix E. Supporting multiple window sizes for fragmentation . 77 Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 77 Appendix G. Note . . . . . . . . . . . . . . . . . . . . . . . .6878 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .6978 1. Introduction This document defines the Static Context Header Compression (SCHC) framework, which provides both header compression and fragmentation functionalities. SCHC has beentailoreddesigned for Low Power Wide Area Networks (LPWAN). Header compression is neededto efficiently bringfor efficient Internet connectivity to the node within an LPWAN network. Some LPWAN networks properties can be exploited to get an efficient header compression: o The network topology is star-oriented, which means that all packets between the same source-destination pair follow the same path. For the needs of this document, the architecture can simply be described as Devices (Dev) exchanging information with LPWAN Application Servers (App) through a NetworkGatewaysGateway (NGW). o Because devices embed built-in applications, the traffic flows to be compressed are known in advance. Indeed, new applicationscannot be easilyare less frequently installed in an LPWANdevices,device, as theywouldare incomputersa computer orsmartphones. The Static Context Header Compression (SCHC) is defined for this environment.smartphone. SCHC compression uses acontext,context in which information about headerfiedsfields is stored. This context is static: the values of the header fields do not change over time. This avoids complex resynchronizationmechanisms,mechanisms. Indeed, downlink is often more restricted/expensive, perhaps completely unavailable [RFC8376]. A compression protocol thatwould be incompatiblerelies on feedback is not compatible withLPWAN characteristics.the characteristics of such LPWANs. In most cases, a small context identifier is enough to represent the full IPv6/UDP headers. The SCHC header compression mechanism is independent of the specific LPWAN technology over which it is used. LPWAN technologies impose some strict limitations on traffic. For instance, devices are sleeping most of the time andMAYmay receive data during short periods of time after transmission to preserve battery. LPWAN technologies are alsocharacterized, among others,characterized by averygreatly reduced data unit and/or payload size (see [RFC8376]). However, someof theseLPWAN technologies do not provide fragmentationfunctionality, therefore the only option for themfunctionality; to support the IPv6 MTU requirement of 1280 bytes[RFC8200] is to use[RFC8200], they require a fragmentation protocol at the adaptationlayer,layer below IPv6.In response to this need,Accordingly, this documentalsodefinesaan fragmentation/reassemblymechanism, whichmechanism for LPWAN technologies to supports the IPv6MTU requirement over LPWAN technologies. Such functionality has been designed under the assumption that thereMTU. Its implementation isno out-of-sequence delivery of data units between the entity performing fragmentation andoptional. If not interested, theentity performing reassembly. Note that thisreader can safely skip its description. This document defines generic functionality andpurposefullyoffers flexibility with regard toparameterparameters settings and mechanism choices.SuchTechnology-specific settings and product-specific and choices are expected to bemadegrouped into Profiles specified inother, technology-specificother documents. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. LPWAN Architecture LPWAN technologies have similar network architectures but different terminologies. Using the terminology defined in [RFC8376], we can identify different types of entities in a typical LPWAN network, see Figure 1: o Devices (Dev) are the end-devices or hosts (e.g. sensors, actuators, etc.). There can be a very high density of devices per radio gateway. o The Radio Gateway (RGW), which is the end point of the constrained link. o The Network Gateway (NGW) is the interconnection node between the Radio Gateway and the Internet. o LPWAN-AAA Server, which controls the user authentication and the applications. o Application Server (App) +------+ () () () | |LPWAN-| () () () () / \ +---------+ | AAA | () () () () () () / \======| ^ |===|Server| +-----------+ () () () | | <--|--> | +------+ |APPLICATION| () () () () / \==========| v |=============| (App) | () () () / \ +---------+ +-----------+ Dev Radio Gateways NGW Figure 1: LPWAN Architecture 4. Terminology This section defines the terminology and acronyms used in this document. Note that the SCHC acronym is pronounced like "sheek" in English (or "chic" in French). Therefore, this document writes "a SCHC Packet" instead of "an SCHC Packet". oAbort. A SCHC Fragment format to signal the other end-point that the on-going fragment transmission is stopped and finished. o All-0. The SCHC Fragment format for the last fragment of a window that is not the last one of a SCHC Packet (see window in this glossary). o All-1. The SCHC Fragment format for the last fragment of the SCHC Packet. o All-0 empty. An All-0 SCHC Fragment without payload. It is used to request the SCHC ACK with the encoded Bitmap when the Retransmission Timer expires, in a window that is not the last one of a packet. o All-1 empty. An All-1 SCHC Fragment without payload. It is used to request the SCHC ACK with the encoded Bitmap when the Retransmission Timer expires in the last window of a packet. oApp: LPWAN Application. An application sending/receiving IPv6 packets to/from the Device. o AppIID: Application Interface Identifier. The IID that identifies the application server interface. o Bi: Bidirectional. Characterises aRule EntryField Descriptor that applies to headers of packets travelling in either direction (Up and Dw, see this glossary). oBitmap: a bit field in the SCHC ACK message that tells the sender which SCHC Fragments in a window of fragments were correctly received. o C: Checked bit. Used in an acknowledgement (SCHC ACK) header to determine if the MIC locally computed by the receiver matches (1) the received MIC or not (0). oCDA: Compression/Decompression Action. Describes the reciprocal pair of actions that are performed at the compressor to compress a header field and at the decompressor to recover the original header field value. o Compression Residue. The bits that need to be sent (beyond the Rule ID itself) after applying the SCHC compression over each header field. o Context: A set of Rules used to compress/decompress headers. o Dev: Device. A node connected to an LPWAN. A Dev SHOULD implement SCHC. o DevIID: Device Interface Identifier. The IID that identifies the Dev interface. o DI: Direction Indicator. This field tells which direction of packet travel (Up, Dw or Bi) a Rule applies to. This allows for assymmetric processing. oDTag: Datagram Tag. This SCHC F/R header field is set to the same value for all SCHC Fragments carrying the same SCHC Packet. oDw: Downlink direction for compression/decompression in both sides, from SCHC C/D in the network to SCHC C/D in the Dev. oFCN: Fragment Compressed Number. This SCHC F/R header field carries an efficient representation of a larger-sized fragment number. oField Description. A line in the Rule table. o FID: Field Identifier. This is an index to describe the header fields in a Rule. o FL: Field Length is the length of the packet header field. It is expressed in bits for header fields of fixed lengths or as a type (e.g. variable, token length, ...) for field lengths that are unknown at the time of Rule creation. The length of a header field is defined in the corresponding protocolspecification.specification (such as IPv6 or UDP). o FP: Field Position is a value that is used to identify the position where each instance of a field appears in the header. o IID: Interface Identifier. See the IPv6 addressing architecture [RFC7136] oInactivity Timer. A timer used after receiving a SCHC Fragment to detect when, due to a communication error, there is no possibility to continue an on-going fragmented SCHC Packet transmission. oL2: Layer two. The immediate lower layer SCHC interfaces with. It is provided by an underlying LPWAN technology. It does not necessarily correspond to the OSI model definition of Layer 2. o L2 Word: this is the minimum subdivision of payload data that the L2 will carry. In most L2 technologies, the L2 Word is an octet. In bit-oriented radio technologies, the L2 Word might be a single bit. The L2 Word size is assumed to be constant over time for each device. oMIC: Message Integrity Check. A SCHC F/R header field computed over the fragmented SCHC Packet and potential fragment padding, used for error detection after SCHC Packet reassembly. oMO: Matching Operator. An operator used to match a value contained in a header field with a value contained in a Rule. o Padding (P). Extra bits that may be appended by SCHC to a data unit that it passes to the underlying Layer 2 for transmission. SCHC itself operates on bits, not bytes, and does not have any alignment prerequisite. See Section 9. oRetransmission Timer. A timer used by the SCHC Fragment sender during an on-going fragmentedProfile: SCHCPacket transmission to detect possible link errors when waiting foroffers variations in the way it is operated, with a number of parameters listed in Appendix D. A Profile indicates a particular setting of all these parameters. Both ends of apossible incomingSCHCACK.session must be provisioned with the same Profile information and with the same set of Rules before the session starts, so that there is no ambiguity in how they expect to communicate. o Rule: A set of header field values. o Ruleentry: A column in a Rule that describes a parameter of the header field. o RuleID: An identifier for a Rule. SCHC C/D on both sides share the same Rule ID for a given packet. A set of Rule IDs are used to support SCHC F/R functionality. o SCHCACK: A SCHC acknowledgement for fragmentation. This message is used to report on the success of reception of a set of SCHC Fragments. See Section 8 for more details. o SCHCC/D: Static Context Header Compression Compressor/ Decompressor. A mechanism used on both sides, at the Dev and at the network, to achieve Compression/Decompression of headers. SCHC C/D uses Rules to perform compression and decompression. o SCHCF/R: Static Context Header Compression Fragmentation/ Reassembly. A protocol used on both sides, at the Dev and at the network, to achieve Fragmentation/Reassembly of SCHC Packets. SCHC F/R has three reliability modes. o SCHC Fragment: A data unit that carries a subset of a SCHC Packet. SCHC F/R is needed when the size of a SCHC packet exceeds the available payload size of the underlying L2 technology data unit. See Section 8. o SCHCPacket: A packet (e.g. an IPv6 packet) whose header has been compressed as per the header compression mechanism defined in this document. If the header compression process is unable to actually compress the packet header, the packet with the uncompressed header is still called a SCHC Packet (in this case, a Rule ID is used to indicate that the packet header has not been compressed). See Section 7 for more details. o TV: Target value. A value contained in a Rule that will be matched with the value of a header field. o Up: Uplink direction for compression/decompression in both sides, from the Dev SCHC C/D to the network SCHC C/D.o W: Window bit. A SCHC Fragment header field used in ACK-on-Error or ACK-Always mode Section 8, which carries the same valueAdditional terminology forall SCHC Fragments of a window. o Window: A subset ofthe optional SCHCFragments needed to carry a SCHC Packet (seeFragmentation / Reassembly mechanism (SCHC F/R) is found in Section8).8.2. 5. SCHC overview SCHC can beabstractedcharacterized as an adaptation layer between IPv6 and the underlying LPWAN technology. SCHC comprises two sublayers (i.e. the Compression sublayer and the Fragmentation sublayer), as shown in Figure 2. +----------------+ | IPv6 | +- +----------------+ | | Compression | SCHC < +----------------+ | | Fragmentation | +- +----------------+ |LPWAN technology| +----------------+ Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN technology As per this document, when a packet (e.g. an IPv6 packet) needs to be transmitted, header compression is first applied to the packet. The resulting packet after header compression (whose header may or may not actually be smaller than that of the original packet) is called a SCHC Packet. If the SCHC Packetsize exceedsneeds to be fragmented by thelayer 2 (L2) MTU,optional SCHC Fragmentation, fragmentation is then applied to the SCHC Packet. The SCHC Packet or the SCHC Fragments are then transmitted over the LPWAN. The reciprocal operations take place at the receiver. This process is illustrated in Figure 3. A packet (e.g. an IPv6 packet) | ^ v | +------------------+ +--------------------+ | SCHC Compression | | SCHC Decompression | +------------------+ +--------------------+ | ^ | If no fragmentation (*) | +-------------- SCHC Packet -------------->| | | v | +--------------------+ +-----------------+ | SCHC Fragmentation | | SCHC Reassembly | +--------------------+ +-----------------+ | ^ | ^ | | | | | +-------------- SCHC ACK -------------+ | | | +-------------- SCHC Fragments -------------------+ SENDER RECEIVER *: the decision to use Fragmentation or not is left to eachLPWAN technology over which SCHC is applied. See LPWAN technology-specific documents.Profile. Figure 3: SCHC operationstaking placeat thesenderSENDER and thereceiverRECEIVER 5.1. SCHC Packet format The SCHC Packet is composed of the Compressed Header followed by the payload from the original packet (see Figure 4). The Compressed Header itself is composed ofathe Rule ID and a CompressionResidue.Residue, which is the output of the compression actions of the Rule that was applied (see Section 7). The Compression Residue may beabsent, see Section 7.empty. Both the Rule ID and the Compression Residue potentially have a variable size, and generally are not a mutiple of bytes in size. | Rule ID + Compression Residue | +---------------------------------+--------------------+ | Compressed Header | Payload | +---------------------------------+--------------------+ Figure 4: SCHC PacketThe Fragment Header size is variable and depends on the Fragmentation parameters. The Fragment payload contains a part of the SCHC Packet Compressed Header, a part of the SCHC Packet Payload or both. Its size depends on the L2 data unit, see Section 8. The SCHC Fragment has the following format: | Rule ID + DTAG + W + FCN [+ MIC ] | Partial SCHC Packet | +-----------------------------------+-------------------------+ | Fragment Header | Fragment Payload | +-----------------------------------+-------------------------+ Figure 5: SCHC Fragment The SCHC ACK is only used for Fragmentation. It has the following format: |Rule ID + DTag + W| +------------------+-------- ... ---------+ | ACK Header | encoded Bitmap | +------------------+-------- ... ---------+ Figure 6: SCHC ACK The SCHC ACK Header and the encoded Bitmap both have variable size.5.2. Functional mapping Figure75 below maps the functional elements of Figure 3 onto the LPWAN architecture elements of Figure 1. Dev App +----------------+ +--------------+ | APP1 APP2 APP3 | |APP1 APP2 APP3| | | | | | UDP | | UDP | | IPv6 | | IPv6 | | | | | |SCHC C/D and F/R| | | +--------+-------+ +-------+------+ | +--+ +----+ +-----------+ . +~~ |RG| === |NGW | === | SCHC |... Internet .. +--+ +----+ |F/R and C/D| +-----------+ Figure7:5: Architecture SCHC C/D and SCHC F/R are located on both sides of the LPWAN transmission, i.e. on the Dev side and on the Network side.Let's describe theThe operation in the Uplinkdirection.direction is as follows. The Device applicationpackets useuses IPv6 or IPv6/UDP protocols. Before sendingthesethe packets, the Dev compresses their headers using SCHC C/D and, if the SCHC Packet resulting from the compressionexceeds the maximum payload size of the underlying LPWAN technology,needs to be fragmented by SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC Fragments are sentas one or more L2 framesto an LPWAN Radio Gateway (RG) which forwards them to a Network Gateway (NGW). The NGW sends the data to a SCHCF/ RF/R for re-assembly (if needed) and then to the SCHC C/D for decompression. After decompression, the packet can be sent over the Internet to one or several LPWAN Application Servers (App). The SCHC F/R and C/D on the Network side can be located in theNGWNGW, or somewhere else as long as a tunnel is established between them and the NGW. Note that, for some LPWAN technologies, it MAY be suitable to locate the SCHCF/ RF/R functionality nearer the NGW, in order to better deal with time constraints of such technologies. The SCHC C/D and F/R on both sides MUST share the same set of Rules.After decompression, the packet can be sent over the Internet to one or several LPWAN Application Servers (App).The SCHC C/D and F/R process is symmetrical, therefore the description of the Downlink directiontrivially derives fromis symmetrical to the one above. 6. Rule ID Rule IDs are identifiers used to select the correct context either for Compression/Decompression or for Fragmentation/Reassembly. The size of the Rule IDs is not specified in this document, as it is implementation-specific and can vary according to the LPWAN technology and the number of Rules, among others. It is defined in Profiles. The Rule IDs are used: o In the SCHC C/D context, to identify the Rule (i.e., the set of Field Descriptions) that is used to compress a packet header. o At least one Rule ID MAY be allocated to tagging packets for which SCHC compression was not possible (no matching Rule was found). o In SCHC F/R, to identify the specific modes and settings of SCHC Fragments being transmitted, and to identify theSCKSCHC ACKs, including their modes and settings. Note thatin the case of bidirectional communication,when F/R is used for both communication directions, at least two Rule ID values are therefore needed for F/R. 7.Static Context Header Compression In order to perform header compression, this document defines a mechanism called Static Context HeaderCompression/Decompression Compression(SCHC), whichwith SCHC is based on using context, i.e. a set of Rules to compress or decompress headers. SCHC avoids context synchronization, whichis the most bandwidth-consuming operationconsumes considerable bandwidth in other header compression mechanisms such as RoHC [RFC5795]. Since thenaturecontent of packets is highly predictable in LPWAN networks, static contexts MAY be stored beforehand to omit transmitting some information over the air. The contexts MUST be stored at both ends, and they can be learned by a provisioning protocol or by out of band means, or they can bepre- provisioned.pre-provisioned. The way the contexts are provisionedon both endsis out of the scope of this document. 7.1. SCHC C/D Rules The main idea of the SCHC compression scheme is to transmit the Rule ID to the other end instead of sending known field values. This Rule ID identifies a Rule that provides the closest match to the original packet values. Hence, when a value is known by both ends, it is only necessary to send the corresponding Rule ID over the LPWAN network.HowThe manner by which Rules are generated is out of the scope of this document. The Rules MAY be changed at run-time but theway to domechanism is out of scope of thiswill be specified in anotherdocument. The context contains a list of Rules(cf.(see Figure8).6). Each Rule itself contains a list of Field Descriptions composed of a Field Identifier (FID), a Field Length (FL), a Field Position (FP), a Direction Indicator (DI), a Target Value (TV), a Matching Operator (MO) and a Compression/Decompression Action (CDA). /-----------------------------------------------------------------\ | Rule N | /-----------------------------------------------------------------\| | Rule i || /-----------------------------------------------------------------\|| | (FID) Rule 1 ||| |+-------+--+--+--+------------+-----------------+---------------+||| ||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| |+-------+--+--+--+------------+-----------------+---------------+||| ||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||| |+-------+--+--+--+------------+-----------------+---------------+||| ||... |..|..|..| ... | ... | ... |||| |+-------+--+--+--+------------+-----------------+---------------+||/ ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||| |+-------+--+--+--+------------+-----------------+---------------+|/ | | \-----------------------------------------------------------------/ Figure8:6: A Compression/Decompression Context A Rule does not describe how to parse a packet header to find each field. This MUST be known from the compressor/decompressor. Rules only describe the compression/decompression behavior for each header field. In a Rule, the Field Descriptions are listed in the order in which the fields appear in the packet header. A Rule also describes whatCompression Residueissent.sent in the Compression Residue. The Compression Residue is assembled by concatenating the residues for each field, in the order the Field Descriptions appear in the Rule. The Context describes the header fields and its values with the following entries: o Field ID (FID) is a unique value to define the header field. o Field Length (FL) represents the length of the field. It can be either a fixed value (in bits) if the length is known when the Rule is created or a type if the length is variable. The length of a header field is defined in the corresponding protocol specification. The type defines the process to compute the length, its unit (bits, bytes,...) and the value to be sent before the Compression Residue. o Field Position (FP): most often, a field only occurs once in a packet header. Some fields may occur multiple times in a header. FP indicates which occurrence this Field Description applies to. The default value is 1 (first occurence). o A Direction Indicator (DI) indicates the packet direction(s) this Field Description applies to. Three values are possible: * UPLINK (Up): this Field Description is only applicable to packets sent by the Dev to the App, * DOWNLINK (Dw): this Field Description is only applicable to packets sent from the App to the Dev, * BIDIRECTIONAL (Bi): this Field Description is applicable to packets travelling both Up and Dw. o Target Value (TV) is the value used tomake thematchwithagainst the packet header field. The Target Value can be of any type (integer, strings, etc.).For instance, itIt can be a single value or a more complex structure (array, list, etc.), such as a JSON or a CBOR structure. o Matching Operator (MO) is the operator used to match the Field Value and the Target Value. The Matching Operator may require some parameters. MO is only used during the compression phase. The set of MOs defined in this document can be found in Section 7.4. o Compression Decompression Action (CDA) describes the compression and decompression processes to be performed after the MO is applied. Some CDAs MAY require parameter values for their operation. CDAs are used in both the compression and the decompression functions. The set of CDAs defined in this document can be found in Section 7.5. 7.2. Rule ID for SCHC C/D Rule IDs are sent by the compression function in one side and are received for the decompression function in the other side. In SCHC C/D, the Rule IDs are specific to a Dev. Hence, multiple Dev instances MAY use the same Rule ID to define different header compression contexts. To identify the correct Rule ID, the SCHC C/D needs tocorrelateassociate the Rule ID with the Dev identifier to find the appropriate Rule to be applied. 7.3. Packet processing The compression/decompression process follows several steps: o Compression Rule selection: The goal is to identify which Rule(s) will be used to compress the packet's headers. Whendoingperforming decompression, on the network side the SCHC C/D needs to find the correct Rule based on the L2address andaddress; in this way, it can use the DevIID and the Rule ID. On the Dev side, only the Rule ID is needed to identify the correct Rule since the Dev typically only holds Rules that apply to itself. The Rule will be selected by matching the Fields Descriptions to the packet header as described below. When the selection of a Rule is done, this Rule is used to compress the header. The detailed steps for compression Rule selection are the following: * The first step is to choose the Field Descriptions by their direction, using the Direction Indicator (DI). A Field Description that does not correspond to the appropriate DI will be ignored. If all the fields of the packet do not have a Field Description with the correct DI, the Rule is discarded and SCHC C/D proceeds toexploreconsider the next Rule. * When the DI has matched, then the next step is to identify the fields according to Field Position (FP). If FP does not correspond, the Rule is not used and the SCHC C/D proceeds to consider the next Rule. * Once the DI and the FP correspond to the header information, each packet field's value is then compared to the corresponding Target Value (TV) stored in the Rule for that specific field using the matching operator (MO). If all the fields in the packet's header satisfy all the matching operators (MO) of a Rule (i.e. all MO results are True), the fields of the header are then compressed according to the Compression/Decompression Actions (CDAs) and a compressed header (with possibly a Compression Residue) SHOULD be obtained. Otherwise, the next Rule is tested. * If no eligible compression Rule is found, then the header MUST be sent withoutcompression. This MAYcompression, using a Rule ID dedicated to this purpose. Sending the header uncompressed but may require the use of the SCHC F/R process. o Sending:If an eligible Rule is found, theThe Rule ID is sent to the other end followed by the Compression Residue (which could be empty) or the uncompressed header, and directly followed by the payload. The Compression Residue is the concatenation of the Compression Residues for each field according to the CDAs for that Rule. The way the Rule ID is sent depends on thespecific underlying LPWAN technology.Profile. For example, it can be either included in an L2 header or sent in the first byte of the L2 payload.(Cf.(see Figure9).4). This process will be specified in theLPWAN technology-specific documentProfile and is out of the scope of the present document. On LPWAN technologies that are byte-oriented, the compressed header concatenated with the original packet payload is padded to a multiple of 8 bits, if needed. See Section 9 for details. o Decompression: When doing decompression, on the network side the SCHC C/D needs to find the correct Rule based on the L2 address and in this way, it can use the DevIID and the Rule ID. On the Dev side, only the Rule ID is needed to identify the correct Rule since the Dev only holds Rules that apply to itself. The receiver identifies the sender through its device-id or source identifier (e.g. MAC address, if it exists) and selects theappropriate Rule from theRuleID. If a source identifier is present in the L2 technology, it is used to selectusing the Rule ID. This Rule describes the compressed header format and associates thevaluesreceived Compression Residue to each of the header fields.TheFor each field in the header, the receiver applies the CDA action associated to that field in order to reconstruct the original headerfields.field value. The CDA application order can be different from the ordergiven byin which the fields are listed in the Rule.For instance,In particular, Compute-*SHOULDMUST be appliedat the end,after the application of the CDAs of all theother CDAs. +--- ... --+------- ... -------+------------------+ | Rule ID |Compression Residue| packet payload | +--- ... --+------- ... -------+------------------+ |----- compressed header ------| Figure 9: SCHC C/D Packet Formatfields it computes on. 7.4. Matching operators Matching Operators (MOs) are functions used by both SCHC C/D endpoints involved in the header compression/decompression. They are not typed and can beindifferentlyapplied to integer, string or any other data type. The result of the operation can either be True or False. MOs are defined as follows: o equal: The match result is True ifathe field value ina packet andthevalue inpacket matches theTV are equal.TV. o ignore: No check is done betweenathe field value inathe packet andathe TV in the Rule. The result of the matching is always true. o MSB(x): A match is obtained if the most significant x bits of the packet header field value are equal to the TV in the Rule. The x parameter of the MSB MO indicates how many bits are involved in the comparison. If the FL is described as variable, the length must be a multiple of the unit. For example, x must be multiple of 8 if the unit of the variable length is in bytes. o match-mapping: With match-mapping, the Target Value is a list of values. Each value of the list is identified by a short ID (or index). Compression is achieved by sending the index instead of the original header field value. This operator matches if the header field value is equal to one of the values in the target list. 7.5. Compression Decompression Actions (CDA) The Compression Decompression Action (CDA) describes the actions taken during the compression of headers fields, and inversely, the action taken by the decompressor to restore the original value. /--------------------+-------------+----------------------------\ | Action | Compression | Decompression | | | | | +--------------------+-------------+----------------------------+ |not-sent |elided |use value stored in context | |value-sent |send |build from received value | |mapping-sent |send index |value from index on a table | |LSB |send LSB |TV, received value | |compute-length |elided |compute length | |compute-checksum |elided |compute UDP checksum | |DevIID |elided |build IID from L2 Dev addr | |AppIID |elided |build IID from L2 App addr | \--------------------+-------------+----------------------------/ Figure10:7: Compression and Decompression Actions Figure107 summarizes the basicfunctionsactions that can be used to compress and decompress a field. The first columnlistsshows theactionsaction's name. The second and third columnsoutlineshow the reciprocal compression/ decompression behavior for each action. Compression is done in the order thatFieldsthe Field Descriptions appear in a Rule. The result of each Compression/Decompression Action is appended to theworkingaccumulated Compression Residue in that same order. The receiver knows the size of each compressedfieldfield, which can be given by the Rule or MAY be sent with the compressed header. 7.5.1. processing variable-length fields If the field is identifiedas being variablein the FieldDescription,Description as being of variable size, then the size of the Compression Residue value (using the unit defined in the FL) MUST first be sentfirst using the following coding:as follows: o If the size is between 0 and 14, it is sent as a 4-bits unsigned integer. o For values between 15 and 254,the first 4 bits sent are set to 10b1111 is transmitted and then the size is sentusingas an 8 bits unsigned integer. o Forhigherlarger values ofsize,thefirst 12 bits are set to 1size, 0xfff is transmitted and then the next two bytes contain the size value as a 16 bits unsigned integer. If a field is not present in the packet but exists in the Rule and its FL is specified as being variable, size 0 MUST be sent to denote its absence.7.5.1.7.5.2. not-sent CDA The not-sentfunctionaction is generally used when the field value is specified in a Rule and therefore known by both the Compressor and the Decompressor. This actionis generallySHOULD be used with the "equal" MO. If MO is "ignore", there is a risk to have a decompressed field value different from the original field that was compressed. The compressor does not send any Compression Residue for a field on which not-sent compression is applied. The decompressor restores the field value with the Target Value stored in the matched Rule identified by the received Rule ID.7.5.2.7.5.3. value-sent CDA The value-sent action is generally used when the field value is not known by both the Compressor and the Decompressor. The value is sent as a residue in the compressed message header. Both Compressor and Decompressor MUST know the size of the field, either implicitly (the size is known by both sides) or by explicitly indicating the length in the Compression Residue, as defined in Section7.5.7.5.1. Thisfunctionaction is generally used with the "ignore" MO.7.5.3.7.5.4. mapping-sent CDA The mapping-sent action is used to senda smalleran index (the index into the Target Value list of values) instead of the original value. Thisfunctionaction is used together with the "match-mapping" MO. On the compressor side, the match-mapping Matching Operator searches the TV for a match with the header field value and the mapping-sent CDA appends the corresponding index to the Compression Residue to be sent. On the decompressor side, the CDA uses the received index to restore the field value by looking up the list in the TV. The number of bits sent is the minimal size for coding all the possible indices.7.5.4.7.5.5. LSB CDA The LSB action is used together with the "MSB(x)" MO to avoid sending the most significant part of the packet field if that part is already known by the receiving end. The number of bits sent is the original header field length minus the length specified in the MSB(x) MO. The compressor sends the Least Significant Bits (e.g. LSB of the length field). The decompressor concatenates the x most significant bits of Target Value and the received residue. If this action needs to be done on a variable length field, the size of the Compression Residue in bytes MUST be sent as described in Section7.5. 7.5.5.7.5.1. 7.5.6. DevIID, AppIID CDA Thesefunctionsactions are used to process respectively the Dev and the App Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. AppIID CDA is less common since most current LPWAN technologies frames contain a single L2 address, which is the Dev's address. The IID value MAY be computed from the Device ID present in the L2 header, or from some other stable identifier. The computation is specific to eachLPWAN technologyProfile and MAY depend on the Device ID size. In the downlink direction (Dw), at the compressor,thisthe DevIID CDA may be used to generate the L2 addresses on the LPWAN, based on thepacket destination address. 7.5.6.packet's Destination Address. 7.5.7. Compute-* Some fieldsaremay be elided during compression and reconstructed during decompression. This is the case for length and checksum, so: o compute-length: computes the length assigned to this field. This CDA MAY be used to compute IPv6 length or UDP length. o compute-checksum: computes a checksum from the information already received by the SCHC C/D. This field MAY be used to compute UDP checksum. 8.FragmentationFragmentation/Reassembly 8.1. Overview In LPWAN technologies, the L2data unit sizeMTU typicallyvariesranges from tens to hundreds of bytes.The SCHC F/R (Fragmentation /Reassembly) MAY be used either because after applying SCHC C/D or when SCHC C/D isSome of these technologies do notpossible the entire SCHC Packet still exceeds the L2 data unit.have an internal fragmentation/reassembly mechanism. The SCHCF/RFragmentation/Reassembly (SCHC F/R) functionalitydefined in this document has been designed under the assumption that data unit out-of-sequence delivery will not happen between the entity performing fragmentation and the entity performing reassembly. This assumption allows reducing the complexity and overhead of the SCHC F/R mechanism. This document also assumes that the L2 data unit size does not vary while a fragmented SCHC Packetisbeing transmitted. To adapt the SCHC F/Roffered as an option for such LPWAN technologies to cope with thecapabilitiesIPv6 MTU requirement ofLPWAN technologies, it1280 bytes [RFC8200]. It isrequired to enableoptionalSCHC Fragment retransmission andto implement. If it is not needed, its description can be safely ignored. This specification includes several SCHC F/R modes, which allow for a range of reliability options such as optional SCHC Fragment retransmission. More modes may be defined in the future. The same SCHC F/R mode MUST be used forsendingall SCHC Fragments of the same fragmented SCHCFragments.Packet. This document does not make any decision with regard to whichSCHC Fragment delivery reliability modemode(s) will be used over a specific LPWAN technology.These detailsThis will be defined inother technology-specific documents.Profiles. SCHC F/R uses the knowledge of the L2 Word size (see Section 4) to encode some messages. Therefore, SCHC MUST know the L2 Word size. SCHC F/R usually generates SCHC Fragments and SCHC ACKs thatare, for most of them,are multiples of L2 Words. The padding overhead is kept to the absoluteminimum. Seeminimum (see Section9.9). 8.2.FragmentationSCHC F/R Tools This subsection describes the different tools that are used to enable the SCHC F/R functionality defined in thisdocument, such as fields indocument. These tools include the SCHC F/Rheader frames (see the related formats in Section 8.4), windows and timers. o Rule ID. The Rule ID is present in the SCHC Fragment headermessages, tiles, windows, counters, timers andin the SCHC ACKheaderformats.fields. TheRule IDtools are described here in a generic manner. Their application to each SCHCFragment headerF/R mode is found in Section 8.4. 8.2.1. Messages The messages that can be usedto identifyby SCHC F/R are the following: o SCHC Fragment: A data unit that carries a piece of a SCHCFragment is being carried, whichPacket from the sender to the receiver. o SCHCF/R reliability modeACK: An acknowledgement for fragmentation, by the receiver to the sender. This message is usedand which window size is used. The Rule ID into report on the successful reception of pieces of, or the whole of the fragmented SCHCFragment header also allows interleaving non-fragmented SCHC Packets and SCHC Fragments that carry otherPacket. o SCHCPackets. The Rule ID inACK REQ: An explicit request for a SCHCACK identifiesACK. By the sender to the receiver. o SCHC Sender-Abort: A messageasby the sender telling the receiver that it has aborted the transmission of a fragmented SCHCACK.Packet. oFragment Compressed Number (FCN). The FCN is included in allSCHCFragments. This field can be understood as a truncated, efficient representationReceiver-Abort: A message by the receiver to tell the sender to abort the transmission of alarger-sized fragment number, and does not carryfragmented SCHC Packet. 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters 8.2.2.1. Tiles The SCHC Packet is fragmented into pieces, hereafter called tiles. The tiles MUST be contiguous. See Figure 8 for anabsoluteexample. SCHC Packet +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ Tiles | | | | | | | | | | | | | | +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+ Figure 8: a SCHC Packet fragmented in tiles Each SCHC Fragmentnumber. There are two FCN reserved values that are used for controllingmessage carries at least one tile in its Payload, if the Payload field is present. 8.2.2.2. Windows Some SCHC F/Rprocess, as described next: * The FCN value withmodes may handle successive tiles in groups, called windows. If windows are used o all thebits equal to 1 (All-1) denotes the last SCHC Fragmentwindows of apacket. TheSCHC Packet, except the lastwindowone, MUST contain the same number ofa packettiles. This number iscalled an All-1 window. * The FCN value with allWINDOW_SIZE. o WINDOW_SIZE MUST be specified in a Profile. o thebits equal towindows are numbered. o their numbers MUST increase from 0(All-0) denotesupward, from thelast SCHC Fragmentstart ofa window that is notthelast one ofSCHC Packet to its end. o thepacket. Such alast windowis called an All-0 window. The rest of the FCN valuesMUST contain WINDOW_SIZE tiles or less. o tiles areassigned in a sequentially decreasing order, which hasnumbered within each window. o thepurpose to avoid possible ambiguity fortile numbers MUST decrement from WINDOW_SIZE - 1 downward, looking from thereceiver that might arise under certain conditions. Instart of the SCHCFragments, this fieldPacket toward its end. o each tile of a SCHC Packet is therefore uniquely identified by a window number and a tile number within this window. See Figure 9 for anunsigned integer, withexample. +---------------------------------------------...-------------+ | SCHC Packet | +---------------------------------------------...-------------+ Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 | Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -| Figure 9: asizeSCHC Packet fragmented in tiles grouped in 28 windows, with WINDOW_SIZE = 5 When windows are used o information on the correct reception ofN bits. IntheNo-ACK mode,tiles belonging to thesizesame window MUST be grouped together. o it isset to 1 bit (N=1), All-0RECOMMENDED that this information isusedkept inall SCHC Fragments and All-1 forBitmaps. o Bitmaps MAY be sent back to thelast one. Forsender in a SCHC ACK message. o Each window has a Bitmap. 8.2.2.3. Bitmaps Each bit in theother reliability modes, it is recommended to useBitmap for anumber of bits (N) equalwindow corresponds toor greater than 3. Nevertheless, the appropriate value of N MUST be defineda tile in thecorresponding technology-specific profile documents. Forwindow. Each Bitmap has therefore WINDOW_SIZE bits. The bit at the left-most position corresponds to the tile numbered WINDOW_SIZE - 1. Consecutive bits, going right, correspond to sequentially decreasing tile numbers. In Bitmaps for windows that are not the last one of afragmentedSCHC Packet, theFCN for the last SCHC Fragment in such windows is an All-0. This indicates thatbit at thewindow is finished and communication proceeds accordingright-most position corresponds to thereliability mode in use. The FCN fortile numbered 0. In thelast SCHC Fragment inBitmap for the lastwindow is an All-1, indicatingwindow, thelast SCHC Fragment ofbit at theSCHC Packet. It is also importantright-most position corresponds either tonote that, intheNo-ACK modetile numbered 0 orwhen N=1, theto a tile that is sent/received as "the lastSCHC Fragmentone of thepacket will carry a FCN equal to 1, while all previousSCHCFragments will carry a FCN to 0. For further details seePacket" without explicitely stating its number (see Section8.5. The highest FCN in8.3.1.2). At thewindow, denoted MAX_WIND_FCN, MUST bereceiver o avalue equal to or smaller than 2^N-2. (Example for N=5, MAX_WIND_FCN MAY bebit set to23, then subsequent FCNs are set sequentially and1 indecreasing order, andtheFCN will wrap from 0 back to 23).Bitmap indicates that a tile associated with that bit position has been correctly received for that window. oDatagram Tag (DTag). The DTag field, if present, isa bit set to 0 in thesame value for all SCHC Fragments carrying the same SCHC packet, and to different valuesBitmap indicates that no tile associated with that bit position has been correctly received fordifferent SCHC Packets. Using this field, the sender can interleave fragments from different SCHC Packets, while the receiver can still tell them apart. In the SCHC Fragment formats,that window. WINDOW_SIZE finely controls the size of theDTag field is T bits, which MAY be set to a value greater than or equal to 0 bits. For each new SCHC Packet processed byBitmap sent in thesender, DTag MUSTSCHC ACK message, which may besequentially increased, from 0 to 2^T - 1 wrapping back from 2^T - 1critical to0. In thesome LPWAN technologies. 8.2.2.4. Timers and counters Some SCHCACK format, DTag carries the same value as the DTag field inF/R modes can use theSCHC Fragments for whichfollowing timers and counters o Inactivity Timer: thisSCHC ACK is intended. When there is no Dtag, theretimer can beonly one SCHC Packet in transit. Only after all its fragments have been transmitted can anotherused to unlock a SCHCPacket be sent. The length of DTag, denoted T,Fragment receiver that is notspecified in this document becausereceiving a SCHC F/R message while it istechnology dependant. It willexpecting one. o Retransmission Timer: this timer can bedefined in the corresponding technology-specific documents, based on the number of simultaneous packets that areused by a SCHC Fragment sender tobe supported. o W (window): W isset a1-bit field. This field carriestimeout on expecting a SCHC ACK. o Attempts: this counter counts thesame valuerequests forallSCHCFragments of a window, and itACKs. MAX_ACK_REQUESTS iscomplemented forthenext window. The initial value for this fieldthreshold at which an exception is0. In the SCHC ACK format, this field also has a size of 1 bit. In all SCHC ACKs, the W bit carries the same value as the W bit carried by theraised. 8.2.3. Integrity Checking The reassembled SCHCFragments whose receptionPacket isbeing positively or negatively acknowledged bychecked for integrity at theSCHC ACK. o Messagereceive end. IntegrityCheck (MIC). This fieldchecking iscomputedperformed by computing a MIC at the senderover the complete SCHC Packetside andbefore SCHC fragmentation. The MIC allows the receivertransmitting it tocheck errors inthereassembled packet, while it also enables compressingreceiver for comparison with the locally computed MIC. The MIC supports UDP checksum elision byuse ofSCHCcompression.C/D (see Section 10.11). The CRC32aspolynomial 0xEDB88320 (i.e. the reverse representation of the polynomial used e.g. in the Ethernet standard [RFC3385]) isrecommendedRECOMMENDED as the default algorithm for computing the MIC. Nevertheless, other MIC lengths or other algorithms MAY be requiredand are defined inby thetechnology-specific documents as well asProfile. Note that thelength in bitsconcatenation of theMIC used. o C (MIC checked): C is a 1-bit field. This field is used in thecomplete SCHCACK packets to report the outcome of the MIC check, i.e. whetherPacket and thereassembled packet was correctly received or not. A valuepotential padding bits of1 represents a positive MIC check at the receiver side (i.e. the MIC computed by the receiver matchesthereceived MIC). o Retransmission Timer. Alast SCHC Fragmentsender uses it after the transmissiondoes not generally constitute an integer number ofa windowbytes. For implementers todetect a transmission errorbe able to use byte-oriented CRC libraries, it is RECOMMENDED that the concatenation of the complete SCHCACK corresponding to this window. Depending onPacket and thereliability mode, it will leadlast fragment potential padding bits be zero-extended toa request a SCHC ACK retransmission (in ACK-Always mode) or it will trigger the transmission ofthe nextwindow (in ACK-on-Error mode). The duration of this timer is not defined in this documentbyte boundary andMUST be defined inthat thecorresponding technology-specific documents. o Inactivity Timer.MIC be computed on that byte array. A Profile MAY specify another behaviour. 8.2.4. Header Fields The SCHCFragment receiver uses it to take action when thereF/R messages use the following fields (see the related formats in Section 8.3): o Rule ID: this field isa problempresent in all thetransmission ofSCHCfragments. Such a problem could be detected by the receiver not gettingF/R messages. It is used to identify * that asingleSCHCFragment during a given period of time. When this happens, an AbortF/R messagewill be sent (see related text later in this section). Initially, and each time ais being carried, as opposed to an unfragmented SCHCFragmentPacket, * which SCHC F/R mode isreceived,used * and among this mode + if windows are used and what thetimer is reinitialized. The durationvalue ofthis timer is not defined in this documentWINDOW_SIZE is, + what other optional fields are present andMUST be defined inwhat thecorresponding technology-specific document. o Attempts. This counter countsfield sizes are. Therefore, therequests for a missingRule ID allows SCHCACK. When it reaches the value MAX_ACK_REQUESTS, the sender assumes there are recurrentF/R interleaving non-fragmented SCHCFragment transmission errorsPackets anddeterminesSCHC Fragments thatan Abort is needed.carry other SCHC Packets, or interleaving SCHC Fragments that use different SCHC F/R modes or different parameters. o Datagram Tag (DTag). Thedefault value MAX_ACK_REQUESTSDTag field isnot stated in this document,optional. Its presence anditsize (called T, in bits) isexpected to bedefined by each Profile for each Rule ID. When there is no DTag, there can be only one fragmented SCHC Packet in transit for a given Rule ID. If present, DTag * MUST be set to thecorresponding technology-specific document. The Attemptssame value for all the SCHC F/R messages related to the same fragmented SCHC Packet, * MUST be set to different values for SCHC F/R messages related to different SCHC Packets that are being fragmented under the same Rule ID and that may overlap during the fragmented transmission. A sequence counter that isdefined per window. It is initializedincremented for eachtime anewwindowfragmented SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to 0 isused.RECOMMENDED for maximum traceability and replay avoidance. oBitmap.W: TheBitmapW field isa sequence of bits carriedoptional. It is only present if windows are used. Its presence and size (called M, inabits) is defined by each SCHCACK. Each bit in the Bitmap correspondsF/R mode and each Profile for each Rule ID. This field carries information pertaining to the window a SCHCfragment ofF/R message relates to. If present, W MUST carry thecurrent window, and provides feedback on whethersame value for all the SCHCFragment has been received or not. The right-most positionF/R messages related to the same window. Depending on theBitmap reports ifmode and Profile, W may carry theAll-0 or All-1 fragment has been receivedfull window number, ornot. Feedback onjust theSCHC fragment withleast significant bit or any other partial representation of thehighestwindow number. o Fragment Compressed Number (FCN). The FCNvaluefield isprovidedpresent in the SCHC Fragment Header. Its size (called N, in bits) is defined by each Profile for each Rule ID. This field conveys information about thebitprogress in theleft-most positionsequence ofthe Bitmap. In the Bitmap, a bit set to 1 indicates that thetiles being transmitted by SCHC Fragment messages. For example, it can contain a partial, efficient representation ofFCN corresponding to that bit position has been correctly sent and received.a larger-sized tile number. Thetext above describes the internal representationdescription of theBitmap. When inserted inexact use of the FCN field is left to each SCHCACKF/R mode. However, two values are reserved fortransmission fromspecial purposes. They help control thereceiver toSCHC F/R process: * The FCN value with all thesender,bits equal to 1 (called All-1) signals theBitmap is shortened for energy/ bandwidth optimisation, see more details in Section 8.4.3.1. o Abort. On expirationvery last tile of a SCHC Packet. By extension, if windows are used, theInactivity timer, or when Attempts reaches MAX_ACK_REQUESTS or upon occurrencelast window ofsome other error, the sender or the receiver may use the Abort. When the receiver needs to aborta packet is called theon-going fragmented SCHC Packet transmission, it sendsAll-1 window. * If windows are used, theReceiver-Abort format. WhenFCN value with all thesender needsbits equal toabort the transmission, it sends the Sender-Abort format. None of0 (called All-0) signals theAborts are acknowledged. 8.3. Reliability modes This specification defines three reliability modes: No-ACK, ACK- Always, and ACK-on-Error. ACK-Always and ACK-on-Error operate on windowslast tile ofSCHC Fragments. Aa windowof SCHC Fragmentsthat isa subset ofnot thefull setlast one of the SCHCFragments needed to carrypacket. By extension, such aSCHC Packet. o No-ACK. No-ACKwindow isthe simplest SCHC Fragment reliability mode.called an All-0 window. Thereceiver does not generate overhead in the formhighest value ofacknowledgements (ACKs). However, this mode does not enhance reliability beyondFCN (an unsigned integer) is called MAX_WIND_FCN. Since All-1 is reserved, MAX_WIND_FCN MUST be stricly less thatoffered by the underlying LPWAN technology. In the No-ACK mode,(2^N)-1. o Message Integrity Check (MIC). This field only appears in thereceiver MUST NOT issueAll-1 SCHCACKs. See further detailsFragments. Its size (called T, in bits) is defined by each Profile for each Rule ID. See Section8.5.1.8.2.3 for the MIC default size, default polynomials and details on its computation. oACK-Always. The ACK-Always mode provides flow control usingC (integrity Check): C is awindowing scheme.1-bit field. Thismodefield isalso able to handle long bursts of lost SCHC Fragments since detection of such events can be done beforeused in theend ofSCHC ACK message to report on the reassembled SCHC Packettransmission as long asintegrity check (see Section 8.2.3). A value of 1 tells that thewindow sizeintegrity check was performed and isshort enough. However, such benefit comes at the expensesuccessful. A value ofSCHC ACK use. In ACK-Always,0 tells that thereceiver sends a SCHC ACK afterintegrity check was not performed, or that is was awindow of SCHC Fragments has been received.failure. o Compressed Bitmap. TheSCHC ACKCompressed Bitmap is usedto inform the sender which SCHC Fragmentstogether with windows and Bitmaps (see Section 8.2.2.3). Its presence and size is defined for each F/R mode for each Rule ID. This field appears in thecurrent window have been well received. Upon aSCHC ACKreception,message to report on thesender retransmitsreceiver Bitmap (see Section 8.3.2.1). 8.3. SCHC F/R Message Formats This section defines thelostSCHCFragments. When aFragment formats, the SCHC ACKis lost and the sender has not received it by the expiration of the Retransmission Timer,format, thesender uses aSCHC ACKrequest by sendingREQ format and theAll-0 emptySCHC Abort formats. 8.3.1. SCHC Fragmentwhen it is not the last window and the All-1 empty Fragment when it is the last window. The maximum number of SCHC ACK requests is MAX_ACK_REQUESTS. If MAX_ACK_REQUESTS is reached, the transmission needs to be aborted. See further details in Section 8.5.2. o ACK-on-Error. The ACK-on-Error mode is suitable for links offering relatively low L2 data unit loss probability. In this mode, the SCHC Fragment receiver reduces the number of SCHC ACKs transmitted, which MAY be especially beneficial in asymmetric scenarios. The receiver transmits a SCHC ACK only after the complete window transmission and if at least one SCHC Fragment of this window has been lost. An exception to this behavior is in the last window, where the receiver MUST transmit a SCHC ACK, including the C bit set based on the MIC checked result, even if all the SCHC Fragments of the last window have been correctly received. The SCHC ACK gives the state of all the SCHC Fragments of the current window (received or lost). Upon a SCHC ACK reception, the sender retransmits any lost SCHC Fragments based on the SCHC ACK. If a SCHC ACK is not transmitted back by the receiver at the end of a window, the sender assumes that all SCHC Fragments have been correctly received. When a SCHC ACK is lost, the sender assumes that all SCHC Fragments covered by the lost SCHC ACK have been successfully delivered, so the sender continues transmitting the next window of SCHC Fragments. If the next SCHC Fragments received belong to the next window and it is still expecting fragments from the previous window, the receiver will abort the on-going fragmented packet transmission. See further details in Section 8.5.3. The same reliability mode MUST be used for all SCHC Fragments of a SCHC Packet. The decision on which reliability mode will be used and whether the same reliability mode applies to all SCHC Packets is an implementation problem and is out of the scope of this document. Note that the reliability mode choice is not necessarily tied to a particular characteristic of the underlying L2 LPWAN technology, e.g. the No-ACK mode MAY be used on top of an L2 LPWAN technology with symmetric characteristics for uplink and downlink. This document does not make any decision as to which SCHC Fragment reliability modes are relevant for a specific LPWAN technology. Examples of the different reliability modes described are provided in Appendix B. 8.4. Fragmentation Formats This section defines the SCHC Fragment format, including the All-0 and All-1 formats and their "empty" variations, the SCHC ACKformatand the Abort formats.A SCHC Fragment conforms to the general format shown in Figure11.10. It comprises a SCHC Fragment Header and a SCHC Fragment Payload.In addition, the last SCHC Fragment carries as many padding bits as needed to fill up an L2 Word.The SCHC Fragment Payload carriesa subset of the SCHC Packet. The SCHC Fragment is the data unit passed on to the L2 for transmission.one or several tile(s). +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ | Fragment Header | FragmentpayloadPayload | padding (as needed) +-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ Figure11:10: SCHC Fragment general format. Presence of a padding field is optional8.4.1.8.3.1.1. Regular SCHC Fragment The Regular SCHC Fragment format is shown in Figure 11. Regular SCHC Fragments are generally used to carry tiles that are not the last oneIn ACK-Always or ACK-on-Error,of a SCHCFragments except the last one SHALL conform to the detailed format defined in Figure 12. |----- Fragment Header -----| |-- T --|1|-- N --| +-- ... --+- ... -+-+- ... -+--------...-------+ | Rule ID |Packet. The DTag|W| FCN | Fragment payload | +-- ... --+- ... -+-+- ... -+--------...-------+ Figure 12: Fragment Detailed Format for Fragments except the Last One, ACK-Alwaysfield andACK-on-Error IntheNo-ACK mode,W field are optional. |--- SCHCFragments except the last one SHALL conform to the detailed format defined in Figure 13. |----Fragment Header ----| |-- T--|----|-M-|-- N --| +-- ... --+- ...-+--+---+- ...-+--------...-------+-+--------...-------+~~~~~~~~~~~~~~~~~~~~~ | Rule ID | DTag | W | FCN | FragmentpayloadPayload | padding (as needed) +-- ... --+- ...-+--+---+- ...-+--------...-------+-+--------...-------+~~~~~~~~~~~~~~~~~~~~~ Figure13: Fragment11: Detailed Header Format for Regular SCHC Fragmentsexcept the Last One, No-ACK modeThetotal size ofFCN field MUST NOT contain all bits set to 1. If thefragment header is not necessarily a multiplesize of theL2 Word size. To build the fragment payload,SCHCF/R MUST take fromFragment Payload does not nicely complement the SCHCPacketHeader size in anumber of bitsway thatmakeswould make the SCHC Fragmentan exacta multiple of the L2Words. As a consequence, noWord, then paddingbit is used for these fragments. 8.4.1.1. All-0 fragmentbits MUST be added. TheAll-0 format is used for sending the last SCHCFragment Payload of awindow that is not the last window of theSCHCPacket. |-----FragmentHeader -----| |-- T --|1|-- N --| +-- ... --+- ... -+-+- ... -+--------...-------+ | Rule ID | DTag |W| 0..0 | Fragment payload | +-- ... --+- ... -+-+- ... -+--------...-------+ Figure 14: All-0 fragment detailed format This is simplywith FCN == 0 (called aninstance of the format described in Figure 12. AnAll-0fragment payloadSCHC Fragment) MUST be at least the size of an L2 Word. The rationale isthat the All-0 empty fragment (see Section 8.4.1.2) needs to be distinguishable from the All-0 regular fragment,that, even in the presence ofpadding. 8.4.1.2. All-0 empty fragment The All-0 empty fragment ispadding, anexception to theAll-0fragment described above. It is used by a senderSCHC Fragment needs torequestbe distinguishable from theretransmission of aSCHC ACKby the receiver. It is only used in ACK-Always mode. |----- Fragment Header -----| |-- T --|1|-- N --| +-- ... --+- ... -+-+- ... -+~~~~~~~~~~~~~~~~~~~~~ | Rule ID | DTag |W| 0..0 | padding (as needed) (no payload) +-- ... --+- ... -+-+- ... -+~~~~~~~~~~~~~~~~~~~~~ Figure 15: All-0 empty fragment detailed format The size ofREQ message, which has theAll-0 fragmentsame headeris generally not a multiple of the L2 Word size. Therefore, an All-0 empty fragment generally needs padding bits. The padding bits are always less than an L2 Word. Since an All-0but has no payloadMUST be at least the size of an L2 Word, a receiver can distinguish an All-0 empty fragment from a regular All-0 fragment, even in the presence of padding. 8.4.2.(see Section 8.3.3). 8.3.1.2. All-1fragment In the No-ACK mode, the lastSCHC Fragmentof a SCHC Packet SHALL contain aThe All-1 SCHC Fragmentheader that conforms to the detailedformat is shown in Figure16. |---------- Fragment Header ----------| |-- T --|-N=1-| +---- ... ---+- ... -+-----+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ | Rule ID | DTag | 1 | MIC | payload | padding (as needed) +---- ... ---+- ... -+-----+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ Figure 16:12. The All-1 SCHC FragmentDetailed Format for the Last Fragment, No- ACK mode In ACK-Always or ACK-on-Error mode,is generally used to carry the very lastfragmenttile of a SCHC PacketSHALL containand aSCHC Fragment header that conforms toMIC, or a MIC only. The DTag field, thedetailed format shown in Figure 17. |----------W field and the Payload are optional. |-------- SCHC Fragment Header----------|-------| |-- T--|1|----|-M-|-- N --| +-- ... --+- ...-+-+--+---+- ...-+---+- ...--+---...---+~~~~~~~~~~~~~~~~~~~~~-+------...-----+~~~~~~~~~~~~~~~~~~ | Rule ID | DTag|W|| W | 11..1 | MIC |payloadFrag Payload |paddingpad. (as needed) +-- ... --+- ...-+-+--+---+- ...-+---+- ...--+---...---+~~~~~~~~~~~~~~~~~~~~~-+------...-----+~~~~~~~~~~~~~~~~~~ (FCN) Figure17: All-1 Fragment12: DetailedFormatformat for theLast Fragment, ACK- Always or ACK-on-Error The total size of theAll-1 SCHC Fragmentheader is generally not a multiple of the L2 Word size. The All-1 fragment beingIf thelast onesize of the SCHCPacket, SCHC F/R cannot freely chooseFragment Payload does not nicely complement thepayloadSCHC Header sizeto align the fragment to an L2 Word. Therefore, padding bits are generally appended to the All-1 fragment toin a way that would makeitthe SCHC Fragment a multiple of the L2Words in size. The MICWord, then padding bits MUST becomputed on the payload and the padding bits.added. Therationale is that the SCHC Reassembler needs to check the correctness of the reassembled SCHC packet but has no way of knowing where the payload ends. Indeed, the latter requires decompressing the SCHC Packet. AnAll-1fragment payloadSCHC Fragment message MUST beat least thedistinguishable by sizeof an L2 Word. The rationale is that the All-1 empty fragmentfrom a SCHC Sender-Abort message (see Section8.4.2.1) needs to be distinguishable from the All-1 fragment, even in the presence of padding. This may entail saving an L2 Word from the previous fragment payload to make the payload of this All-1 fragment big enough. The values for N, T and8.3.4.1) that has thelength of MIC are not specified in this document,same T, M andSHOULD be determined in other documents (e.g. technology-specific profile documents). The length ofN values. This is trivially achieved by having the MICMUST be at leastlarger than an L2Word size. The rationale is to be able to distinguish a Sender-Abort (see Section 8.4.4) from an All-1 Fragment, even inWord, or by having thepresence of padding. 8.4.2.1. All-1 empty fragment The All-1 empty fragment format isPayload larger than anAll-1 fragment format without a payload (see Figure 18). ItL2 Word. This isused by a fragment sender, in either ACK-Always or ACK-on-Error, to request a retransmission ofalso naturally achieved if the SCHCACK for the All-1 window. The size of the All-1 empty fragment headerSender-Abort Header isgenerally nota multiple oftheL2Word size. Therefore, an All-1 empty fragment generally needs padding bits.Words. 8.3.2. SCHC ACK format Thepadding bits are always less than an L2 Word. Since an All-1 payloadSCHC ACK message MUSTbe at leastobey thesize of an L2 Word, a receiver can distinguish an All-1 empty fragment from a regular All-1 fragment, evenformat shown in Figure 13. The DTag field, thepresence of padding. |---------- FragmentW field and the Compressed Bitmap field are optional. The Compressed Bitmap field can only be present in SCHC F/R modes that use windows. |---- SCHC ACK Header--------|----| |-- T--|1|-- N --| +----|-M-|1| +---- ... --+- ...-+-+- ... -+- ... -+~~~~~~~~~~~~~~~~~~~-+---+-+~~~~~~~~~~~~~~~~~~ | Rule ID | DTag|W| 1..1 | MIC| W |1| padding as needed(no payload) +--(success) +---- ... --+- ...-+-+- ... -+- ... -+~~~~~~~~~~~~~~~~~~~ Figure 18: All-1 for Retries format, also called All-1 empty 8.4.3. SCHC ACK format The format of a SCHC ACK that acknowledges a window that is not the last one (denoted as All-0 window) is shown in Figure 19. |-- T --|1|-+---+-+~~~~~~~~~~~~~~~~~~ +---- ... --+- ...-+-+-----+---+-+------ ...-----+------+~~~~~~~~~~~~~~~ | Rule ID | DTag|W|encoded| W |0|Compressed Bitmap|(no payload)pad. as needed (failure) +---- ... --+- ...-+-+-----+---+-+------ ...-----+------+~~~~~~~~~~~~~~~ C Figure19: ACK format for All-0 windows To acknowledge the last window13: Format ofa packet (denoted as All-1 window),the SCHC ACK message The SCHC ACK Header contains a C bit(i.e. MIC checked) following(see Section 8.2.4). If theWC bit is set to 1to indicate that the MIC(integrity checkcomputed by the receiver matches the MIC present insuccessful), no Bitmap is carried and padding bits MUST be appended as needed to fill up theAll-1 fragment.last L2 Word. If theMIC check fails, theC bit is set to 0 (integrity check not performed or failed) and if windows are used, o a representation of the Bitmap for theAll-1windowfollows. |-- T --|1|1| +---- ... --+- ... -+-+-+ | Rule ID | DTag |W|1| (MIC correct) +---- ... --+- ... -+-+-+ +---- ... --+- ... -+-+-+----- ... -----+ | Rule ID | DTag |W|0|encoded Bitmap |(MIC Incorrect) +---- ... --+- ... -+-+-+----- ... -----+ C Figure 20: Format of a SCHC ACK for All-1 windows The Rule ID and Dtag values inreferred to by theSCHC ACK messagesW field MUST follow the C bit o padding bits MUST beidenticalappended as needed to fill up theones used inlast L2 Word If theSCHC Fragments thatC bit is 1 or windows arebeing acknowledged. This allows matching the SCHC ACK and the corresponding SCHC Fragments. The Bitmap carries information on the reception of each fragment ofnot used, thewindowC bit MUST be followed by padding bits asdescribed in Section 8.2.needed to fill up the last L2 Word. SeeAppendix DSection 8.2.2.3 for adiscussion ondescription of thesizeBitmap. The representation of theBitmaps. InBitmap that is transmitted MUST be the compressed version specified in Section 8.3.2.1, in order to reduce theSCKSCHC ACKsize,message size. 8.3.2.1. Bitmap Compression For transmission, the Compressed Bitmapthat is actually transmitted is shortened ("encoded") as explainedinSection 8.4.3.1. 8.4.3.1. Bitmap Encoding Thethe SCHC ACKthat is transmittedmessage istruncateddefined byapplyingthe followingalgorithm: the longest contiguous sequence of bitsalgorithm (see Figure 14 for a follow-along example): o Build a temporary SCHC ACK message thatstartscontains the Header followed by the original Bitmap. o Positioning scissors at the end of the Bitmap, after its last bit. o While the bit on the left of the scissors is 1 and belongs to the Bitmap, keep moving left, then stop. When this is done, o While the scissors are not on an L2 Word boundary of the SCHCACK, whereACK message and there is a Bitmap bit on thebits of that sequence are all set to 1, are all partright of theBitmapscissors, keep moving right, then stop. o At this point, cut andfinish exactly atdrop off any bits to theendright of theBitmap, ifscissors When onesuch sequence exists, MUST NOTor more bits have effectively been dropped off as a result of the above algorithm, the SCHC ACK message is a multiple of L2 Words, no padding bits will betransmitted.appended. Because the SCHC Fragment sender knows theactual Bitmap size,size of the original Bitmap, it can reconstruct the original Bitmap from theshortened bitmap. When shortening effectively takes place,Compressed Bitmap received in theSCHCSCH ACKis a multiple of L2 Words, and padding MUST NOT be appended. When shortening does not happen, padding bits MUST be appended as needed to fill up the last L2 Word.message. Figure2114 shows an example where L2 Words are actually bytes and where the original Bitmap contains 17 bits, the last 15 of which are all set to 1.|--|---- SCHC ACK Header--|------------|-------- Bitmap --------| |-- T --|-M-|1| +---- ... --+- ... -+---+-+---------------------------------+ | Rule ID | DTag|W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|| W |0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1| +---- ... --+- ... -+---+-+---------------------------------+ C | next L2 Word boundary ->|next L2 Word | next L2 Word |Figure21: A non-encoded14: Tentative SCHC ACK message with Bitmap before compression Figure2215 shows that the last 14 bits are not sent. |---- SCHC ACK Header ----|CpBmp| |-- T--|1|--|-M-|1| +---- ... --+- ...-+-+-+-+-+-+---+-+-----+ | Rule ID | DTag|W|1|0|1|| W |0|1 0 1| +---- ... --+- ...-+-+-+-+-+-+---+-+-----+ C | next L2 Word boundary ->| Figure22: Optimized Bitmap format15: Actual SCHC ACK message with Compressed Bitmap, no padding Figure2316 shows an example of a SCHC ACK withFCNtile numbers ranging from 6 down to 0, where the Bitmap indicates that the second and thefifth SCHC Fragmentsfourth tile of the window have not been correctly received.6|---- SCHC ACK Header ----|--- Bitmap --| |-- T --|-M-|1|6 5 4 3 2 10 (*) |-- T --|1| +-----------+-------+-+-+-+-+-+-+-+-+0| (tile #) +-----------+-------+---+-+-------------+ | Rule ID | DTag|W|1|0|1|1|0|1|1|| W |0|1 0 1 0 1 1 1| with Original Bitmapbefore tx +-----------+-------+-+-+-+-+-+-+-+-++-----------+-------+---+-+-------------+ C next L2 Word boundary ->|<-- L2 Word -->|(*)=(FCN values) +-----------+-------+-+-+-+-+-+-+-+-+~~~++-----------+-------+---+-+-------------+~~~+ | Rule ID | DTag|W|1|0|1|1|0|1|1|Pad| Encoded Bitmap +-----------+-------+-+-+-+-+-+-+-+-+~~~+| W |0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK +-----------+-------+---+-+-------------+~~~+ C next L2 Word boundary ->|<-- L2 Word -->| Figure23:16: Example of aBitmap before transmission, and the transmitted one, for a window that is not the last oneSCHC ACK message, missing tiles, with padding Figure2417 shows an example of a SCHC ACK with FCN ranging from 6 down to 0, whereMICintegrity check has not been performed or has failedbutand the Bitmap indicates that there is no missing tile in that window. |---- SCHCFragment. |- Fragmentation Header-|6ACK Header ----|--- Bitmap --| |-- T --|-M-|1|6 5 4 3 2 17 (*) |-- T --|1|0| (tile #) +-----------+-------+---+-+-------------+ | Rule ID | DTag|W|0|1|1|1|1|1|1|1|| W |0|1 1 1 1 1 1 1| with Original Bitmapbefore tx+-----------+-------+---+-+-------------+ C next L2 Word boundary->|<-- L2 Word -->| C->| +---- ... --+- ...-+-+-+-+-+---+-+-+ | Rule ID | DTag|W|0|1| Encoded Bitmap| W |0|1| transmitted SCHC ACK +---- ... --+- ...-+-+-+-+-+---+-+-+ C next L2 Word boundary ->|(*) = (FCN values indicating the order)Figure24:17: Example of a SCHC ACK message, no missing tile, no padding 8.3.3. SCHC ACK REQ format The SCHC ACK REQ is used by a sender to explicitely request a SCHC ACK from theBitmapreceiver. Its format is described inACK-Always or ACK-on-Error forFigure 18. The DTag field and thelast window 8.4.4.W field are optional. |---- SCHC ACK REQ Header ----| |-- T --|-M-|-- N --| +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ | Rule ID | DTag | W | 0..0 | padding (as needed) (no payload) +-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ Figure 18: SCHC ACK REQ detailed format The size of the SCHC ACK REQ header is generally not a multiple of the L2 Word size. Therefore, a SCHC ACK REQ generally needs padding bits. Note that the SCHC ACK REQ has the same header as an All-0 SCHC Fragment (see Section 8.3.1.1) but it doesn't have a payload. A receiver can distinguish the former form the latter by the message length, even in the presence of padding. This is possible because o the padding bits are always stricly less than an L2 Word. o the size of an All-0 SCHC Fragment Payload is at least the size of an L2 Word, 8.3.4. SCHC Abort formats 8.3.4.1. SCHC Sender-Abort When a SCHC Fragment sender needs to abortthean on-going fragmented SCHC Packet transmission, it sends aSender-Abort.SCHC Sender-Abort message to the SCHC Fragment receiver. The SCHC Sender-Abort format(see Figure 25)isa variation of the All-1 fragment, with neither a MIC nor a payload. All-1 fragments contain at least a MIC.described in Figure 19. Theabsence ofDTag field and theMIC indicates a Sender-Abort. |---W field are optional. |---- Sender-Abort Header---| +-------| |-- T --|-M-|-- N --| +-- ...---+---+- ...-+-+-...-+~~~~~~~~~~~~~~~~~~~~~-+---+- ... -+~~~~~~~~~~~~~~~~~~~~~ | Rule ID | DTag|W| FCN| W | 11..1 | padding (as needed)+---+-- ... --+- ...---+--+---+- ...-+-+-...-+~~~~~~~~~~~~~~~~~~~~~-+~~~~~~~~~~~~~~~~~~~~~ Figure25:19: SCHC Sender-Abortformat. All FCN field bits in thisformatareIf the W field is present, o the fragment sender MUST set it to1all 1's. Other values are RESERVED. o the fragment receiver MUST check its value. If the value is different from all 1's, the message MUST be ignored. The size of the SCHC Sender-Abort header is generally not a multiple of the L2 Word size. Therefore, a SCHC Sender-Abort generally needs padding bits.SinceNote that the SCHC Sender-Abort has the same header as an All-1fragmentSCHC Fragment (see Section 8.3.1.2), but that it does not include a MICMUST be at least the size of an L2 Word,nor a payload. The receivercan distinguish a Sender-Abortdistinguishes the former froman All-1 fragment,the latter by the message length, even in the presence of padding. This is possible through different combinations o the size of the Sender-Abort Header may be made such that it is not padded o or the total size of the MIC and the Payload of an All-1 SCHC Fragment is at least the size of an L2 Word o or through other alignment and size combinations The SCHC Sender-Abort MUST NOT be acknowledged. 8.3.4.2. SCHC Receiver-Abort When a SCHC Fragment receiver needs to abortthean on-going fragmented SCHC Packet transmission, it transmits aReceiver-Abort. The Receiver-Abort format is a variation on theSCHCACK format, creating an exception in the encoded Bitmap algorithm. As shown in Figure 26, aReceiver-Abortis coded as a SCHC ACKmessagewith a shortened Bitmap set to 1 upto thefirst L2 Word boundary, followed by an extra L2 Word full of 1's. Such a message never occurs in a regular acknowledgement and is detected as a Receiver-Abort.SCHC Fragment sender. TheRule ID and Dtag values in the Receive-Abort message MUST be identical to the ones used in the fragments of theSCHCPacket the transmission of which is being aborted. AReceiver-Abort format isaligned to L2 Words, by design. Therefore, padding MUST NOT be appended. |-described in Figure 20. The DTag field and the W field are optional. |--- Receiver-Abort Header-|---| |--- T ---|-M-|1| +---- ... ----+-- ...--+-+-+-+-+-+-+-+-+-+-+-+-+--+---+-+-+-+-+-+-+-+-+-+-+-+-+ | Rule ID | DTag|W|| W |1| 1..1| 1..1 | +---- ... ----+-- ...--+-+-+-+-+-+-+-+-+-+-+-+-+--+---+-+-+-+-+-+-+-+-+-+-+-+-+ C next L2 Word boundary ->|<-- L2 Word -->| Figure26:20: SCHC Receiver-Abort formatNeitherIf theSender-Abort norW field is present, o theReceiver-Abort messagesfragment receiver MUST set it to all 1's. Other values areever acknowledged or retransmitted. Use cases forRESERVED. o theSender-Abort and Receiver-Abort messages are explained in Section 8.5 or Appendix C. 8.5. Baseline mechanismfragment sender MUST check its value. Ifafter applyingthe value is different from all 1's, the message MUST be ignored. Note that the SCHC Receiver-Abort has the same headercompression (or whenas a SCHCheader compression is not possible)ACK message. The bits that follow the SCHCPacketReceiver-Abort Header MUST be as follows o if the Header does notfit withinend at an L2 Word boundary, append bits set to 1 as needed to reach thepayload of a singlenext L2data unit,Word boundary o append exactly one more L2 Word with bits all set to 1's Such a bit pattern never occurs in a regular SCHC ACK. This is how the fragment sender recognizes a SCHCPacket SHALLReceiver-Abort. A SCHC Receiver-Abort is aligned to L2 Words, by design. Therefore, padding MUST NOT bebroken intoappended. The SCHCFragments and the fragments SHALLReceiver-Abort MUST NOT besent toacknowledged. 8.4. SCHC F/R modes This specification includes several SCHC F/R modes, which allow for o a range of reliability options, such as optional SCHC Fragment retransmission o support of different LPWAN characteristics, such as variable MTU. More modes may be defined in thefragment receiver.future. 8.4.1. No-ACK mode The No-ACK mode has been designed under the assumption that data unit out-of-sequence delivery does not occur between the entity performing fragmentation and the entity performing reassembly. This mode supports LPWAN technologies that have a variable MTU. In No-ACK mode, there is no feedback communication from the fragment receiverneedstoidentifythe fragment sender. The sender just transmits all the SCHC Fragmentsthat belongblindly. Padding is kept to agiven SCHC Packet. To this end,minimum: only thereceiver SHALL use: olast SCHC Fragment is padded as needed. Thesender's L2 source address (if present), otile sizes are not required to be uniform. Windows are not used. Thedestination's L2 address (if present), oRetransmission Timer is not used. The Attempts counter is not used. Each Profile MUST specify which RuleID, o DTag (if present). Then, the fragment receiver MAY determine the SCHC Fragment reliability mode thatID value(s) isused for(are) allocated to thisSCHC Fragment based onmode. For brevity, the rest of Section 8.4.1 only refers to Rule IDinvalues thatfragment. After a SCHC Fragment reception, the receiver starts constructingare allocated to this mode. The W field MUST NOT be present in the SCHCPacket. It usesF/R messages. SCHC ACK MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort MAY be sent. SCHC Receiver-Abort MUST NOT be sent. The value of N (size of the FCNand the arrival order of each SCHC Fragmentfield) is RECOMMENDED todeterminebe 1. Each Profile, for each Rule ID value, MUST define o thelocationpresence or absence of theindividual fragments withinDTag field in the SCHCPacket. For example,F/R messages, as well as its size if it is present, o thereceiver MAY placesize and algorithm for thefragment payload within a payload reassembly buffer atMIC field in thelocation determinedSCHC F/R messages, if different from theFCN,default, o thearrival orderexpiration time of theSCHC Fragments, and the fragment payload sizes. In ACK-on-Error or ACK-Always, the fragment receiver also usesInactivity Timer Each Profile, for each Rule ID value, MAY define o a value of N different from theW bitrecommend one, o what values will be sent in thereceived SCHC Fragments. Note thatFCN field, for values different from thesizeAll-1 value. The receiver, for each pair of Rule ID and optional DTag values, MUST maintain o one Inactivity Timer 8.4.1.1. Sender behaviour At the beginning of theoriginal, unfragmented packet cannot be determined fromfragmentationheaders. Fragmentation functionality usesof a new SCHC Packet, theFCNfragment sender MUST select a Rule ID and optional DTag valueto transmit thepair for this SCHCFragments. It has a lengthPacket. For brevity, the rest ofN bits whereSection 8.4.1 only refers to SCHC F/R messages bearing theAll-1Rule ID andAll-0 FCNoptional DTag valuesare used to control the fragmentation transmission.hereby selected. Each SCHC Fragment MUST contain exactly one tile in its Payload. Therest of the FCN numberstile MUST beassigned sequentially in a decreasing order,at least thefirst FCNsize ofa window is RECOMMENDED to be MAX_WIND_FCN, i.e.an L2 Word. The sender MUST transmit thehighest possible FCN value depending onSCHC Fragments messages in theFCN number of bits. In all modes,order that the tiles appear in thelastSCHCFragmentPacket. Except for the last tile of apacketSCHC Packet, each tile MUSTcontainbe of aMIC whichsize that complements the SCHC Fragment Header so that the SCHC Fragment isused to check if there are errors or missinga multiple of L2 Words without the need for padding bits. Except for the last one, the SCHC FragmentsandMUST use thecorresponding All-1 fragment format. Note that aRegular SCHC Fragmentwith an All-0formatis considered thespecified in Section 8.3.1.1. The last SCHC Fragmentof the current window. IfMUST use thereceiver receivesAll-1 format specified in Section 8.3.1.2. The MIC MUST be computed on thelast fragment of areassembled SCHC Packet(All-1), it checks forconcatenated with theintegritypadding bits of thereassembledlast SCHCPacket, based onFragment. The rationale is that theMIC received. In No-ACK, ifSCHC Reassembler has no way of knowing where theintegrity check indicates thatpayload of thereassembledlast SCHCPacket does not matchFragment ends. Indeed, this requires decompressing theoriginalSCHCPacket (prior to fragmentation),Packet, which is out of the scope of thereassembledSCHCPacket MUST be discarded. In ACK-on-Error or ACK-Always,Reassembler. The sender MAY transmit aMIC check is also performed bySCHC Sender-Abort. Figure 35 shows an example of a corresponding state machine. 8.4.1.2. Receiver behaviour On receiving Regular SCHC Fragments, o thefragmentreceiverafter receptionMUST reset the Inactivity Timer, o the receiver assembles the payloads ofeach subsequentthe SCHCFragment retransmitted afterFragments On receiving an All-1 SCHC Fragment, o thefirst MIC check. Notice thatreceiver MUST append the All-1 SCHCACK forFragment Payload and theAll-1 window carries one more bit (the C bit) comparedpadding bits to the previously received SCHCACKsFragment Payloads for this SCHC Packet o if an integrity checking is specified in theprevious windows. See Appendix D for a discussion on various options to dealProfile, * the receiver MUST perform the integrity check * if integrity checking fails, the receiver MUST drop the reassembled SCHC Packet and it MUST release all resources associated with this"bump" inRule ID and optional DTag values. o the reassembly operation concludes. On expiration of the Inactivity Timer, the receiver MUST drop the SCHCACK. There are three reliability modes: No-ACK, ACK-AlwaysPacket being reassembled andACK-on- Error. In ACK-Alwaysit MUST release all resources associated with this Rule ID andACK-on-Error,optional DTag values. On receiving ajumping window protocol uses two windows alternatively, identified as 0 and 1. ASCHCFragment withSender-Abort, the receiver MAY release allFCN bits set to 0 (i.e. an All-0 fragment) indicates thatresources associated with this Rule ID and optional DTag values. The MIC computed at thewindow isreceiver MUST be computed over(i.e.the reassembled SCHC Packet and over the padding bits that were received in the SCHC Fragmentiscarrying the lastonetile. Figure 36 shows an example of a corresponding state machine. 8.4.2. ACK-Always The ACK-Always mode has been designed under thewindow)following assumptions o Data unit out-of-sequence delivery does not occur between the entity performing fragmentation andallows to switch from one window tothenext one.entity performing reassembly o TheAll-1 FCN inL2 MTU value does not change while a fragmented SCHCFragment indicates that itPacket isthe last fragment of the packetbeingtransmitted and therefore there will not be another window for this packet. 8.5.1. No-ACKtransmitted. Inthe No-ACKACK-Always mode,therewindows are used. An acknowledgement, positive or negative, isno feedback communication fromfed by the fragment receiver back to the fragmentreceiver. Thesenderwill send allat theSCHC fragmentsend ofa packet without any possibilitythe transmission ofknowing if errors or losses have occurred. As, in this mode, thereeach window of SCHC Fragments. The tiles are not required to be of uniform size. Padding isno needkept toidentify specifica minimum: only the last SCHCFragments,Fragment is padded as needed. In aone-bit FCN MAY be used. Consequently,nutshell, theFCN All-0 valuealgorithm isused inthe following: after a first blind transmission of allSCHC fragments exceptthelast one, which carries an All-1 FCN andtiles of a window, theMIC. The receiver will wait for SCHC Fragments and will setfragment sender iterates retransmitting theInactivity timer. The receiver will usetiles that are reported missing until theMIC contained infragment receiver reports that all thelast SCHC Fragmenttiles belonging tocheck for errors. WhentheInactivity Timer expireswindow have been correctly received, orifuntil too many attempts were made. The fragment sender only advances to theMIC check indicatesnext window of tiles when it has ascertained that all thereassembled packet does not matchtiles belonging to theoriginal one,current window have been fully and correctly received. This results in a lock-step behaviour between thereceiver will release all resourcessender and the receiver, at the window granularity. Each Profile MUST specify which Rule ID value(s) is (are) allocated toreassemblingthispacket.mode. For brevity, the rest of Section 8.4.1 only refers to Rule ID values that are allocated to this mode. TheinitialW field MUST be present and its size M MUST be 1 bit. WINDOW_SIZE MUST be equal to MAX_WIND_FCN + 1. Each Profile, for each Rule ID value, MUST define o the value of N (size of theInactivity Timer will be determined based onFCN field), o thecharacteristicsvalue of MAX_WIND_FCN o theunderlying LPWAN technologysize andwill be definedalgorithm for the MIC field inother documents (e.g. technology-specific profile documents). 8.5.2. ACK-Always In ACK-Always,thesender transmitsSCHCFragments by usingF/R messages, if different from thetwo- jumping-windows procedure. A delay between each SCHC fragment can be added to respect local regulationsdefault, o the presence orother constraints imposed byabsence of theapplications. Each time a SCHC fragment is sent,DTag field in theFCNSCHC F/R messages, as well as its size if it isdecreased by one. Whenpresent, o theFCN reachesvalue0, if there are more SCHC Fragments remaining to be sent, the sender transmits the last SCHC Fragmentofthis window usingMAX_ACK_REQUESTS, o theAll-0 fragment format. It then startsexpiration time of the Retransmission Timer o the expiration time of the Inactivity Timer The sender, for each active pair of Rule ID andwaitsoptional DTag values, MUST maintain o one Attempts counter o one Retransmission Timer The receiver, fora SCHC ACK. Otherwise, if FCN reaches 0each pair of Rule ID and optional DTag values, MUST maintain o one Inactivity Timer 8.4.2.1. Sender behaviour At thesender transmits the last SCHC Fragmentbeginning of the fragmentation of a new SCHC Packet, thesender uses the All-1fragmentformat, which includes a MIC. Thesendersets the Retransmission TimerMUST select a Rule ID andwaitsDTag value pair forthethis SCHCACKPacket. For brevity, the rest of Section 8.4.2 only refers toknow if transmission errors have occurred. The Retransmission Timer is dimensioned based onSCHC F/R messages bearing theLPWAN technologyRule ID and optional DTag values hereby selected. Each SCHC Fragment MUST contain exactly one tile inuse. Whenits Payload. All tiles with theRetransmission Timer expires,number 0 in their window, as well as thesender sends an All-0 empty (resp. All-1 empty) fragment to request againlast tile, MUST be at least the size of an L2 Word. In all SCHCACK forFragment messages, thewindow that endedW field MUST be filled with theAll-0 (resp. All-1) fragment just sent. Theleast significant bit of the window numberis not changed. After receiving an All-0 or All-1 fragment,that thereceiver sendssender is currently processing. If a SCHCACK with an encoded Bitmap reporting whether any SCHC fragments have been lost or not. When the sender receivesFragment carries a tile that is not the last one of the SCHCACK,Packet, o itchecksMUST be of theW bit carried byRegular type specified in Section 8.3.1.1 o the FCN field MUST contain the tile number o each tile MUST be of a size that complements the SCHCACK. AnyFragment Header so that the SCHCACK carryingFragment is a multiple of L2 Words without the need for padding bits. The SCHC Fragment that carries the last tile MUST be anunexpected W bit valueAll-1 SCHC Fragment, described in Section 8.3.1.2. The bits on which the MIC isdiscarded. Ifcomputed MUST be theW bit valueSCHC Packet concatenated with the potential padding bits that are appended to the Payload of thereceivedSCHCACK is correct,Fragment that carries the last tile. The fragment senderanalyzesMUST start by processing therest ofwindow numbered 0. In a "blind transmission" phase, it MUST transmit all the tiles composing the window, in decreasing tile number. Then, it enters an "equalization phase" in which it MUST initialize an Attempts counter to 0, it MUST start a Retransmission Timer and it MUST expect to receive a SCHC ACK. Then, o on receiving a SCHC ACK, * if the SCHC ACKmessage, such asindicates that some tiles are missing at theencoded Bitmap andreceiver, then theMIC. Ifsender MUST transmit all theSCHC Fragments sent for this windowtiles that have beenwell received,reported missing, it MUST increment Attempts, it MUST reset the Retransmission Timer and MUST expect to receive a SCHC ACK again. * ifat leastthe current window is not the last onemoreand the SCHCFragment needs to be sent,ACK indicates that all tiles were correctly received, the senderadvances its sending windowMUST stop the Retransmission Timer, it MUST advance to the next fragmentation windowvalueandsendsit MUST start a blind transmission phase as described above. * if the current window is the last one and thenextSCHCFragments. If noACK indicates that moreSCHC Fragments have to betiles were received than the sender actually sent,thenthefragmentedfragment sender MUST send a SCHC Sender- Abort, it MUST release all resource associated with this SCHC Packettransmission is finished. However,and it MAY exit with an error condition. * if the current window is the last oneor more SCHC Fragments have not been received as perand the SCHC ACK(i.e. the corresponding bits are not set in the encoded Bitmap) thenindicates that all tiles were correctly received yet integrity check was a failure, the fragment senderresends the missingMUST send a SCHCFragments. WhenSender-Abort, it MUST release allmissingresource associated with this SCHCFragments have been retransmitted,Packet and it MAY exit with an error condition. * if thesender startscurrent window is theRetransmission Timer, even if an All-0 or an All-1 has not been sent as part of this retransmissionlast one andwaits for a SCHC ACK. Upon receipt ofthe SCHCACK, if one or more SCHC Fragments have not yet been received,ACK indicates that integrity checking was successful, thecountersender exits successfully. o on Retransmission Timer expiration, * if Attempts isincreased andstrictly less that MAX_ACK_REQUESTS, the fragment senderresends the missingMUST send a SCHCFragments again. WhenACK REQ and MUST increment the Attemptsreaches MAX_ACK_REQUESTS,counter. * otherwise the fragment senderaborts the on-going fragmentedMUST send a SCHC Sender-Abort, it MUST release all resource associated with this SCHC Packettransmission by sending a Sender-Abort messageandreleasesit MAY exit with an error condition. At anyresources for transmission oftime, o on receiving a SCHC Receiver-Abort, thepacket. Thefragment senderalso aborts an on-going fragmentedMUST release all resource associated with this SCHC Packettransmission whenand it MAY exit with an error condition. o on receiving afailed MIC check is reported bySCHC ACK that bears a W value different from thereceiver or whenW value that it currently uses, the fragment sender MUST silently discard and ignore that SCHC ACK. Figure 37 shows an example of a corresponding state machine. 8.4.2.2. Receiver behaviour On receiving a SCHC Fragment with a Rule ID and optional DTag pair not being processed at that time o the receiver MAY check if the optional DTag value has not recently beensent is reported inused for that Rule ID value, thereby ensuring that theencoded Bitmap. Onreceived SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission. If theother hand, atSCHC Fragment is determined to be such a remant, thebeginning,receiver MAY silently ignore it and discard it. o the receiverside expectsMUST start a process toreceive window 0. Anyassemble a new SCHCFragmentPacket with that Rule ID and DTag value pair. That process MUST only examine receivedbut not belonging toSCHC F/R messages with that Rule ID and DTag value pair and MUST only transmit SCHC F/R messages with that Rule ID and DTag value pair. o thecurrentreceiver MUST start an Inactivity Timer. It MUST initialise an Attempts counter to 0. It MUST initialise a windowis discarded. All SCHC Fragments belongingcounter to 0. In the rest of this section, "local W bit" means the least significant bit of thecorrectwindoware accepted, andcounter of theactualreceiver. On reception of any SCHCFragment number managed byF/R message, the receiveris computed basedMUST reset the Inactivity Timer. Entering an "acceptance phase", the receiver MUST first initialise an empty Bitmap for this window, then o on receiving a SCHC Fragment or SCHC ACK REQ with the W bit different from the local W bit, theFCN value. ThereceiverpreparesMUST silently ignore and discard that message. o on receiving a SCHC Fragment with theencoded BitmapW bit equal toreportthecorrectlylocal W bit, the receiver MUST assemble the received tile based on the window counter and on themissing SCHC Fragments forFCN field in thecurrent window. After eachSCHC Fragmentis received, the receiver initializesand it MUST update theInactivity Timer. WhenBitmap. * if theInactivity Timer expires,SCHC Fragment received is an All-0 SCHC Fragment, thetransmissioncurrent window isaborted bydetermined to be a not-last window, and the receiversendingMUST send aReceiver-Abort message. When an All-0 fragment is received, itSCHC ACK for this window. Then, + If the Bitmap indicates that all theSCHC Fragmentstiles of the current window have beensentcorrectly received, the receiver MUST increment its window counter and it enters the "acceptance phase" for that new window. + If the Bitmap indicates that at least one tile is missing in the current window, the receiver enters the "equalization phase" for this window.Since* if thesenderSCHC Fragment received isnot obliged to always send a full window, somean All-1 SCHC Fragment, the padding bits of the All-1 SCHC Fragmentnumber not set inMUST be assembled after thereceiver memory may not correspondreceived tile, the current window is determined tolosses. Thebe the last window, the receiversendsMUST perform thecorrespondingintegrity check and it MUST send a SCHCACK,ACK for this window. Then, + If theInactivity Timer is set andintegrity check indicates that thetransmission offull SCHC Packet has been correctly reassembled, thenext window byreceiver MUST enter thesender can start."clean-up phase". + Ifan All-0 fragmentthe integrity check indicates that the full SCHC Packet has not beenreceived and allcorrectly reassembled, the receiver enters the "equalization phase" for this window. o on receiving a SCHCFragments ofACK REQ with the W bit equal to the local W bit, the receiver has not yet determined if the current windowhave also been received,is a not-last one or the last one, the receiverthen expectsMUST send anew Window and waitsSCHC ACK for this window, and it keeps accepting incoming messages. In thenext SCHC Fragment. Upon receipt of a SCHC Fragment,"equalization phase": o if the windowvalue has not changed, the receivedis a not-last window * on receiving a SCHCFragments are part ofFragment or SCHC ACK REQ with aretransmission. AW bit different from the local W bit the receiver MUST silently ignore and discard thathas already receivedmessage. * on receiving a SCHC ACK REQ with a W bit equal to the local W bit, the receiver MUST send a SCHC ACK for this window. * on receiving a SCHC FragmentSHOULDwith a W bit equal to the local W bit, + if the SCHC Fragment received is an All-1 SCHC Fragment, the receiver MUST silently ignore it and discardit,it. + otherwise,it updatestheBitmap. If allreceiver MUST update thebits ofBitmap and it MUST assemble the tile received. * on the Bitmapare set to one,becoming fully populated with 1's, the receiver MUST send a SCHC ACKwithout waitingforan All-0 fragmentthis window, it MUST increment its window counter and it enters theInactivity Timer is initialized. On"acceptance phase" for theother hand,new window. o if the windowvalue ofis thenext receivedlast window * on receiving a SCHC Fragmentis setor SCHC ACK REQ with a W bit different from the local W bit the receiver MUST silently ignore and discard that message. * on receiving a SCHC ACK REQ with a W bit equal to thenext expected window value,local W bit, the receiver MUST send a SCHC ACK for thismeans thatwindow. * on receiving a SCHC Fragment with a W bit equal to thesender haslocal W bit, + if the SCHC Fragment receiveda correct encoded Bitmap reporting that allis an All-0 SCHCFragments have beenFragment, the receiver MUST silently ignore it and discard it. + otherwise, the receiver MUST update the Bitmap and it MUST assemble the tile received.TheIf the SCHC Fragment received is an All-1 SCHC Fragment, the receiverthen updatesMUST assemble thevaluepadding bits of thenext expected window. When anAll-1fragment is received, itSCHC Fragment after the received tile. It MUST perform the integrity check. Then - if the integrity check indicates that thelastfull SCHCFragment ofPacket has been correctly reassembled, thepacketreceiver MUST send a SCHC ACK and it enters the "clean-up phase". - if the integrity check indicates that the full SCHC Packet has not beensent. Sincecorrectly reassembled, o if thelastSCHC Fragment received was an All-1 SCHC Fragment, the receiver MUST send a SCHC ACK for this windowis not always full,o it keeps accepting incoming messages. In theMIC will"clean-up phase": o Any received SCHC F/R message with a W bit different from the local W bit MUST beused bysilently ignored and discarded. o Any received SCHC F/R message different from an All-1 SCHC Fragment or a SCHC ACK REQ MUST be silently ignored and discarded. o On receiving an All-1 SCHC Fragment or a SCHC ACK REQ, the receiverto detect if allMUST send a SCHCFragmentsACK. o On expiration of thepacket have been received. A correct MIC indicatesInactivity Timer, theendreceive process for that SCHC Packet MAY exit At any time, on expiration of thetransmission butInactivity Timer, on receiving a SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the receiver MUSTstay alive for an Inactivity Timer period to answer to any empty All-1 fragments the sender MAYsendifa SCHCACKs sent byReceiver-Abort, it MUST release all resource associated with this SCHC Packet and it MAY exit the receive process for that SCHC Packet. The MIC computed at the receiverare lost. IfMUST be computed over theMIC is incorrect, somereassembled SCHCFragments have been lost.Packet and over the padding bits that were received in the SCHC Fragment carrying the last tile. Figure 38 shows an example of a corresponding state machine. 8.4.3. ACK-on-Error Thereceiver sendsACK-on-Error mode supports LPWAN technologies that have variable MTU and out-of-order delivery. In ACK-on-Error mode, windows are used. All tiles MUST be of equal size, except for the last one, which MUST be of the same size or smaller than the preceding ones. WINDOW_SIZE MUST be equal to MAX_WIND_FCN + 1. A SCHC Fragment message carries one or more tiles, which may span multiple windows. A SCHC ACKregardlessreports on the reception ofsuccessful fragmentedexactly one window of tiles. See Figure 21 for an example. +---------------------------------------------...-----------+ | SCHC Packetreception or not, the Inactitivity Timer| +---------------------------------------------...-----------+ Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 |3| Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|- 28-| SCHC Fragment msg |-----------| Figure 21: a SCHC Packet fragmented in tiles, Ack-on-Error mode The W field isset. In case ofwide enough that it unambiguously represents anincorrect MIC,absolute window number. The fragment receiver feeds SCHC ACKs back to the fragment sender about windows that it misses tiles of. No SCHC ACK is fed back by the fragment receiverwaitsfor windows that it knows have been fully received. The fragment sender retransmits SCHC Fragments for tiles that are reported missing. It can advance to next windows even before it has ascertained that all tiles belonging to previous windows have been correctly received, and can still later retransmit SCHC Fragments with tiles belonging to previous windows. Therefore, thesame window. After MAX_ACK_REQUESTS,sender and the receiverwill abort the on-goingmay operate in a fully decoupled fashion. The fragmented SCHC Packet transmissionby transmitting a the Receiver-Abort format. The receiver also aborts upon Inactivity Timer expiration by sending a Receiver-Abort message. Ifconcludes when o integrity checking shows that thesender receives a SCK ACK with a Bitmap containing a bit set for afragmented SCHCFragment that itPacket hasnot sent duringbeen correctly reassembled at thetransmission phase ofreceive end, and thiswindow, it MUST abortinformation has been conveyed back to the sender, o or too many retransmission attempts were made, o or the receiver determines that thewhole fragmentation andtransmission of this fragmented SCHCPacket. 8.5.3. ACK-on-Error The senders behaviorPacket has been inactive for too long. Each Profile MUST specify which Rule ID value(s) is (are) allocated to this ACK-on-Errorand ACK-Alwaysmode. For brevity, the rest of Section 8.4.3 only refers to SCHC F/R messages with Rule ID values that aresimilar.allocated to this mode. Themain difference is thatW field MUST be present inACK-on-Errorthe SCHCACK withF/R messages. Each Profile, for each Rule ID value, MUST define o theencoded Bitmap istile size (a tile does notsent at the endneed to be multiple ofeach windowan L2 Word, butonly whenit MUST be at leastone SCHC Fragmentthe size of an L2 Word) o thecurrent window has been lost. Exceptvalue of M (size of the W field), o the value of N (size of the FCN field), o the value of MAX_WIND_FCN o the size and algorithm for thelast window where aMIC field in the SCHCACK MUST be sent to finishF/R messages, if different from thetransmission. In ACK-on-Error,default, o the presence or absence of the DTag field in the SCHC F/R messages, as well as its size if it is present, o the value of MAX_ACK_REQUESTS, o the expiration time of the Retransmission Timer o the expirationis considered astime of the Inactivity Timer The sender, for each active pair of Rule ID and optional DTag values, MUST maintain o one Attempts counter o one Retransmission Timer The receiver, for each pair of Rule ID and optional DTag values, MUST maintain o one Inactivity Timer 8.4.3.1. Sender behaviour At the beginning of the fragmentation of apositive acknowledgementnew SCHC Packet, o the fragment sender MUST select a Rule ID and DTag value pair forall windows butthis SCHC Packet. A Rule MUST NOT be selected if thelast one. This timer is set after sending an All-0values of M and MAX_WIND_FCN for that Rule are such that the SCHC Packet cannot be fragmented in (2ˆM) * (MAX_WIND_FCN+1) tiles oran All-1 fragment. For an All-0 fragment, on timer expiration,less. o the fragment senderresumes operationMUST initialize the Attempts counter to 0 for that Rule ID andsendsDTag value pair. For brevity, theSCHC Fragmentsrest of Section 8.4.3 only refers to SCHC F/R messages bearing thenext window.Rule ID and optional DTag values hereby selected. A SCHC Fragment message carries in its payload one or more tiles. If more than one tile is carried in one SCHC Fragment o thesender receives aselected tiles MUST be consecutive in the original SCHCACK, it checksPacket o they MUST be placed in thewindow value.SCHCACKsFragment Payload adjacent to one another, in the order they appear in the SCHC Packet, from the start of the SCHC Packet toward its end. In a SCHC Fragment message, the sender MUST fill the W field withan unexpected window number are discarded. Ifthe window numberinof thereceivedfirst tile sent in that SCHCACKFragment. If a SCHC Fragment carries more than one tile, or carries one tile that iscorrect,not thesender verifies iflast one of thereceiver has received allSCHCfragmentsPacket, o it MUST be of thecurrent window. When at least oneRegular type specified in Section 8.3.1.1 o the FCN field MUST contain the tile number of the first tile sent in that SCHC Fragmenthas been lost,o padding bits are appended to thecounter Attemptstiles as needed to fit the Payload size constraint of Regular SCHC Fragments The bits on which the MIC isincreased by one andcomputed MUST be thesender resendsSCHC Packet concatenated with the padding bits that are appended to the Payload of themissingSCHCFragments again. When Attempts reaches MAX_ACK_REQUESTS,Fragment that carries the last tile. The fragment sendersends a Sender-Abort message and releasesMAY send the last tile as the Payload of an All-1 SCHC Fragment. The fragment sender MUST send SCHC Fragments such that, all together, they contain allresources fortheon-goingtiles of the fragmented SCHCPacket transmission. WhenPacket. The fragment sender MUST send at least one All-1 SCHC Fragment. Note that theretransmissionlast tile ofthe missinga SCHCFragments is finished,Packet can be sent in different ways, depending on Profiles and implementations o in a Regular SCHC Fragment, either alone or as part of multiple tiles Payload o in an All-1 SCHC Fragment However, the last tile MUST NOT have ever been sent both in a Regular SCHC Fragment and in a All-1 SCHC Fragment. The fragment senderstarts listeningMUST listen foraSCHC ACK(even if an All-0 or an All-1 has not beenmessages after having sentduring the retransmission) and initializes the Retransmission Timer. After sendingo an All-1fragment, the sender listens forSCHC Fragment o or a SCHCACK, initializes Attempts, and starts the Retransmission Timer. IfACK REQ with theRetransmission Timer expires, Attempts is increased by one and an empty All-1 fragment is sentW field corresponding torequest the SCHC ACK forthe last window.If Attempts reaches MAX_ACK_REQUESTS,A Profile MAY specify other times at which the fragment senderaborts the on-going fragmentedMUST listen for SCHCPacket transmission by transmitting the Sender-Abort fragment. At the end of any window, if the sender receives a SCKACKwith a Bitmap containing a bit set formessages. Each time a fragment sender sends an All-1 SCHC Fragmentthator a SCHC ACK REQ, o ithas not sent duringMUST increment thetransmission phase of that window,Attempts counter o it MUSTabort the whole fragmentation and transmission of this SCHC Packet. Unlikereset thesender,Retransmission Timer On Retransmission Timer expiration o if Attempts is strictly less than MAX_ACK_REQUESTS, thereceiver for ACK-on-Error has a larger amount of differences compared with ACK-Always. First,fragment sender MUST send a SCHC ACKis not sent unless there is a lost SCHC Fragment or an unexpected behavior. WithREQ with theexception ofW field corresponding to the lastwindow, where a SCHC ACK is always sent regardless of SCHC Fragment losses or not. The receiver starts by expecting SCHC Fragments fromwindow0andmaintainsit MUST increment theinformation regarding whichAttempts counter o otherwise the fragment sender MUST send a SCHCFragmentsSender-Abort and itreceives. AfterMUST release all resource associated with this SCHC Packet. On receiving a SCHCFragment, the Inactivity Timer is set. If no further SCHC Fragment are received and the Inactivity Timer expires, the SCHC Fragment receiver abortsACK, o if theon-going fragmented SCHC Packet transmission by transmittingW field in theReceiver-Abort data unit. AnySCHCFragment not belongingACK corresponds to thecurrentlast windowis discarded. The actualof the SCHCFragment number is computed based onPacket, * if theFCN value. When an All-0 fragmentC bit isreceived andset, the sender MAY release all resource associated with this SCHCFragments have been received, the receiver updates the expected window value and expects a new windowPacket andwaits forMAY exit successfully * otherwise, + if thenextSCHCFragment. IfACK shows no missing tile at thewindow value ofreceiver, thenextsender - MUST send a SCHCFragment has not changed,Sender-Abort - MUST release all resource associated with this SCHC Packet - MAY exit with an error condition + otherwise - thereceivedfragment sender MUST send SCHC Fragmentis a retransmission. A receiver that has already received a Fragment discard it. Ifmessages containing all the tiles that are reported missing in the SCHCFragmentsACK. - if the last message in this sequence ofa window (thatSCHC Fragment messages is not an All-1 SCHC Fragment, then thelast one) have been received, the receiver does notfragment sender MUST send a SCHCACK. WhileACK REQ with thereceiver waits forW field corresponding to thenextlast windowand ifafter thewindow value is set tosequence. o otherwise, thenext value, and if an All-1fragmentwith the next value window arrivedsender * MUST send SCHC Fragment messages containing thereceiver knowstiles that are reported missing in thelastSCHCFragment ofACK * then it MAY send a SCHC ACK REQ with thepacket has been sent. SinceW field corresponding to the last windowisSee Figure 39 for one among several possible examples of a Finite State Machine implementing a sender behaviour obeying this specification. 8.4.3.2. Receiver behaviour On receiving a SCHC Fragment with a Rule ID and optional DTag pair notalways full,being processed at that time o theMIC will be used to detectreceiver MAY check ifall SCHC Fragments ofthewindow haveoptional DTag value has not recently beenreceived. A correct MIC check indicatesused for that Rule ID value, thereby ensuring that theendreceived SCHC Fragment is not a remnant ofthea prior fragmented SCHC Packet transmission.An ACK is sent byIf the SCHC Fragmentreceiver. In case of an incorrect MIC, the receiver waits for SCHC Fragments belongingis determined to be such a remant, thesame window or the expiration of the Inactivity Timer. The latter will leadreceiver MAY silently ignore it and discard it. o the receiver MUST start a process toabort the on-goingassemble a new SCHCfragmented packet transmission by transmitting the Receiver-Abort message. If, after receiving an All-0 fragment the receiver missed somePacket with that Rule ID and DTag value pair. That process MUST only examine received SCHCFragments, the receiver uses aF/R messages with that Rule ID and DTag value pair and MUST only transmit SCHCACKF/R messages with that Rule ID and DTag value pair. o theencoded Bitmapreceiver MUST start an Inactivity Timer. It MUST initialise an Attempts counter toask the retransmission0. On reception ofthe missing fragments and expect to receiveany SCHCFragments withF/R message, theactual window. While waitingreceiver MUST reset theretransmission an All-0 empty fragment is received,Inactivity Timer. On reception of a SCHC Fragment message, the receiversends againMUST assemble the received tiles based on the W and FCN fields of the SCHCACK withFragment. o if theencoded Bitmap,FCN is All-1, if a Payload is present, the full SCHCFragments received belongs to another window or an All-1 fragmentFragment Payload MUST be assembled including the padding bits. This isreceived,because thetransmissionsize of the last tile isabortednot known bysending a Receiver-Abort fragment. Once it has received allthemissing fragments it waits forreceiver, therefore padding bits are indistinguishable from thenext window fragments. 8.6. Supporting multiple window sizes For ACK-Always or ACK-on-Error, implementers MAY opt to support a single window size or multiple window sizes. The latter, when feasible, may provide performance optimizations. For example, a large window size SHOULD be used for packets that need totile data bits, at this stage. They will becarriedremoved bya large number of SCHC Fragments. However, whenthenumber of SCHC Fragments required to carry a packet is low, a smaller window size, and thus a shorter Bitmap, MAY be sufficient to provide feedback on allSCHCFragments.C/D sublayer. Ifmultiple window sizes are supported,theRule ID MAY be used to signalsize of the SCHC Fragment Payload exceeds or equals thewindowsizein use for a specific packet transmission. Note thatof one regular tile plus thesame windowsize of an L2 Word, this SHOULD raise an error flag. o otherwise, tiles MUST beused for the transmission of all SCHC Fragments that belong toassembled based on thesame SCHC Packet. 8.7. Downlink SCHC Fragment transmission In some LPWAN technologies, as part of energy-saving techniques, downlink transmissiona priori known size and padding bits MUST be discarded. The latter isonlypossibleimmediately after an uplink transmission. In order to avoid potentially high delay inbecause * thedownlink transmissionsize ofa fragmented SCHC Packet,theSCHC Fragment receiver MAY performtiles is known a priori, * tiles are larger than anuplink transmission as soon as possible afterL2 Word * padding bits are always strictly less than an L2 Word On reception of a SCHCFragment that is not the last one. Such uplink transmission MAY be triggered by the L2 (e.g. an L2ACKsent in response to aREQ or of an All-1 SCHCFragment encapsulated in a L2 frameFragment, o if the receiver has at least one window thatrequires an L2 ACK) oritMAY be triggered from an upper layer. For downlink transmission ofknows has tiles missing, it MUST return afragmentedSCHCPacket in ACK-Always mode,ACK for theSCHC Fragment receiver MAY support timer-basedlowest-numbered such window, o otherwise, * if it has received at least one tile, it MUST return a SCHC ACKretransmission. In this mechanism,for the highest-numbered window it currently has tiles for * otherwise it MUST return a SCHCFragment receiver initializesACK for window numbered 0 A Profile MAY specify other times andstartscircumstances at which atimer (the Inactivity Timer is used) after the transmission ofreceiver sends a SCHC ACK,except whenand which window the SCHC ACKis sentreports about inresponse to the last SCHC Fragment ofthese circumstances. On sending apacket (All-1 fragment). In the latter case, theSCHCFragmentACK, the receiverdoes not start a timer after transmission ofMUST increase theSCHC ACK. If, after transmissionAttempts counter. From reception ofa SCHC ACK that is notan All-1fragment, and before expiration of the corresponding Inactivity timer, the SCHC Fragment receiver receives aSCHC Fragmentthat belongs to the current window (e.g.onward, amissing SCHC Fragment from the current window) or to the next window,receiver MUST check theInactivity timer forintegrity of the reassembled SCHCACK is stopped. However, if the Inactivity timer expires, thePacket at least every time it prepares for sending a SCHC ACKis resent and the Inactivity timer is reinitialized and restarted. The default initial valuefor theInactivity timer, as well as the maximum numberlast window. On reception ofretries foraspecificSCHCACK, denoted MAX_ACK_RETRIES, are not defined inSender-Abort, the receiver MUST release all resource associated with thisdocument, and need to be defined in other documents (e.g. technology-specific profiles). The initial valueSCHC Packet. On expiration of the Inactivitytimer is expected to be greater than that ofTimer, theRetransmission timer, in order to make sure thatreceiver MUST send a(buffered) SCHC Fragment to be retransmitted can find an opportunity for that transmission. When theSCHCFragment sender transmits the All-1 fragment,Receiver-Abort and itstarts its Retransmission TimerMUST release all resource associated witha large timeout value (e.g. several times that of the initial Inactivity timer). If a SCHC ACK is received before expiration ofthistimer, the SCHC Fragment sender retransmits any lostSCHCFragments reported byPacket. On theSCHC ACK, or ifAttempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST send a SCHCACK confirms successful reception ofReceiver-Abort and it MUST release all resource associated with this SCHCFragments of the last window, the transmissionPacket. Reassembly of thefragmentedSCHC Packetis considered complete. If the timer expires, and no SCHC ACKconcludes when o a Sender-Abort has been receivedsince the start ofo or thetimer,Inactivity Timer has expired o or the Attempts counter has exceeded MAX_ACK_REQUESTS o or when at least an All-1 SCHC Fragmentsender assumes that the All-1 fragmenthas beensuccessfullyreceived(and possibly,and integrity checking of thelastreassembled SCHCACK has been lost: this mechanism assumes thatPacket is successful. The MIC computed at theretransmission timer forreceiver MUST be computed over theAll-1 fragment is long enough to allow severalreassembled SCHCACK retries ifPacket and over theAll-1 fragment has not;beenpadding bits that were receivedbyin the SCHC Fragmentreceiver,carrying the last tile. See Figure 40 for one among several possible examples of a Finite State Machine implementing a receiver behaviour obeying this specification, andit also assumesthatitisunlikely that several ACKs become all lost).meant to match the sender Finite State Machine of Figure 39. 9. Padding management SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does not have any alignment prerequisite. The size of SCHC Packets can be any number of bits. If theLayer 2layer below SCHC constrains theL2 Data Unitpayload to align to some boundary, called L2 Words (for example, bytes), SCHC will meet that constraint and produce messages with the correct alignement. This may entail adding extrabits (calledbits, called paddingbits).bits. When padding occurs, the number of appended bitsisMUST be strictly less than the L2 Word size. Padding happens at most once for each Packetgoing through the fullduring SCHCchain, i.e.Compression and(optionally)optional SCHC Fragmentation (see Figure 2). If a SCHC Packet is sent unfragmented (see Figure27),22), it is padded asneeded.needed for transmission. If a SCHC Packet is fragmented, it is not padded in itself, only thelast fragment isSCHC Fragments are padded asneeded.needed for transmission. Some SCHC F/R modes only pad the very last SCHC Fragment. A packet (e.g. an IPv6 packet) | ^ (padding bits v | dropped) +------------------+ +--------------------+ | SCHC Compression | | SCHC Decompression | +------------------+ +--------------------+ | ^ | If no fragmentation | +---- SCHC Packet + padding as needed ----->| | | (MIC checked v | and removed) +--------------------+ +-----------------+ | SCHC Fragmentation | | SCHC Reassembly | +--------------------+ +-----------------+ | ^ | ^ | | | | | +------------- SCHC ACK ------------+ | | |+---------------+------- SCHC Fragments--------------------+ +--- last SCHC Frag with MIC+ padding asneeded ---+needed---------+ SENDER RECEIVER Figure27:22: SCHC operations, including padding as needed Eachtechnology-specific documentProfile MUST specify the size of the L2 Word. The L2 Word might actually be a single bit, in which case at most zero bits of padding will be appended to any message, i.e. no padding will take place at all. A Profile MAY define the value of the padding bits. The RECOMMENDED value is 0. 10. SCHC Compression for IPv6 and UDP headers This section lists the different IPv6 and UDP header fields and how they can be compressed. 10.1. IPv6 version field This field always holds the same value. Therefore, in the Rule, TV is set to 6, MO to "equal" and CDA to "not-sent". 10.2. IPv6 Traffic class field If the DiffServ field does not vary and is known by both sides, the Field Descriptor in the Rule SHOULD contain a TV with this well-known value, an "equal" MO and a "not-sent" CDA.Otherwise,Otherwise (e.g. ECN bits are to be transmitted), two possibilities can be considered depending on the variability of the value: o One possibility is to not compress the field and send the original value. In the Rule, TV is not set to any particular value, MO is set to "ignore" and CDA is set to "value-sent". o If some upper bits in the field are constant and known, a better option is to only send the LSBs. In the Rule, TV is set to a value with the stable known upper part, MO is set to MSB(x) and CDA toLSB(y).LSB. 10.3. Flow label field If the Flow Label field does not vary and is known by both sides, the Field Descriptor in the Rule SHOULD contain a TV with this well-known value, an "equal" MO and a "not-sent" CDA. Otherwise, two possibilities can be considered: o One possibility is to not compress the field and send the original value. In the Rule, TV is not set to any particular value, MO is set to "ignore" and CDA is set to "value-sent". o If some upper bits in the field are constant and known, a better option is to only send the LSBs. In the Rule, TV is set to a value with the stable known upper part, MO is set to MSB(x) and CDA toLSB(y).LSB. 10.4. Payload Length field This field can be elided for the transmission on the LPWAN network. The SCHC C/D recomputes the original payload length value. In the Field Descriptor, TV is not set, MO is set to "ignore" and CDA is "compute-IPv6-length". If the payload length needs to be sent and does not need to be coded in 16 bits, the TV can be set to 0x0000, the MO set to MSB(16-s) where 's' is the number of bits to code the maximum length, and CDA is set toLSB(s).LSB. 10.5. Next Header field If the Next Header field does not vary and is known by both sides, the Field Descriptor in the Rule SHOULD contain a TV with this Next Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not- sent". Otherwise, TV is not set in the Field Descriptor, MO is set to "ignore" and CDA is set to "value-sent". Alternatively, a matching- list MAY also be used. 10.6. Hop Limit field The field behavior for this field is different for Uplink and Downlink. In Uplink, since there is no IP forwarding between the Dev and the SCHC C/D, the value is relatively constant. On the other hand, the Downlink value depends of Internet routing and MAY change more frequently. One neat way of processing this field is to use the Direction Indicator (DI) to distinguish both directions: o in the Uplink, elide the field: the TV in the Field Descriptor is set to the known constant value, the MO is set to "equal" and the CDA is set to "not-sent". o in the Downlink, send the value: TV is not set, MO is set to "ignore" and CDA is set to "value-sent". 10.7. IPv6 addresses fields As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit long fields; one for the prefix and one for the Interface Identifier (IID). These fields SHOULD be compressed. To allow for a single Rule being used for both directions, these values are identified by their role (DEV or APP) and not by their position in theframeheader (source or destination). 10.7.1. IPv6 source and destination prefixes Both ends MUST be synchronized with the appropriate prefixes. For a specific flow, the source and destination prefixes can be unique and stored in the context. It can be either a link-local prefix or a global prefix. In that case, the TV for the source and destination prefixes contain the values, the MO is set to "equal" and the CDA is set to "not-sent". If the Rule is intended to compress packets with different prefix values, match-mapping SHOULD be used. The different prefixes are listed in the TV, the MO is set to "match-mapping" and the CDA is set to "mapping-sent". See Figure2924 Otherwise, the TV contains the prefix, the MO is set to "equal" and the CDA is set to "value-sent". 10.7.2. IPv6 source and destination IID If the DEV or APP IID are based on an LPWAN address, then the IID can be reconstructed with information coming from the LPWAN header. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "DevIID" or "AppIID". Note that the LPWAN technology generally carries a single identifier corresponding to the DEV. Therefore AppIID cannot be used. For privacy reasons or if the DEV address is changing over time, a static value that is not equal to the DEV address SHOULD be used. In that case, the TV contains the static value, the MO operator is set to "equal" and theCDFCDA is set to "not-sent". [RFC7217] provides some methods that MAY be used to derive this static identifier. If several IIDs are possible, then the TV contains the list of possible IIDs, the MO is set to "match-mapping" and the CDA is set to "mapping-sent". It MAY also happen that the IID variability only expresses itself on a few bytes. In that case, the TV is set to the stable part of the IID, the MO is set to "MSB" and the CDA is set to "LSB". Finally, the IID can be sent in extenso on the LPWAN. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "value-sent". 10.8. IPv6 extensions No Rule is currently defined that processes IPv6 extensions. If such extensions are needed, their compression/decompression Rules can be based on the MOs and CDAs described above. 10.9. UDP source and destination port To allow for a single Rule being used for both directions, the UDP port values are identified by their role (DEV or APP) and not by their position in theframeheader (source or destination). The SCHC C/D MUST be aware of the traffic direction (Uplink, Downlink) to select the appropriate field. The following Rules apply for DEV and APP port numbers. If both ends know the port number, it can be elided. The TV contains the port number, the MO is set to "equal" and the CDA is set to "not- sent". If the port variation is on few bits, the TV contains the stable part of the port number, the MO is set to "MSB" and the CDA is set to "LSB". If some well-known values are used, the TV can contain the list of these values, the MO is set to "match-mapping" and the CDA is set to "mapping-sent". Otherwise the port numbers are sent over the LPWAN. The TV is not set, the MO is set to "ignore" and the CDA is set to "value-sent". 10.10. UDP length field The UDP length can be computed from the received data. In that case, the TV is not set, the MO is set to "ignore" and the CDA is set to "compute-length". If the payload is small, the TV can be set to 0x0000, the MO set to "MSB" and the CDA to "LSB". In other cases, the length SHOULD be sent and the CDA is replaced by "value-sent". 10.11. UDP Checksum field The UDP checksum operation is mandatory with IPv6 [RFC8200] for most packets but recognizes that there are exceptions to that default behavior. For instance, protocols that use UDP as a tunnel encapsulation may enable zero-checksum mode for a specific port (or set of ports) for sending and/or receiving. [RFC8200] also stipulates that any node implementing zero-checksum mode must follow the requirements specified in "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936]. 6LoWPAN Header Compression [RFC6282] also authorizes to send UDP datagram that are deprived of the checksum protection when an upper layer guarantees the integrity of the UDP payload and pseudo-header all the way between the compressor that elides the UDP checksum and the decompressor that computes again it. A specific example of this is when a Message Integrity Check (MIC) protects the compressed message all along that path with a strength that is identical or better to the UDP checksum. In a similar fashion, this specification allows a SCHC compressor to elide the UDP checks when another layer guarantees an identical or better integrity protection for the UDP payload and the pseudo- header. In this case, the TV is not set, the MO is set to "ignore" and the CDA is set to "compute-checksum". In particular, when SCHC fragmentation is used, a fragmentation MIC of 2 bytes or more provides equal or better protection than the UDP checksum; in that case, if the compressor is collocated with the fragmentation point and the decompressor is collocated with the packet reassembly point, then compressor MAY elide the UDP checksum. Whether and when the UDP Checksum is elided is to be specified in thetechnology-specific documents.Profile. Since the compression happens before the fragmentation, implementors should understand the risks when dealing with unprotected data below the transport layer and take special care when manipulating that data. In other cases, the checksum SHOULD be explicitly sent. The TV is not set, the MO is set to "ignore" and the CDA is set to "value- sent". 11. IANA Considerations This document has no request to IANA. 12. Security considerations 12.1. Security considerations for SCHC Compression/Decompression A malicious header compression could cause the reconstruction of a wrong packet that does not match with the original one. Such a corruption MAY be detected with end-to-end authentication and integrity mechanisms. Header Compression does not add more security problem than what is already needed in a transmission. For instance, to avoid an attack, never re-construct a packet bigger than some configured size (with 1500 bytes as generic default). 12.2. Security considerations for SCHC Fragmentation/Reassembly This subsection describes potential attacks to LPWAN SCHC F/R and suggests possible countermeasures. A node can perform a buffer reservation attack by sending a first SCHC Fragment to a target. Then, the receiver will reserve buffer space for the IPv6 packet. Other incoming fragmented SCHC Packets will be dropped while the reassembly buffer is occupied during the reassembly timeout. Once that timeout expires, the attacker can repeat the same procedure, and iterate, thus creating a denial of service attack. The (low) cost to mount this attack is linear with the number of buffers at the target node. However, the cost for an attacker can be increased if individual SCHC Fragments of multiple packets can be stored in the reassembly buffer. To further increase the attack cost, the reassembly buffer can be split into SCHC Fragment-sized buffer slots. Once a packet is complete, it is processed normally. If buffer overload occurs, a receiver can discard packets based on the sender behavior, which MAY help identify which SCHC Fragments have been sent by an attacker. In another type of attack, the malicious node is required to have overhearing capabilities. If an attacker can overhear a SCHC Fragment, it can send a spoofed duplicate (e.g. with random payload) to the destination. If the LPWAN technology does not support suitable protection (e.g. source authentication and frame counters to prevent replay attacks), a receiver cannot distinguish legitimate from spoofed SCHC Fragments. Therefore, the original IPv6 packet will be considered corrupt and will be dropped. To protect resource- constrained nodes from this attack, it has been proposed to establish a binding among the SCHC Fragments to be transmitted by a node, by applying content-chaining to the different SCHC Fragments, based on cryptographic hash functionality. The aim of this technique is to allow a receiver to identify illegitimate SCHC Fragments. Further attacks MAY involve sending overlapped fragments (i.e. comprising some overlapping parts of the original IPv6 datagram). Implementers SHOULD make sure that the correct operation is not affected by such event. In ACK-on-Error, a malicious node MAY force a SCHC Fragment sender to resend a SCHC Fragment a number of times, with the aim to increase consumption of the SCHC Fragment sender's resources. To this end, the malicious node MAY repeatedly send a fake ACK to the SCHC Fragment sender, with a Bitmap that reports that one or more SCHC Fragments have been lost. In order to mitigate this possible attack, MAX_ACK_RETRIES MAY be set to a safe value which allows to limit the maximum damage of the attack to an acceptable extent. However, note that a high setting for MAX_ACK_RETRIES benefits SCHC Fragment reliability modes, therefore the trade-off needs to be carefully considered. 13. Acknowledgements Thanks to Carsten Bormann, Philippe Clavier, Diego Dujovne, Eduardo Ingles Sanchez, Arunprabhu Kandasamy, Rahul Jadhav, Sergio Lopez Bernal, Antony Markovski, Alexander Pelov,Pascal Thubert, Juan Carlos Zuniga, Diego Dujovne,Charles Perkins, Edgar Ramos,andShoichiSakaneSakane, and Pascal Thubert for useful design consideration and comments. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. 14.2. Informative References [RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna, "Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations", RFC 3385, DOI 10.17487/RFC3385, September 2002, <https://www.rfc-editor.org/info/rfc3385>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>. [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, DOI 10.17487/RFC5795, March 2010, <https://www.rfc-editor.org/info/rfc5795>. [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>. [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>. [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <https://www.rfc-editor.org/info/rfc7136>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, <https://www.rfc-editor.org/info/rfc8376>. Appendix A. SCHC Compression Examples This section gives some scenarios of the compression mechanism for IPv6/UDP. The goal is to illustrate the behavior of SCHC. The most common case using the mechanisms defined in this document will be a LPWAN Dev that embeds some applications running over CoAP. In this example, three flows are considered. The first flow is for the device management based on CoAP using Link Local IPv6 addresses and UDP ports 123 and 124 for Dev and App, respectively. The second flow will be a CoAP server for measurements done by the Device (using ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to beta::1/64. The last flow is for legacy applications using different ports numbers, the destination IPv6 address prefix is gamma::1/64. Figure2823 presents the protocol stack for this Device. IPv6 and UDP are represented with dotted lines since these protocols are compressed on the radio link. Management Data +----------+---------+---------+ | CoAP | CoAP | legacy | +----||----+---||----+---||----+ . UDP . UDP | UDP | ................................ . IPv6 . IPv6 . IPv6 . +------------------------------+ | SCHC Header compression | | and fragmentation | +------------------------------+ | LPWAN L2 technologies | +------------------------------+ DEV or NGW Figure28:23: Simplified Protocol Stack for LP-WAN Note that in some LPWAN technologies, only the Devs have a device ID. Therefore, when such technologies are used, it is necessary to statically define an IID for the Link Local address for the SCHC C/D. Rule 0 +----------------+--+--+--+---------+--------+------------++------+ | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | | | | | | | Opera. | Action ||[bits]| +----------------+--+--+--+---------+---------------------++------+ |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | |IPv6 DEVprefix |64|1 |Bi|FE80::/64| equal | not-sent || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 APPprefix |64|1 |Bi|FE80::/64| equal | not-sent || | |IPv6 AppIID |64|1 |Bi|::1 | equal | not-sent || | +================+==+==+==+=========+========+============++======+ |UDP DEVport |16|1 |Bi|123 | equal | not-sent || | |UDP APPport |16|1 |Bi|124 | equal | not-sent || | |UDP Length |16|1 |Bi| | ignore | comp-length|| | |UDP checksum |16|1 |Bi| | ignore | comp-chk || | +================+==+==+==+=========+========+============++======+ Rule 1 +----------------+--+--+--+---------+--------+------------++------+ | Field |FL|FP|DI| Value | Match | Action || Sent | | | | | | | Opera. | Action ||[bits]| +----------------+--+--+--+---------+--------+------------++------+ |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent||[1]1 | | | | | |fe80::/64] mapping| || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent||[2]2 | | | | | |alpha/64,| mapping| || | | | | | |fe80::64]| | || | |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | +================+==+==+==+=========+========+============++======+ |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | |UDP APPport |16|1 |Bi|5683 | equal | not-sent || | |UDP Length |16|1 |Bi| | ignore | comp-length|| | |UDP checksum |16|1 |Bi| | ignore | comp-chk || | +================+==+==+==+=========+========+============++======+ Rule 2 +----------------+--+--+--+---------+--------+------------++------+ | Field |FL|FP|DI| Value | Match | Action || Sent | | | | | | | Opera. | Action ||[bits]| +----------------+--+--+--+---------+--------+------------++------+ |IPv6 version |4 |1 |Bi|6 | equal | not-sent || | |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 Flow Label |20|1 |Bi|0 | equal | not-sent || | |IPv6 Length |16|1 |Bi| | ignore | comp-length|| | |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |IPv6 Hop Limit |8 |1 |Up|255 | ignore | not-sent || | |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent ||[8]8 | |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | +================+==+==+==+=========+========+============++======+ |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB ||[4]4 | |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB ||[4]4 | |UDP Length |16|1 |Bi| | ignore | comp-length|| | |UDP checksum |16|1 |Bi| | ignore | comp-chk || | +================+==+==+==+=========+========+============++======+ Figure29:24: Context Rules All the fields described in the three Rules depicted on Figure2924 are present in the IPv6 and UDP headers. The DevIID-DID value is found in the L2 header. The second and third Rules use global addresses. The way the Dev learns the prefix is not in the scope of the document. The third Rule compresses port numbers to 4 bits. Appendix B. Fragmentation Examples This section provides examples for the different fragment reliability modes specified in this document. Figure3025 illustrates the transmission in No-ACK mode ofan IPv6 packeta SCHC Packet that needs 11fragments.SCHC Fragments. FCN is 1 bit wide. Sender Receiver |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-------FCN=0-------->| |-----FCN=1 + MIC--->|MIC checked:--->| Integrity check: success=>(End) Figure30:25: Transmission in No-ACK mode ofan IPv6 packeta SCHC Packet carried by 11fragmentsSCHC Fragments In the following examples, N(i.e. the(the sizeifof the FCN field) is 3 bits. Therefore, the All-1 FCN value is 7. Figure3126 illustrates the transmission in ACK-on-Error mode ofan IPv6 packet that needsa SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, MAX_WIND_FCN=6 and nofragment loss.lost SCHC Fragment. Sender Receiver |-----W=0, FCN=6----->| |-----W=0, FCN=5----->| |-----W=0, FCN=4----->| |-----W=0, FCN=3----->| |-----W=0, FCN=2----->| |-----W=0, FCN=1----->| |-----W=0, FCN=0----->| (no ACK) |-----W=1, FCN=6----->| |-----W=1, FCN=5----->| |-----W=1, FCN=4----->| |--W=1, FCN=7 +MIC-->|MIC checked:MIC-->| Integrity check: success=> |<----|<-- ACK,W=1 ------|W=1, C=1 ---| C=1 (End) Figure31:26: Transmission in ACK-on-Error mode ofan IPv6 packet carried bya SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, MAX_WIND_FCN=6 and noloss.lost SCHC Fragment. Figure3227 illustrates the transmission in ACK-on-Error mode ofan IPv6 packet that needsa SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, MAX_WIND_FCN=6 and three lostfragments.SCHC Fragments. Sender Receiver |-----W=0, FCN=6----->| |-----W=0, FCN=5----->| |-----W=0, FCN=4--X-->| |-----W=0, FCN=3----->| |-----W=0, FCN=2--X-->|7|-----W=0, FCN=1----->|/|-----W=0, FCN=0----->| 6543210|<-----ACK, W=0-------|Bitmap:1101011|<-- ACK, W=0, C=0 ---| Bitmap:1101011 |-----W=0, FCN=4----->| |-----W=0, FCN=2----->| (no ACK) |-----W=1, FCN=6----->| |-----W=1, FCN=5----->| |-----W=1, FCN=4--X-->| |- W=1, FCN=7 + MIC->|MIC checked: failed |<-----ACK, W=1-------|C=0->| Integrity check: failure |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001 |-----W=1,FCN=4----->|MIC checked:FCN=4----->| Integrity check: success=> |<----|<-- ACK,W=1 ------|C=1, no BitmapW=1, C=1 ---| C=1 (End) Figure32:27: Transmission in ACK-on-Error mode ofan IPv6 packet carried bya SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, MAX_WIND_FCN=6 and three lostfragments.SCHC Fragments. Figure3328 shows an example of a transmission in ACK-on-Error mode of a SCHC Packet fragmented in 73 tiles, with N=5, MAX_WIND_FCN=27, M=2 and 3 lost SCHC Fragments. Sender Receiver |-----W=0, FCN=27----->| 4 tiles sent |-----W=0, FCN=23----->| 4 tiles sent |-----W=0, FCN=19----->| 4 tiles sent |-----W=0, FCN=15--X-->| 4 tiles sent (not received) |-----W=0, FCN=11----->| 4 tiles sent |-----W=0, FCN=7 ----->| 4 tiles sent |-----W=0, FCN=3 ----->| 4 tiles sent |-----W=1, FCN=27----->| 4 tiles sent |-----W=1, FCN=23----->| 4 tiles sent |-----W=1, FCN=19----->| 4 tiles sent |-----W=1, FCN=15----->| 4 tiles sent |-----W=1, FCN=11----->| 4 tiles sent |-----W=1, FCN=7 ----->| 4 tiles sent |-----W=1, FCN=3 --X-->| 4 tiles sent (not received) |-----W=2, FCN=27----->| 4 tiles sent |-----W=2, FCN=23----->| 4 tiles sent ^ |-----W=2, FCN=19----->| 1 tile sent | |-----W=2, FCN=18----->| 1 tile sent | |-----W=2, FCN=17----->| 1 tile sent |-----W=2, FCN=16----->| 1 tile sent s |-----W=2, FCN=15----->| 1 tile sent m |-----W=2, FCN=14----->| 1 tile sent a |-----W=2, FCN=13--X-->| 1 tile sent (not received) l |-----W=2, FCN=12----->| 1 tile sent l |---W=2, FCN=31 + MIC->| Integrity check: failure e |<--- ACK, W=0, C=0 ---| C=0, Bitmap:1111111111110000111111111111 r |-----W=0, FCN=15----->| 1 tile sent |-----W=0, FCN=14----->| 1 tile sent L |-----W=0, FCN=13----->| 1 tile sent 2 |-----W=0, FCN=12----->| 1 tile sent |<--- ACK, W=1, C=0 ---| C=0, Bitmap:1111111111111111111111110000 M |-----W=1, FCN=3 ----->| 1 tile sent T |-----W=1, FCN=2 ----->| 1 tile sent U |-----W=1, FCN=1 ----->| 1 tile sent |-----W=1, FCN=0 ----->| 1 tile sent | |<--- ACK, W=2, C=0 ---| C=0, Bitmap:1111111111111101000000000001 | |-----W=2, FCN=13----->| Integrity check: success V |<--- ACK, W=2, C=1 ---| C=1 (End) Figure 28: ACK-on-Error mode with variable MTU. In this example, the L2 MTU becomes reduced just before sending the "W=2, FCN=19" fragment, leaving space for only 1 tile in each forthcoming SCHC Fragment. Before retransmissions, the 73 tiles are carried by a total of 25 SCHC Fragments, the last 9 being of smaller size. Note 1: Bitmaps are shown prior to compression for transmission Note 2: other sequences of events (e.g. regarding when ACKs are sent by the Receiver) are also allowed by this specification. Profiles may restrict this flexibility. Figure 29 illustrates the transmission in ACK-Always mode ofan IPv6 packet that needsa SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, with N=3, MAX_WIND_FCN=6 and no loss. Sender Receiver |-----W=0, FCN=6----->| |-----W=0, FCN=5----->| |-----W=0, FCN=4----->| |-----W=0, FCN=3----->| |-----W=0, FCN=2----->| |-----W=0, FCN=1----->| |-----W=0, FCN=0----->||<-----ACK, W=0-------||<-- ACK, W=0, C=0 ---| Bitmap:1111111 |-----W=1, FCN=6----->| |-----W=1, FCN=5----->| |-----W=1, FCN=4----->| |--W=1, FCN=7 +MIC-->|MIC checked:MIC-->| Integrity check: success=> |<-----ACK, W=1-------||<-- ACK, W=1, C=1 ---| C=1no Bitmap(End) Figure33:29: Transmission in ACK-Always mode ofan IPv6 packet carried bya SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, with N=3, MAX_WIND_FCN=6 and nolost fragment.loss. Figure3430 illustrates the transmission in ACK-Always mode ofan IPv6 packet that needsa SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, N=3, MAX_WIND_FCN=6 and three lostfragments.SCHC Fragments. Sender Receiver|-----W=1,|-----W=0, FCN=6----->||-----W=1,|-----W=0, FCN=5----->||-----W=1,|-----W=0, FCN=4--X-->||-----W=1,|-----W=0, FCN=3----->||-----W=1,|-----W=0, FCN=2--X-->|7 |-----W=1,|-----W=0, FCN=1----->|/ |-----W=1,|-----W=0, FCN=0----->| 6543210|<-----ACK, W=1-------|Bitmap:1101011 |-----W=1,|<-- ACK, W=0, C=0 ---| Bitmap:1101011 |-----W=0, FCN=4----->||-----W=1, FCN=2----->| |<-----ACK, W=1-------|Bitmap:|-----W=0, FCN=2----->| |<-- ACK, W=0, C=0 ---| Bitmap:1111111 |-----W=1, FCN=6----->||-----W=0,|-----W=1, FCN=5----->||-----W=0,|-----W=1, FCN=4--X-->||--W=0,|--W=1, FCN=7 +MIC-->|MIC checked: failed |<-----ACK, W=0-------| C= 0MIC-->| Integrity check: failure |<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001|-----W=0, FCN=4----->|MIC checked:|-----W=1, FCN=4----->| Integrity check: success=> |<-----ACK, W=0-------| C= 1 no Bitmap|<-- ACK, W=1, C=1 ---| C=1 (End) Figure34:30: Transmission in ACK-Always mode ofan IPv6 packet carried bya SCHC Packet fragmented in 11fragments,tiles, with one tile per SCHC Fragment, N=3, MAX_WIND_FCN=6 and three lostfragments.SCHC Fragments. Figure3531 illustrates the transmission in ACK-Always mode ofan IPv6 packet that needsa SCHC Packet fragmented in 6fragments,tiles, with one tile per SCHC Fragment, N=3, MAX_WIND_FCN=6, three lostfragmentsSCHC Fragments and only one retry needed to recover each lostfragment.SCHC Fragment. Sender Receiver |-----W=0, FCN=6----->| |-----W=0, FCN=5----->| |-----W=0, FCN=4--X-->| |-----W=0, FCN=3--X-->| |-----W=0, FCN=2--X-->| |--W=0, FCN=7 +MIC-->|MIC checked: failed |<-----ACK, W=0-------|C= 0MIC-->| Integrity check: failure |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 |-----W=0,FCN=4----->|MIC checked: failedFCN=4----->| Integrity check: failure |-----W=0,FCN=3----->|MIC checked: failedFCN=3----->| Integrity check: failure |-----W=0,FCN=2----->|MIC checked:FCN=2----->| Integrity check: success|<-----ACK, W=0-------|C=1 no Bitmap|<-- ACK, W=0, C=1 ---| C=1 (End) Figure35:31: Transmission in ACK-Always mode ofan IPv6 packet carried by 11 fragments,a SCHC Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, MAX_WIND_FCN=6, three lostframents and only one retry needed for each lost fragment.SCHC Fragments. Figure3632 illustrates the transmission in ACK-Always mode ofan IPv6 packet that needsa SCHC Packet fragmented in 6fragments,tiles, with one tile per SCHC Fragment, N=3, MAX_WIND_FCN=6, three lostfragments,SCHC Fragments, and the second SCHC ACK lost. Sender Receiver |-----W=0, FCN=6----->| |-----W=0, FCN=5----->| |-----W=0, FCN=4--X-->| |-----W=0, FCN=3--X-->| |-----W=0, FCN=2--X-->| |--W=0, FCN=7 +MIC-->|MIC checked: failed |<-----ACK, W=0-------|C=0MIC-->| Integrity check: failure |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 |-----W=0,FCN=4----->|MIC checked: failedFCN=4----->| Integrity check: failure |-----W=0,FCN=3----->|MIC checked: failedFCN=3----->| Integrity check: failure |-----W=0,FCN=2----->|MIC checked:FCN=2----->| Integrity check: success| X---ACK, W=0-------|C= 1 no Bitmap|<-X-ACK, W=0, C=1 ---| C=1 timeout | ||--W=0, FCN=7 + MIC-->| |<-----ACK, W=0-------|C= 1 no Bitmap|--- W=0, ACK REQ --->| ACK REQ |<-- ACK, W=0, C=1 ---| C=1 (End) Figure36:32: Transmission in ACK-Always mode ofan IPv6 packet carried by 11 fragments,a SCHC Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3, MAX_WIND_FCN=6, three lostfragments,SCHC Fragments, and the second SCHC ACK lost. Figure3733 illustrates the transmission in ACK-Always mode ofan IPv6 packet that needsa SCHC Packet fragmented in 6fragments,tiles, with N=3, MAX_WIND_FCN=6, with three lostfragments,SCHC Fragments, and one retransmittedfragmentSCHC Fragment lost again. Sender Receiver |-----W=0, FCN=6----->| |-----W=0, FCN=5----->| |-----W=0, FCN=4--X-->| |-----W=0, FCN=3--X-->| |-----W=0, FCN=2--X-->| |--W=0, FCN=7 +MIC-->|MIC checked: failed |<-----ACK, W=0-------|C=0MIC-->| Integrity check: failure |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001 |-----W=0,FCN=4----->|MIC checked: failedFCN=4----->| Integrity check: failure |-----W=0,FCN=3----->|MIC checked: failedFCN=3----->| Integrity check: failure |-----W=0, FCN=2--X-->| timeout| ||--W=0, FCN=7 + MIC-->|All-0 empty |<-----ACK, W=0-------|C=0|--- W=0, ACK REQ --->| ACK REQ |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101 |-----W=0,FCN=2----->|MIC checked:FCN=2----->| Integrity check: success|<-----ACK, W=0-------|C=1 no Bitmap|<-- ACK, W=0, C=1 ---| C=1 (End) Figure37:33: Transmission in ACK-Always mode ofan IPv6 packet carried by 11 fragments,a SCHC Packet fragmented in 6 tiles, with N=3, MAX_WIND_FCN=6, with three lostfragments,SCHC Fragments, and one retransmittedfragmentSCHC Fragment lost again. Figure3834 illustrates the transmission in ACK-Always mode ofan IPv6 packet that needsa SCHC Packet fragmented in 28fragments,tiles, with one tile per SCHC Fragment, N=5, MAX_WIND_FCN=23 and two lostfragments. Note that MAX_WIND_FCN=23 may be useful when the maximum possible Bitmap size, considering the maximum lower layer technology payload size and the value of R, is 3 bytes. Note also that the FCN of the last fragment of the packet is the one with FCN=31 (i.e. FCN=2^N-1 for N=5, or equivalently, all FCN bits set to 1).SCHC Fragments. Sender Receiver |-----W=0, FCN=23----->| |-----W=0, FCN=22----->| |-----W=0, FCN=21--X-->| |-----W=0, FCN=20----->| |-----W=0, FCN=19----->| |-----W=0, FCN=18----->| |-----W=0, FCN=17----->| |-----W=0, FCN=16----->| |-----W=0, FCN=15----->| |-----W=0, FCN=14----->| |-----W=0, FCN=13----->| |-----W=0, FCN=12----->| |-----W=0, FCN=11----->| |-----W=0, FCN=10--X-->| |-----W=0, FCN=9 ----->| |-----W=0, FCN=8 ----->| |-----W=0, FCN=7 ----->| |-----W=0, FCN=6 ----->| |-----W=0, FCN=5 ----->| |-----W=0, FCN=4 ----->| |-----W=0, FCN=3 ----->| |-----W=0, FCN=2 ----->| |-----W=0, FCN=1 ----->| |-----W=0, FCN=0 ----->| ||lcl-Bitmap:110111111111101111111111 |<------ACK, W=0-------|encoded Bitmap:1101111111111011| |<--- ACK, W=0, C=0 ---| Bitmap:110111111111101111111111 |-----W=0, FCN=21----->| |-----W=0, FCN=10----->||<------ACK, W=0-------|no Bitmap|<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111 |-----W=1, FCN=23----->| |-----W=1, FCN=22----->| |-----W=1, FCN=21----->| |--W=1, FCN=31 +MIC-->|MIC checked: sucess => |<------ACK, W=1-------|no BitmapMIC-->| Integrity check: success |<--- ACK, W=1, C=1 ---| C=1 (End) Figure38:34: Transmission in ACK-Always mode ofan IPv6 packet carried bya SCHC Packet fragmented in 28fragments,tiles, with one tile per SCHC Fragment, N=5, MAX_WIND_FCN=23 and two lostfragments.SCHC Fragments. Appendix C. Fragmentation State Machines The fragmentation state machines of the sender and the receiver, one for each of the different reliability modes, are described in the following figures: +===========+ +------------+ Init | | FCN=0 +===========+ | No Window | No Bitmap | +-------+ | +========+==+ | More Fragments | | | <--+ ~~~~~~~~~~~~~~~~~~~~ +--------> | Send | send Fragment (FCN=0) +===+=======+ | last fragment | ~~~~~~~~~~~~ | FCN = 1 v send fragment+MIC +============+ | END | +============+ Figure39:35: Sender State Machine for the No-ACK Mode +------+ Not All-1 +==========+=+ | ~~~~~~~~~~~~~~~~~~~ | + <--+ set Inactivity Timer | RCV Frag +-------+ +=+===+======+ |All-1 & All-1 & | | |MIC correct MIC wrong | |Inactivity | | |Timer Exp. | v | | +==========++ | v | Error |<-+ +========+==+ +===========+ | END | +===========+ Figure40:36: Receiver State Machine for the No-ACK Mode +=======+ | INIT | FCN!=0 & more frags | | ~~~~~~~~~~~~~~~~~~~~~~ +======++ +--+ send Window + frag(FCN) W=0 | | | FCN- Clearlocal Bitmaplcl_bm | | v setlocal Bitmaplcl_bm FCN=max value | ++==+========+ +> | | +---------------------> | SEND | | +==+===+=====+ | FCN==0 & more frags | | last frag | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ | setlocal-Bitmaplcl_bm | | setlocal-Bitmaplcl_bm | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC | set Retrans_Timer | | set Retrans_Timer | | | |Recv_wnd == wnd & | ||Lcl_Bitmap==recv_Bitmap&|lcl_bm==recv_bm & | |+----------------------++-----------------------+ |more frag | ||lcl-Bitmap!=rcv-Bitmap|| lcl_bm!=rcv-bm | |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | |Stop Retrans_Timer | | |Attemp++Attempt++ v |clearlocal_Bitmaplcl_bm v v | +=====+=+ |window=next_window +====+===+==+===+ |Resend | +---------------------+ | |Missing| +----+ Wait | |Frag | not expected wnd | | Bitmap | +=======+ ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | | | | ^ ^ |reSend(empty)All-* | | | | | | |Set Retrans_Timer | | | | |+--+Attemp+++--+Attempt++ | MIC_bit==1 & | | | +-------------------------+ Recv_window==window & | | | all missing frags sent no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer Stop Retrans_Timer| | | +=============+ | | | | END +<--------+ | | +=============+ | |AttempAttempt > MAX_ACK_REQUESTS All-1 Window & | | ~~~~~~~~~~~~~~~~~~ MIC_bit ==0 & | v Send AbortLcl_Bitmap==recv_Bitmaplcl_bm==recv_bm | +=+===========+ ~~~~~~~~~~~~ +>| ERROR | Send Abort +=============+ Figure41:37: Sender State Machine for the ACK-Always Mode Not All- & w=expected +---+ +---+w = Not expected ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ Setlocal_Bitmap(FCN)lcl_bm(FCN) | v v |discard ++===+===+===+=+ +---------------------+ Rcv +--->* ABORT | +------------------+ Window | | | +=====+==+=====+ | | All-0 & w=expect | ^ w =next & not-All | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ | | setlcl_Bitmap(FCN)|lcl_bm(FCN) | |expected = next window | | sendlocal_Bitmaplcl_bm | |Clearlocal_Bitmaplcl_bm | | | | | |w=expctw=expected & not-All | | | | ~~~~~~~~~~~~~~~~~~ | | | | setlcl_Bitmap(FCN)+-+lcl_bm(FCN)+-+ | | +--+ w=next & All-0 | | iflcl_Bitmaplcl_bm full | | | | | | ~~~~~~~~~~~~~~~ | | sendlcl_Bitmaplcl_bm | | | | | |expctexpected = nxt wnd | | v | v | | | Clearlcl_Bitmap |lcl_bm |w=expct &|w=expected& All-1 +=+=+=+==+=++ | setlcl_Bitmap(FCN)lcl_bm(FCN) | | ~~~~~~~~~~~ +->+ Wait +<+ sendlcl_Bitmaplcl_bm | | discard +--| Next | | | All-0 +---------+ Window +--->* ABORT | | ~~~~~ +-------->+========+=++ | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt | | & MIC wrong| | & MIC right | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ | | setlocal_Bitmap(FCN)|lcl_bm(FCN)| |setlcl_Bitmap(FCN)lcl_bm(FCN) | | sendlocal_Bitmap|lcl_bm| |sendlocal_Bitmaplcl_bm | | | +----------------------+ | |All-1 &w=expctw=expected | | | |& MIC wrong v +---+w=expctdw=expected & | | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong | | |setlocal_Bitmap(FCN)lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ | | |sendlocal_Bitmaplcl_bm | Wait End | setlcl_btmp(FCN)|lcl_bm(FCN)| | +--------------------->+ +--->* ABORT | | +===+====+=+-+ All-1&MIC wrong| | | ^ | ~~~~~~~~~~~~~~~| | w=expected & MIC right | +---+ sendlcl_btmplcl_bm | | ~~~~~~~~~~~~~~~~~~~~~~ | | | setlocal_Bitmap(FCN)lcl_bm(FCN) | +-+ Not All-1 | | sendlocal_Bitmaplcl_bm | | | ~~~~~~~~~ | | | | | discard ||All-1 & w=expctd|All-1&w=expected & MIC right | | | | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | |setlocal_Bitmap(FCN)lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ | |sendlocal_Bitmaplcl_bm | +<+Sendlcl_btmplcl_bm | +-------------------------->+ END | | +==========+<---------------+ --->* ABORT ~~~~~~~ Inactivity_Timer = expires WhenDWN_LinkDWL IF Inactivity_Timer expires Send DWL RequestAttemp++Attempt++ Figure42:38: Receiver State Machine for the ACK-Always Mode +=======+ | | | INIT | | | FCN!=0 & more frags +======+++--+~~~~~~~~~~~~~~~~~~~~~~W=0 | |Frag RuleID trigger |send Window+--+ Send cur_W +frag(FCN) ~~~~~~~~~~~~~~~~~~frag(FCN); ~~~~~~~~~~~~~~~~~~~ | | |FCN- Clear local BitmapFCN--; cur_W=0; FCN=max_value;| | |vsetlocal Bitmap FCN=max value[cur_W, cur_Bmp] clear [cur_W, Bmp_n];| |++=============+ +>v clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND +->+ | cur_W==rcv_W & **BACK_TO_SEND | SEND |+------------------------->[cur_W,Bmp_n]==rcv_Bmp +-------------------------->+ | & more frags | +----------------------->+ | ~~~~~~~~~~~~ | | ++===+=========+ cur_W++; |++=====+=======+| FCN==0 & more frags| |last frag clear [cur_W, Bmp_n] | | ~~~~~~~~~~~~~~~~~~~~~~~||~~~~~~~~~~~~~~~~~|~~~~~~~~~ | | setlocal-Bitmap|cur_Bmp; | |setlocal-Bitmap[cur_W, Bmp_n]; |send wnd|send cur_W +frag(all-0)|frag(All-0);| |sendwnd+frag(all-1)+MICcur_W + frag(All-1)+MIC; | | set Retrans_Timer| |set Retrans_Timer | | | | +-----------------------------------+ | |Retrans_Timer expires & | |lcl-Bitmap!=rcv-Bitmap|cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp| | |morefragmentsFrags | | | ~~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~ | |Attemp++| Attempts++; W=cur_W | | |stopRetrans_TimerRetrans_Timer; | |+-----------------+ |clear local-Bitmap| +--------+ rcv_W==Wn &| | |[cur_W,Bmp_n]==cur_Bmp; v v | | v|window = next window +=====+=====+==+==+ +====+====+ +----------------------+ +[Wn,Bmp_n]!=rcv_Bmp| | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~| | +-------------------+ | | Resend |+--------------------->+Attempts++;| +----------------------+ WaitBitmapx ACK | | Missing | W=Wn |+-- ++--------------------->+ | |FragFrags(W) +<-------------+ | rcv_W==Wn &+-+ |not expected wnd+======+====+ |++=+===+===+===+==+ +======+==+[Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ |~~~~~~~~~~~~~~~~| ~~~~~~~~~~~~~~| ^ | | | ^ | |discard frag +----+send (cur_W,+--+ | | |+-------------------++-------------+ | ALL-0-empty) | | | all missing fragsent |Retrans_Timer expires &sent(W) | | |~~~~~~~~~~~~~~~~~~~~~|No more Frag~~~~~~~~~~~~~~~~~ | Retrans_Timer expires &| | |Setset Retrans_Timer |~~~~~~~~~~~~~~~~~~~~~~~No more Frags| | | | ~~~~~~~~~~~~~~| |Stop Retrans_Timer| | stop Retrans_Timer;| | |Send ALL-1-empty|(re)send frag(All-1)+MIC | | | +-------------------------+ | | cur_W==rcv_W&| | [cur_W,Bmp_n]==rcv_Bmp&| |Local_Bitmap==Recv_Bitmap| | ~~~~~~~~~~~~~~~~~~~~~~~~~| |AttempAttempts > MAX_ACK_REQUESTS+=========+Stop Retrans_TimerNo more Frags & MIC flag==OK| ||~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~| |END +<------------------+ v Sendsend Abort+=========+ +=+=========++=========+stop Retrans_Timer| | +===========+ | END +<-----------------+ +->+ ERROR | +=========+ +===========+ Figure43:39: Sender State Machine for the ACK-on-Error Mode This is an example only. The specification in Section 8.4.3.1 is open to very different sequencing of operations. +=======+ New frag RuleID received | | ~~~~~~~~~~~~~ | INIT +-------+cur_W=0;clear([cur_W,Bmp_n]); +=======+ |sync=0 | NotAll-All* &w=expectedrcv_W==cur_W+---+ | +---++---+w = Not expected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | ||~~~~~~~~~~~~~~~~ Set local_Bitmap(FCN)| (E) set[cur_W,Bmp_n(FCN)]| v v|discard ++===+===+===+=+ +-----------------------+v | ++===+=+=+===+=+ +----------------------+ +--+All-0 & fullAll-0&Full[cur_W,Bmp_n] | ABORT *<---+ Rcv Window | |~~~~~~~~~~~~~~~~~~~~~~ |+--------------------++-------------------+ +<-+w =nextcur_W++;set Inact_timer; | |All-0 empty +->+=+=+===+======++->+=+=+=+=+=+====+ clearlcl_Bitmap[cur_W,Bmp_n] | |~~~~~~~~~~~All-0 empty(Wn)| | | | ^ ^ | |send bitmap~~~~~~~~~~~~~~ +----+ ||w=expct & not-All| | |rcv_W==cur_W &fullsync==0; | | sendACK([Wn,Bmp_n]) ||~~~~~~~~~~~~~~~~~~~~~~~~| | |& Full([cur_W,Bmp_n]) ||set lcl_Bitmap; w =nxt| | | | |& All* || last_miss_frag | |All-0 & w=expect| |w=next| |~~~~~~~~~~~~~~~~~~~~~~ | | All* &no_full Bitmaprcv_W==cur_W|(C)| |sendACK([cur_W,Bmp_n]); | | & sync==0| | | |cur_W++; clear([cur_W,Bmp_n]) | |&no_full([cur_W,Bmp_n])| |(E)| | | ~~~~~~~~~~~~~~~~ | | | |~~~~~~~~+========+ | |~~~~~~~~~~~~~~~~~sendACK([cur_W,Bmp_n])| | |Send abort| Error/| | Error/ |send local_Bitmap| |+---------->+ Abort| | | | +----+ | Abort |+-------->+========+| | v v | | |all-1 ^| +===+====+ |All-0 empty +====+===+==+=+=+ ~~~~~~~| +===+=+=+=+===+=+ (D) ^ | |~~~~~~~~~~~~~+--+ Wait x |Send abort| | |send lcl_btmp +->|| All-0 empty(Wn)+->| MissingFragm.|Frags |<-+ | | |+==============++~~~~~~~~~~~~~~ +=============+=+ | | | sendACK([Wn,Bmp_n]) +--------------+ | | *ABORT v v (A)(B) (D) All* || last_miss_frag (C) All* & sync>0 & rcv_W!=cur_W & sync>0 ~~~~~~~~~~~~ & Full([rcv_W,Bmp_n]) Wn=oldest[not full(W)]; ~~~~~~~~~~~~~~~~~~~~ sendACK([Wn,Bmp_n]) Wn=oldest[not full(W)]; sendACK([Wn,Bmp_n]);sync-- ABORT-->* Uplink Only &| | Inactivity_Timer =Inact_Timer expires (E) Not All* & rcv_W!=cur_W || Attempts > MAX_ACK_REQUESTS ~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ sync++; cur_W=rcv_W; send Abort set[cur_W,Bmp_n(FCN)] (A)(B) | |~~~~~~~~~~~~~~~~~~~~~~~~~~ ||Send Abort||All-1All-1 &w=expectrcv_W==cur_W &MIC wrongMIC!=OK All-0 empty(Wn) ||~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+All-1~~~~~~~~~~ ||set local_Bitmap(FCN)| sendACK([cur_W,Bmp_n],MIC=0) | v~~~~~~~~~~sendACK([Wn,Bmp_n]) ||send local_Bitmap +===========+==+ snd lcl_btmp| +===========+=++ | +--------------------->+ Wait End +-+ | +=====+=+====+=+ |w=expct &All-1 |w=expectedrcv_W==cur_W &MIC rightMIC==OK | | ^ |MIC wrong& rcv_W==cur_W | ~~~~~~~~~~~~~~~~~~~~~~ | | +---+~~~~~~~~~ | set&send local_Bitmap(FCN)MIC!=OK | sendACK([cur_W,Bmp_n],MIC=1) |set lcl_Bitmap(FCN)| ~~~~~~~~~~~~~~~~~~~ | | | sendACK([cur_W,Bmp_n],MIC=0); | | | Attempts++ |All-1 &w=expectedFull([cur_W,Bmp_n]) | | |& MIC==OK &MIC rightsync==0 | +-->* ABORT|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~ v|set & send local_Bitmap(FCN) +=+==========+|sendACK([cur_W,Bmp_n],MIC=1) +=+=========+ +---------------------------->+ END |+============+ --->*+===========+ ABORTOnly-->* UplinkInactivity_TimerOnly & Inact_Timer = expires~~~~~~~~~~~~~~~~~~~~~~~~~~ Send|| Attempts > MAX_ACK_REQUESTS ~~~~~~~~~~~~~~~~~~~~~ send Abort Figure44:40: Receiver State Machine for the ACK-on-Error Mode Appendix D. SCHC Parameters- Ticket #15This sectiongiveslists thelist of parametersinformation that need to bedefinedprovided in the LPWAN technology-specific documents. oDefine the mostMost common usescase and how SCHC may be deployed.cases, deployment scenarios oLPWAN Architecture. ExplainMapping of the SCHCentities (Compression and Fragmentation), how/where they are represented in the corresponding technology architecture. If applicable, explainarchitectural elements onto thevariousLPWAN architecture o Assessment of LPWAN integrity checking o Various potential channel conditions for the technology and the corresponding recommended use of SCHC C/D andF/R. o L2 fragmentation decision o Technology developers must evaluateF/R This section lists the parameters thatL2 has strong enough integrity checkingneed tomatch SCHC's assumption.be defined in the Profile. o Rule ID numberingsystem,scheme, fixed-sized or variable-sized Rule IDs, number ofRules o Size ofRules, theRule IDs o Theway the Rule ID issent (L2 or L3) and how (describe)transmitted oFragmentation deliveryPadding: size of the L2 Word (for most LPWAN technologies, this would be a byte; for some technologies, a bit) o Decision to use SCHC fragmentation mechanism or not. If yes: * reliabilitymode usedmode(s) used, in which cases (e.g. based on link channel condition)o Define the* Rule ID values assigned to each mode in use * presence and number of bits forFCN (N) andDTag (T)o in particular, isfor each Rule ID value * support for interleaved packettransmission supported andtransmission, to what extento The MIC algorithm to be used* WINDOW_SIZE, for modes that use windows * number of bits for W (M) for each Rule ID value, for modes that use windows * number of bits for FCN (N) for each Rule ID value * value of MAX_WIND_FCN and use of FCN values, if applicable to thesize,SCHC F/R mode. * size of MIC and algorithm for its computation, for each Rule ID, if different from the defaultCRC32 oCRC32. Byte fill-up with zeroes or other mechanism, to be specified. * Retransmission Timer durationofor each Rule ID value, if applicable to the SCHC F/R mode * Inactivity Timer durationo Definefor each Rule ID value, if applicable to the SCHC F/R mode * MAX_ACK_REQUEST(number of attempts) o Padding: size ofvalue for each Rule ID value, if applicable to the SCHC F/R mode o if L2 Word(for most technologies, a byte; for some technologies,is wider than abit). Value of the padding bits (1 or 0). Thebit and SCHC fragmentation is used, value of the padding bitsneeds to be specified(0 or 1). This is needed because the padding bits of the last fragment are included in the MICcalculation. o Take into account thatcomputation. A Profile MAY define a delay to be added between each SCHC message transmission to respect local regulations or other constraints imposed by thelengthapplications. o Note on soliciting downlink transmissions: In some LPWAN technologies, as part ofRule ID + N + T + W when possibleenergy-saving techniques, downlink transmission isgoodonly possible immediately after an uplink transmission. In order tohaveavoid potentially high delay in the downlink transmission of amultiplefragmented SCHC Packet, the SCHC Fragment receiver may want to perform an uplink transmission as soon as possible after reception of8 bitsa SCHC Fragment that is not the last one. Such uplink transmission may be triggered by the L2 (e.g. an L2 ACK sent in response tocompleteabyte and avoid paddingSCHC Fragment encapsulated in a L2 PDU that requires an L2 ACK) or it may be triggered from an upper layer. oIntheACK formatfollowing parameters need tohavebe addressed in documents other than this one but not forcely in the LPWAN technology-specific documents: * The way the contexts are provisioned * The way the Rules as generated Appendix E. Supporting multiple window sizes for fragmentation For ACK-Always or ACK-on-Error, implementers MAY opt to support alengthsingle window size or multiple window sizes. The latter, when feasible, may provide performance optimizations. For example, a large window size SHOULD be used forRule ID + T + W bit intopackets that need to be carried by acompletelarge number ofbyteSCHC Fragments. However, when the number of SCHC Fragments required todo optimization more easily o The technology documents will describe ifcarry a packet is low, a smaller window size, and thus a shorter Bitmap, MAY be sufficient to provide feedback on all SCHC Fragments. If multiple window sizes are supported, the Rule IDis constrained by any alignment o When fragmentingMAY be used to signal the window size inACK-on-Error or ACK-Always mode, it is expecteduse for a specific packet transmission. Note that thelastsame window(called All-1 window) will not be fully utilised, i.e. there won'tsize MUST befragments withused for the transmission of allFCN values from MAX_WIND_FCN downto 1 and finally All-1. It is worth notingSCHC Fragments that belong to the same SCHC Packet. Appendix F. Downlink SCHC Fragment transmission For downlink transmission of a fragmented SCHC Packet in ACK-Always mode, the SCHC Fragment receiver MAY support timer-based SCHC ACK retransmission. In thisdocumentmechanism, the SCHC Fragment receiver initializes and starts a timer (the Inactivity Timer is used) after the transmission of a SCHC ACK, except when the SCHC ACK is sent in response to the last SCHC Fragment of a packet (All-1 fragment). In the latter case, the SCHC Fragment receiver does notmandatestart a timer after transmission of the SCHC ACK. If, after transmission of a SCHC ACK thatother windows (called All-0 windows) are fully utilised either. This document purposely doesis notspecify thatan All-1windows use Bitmaps with the same number of bits as All-0 windows do. By default, Bitmaps for All-0fragment, andAll-1 windows arebefore expiration of thesame size MAX_WIND_FCN + 1. Butcorresponding Inactivity timer, the SCHC Fragment receiver receives atechnology-specific document MAY revertSCHC Fragment thatdecision. The rationalebelongs to the current window (e.g. a missing SCHC Fragment from the current window) or to the next window, the Inactivity timer forrevertingthedecision could beSCHC ACK is stopped. However, if thefollowing: Note thatInactivity timer expires, the SCHC ACKsentis resent and the Inactivity timer is reinitialized and restarted. The default initial value for the Inactivity timer, as well as the maximum number of retries for aresponsespecific SCHC ACK, denoted MAX_ACK_RETRIES, are not defined in this document, and need toan All-1 fragment includesbe defined in aC bitProfile. The initial value of the Inactivity timer is expected to be greater than that of the Retransmission timer, in order to make sure that a (buffered) SCHCACKFragment to be retransmitted can find an opportunity forother windows don't have. Therefore,that transmission. When the SCHCACK forFragment sender transmits the All-1window is one bit bigger. An L2 technologyfragment, it starts its Retransmission Timer with aseverely constrained payload size might decidelarge timeout value (e.g. several times that of the initial Inactivity timer). If a SCHC ACK is received before expiration of this"bump" intimer, the SCHC Fragment sender retransmits any lost SCHC Fragments reported by the SCHC ACK, or if the SCHC ACKforconfirms successful reception of all SCHC Fragments of the lastfragment is a bad resource usage. It could thus mandate thatwindow, theAll-1 windowtransmission of the fragmented SCHC Packet isnot allowed to useconsidered complete. If theFCN value 1timer expires, and no SCHC ACK has been received since the start of the timer, the SCHC Fragment sender assumes that the All-1 fragment has been successfully received (and possibly, the last SCHC ACKBitmap size is reduced by 1 bit. This provides room for the C bit without creating a bump inhas been lost: this mechanism assumes that theSCHC ACK. Andretransmission timer for thefollowing parameters needAll-1 fragment is long enough tobe addressed in another document but not forcely in the technology-specific one: o The wayallow several SCHC ACK retries if thecontexts are provisioning o The wayAll-1 fragment has not;been received by theRules as generatedSCHC Fragment receiver, and it also assumes that it is unlikely that several ACKs become all lost). AppendixE.G. Note Carles Gomez has been funded in part by the Spanish Government (Ministerio de Educacion, Cultura y Deporte) through the Jose Castillejo grant CAS15/00336, and by the ERDF and the Spanish Government through project TEC2016-79988-P. Part of his contribution to this work has been carried out during his stay as a visiting scholar at the Computer Laboratory of the University of Cambridge. Authors' Addresses Ana Minaburo Acklio 1137A avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France Email: ana@ackl.io Laurent Toutain IMT-Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@imt-atlantique.fr Carles Gomez Universitat Politecnica de Catalunya C/Esteve Terradas, 7 08860 Castelldefels Spain Email: carlesgo@entel.upc.edu Dominique Barthel Orange Labs 28 chemin du Vieux Chene 38243 Meylan France Email: dominique.barthel@orange.com Juan Carlos Zuniga SIGFOX 425 rue Jean Rostand Labege 31670 France Email: JuanCarlos.Zuniga@sigfox.com