< draft-ietf-lpwan-ipv6-static-context-hc-16.txt   draft-ietf-lpwan-ipv6-static-context-hc-17.txt >
lpwan Working Group A. Minaburo lpwan Working Group A. Minaburo
Internet-Draft Acklio Internet-Draft Acklio
Intended status: Standards Track L. Toutain Intended status: Standards Track L. Toutain
Expires: December 31, 2018 IMT-Atlantique Expires: April 25, 2019 IMT-Atlantique
C. Gomez C. Gomez
Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya
D. Barthel D. Barthel
Orange Labs Orange Labs
June 29, 2018 JC. Zuniga
SIGFOX
October 22, 2018
LPWAN Static Context Header Compression (SCHC) and fragmentation for LPWAN Static Context Header Compression (SCHC) and fragmentation for
IPv6 and UDP IPv6 and UDP
draft-ietf-lpwan-ipv6-static-context-hc-16 draft-ietf-lpwan-ipv6-static-context-hc-17
Abstract Abstract
This document defines the Static Context Header Compression (SCHC) This document defines the Static Context Header Compression (SCHC)
framework, which provides both header compression and fragmentation framework, which provides both header compression and fragmentation
functionalities. SCHC has been tailored for Low Power Wide Area functionalities. SCHC has been designed for Low Power Wide Area
Networks (LPWAN). Networks (LPWAN).
SCHC compression is based on a common static context stored in both SCHC compression is based on a common static context stored in both
the LPWAN devices and the network side. This document defines a the LPWAN device and the network side. This document defines a
header compression mechanism and its application to compress IPv6/UDP header compression mechanism and its application to compress IPv6/UDP
headers. headers.
This document also specifies a fragmentation and reassembly mechanism This document also specifies a fragmentation and reassembly mechanism
that is used to support the IPv6 MTU requirement over the LPWAN that is used to support the IPv6 MTU requirement over the LPWAN
technologies. Fragmentation is needed for IPv6 datagrams that, after technologies. Fragmentation is needed for IPv6 datagrams that, after
SCHC compression or when such compression was not possible, still SCHC compression or when such compression was not possible, still
exceed the layer two maximum payload size. exceed the layer-2 maximum payload size.
The SCHC header compression and fragmentation mechanisms are The SCHC header compression and fragmentation mechanisms are
independent of the specific LPWAN technology over which they are independent of the specific LPWAN technology over which they are
used. Note that this document defines generic functionalities and used. This document defines generic functionalities and offers
advisedly offers flexibility with regard to parameter settings and flexibility with regard to parameter settings and mechanism choices.
mechanism choices. Such settings and choices are expected to be made Technology-specific and product-specific settings and choices are
in other technology-specific documents. expected to be grouped into Profiles specified in other documents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 31, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 38
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5 3. LPWAN Architecture . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 9 5. SCHC overview . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. SCHC Packet format . . . . . . . . . . . . . . . . . . . 10
7. Static Context Header Compression . . . . . . . . . . . . . . 13 5.2. Functional mapping . . . . . . . . . . . . . . . . . . . 11
7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 14 6. Rule ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 16 7. Compression/Decompression . . . . . . . . . . . . . . . . . . 12
7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 16 7.1. SCHC C/D Rules . . . . . . . . . . . . . . . . . . . . . 12
7.4. Matching operators . . . . . . . . . . . . . . . . . . . 18 7.2. Rule ID for SCHC C/D . . . . . . . . . . . . . . . . . . 14
7.5. Compression Decompression Actions (CDA) . . . . . . . . . 18 7.3. Packet processing . . . . . . . . . . . . . . . . . . . . 15
7.5.1. not-sent CDA . . . . . . . . . . . . . . . . . . . . 20 7.4. Matching operators . . . . . . . . . . . . . . . . . . . 16
7.5.2. value-sent CDA . . . . . . . . . . . . . . . . . . . 20 7.5. Compression Decompression Actions (CDA) . . . . . . . . . 17
7.5.3. mapping-sent CDA . . . . . . . . . . . . . . . . . . 20 7.5.1. processing variable-length fields . . . . . . . . . . 17
7.5.4. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 20 7.5.2. not-sent CDA . . . . . . . . . . . . . . . . . . . . 18
7.5.5. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 21 7.5.3. value-sent CDA . . . . . . . . . . . . . . . . . . . 18
7.5.6. Compute-* . . . . . . . . . . . . . . . . . . . . . . 21 7.5.4. mapping-sent CDA . . . . . . . . . . . . . . . . . . 18
8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 21 7.5.5. LSB CDA . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 7.5.6. DevIID, AppIID CDA . . . . . . . . . . . . . . . . . 19
8.2. Fragmentation Tools . . . . . . . . . . . . . . . . . . . 22 7.5.7. Compute-* . . . . . . . . . . . . . . . . . . . . . . 19
8.3. Reliability modes . . . . . . . . . . . . . . . . . . . . 25 8. Fragmentation/Reassembly . . . . . . . . . . . . . . . . . . 20
8.4. Fragmentation Formats . . . . . . . . . . . . . . . . . . 27 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 20
8.4.1. Fragments that are not the last one . . . . . . . . . 27 8.2. SCHC F/R Tools . . . . . . . . . . . . . . . . . . . . . 20
8.4.2. All-1 fragment . . . . . . . . . . . . . . . . . . . 29 8.2.1. Messages . . . . . . . . . . . . . . . . . . . . . . 20
8.4.3. SCHC ACK format . . . . . . . . . . . . . . . . . . . 31 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters . . . . . . 21
8.4.4. Abort formats . . . . . . . . . . . . . . . . . . . . 33 8.2.3. Integrity Checking . . . . . . . . . . . . . . . . . 23
8.5. Baseline mechanism . . . . . . . . . . . . . . . . . . . 35 8.2.4. Header Fields . . . . . . . . . . . . . . . . . . . . 24
8.5.1. No-ACK . . . . . . . . . . . . . . . . . . . . . . . 36 8.3. SCHC F/R Message Formats . . . . . . . . . . . . . . . . 26
8.5.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 36 8.3.1. SCHC Fragment format . . . . . . . . . . . . . . . . 26
8.5.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 39 8.3.2. SCHC ACK format . . . . . . . . . . . . . . . . . . . 27
8.6. Supporting multiple window sizes . . . . . . . . . . . . 40 8.3.3. SCHC ACK REQ format . . . . . . . . . . . . . . . . . 30
8.7. Downlink SCHC Fragment transmission . . . . . . . . . . . 41 8.3.4. SCHC Abort formats . . . . . . . . . . . . . . . . . 31
9. Padding management . . . . . . . . . . . . . . . . . . . . . 42 8.4. SCHC F/R modes . . . . . . . . . . . . . . . . . . . . . 33
10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 43 8.4.1. No-ACK mode . . . . . . . . . . . . . . . . . . . . . 33
10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 43 8.4.2. ACK-Always . . . . . . . . . . . . . . . . . . . . . 36
10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 43 8.4.3. ACK-on-Error . . . . . . . . . . . . . . . . . . . . 42
10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 44 9. Padding management . . . . . . . . . . . . . . . . . . . . . 49
10.4. Payload Length field . . . . . . . . . . . . . . . . . . 44 10. SCHC Compression for IPv6 and UDP headers . . . . . . . . . . 50
10.5. Next Header field . . . . . . . . . . . . . . . . . . . 44 10.1. IPv6 version field . . . . . . . . . . . . . . . . . . . 50
10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 45 10.2. IPv6 Traffic class field . . . . . . . . . . . . . . . . 51
10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 45 10.3. Flow label field . . . . . . . . . . . . . . . . . . . . 51
10.7.1. IPv6 source and destination prefixes . . . . . . . . 45 10.4. Payload Length field . . . . . . . . . . . . . . . . . . 51
10.7.2. IPv6 source and destination IID . . . . . . . . . . 46 10.5. Next Header field . . . . . . . . . . . . . . . . . . . 52
10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 46 10.6. Hop Limit field . . . . . . . . . . . . . . . . . . . . 52
10.9. UDP source and destination port . . . . . . . . . . . . 46 10.7. IPv6 addresses fields . . . . . . . . . . . . . . . . . 52
10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 47 10.7.1. IPv6 source and destination prefixes . . . . . . . . 52
10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 47 10.7.2. IPv6 source and destination IID . . . . . . . . . . 53
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10.8. IPv6 extensions . . . . . . . . . . . . . . . . . . . . 53
12. Security considerations . . . . . . . . . . . . . . . . . . . 48 10.9. UDP source and destination port . . . . . . . . . . . . 53
10.10. UDP length field . . . . . . . . . . . . . . . . . . . . 54
10.11. UDP Checksum field . . . . . . . . . . . . . . . . . . . 54
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
12. Security considerations . . . . . . . . . . . . . . . . . . . 55
12.1. Security considerations for SCHC 12.1. Security considerations for SCHC
Compression/Decompression . . . . . . . . . . . . . . . 48 Compression/Decompression . . . . . . . . . . . . . . . 55
12.2. Security considerations for SCHC 12.2. Security considerations for SCHC
Fragmentation/Reassembly . . . . . . . . . . . . . . . . 48 Fragmentation/Reassembly . . . . . . . . . . . . . . . . 55
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
14.1. Normative References . . . . . . . . . . . . . . . . . . 50 14.1. Normative References . . . . . . . . . . . . . . . . . . 57
14.2. Informative References . . . . . . . . . . . . . . . . . 50 14.2. Informative References . . . . . . . . . . . . . . . . . 57
Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 51 Appendix A. SCHC Compression Examples . . . . . . . . . . . . . 58
Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 54 Appendix B. Fragmentation Examples . . . . . . . . . . . . . . . 61
Appendix C. Fragmentation State Machines . . . . . . . . . . . . 60 Appendix C. Fragmentation State Machines . . . . . . . . . . . . 68
Appendix D. SCHC Parameters - Ticket #15 . . . . . . . . . . . . 67 Appendix D. SCHC Parameters . . . . . . . . . . . . . . . . . . 75
Appendix E. Note . . . . . . . . . . . . . . . . . . . . . . . . 68 Appendix E. Supporting multiple window sizes for fragmentation . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 Appendix F. Downlink SCHC Fragment transmission . . . . . . . . 77
Appendix G. Note . . . . . . . . . . . . . . . . . . . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
1. Introduction 1. Introduction
This document defines the Static Context Header Compression (SCHC) This document defines the Static Context Header Compression (SCHC)
framework, which provides both header compression and fragmentation framework, which provides both header compression and fragmentation
functionalities. SCHC has been tailored for Low Power Wide Area functionalities. SCHC has been designed for Low Power Wide Area
Networks (LPWAN). Networks (LPWAN).
Header compression is needed to efficiently bring Internet Header compression is needed for efficient Internet connectivity to
connectivity to the node within an LPWAN network. Some LPWAN the node within an LPWAN network. Some LPWAN networks properties can
networks properties can be exploited to get an efficient header be exploited to get an efficient header compression:
compression:
o The network topology is star-oriented, which means that all o The network topology is star-oriented, which means that all
packets follow the same path. For the needs of this document, the packets between the same source-destination pair follow the same
architecture can simply be described as Devices (Dev) exchanging path. For the needs of this document, the architecture can simply
information with LPWAN Application Servers (App) through Network be described as Devices (Dev) exchanging information with LPWAN
Gateways (NGW). Application Servers (App) through a Network Gateway (NGW).
o Because devices embed built-in applications, the traffic flows to o Because devices embed built-in applications, the traffic flows to
be compressed are known in advance. Indeed, new applications be compressed are known in advance. Indeed, new applications are
cannot be easily installed in LPWAN devices, as they would in less frequently installed in an LPWAN device, as they are in a
computers or smartphones. computer or smartphone.
The Static Context Header Compression (SCHC) is defined for this SCHC compression uses a context in which information about header
environment. SCHC uses a context, in which information about header fields is stored. This context is static: the values of the header
fieds is stored. This context is static: the values of the header
fields do not change over time. This avoids complex fields do not change over time. This avoids complex
resynchronization mechanisms, that would be incompatible with LPWAN resynchronization mechanisms. Indeed, downlink is often more
characteristics. In most cases, a small context identifier is enough restricted/expensive, perhaps completely unavailable [RFC8376]. A
to represent the full IPv6/UDP headers. The SCHC header compression compression protocol that relies on feedback is not compatible with
mechanism is independent of the specific LPWAN technology over which the characteristics of such LPWANs.
it is used.
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 LPWAN technologies impose some strict limitations on traffic. For
instance, devices are sleeping most of the time and MAY receive data instance, devices are sleeping most of the time and may receive data
during short periods of time after transmission to preserve battery. during short periods of time after transmission to preserve battery.
LPWAN technologies are also characterized, among others, by a very LPWAN technologies are also characterized by a greatly reduced data
reduced data unit and/or payload size (see [RFC8376]). However, some unit and/or payload size (see [RFC8376]). However, some LPWAN
of these technologies do not provide fragmentation functionality, technologies do not provide fragmentation functionality; to support
therefore the only option for them to support the IPv6 MTU the IPv6 MTU requirement of 1280 bytes [RFC8200], they require a
requirement of 1280 bytes [RFC8200] is to use a fragmentation fragmentation protocol at the adaptation layer below IPv6.
protocol at the adaptation layer, below IPv6. In response to this Accordingly, this document defines an fragmentation/reassembly
need, this document also defines a fragmentation/reassembly mechanism for LPWAN technologies to supports the IPv6 MTU. Its
mechanism, which supports the IPv6 MTU requirement over LPWAN implementation is optional. If not interested, the reader can safely
technologies. Such functionality has been designed under the skip its description.
assumption that there is no out-of-sequence delivery of data units
between the entity performing fragmentation and the entity performing
reassembly.
Note that this document defines generic functionality and This document defines generic functionality and offers flexibility
purposefully offers flexibility with regard to parameter settings and with regard to parameters settings and mechanism choices.
mechanism choices. Such settings and choices are expected to be made Technology-specific settings and product-specific and choices are
in other, technology-specific documents. expected to be grouped into Profiles specified in other documents.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. LPWAN Architecture 3. LPWAN Architecture
skipping to change at page 5, line 39 skipping to change at page 6, line 4
o The Radio Gateway (RGW), which is the end point of the constrained o The Radio Gateway (RGW), which is the end point of the constrained
link. link.
o The Network Gateway (NGW) is the interconnection node between the o The Network Gateway (NGW) is the interconnection node between the
Radio Gateway and the Internet. Radio Gateway and the Internet.
o LPWAN-AAA Server, which controls the user authentication and the o LPWAN-AAA Server, which controls the user authentication and the
applications. applications.
o Application Server (App) o Application Server (App)
+------+ +------+
() () () | |LPWAN-| () () () | |LPWAN-|
() () () () / \ +---------+ | AAA | () () () () / \ +---------+ | AAA |
() () () () () () / \======| ^ |===|Server| +-----------+ () () () () () () / \======| ^ |===|Server| +-----------+
() () () | | <--|--> | +------+ |APPLICATION| () () () | | <--|--> | +------+ |APPLICATION|
() () () () / \==========| v |=============| (App) | () () () () / \==========| v |=============| (App) |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
Dev Radio Gateways NGW Dev Radio Gateways NGW
Figure 1: LPWAN Architecture Figure 1: LPWAN Architecture
4. Terminology 4. Terminology
This section defines the terminology and acronyms used in this This section defines the terminology and acronyms used in this
document. document.
Note that the SCHC acronym is pronounced like "sheek" in English (or Note that the SCHC acronym is pronounced like "sheek" in English (or
"chic" in French). Therefore, this document writes "a SCHC Packet" "chic" in French). Therefore, this document writes "a SCHC Packet"
instead of "an SCHC Packet". instead of "an SCHC Packet".
o Abort. 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.
o App: LPWAN Application. An application sending/receiving IPv6 o App: LPWAN Application. An application sending/receiving IPv6
packets to/from the Device. packets to/from the Device.
o AppIID: Application Interface Identifier. The IID that identifies o AppIID: Application Interface Identifier. The IID that identifies
the application server interface. the application server interface.
o Bi: Bidirectional. Characterises a Rule Entry that applies to o Bi: Bidirectional. Characterises a Field Descriptor that applies
headers of packets travelling in either direction (Up and Dw, see to headers of packets travelling in either direction (Up and Dw,
this glossary). see this glossary).
o Bitmap: 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).
o CDA: Compression/Decompression Action. Describes the reciprocal o CDA: Compression/Decompression Action. Describes the reciprocal
pair of actions that are performed at the compressor to compress a pair of actions that are performed at the compressor to compress a
header field and at the decompressor to recover the original header field and at the decompressor to recover the original
header field value. header field value.
o Compression Residue. The bits that need to be sent (beyond the o Compression Residue. The bits that need to be sent (beyond the
Rule ID itself) after applying the SCHC compression over each Rule ID itself) after applying the SCHC compression over each
header field. header field.
skipping to change at page 7, line 23 skipping to change at page 7, line 9
o Dev: Device. A node connected to an LPWAN. A Dev SHOULD o Dev: Device. A node connected to an LPWAN. A Dev SHOULD
implement SCHC. implement SCHC.
o DevIID: Device Interface Identifier. The IID that identifies the o DevIID: Device Interface Identifier. The IID that identifies the
Dev interface. Dev interface.
o DI: Direction Indicator. This field tells which direction of o DI: Direction Indicator. This field tells which direction of
packet travel (Up, Dw or Bi) a Rule applies to. This allows for packet travel (Up, Dw or Bi) a Rule applies to. This allows for
assymmetric processing. assymmetric processing.
o DTag: Datagram Tag. This SCHC F/R header field is set to the same
value for all SCHC Fragments carrying the same SCHC Packet.
o Dw: Downlink direction for compression/decompression in both o Dw: Downlink direction for compression/decompression in both
sides, from SCHC C/D in the network to SCHC C/D in the Dev. sides, from SCHC C/D in the network to SCHC C/D in the Dev.
o FCN: Fragment Compressed Number. This SCHC F/R header field
carries an efficient representation of a larger-sized fragment
number.
o Field Description. A line in the Rule table. o Field Description. A line in the Rule table.
o FID: Field Identifier. This is an index to describe the header o FID: Field Identifier. This is an index to describe the header
fields in a Rule. fields in a Rule.
o FL: Field Length is the length of the packet header field. It is 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 expressed in bits for header fields of fixed lengths or as a type
(e.g. variable, token length, ...) for field lengths that are (e.g. variable, token length, ...) for field lengths that are
unknown at the time of Rule creation. The length of a header unknown at the time of Rule creation. The length of a header
field is defined in the corresponding protocol specification. field is defined in the corresponding protocol specification (such
as IPv6 or UDP).
o FP: Field Position is a value that is used to identify the o FP: Field Position is a value that is used to identify the
position where each instance of a field appears in the header. position where each instance of a field appears in the header.
o IID: Interface Identifier. See the IPv6 addressing architecture o IID: Interface Identifier. See the IPv6 addressing architecture
[RFC7136] [RFC7136]
o Inactivity 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.
o L2: Layer two. The immediate lower layer SCHC interfaces with. o L2: Layer two. The immediate lower layer SCHC interfaces with.
It is provided by an underlying LPWAN technology. 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 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. 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 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 bit. The L2 Word size is assumed to be constant over time for
each device. each device.
o MIC: 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.
o MO: Matching Operator. An operator used to match a value o MO: Matching Operator. An operator used to match a value
contained in a header field with a value contained in a Rule. 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 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. unit that it passes to the underlying Layer 2 for transmission.
SCHC itself operates on bits, not bytes, and does not have any SCHC itself operates on bits, not bytes, and does not have any
alignment prerequisite. See Section 9. alignment prerequisite. See Section 9.
o Retransmission Timer. A timer used by the SCHC Fragment sender o Profile: SCHC offers variations in the way it is operated, with a
during an on-going fragmented SCHC Packet transmission to detect number of parameters listed in Appendix D. A Profile indicates a
possible link errors when waiting for a possible incoming SCHC particular setting of all these parameters. Both ends of a SCHC
ACK. 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 Rule: A set of header field values.
o Rule entry: A column in a Rule that describes a parameter of the
header field.
o Rule ID: An identifier for a Rule. SCHC C/D on both sides share o Rule ID: 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 the same Rule ID for a given packet. A set of Rule IDs are used
to support SCHC F/R functionality. to support SCHC F/R functionality.
o SCHC ACK: 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 SCHC C/D: Static Context Header Compression Compressor/ o SCHC C/D: Static Context Header Compression Compressor/
Decompressor. A mechanism used on both sides, at the Dev and at Decompressor. A mechanism used on both sides, at the Dev and at
the network, to achieve Compression/Decompression of headers. the network, to achieve Compression/Decompression of headers.
SCHC C/D uses Rules to perform compression and decompression. SCHC C/D uses Rules to perform compression and decompression.
o SCHC F/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 SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been o SCHC Packet: A packet (e.g. an IPv6 packet) whose header has been
compressed as per the header compression mechanism defined in this compressed as per the header compression mechanism defined in this
document. If the header compression process is unable to actually document. If the header compression process is unable to actually
compress the packet header, the packet with the uncompressed compress the packet header, the packet with the uncompressed
header is still called a SCHC Packet (in this case, a Rule ID is 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). used to indicate that the packet header has not been compressed).
See Section 7 for more details. See Section 7 for more details.
o TV: Target value. A value contained in a Rule that will be o TV: Target value. A value contained in a Rule that will be
matched with the value of a header field. matched with the value of a header field.
o Up: Uplink direction for compression/decompression in both sides, o Up: Uplink direction for compression/decompression in both sides,
from the Dev SCHC C/D to the network SCHC C/D. 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 Additional terminology for the optional SCHC Fragmentation /
or ACK-Always mode Section 8, which carries the same value for all Reassembly mechanism (SCHC F/R) is found in Section 8.2.
SCHC Fragments of a window.
o Window: A subset of the SCHC Fragments needed to carry a SCHC
Packet (see Section 8).
5. SCHC overview 5. SCHC overview
SCHC can be abstracted as an adaptation layer between IPv6 and the SCHC can be characterized as an adaptation layer between IPv6 and the
underlying LPWAN technology. SCHC comprises two sublayers (i.e. the underlying LPWAN technology. SCHC comprises two sublayers (i.e. the
Compression sublayer and the Fragmentation sublayer), as shown in Compression sublayer and the Fragmentation sublayer), as shown in
Figure 2. Figure 2.
+----------------+ +----------------+
| IPv6 | | IPv6 |
+- +----------------+ +- +----------------+
| | Compression | | | Compression |
SCHC < +----------------+ SCHC < +----------------+
| | Fragmentation | | | Fragmentation |
skipping to change at page 10, line 22 skipping to change at page 9, line 22
|LPWAN technology| |LPWAN technology|
+----------------+ +----------------+
Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN Figure 2: Protocol stack comprising IPv6, SCHC and an LPWAN
technology technology
As per this document, when a packet (e.g. an IPv6 packet) needs to be 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 transmitted, header compression is first applied to the packet. The
resulting packet after header compression (whose header may or may resulting packet after header compression (whose header may or may
not actually be smaller than that of the original packet) is called a not actually be smaller than that of the original packet) is called a
SCHC Packet. If the SCHC Packet size exceeds the layer 2 (L2) MTU, SCHC Packet. If the SCHC Packet needs to be fragmented by the
fragmentation is then applied to the SCHC Packet. The SCHC Packet or optional SCHC Fragmentation, fragmentation is then applied to the
the SCHC Fragments are then transmitted over the LPWAN. The SCHC Packet. The SCHC Packet or the SCHC Fragments are then
reciprocal operations take place at the receiver. This process is transmitted over the LPWAN. The reciprocal operations take place at
illustrated in Figure 3. the receiver. This process is illustrated in Figure 3.
A packet (e.g. an IPv6 packet) A packet (e.g. an IPv6 packet)
| ^ | ^
v | v |
+------------------+ +--------------------+ +------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression | | SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+ +------------------+ +--------------------+
| ^ | ^
| If no fragmentation (*) | | If no fragmentation (*) |
+-------------- SCHC Packet -------------->| +-------------- SCHC Packet -------------->|
skipping to change at page 11, line 27 skipping to change at page 10, line 27
| SCHC Fragmentation | | SCHC Reassembly | | SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| +-------------- SCHC ACK -------------+ | | +-------------- SCHC ACK -------------+ |
| | | |
+-------------- SCHC Fragments -------------------+ +-------------- SCHC Fragments -------------------+
SENDER RECEIVER SENDER RECEIVER
*: the decision to use Fragmentation or not is left to each LPWAN *: the decision to use Fragmentation or not is left to each Profile.
technology over which SCHC is applied. See LPWAN
technology-specific documents.
Figure 3: SCHC operations taking place at the sender and the receiver Figure 3: SCHC operations at the SENDER and the RECEIVER
5.1. SCHC Packet format
The SCHC Packet is composed of the Compressed Header followed by the The SCHC Packet is composed of the Compressed Header followed by the
payload from the original packet (see Figure 4). The Compressed payload from the original packet (see Figure 4). The Compressed
Header itself is composed of a Rule ID and a Compression Residue. Header itself is composed of the Rule ID and a Compression Residue,
The Compression Residue may be absent, see Section 7. Both the Rule which is the output of the compression actions of the Rule that was
ID and the Compression Residue potentially have a variable size, and applied (see Section 7). The Compression Residue may be empty. Both
generally are not a mutiple of bytes in size. 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 | | Rule ID + Compression Residue |
+---------------------------------+--------------------+ +---------------------------------+--------------------+
| Compressed Header | Payload | | Compressed Header | Payload |
+---------------------------------+--------------------+ +---------------------------------+--------------------+
Figure 4: SCHC Packet Figure 4: SCHC Packet
The Fragment Header size is variable and depends on the Fragmentation 5.2. Functional mapping
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.
Figure 7 below maps the functional elements of Figure 3 onto the Figure 5 below maps the functional elements of Figure 3 onto the
LPWAN architecture elements of Figure 1. LPWAN architecture elements of Figure 1.
Dev App Dev App
+----------------+ +--------------+ +----------------+ +--------------+
| APP1 APP2 APP3 | |APP1 APP2 APP3| | APP1 APP2 APP3 | |APP1 APP2 APP3|
| | | | | | | |
| UDP | | UDP | | UDP | | UDP |
| IPv6 | | IPv6 | | IPv6 | | IPv6 |
| | | | | | | |
|SCHC C/D and F/R| | | |SCHC C/D and F/R| | |
+--------+-------+ +-------+------+ +--------+-------+ +-------+------+
| +--+ +----+ +-----------+ . | +--+ +----+ +-----------+ .
+~~ |RG| === |NGW | === | SCHC |... Internet .. +~~ |RG| === |NGW | === | SCHC |... Internet ..
+--+ +----+ |F/R and C/D| +--+ +----+ |F/R and C/D|
+-----------+ +-----------+
Figure 7: Architecture Figure 5: Architecture
SCHC C/D and SCHC F/R are located on both sides of the LPWAN 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. transmission, i.e. on the Dev side and on the Network side.
Let's describe the operation in the Uplink direction. The Device The operation in the Uplink direction is as follows. The Device
application packets use IPv6 or IPv6/UDP protocols. Before sending application uses IPv6 or IPv6/UDP protocols. Before sending the
these packets, the Dev compresses their headers using SCHC C/D and, packets, the Dev compresses their headers using SCHC C/D and, if the
if the SCHC Packet resulting from the compression exceeds the maximum SCHC Packet resulting from the compression needs to be fragmented by
payload size of the underlying LPWAN technology, SCHC F/R is SCHC, SCHC F/R is performed (see Section 8). The resulting SCHC
performed (see Section 8). The resulting SCHC Fragments are sent as Fragments are sent to an LPWAN Radio Gateway (RG) which forwards them
one or more L2 frames to an LPWAN Radio Gateway (RG) which forwards to a Network Gateway (NGW). The NGW sends the data to a SCHC F/R for
them to a Network Gateway (NGW). The NGW sends the data to a SCHC F/ re-assembly (if needed) and then to the SCHC C/D for decompression.
R and then to the SCHC C/D for decompression. The SCHC F/R and C/D After decompression, the packet can be sent over the Internet to one
on the Network side can be located in the NGW or somewhere else as or several LPWAN Application Servers (App).
long as a tunnel is established between them and the NGW. Note that,
for some LPWAN technologies, it MAY be suitable to locate the SCHC F/ The SCHC F/R and C/D on the Network side can be located in the NGW,
R functionality nearer the NGW, in order to better deal with time or somewhere else as long as a tunnel is established between them and
constraints of such technologies. The SCHC C/D and F/R on both sides the NGW. Note that, for some LPWAN technologies, it MAY be suitable
MUST share the same set of Rules. After decompression, the packet to locate the SCHC F/R functionality nearer the NGW, in order to
can be sent over the Internet to one or several LPWAN Application better deal with time constraints of such technologies.
Servers (App).
The SCHC C/D and F/R on both sides MUST share the same set of Rules.
The SCHC C/D and F/R process is symmetrical, therefore the The SCHC C/D and F/R process is symmetrical, therefore the
description of the Downlink direction trivially derives from the one description of the Downlink direction is symmetrical to the one
above. above.
6. Rule ID 6. Rule ID
Rule IDs are identifiers used to select the correct context either Rule IDs are identifiers used to select the correct context either
for Compression/Decompression or for Fragmentation/Reassembly. for Compression/Decompression or for Fragmentation/Reassembly.
The size of the Rule IDs is not specified in this document, as it is The size of the Rule IDs is not specified in this document, as it is
implementation-specific and can vary according to the LPWAN implementation-specific and can vary according to the LPWAN
technology and the number of Rules, among others. technology and the number of Rules, among others. It is defined in
Profiles.
The Rule IDs are used: The Rule IDs are used:
o In the SCHC C/D context, to identify the Rule (i.e., the set of 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. Field Descriptions) that is used to compress a packet header.
o At least one Rule ID MAY be allocated to tagging packets for which o At least one Rule ID MAY be allocated to tagging packets for which
SCHC compression was not possible (no matching Rule was found). SCHC compression was not possible (no matching Rule was found).
o In SCHC F/R, to identify the specific modes and settings of SCHC o In SCHC F/R, to identify the specific modes and settings of SCHC
Fragments being transmitted, and to identify the SCK ACKs, Fragments being transmitted, and to identify the SCHC ACKs,
including their modes and settings. Note that in the case of including their modes and settings. Note that when F/R is used
bidirectional communication, at least two Rule ID values are for both communication directions, at least two Rule ID values are
therefore needed for F/R. therefore needed for F/R.
7. Static Context Header Compression 7. Compression/Decompression
In order to perform header compression, this document defines a Compression with SCHC is based on using context, i.e. a set of Rules
mechanism called Static Context Header Compression (SCHC), which is to compress or decompress headers. SCHC avoids context
based on using context, i.e. a set of Rules to compress or decompress synchronization, which consumes considerable bandwidth in other
headers. SCHC avoids context synchronization, which is the most header compression mechanisms such as RoHC [RFC5795]. Since the
bandwidth-consuming operation in other header compression mechanisms content of packets is highly predictable in LPWAN networks, static
such as RoHC [RFC5795]. Since the nature of packets is highly contexts MAY be stored beforehand to omit transmitting some
predictable in LPWAN networks, static contexts MAY be stored information over the air. The contexts MUST be stored at both ends,
beforehand to omit transmitting some information over the air. The and they can be learned by a provisioning protocol or by out of band
contexts MUST be stored at both ends, and they can be learned by a means, or they can be pre-provisioned. The way the contexts are
provisioning protocol or by out of band means, or they can be pre- provisioned is out of the scope of this document.
provisioned. The way the contexts are provisioned on both ends is
out of the scope of this document.
7.1. SCHC C/D Rules 7.1. SCHC C/D Rules
The main idea of the SCHC compression scheme is to transmit the Rule 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 to the other end instead of sending known field values. This Rule
ID identifies a Rule that provides the closest match to the original 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 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. necessary to send the corresponding Rule ID over the LPWAN network.
How Rules are generated is out of the scope of this document. The The manner by which Rules are generated is out of the scope of this
Rules MAY be changed at run-time but the way to do this will be document. The Rules MAY be changed at run-time but the mechanism is
specified in another document. out of scope of this document.
The context contains a list of Rules (cf. Figure 8). Each Rule The context contains a list of Rules (see Figure 6). Each Rule
itself contains a list of Field Descriptions composed of a Field itself contains a list of Field Descriptions composed of a Field
Identifier (FID), a Field Length (FL), a Field Position (FP), a Identifier (FID), a Field Length (FL), a Field Position (FP), a
Direction Indicator (DI), a Target Value (TV), a Matching Operator Direction Indicator (DI), a Target Value (TV), a Matching Operator
(MO) and a Compression/Decompression Action (CDA). (MO) and a Compression/Decompression Action (CDA).
/-----------------------------------------------------------------\ /-----------------------------------------------------------------\
| Rule N | | Rule N |
/-----------------------------------------------------------------\| /-----------------------------------------------------------------\|
| Rule i || | Rule i ||
/-----------------------------------------------------------------\|| /-----------------------------------------------------------------\||
skipping to change at page 14, line 49 skipping to change at page 13, line 29
|+-------+--+--+--+------------+-----------------+---------------+||| |+-------+--+--+--+------------+-----------------+---------------+|||
||Field 2|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||| ||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||
|+-------+--+--+--+------------+-----------------+---------------+|/ |+-------+--+--+--+------------+-----------------+---------------+|/
| | | |
\-----------------------------------------------------------------/ \-----------------------------------------------------------------/
Figure 8: Compression/Decompression Context Figure 6: A Compression/Decompression Context
A Rule does not describe how to parse a packet header to find each A Rule does not describe how to parse a packet header to find each
field. This MUST be known from the compressor/decompressor. Rules field. This MUST be known from the compressor/decompressor. Rules
only describe the compression/decompression behavior for each header only describe the compression/decompression behavior for each header
field. In a Rule, the Field Descriptions are listed in the order in field. In a Rule, the Field Descriptions are listed in the order in
which the fields appear in the packet header. which the fields appear in the packet header.
A Rule also describes what Compression Residue is sent. The A Rule also describes what is sent in the Compression Residue. The
Compression Residue is assembled by concatenating the residues for Compression Residue is assembled by concatenating the residues for
each field, in the order the Field Descriptions appear in the Rule. each field, in the order the Field Descriptions appear in the Rule.
The Context describes the header fields and its values with the The Context describes the header fields and its values with the
following entries: following entries:
o Field ID (FID) is a unique value to define the header field. 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 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 either a fixed value (in bits) if the length is known when the
skipping to change at page 15, line 45 skipping to change at page 14, line 24
* UPLINK (Up): this Field Description is only applicable to * UPLINK (Up): this Field Description is only applicable to
packets sent by the Dev to the App, packets sent by the Dev to the App,
* DOWNLINK (Dw): this Field Description is only applicable to * DOWNLINK (Dw): this Field Description is only applicable to
packets sent from the App to the Dev, packets sent from the App to the Dev,
* BIDIRECTIONAL (Bi): this Field Description is applicable to * BIDIRECTIONAL (Bi): this Field Description is applicable to
packets travelling both Up and Dw. packets travelling both Up and Dw.
o Target Value (TV) is the value used to make the match with the o Target Value (TV) is the value used to match against the packet
packet header field. The Target Value can be of any type header field. The Target Value can be of any type (integer,
(integer, strings, etc.). For instance, it can be a single value strings, etc.). It can be a single value or a more complex
or a more complex structure (array, list, etc.), such as a JSON or structure (array, list, etc.), such as a JSON or a CBOR structure.
a CBOR structure.
o Matching Operator (MO) is the operator used to match the Field o Matching Operator (MO) is the operator used to match the Field
Value and the Target Value. The Matching Operator may require Value and the Target Value. The Matching Operator may require
some parameters. MO is only used during the compression phase. some parameters. MO is only used during the compression phase.
The set of MOs defined in this document can be found in The set of MOs defined in this document can be found in
Section 7.4. Section 7.4.
o Compression Decompression Action (CDA) describes the compression o Compression Decompression Action (CDA) describes the compression
and decompression processes to be performed after the MO is and decompression processes to be performed after the MO is
applied. Some CDAs MAY require parameter values for their applied. Some CDAs MAY require parameter values for their
skipping to change at page 16, line 22 skipping to change at page 14, line 49
decompression functions. The set of CDAs defined in this document decompression functions. The set of CDAs defined in this document
can be found in Section 7.5. can be found in Section 7.5.
7.2. Rule ID for SCHC C/D 7.2. Rule ID for SCHC C/D
Rule IDs are sent by the compression function in one side and are Rule IDs are sent by the compression function in one side and are
received for the decompression function in the other side. In SCHC received for the decompression function in the other side. In SCHC
C/D, the Rule IDs are specific to a Dev. Hence, multiple Dev C/D, the Rule IDs are specific to a Dev. Hence, multiple Dev
instances MAY use the same Rule ID to define different header instances MAY use the same Rule ID to define different header
compression contexts. To identify the correct Rule ID, the SCHC C/D compression contexts. To identify the correct Rule ID, the SCHC C/D
needs to correlate the Rule ID with the Dev identifier to find the needs to associate the Rule ID with the Dev identifier to find the
appropriate Rule to be applied. appropriate Rule to be applied.
7.3. Packet processing 7.3. Packet processing
The compression/decompression process follows several steps: The compression/decompression process follows several steps:
o Compression Rule selection: The goal is to identify which Rule(s) o Compression Rule selection: The goal is to identify which Rule(s)
will be used to compress the packet's headers. When doing will be used to compress the packet's headers. When performing
decompression, on the network side the SCHC C/D needs to find the 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 correct Rule based on the L2 address; in this way, it can use the
the DevIID and the Rule ID. On the Dev side, only the Rule ID is 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 needed to identify the correct Rule since the Dev typically only
that apply to itself. The Rule will be selected by matching the holds Rules that apply to itself. The Rule will be selected by
Fields Descriptions to the packet header as described below. When matching the Fields Descriptions to the packet header as described
the selection of a Rule is done, this Rule is used to compress the below. When the selection of a Rule is done, this Rule is used to
header. The detailed steps for compression Rule selection are the compress the header. The detailed steps for compression Rule
following: selection are the following:
* The first step is to choose the Field Descriptions by their * The first step is to choose the Field Descriptions by their
direction, using the Direction Indicator (DI). A Field direction, using the Direction Indicator (DI). A Field
Description that does not correspond to the appropriate DI will Description that does not correspond to the appropriate DI will
be ignored. If all the fields of the packet do not have a be ignored. If all the fields of the packet do not have a
Field Description with the correct DI, the Rule is discarded Field Description with the correct DI, the Rule is discarded
and SCHC C/D proceeds to explore the next Rule. and SCHC C/D proceeds to consider the next Rule.
* When the DI has matched, then the next step is to identify the * When the DI has matched, then the next step is to identify the
fields according to Field Position (FP). If FP does not fields according to Field Position (FP). If FP does not
correspond, the Rule is not used and the SCHC C/D proceeds to correspond, the Rule is not used and the SCHC C/D proceeds to
consider the next Rule. consider the next Rule.
* Once the DI and the FP correspond to the header information, * Once the DI and the FP correspond to the header information,
each packet field's value is then compared to the corresponding each packet field's value is then compared to the corresponding
Target Value (TV) stored in the Rule for that specific field Target Value (TV) stored in the Rule for that specific field
using the matching operator (MO). using the matching operator (MO).
If all the fields in the packet's header satisfy all the If all the fields in the packet's header satisfy all the
matching operators (MO) of a Rule (i.e. all MO results are matching operators (MO) of a Rule (i.e. all MO results are
True), the fields of the header are then compressed according True), the fields of the header are then compressed according
to the Compression/Decompression Actions (CDAs) and a to the Compression/Decompression Actions (CDAs) and a
compressed header (with possibly a Compression Residue) SHOULD compressed header (with possibly a Compression Residue) SHOULD
be obtained. Otherwise, the next Rule is tested. be obtained. Otherwise, the next Rule is tested.
* If no eligible Rule is found, then the header MUST be sent * If no eligible compression Rule is found, then the header MUST
without compression. This MAY require the use of the SCHC F/R be sent without compression, using a Rule ID dedicated to this
process. purpose. Sending the header uncompressed but may require the
use of the SCHC F/R process.
o Sending: If an eligible Rule is found, the Rule ID is sent to the o Sending: The Rule ID is sent to the other end followed by the
other end followed by the Compression Residue (which could be Compression Residue (which could be empty) or the uncompressed
empty) and directly followed by the payload. The Compression header, and directly followed by the payload. The Compression
Residue is the concatenation of the Compression Residues for each Residue is the concatenation of the Compression Residues for each
field according to the CDAs for that Rule. The way the Rule ID is field according to the CDAs for that Rule. The way the Rule ID is
sent depends on the specific underlying LPWAN technology. For sent depends on the Profile. For example, it can be either
example, it can be either included in an L2 header or sent in the included in an L2 header or sent in the first byte of the L2
first byte of the L2 payload. (Cf. Figure 9). This process will payload. (see Figure 4). This process will be specified in the
be specified in the LPWAN technology-specific document and is out Profile and is out of the scope of the present document. On LPWAN
of the scope of the present document. On LPWAN technologies that technologies that are byte-oriented, the compressed header
are byte-oriented, the compressed header concatenated with the concatenated with the original packet payload is padded to a
original packet payload is padded to a multiple of 8 bits, if multiple of 8 bits, if needed. See Section 9 for details.
needed. See Section 9 for details.
o Decompression: When doing decompression, on the network side the o Decompression: When doing decompression, on the network side the
SCHC C/D needs to find the correct Rule based on the L2 address 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 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 Dev side, only the Rule ID is needed to identify the correct Rule
since the Dev only holds Rules that apply to itself. since the Dev only holds Rules that apply to itself.
The receiver identifies the sender through its device-id (e.g. The receiver identifies the sender through its device-id or source
MAC address, if exists) and selects the appropriate Rule from the identifier (e.g. MAC address, if it exists) and selects the Rule
Rule ID. If a source identifier is present in the L2 technology, using the Rule ID. This Rule describes the compressed header
it is used to select the Rule ID. This Rule describes the format and associates the received Compression Residue to each of
compressed header format and associates the values to the header the header fields. For each field in the header, the receiver
fields. The receiver applies the CDA action to reconstruct the applies the CDA action associated to that field in order to
original header fields. The CDA application order can be reconstruct the original header field value. The CDA application
different from the order given by the Rule. For instance, order can be different from the order in which the fields are
Compute-* SHOULD be applied at the end, after all the other CDAs. listed in the Rule. In particular, Compute-* MUST be applied
after the application of the CDAs of all the fields it computes
+--- ... --+------- ... -------+------------------+ on.
| Rule ID |Compression Residue| packet payload |
+--- ... --+------- ... -------+------------------+
|----- compressed header ------|
Figure 9: SCHC C/D Packet Format
7.4. Matching operators 7.4. Matching operators
Matching Operators (MOs) are functions used by both SCHC C/D Matching Operators (MOs) are functions used by both SCHC C/D
endpoints involved in the header compression/decompression. They are endpoints involved in the header compression/decompression. They are
not typed and can be indifferently applied to integer, string or any not typed and can be applied to integer, string or any other data
other data type. The result of the operation can either be True or type. The result of the operation can either be True or False. MOs
False. MOs are defined as follows: are defined as follows:
o equal: The match result is True if a field value in a packet and o equal: The match result is True if the field value in the packet
the value in the TV are equal. matches the TV.
o ignore: No check is done between a field value in a packet and a o ignore: No check is done between the field value in the packet and
TV in the Rule. The result of the matching is always true. the 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 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 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 parameter of the MSB MO indicates how many bits are involved in
the comparison. If the FL is described as variable, the length the comparison. If the FL is described as variable, the length
must be a multiple of the unit. For example, x must be multiple 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. 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 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 values. Each value of the list is identified by a short ID (or
skipping to change at page 19, line 19 skipping to change at page 17, line 32
|not-sent |elided |use value stored in context | |not-sent |elided |use value stored in context |
|value-sent |send |build from received value | |value-sent |send |build from received value |
|mapping-sent |send index |value from index on a table | |mapping-sent |send index |value from index on a table |
|LSB |send LSB |TV, received value | |LSB |send LSB |TV, received value |
|compute-length |elided |compute length | |compute-length |elided |compute length |
|compute-checksum |elided |compute UDP checksum | |compute-checksum |elided |compute UDP checksum |
|DevIID |elided |build IID from L2 Dev addr | |DevIID |elided |build IID from L2 Dev addr |
|AppIID |elided |build IID from L2 App addr | |AppIID |elided |build IID from L2 App addr |
\--------------------+-------------+----------------------------/ \--------------------+-------------+----------------------------/
Figure 10: Compression and Decompression Actions Figure 7: Compression and Decompression Actions
Figure 10 summarizes the basic functions that can be used to compress Figure 7 summarizes the basic actions that can be used to compress
and decompress a field. The first column lists the actions name. and decompress a field. The first column shows the action's name.
The second and third columns outline the reciprocal compression/ The second and third columns show the reciprocal compression/
decompression behavior for each action. decompression behavior for each action.
Compression is done in order that Fields Descriptions appear in a Compression is done in the order that the Field Descriptions appear
Rule. The result of each Compression/Decompression Action is in a Rule. The result of each Compression/Decompression Action is
appended to the working Compression Residue in that same order. The appended to the accumulated Compression Residue in that same order.
receiver knows the size of each compressed field which can be given The receiver knows the size of each compressed field, which can be
by the Rule or MAY be sent with the compressed header. given by the Rule or MAY be sent with the compressed header.
If the field is identified as being variable in the Field 7.5.1. processing variable-length fields
Description, then the size of the Compression Residue value (using
the unit defined in the FL) MUST be sent first using the following
coding:
o If the size is between 0 and 14, it is sent as a 4-bits integer. If the field is identified in the Field Description as being of
variable size, then the size of the Compression Residue value (using
the unit defined in the FL) MUST first be sent as follows:
o For values between 15 and 254, the first 4 bits sent are set to 1 o If the size is between 0 and 14, it is sent as a 4-bits unsigned
and the size is sent using 8 bits integer. integer.
o For higher values of size, the first 12 bits are set to 1 and the o For values between 15 and 254, 0b1111 is transmitted and then the
next two bytes contain the size value as a 16 bits integer. size is sent as an 8 bits unsigned integer.
o For larger values of the size, 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 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 FL is specified as being variable, size 0 MUST be sent to denote
its absence. its absence.
7.5.1. not-sent CDA 7.5.2. not-sent CDA
The not-sent function is generally used when the field value is The not-sent action is generally used when the field value is
specified in a Rule and therefore known by both the Compressor and specified in a Rule and therefore known by both the Compressor and
the Decompressor. This action is generally used with the "equal" MO. the Decompressor. This action SHOULD be used with the "equal" MO.
If MO is "ignore", there is a risk to have a decompressed field value If MO is "ignore", there is a risk to have a decompressed field value
different from the original field that was compressed. different from the original field that was compressed.
The compressor does not send any Compression Residue for a field on The compressor does not send any Compression Residue for a field on
which not-sent compression is applied. which not-sent compression is applied.
The decompressor restores the field value with the Target Value The decompressor restores the field value with the Target Value
stored in the matched Rule identified by the received Rule ID. stored in the matched Rule identified by the received Rule ID.
7.5.2. value-sent CDA 7.5.3. value-sent CDA
The value-sent action is generally used when the field value is not 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 known by both the Compressor and the Decompressor. The value is sent
as a residue in the compressed message header. Both Compressor and as a residue in the compressed message header. Both Compressor and
Decompressor MUST know the size of the field, either implicitly (the Decompressor MUST know the size of the field, either implicitly (the
size is known by both sides) or by explicitly indicating the length size is known by both sides) or by explicitly indicating the length
in the Compression Residue, as defined in Section 7.5. This function in the Compression Residue, as defined in Section 7.5.1. This action
is generally used with the "ignore" MO. is generally used with the "ignore" MO.
7.5.3. mapping-sent CDA 7.5.4. mapping-sent CDA
The mapping-sent is used to send a smaller index (the index into the The mapping-sent action is used to send an index (the index into the
Target Value list of values) instead of the original value. This Target Value list of values) instead of the original value. This
function is used together with the "match-mapping" MO. action is used together with the "match-mapping" MO.
On the compressor side, the match-mapping Matching Operator searches On the compressor side, the match-mapping Matching Operator searches
the TV for a match with the header field value and the mapping-sent 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 CDA appends the corresponding index to the Compression Residue to be
sent. On the decompressor side, the CDA uses the received index to sent. On the decompressor side, the CDA uses the received index to
restore the field value by looking up the list in the TV. 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 The number of bits sent is the minimal size for coding all the
possible indices. possible indices.
7.5.4. LSB CDA 7.5.5. LSB CDA
The LSB action is used together with the "MSB(x)" MO to avoid sending 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 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 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. header field length minus the length specified in the MSB(x) MO.
The compressor sends the Least Significant Bits (e.g. LSB of the The compressor sends the Least Significant Bits (e.g. LSB of the
length field). The decompressor concatenates the x most significant length field). The decompressor concatenates the x most significant
bits of Target Value and the received residue. bits of Target Value and the received residue.
If this action needs to be done on a variable length field, the size 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 of the Compression Residue in bytes MUST be sent as described in
Section 7.5. Section 7.5.1.
7.5.5. DevIID, AppIID CDA 7.5.6. DevIID, AppIID CDA
These functions are used to process respectively the Dev and the App These actions are used to process respectively the Dev and the App
Interface Identifiers (DevIID and AppIID) of the IPv6 addresses. Interface Identifiers (DevIID and AppIID) of the IPv6 addresses.
AppIID CDA is less common since current LPWAN technologies frames AppIID CDA is less common since most current LPWAN technologies
contain a single address, which is the Dev's address. 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 The IID value MAY be computed from the Device ID present in the L2
header, or from some other stable identifier. The computation is header, or from some other stable identifier. The computation is
specific to each LPWAN technology and MAY depend on the Device ID specific to each Profile and MAY depend on the Device ID size.
size.
In the downlink direction (Dw), at the compressor, this DevIID CDA In the downlink direction (Dw), at the compressor, the DevIID CDA may
may be used to generate the L2 addresses on the LPWAN, based on the be used to generate the L2 addresses on the LPWAN, based on the
packet destination address. packet's Destination Address.
7.5.6. Compute-* 7.5.7. Compute-*
Some fields are elided during compression and reconstructed during Some fields may be elided during compression and reconstructed during
decompression. This is the case for length and checksum, so: decompression. This is the case for length and checksum, so:
o compute-length: computes the length assigned to this field. This o compute-length: computes the length assigned to this field. This
CDA MAY be used to compute IPv6 length or UDP length. CDA MAY be used to compute IPv6 length or UDP length.
o compute-checksum: computes a checksum from the information already o compute-checksum: computes a checksum from the information already
received by the SCHC C/D. This field MAY be used to compute UDP received by the SCHC C/D. This field MAY be used to compute UDP
checksum. checksum.
8. Fragmentation 8. Fragmentation/Reassembly
8.1. Overview 8.1. Overview
In LPWAN technologies, the L2 data unit size typically varies from In LPWAN technologies, the L2 MTU typically ranges from tens to
tens to hundreds of bytes. The SCHC F/R (Fragmentation /Reassembly) hundreds of bytes. Some of these technologies do not have an
MAY be used either because after applying SCHC C/D or when SCHC C/D internal fragmentation/reassembly mechanism.
is not possible the entire SCHC Packet still exceeds the L2 data
unit.
The SCHC F/R functionality defined in this document has been designed The SCHC Fragmentation/Reassembly (SCHC F/R) functionality is offered
under the assumption that data unit out-of-sequence delivery will not as an option for such LPWAN technologies to cope with the IPv6 MTU
happen between the entity performing fragmentation and the entity requirement of 1280 bytes [RFC8200]. It is optional to implement.
performing reassembly. This assumption allows reducing the If it is not needed, its description can be safely ignored.
complexity and overhead of the SCHC F/R mechanism.
This document also assumes that the L2 data unit size does not vary This specification includes several SCHC F/R modes, which allow for a
while a fragmented SCHC Packet is being transmitted. range of reliability options such as optional SCHC Fragment
retransmission. More modes may be defined in the future.
To adapt the SCHC F/R to the capabilities of LPWAN technologies, it The same SCHC F/R mode MUST be used for all SCHC Fragments of the
is required to enable optional SCHC Fragment retransmission and to same fragmented SCHC Packet. This document does not make any
allow for a range of reliability options for sending the SCHC decision with regard to which mode(s) will be used over a specific
Fragments. This document does not make any decision with regard to LPWAN technology. This will be defined in Profiles.
which SCHC Fragment delivery reliability mode will be used over a
specific LPWAN technology. These details will be defined in other
technology-specific documents.
SCHC F/R uses the knowledge of the L2 Word size (see Section 4) to 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. encode some messages. Therefore, SCHC MUST know the L2 Word size.
SCHC F/R generates SCHC Fragments and SCHC ACKs that are, for most of SCHC F/R usually generates SCHC Fragments and SCHC ACKs that are
them, multiples of L2 Words. The padding overhead is kept to the multiples of L2 Words. The padding overhead is kept to the absolute
absolute minimum. See Section 9. minimum (see Section 9).
8.2. Fragmentation Tools 8.2. SCHC F/R Tools
This subsection describes the different tools that are used to enable This subsection describes the different tools that are used to enable
the SCHC F/R functionality defined in this document, such as fields the SCHC F/R functionality defined in this document. These tools
in the SCHC F/R header frames (see the related formats in include the SCHC F/R messages, tiles, windows, counters, timers and
Section 8.4), windows and timers. header fields.
o Rule ID. The Rule ID is present in the SCHC Fragment header and The tools are described here in a generic manner. Their application
in the SCHC ACK header formats. The Rule ID in a SCHC Fragment to each SCHC F/R mode is found in Section 8.4.
header is used to identify that a SCHC Fragment is being carried,
which SCHC F/R reliability mode is used and which window size is
used. The Rule ID in the SCHC Fragment header also allows
interleaving non-fragmented SCHC Packets and SCHC Fragments that
carry other SCHC Packets. The Rule ID in a SCHC ACK identifies
the message as a SCHC ACK.
o Fragment Compressed Number (FCN). The FCN is included in all SCHC 8.2.1. Messages
Fragments. This field can be understood as a truncated, efficient
representation of a larger-sized fragment number, and does not
carry an absolute SCHC Fragment number. There are two FCN
reserved values that are used for controlling the SCHC F/R
process, as described next:
* The FCN value with all the bits equal to 1 (All-1) denotes the The messages that can be used by SCHC F/R are the following:
last SCHC Fragment of a packet. The last window of a packet is
called an All-1 window.
* The FCN value with all the bits equal to 0 (All-0) denotes the o SCHC Fragment: A data unit that carries a piece of a SCHC Packet
last SCHC Fragment of a window that is not the last one of the from the sender to the receiver.
packet. Such a window is called an All-0 window.
The rest of the FCN values are assigned in a sequentially o SCHC ACK: An acknowledgement for fragmentation, by the receiver to
decreasing order, which has the purpose to avoid possible the sender. This message is used to report on the successful
ambiguity for the receiver that might arise under certain reception of pieces of, or the whole of the fragmented SCHC
conditions. In the SCHC Fragments, this field is an unsigned Packet.
integer, with a size of N bits. In the No-ACK mode, the size is
set to 1 bit (N=1), All-0 is used in all SCHC Fragments and All-1
for the last one. For the other reliability modes, it is
recommended to use a number of bits (N) equal to or greater than
3. Nevertheless, the appropriate value of N MUST be defined in
the corresponding technology-specific profile documents. For
windows that are not the last one of a fragmented SCHC Packet, the
FCN for the last SCHC Fragment in such windows is an All-0. This
indicates that the window is finished and communication proceeds
according to the reliability mode in use. The FCN for the last
SCHC Fragment in the last window is an All-1, indicating the last
SCHC Fragment of the SCHC Packet. It is also important to note
that, in the No-ACK mode or when N=1, the last SCHC Fragment of
the packet will carry a FCN equal to 1, while all previous SCHC
Fragments will carry a FCN to 0. For further details see
Section 8.5. The highest FCN in the window, denoted MAX_WIND_FCN,
MUST be a value equal to or smaller than 2^N-2. (Example for N=5,
MAX_WIND_FCN MAY be set to 23, then subsequent FCNs are set
sequentially and in decreasing order, and the FCN will wrap from 0
back to 23).
o Datagram Tag (DTag). The DTag field, if present, is set to the o SCHC ACK REQ: An explicit request for a SCHC ACK. By the sender
same value for all SCHC Fragments carrying the same SCHC to the receiver.
packet, and to different values for different 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, the size of the DTag field is T bits,
which MAY be set to a value greater than or equal to 0 bits. For
each new SCHC Packet processed by the sender, DTag MUST be
sequentially increased, from 0 to 2^T - 1 wrapping back from 2^T -
1 to 0. In the SCHC ACK format, DTag carries the same value as
the DTag field in the SCHC Fragments for which this SCHC ACK is
intended. When there is no Dtag, there can be only one SCHC
Packet in transit. Only after all its fragments have been
transmitted can another SCHC Packet be sent. The length of DTag,
denoted T, is not specified in this document because it is
technology dependant. It will be defined in the corresponding
technology-specific documents, based on the number of simultaneous
packets that are to be supported.
o W (window): W is a 1-bit field. This field carries the same value o SCHC Sender-Abort: A message by the sender telling the receiver
for all SCHC Fragments of a window, and it is complemented for the that it has aborted the transmission of a fragmented SCHC Packet.
next window. The initial value for this field is 0. 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 the
SCHC Fragments whose reception is being positively or negatively
acknowledged by the SCHC ACK.
o Message Integrity Check (MIC). This field is computed by the o SCHC Receiver-Abort: A message by the receiver to tell the sender
sender over the complete SCHC Packet and before SCHC to abort the transmission of a fragmented SCHC Packet.
fragmentation. The MIC allows the receiver to check errors in the
reassembled packet, while it also enables compressing the UDP
checksum by use of SCHC compression. The CRC32 as 0xEDB88320
(i.e. the reverse representation of the polynomial used e.g. in
the Ethernet standard [RFC3385]) is recommended as the default
algorithm for computing the MIC. Nevertheless, other algorithms
MAY be required and are defined in the technology-specific
documents as well as the length in bits of the MIC used.
o C (MIC checked): C is a 1-bit field. This field is used in the 8.2.2. Tiles, Windows, Bitmaps, Timers, Counters
SCHC ACK packets to report the outcome of the MIC check, i.e.
whether the reassembled packet was correctly received or not. A
value of 1 represents a positive MIC check at the receiver side
(i.e. the MIC computed by the receiver matches the received MIC).
o Retransmission Timer. A SCHC Fragment sender uses it after the 8.2.2.1. Tiles
transmission of a window to detect a transmission error of the
SCHC ACK corresponding to this window. Depending on the
reliability mode, it will lead to a request a SCHC ACK
retransmission (in ACK-Always mode) or it will trigger the
transmission of the next window (in ACK-on-Error mode). The
duration of this timer is not defined in this document and MUST be
defined in the corresponding technology-specific documents.
o Inactivity Timer. A SCHC Fragment receiver uses it to take action The SCHC Packet is fragmented into pieces, hereafter called tiles.
when there is a problem in the transmission of SCHC fragments. The tiles MUST be contiguous.
Such a problem could be detected by the receiver not getting a
single SCHC Fragment during a given period of time. When this
happens, an Abort message will be sent (see related text later in
this section). Initially, and each time a SCHC Fragment is
received, the timer is reinitialized. The duration of this timer
is not defined in this document and MUST be defined in the
corresponding technology-specific document.
o Attempts. This counter counts the requests for a missing SCHC See Figure 8 for an example.
ACK. When it reaches the value MAX_ACK_REQUESTS, the sender
assumes there are recurrent SCHC Fragment transmission errors and
determines that an Abort is needed. The default value
MAX_ACK_REQUESTS is not stated in this document, and it is
expected to be defined in the corresponding technology-specific
document. The Attempts counter is defined per window. It is
initialized each time a new window is used.
o Bitmap. The Bitmap is a sequence of bits carried in a SCHC ACK. SCHC Packet
Each bit in the Bitmap corresponds to a SCHC fragment of the +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+
current window, and provides feedback on whether the SCHC Fragment Tiles | | | | | | | | | | | | | |
has been received or not. The right-most position on the Bitmap +----+--+-----+---+----+-+---+---+-----+...-----+----+---+------+
reports if the All-0 or All-1 fragment has been received or not.
Feedback on the SCHC fragment with the highest FCN value is
provided by the bit in the left-most position of the Bitmap. In
the Bitmap, a bit set to 1 indicates that the SCHC Fragment of FCN
corresponding to that bit position has been correctly sent and
received. The text above describes the internal representation of
the Bitmap. When inserted in the SCHC ACK for transmission from
the receiver to the sender, the Bitmap is shortened for energy/
bandwidth optimisation, see more details in Section 8.4.3.1.
o Abort. On expiration of the Inactivity timer, or when Attempts Figure 8: a SCHC Packet fragmented in tiles
reaches MAX_ACK_REQUESTS or upon occurrence of some other error,
the sender or the receiver may use the Abort. When the receiver
needs to abort the on-going fragmented SCHC Packet transmission,
it sends the Receiver-Abort format. When the sender needs to
abort the transmission, it sends the Sender-Abort format. None of
the Aborts are acknowledged.
8.3. Reliability modes Each SCHC Fragment message carries at least one tile in its Payload,
if the Payload field is present.
This specification defines three reliability modes: No-ACK, ACK- 8.2.2.2. Windows
Always, and ACK-on-Error. ACK-Always and ACK-on-Error operate on
windows of SCHC Fragments. A window of SCHC Fragments is a subset of
the full set of SCHC Fragments needed to carry a SCHC Packet.
o No-ACK. No-ACK is the simplest SCHC Fragment reliability mode. Some SCHC F/R modes may handle successive tiles in groups, called
The receiver does not generate overhead in the form of windows.
acknowledgements (ACKs). However, this mode does not enhance
reliability beyond that offered by the underlying LPWAN
technology. In the No-ACK mode, the receiver MUST NOT issue SCHC
ACKs. See further details in Section 8.5.1.
o ACK-Always. The ACK-Always mode provides flow control using a If windows are used
windowing scheme. This mode is also able to handle long bursts of
lost SCHC Fragments since detection of such events can be done
before the end of the SCHC Packet transmission as long as the
window size is short enough. However, such benefit comes at the
expense of SCHC ACK use. In ACK-Always, the receiver sends a SCHC
ACK after a window of SCHC Fragments has been received. The SCHC
ACK is used to inform the sender which SCHC Fragments in the
current window have been well received. Upon a SCHC ACK
reception, the sender retransmits the lost SCHC Fragments. When a
SCHC ACK is lost and the sender has not received it by the
expiration of the Retransmission Timer, the sender uses a SCHC ACK
request by sending the All-0 empty SCHC Fragment when 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 o all the windows of a SCHC Packet, except the last one, MUST
offering relatively low L2 data unit loss probability. In this contain the same number of tiles. This number is WINDOW_SIZE.
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 o WINDOW_SIZE MUST be specified in a Profile.
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 o the windows are numbered.
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 o their numbers MUST increase from 0 upward, from the start of the
Appendix B. SCHC Packet to its end.
8.4. Fragmentation Formats o the last window MUST contain WINDOW_SIZE tiles or less.
This section defines the SCHC Fragment format, including the All-0 o tiles are numbered within each window.
and All-1 formats and their "empty" variations, the SCHC ACK format
and the Abort formats.
A SCHC Fragment conforms to the general format shown in Figure 11. o the tile numbers MUST decrement from WINDOW_SIZE - 1 downward,
It comprises a SCHC Fragment Header and a SCHC Fragment Payload. In looking from the start of the SCHC Packet toward its end.
addition, the last SCHC Fragment carries as many padding bits as
needed to fill up an L2 Word. The SCHC Fragment Payload carries a
subset of the SCHC Packet. The SCHC Fragment is the data unit passed
on to the L2 for transmission.
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~ o each tile of a SCHC Packet is therefore uniquely identified by a
| Fragment Header | Fragment payload | padding (as needed) window number and a tile number within this window.
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
Figure 11: SCHC Fragment general format. Presence of a padding field See Figure 9 for an example.
is optional
8.4.1. Fragments that are not the last one +---------------------------------------------...-------------+
| SCHC Packet |
+---------------------------------------------...-------------+
In ACK-Always or ACK-on-Error, SCHC Fragments except the last one Tile # | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 | | 0 | 4 | 3 |
SHALL conform to the detailed format defined in Figure 12. Window # |-------- 0 --------|-------- 1 --------|- 2 ... 27 -|-- 28 -|
|----- Fragment Header -----| Figure 9: a SCHC Packet fragmented in tiles grouped in 28 windows,
|-- T --|1|-- N --| with WINDOW_SIZE = 5
+-- ... --+- ... -+-+- ... -+--------...-------+
| Rule ID | DTag |W| FCN | Fragment payload |
+-- ... --+- ... -+-+- ... -+--------...-------+
Figure 12: Fragment Detailed Format for Fragments except the Last When windows are used
One, ACK-Always and ACK-on-Error
In the No-ACK mode, SCHC Fragments except the last one SHALL conform o information on the correct reception of the tiles belonging to the
to the detailed format defined in Figure 13. same window MUST be grouped together.
|---- Fragment Header ----| o it is RECOMMENDED that this information is kept in Bitmaps.
|-- T --|-- N --|
+-- ... --+- ... -+- ... -+--------...-------+
| Rule ID | DTag | FCN | Fragment payload |
+-- ... --+- ... -+- ... -+--------...-------+
Figure 13: Fragment Detailed Format for Fragments except the Last o Bitmaps MAY be sent back to the sender in a SCHC ACK message.
One, No-ACK mode
The total size of the fragment header is not necessarily a multiple o Each window has a Bitmap.
of the L2 Word size. To build the fragment payload, SCHC F/R MUST
take from the SCHC Packet a number of bits that makes the SCHC
Fragment an exact multiple of L2 Words. As a consequence, no padding
bit is used for these fragments.
8.4.1.1. All-0 fragment 8.2.2.3. Bitmaps
The All-0 format is used for sending the last SCHC Fragment of a Each bit in the Bitmap for a window corresponds to a tile in the
window that is not the last window of the SCHC Packet. window. 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 a
SCHC Packet, the bit at the right-most position corresponds to the
tile numbered 0. In the Bitmap for the last window, the bit at the
right-most position corresponds either to the tile numbered 0 or to a
tile that is sent/received as "the last one of the SCHC Packet"
without explicitely stating its number (see Section 8.3.1.2).
|----- Fragment Header -----| At the receiver
|-- T --|1|-- N --| o a bit set to 1 in the Bitmap indicates that a tile associated with
+-- ... --+- ... -+-+- ... -+--------...-------+ that bit position has been correctly received for that window.
| Rule ID | DTag |W| 0..0 | Fragment payload |
+-- ... --+- ... -+-+- ... -+--------...-------+
Figure 14: All-0 fragment detailed format o a bit set to 0 in the Bitmap indicates that no tile associated
with that bit position has been correctly received for that
window.
This is simply an instance of the format described in Figure 12. An WINDOW_SIZE finely controls the size of the Bitmap sent in the SCHC
All-0 fragment payload MUST be at least the size of an L2 Word. The ACK message, which may be critical to some LPWAN technologies.
rationale is that the All-0 empty fragment (see Section 8.4.1.2)
needs to be distinguishable from the All-0 regular fragment, even in
the presence of padding.
8.4.1.2. All-0 empty fragment 8.2.2.4. Timers and counters
The All-0 empty fragment is an exception to the All-0 fragment Some SCHC F/R modes can use the following timers and counters
described above. It is used by a sender to request the
retransmission of a SCHC ACK by the receiver. It is only used in
ACK-Always mode.
|----- Fragment Header -----| o Inactivity Timer: this timer can be used to unlock a SCHC Fragment
|-- T --|1|-- N --| receiver that is not receiving a SCHC F/R message while it is
+-- ... --+- ... -+-+- ... -+~~~~~~~~~~~~~~~~~~~~~ expecting one.
| Rule ID | DTag |W| 0..0 | padding (as needed) (no payload)
+-- ... --+- ... -+-+- ... -+~~~~~~~~~~~~~~~~~~~~~
Figure 15: All-0 empty fragment detailed format o Retransmission Timer: this timer can be used by a SCHC Fragment
sender to set a timeout on expecting a SCHC ACK.
The size of the All-0 fragment header is generally not a multiple of o Attempts: this counter counts the requests for SCHC ACKs.
the L2 Word size. Therefore, an All-0 empty fragment generally needs MAX_ACK_REQUESTS is the threshold at which an exception is raised.
padding bits. The padding bits are always less than an L2 Word.
Since an All-0 payload MUST be at least the size of an L2 Word, a 8.2.3. Integrity Checking
receiver can distinguish an All-0 empty fragment from a regular All-0
fragment, even in the presence of padding.
8.4.2. All-1 fragment The reassembled SCHC Packet is checked for integrity at the receive
end. Integrity checking is performed by computing a MIC at the
sender side and transmitting it to the receiver for comparison with
the locally computed MIC.
In the No-ACK mode, the last SCHC Fragment of a SCHC Packet SHALL The MIC supports UDP checksum elision by SCHC C/D (see
contain a SCHC Fragment header that conforms to the detailed format Section 10.11).
shown in Figure 16.
|---------- Fragment Header ----------| The CRC32 polynomial 0xEDB88320 (i.e. the reverse representation of
|-- T --|-N=1-| the polynomial used e.g. in the Ethernet standard [RFC3385]) is
+---- ... ---+- ... -+-----+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ RECOMMENDED as the default algorithm for computing the MIC.
| Rule ID | DTag | 1 | MIC | payload | padding (as needed) Nevertheless, other MIC lengths or other algorithms MAY be required
+---- ... ---+- ... -+-----+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~ by the Profile.
Figure 16: All-1 Fragment Detailed Format for the Last Fragment, No- Note that the concatenation of the complete SCHC Packet and the
ACK mode potential padding bits of the last SCHC Fragment does not generally
constitute an integer number of bytes. For implementers to be able
to use byte-oriented CRC libraries, it is RECOMMENDED that the
concatenation of the complete SCHC Packet and the last fragment
potential padding bits be zero-extended to the next byte boundary and
that the MIC be computed on that byte array. A Profile MAY specify
another behaviour.
In ACK-Always or ACK-on-Error mode, the last fragment of a SCHC 8.2.4. Header Fields
Packet SHALL contain a SCHC Fragment header that conforms to the
detailed format shown in Figure 17.
|---------- Fragment Header ----------| The SCHC F/R messages use the following fields (see the related
|-- T --|1|-- N --| formats in Section 8.3):
+-- ... --+- ... -+-+- ... -+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag |W| 11..1 | MIC | payload | padding (as needed)
+-- ... --+- ... -+-+- ... -+-- ... --+---...---+~~~~~~~~~~~~~~~~~~~~~
(FCN)
Figure 17: All-1 Fragment Detailed Format for the Last Fragment, ACK- o Rule ID: this field is present in all the SCHC F/R messages. It
Always or ACK-on-Error is used to identify
The total size of the All-1 SCHC Fragment header is generally not a * that a SCHC F/R message is being carried, as opposed to an
multiple of the L2 Word size. The All-1 fragment being the last one unfragmented SCHC Packet,
of the SCHC Packet, SCHC F/R cannot freely choose the payload size to
align the fragment to an L2 Word. Therefore, padding bits are
generally appended to the All-1 fragment to make it a multiple of L2
Words in size.
The MIC MUST be computed on the payload and the padding bits. The * which SCHC F/R mode is used
rationale 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.
An All-1 fragment payload MUST be at least the size of an L2 Word. * and among this mode
The rationale is that the All-1 empty fragment (see Section 8.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 and the length of MIC are not specified in this + if windows are used and what the value of WINDOW_SIZE is,
document, and SHOULD be determined in other documents (e.g.
technology-specific profile documents).
The length of the MIC MUST be at least an L2 Word size. The + what other optional fields are present and what the field
rationale is to be able to distinguish a Sender-Abort (see sizes are.
Section 8.4.4) from an All-1 Fragment, even in the presence of
padding.
8.4.2.1. All-1 empty fragment Therefore, the Rule ID allows SCHC F/R interleaving non-fragmented
SCHC Packets and SCHC Fragments that carry other SCHC Packets, or
interleaving SCHC Fragments that use different SCHC F/R modes or
different parameters.
The All-1 empty fragment format is an All-1 fragment format without a o Datagram Tag (DTag). The DTag field is optional. Its presence
payload (see Figure 18). It is used by a fragment sender, in either and size (called T, in bits) is defined by each Profile for each
ACK-Always or ACK-on-Error, to request a retransmission of the SCHC Rule ID.
ACK for the All-1 window.
The size of the All-1 empty fragment header is generally not a When there is no DTag, there can be only one fragmented SCHC
multiple of the L2 Word size. Therefore, an All-1 empty fragment Packet in transit for a given Rule ID.
generally needs padding bits. The padding bits are always less than
an L2 Word.
Since an All-1 payload MUST be at least the size of an L2 Word, a If present, DTag
receiver can distinguish an All-1 empty fragment from a regular All-1
fragment, even in the presence of padding.
|---------- Fragment Header --------| * MUST be set to the same value for all the SCHC F/R messages
|-- T --|1|-- N --| related to the same fragmented SCHC Packet,
+-- ... --+- ... -+-+- ... -+- ... -+~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag |W| 1..1 | MIC | padding as needed (no payload)
+-- ... --+- ... -+-+- ... -+- ... -+~~~~~~~~~~~~~~~~~~~
Figure 18: All-1 for Retries format, also called All-1 empty * 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.
8.4.3. SCHC ACK format A sequence counter that is incremented for each new fragmented
SCHC Packet, counting from 0 to up to (2^T)-1 and wrapping back to
0 is RECOMMENDED for maximum traceability and replay avoidance.
The format of a SCHC ACK that acknowledges a window that is not the o W: The W field is optional. It is only present if windows are
last one (denoted as All-0 window) is shown in Figure 19. used. Its presence and size (called M, in bits) is defined by
each SCHC F/R mode and each Profile for each Rule ID.
|-- T --|1| This field carries information pertaining to the window a SCHC F/R
+---- ... --+- ... -+-+---- ... -----+ message relates to. If present, W MUST carry the same value for
| Rule ID | DTag |W|encoded Bitmap| (no payload) all the SCHC F/R messages related to the same window. Depending
+---- ... --+- ... -+-+---- ... -----+ on the mode and Profile, W may carry the full window number, or
just the least significant bit or any other partial representation
of the window number.
Figure 19: ACK format for All-0 windows o Fragment Compressed Number (FCN). The FCN field is present in the
SCHC Fragment Header. Its size (called N, in bits) is defined by
each Profile for each Rule ID.
To acknowledge the last window of a packet (denoted as All-1 window), This field conveys information about the progress in the sequence
a C bit (i.e. MIC checked) following the W bit is set to 1 to of tiles being transmitted by SCHC Fragment messages. For
indicate that the MIC check computed by the receiver matches the MIC example, it can contain a partial, efficient representation of a
present in the All-1 fragment. If the MIC check fails, the C bit is larger-sized tile number. The description of the exact use of the
set to 0 and the Bitmap for the All-1 window follows. FCN field is left to each SCHC F/R mode. However, two values are
reserved for special purposes. They help control the SCHC F/R
process:
|-- T --|1|1| * The FCN value with all the bits equal to 1 (called All-1)
+---- ... --+- ... -+-+-+ signals the very last tile of a SCHC Packet. By extension, if
| Rule ID | DTag |W|1| (MIC correct) windows are used, the last window of a packet is called the
+---- ... --+- ... -+-+-+ All-1 window.
+---- ... --+- ... -+-+-+----- ... -----+ * If windows are used, the FCN value with all the bits equal to 0
| Rule ID | DTag |W|0|encoded Bitmap |(MIC Incorrect) (called All-0) signals the last tile of a window that is not
+---- ... --+- ... -+-+-+----- ... -----+ the last one of the SCHC packet. By extension, such a window
C is called an All-0 window.
Figure 20: Format of a SCHC ACK for All-1 windows The highest value of FCN (an unsigned integer) is called
MAX_WIND_FCN. Since All-1 is reserved, MAX_WIND_FCN MUST be
stricly less that (2^N)-1.
The Rule ID and Dtag values in the SCHC ACK messages MUST be o Message Integrity Check (MIC). This field only appears in the
identical to the ones used in the SCHC Fragments that are being All-1 SCHC Fragments. Its size (called T, in bits) is defined by
acknowledged. This allows matching the SCHC ACK and the each Profile for each Rule ID.
corresponding SCHC Fragments.
The Bitmap carries information on the reception of each fragment of See Section 8.2.3 for the MIC default size, default polynomials
the window as described in Section 8.2. and details on its computation.
See Appendix D for a discussion on the size of the Bitmaps. o C (integrity Check): C is a 1-bit field. This field is used in
the SCHC ACK message to report on the reassembled SCHC Packet
integrity check (see Section 8.2.3).
In order to reduce the SCK ACK size, the Bitmap that is actually A value of 1 tells that the integrity check was performed and is
transmitted is shortened ("encoded") as explained in Section 8.4.3.1. successful. A value of 0 tells that the integrity check was not
performed, or that is was a failure.
8.4.3.1. Bitmap Encoding o Compressed Bitmap. The Compressed Bitmap is used together 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.
The SCHC ACK that is transmitted is truncated by applying the This field appears in the SCHC ACK message to report on the
following algorithm: the longest contiguous sequence of bits that receiver Bitmap (see Section 8.3.2.1).
starts at an L2 Word boundary of the SCHC ACK, where the bits of that
sequence are all set to 1, are all part of the Bitmap and finish
exactly at the end of the Bitmap, if one such sequence exists, MUST
NOT be transmitted. Because the SCHC Fragment sender knows the
actual Bitmap size, it can reconstruct the original Bitmap from the
shortened bitmap.
When shortening effectively takes place, the SCHC ACK is a multiple 8.3. SCHC F/R Message Formats
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 This section defines the SCHC Fragment formats, the SCHC ACK format,
the SCHC ACK REQ format and the SCHC Abort formats.
8.3.1. SCHC Fragment format
A SCHC Fragment conforms to the general format shown in Figure 10.
It comprises a SCHC Fragment Header and a SCHC Fragment Payload. The
SCHC Fragment Payload carries one or several tile(s).
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
| Fragment Header | Fragment Payload | padding (as needed)
+-----------------+-----------------------+~~~~~~~~~~~~~~~~~~~~~
Figure 10: SCHC Fragment general format. Presence of a padding field
is optional
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 one
of a SCHC Packet. The DTag field and the W field are optional.
|--- SCHC Fragment Header ----|
|-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | FCN | Fragment Payload | padding (as needed)
+-- ... --+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~~
Figure 11: Detailed Header Format for Regular SCHC Fragments
The FCN field MUST NOT contain all bits set to 1.
If the size of the SCHC Fragment Payload does not nicely complement
the SCHC Header size in a way that would make the SCHC Fragment a
multiple of the L2 Word, then padding bits MUST be added.
The Fragment Payload of a SCHC Fragment with FCN == 0 (called an
All-0 SCHC Fragment) MUST be at least the size of an L2 Word. The
rationale is that, even in the presence of padding, an All-0 SCHC
Fragment needs to be distinguishable from the SCHC ACK REQ message,
which has the same header but has no payload (see Section 8.3.3).
8.3.1.2. All-1 SCHC Fragment
The All-1 SCHC Fragment format is shown in Figure 12. The All-1 SCHC
Fragment is generally used to carry the very last tile of a SCHC
Packet and a MIC, or a MIC only. The DTag field, the W field and the
Payload are optional.
|-------- SCHC Fragment Header -------|
|-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 11..1 | MIC | Frag Payload | pad. (as needed)
+-- ... --+- ... -+---+- ... -+- ... -+------...-----+~~~~~~~~~~~~~~~~~~
(FCN)
Figure 12: Detailed format for the All-1 SCHC Fragment
If the size of the SCHC Fragment Payload does not nicely complement
the SCHC Header size in a way that would make the SCHC Fragment a
multiple of the L2 Word, then padding bits MUST be added.
The All-1 SCHC Fragment message MUST be distinguishable by size from
a SCHC Sender-Abort message (see Section 8.3.4.1) that has the same
T, M and N values. This is trivially achieved by having the MIC
larger than an L2 Word, or by having the Payload larger than an L2
Word. This is also naturally achieved if the SCHC Sender-Abort
Header is a multiple of L2 Words.
8.3.2. SCHC ACK format
The SCHC ACK message MUST obey the format shown in Figure 13. The
DTag field, the W 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 --|-M-|1|
+---- ... --+- ... -+---+-+~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W |1| padding as needed (success)
+---- ... --+- ... -+---+-+~~~~~~~~~~~~~~~~~~
+---- ... --+- ... -+---+-+------ ... ------+~~~~~~~~~~~~~~~
| Rule ID | DTag | W |0|Compressed Bitmap| pad. as needed (failure)
+---- ... --+- ... -+---+-+------ ... ------+~~~~~~~~~~~~~~~
C
Figure 13: Format of the SCHC ACK message
The SCHC ACK Header contains a C bit (see Section 8.2.4).
If the C bit is set to 1 (integrity check successful), no Bitmap is
carried and padding bits MUST be appended as needed to fill up the
last L2 Word. last L2 Word.
Figure 21 shows an example where L2 Words are actually bytes and If the C bit is set to 0 (integrity check not performed or failed)
and if windows are used,
o a representation of the Bitmap for the window referred to by the W
field MUST follow the C bit
o padding bits MUST be appended as needed to fill up the last L2
Word
If the C bit is 1 or windows are not used, the C bit MUST be followed
by padding bits as needed to fill up the last L2 Word.
See Section 8.2.2.3 for a description of the Bitmap.
The representation of the Bitmap that is transmitted MUST be the
compressed version specified in Section 8.3.2.1, in order to reduce
the SCHC ACK message size.
8.3.2.1. Bitmap Compression
For transmission, the Compressed Bitmap in the SCHC ACK message is
defined by the following algorithm (see Figure 14 for a follow-along
example):
o Build a temporary SCHC ACK message that contains 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 SCHC ACK
message and there is a Bitmap bit on the right of the scissors,
keep moving right, then stop.
o At this point, cut and drop off any bits to the right of the
scissors
When one or 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 be appended.
Because the SCHC Fragment sender knows the size of the original
Bitmap, it can reconstruct the original Bitmap from the Compressed
Bitmap received in the SCH ACK message.
Figure 14 shows an example where L2 Words are actually bytes and
where the original Bitmap contains 17 bits, the last 15 of which are where the original Bitmap contains 17 bits, the last 15 of which are
all set to 1. all set to 1.
|-- SCHC ACK Header --|-------- Bitmap --------| |---- SCHC ACK Header ----|-------- Bitmap --------|
| Rule ID | DTag |W|1|0|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| |-- T --|-M-|1|
next L2 Word boundary ->| next L2 Word | next L2 Word | +---- ... --+- ... -+---+-+---------------------------------+
| Rule ID | DTag | W |0|1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1|
+---- ... --+- ... -+---+-+---------------------------------+
C |
next L2 Word boundary ->|
Figure 21: A non-encoded Bitmap Figure 14: Tentative SCHC ACK message with Bitmap before compression
Figure 22 shows that the last 14 bits are not sent. Figure 15 shows that the last 14 bits are not sent.
|-- T --|1| |---- SCHC ACK Header ----|CpBmp|
+---- ... --+- ... -+-+-+-+-+ |-- T --|-M-|1|
| Rule ID | DTag |W|1|0|1| +---- ... --+- ... -+---+-+-----+
+---- ... --+- ... -+-+-+-+-+ | Rule ID | DTag | W |0|1 0 1|
next L2 Word boundary ->| +---- ... --+- ... -+---+-+-----+
C |
next L2 Word boundary ->|
Figure 22: Optimized Bitmap format Figure 15: Actual SCHC ACK message with Compressed Bitmap, no padding
Figure 23 shows an example of a SCHC ACK with FCN ranging from 6 down Figure 16 shows an example of a SCHC ACK with tile numbers ranging
to 0, where the Bitmap indicates that the second and the fifth SCHC from 6 down to 0, where the Bitmap indicates that the second and the
Fragments have not been correctly received. fourth tile of the window have not been correctly received.
6 5 4 3 2 1 0 (*) |---- SCHC ACK Header ----|--- Bitmap --|
|-- T --|1| |-- T --|-M-|1|6 5 4 3 2 1 0| (tile #)
+-----------+-------+-+-+-+-+-+-+-+-+ +-----------+-------+---+-+-------------+
| Rule ID | DTag |W|1|0|1|1|0|1|1| Bitmap before tx | Rule ID | DTag | W |0|1 0 1 0 1 1 1| with Original Bitmap
+-----------+-------+-+-+-+-+-+-+-+-+ +-----------+-------+---+-+-------------+
next L2 Word boundary ->|<-- L2 Word -->| C
(*)=(FCN values) next L2 Word boundary ->|<-- L2 Word -->|
+-----------+-------+-+-+-+-+-+-+-+-+~~~+ +-----------+-------+---+-+-------------+~~~+
| Rule ID | DTag |W|1|0|1|1|0|1|1|Pad| Encoded Bitmap | Rule ID | DTag | W |0|1 0 1 0 1 1 1|Pad| transmitted SCHC ACK
+-----------+-------+-+-+-+-+-+-+-+-+~~~+ +-----------+-------+---+-+-------------+~~~+
next L2 Word boundary ->|<-- L2 Word -->| C
next L2 Word boundary ->|<-- L2 Word -->|
Figure 23: Example of a Bitmap before transmission, and the Figure 16: Example of a SCHC ACK message, missing tiles, with padding
transmitted one, for a window that is not the last one
Figure 24 shows an example of a SCHC ACK with FCN ranging from 6 down Figure 17 shows an example of a SCHC ACK with FCN ranging from 6 down
to 0, where MIC check has failed but the Bitmap indicates that there to 0, where integrity check has not been performed or has failed and
is no missing SCHC Fragment. the Bitmap indicates that there is no missing tile in that window.
|- Fragmentation Header-|6 5 4 3 2 1 7 (*) |---- SCHC ACK Header ----|--- Bitmap --|
|-- T --|1| |-- T --|-M-|1|6 5 4 3 2 1 0| (tile #)
| Rule ID | DTag |W|0|1|1|1|1|1|1|1| Bitmap before tx +-----------+-------+---+-+-------------+
next L2 Word boundary ->|<-- L2 Word -->| | Rule ID | DTag | W |0|1 1 1 1 1 1 1| with Original Bitmap
C +-----------+-------+---+-+-------------+
+---- ... --+- ... -+-+-+-+ C
| Rule ID | DTag |W|0|1| Encoded Bitmap next L2 Word boundary ->|
+---- ... --+- ... -+-+-+-+
next L2 Word boundary ->|
(*) = (FCN values indicating the order)
Figure 24: Example of the Bitmap in ACK-Always or ACK-on-Error for +---- ... --+- ... -+---+-+-+
the last window | Rule ID | DTag | W |0|1| transmitted SCHC ACK
+---- ... --+- ... -+---+-+-+
C
next L2 Word boundary ->|
8.4.4. Abort formats Figure 17: Example of a SCHC ACK message, no missing tile, no padding
When a SCHC Fragment sender needs to abort the on-going fragmented 8.3.3. SCHC ACK REQ format
SCHC Packet transmission, it sends a Sender-Abort. The Sender-Abort
format (see Figure 25) is a variation of the All-1 fragment, with
neither a MIC nor a payload. All-1 fragments contain at least a MIC.
The absence of the MIC indicates a Sender-Abort.
|--- Sender-Abort Header ---| The SCHC ACK REQ is used by a sender to explicitely request a SCHC
+--- ... ---+- ... -+-+-...-+~~~~~~~~~~~~~~~~~~~~~ ACK from the receiver. Its format is described in Figure 18. The
| Rule ID | DTag |W| FCN | padding (as needed) DTag field and the W field are optional.
+--- ... ---+- ... -+-+-...-+~~~~~~~~~~~~~~~~~~~~~
Figure 25: Sender-Abort format. All FCN field bits in this format |---- SCHC ACK REQ Header ----|
are set to 1 |-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 0..0 | padding (as needed) (no payload)
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
The size of the Sender-Abort header is generally not a multiple of Figure 18: SCHC ACK REQ detailed format
the L2 Word size. Therefore, a Sender-Abort generally needs padding
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. bits.
Since an All-1 fragment MIC MUST be at least the size of an L2 Word, Note that the SCHC ACK REQ has the same header as an All-0 SCHC
a receiver can distinguish a Sender-Abort from an All-1 fragment, Fragment (see Section 8.3.1.1) but it doesn't have a payload. A
even in the presence of padding. receiver can distinguish the former form the latter by the message
length, even in the presence of padding. This is possible because
When a SCHC Fragment receiver needs to abort the on-going fragmented o the padding bits are always stricly less than an L2 Word.
SCHC Packet transmission, it transmits a Receiver-Abort. The
Receiver-Abort format is a variation on the SCHC ACK format, creating
an exception in the encoded Bitmap algorithm. As shown in Figure 26,
a Receiver-Abort is coded as a SCHC ACK message with a shortened
Bitmap set to 1 up to the first 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.
The Rule ID and Dtag values in the Receive-Abort message MUST be o the size of an All-0 SCHC Fragment Payload is at least the size of
identical to the ones used in the fragments of the SCHC Packet the an L2 Word,
transmission of which is being aborted.
A Receiver-Abort is aligned to L2 Words, by design. Therefore, 8.3.4. SCHC Abort formats
8.3.4.1. SCHC Sender-Abort
When a SCHC Fragment sender needs to abort an on-going fragmented
SCHC Packet transmission, it sends a SCHC Sender-Abort message to the
SCHC Fragment receiver.
The SCHC Sender-Abort format is described in Figure 19. The DTag
field and the W field are optional.
|---- Sender-Abort Header ----|
|-- T --|-M-|-- N --|
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
| Rule ID | DTag | W | 11..1 | padding (as needed)
+-- ... --+- ... -+---+- ... -+~~~~~~~~~~~~~~~~~~~~~
Figure 19: SCHC Sender-Abort format
If the W field is present,
o the fragment sender MUST set it to all 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.
Note that the SCHC Sender-Abort has the same header as an All-1 SCHC
Fragment (see Section 8.3.1.2), but that it does not include a MIC
nor a payload. The receiver distinguishes the former from 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 abort an on-going fragmented
SCHC Packet transmission, it transmits a SCHC Receiver-Abort message
to the SCHC Fragment sender.
The SCHC Receiver-Abort format is described in Figure 20. The DTag
field and the W field are optional.
|--- Receiver-Abort Header ---|
|--- T ---|-M-|1|
+---- ... ----+-- ... --+---+-+-+-+-+-+-+-+-+-+-+-+-+
| Rule ID | DTag | W |1| 1..1| 1..1 |
+---- ... ----+-- ... --+---+-+-+-+-+-+-+-+-+-+-+-+-+
C
next L2 Word boundary ->|<-- L2 Word -->|
Figure 20: SCHC Receiver-Abort format
If the W field is present,
o the fragment receiver MUST set it to all 1's. Other values are
RESERVED.
o the fragment sender MUST check its value. If the value is
different from all 1's, the message MUST be ignored.
Note that the SCHC Receiver-Abort has the same header as a SCHC ACK
message. The bits that follow the SCHC Receiver-Abort Header MUST be
as follows
o if the Header does not end at an L2 Word boundary, append bits set
to 1 as needed to reach the next L2 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 SCHC Receiver-Abort.
A SCHC Receiver-Abort is aligned to L2 Words, by design. Therefore,
padding MUST NOT be appended. padding MUST NOT be appended.
|- Receiver-Abort Header -| The SCHC Receiver-Abort MUST NOT be acknowledged.
+---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+ 8.4. SCHC F/R modes
| Rule ID | DTag |W| 1..1| 1..1 |
+---- ... ----+-- ... --+-+-+-+-+-+-+-+-+-+-+-+-+
next L2 Word boundary ->|<-- L2 Word -->|
Figure 26: Receiver-Abort format This specification includes several SCHC F/R modes, which allow for
Neither the Sender-Abort nor the Receiver-Abort messages are ever o a range of reliability options, such as optional SCHC Fragment
acknowledged or retransmitted. retransmission
Use cases for the Sender-Abort and Receiver-Abort messages are o support of different LPWAN characteristics, such as variable MTU.
explained in Section 8.5 or Appendix C.
8.5. Baseline mechanism More modes may be defined in the future.
If after applying SCHC header compression (or when SCHC header 8.4.1. No-ACK mode
compression is not possible) the SCHC Packet does not fit within the
payload of a single L2 data unit, the SCHC Packet SHALL be broken
into SCHC Fragments and the fragments SHALL be sent to the fragment
receiver. The fragment receiver needs to identify all the SCHC
Fragments that belong to a given SCHC Packet. To this end, the
receiver SHALL use:
o The sender's L2 source address (if present), 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.
o The destination's L2 address (if present), In No-ACK mode, there is no feedback communication from the fragment
receiver to the fragment sender. The sender just transmits all the
SCHC Fragments blindly.
o Rule ID, Padding is kept to a minimum: only the last SCHC Fragment is padded
as needed.
o DTag (if present). The tile sizes are not required to be uniform. Windows are not used.
The Retransmission Timer is not used. The Attempts counter is not
used.
Then, the fragment receiver MAY determine the SCHC Fragment Each Profile MUST specify which Rule ID value(s) is (are) allocated
reliability mode that is used for this SCHC Fragment based on the to this mode. For brevity, the rest of Section 8.4.1 only refers to
Rule ID in that fragment. Rule ID values that are allocated to this mode.
After a SCHC Fragment reception, the receiver starts constructing the The W field MUST NOT be present in the SCHC F/R messages. SCHC ACK
SCHC Packet. It uses the FCN and the arrival order of each SCHC MUST NOT be sent. SCHC ACK REQ MUST NOT be sent. SCHC Sender-Abort
Fragment to determine the location of the individual fragments within MAY be sent. SCHC Receiver-Abort MUST NOT be sent.
the SCHC Packet. For example, the receiver MAY place the fragment
payload within a payload reassembly buffer at the location determined
from the FCN, the arrival order of the SCHC Fragments, and the
fragment payload sizes. In ACK-on-Error or ACK-Always, the fragment
receiver also uses the W bit in the received SCHC Fragments. Note
that the size of the original, unfragmented packet cannot be
determined from fragmentation headers.
Fragmentation functionality uses the FCN value to transmit the SCHC The value of N (size of the FCN field) is RECOMMENDED to be 1.
Fragments. It has a length of N bits where the All-1 and All-0 FCN
values are used to control the fragmentation transmission. The rest
of the FCN numbers MUST be assigned sequentially in a decreasing
order, the first FCN of a window is RECOMMENDED to be MAX_WIND_FCN,
i.e. the highest possible FCN value depending on the FCN number of
bits.
In all modes, the last SCHC Fragment of a packet MUST contain a MIC Each Profile, for each Rule ID value, MUST define
which is used to check if there are errors or missing SCHC Fragments
and MUST use the corresponding All-1 fragment format. Note that a
SCHC Fragment with an All-0 format is considered the last SCHC
Fragment of the current window.
If the receiver receives the last fragment of a SCHC Packet (All-1), o the presence or absence of the DTag field in the SCHC F/R
it checks for the integrity of the reassembled SCHC Packet, based on messages, as well as its size if it is present,
the MIC received. In No-ACK, if the integrity check indicates that
the reassembled SCHC Packet does not match the original SCHC Packet
(prior to fragmentation), the reassembled SCHC Packet MUST be
discarded. In ACK-on-Error or ACK-Always, a MIC check is also
performed by the fragment receiver after reception of each subsequent
SCHC Fragment retransmitted after the first MIC check.
Notice that the SCHC ACK for the All-1 window carries one more bit o the size and algorithm for the MIC field in the SCHC F/R messages,
(the C bit) compared to the SCHC ACKs for the previous windows. See if different from the default,
Appendix D for a discussion on various options to deal with this
"bump" in the SCHC ACK.
There are three reliability modes: No-ACK, ACK-Always and ACK-on- o the expiration time of the Inactivity Timer
Error. In ACK-Always and ACK-on-Error, a jumping window protocol
uses two windows alternatively, identified as 0 and 1. A SCHC
Fragment with all FCN bits set to 0 (i.e. an All-0 fragment)
indicates that the window is over (i.e. the SCHC Fragment is the last
one of the window) and allows to switch from one window to the next
one. The All-1 FCN in a SCHC Fragment indicates that it is the last
fragment of the packet being transmitted and therefore there will not
be another window for this packet.
8.5.1. No-ACK Each Profile, for each Rule ID value, MAY define
In the No-ACK mode, there is no feedback communication from the o a value of N different from the recommend one,
fragment receiver. The sender will send all the SCHC fragments of a
packet without any possibility of knowing if errors or losses have
occurred. As, in this mode, there is no need to identify specific
SCHC Fragments, a one-bit FCN MAY be used. Consequently, the FCN
All-0 value is used in all SCHC fragments except the last one, which
carries an All-1 FCN and the MIC. The receiver will wait for SCHC
Fragments and will set the Inactivity timer. The receiver will use
the MIC contained in the last SCHC Fragment to check for errors.
When the Inactivity Timer expires or if the MIC check indicates that
the reassembled packet does not match the original one, the receiver
will release all resources allocated to reassembling this packet.
The initial value of the Inactivity Timer will be determined based on
the characteristics of the underlying LPWAN technology and will be
defined in other documents (e.g. technology-specific profile
documents).
8.5.2. ACK-Always o what values will be sent in the FCN field, for values different
from the All-1 value.
In ACK-Always, the sender transmits SCHC Fragments by using the two- The receiver, for each pair of Rule ID and optional DTag values, MUST
jumping-windows procedure. A delay between each SCHC fragment can be maintain
added to respect local regulations or other constraints imposed by
the applications. Each time a SCHC fragment is sent, the FCN is
decreased by one. When the FCN reaches value 0, if there are more
SCHC Fragments remaining to be sent, the sender transmits the last
SCHC Fragment of this window using the All-0 fragment format. It
then starts the Retransmission Timer and waits for a SCHC ACK.
Otherwise, if FCN reaches 0 and the sender transmits the last SCHC
Fragment of the SCHC Packet, the sender uses the All-1 fragment
format, which includes a MIC. The sender sets the Retransmission
Timer and waits for the SCHC ACK to know if transmission errors have
occurred.
The Retransmission Timer is dimensioned based on the LPWAN technology o one Inactivity Timer
in use. When the Retransmission Timer expires, the sender sends an
All-0 empty (resp. All-1 empty) fragment to request again the SCHC
ACK for the window that ended with the All-0 (resp. All-1) fragment
just sent. The window number is not changed.
After receiving an All-0 or All-1 fragment, the receiver sends a SCHC 8.4.1.1. Sender behaviour
ACK with an encoded Bitmap reporting whether any SCHC fragments have
been lost or not. When the sender receives a SCHC ACK, it checks the
W bit carried by the SCHC ACK. Any SCHC ACK carrying an unexpected W
bit value is discarded. If the W bit value of the received SCHC ACK
is correct, the sender analyzes the rest of the SCHC ACK message,
such as the encoded Bitmap and the MIC. If all the SCHC Fragments
sent for this window have been well received, and if at least one
more SCHC Fragment needs to be sent, the sender advances its sending
window to the next window value and sends the next SCHC Fragments.
If no more SCHC Fragments have to be sent, then the fragmented SCHC
Packet transmission is finished.
However, if one or more SCHC Fragments have not been received as per At the beginning of the fragmentation of a new SCHC Packet, the
the SCHC ACK (i.e. the corresponding bits are not set in the encoded fragment sender MUST select a Rule ID and optional DTag value pair
Bitmap) then the sender resends the missing SCHC Fragments. When all for this SCHC Packet. For brevity, the rest of Section 8.4.1 only
missing SCHC Fragments have been retransmitted, the sender starts the refers to SCHC F/R messages bearing the Rule ID and optional DTag
Retransmission Timer, even if an All-0 or an All-1 has not been sent values hereby selected.
as part of this retransmission and waits for a SCHC ACK. Upon
receipt of the SCHC ACK, if one or more SCHC Fragments have not yet
been received, the counter Attempts is increased and the sender
resends the missing SCHC Fragments again. When Attempts reaches
MAX_ACK_REQUESTS, the sender aborts the on-going fragmented SCHC
Packet transmission by sending a Sender-Abort message and releases
any resources for transmission of the packet. The sender also aborts
an on-going fragmented SCHC Packet transmission when a failed MIC
check is reported by the receiver or when a SCHC Fragment that has
not been sent is reported in the encoded Bitmap.
On the other hand, at the beginning, the receiver side expects to Each SCHC Fragment MUST contain exactly one tile in its Payload. The
receive window 0. Any SCHC Fragment received but not belonging to tile MUST be at least the size of an L2 Word. The sender MUST
the current window is discarded. All SCHC Fragments belonging to the transmit the SCHC Fragments messages in the order that the tiles
correct window are accepted, and the actual SCHC Fragment number appear in the SCHC Packet. Except for the last tile of a SCHC
managed by the receiver is computed based on the FCN value. The Packet, each tile MUST be of a size that complements the SCHC
receiver prepares the encoded Bitmap to report the correctly received Fragment Header so that the SCHC Fragment is a multiple of L2 Words
and the missing SCHC Fragments for the current window. After each without the need for padding bits. Except for the last one, the SCHC
SCHC Fragment is received, the receiver initializes the Inactivity Fragments MUST use the Regular SCHC Fragment format specified in
Timer. When the Inactivity Timer expires, the transmission is Section 8.3.1.1. The last SCHC Fragment MUST use the All-1 format
aborted by the receiver sending a Receiver-Abort message. specified in Section 8.3.1.2.
When an All-0 fragment is received, it indicates that all the SCHC The MIC MUST be computed on the reassembled SCHC Packet concatenated
Fragments have been sent in the current window. Since the sender is with the padding bits of the last SCHC Fragment. The rationale is
not obliged to always send a full window, some SCHC Fragment number that the SCHC Reassembler has no way of knowing where the payload of
not set in the receiver memory may not correspond to losses. The the last SCHC Fragment ends. Indeed, this requires decompressing the
receiver sends the corresponding SCHC ACK, the Inactivity Timer is SCHC Packet, which is out of the scope of the SCHC Reassembler.
set and the transmission of the next window by the sender can start.
If an All-0 fragment has been received and all SCHC Fragments of the The sender MAY transmit a SCHC Sender-Abort.
current window have also been received, the receiver then expects a
new Window and waits for the next SCHC Fragment. Upon receipt of a
SCHC Fragment, if the window value has not changed, the received SCHC
Fragments are part of a retransmission. A receiver that has already
received a SCHC Fragment SHOULD discard it, otherwise, it updates the
Bitmap. If all the bits of the Bitmap are set to one, the receiver
MUST send a SCHC ACK without waiting for an All-0 fragment and the
Inactivity Timer is initialized.
On the other hand, if the window value of the next received SCHC Figure 35 shows an example of a corresponding state machine.
Fragment is set to the next expected window value, this means that
the sender has received a correct encoded Bitmap reporting that all
SCHC Fragments have been received. The receiver then updates the
value of the next expected window.
When an All-1 fragment is received, it indicates that the last SCHC 8.4.1.2. Receiver behaviour
Fragment of the packet has been sent. Since the last window is not
always full, the MIC will be used by the receiver to detect if all
SCHC Fragments of the packet have been received. A correct MIC
indicates the end of the transmission but the receiver MUST stay
alive for an Inactivity Timer period to answer to any empty All-1
fragments the sender MAY send if SCHC ACKs sent by the receiver are
lost. If the MIC is incorrect, some SCHC Fragments have been lost.
The receiver sends the SCHC ACK regardless of successful fragmented
SCHC Packet reception or not, the Inactitivity Timer is set. In case
of an incorrect MIC, the receiver waits for SCHC Fragments belonging
to the same window. After MAX_ACK_REQUESTS, the receiver will abort
the on-going fragmented SCHC Packet transmission by transmitting a
the Receiver-Abort format. The receiver also aborts upon Inactivity
Timer expiration by sending a Receiver-Abort message.
If the sender receives a SCK ACK with a Bitmap containing a bit set On receiving Regular SCHC Fragments,
for a SCHC Fragment that it has not sent during the transmission
phase of this window, it MUST abort the whole fragmentation and
transmission of this SCHC Packet.
8.5.3. ACK-on-Error o the receiver MUST reset the Inactivity Timer,
The senders behavior for ACK-on-Error and ACK-Always are similar. o the receiver assembles the payloads of the SCHC Fragments
The main difference is that in ACK-on-Error the SCHC ACK with the
encoded Bitmap is not sent at the end of each window but only when at
least one SCHC Fragment of the current window has been lost. Except
for the last window where a SCHC ACK MUST be sent to finish the
transmission.
In ACK-on-Error, the Retransmission Timer expiration is considered as On receiving an All-1 SCHC Fragment,
a positive acknowledgement for all windows but the last one. This
timer is set after sending an All-0 or an All-1 fragment. For an
All-0 fragment, on timer expiration, the sender resumes operation and
sends the SCHC Fragments of the next window.
If the sender receives a SCHC ACK, it checks the window value. SCHC o the receiver MUST append the All-1 SCHC Fragment Payload and the
ACKs with an unexpected window number are discarded. If the window padding bits to the previously received SCHC Fragment Payloads for
number in the received SCHC ACK is correct, the sender verifies if this SCHC Packet
the receiver has received all SCHC fragments of the current window.
When at least one SCHC Fragment has been lost, the counter Attempts
is increased by one and the sender resends the missing SCHC Fragments
again. When Attempts reaches MAX_ACK_REQUESTS, the sender sends a
Sender-Abort message and releases all resources for the on-going
fragmented SCHC Packet transmission. When the retransmission of the
missing SCHC Fragments is finished, the sender starts listening for a
SCHC ACK (even if an All-0 or an All-1 has not been sent during the
retransmission) and initializes the Retransmission Timer.
After sending an All-1 fragment, the sender listens for a SCHC ACK, o if an integrity checking is specified in the Profile,
initializes Attempts, and starts the Retransmission Timer. If the
Retransmission Timer expires, Attempts is increased by one and an
empty All-1 fragment is sent to request the SCHC ACK for the last
window. If Attempts reaches MAX_ACK_REQUESTS, the sender aborts the
on-going fragmented SCHC Packet transmission by transmitting the
Sender-Abort fragment.
At the end of any window, if the sender receives a SCK ACK with a * the receiver MUST perform the integrity check
Bitmap containing a bit set for a SCHC Fragment that it has not sent
during the transmission phase of that window, it MUST abort the whole
fragmentation and transmission of this SCHC Packet.
Unlike the sender, the receiver for ACK-on-Error has a larger amount * if integrity checking fails, the receiver MUST drop the
of differences compared with ACK-Always. First, a SCHC ACK is not reassembled SCHC Packet and it MUST release all resources
sent unless there is a lost SCHC Fragment or an unexpected behavior. associated with this Rule ID and optional DTag values.
With the exception of the last window, where a SCHC ACK is always
sent regardless of SCHC Fragment losses or not. The receiver starts
by expecting SCHC Fragments from window 0 and maintains the
information regarding which SCHC Fragments it receives. After
receiving a SCHC Fragment, the Inactivity Timer is set. If no
further SCHC Fragment are received and the Inactivity Timer expires,
the SCHC Fragment receiver aborts the on-going fragmented SCHC Packet
transmission by transmitting the Receiver-Abort data unit.
Any SCHC Fragment not belonging to the current window is discarded. o the reassembly operation concludes.
The actual SCHC Fragment number is computed based on the FCN value.
When an All-0 fragment is received and all SCHC Fragments have been
received, the receiver updates the expected window value and expects
a new window and waits for the next SCHC Fragment.
If the window value of the next SCHC Fragment has not changed, the
received SCHC Fragment is a retransmission. A receiver that has
already received a Fragment discard it. If all SCHC Fragments of a
window (that is not the last one) have been received, the receiver
does not send a SCHC ACK. While the receiver waits for the next
window and if the window value is set to the next value, and if an
All-1 fragment with the next value window arrived the receiver knows
that the last SCHC Fragment of the packet has been sent. Since the
last window is not always full, the MIC will be used to detect if all
SCHC Fragments of the window have been received. A correct MIC check
indicates the end of the fragmented SCHC Packet transmission. An ACK
is sent by the SCHC Fragment receiver. In case of an incorrect MIC,
the receiver waits for SCHC Fragments belonging to the same window or
the expiration of the Inactivity Timer. The latter will lead the
receiver to abort the on-going SCHC fragmented packet transmission by
transmitting the Receiver-Abort message.
If, after receiving an All-0 fragment the receiver missed some SCHC On expiration of the Inactivity Timer, the receiver MUST drop the
Fragments, the receiver uses a SCHC ACK with the encoded Bitmap to SCHC Packet being reassembled and it MUST release all resources
ask the retransmission of the missing fragments and expect to receive associated with this Rule ID and optional DTag values.
SCHC Fragments with the actual window. While waiting the
retransmission an All-0 empty fragment is received, the receiver
sends again the SCHC ACK with the encoded Bitmap, if the SCHC
Fragments received belongs to another window or an All-1 fragment is
received, the transmission is aborted by sending a Receiver-Abort
fragment. Once it has received all the missing fragments it waits
for the next window fragments.
8.6. Supporting multiple window sizes On receiving a SCHC Sender-Abort, the receiver MAY release all
resources associated with this Rule ID and optional DTag values.
For ACK-Always or ACK-on-Error, implementers MAY opt to support a The MIC computed at the receiver MUST be computed over the
single window size or multiple window sizes. The latter, when reassembled SCHC Packet and over the padding bits that were received
feasible, may provide performance optimizations. For example, a in the SCHC Fragment carrying the last tile.
large window size SHOULD be used for packets that need to be carried
by a large number of SCHC Fragments. However, when the number 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 all SCHC Fragments. If multiple window sizes are
supported, the Rule ID MAY be used to signal the window size in use
for a specific packet transmission.
Note that the same window size MUST be used for the transmission of Figure 36 shows an example of a corresponding state machine.
all SCHC Fragments that belong to the same SCHC Packet.
8.7. Downlink SCHC Fragment transmission 8.4.2. ACK-Always
In some LPWAN technologies, as part of energy-saving techniques, The ACK-Always mode has been designed under the following assumptions
downlink transmission is only possible immediately after an uplink
transmission. In order to avoid potentially high delay in the
downlink transmission of a fragmented SCHC Packet, the SCHC Fragment
receiver MAY perform an uplink transmission as soon as possible after
reception of a 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 to a SCHC Fragment encapsulated in a L2 frame that requires
an L2 ACK) or it MAY be triggered from an upper layer.
For downlink transmission of a fragmented SCHC Packet in ACK-Always o Data unit out-of-sequence delivery does not occur between the
mode, the SCHC Fragment receiver MAY support timer-based SCHC ACK entity performing fragmentation and the entity performing
retransmission. In this mechanism, the SCHC Fragment receiver reassembly
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 not start a timer
after transmission of the SCHC ACK.
If, after transmission of a SCHC ACK that is not an All-1 fragment, o The L2 MTU value does not change while a fragmented SCHC Packet is
and before expiration of the corresponding Inactivity timer, the SCHC being transmitted.
Fragment receiver receives a SCHC Fragment that belongs to the
current window (e.g. a missing SCHC Fragment from the current window)
or to the next window, the Inactivity timer for the SCHC ACK is
stopped. However, if the Inactivity timer expires, the SCHC ACK is
resent and the Inactivity timer is reinitialized and restarted.
The default initial value for the Inactivity timer, as well as the In ACK-Always mode, windows are used. An acknowledgement, positive
maximum number of retries for a specific SCHC ACK, denoted or negative, is fed by the fragment receiver back to the fragment
MAX_ACK_RETRIES, are not defined in this document, and need to be sender at the end of the transmission of each window of SCHC
defined in other documents (e.g. technology-specific profiles). The Fragments.
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) SCHC Fragment to be retransmitted can find an opportunity
for that transmission.
When the SCHC Fragment sender transmits the All-1 fragment, it starts The tiles are not required to be of uniform size. Padding is kept to
its Retransmission Timer with a large timeout value (e.g. several a minimum: only the last SCHC Fragment is padded as needed.
times that of the initial Inactivity timer). If a SCHC ACK is
received before expiration of this timer, the SCHC Fragment sender In a nutshell, the algorithm is the following: after a first blind
retransmits any lost SCHC Fragments reported by the SCHC ACK, or if transmission of all the tiles of a window, the fragment sender
the SCHC ACK confirms successful reception of all SCHC Fragments of iterates retransmitting the tiles that are reported missing until the
the last window, the transmission of the fragmented SCHC Packet is fragment receiver reports that all the tiles belonging to the window
considered complete. If the timer expires, and no SCHC ACK has been have been correctly received, or until too many attempts were made.
received since the start of the timer, the SCHC Fragment sender The fragment sender only advances to the next window of tiles when it
assumes that the All-1 fragment has been successfully received (and has ascertained that all the tiles belonging to the current window
possibly, the last SCHC ACK has been lost: this mechanism assumes have been fully and correctly received. This results in a lock-step
that the retransmission timer for the All-1 fragment is long enough behaviour between the sender and the receiver, at the window
to allow several SCHC ACK retries if the All-1 fragment has not;been granularity.
received by the SCHC Fragment receiver, and it also assumes that it
is unlikely that several ACKs become all lost). Each Profile MUST specify which Rule ID value(s) is (are) allocated
to this mode. For brevity, the rest of Section 8.4.1 only refers to
Rule ID values that are allocated to this mode.
The W 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 the FCN field),
o the value of MAX_WIND_FCN
o the size and algorithm for the MIC field in the SCHC F/R messages,
if different from the 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 expiration time 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.2.1. Sender behaviour
At the beginning of the fragmentation of a new SCHC Packet, the
fragment sender MUST select a Rule ID and DTag value pair for this
SCHC Packet. For brevity, the rest of Section 8.4.2 only refers to
SCHC F/R messages bearing the Rule ID and optional DTag values hereby
selected.
Each SCHC Fragment MUST contain exactly one tile in its Payload. All
tiles with the number 0 in their window, as well as the last tile,
MUST be at least the size of an L2 Word.
In all SCHC Fragment messages, the W field MUST be filled with the
least significant bit of the window number that the sender is
currently processing.
If a SCHC Fragment carries a tile that is not the last one of the
SCHC Packet,
o it MUST be of the Regular 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 SCHC Fragment
Header so that the SCHC Fragment is a multiple of L2 Words without
the need for padding bits.
The SCHC Fragment that carries the last tile MUST be an All-1 SCHC
Fragment, described in Section 8.3.1.2.
The bits on which the MIC is computed MUST be the SCHC Packet
concatenated with the potential padding bits that are appended to the
Payload of the SCHC Fragment that carries the last tile.
The fragment sender MUST start by processing the window 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 ACK indicates that some tiles are missing at the
receiver, then the sender MUST transmit all the tiles that have
been reported missing, it MUST increment Attempts, it MUST
reset the Retransmission Timer and MUST expect to receive a
SCHC ACK again.
* if the current window is not the last one and the SCHC ACK
indicates that all tiles were correctly received, the sender
MUST stop the Retransmission Timer, it MUST advance to the next
fragmentation window and it MUST start a blind transmission
phase as described above.
* if the current window is the last one and the SCHC ACK
indicates that more tiles were received than the sender
actually sent, the fragment sender MUST send a SCHC Sender-
Abort, it MUST release all resource associated with this SCHC
Packet and it MAY exit with an error condition.
* if the current window is the last one and the SCHC ACK
indicates that all tiles were correctly received yet integrity
check was a failure, the fragment sender MUST send a SCHC
Sender-Abort, it MUST release all resource associated with this
SCHC Packet and it MAY exit with an error condition.
* if the current window is the last one and the SCHC ACK
indicates that integrity checking was successful, the sender
exits successfully.
o on Retransmission Timer expiration,
* if Attempts is strictly less that MAX_ACK_REQUESTS, the
fragment sender MUST send a SCHC ACK REQ and MUST increment the
Attempts counter.
* otherwise the fragment sender MUST send a SCHC Sender-Abort, it
MUST release all resource associated with this SCHC Packet and
it MAY exit with an error condition.
At any time,
o on receiving a SCHC Receiver-Abort, the fragment sender MUST
release all resource associated with this SCHC Packet and it MAY
exit with an error condition.
o on receiving a SCHC ACK that bears a W value different from the W
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
been used for that Rule ID value, thereby ensuring that the
received SCHC Fragment is not a remnant of a prior fragmented SCHC
Packet transmission. If the SCHC Fragment is determined to be
such a remant, the receiver MAY silently ignore it and discard it.
o the receiver MUST start a process to assemble a new SCHC Packet
with that Rule ID and DTag value pair. That process MUST only
examine received SCHC 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 the receiver MUST start an Inactivity Timer. It MUST initialise
an Attempts counter to 0. It MUST initialise a window counter to
0.
In the rest of this section, "local W bit" means the least
significant bit of the window counter of the receiver.
On reception of any SCHC F/R message, the receiver MUST 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, the receiver MUST silently ignore
and discard that message.
o on receiving a SCHC Fragment with the W bit equal to the local W
bit, the receiver MUST assemble the received tile based on the
window counter and on the FCN field in the SCHC Fragment and it
MUST update the Bitmap.
* if the SCHC Fragment received is an All-0 SCHC Fragment, the
current window is determined to be a not-last window, and the
receiver MUST send a SCHC ACK for this window. Then,
+ If the Bitmap indicates that all the tiles of the current
window have been correctly 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.
* if the SCHC Fragment received is an All-1 SCHC Fragment, the
padding bits of the All-1 SCHC Fragment MUST be assembled after
the received tile, the current window is determined to be the
last window, the receiver MUST perform the integrity check and
it MUST send a SCHC ACK for this window. Then,
+ If the integrity check indicates that the full SCHC Packet
has been correctly reassembled, the receiver MUST enter the
"clean-up phase".
+ If the integrity check indicates that the full SCHC Packet
has not been correctly reassembled, the receiver enters the
"equalization phase" for this window.
o on receiving a SCHC ACK REQ with the W bit equal to the local W
bit, the receiver has not yet determined if the current window is
a not-last one or the last one, the receiver MUST send a SCHC ACK
for this window, and it keeps accepting incoming messages.
In the "equalization phase":
o if the window is a not-last window
* on receiving a SCHC Fragment or 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 the local W
bit, the receiver MUST send a SCHC ACK for this window.
* on receiving a SCHC Fragment with 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 discard it.
+ otherwise, the receiver MUST update the Bitmap and it MUST
assemble the tile received.
* on the Bitmap becoming fully populated with 1's, the receiver
MUST send a SCHC ACK for this window, it MUST increment its
window counter and it enters the "acceptance phase" for the new
window.
o if the window is the last window
* on receiving a SCHC Fragment or 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 the local W
bit, the receiver MUST send a SCHC ACK for this window.
* on receiving a SCHC Fragment with a W bit equal to the local W
bit,
+ if the SCHC Fragment received is an All-0 SCHC Fragment, the
receiver MUST silently ignore it and discard it.
+ otherwise, the receiver MUST update the Bitmap and it MUST
assemble the tile received. If the SCHC Fragment received
is an All-1 SCHC Fragment, the receiver MUST assemble the
padding bits of the All-1 SCHC Fragment after the received
tile. It MUST perform the integrity check. Then
- if the integrity check indicates that the full SCHC
Packet has been correctly reassembled, the receiver MUST
send a SCHC ACK and it enters the "clean-up phase".
- if the integrity check indicates that the full SCHC
Packet has not been correctly reassembled,
o if the SCHC Fragment received was an All-1 SCHC
Fragment, the receiver MUST send a SCHC ACK for this
window
o it keeps accepting incoming messages.
In the "clean-up phase":
o Any received SCHC F/R message with a W bit different from the
local W bit MUST be silently 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
receiver MUST send a SCHC ACK.
o On expiration of the Inactivity Timer, the receive process for
that SCHC Packet MAY exit
At any time, on expiration of the Inactivity Timer, on receiving a
SCHC Sender-Abort or when Attempts reaches MAX_ACK_REQUESTS, the
receiver MUST send a SCHC Receiver-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 receiver MUST be computed over the
reassembled SCHC 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
The ACK-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 ACK reports on the reception of exactly one
window of tiles.
See Figure 21 for an example.
+---------------------------------------------...-----------+
| SCHC Packet |
+---------------------------------------------...-----------+
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 is wide enough that it unambiguously represents an
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 receiver for 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, the sender and
the receiver may operate in a fully decoupled fashion. The
fragmented SCHC Packet transmission concludes when
o integrity checking shows that the fragmented SCHC Packet has been
correctly reassembled at the receive end, and this information has
been conveyed back to the sender,
o or too many retransmission attempts were made,
o or the receiver determines that the transmission of this
fragmented SCHC Packet has been inactive for too long.
Each Profile MUST specify which Rule ID value(s) is (are) allocated
to this ACK-on-Error mode. For brevity, the rest of Section 8.4.3
only refers to SCHC F/R messages with Rule ID values that are
allocated to this mode.
The W field MUST be present in the SCHC F/R messages.
Each Profile, for each Rule ID value, MUST define
o the tile size (a tile does not need to be multiple of an L2 Word,
but it MUST be at least the size of an L2 Word)
o the value 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 the MIC field in the SCHC F/R messages,
if different from the 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 expiration time 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 a new SCHC Packet,
o the fragment sender MUST select a Rule ID and DTag value pair for
this SCHC Packet. A Rule MUST NOT be selected if the values of M
and MAX_WIND_FCN for that Rule are such that the SCHC Packet
cannot be fragmented in (2&#710;M) * (MAX_WIND_FCN+1) tiles or
less.
o the fragment sender MUST initialize the Attempts counter to 0 for
that Rule ID and DTag value pair.
For brevity, the rest of Section 8.4.3 only refers to SCHC F/R
messages bearing the 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 the selected tiles MUST be consecutive in the original SCHC Packet
o they MUST be placed in the SCHC Fragment 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 with the
window number of the first tile sent in that SCHC Fragment.
If a SCHC Fragment carries more than one tile, or carries one tile
that is not the last one of the SCHC Packet,
o it MUST be of the Regular 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 Fragment
o padding bits are appended to the tiles as needed to fit the
Payload size constraint of Regular SCHC Fragments
The bits on which the MIC is computed MUST be the SCHC Packet
concatenated with the padding bits that are appended to the Payload
of the SCHC Fragment that carries the last tile.
The fragment sender MAY 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 all the tiles of the fragmented SCHC Packet.
The fragment sender MUST send at least one All-1 SCHC Fragment.
Note that the last tile of a SCHC 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 sender MUST listen for SCHC ACK messages after having
sent
o an All-1 SCHC Fragment
o or a SCHC ACK REQ with the W field corresponding to the last
window.
A Profile MAY specify other times at which the fragment sender MUST
listen for SCHC ACK messages.
Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC
ACK REQ,
o it MUST increment the Attempts counter
o it MUST reset the Retransmission Timer
On Retransmission Timer expiration
o if Attempts is strictly less than MAX_ACK_REQUESTS, the fragment
sender MUST send a SCHC ACK REQ with the W field corresponding to
the last window and it MUST increment the Attempts counter
o otherwise the fragment sender MUST send a SCHC Sender-Abort and it
MUST release all resource associated with this SCHC Packet.
On receiving a SCHC ACK,
o if the W field in the SCHC ACK corresponds to the last window of
the SCHC Packet,
* if the C bit is set, the sender MAY release all resource
associated with this SCHC Packet and MAY exit successfully
* otherwise,
+ if the SCHC ACK shows no missing tile at the receiver, the
sender
- MUST send a SCHC Sender-Abort
- MUST release all resource associated with this SCHC
Packet
- MAY exit with an error condition
+ otherwise
- the fragment sender MUST send SCHC Fragment messages
containing all the tiles that are reported missing in the
SCHC ACK.
- if the last message in this sequence of SCHC Fragment
messages is not an All-1 SCHC Fragment, then the fragment
sender MUST send a SCHC ACK REQ with the W field
corresponding to the last window after the sequence.
o otherwise, the fragment sender
* MUST send SCHC Fragment messages containing the tiles that are
reported missing in the SCHC ACK
* then it MAY send a SCHC ACK REQ with the W field corresponding
to the last window
See 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
not being processed at that time
o the receiver MAY check if the optional DTag value has not recently
been used for that Rule ID value, thereby ensuring that the
received SCHC Fragment is not a remnant of a prior fragmented SCHC
Packet transmission. If the SCHC Fragment is determined to be
such a remant, the receiver MAY silently ignore it and discard it.
o the receiver MUST start a process to assemble a new SCHC Packet
with that Rule ID and DTag value pair. That process MUST only
examine received SCHC 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 the receiver MUST start an Inactivity Timer. It MUST initialise
an Attempts counter to 0.
On reception of any SCHC F/R message, the receiver MUST reset the
Inactivity Timer.
On reception of a SCHC Fragment message, the receiver MUST assemble
the received tiles based on the W and FCN fields of the SCHC
Fragment.
o if the FCN is All-1, if a Payload is present, the full SCHC
Fragment Payload MUST be assembled including the padding bits.
This is because the size of the last tile is not known by the
receiver, therefore padding bits are indistinguishable from the
tile data bits, at this stage. They will be removed by the SCHC
C/D sublayer. If the size of the SCHC Fragment Payload exceeds or
equals the size of one regular tile plus the size of an L2 Word,
this SHOULD raise an error flag.
o otherwise, tiles MUST be assembled based on the a priori known
size and padding bits MUST be discarded. The latter is possible
because
* the size of the tiles is known a priori,
* tiles are larger than an L2 Word
* padding bits are always strictly less than an L2 Word
On reception of a SCHC ACK REQ or of an All-1 SCHC Fragment,
o if the receiver has at least one window that it knows has tiles
missing, it MUST return a SCHC ACK for the lowest-numbered such
window,
o otherwise,
* if it has received at least one tile, it MUST return a SCHC ACK
for the highest-numbered window it currently has tiles for
* otherwise it MUST return a SCHC ACK for window numbered 0
A Profile MAY specify other times and circumstances at which a
receiver sends a SCHC ACK, and which window the SCHC ACK reports
about in these circumstances.
On sending a SCHC ACK, the receiver MUST increase the Attempts
counter.
From reception of an All-1 SCHC Fragment onward, a receiver MUST
check the integrity of the reassembled SCHC Packet at least every
time it prepares for sending a SCHC ACK for the last window.
On reception of a SCHC Sender-Abort, the receiver MUST release all
resource associated with this SCHC Packet.
On expiration of the Inactivity Timer, the receiver MUST send a SCHC
Receiver-Abort and it MUST release all resource associated with this
SCHC Packet.
On the Attempts counter exceeding MAX_ACK_REQUESTS, the receiver MUST
send a SCHC Receiver-Abort and it MUST release all resource
associated with this SCHC Packet.
Reassembly of the SCHC Packet concludes when
o a Sender-Abort has been received
o or the Inactivity Timer has expired
o or the Attempts counter has exceeded MAX_ACK_REQUESTS
o or when at least an All-1 SCHC Fragment has been received and
integrity checking of the reassembled SCHC Packet is successful.
The MIC computed at the receiver MUST be computed over the
reassembled SCHC Packet and over the padding bits that were received
in the SCHC Fragment 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, and that is meant to match the sender Finite State
Machine of Figure 39.
9. Padding management 9. Padding management
SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does SCHC C/D and SCHC F/R operate on bits, not bytes. SCHC itself does
not have any alignment prerequisite. If the Layer 2 below SCHC not have any alignment prerequisite. The size of SCHC Packets can be
constrains the L2 Data Unit to align to some boundary, called L2 any number of bits. If the layer below SCHC constrains the payload
Words (for example, bytes), SCHC will meet that constraint and to align to some boundary, called L2 Words (for example, bytes), SCHC
produce messages with the correct alignement. This may entail adding will meet that constraint and produce messages with the correct
extra bits (called padding bits). alignement. This may entail adding extra bits, called padding bits.
When padding occurs, the number of appended bits is strictly less When padding occurs, the number of appended bits MUST be strictly
than the L2 Word size. less than the L2 Word size.
Padding happens at most once for each Packet going through the full Padding happens at most once for each Packet during SCHC Compression
SCHC chain, i.e. Compression and (optionally) SCHC Fragmentation (see and optional SCHC Fragmentation (see Figure 2). If a SCHC Packet is
Figure 2). If a SCHC Packet is sent unfragmented (see Figure 27), it sent unfragmented (see Figure 22), it is padded as needed for
is padded as needed. If a SCHC Packet is fragmented, only the last transmission. If a SCHC Packet is fragmented, it is not padded in
fragment is padded as needed. itself, only the SCHC Fragments are padded as needed for
transmission. Some SCHC F/R modes only pad the very last SCHC
Fragment.
A packet (e.g. an IPv6 packet) A packet (e.g. an IPv6 packet)
| ^ (padding bits | ^ (padding bits
v | dropped) v | dropped)
+------------------+ +--------------------+ +------------------+ +--------------------+
| SCHC Compression | | SCHC Decompression | | SCHC Compression | | SCHC Decompression |
+------------------+ +--------------------+ +------------------+ +--------------------+
| ^ | ^
| If no fragmentation | | If no fragmentation |
+---- SCHC Packet + padding as needed ----->| +---- SCHC Packet + padding as needed ----->|
| | (MIC checked | | (MIC checked
v | and removed) v | and removed)
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| SCHC Fragmentation | | SCHC Reassembly | | SCHC Fragmentation | | SCHC Reassembly |
+--------------------+ +-----------------+ +--------------------+ +-----------------+
| ^ | ^ | ^ | ^
| | | | | | | |
| +------------- SCHC ACK ------------+ | | +------------- SCHC ACK ------------+ |
| | | |
+--------------- SCHC Fragments --------------------+ +------- SCHC Fragments + padding as needed---------+
+--- last SCHC Frag with MIC + padding as needed ---+
SENDER RECEIVER SENDER RECEIVER
Figure 27: SCHC operations, including padding as needed Figure 22: SCHC operations, including padding as needed
Each technology-specific document MUST specify the size of the L2 Each Profile MUST specify the size of the L2 Word. The L2 Word might
Word. The L2 Word might actually be a single bit, in which case at actually be a single bit, in which case at most zero bits of padding
most zero bits of padding will be appended to any message, i.e. no will be appended to any message, i.e. no padding will take place at
padding will take place at all. all.
A Profile MAY define the value of the padding bits. The RECOMMENDED
value is 0.
10. SCHC Compression for IPv6 and UDP headers 10. SCHC Compression for IPv6 and UDP headers
This section lists the different IPv6 and UDP header fields and how This section lists the different IPv6 and UDP header fields and how
they can be compressed. they can be compressed.
10.1. IPv6 version field 10.1. IPv6 version field
This field always holds the same value. Therefore, in the Rule, TV This field always holds the same value. Therefore, in the Rule, TV
is set to 6, MO to "equal" and CDA to "not-sent". is set to 6, MO to "equal" and CDA to "not-sent".
10.2. IPv6 Traffic class field 10.2. IPv6 Traffic class field
If the DiffServ field does not vary and is known by both sides, the 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 Field Descriptor in the Rule SHOULD contain a TV with this well-known
value, an "equal" MO and a "not-sent" CDA. value, an "equal" MO and a "not-sent" CDA.
Otherwise, two possibilities can be considered depending on the Otherwise (e.g. ECN bits are to be transmitted), two possibilities
variability of the value: can be considered depending on the variability of the value:
o One possibility is to not compress the field and send the original 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 value. In the Rule, TV is not set to any particular value, MO is
set to "ignore" and CDA is set to "value-sent". set to "ignore" and CDA is set to "value-sent".
o If some upper bits in the field are constant and known, a better 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 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 value with the stable known upper part, MO is set to MSB(x) and
CDA to LSB(y). CDA to LSB.
10.3. Flow label field 10.3. Flow label field
If the Flow Label field does not vary and is known by both sides, the 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 Field Descriptor in the Rule SHOULD contain a TV with this well-known
value, an "equal" MO and a "not-sent" CDA. value, an "equal" MO and a "not-sent" CDA.
Otherwise, two possibilities can be considered: Otherwise, two possibilities can be considered:
o One possibility is to not compress the field and send the original 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 value. In the Rule, TV is not set to any particular value, MO is
set to "ignore" and CDA is set to "value-sent". set to "ignore" and CDA is set to "value-sent".
o If some upper bits in the field are constant and known, a better 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 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 value with the stable known upper part, MO is set to MSB(x) and
CDA to LSB(y). CDA to LSB.
10.4. Payload Length field 10.4. Payload Length field
This field can be elided for the transmission on the LPWAN network. This field can be elided for the transmission on the LPWAN network.
The SCHC C/D recomputes the original payload length value. In the 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 Field Descriptor, TV is not set, MO is set to "ignore" and CDA is
"compute-IPv6-length". "compute-IPv6-length".
If the payload length needs to be sent and does not need to be coded 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) 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 where 's' is the number of bits to code the maximum length, and CDA
is set to LSB(s). is set to LSB.
10.5. Next Header field 10.5. Next Header field
If the Next Header field does not vary and is known by both sides, 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 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- Header value, the MO SHOULD be "equal" and the CDA SHOULD be "not-
sent". sent".
Otherwise, TV is not set in the Field Descriptor, MO is set to Otherwise, TV is not set in the Field Descriptor, MO is set to
"ignore" and CDA is set to "value-sent". Alternatively, a matching- "ignore" and CDA is set to "value-sent". Alternatively, a matching-
skipping to change at page 45, line 31 skipping to change at page 52, line 38
o in the Downlink, send the value: TV is not set, MO is set to o in the Downlink, send the value: TV is not set, MO is set to
"ignore" and CDA is set to "value-sent". "ignore" and CDA is set to "value-sent".
10.7. IPv6 addresses fields 10.7. IPv6 addresses fields
As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit As in 6LoWPAN [RFC4944], IPv6 addresses are split into two 64-bit
long fields; one for the prefix and one for the Interface Identifier long fields; one for the prefix and one for the Interface Identifier
(IID). These fields SHOULD be compressed. To allow for a single (IID). These fields SHOULD be compressed. To allow for a single
Rule being used for both directions, these values are identified by Rule being used for both directions, these values are identified by
their role (DEV or APP) and not by their position in the frame their role (DEV or APP) and not by their position in the header
(source or destination). (source or destination).
10.7.1. IPv6 source and destination prefixes 10.7.1. IPv6 source and destination prefixes
Both ends MUST be synchronized with the appropriate prefixes. For a Both ends MUST be synchronized with the appropriate prefixes. For a
specific flow, the source and destination prefixes can be unique and 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 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 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 prefixes contain the values, the MO is set to "equal" and the CDA is
set to "not-sent". set to "not-sent".
If the Rule is intended to compress packets with different prefix If the Rule is intended to compress packets with different prefix
values, match-mapping SHOULD be used. The different prefixes are 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 listed in the TV, the MO is set to "match-mapping" and the CDA is set
to "mapping-sent". See Figure 29 to "mapping-sent". See Figure 24
Otherwise, the TV contains the prefix, the MO is set to "equal" and Otherwise, the TV contains the prefix, the MO is set to "equal" and
the CDA is set to "value-sent". the CDA is set to "value-sent".
10.7.2. IPv6 source and destination IID 10.7.2. IPv6 source and destination IID
If the DEV or APP IID are based on an LPWAN address, then the IID can 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 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 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 is set to "DevIID" or "AppIID". Note that the LPWAN technology
generally carries a single identifier corresponding to the DEV. generally carries a single identifier corresponding to the DEV.
Therefore AppIID cannot be used. Therefore AppIID cannot be used.
For privacy reasons or if the DEV address is changing over time, a 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 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 that case, the TV contains the static value, the MO operator is set
to "equal" and the CDF is set to "not-sent". [RFC7217] provides some to "equal" and the CDA is set to "not-sent". [RFC7217] provides some
methods that MAY be used to derive this static identifier. methods that MAY be used to derive this static identifier.
If several IIDs are possible, then the TV contains the list of 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 possible IIDs, the MO is set to "match-mapping" and the CDA is set to
"mapping-sent". "mapping-sent".
It MAY also happen that the IID variability only expresses itself on 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 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". IID, the MO is set to "MSB" and the CDA is set to "LSB".
skipping to change at page 46, line 42 skipping to change at page 53, line 47
10.8. IPv6 extensions 10.8. IPv6 extensions
No Rule is currently defined that processes IPv6 extensions. If such No Rule is currently defined that processes IPv6 extensions. If such
extensions are needed, their compression/decompression Rules can be extensions are needed, their compression/decompression Rules can be
based on the MOs and CDAs described above. based on the MOs and CDAs described above.
10.9. UDP source and destination port 10.9. UDP source and destination port
To allow for a single Rule being used for both directions, the UDP 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 port values are identified by their role (DEV or APP) and not by
their position in the frame (source or destination). The SCHC C/D their position in the header (source or destination). The SCHC C/D
MUST be aware of the traffic direction (Uplink, Downlink) to select MUST be aware of the traffic direction (Uplink, Downlink) to select
the appropriate field. The following Rules apply for DEV and APP the appropriate field. The following Rules apply for DEV and APP
port numbers. port numbers.
If both ends know the port number, it can be elided. The TV contains 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- the port number, the MO is set to "equal" and the CDA is set to "not-
sent". sent".
If the port variation is on few bits, the TV contains the stable part 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 of the port number, the MO is set to "MSB" and the CDA is set to
skipping to change at page 48, line 13 skipping to change at page 55, line 17
better integrity protection for the UDP payload and the pseudo- 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" header. In this case, the TV is not set, the MO is set to "ignore"
and the CDA is set to "compute-checksum". and the CDA is set to "compute-checksum".
In particular, when SCHC fragmentation is used, a fragmentation MIC In particular, when SCHC fragmentation is used, a fragmentation MIC
of 2 bytes or more provides equal or better protection than the UDP of 2 bytes or more provides equal or better protection than the UDP
checksum; in that case, if the compressor is collocated with the checksum; in that case, if the compressor is collocated with the
fragmentation point and the decompressor is collocated with the fragmentation point and the decompressor is collocated with the
packet reassembly point, then compressor MAY elide the UDP checksum. packet reassembly point, then compressor MAY elide the UDP checksum.
Whether and when the UDP Checksum is elided is to be specified in the Whether and when the UDP Checksum is elided is to be specified in the
technology-specific documents. Profile.
Since the compression happens before the fragmentation, implementors Since the compression happens before the fragmentation, implementors
should understand the risks when dealing with unprotected data below should understand the risks when dealing with unprotected data below
the transport layer and take special care when manipulating that the transport layer and take special care when manipulating that
data. data.
In other cases, the checksum SHOULD be explicitly sent. The TV is 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- not set, the MO is set to "ignore" and the CDA is set to "value-
sent". sent".
skipping to change at page 49, line 46 skipping to change at page 56, line 49
Fragment sender, with a Bitmap that reports that one or more SCHC Fragment sender, with a Bitmap that reports that one or more SCHC
Fragments have been lost. In order to mitigate this possible attack, 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 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 maximum damage of the attack to an acceptable extent. However, note
that a high setting for MAX_ACK_RETRIES benefits SCHC Fragment that a high setting for MAX_ACK_RETRIES benefits SCHC Fragment
reliability modes, therefore the trade-off needs to be carefully reliability modes, therefore the trade-off needs to be carefully
considered. considered.
13. Acknowledgements 13. Acknowledgements
Thanks to Carsten Bormann, Philippe Clavier, Eduardo Ingles Sanchez, Thanks to Carsten Bormann, Philippe Clavier, Diego Dujovne, Eduardo
Arunprabhu Kandasamy, Rahul Jadhav, Sergio Lopez Bernal, Antony Ingles Sanchez, Arunprabhu Kandasamy, Rahul Jadhav, Sergio Lopez
Markovski, Alexander Pelov, Pascal Thubert, Juan Carlos Zuniga, Diego Bernal, Antony Markovski, Alexander Pelov, Charles Perkins, Edgar
Dujovne, Edgar Ramos, and Shoichi Sakane for useful design Ramos, Shoichi Sakane, and Pascal Thubert for useful design
consideration and comments. consideration and comments.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 51, line 33 skipping to change at page 58, line 38
The most common case using the mechanisms defined in this document The most common case using the mechanisms defined in this document
will be a LPWAN Dev that embeds some applications running over CoAP. will be a LPWAN Dev that embeds some applications running over CoAP.
In this example, three flows are considered. The first flow is for In this example, three flows are considered. The first flow is for
the device management based on CoAP using Link Local IPv6 addresses the device management based on CoAP using Link Local IPv6 addresses
and UDP ports 123 and 124 for Dev and App, respectively. The second 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 flow will be a CoAP server for measurements done by the Device (using
ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to ports 5683) and Global IPv6 Address prefixes alpha::IID/64 to
beta::1/64. The last flow is for legacy applications using different beta::1/64. The last flow is for legacy applications using different
ports numbers, the destination IPv6 address prefix is gamma::1/64. ports numbers, the destination IPv6 address prefix is gamma::1/64.
Figure 28 presents the protocol stack for this Device. IPv6 and UDP Figure 23 presents the protocol stack for this Device. IPv6 and UDP
are represented with dotted lines since these protocols are are represented with dotted lines since these protocols are
compressed on the radio link. compressed on the radio link.
Management Data Management Data
+----------+---------+---------+ +----------+---------+---------+
| CoAP | CoAP | legacy | | CoAP | CoAP | legacy |
+----||----+---||----+---||----+ +----||----+---||----+---||----+
. UDP . UDP | UDP | . UDP . UDP | UDP |
................................ ................................
. IPv6 . IPv6 . IPv6 . . IPv6 . IPv6 . IPv6 .
+------------------------------+ +------------------------------+
| SCHC Header compression | | SCHC Header compression |
| and fragmentation | | and fragmentation |
+------------------------------+ +------------------------------+
| LPWAN L2 technologies | | LPWAN L2 technologies |
+------------------------------+ +------------------------------+
DEV or NGW DEV or NGW
Figure 28: Simplified Protocol Stack for LP-WAN Figure 23: Simplified Protocol Stack for LP-WAN
Note that in some LPWAN technologies, only the Devs have a device ID. Note that in some LPWAN technologies, only the Devs have a device ID.
Therefore, when such technologies are used, it is necessary to Therefore, when such technologies are used, it is necessary to
statically define an IID for the Link Local address for the SCHC C/D. statically define an IID for the Link Local address for the SCHC C/D.
Rule 0 Rule 0
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent | | Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |
| | | | | | Opera. | Action ||[bits]| | | | | | | Opera. | Action ||[bits]|
+----------------+--+--+--+---------+---------------------++------+ +----------------+--+--+--+---------+---------------------++------+
skipping to change at page 53, line 11 skipping to change at page 60, line 11
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
| Field |FL|FP|DI| Value | Match | Action || Sent | | Field |FL|FP|DI| Value | Match | Action || Sent |
| | | | | | Opera. | Action ||[bits]| | | | | | | Opera. | Action ||[bits]|
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
|IPv6 version |4 |1 |Bi|6 | equal | not-sent || | |IPv6 version |4 |1 |Bi|6 | equal | not-sent || |
|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|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 Length |16|1 |Bi| | ignore | comp-length|| |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || |
|IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || | |IPv6 Hop Limit |8 |1 |Bi|255 | ignore | not-sent || |
|IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| [1] | |IPv6 DEVprefix |64|1 |Bi|[alpha/64, match- |mapping-sent|| 1 |
| | | | |fe80::/64] mapping| || | | | | | |fe80::/64] mapping| || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| [2] | |IPv6 APPprefix |64|1 |Bi|[beta/64,| match- |mapping-sent|| 2 |
| | | | |alpha/64,| mapping| || | | | | | |alpha/64,| mapping| || |
| | | | |fe80::64]| | || | | | | | |fe80::64]| | || |
|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
|UDP DEVport |16|1 |Bi|5683 | equal | not-sent || | |UDP DEVport |16|1 |Bi|5683 | equal | not-sent || |
|UDP APPport |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 Length |16|1 |Bi| | ignore | comp-length|| |
|UDP checksum |16|1 |Bi| | ignore | comp-chk || | |UDP checksum |16|1 |Bi| | ignore | comp-chk || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
skipping to change at page 53, line 36 skipping to change at page 60, line 36
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
| Field |FL|FP|DI| Value | Match | Action || Sent | | Field |FL|FP|DI| Value | Match | Action || Sent |
| | | | | | Opera. | Action ||[bits]| | | | | | | Opera. | Action ||[bits]|
+----------------+--+--+--+---------+--------+------------++------+ +----------------+--+--+--+---------+--------+------------++------+
|IPv6 version |4 |1 |Bi|6 | equal | not-sent || | |IPv6 version |4 |1 |Bi|6 | equal | not-sent || |
|IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || | |IPv6 DiffServ |8 |1 |Bi|0 | equal | not-sent || |
|IPv6 Flow Label |20|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 Length |16|1 |Bi| | ignore | comp-length|| |
|IPv6 Next Header|8 |1 |Bi|17 | equal | not-sent || | |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 |Up|255 | ignore | not-sent || |
|IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || [8] | |IPv6 Hop Limit |8 |1 |Dw| | ignore | value-sent || 8 |
|IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || | |IPv6 DEVprefix |64|1 |Bi|alpha/64 | equal | not-sent || |
|IPv6 DevIID |64|1 |Bi| | ignore | DevIID || | |IPv6 DevIID |64|1 |Bi| | ignore | DevIID || |
|IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || | |IPv6 APPprefix |64|1 |Bi|gamma/64 | equal | not-sent || |
|IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || | |IPv6 AppIID |64|1 |Bi|::1000 | equal | not-sent || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
|UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB || [4] | |UDP DEVport |16|1 |Bi|8720 | MSB(12)| LSB || 4 |
|UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB || [4] | |UDP APPport |16|1 |Bi|8720 | MSB(12)| LSB || 4 |
|UDP Length |16|1 |Bi| | ignore | comp-length|| | |UDP Length |16|1 |Bi| | ignore | comp-length|| |
|UDP checksum |16|1 |Bi| | ignore | comp-chk || | |UDP checksum |16|1 |Bi| | ignore | comp-chk || |
+================+==+==+==+=========+========+============++======+ +================+==+==+==+=========+========+============++======+
Figure 29: Context Rules Figure 24: Context Rules
All the fields described in the three Rules depicted on Figure 29 are All the fields described in the three Rules depicted on Figure 24 are
present in the IPv6 and UDP headers. The DevIID-DID value is found present in the IPv6 and UDP headers. The DevIID-DID value is found
in the L2 header. in the L2 header.
The second and third Rules use global addresses. The way the Dev The second and third Rules use global addresses. The way the Dev
learns the prefix is not in the scope of the document. learns the prefix is not in the scope of the document.
The third Rule compresses port numbers to 4 bits. The third Rule compresses port numbers to 4 bits.
Appendix B. Fragmentation Examples Appendix B. Fragmentation Examples
This section provides examples for the different fragment reliability This section provides examples for the different fragment reliability
modes specified in this document. modes specified in this document.
Figure 30 illustrates the transmission in No-ACK mode of an IPv6 Figure 25 illustrates the transmission in No-ACK mode of a SCHC
packet that needs 11 fragments. FCN is 1 bit wide. Packet that needs 11 SCHC Fragments. FCN is 1 bit wide.
Sender Receiver Sender Receiver
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------FCN=0-------->| |-------FCN=0-------->|
|-------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: success => |-----FCN=1 + MIC --->| Integrity check: success
(End)
Figure 30: Transmission in No-ACK mode of an IPv6 packet carried by Figure 25: Transmission in No-ACK mode of a SCHC Packet carried by 11
11 fragments SCHC Fragments
In the following examples, N (i.e. the size if the FCN field) is 3 In the following examples, N (the size of the FCN field) is 3 bits.
bits. Therefore, the All-1 FCN value is 7. Therefore, the All-1 FCN value is 7.
Figure 31 illustrates the transmission in ACK-on-Error of an IPv6 Figure 26 illustrates the transmission in ACK-on-Error mode of a SCHC
packet that needs 11 fragments, with MAX_WIND_FCN=6 and no fragment Packet fragmented in 11 tiles, with one tile per SCHC Fragment,
loss. MAX_WIND_FCN=6 and no lost SCHC Fragment.
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=3----->| |-----W=0, FCN=3----->|
|-----W=0, FCN=2----->| |-----W=0, FCN=2----->|
|-----W=0, FCN=1----->| |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| |-----W=0, FCN=0----->|
(no ACK) (no ACK)
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4----->| |-----W=1, FCN=4----->|
|--W=1, FCN=7 + MIC-->|MIC checked: success => |--W=1, FCN=7 + MIC-->| Integrity check: success
|<---- ACK, W=1 ------| |<-- ACK, W=1, C=1 ---| C=1
(End)
Figure 31: Transmission in ACK-on-Error mode of an IPv6 packet Figure 26: Transmission in ACK-on-Error mode of a SCHC Packet
carried by 11 fragments, with MAX_WIND_FCN=6 and no loss. fragmented in 11 tiles, with one tile per SCHC Fragment,
MAX_WIND_FCN=6 and no lost SCHC Fragment.
Figure 32 illustrates the transmission in ACK-on-Error mode of an Figure 27 illustrates the transmission in ACK-on-Error mode of a SCHC
IPv6 packet that needs 11 fragments, with MAX_WIND_FCN=6 and three Packet fragmented in 11 tiles, with one tile per SCHC Fragment,
lost fragments. MAX_WIND_FCN=6 and three lost SCHC Fragments.
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3----->| |-----W=0, FCN=3----->|
|-----W=0, FCN=2--X-->| 7 |-----W=0, FCN=2--X-->|
|-----W=0, FCN=1----->| / |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| 6543210 |-----W=0, FCN=0----->| 6543210
|<-----ACK, W=0-------|Bitmap:1101011 |<-- ACK, W=0, C=0 ---| Bitmap:1101011
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=2----->| |-----W=0, FCN=2----->|
(no ACK) (no ACK)
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->| |-----W=1, FCN=4--X-->|
|- W=1, FCN=7 + MIC ->|MIC checked: failed |- W=1, FCN=7 + MIC ->| Integrity check: failure
|<-----ACK, W=1-------|C=0 Bitmap:1100001 |<-- ACK, W=1, C=0 ---| C=0, Bitmap:1100001
|-----W=1, FCN=4----->|MIC checked: success => |-----W=1, FCN=4----->| Integrity check: success
|<---- ACK, W=1 ------|C=1, no Bitmap |<-- ACK, W=1, C=1 ---| C=1
(End)
Figure 32: Transmission in ACK-on-Error mode of an IPv6 packet Figure 27: Transmission in ACK-on-Error mode of a SCHC Packet
carried by 11 fragments, with MAX_WIND_FCN=6 and three lost fragmented in 11 tiles, with one tile per SCHC Fragment,
fragments. MAX_WIND_FCN=6 and three lost SCHC Fragments.
Figure 33 illustrates the transmission in ACK-Always mode of an IPv6 Figure 28 shows an example of a transmission in ACK-on-Error mode of
packet that needs 11 fragments, with MAX_WIND_FCN=6 and no loss. 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 of a SCHC
Packet fragmented in 11 tiles, with one tile per SCHC Fragment, with
N=3, MAX_WIND_FCN=6 and no loss.
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4----->| |-----W=0, FCN=4----->|
|-----W=0, FCN=3----->| |-----W=0, FCN=3----->|
|-----W=0, FCN=2----->| |-----W=0, FCN=2----->|
|-----W=0, FCN=1----->| |-----W=0, FCN=1----->|
|-----W=0, FCN=0----->| |-----W=0, FCN=0----->|
|<-----ACK, W=0-------| Bitmap:1111111 |<-- ACK, W=0, C=0 ---| Bitmap:1111111
|-----W=1, FCN=6----->| |-----W=1, FCN=6----->|
|-----W=1, FCN=5----->| |-----W=1, FCN=5----->|
|-----W=1, FCN=4----->| |-----W=1, FCN=4----->|
|--W=1, FCN=7 + MIC-->|MIC checked: success => |--W=1, FCN=7 + MIC-->| Integrity check: success
|<-----ACK, W=1-------| C=1 no Bitmap |<-- ACK, W=1, C=1 ---| C=1
(End) (End)
Figure 33: Transmission in ACK-Always mode of an IPv6 packet carried Figure 29: Transmission in ACK-Always mode of a SCHC Packet
by 11 fragments, with MAX_WIND_FCN=6 and no lost fragment. fragmented in 11 tiles, with one tile per SCHC Fragment, with N=3,
MAX_WIND_FCN=6 and no loss.
Figure 34 illustrates the transmission in ACK-Always mode of an IPv6 Figure 30 illustrates the transmission in ACK-Always mode of a SCHC
packet that needs 11 fragments, with MAX_WIND_FCN=6 and three lost Packet fragmented in 11 tiles, with one tile per SCHC Fragment, N=3,
fragments. MAX_WIND_FCN=6 and three lost SCHC Fragments.
Sender Receiver Sender Receiver
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->|
|-----W=1, FCN=3----->|
|-----W=1, FCN=2--X-->| 7
|-----W=1, FCN=1----->| /
|-----W=1, FCN=0----->| 6543210
|<-----ACK, W=1-------|Bitmap:1101011
|-----W=1, FCN=4----->|
|-----W=1, FCN=2----->|
|<-----ACK, W=1-------|Bitmap:
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|--W=0, FCN=7 + MIC-->|MIC checked: failed |-----W=0, FCN=3----->|
|<-----ACK, W=0-------| C= 0 Bitmap:11000001 |-----W=0, FCN=2--X-->|
|-----W=0, FCN=4----->|MIC checked: success => |-----W=0, FCN=1----->|
|<-----ACK, W=0-------| C= 1 no Bitmap |-----W=0, FCN=0----->| 6543210
|<-- ACK, W=0, C=0 ---| Bitmap:1101011
|-----W=0, FCN=4----->|
|-----W=0, FCN=2----->|
|<-- ACK, W=0, C=0 ---| Bitmap:1111111
|-----W=1, FCN=6----->|
|-----W=1, FCN=5----->|
|-----W=1, FCN=4--X-->|
|--W=1, FCN=7 + MIC-->| Integrity check: failure
|<-- ACK, W=1, C=0 ---| C=0, Bitmap:11000001
|-----W=1, FCN=4----->| Integrity check: success
|<-- ACK, W=1, C=1 ---| C=1
(End) (End)
Figure 34: Transmission in ACK-Always mode of an IPv6 packet carried Figure 30: Transmission in ACK-Always mode of a SCHC Packet
by 11 fragments, with MAX_WIND_FCN=6 and three lost fragments. fragmented in 11 tiles, with one tile per SCHC Fragment, N=3,
MAX_WIND_FCN=6 and three lost SCHC Fragments.
Figure 35 illustrates the transmission in ACK-Always mode of an IPv6 Figure 31 illustrates the transmission in ACK-Always mode of a SCHC
packet that needs 6 fragments, with MAX_WIND_FCN=6, three lost Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3,
fragments and only one retry needed to recover each lost fragment. MAX_WIND_FCN=6, three lost SCHC Fragments and only one retry needed
to recover each lost SCHC Fragment.
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->| |-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + MIC-->|MIC checked: failed |--W=0, FCN=7 + MIC-->| Integrity check: failure
|<-----ACK, W=0-------|C= 0 Bitmap:1100001 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->|MIC checked: failed |-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->|MIC checked: failed |-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2----->|MIC checked: success |-----W=0, FCN=2----->| Integrity check: success
|<-----ACK, W=0-------|C=1 no Bitmap |<-- ACK, W=0, C=1 ---| C=1
(End) (End)
Figure 35: Transmission in ACK-Always mode of an IPv6 packet carried Figure 31: Transmission in ACK-Always mode of a SCHC Packet
by 11 fragments, with MAX_WIND_FCN=6, three lost framents and only fragmented in 6 tiles, with one tile per SCHC Fragment, N=3,
one retry needed for each lost fragment. MAX_WIND_FCN=6, three lost SCHC Fragments.
Figure 36 illustrates the transmission in ACK-Always mode of an IPv6 Figure 32 illustrates the transmission in ACK-Always mode of a SCHC
packet that needs 6 fragments, with MAX_WIND_FCN=6, three lost Packet fragmented in 6 tiles, with one tile per SCHC Fragment, N=3,
fragments, and the second ACK lost. MAX_WIND_FCN=6, three lost SCHC Fragments, and the second SCHC ACK
lost.
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->| |-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + MIC-->|MIC checked: failed |--W=0, FCN=7 + MIC-->| Integrity check: failure
|<-----ACK, W=0-------|C=0 Bitmap:1100001 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->|MIC checked: failed |-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->|MIC checked: failed |-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2----->|MIC checked: success |-----W=0, FCN=2----->| Integrity check: success
| X---ACK, W=0-------|C= 1 no Bitmap |<-X-ACK, W=0, C=1 ---| C=1
timeout | | timeout | |
|--W=0, FCN=7 + MIC-->| |--- W=0, ACK REQ --->| ACK REQ
|<-----ACK, W=0-------|C= 1 no Bitmap |<-- ACK, W=0, C=1 ---| C=1
(End) (End)
Figure 36: Transmission in ACK-Always mode of an IPv6 packet carried Figure 32: Transmission in ACK-Always mode of a SCHC Packet
by 11 fragments, with MAX_WIND_FCN=6, three lost fragments, and the fragmented in 6 tiles, with one tile per SCHC Fragment, N=3,
second ACK lost. MAX_WIND_FCN=6, three lost SCHC Fragments, and the second SCHC ACK
lost.
Figure 37 illustrates the transmission in ACK-Always mode of an IPv6 Figure 33 illustrates the transmission in ACK-Always mode of a SCHC
packet that needs 6 fragments, with MAX_WIND_FCN=6, with three lost Packet fragmented in 6 tiles, with N=3, MAX_WIND_FCN=6, with three
fragments, and one retransmitted fragment lost again. lost SCHC Fragments, and one retransmitted SCHC Fragment lost again.
Sender Receiver Sender Receiver
|-----W=0, FCN=6----->| |-----W=0, FCN=6----->|
|-----W=0, FCN=5----->| |-----W=0, FCN=5----->|
|-----W=0, FCN=4--X-->| |-----W=0, FCN=4--X-->|
|-----W=0, FCN=3--X-->| |-----W=0, FCN=3--X-->|
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
|--W=0, FCN=7 + MIC-->|MIC checked: failed |--W=0, FCN=7 + MIC-->| Integrity check: failure
|<-----ACK, W=0-------|C=0 Bitmap:1100001 |<-- ACK, W=0, C=0 ---| C=0, Bitmap:1100001
|-----W=0, FCN=4----->|MIC checked: failed |-----W=0, FCN=4----->| Integrity check: failure
|-----W=0, FCN=3----->|MIC checked: failed |-----W=0, FCN=3----->| Integrity check: failure
|-----W=0, FCN=2--X-->| |-----W=0, FCN=2--X-->|
timeout| | timeout| |
|--W=0, FCN=7 + MIC-->|All-0 empty |--- W=0, ACK REQ --->| ACK REQ
|<-----ACK, W=0-------|C=0 Bitmap: 1111101 |<-- ACK, W=0, C=0 ---| C=0, Bitmap: 1111101
|-----W=0, FCN=2----->|MIC checked: success |-----W=0, FCN=2----->| Integrity check: success
|<-----ACK, W=0-------|C=1 no Bitmap |<-- ACK, W=0, C=1 ---| C=1
(End) (End)
Figure 37: Transmission in ACK-Always mode of an IPv6 packet carried Figure 33: Transmission in ACK-Always mode of a SCHC Packet
by 11 fragments, with MAX_WIND_FCN=6, with three lost fragments, and fragmented in 6 tiles, with N=3, MAX_WIND_FCN=6, with three lost SCHC
one retransmitted fragment lost again. Fragments, and one retransmitted SCHC Fragment lost again.
Figure 38 illustrates the transmission in ACK-Always mode of an IPv6 Figure 34 illustrates the transmission in ACK-Always mode of a SCHC
packet that needs 28 fragments, with N=5, MAX_WIND_FCN=23 and two Packet fragmented in 28 tiles, with one tile per SCHC Fragment, N=5,
lost fragments. Note that MAX_WIND_FCN=23 may be useful when the MAX_WIND_FCN=23 and two lost SCHC Fragments.
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).
Sender Receiver Sender Receiver
|-----W=0, FCN=23----->| |-----W=0, FCN=23----->|
|-----W=0, FCN=22----->| |-----W=0, FCN=22----->|
|-----W=0, FCN=21--X-->| |-----W=0, FCN=21--X-->|
|-----W=0, FCN=20----->| |-----W=0, FCN=20----->|
|-----W=0, FCN=19----->| |-----W=0, FCN=19----->|
|-----W=0, FCN=18----->| |-----W=0, FCN=18----->|
|-----W=0, FCN=17----->| |-----W=0, FCN=17----->|
|-----W=0, FCN=16----->| |-----W=0, FCN=16----->|
skipping to change at page 60, line 30 skipping to change at page 68, line 30
|-----W=0, FCN=9 ----->| |-----W=0, FCN=9 ----->|
|-----W=0, FCN=8 ----->| |-----W=0, FCN=8 ----->|
|-----W=0, FCN=7 ----->| |-----W=0, FCN=7 ----->|
|-----W=0, FCN=6 ----->| |-----W=0, FCN=6 ----->|
|-----W=0, FCN=5 ----->| |-----W=0, FCN=5 ----->|
|-----W=0, FCN=4 ----->| |-----W=0, FCN=4 ----->|
|-----W=0, FCN=3 ----->| |-----W=0, FCN=3 ----->|
|-----W=0, FCN=2 ----->| |-----W=0, FCN=2 ----->|
|-----W=0, FCN=1 ----->| |-----W=0, FCN=1 ----->|
|-----W=0, FCN=0 ----->| |-----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=21----->|
|-----W=0, FCN=10----->| |-----W=0, FCN=10----->|
|<------ACK, W=0-------|no Bitmap |<--- ACK, W=0, C=0 ---| Bitmap:111111111111111111111111
|-----W=1, FCN=23----->| |-----W=1, FCN=23----->|
|-----W=1, FCN=22----->| |-----W=1, FCN=22----->|
|-----W=1, FCN=21----->| |-----W=1, FCN=21----->|
|--W=1, FCN=31 + MIC-->|MIC checked: sucess => |--W=1, FCN=31 + MIC-->| Integrity check: success
|<------ACK, W=1-------|no Bitmap |<--- ACK, W=1, C=1 ---| C=1
(End) (End)
Figure 38: Transmission in ACK-Always mode of an IPv6 packet carried Figure 34: Transmission in ACK-Always mode of a SCHC Packet
by 28 fragments, with N=5, MAX_WIND_FCN=23 and two lost fragments. fragmented in 28 tiles, with one tile per SCHC Fragment, N=5,
MAX_WIND_FCN=23 and two lost SCHC Fragments.
Appendix C. Fragmentation State Machines Appendix C. Fragmentation State Machines
The fragmentation state machines of the sender and the receiver, one The fragmentation state machines of the sender and the receiver, one
for each of the different reliability modes, are described in the for each of the different reliability modes, are described in the
following figures: following figures:
+===========+ +===========+
+------------+ Init | +------------+ Init |
| FCN=0 +===========+ | FCN=0 +===========+
skipping to change at page 61, line 23 skipping to change at page 69, line 23
+--------> | Send | send Fragment (FCN=0) +--------> | Send | send Fragment (FCN=0)
+===+=======+ +===+=======+
| last fragment | last fragment
| ~~~~~~~~~~~~ | ~~~~~~~~~~~~
| FCN = 1 | FCN = 1
v send fragment+MIC v send fragment+MIC
+============+ +============+
| END | | END |
+============+ +============+
Figure 39: Sender State Machine for the No-ACK Mode Figure 35: Sender State Machine for the No-ACK Mode
+------+ Not All-1 +------+ Not All-1
+==========+=+ | ~~~~~~~~~~~~~~~~~~~ +==========+=+ | ~~~~~~~~~~~~~~~~~~~
| + <--+ set Inactivity Timer | + <--+ set Inactivity Timer
| RCV Frag +-------+ | RCV Frag +-------+
+=+===+======+ |All-1 & +=+===+======+ |All-1 &
All-1 & | | |MIC correct All-1 & | | |MIC correct
MIC wrong | |Inactivity | MIC wrong | |Inactivity |
| |Timer Exp. | | |Timer Exp. |
v | | v | |
+==========++ | v +==========++ | v
| Error |<-+ +========+==+ | Error |<-+ +========+==+
+===========+ | END | +===========+ | END |
+===========+ +===========+
Figure 40: Receiver State Machine for the No-ACK Mode Figure 36: Receiver State Machine for the No-ACK Mode
+=======+ +=======+
| INIT | FCN!=0 & more frags | INIT | FCN!=0 & more frags
| | ~~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~~~~~
+======++ +--+ send Window + frag(FCN) +======++ +--+ send Window + frag(FCN)
W=0 | | | FCN- W=0 | | | FCN-
Clear local Bitmap | | v set local Bitmap Clear lcl_bm | | v set lcl_bm
FCN=max value | ++==+========+ FCN=max value | ++==+========+
+> | | +> | |
+---------------------> | SEND | +---------------------> | SEND |
| +==+===+=====+ | +==+===+=====+
| FCN==0 & more frags | | last frag | FCN==0 & more frags | | last frag
| ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~
| set local-Bitmap | | set local-Bitmap | set lcl_bm | | set lcl_bm
| send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC | send wnd + frag(all-0) | | send wnd+frag(all-1)+MIC
| set Retrans_Timer | | set Retrans_Timer | set Retrans_Timer | | set Retrans_Timer
| | | | | |
|Recv_wnd == wnd & | | |Recv_wnd == wnd & | |
|Lcl_Bitmap==recv_Bitmap& | | +----------------------+ |lcl_bm==recv_bm & | | +-----------------------+
|more frag | | |lcl-Bitmap!=rcv-Bitmap| |more frag | | | lcl_bm!=rcv-bm |
|~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~ |
|Stop Retrans_Timer | | | Attemp++ v |Stop Retrans_Timer | | | Attempt++ v
|clear local_Bitmap v v | +=====+=+ |clear lcl_bm v v | +=====+=+
|window=next_window +====+===+==+===+ |Resend | |window=next_window +====+===+==+===+ |Resend |
+---------------------+ | |Missing| +---------------------+ | |Missing|
+----+ Wait | |Frag | +----+ Wait | |Frag |
not expected wnd | | Bitmap | +=======+ not expected wnd | | Bitmap | +=======+
~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp | ~~~~~~~~~~~~~~~~ +--->+ ++Retrans_Timer Exp |
discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ | discard frag +==+=+===+=+==+=+| ~~~~~~~~~~~~~~~~~ |
| | | ^ ^ |reSend(empty)All-* | | | | ^ ^ |reSend(empty)All-* |
| | | | | |Set Retrans_Timer | | | | | | |Set Retrans_Timer |
| | | | +--+Attemp++ | | | | | +--+Attempt++ |
MIC_bit==1 & | | | +-------------------------+ MIC_bit==1 & | | | +-------------------------+
Recv_window==window & | | | all missing frags sent Recv_window==window & | | | all missing frags sent
no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~ no more frag| | | ~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer ~~~~~~~~~~~~~~~~~~~~~~~~| | | Set Retrans_Timer
Stop Retrans_Timer| | | Stop Retrans_Timer| | |
+=============+ | | | +=============+ | | |
| END +<--------+ | | | END +<--------+ | |
+=============+ | | Attemp > MAX_ACK_REQUESTS +=============+ | | Attempt > MAX_ACK_REQUESTS
All-1 Window & | | ~~~~~~~~~~~~~~~~~~ All-1 Window & | | ~~~~~~~~~~~~~~~~~~
MIC_bit ==0 & | v Send Abort MIC_bit ==0 & | v Send Abort
Lcl_Bitmap==recv_Bitmap | +=+===========+ lcl_bm==recv_bm | +=+===========+
~~~~~~~~~~~~ +>| ERROR | ~~~~~~~~~~~~ +>| ERROR |
Send Abort +=============+ Send Abort +=============+
Figure 41: Sender State Machine for the ACK-Always Mode Figure 37: Sender State Machine for the ACK-Always Mode
Not All- & w=expected +---+ +---+w = Not expected Not All- & w=expected +---+ +---+w = Not expected
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~
Set local_Bitmap(FCN) | v v |discard Set lcl_bm(FCN) | v v |discard
++===+===+===+=+ ++===+===+===+=+
+---------------------+ Rcv +--->* ABORT +---------------------+ Rcv +--->* ABORT
| +------------------+ Window | | +------------------+ Window |
| | +=====+==+=====+ | | +=====+==+=====+
| | All-0 & w=expect | ^ w =next & not-All | | All-0 & w=expect | ^ w =next & not-All
| | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~~ | |~~~~~~~~~~~~~~~~~~~~~
| | set lcl_Bitmap(FCN)| |expected = next window | | set lcl_bm(FCN) | |expected = next window
| | send local_Bitmap | |Clear local_Bitmap | | send lcl_bm | |Clear lcl_bm
| | | | | | | |
| | w=expct & not-All | | | | w=expected & not-All | |
| | ~~~~~~~~~~~~~~~~~~ | | | | ~~~~~~~~~~~~~~~~~~ | |
| | set lcl_Bitmap(FCN)+-+ | | +--+ w=next & All-0 | | set lcl_bm(FCN)+-+ | | +--+ w=next & All-0
| | if lcl_Bitmap full | | | | | | ~~~~~~~~~~~~~~~ | | if lcl_bm full | | | | | | ~~~~~~~~~~~~~~~
| | send lcl_Bitmap | | | | | | expct = nxt wnd | | send lcl_bm | | | | | | expected = nxt wnd
| | v | v | | | Clear lcl_Bitmap | | v | v | | | Clear lcl_bm
| | w=expct & All-1 +=+=+=+==+=++ | set lcl_Bitmap(FCN) | |w=expected& All-1 +=+=+=+==+=++ | set lcl_bm(FCN)
| | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_Bitmap | | ~~~~~~~~~~~ +->+ Wait +<+ send lcl_bm
| | discard +--| Next | | | discard +--| Next |
| | All-0 +---------+ Window +--->* ABORT | | All-0 +---------+ Window +--->* ABORT
| | ~~~~~ +-------->+========+=++ | | ~~~~~ +-------->+========+=++
| | snd lcl_bm All-1 & w=next| | All-1 & w=nxt | | snd lcl_bm All-1 & w=next| | All-1 & w=nxt
| | & MIC wrong| | & MIC right | | & MIC wrong| | & MIC right
| | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~ | | ~~~~~~~~~~~~~~~~~| | ~~~~~~~~~~~~~~~~~~
| | set local_Bitmap(FCN)| |set lcl_Bitmap(FCN) | | set lcl_bm(FCN)| |set lcl_bm(FCN)
| | send local_Bitmap| |send local_Bitmap | | send lcl_bm| |send lcl_bm
| | | +----------------------+ | | | +----------------------+
| |All-1 & w=expct | | | |All-1 & w=expected | |
| |& MIC wrong v +---+ w=expctd & | | |& MIC wrong v +---+ w=expected & |
| |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong | | |~~~~~~~~~~~~~~~~~~~~ +====+=====+ | MIC wrong |
| |set local_Bitmap(FCN) | +<+ ~~~~~~~~~~~~~~ | | |set lcl_bm(FCN) | +<+ ~~~~~~~~~~~~~~ |
| |send local_Bitmap | Wait End | set lcl_btmp(FCN)| | |send lcl_bm | Wait End | set lcl_bm(FCN)|
| +--------------------->+ +--->* ABORT | | +--------------------->+ +--->* ABORT |
| +===+====+=+-+ All-1&MIC wrong| | +===+====+=+-+ All-1&MIC wrong|
| | ^ | ~~~~~~~~~~~~~~~| | | ^ | ~~~~~~~~~~~~~~~|
| w=expected & MIC right | +---+ send lcl_btmp | | w=expected & MIC right | +---+ send lcl_bm |
| ~~~~~~~~~~~~~~~~~~~~~~ | | | ~~~~~~~~~~~~~~~~~~~~~~ | |
| set local_Bitmap(FCN) | +-+ Not All-1 | | set lcl_bm(FCN) | +-+ Not All-1 |
| send local_Bitmap | | | ~~~~~~~~~ | | send lcl_bm | | | ~~~~~~~~~ |
| | | | discard | | | | | discard |
|All-1 & w=expctd & MIC right | | | | |All-1&w=expected & MIC right | | | |
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 | |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v | v +----+All-1 |
|set local_Bitmap(FCN) +=+=+=+=+==+ |~~~~~~~~~ | |set lcl_bm(FCN) +=+=+=+=+==+ |~~~~~~~~~ |
|send local_Bitmap | +<+Send lcl_btmp | |send lcl_bm | +<+Send lcl_bm |
+-------------------------->+ END | | +-------------------------->+ END | |
+==========+<---------------+ +==========+<---------------+
--->* ABORT --->* ABORT
~~~~~~~ ~~~~~~~
Inactivity_Timer = expires Inactivity_Timer = expires
When DWN_Link When DWL
IF Inactivity_Timer expires IF Inactivity_Timer expires
Send DWL Request Send DWL Request
Attemp++ Attempt++
Figure 42: Receiver State Machine for the ACK-Always Mode Figure 38: Receiver State Machine for the ACK-Always Mode
+=======+
| | +=======+
| INIT | | |
| | FCN!=0 & more frags | INIT |
+======++ +--+ ~~~~~~~~~~~~~~~~~~~~~~ | | FCN!=0 & more frags
W=0 | | | send Window + frag(FCN) +======++ ~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~ | | | FCN- Frag RuleID trigger | +--+ Send cur_W + frag(FCN);
Clear local Bitmap | | v set local Bitmap ~~~~~~~~~~~~~~~~~~~ | | | FCN--;
FCN=max value | ++=============+ cur_W=0; FCN=max_value;| | | set [cur_W, cur_Bmp]
+> | | clear [cur_W, Bmp_n];| | v
| SEND | clear rcv_Bmp | ++==+==========+ **BACK_TO_SEND
+-------------------------> | | +->+ | cur_W==rcv_W &
| ++=====+=======+ **BACK_TO_SEND | SEND | [cur_W,Bmp_n]==rcv_Bmp
| FCN==0 & more frags| |last frag +-------------------------->+ | & more frags
| ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~ | +----------------------->+ | ~~~~~~~~~~~~
| set local-Bitmap| |set local-Bitmap | | ++===+=========+ cur_W++;
| send wnd + frag(all-0)| |send wnd+frag(all-1)+MIC | | FCN==0 & more frags| |last frag clear [cur_W, Bmp_n]
| set Retrans_Timer| |set Retrans_Timer | | ~~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~
| | | | | set cur_Bmp; | |set [cur_W, Bmp_n];
|Retrans_Timer expires & | | lcl-Bitmap!=rcv-Bitmap | |send cur_W + frag(All-0);| |send cur_W + frag(All-1)+MIC;
|more fragments | | ~~~~~~~~~~~~~~~~~~~~~~ | | set Retrans_Timer| |set Retrans_Timer
|~~~~~~~~~~~~~~~~~~~~ | | Attemp++ | | | | +-----------------------------------+
|stop Retrans_Timer | | +-----------------+ | |Retrans_Timer expires & | | |cur_W==rcv_W&[cur_W,Bmp_n]!=rcv_Bmp|
|clear local-Bitmap v v | v | |more Frags | | | ~~~~~~~~~~~~~~~~~~~ |
|window = next window +=====+=====+==+==+ +====+====+ | |~~~~~~~~~~~~~~~~~~~~ | | | Attempts++; W=cur_W |
+----------------------+ + | Resend | | |stop Retrans_Timer; | | | +--------+ rcv_W==Wn &|
+--------------------->+ Wait Bitmap | | Missing | | |[cur_W,Bmp_n]==cur_Bmp; v v | | v [Wn,Bmp_n]!=rcv_Bmp|
| +-- + | | Frag | | |cur_W++ +=====+===+=+=+==+ +=+=========+ ~~~~~~~~~~~|
| not expected wnd | ++=+===+===+===+==+ +======+==+ | +-------------------+ | | Resend | Attempts++;|
| ~~~~~~~~~~~~~~~~ | ^ | | | ^ | +----------------------+ Wait x ACK | | Missing | W=Wn |
| discard frag +----+ | | | +-------------------+ +--------------------->+ | | Frags(W) +<-------------+
| | | | all missing frag sent | rcv_W==Wn &+-+ | +======+====+
|Retrans_Timer expires & | | | ~~~~~~~~~~~~~~~~~~~~~ | [Wn,Bmp_n]!=rcv_Bmp| ++=+===+===+==+==+ |
| No more Frag | | | Set Retrans_Timer | ~~~~~~~~~~~~~~| ^ | | | ^ |
| ~~~~~~~~~~~~~~~~~~~~~~~ | | | | send (cur_W,+--+ | | | +-------------+
| Stop Retrans_Timer | | | | ALL-0-empty) | | | all missing frag sent(W)
| Send ALL-1-empty | | | | | | | ~~~~~~~~~~~~~~~~~
+-------------------------+ | | | Retrans_Timer expires &| | | set Retrans_Timer
| | | No more Frags| | |
Local_Bitmap==Recv_Bitmap| | | ~~~~~~~~~~~~~~| | |
~~~~~~~~~~~~~~~~~~~~~~~~~| |Attemp > MAX_ACK_REQUESTS | stop Retrans_Timer;| | |
+=========+Stop Retrans_Timer | |~~~~~~~~~~~~~~~~~~~~~~~ |(re)send frag(All-1)+MIC | | |
| END +<------------------+ v Send Abort +-------------------------+ | |
+=========+ +=+=========+ cur_W==rcv_W&| |
| ERROR | [cur_W,Bmp_n]==rcv_Bmp&| | Attempts > MAX_ACK_REQUESTS
No more Frags & MIC flag==OK| | ~~~~~~~~~~
~~~~~~~~~~~~~~~~~~| | send Abort
+=========+stop Retrans_Timer| | +===========+
| END +<-----------------+ +->+ ERROR |
+=========+ +===========+
Figure 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
|
Not All* & rcv_W==cur_W+---+ | +---+
~~~~~~~~~~~~~~~~~~~~ | | | | (E)
set[cur_W,Bmp_n(FCN)]| v v v |
++===+=+=+===+=+
+----------------------+ +--+ All-0&Full[cur_W,Bmp_n]
| ABORT *<---+ Rcv Window | | ~~~~~~~~~~
| +-------------------+ +<-+ cur_W++;set Inact_timer;
| | +->+=+=+=+=+=+====+ clear [cur_W,Bmp_n]
| | All-0 empty(Wn)| | | | ^ ^
| | ~~~~~~~~~~~~~~ +----+ | | | |rcv_W==cur_W & sync==0;
| | sendACK([Wn,Bmp_n]) | | | |& Full([cur_W,Bmp_n])
| | | | | |& All* || last_miss_frag
| | | | | |~~~~~~~~~~~~~~~~~~~~~~
| | All* & rcv_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])| | | | | Error/ |
| | | | | | +----+ | Abort |
| | v v | | | | +===+====+
| | +===+=+=+=+===+=+ (D) ^
| | +--+ Wait x | | |
| | All-0 empty(Wn)+->| Missing 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 &
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)
| |
| | All-1 & rcv_W==cur_W & MIC!=OK All-0 empty(Wn)
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ ~~~~~~~~~~
| | sendACK([cur_W,Bmp_n],MIC=0) | v sendACK([Wn,Bmp_n])
| | +===========+=++
| +--------------------->+ Wait End +-+
| +=====+=+====+=+ | All-1
| rcv_W==cur_W & MIC==OK | | ^ | & rcv_W==cur_W
| ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ & MIC!=OK
| sendACK([cur_W,Bmp_n],MIC=1) | | ~~~~~~~~~~~~~~~~~~~
| | | sendACK([cur_W,Bmp_n],MIC=0);
| | | Attempts++
|All-1 & Full([cur_W,Bmp_n]) | |
|& MIC==OK & sync==0 | +-->* ABORT
|~~~~~~~~~~~~~~~~~~~ v
|sendACK([cur_W,Bmp_n],MIC=1) +=+=========+
+---------------------------->+ END |
+===========+ +===========+
Figure 43: Sender State Machine for the ACK-on-Error Mode ABORT -->* Uplink Only &
Inact_Timer = expires
|| Attempts > MAX_ACK_REQUESTS
~~~~~~~~~~~~~~~~~~~~~
send Abort
Not All- & w=expected +---+ +---+w = Not expected Figure 40: Receiver State Machine for the ACK-on-Error Mode
~~~~~~~~~~~~~~~~~~~~~ | | | |~~~~~~~~~~~~~~~~
Set local_Bitmap(FCN) | v v |discard
++===+===+===+=+
+-----------------------+ +--+ All-0 & full
| ABORT *<---+ Rcv Window | | ~~~~~~~~~~~~
| +--------------------+ +<-+ w =next
| | All-0 empty +->+=+=+===+======+ clear lcl_Bitmap
| | ~~~~~~~~~~~ | | | ^
| | send bitmap +----+ | |w=expct & not-All & full
| | | |~~~~~~~~~~~~~~~~~~~~~~~~
| | | |set lcl_Bitmap; w =nxt
| | | |
| | All-0 & w=expect | | w=next
| | & no_full Bitmap | | ~~~~~~~~ +========+
| | ~~~~~~~~~~~~~~~~~ | | Send abort| Error/ |
| | send local_Bitmap | | +---------->+ Abort |
| | | | | +-------->+========+
| | v | | | all-1 ^
| | All-0 empty +====+===+==+=+=+ ~~~~~~~ |
| | ~~~~~~~~~~~~~ +--+ Wait | Send abort |
| | send lcl_btmp +->| Missing Fragm.| |
| | +==============++ |
| | +--------------+
| | Uplink Only &
| | Inactivity_Timer = expires
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~
| | Send Abort
| |All-1 & w=expect & MIC wrong
| |~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +-+ All-1
| |set local_Bitmap(FCN) | v ~~~~~~~~~~
| |send local_Bitmap +===========+==+ snd lcl_btmp
| +--------------------->+ Wait End +-+
| +=====+=+====+=+ | w=expct &
| w=expected & MIC right | | ^ | MIC wrong
| ~~~~~~~~~~~~~~~~~~~~~~ | | +---+ ~~~~~~~~~
| set & send local_Bitmap(FCN) | | set lcl_Bitmap(FCN)
| | |
|All-1 & w=expected & MIC right | +-->* ABORT
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ v
|set & send local_Bitmap(FCN) +=+==========+
+---------------------------->+ END |
+============+
--->* ABORT
Only Uplink
Inactivity_Timer = expires
~~~~~~~~~~~~~~~~~~~~~~~~~~
Send Abort
Figure 44: Receiver State Machine for the ACK-on-Error Mode Appendix D. SCHC Parameters
Appendix D. SCHC Parameters - Ticket #15 This section lists the information that need to be provided in the
LPWAN technology-specific documents.
This section gives the list of parameters that need to be defined in o Most common uses cases, deployment scenarios
the technology-specific documents.
o Define the most common uses case and how SCHC may be deployed. o Mapping of the SCHC architectural elements onto the LPWAN
architecture
o LPWAN Architecture. Explain the SCHC entities (Compression and o Assessment of LPWAN integrity checking
Fragmentation), how/where they are represented in the
corresponding technology architecture. If applicable, explain the
various potential channel conditions for the technology and the
corresponding recommended use of C/D and F/R.
o L2 fragmentation decision o Various potential channel conditions for the technology and the
corresponding recommended use of SCHC C/D and F/R
o Technology developers must evaluate that L2 has strong enough This section lists the parameters that need to be defined in the
integrity checking to match SCHC's assumption. Profile.
o Rule ID numbering system, number of Rules o Rule ID numbering scheme, fixed-sized or variable-sized Rule IDs,
number of Rules, the way the Rule ID is transmitted
o Size of the Rule IDs o Padding: size of the L2 Word (for most LPWAN technologies, this
would be a byte; for some technologies, a bit)
o The way the Rule ID is sent (L2 or L3) and how (describe) o Decision to use SCHC fragmentation mechanism or not. If yes:
o Fragmentation delivery reliability mode used in which cases (e.g. * reliability mode(s) used, in which cases (e.g. based on link
based on link channel condition) channel condition)
o Define the number of bits for FCN (N) and DTag (T) * Rule ID values assigned to each mode in use
o in particular, is interleaved packet transmission supported and to * presence and number of bits for DTag (T) for each Rule ID value
what extent
o The MIC algorithm to be used and the size, if different from the * support for interleaved packet transmission, to what extent
default CRC32
o Retransmission Timer duration * WINDOW_SIZE, for modes that use windows
o Inactivity Timer duration * number of bits for W (M) for each Rule ID value, for modes that
use windows
o Define MAX_ACK_REQUEST (number of attempts) * number of bits for FCN (N) for each Rule ID value
o Padding: size of the L2 Word (for most technologies, a byte; for * value of MAX_WIND_FCN and use of FCN values, if applicable to
some technologies, a bit). Value of the padding bits (1 or 0). the SCHC F/R mode.
The value of the padding bits needs to be specified because the
padding bits are included in the MIC calculation.
o Take into account that the length of Rule ID + N + T + W when * size of MIC and algorithm for its computation, for each Rule
possible is good to have a multiple of 8 bits to complete a byte ID, if different from the default CRC32. Byte fill-up with
and avoid padding zeroes or other mechanism, to be specified.
o In the ACK format to have a length for Rule ID + T + W bit into a * Retransmission Timer duration for each Rule ID value, if
complete number of byte to do optimization more easily applicable to the SCHC F/R mode
o The technology documents will describe if Rule ID is constrained * Inactivity Timer duration for each Rule ID value, if applicable
by any alignment to the SCHC F/R mode
o When fragmenting in ACK-on-Error or ACK-Always mode, it is * MAX_ACK_REQUEST value for each Rule ID value, if applicable to
expected that the last window (called All-1 window) will not be the SCHC F/R mode
fully utilised, i.e. there won't be fragments with all FCN values
from MAX_WIND_FCN downto 1 and finally All-1. It is worth noting
that this document does not mandate that other windows (called
All-0 windows) are fully utilised either. This document purposely
does not specify that All-1 windows use Bitmaps with the same
number of bits as All-0 windows do. By default, Bitmaps for All-0
and All-1 windows are of the same size MAX_WIND_FCN + 1. But a
technology-specific document MAY revert that decision. The
rationale for reverting the decision could be the following: Note
that the SCHC ACK sent as a response to an All-1 fragment includes
a C bit that SCHC ACK for other windows don't have. Therefore,
the SCHC ACK for the All-1 window is one bit bigger. An L2
technology with a severely constrained payload size might decide
that this "bump" in the SCHC ACK for the last fragment is a bad
resource usage. It could thus mandate that the All-1 window is
not allowed to use the FCN value 1 and that the All-1 SCHC ACK
Bitmap size is reduced by 1 bit. This provides room for the C bit
without creating a bump in the SCHC ACK.
And the following parameters need to be addressed in another document o if L2 Word is wider than a bit and SCHC fragmentation is used,
but not forcely in the technology-specific one: value of the padding bits (0 or 1). This is needed because the
padding bits of the last fragment are included in the MIC
computation.
o The way the contexts are provisioning A Profile MAY define a delay to be added between each SCHC message
transmission to respect local regulations or other constraints
imposed by the applications.
o The way the Rules as generated o Note on soliciting downlink transmissions: In some LPWAN
technologies, as part of energy-saving techniques, downlink
transmission is only possible immediately after an uplink
transmission. In order to avoid potentially high delay in the
downlink transmission of a fragmented SCHC Packet, the SCHC
Fragment receiver may want to perform an uplink transmission as
soon as possible after reception of a 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 to a SCHC Fragment encapsulated
in a L2 PDU that requires an L2 ACK) or it may be triggered from
an upper layer.
Appendix E. Note o the following parameters need to be 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 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 to be carried
by a large number of SCHC Fragments. However, when the number 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 all SCHC Fragments. If multiple window sizes are
supported, the Rule ID MAY be used to signal the window size in use
for a specific packet transmission.
Note that the same window size MUST be used for the transmission of
all SCHC 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 this mechanism, 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 not start a timer
after transmission of the SCHC ACK.
If, after transmission of a SCHC ACK that is not an All-1 fragment,
and before expiration of the corresponding Inactivity timer, the SCHC
Fragment receiver receives a SCHC Fragment that belongs to the
current window (e.g. a missing SCHC Fragment from the current window)
or to the next window, the Inactivity timer for the SCHC ACK is
stopped. However, if the Inactivity timer expires, the SCHC ACK is
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 a specific SCHC ACK, denoted
MAX_ACK_RETRIES, are not defined in this document, and need to be
defined in a Profile. 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) SCHC Fragment to be
retransmitted can find an opportunity for that transmission.
When the SCHC Fragment sender transmits the All-1 fragment, it starts
its Retransmission Timer with a large timeout value (e.g. several
times that of the initial Inactivity timer). If a SCHC ACK is
received before expiration of this timer, the SCHC Fragment sender
retransmits any lost SCHC Fragments reported by the SCHC ACK, or if
the SCHC ACK confirms successful reception of all SCHC Fragments of
the last window, the transmission of the fragmented SCHC Packet is
considered complete. If the timer 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 ACK has been lost: this mechanism assumes
that the retransmission timer for the All-1 fragment is long enough
to allow several SCHC ACK retries if the All-1 fragment has not;been
received by the SCHC Fragment receiver, and it also assumes that it
is unlikely that several ACKs become all lost).
Appendix G. Note
Carles Gomez has been funded in part by the Spanish Government Carles Gomez has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose (Ministerio de Educacion, Cultura y Deporte) through the Jose
Castillejo grant CAS15/00336, and by the ERDF and the Spanish Castillejo grant CAS15/00336, and by the ERDF and the Spanish
Government through project TEC2016-79988-P. Part of his contribution Government through project TEC2016-79988-P. Part of his contribution
to this work has been carried out during his stay as a visiting to this work has been carried out during his stay as a visiting
scholar at the Computer Laboratory of the University of Cambridge. scholar at the Computer Laboratory of the University of Cambridge.
Authors' Addresses Authors' Addresses
Ana Minaburo Ana Minaburo
Acklio Acklio
1137A avenue des Champs Blancs 1137A avenue des Champs Blancs
35510 Cesson-Sevigne Cedex 35510 Cesson-Sevigne Cedex
France France
Email: ana@ackl.io Email: ana@ackl.io
Laurent Toutain Laurent Toutain
IMT-Atlantique IMT-Atlantique
skipping to change at line 3042 skipping to change at page 79, line 36
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
Dominique Barthel Dominique Barthel
Orange Labs Orange Labs
28 chemin du Vieux Chene 28 chemin du Vieux Chene
38243 Meylan 38243 Meylan
France France
Email: dominique.barthel@orange.com Email: dominique.barthel@orange.com
Juan Carlos Zuniga
SIGFOX
425 rue Jean Rostand
Labege 31670
France
Email: JuanCarlos.Zuniga@sigfox.com
 End of changes. 358 change blocks. 
1490 lines changed or deleted 2004 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/