diff options
Diffstat (limited to 'doc/rfc/rfc9391.txt')
| -rw-r--r-- | doc/rfc/rfc9391.txt | 1090 |
1 files changed, 1090 insertions, 0 deletions
diff --git a/doc/rfc/rfc9391.txt b/doc/rfc/rfc9391.txt new file mode 100644 index 0000000..37fcb1c --- /dev/null +++ b/doc/rfc/rfc9391.txt @@ -0,0 +1,1090 @@ + + + + +Internet Engineering Task Force (IETF) E. Ramos +Request for Comments: 9391 Ericsson +Category: Standards Track A. Minaburo +ISSN: 2070-1721 Acklio + April 2023 + + + Static Context Header Compression over Narrowband Internet of Things + +Abstract + + This document describes Static Context Header Compression and + fragmentation (SCHC) specifications, RFCs 8724 and 8824, in + combination with the 3rd Generation Partnership Project (3GPP) and + the Narrowband Internet of Things (NB-IoT). + + This document has two parts: one normative part that specifies the + use of SCHC over NB-IoT and one informational part that recommends + some values if 3GPP wants to use SCHC inside their architectures. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9391. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions and Definitions + 3. Terminology + 4. NB-IoT Architecture + 5. Data Transmission in the 3GPP Architecture + 5.1. Normative Scenarios + 5.1.1. SCHC over Non-IP Data Delivery (NIDD) + 5.2. Informational Scenarios + 5.2.1. Use of SCHC over the Radio Link + 5.2.2. Use of SCHC over the Non-Access Stratum (NAS) + 5.2.3. Parameters for Static Context Header Compression and + Fragmentation (SCHC) for the Radio Link and DoNAS Use + Cases + 6. Padding + 7. IANA Considerations + 8. Security Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Appendix A. NB-IoT User Plane Protocol Architecture + A.1. Packet Data Convergence Protocol (PDCP) + A.2. Radio Link Protocol (RLC) + A.3. Medium Access Control (MAC) + Appendix B. NB-IoT Data over NAS (DoNAS) + Acknowledgements + Authors' Addresses + +1. Introduction + + This document defines scenarios where Static Context Header + Compression and fragmentation (SCHC) [RFC8724] [RFC8824] are suitable + for 3rd Generation Partnership Project (3GPP) and Narrowband Internet + of Things (NB-IoT) protocol stacks. + + In the 3GPP and the NB-IoT networks, header compression efficiently + brings Internet connectivity to the Device UE (Dev-UE), the radio + (RGW-eNB) and network (NGW-MME) gateways, and the Application Server. + This document describes the SCHC parameters supporting SCHC over the + NB-IoT architecture. + + This document assumes functionality for NB-IoT of 3GPP release 15 + [R15-3GPP]. Otherwise, the text explicitly mentions other versions' + functionality. + + This document has two parts: normative end-to-end scenarios + describing how any application must use SCHC over the 3GPP public + service and informational scenarios about how 3GPP could use SCHC in + their protocol stack network. + +2. Conventions and Definitions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Terminology + + This document will follow the terms defined in [RFC8724], [RFC8376], + and [TR23720]. + + Capillary Gateway: Facilitates seamless integration because it has + wide-area connectivity through cellular and provides wide-area + access as a proxy to other devices using LAN technologies (BT, Wi- + Fi, Zigbee, or others). + + Cellular IoT Evolved Packet System (CIoT EPS): A functionality to + improve the support of small data transfers. + + Device UE (Dev-UE): As defined in [RFC8376], Section 3. + + Data over Non-Access Stratum (DoNAS): Sending user data within + signaling messages over the NAS functional layer. + + Evolved Packet Connectivity (EPC): Core network of 3GPP LTE systems. + + Evolved Universal Terrestrial Radio Access Network (EUTRAN): Radio + access network of LTE-based systems. + + Hybrid Automatic Repeat reQuest (HARQ): A combination of high-rate + Forward Error Correction (FEC) and Automatic Repeat reQuest (ARQ) + error control. + + Home Subscriber Server (HSS): A database that contains users' + subscription data, including data needed for mobility management. + + IP address: IPv6 or IPv4 address used. + + InterWorking Service Capabilities Exposure Function (IWK-SCEF): Used + in roaming scenarios, is located in the Visited PLMN, and serves + for interconnection with the Service Capabilities Exposure + Function (SCEF) of the Home PLMN. + + Layer 2 (L2): L2 in the 3GPP architectures includes MAC, RLC, and + PDCP layers; see Appendix A. + + Logical Channel ID (LCID): The logical channel instance of the + corresponding MAC SDU. + + Medium Access Control (MAC) protocol: Part of L2. + + Non-Access Stratum (NAS): Functional layer for signaling messages + that establishes communication sessions and maintains the + communication while the user moves. + + Narrowband IoT (NB-IoT): A 3GPP Low-Power WAN (LPWAN) technology + based on the LTE architecture but with additional optimization for + IoT and using a Narrowband spectrum frequency. + + Network Gateway - CIoT Serving Gateway Node (NGW-CSGN): As defined + in [RFC8376], Section 3. + + Network Gateway - Cellular Serving Gateway (NGW-CSGW): Routes and + forwards the user data packets through the access network. + + Network Gateway - Mobility Management Entity (NGW-MME): An entity in + charge of handling mobility of the Dev-UE. + + Network Gateway - Packet Data Network Gateway (NGW-PGW): An + interface between the internal and external network. + + Network Gateway - Service Capability Exposure Function (NGW-SCEF): E + PC node for exposure of 3GPP network service capabilities to third + party applications. + + Non-IP Data Delivery (NIDD): End-to-end communication between the UE + and the Application Server. + + Packet Data Convergence Protocol (PDCP): Part of L2. + + Public Land-based Mobile Network (PLMN): A combination of wireless + communication services offered by a specific operator. + + Protocol Data Unit (PDU): A data packet including headers that are + transmitted between entities through a protocol. + + Radio Link Protocol (RLC): Part of L2. + + Radio Gateway - evolved Node B (RGW-eNB): Base Station that controls + the UE. + + Service Data Unit (SDU): A data packet (PDU) from higher-layer + protocols used by lower-layer protocols as a payload of their own + PDUs. + +4. NB-IoT Architecture + + The NB-IoT architecture has a complex structure. It relies on + different Network Gateways (NGWs) from different providers. It can + send data via different paths, each with different characteristics in + terms of bandwidth, acknowledgments, and L2 reliability and + segmentation. + + Figure 1 shows this architecture, where the Network Gateway - + Cellular IoT Serving Gateway Node (NGW-CSGN) optimizes co-locating + entities in different paths. For example, a Dev-UE using the path + formed by the Network Gateway - Mobility Management Entity (NGW-MME), + the NGW-CSGW, and the Network Gateway - Packet Data Network Gateway + (NGW-PGW) may get a limited bandwidth transmission from a few bytes/s + to one thousand bytes/s only. + + Another node introduced in the NB-IoT architecture is the Network + Gateway - Service Capability Exposure Function (NGW-SCEF), which + securely exposes service and network capabilities to entities + external to the network operator. The Open Mobile Alliance (OMA) + [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define + the northbound APIs. [TS23222] defines architecture for the common + API framework for 3GPP northbound APIs. [TS33122] defines security + aspects for a common API framework for 3GPP northbound APIs. In this + case, the path is small for data transmission. The main functions of + the NGW-SCEF are path connectivity and device monitoring. + + +---+ +---------+ +------+ + |Dev| \ | +-----+ | ---| HSS | + |-UE| \ | | NGW | | +------+ + +---+ | | |-MME |\__ + \ / +-----+ | \ + +---+ \+-----+ /| | | +------+ + |Dev| ----| RGW |- | | | | NGW- | + |-UE| |-eNB | | | | | SCEF |---------+ + +---+ /+-----+ \| | | +------+ | + / \ +------+| | + / |\| NGW- || +-----+ +-----------+ + +---+ / | | CSGW |--| NGW-|---|Application| + |Dev| | | || | PGW | | Server | + |-UE| | +------+| +-----+ +-----------+ + +---+ | | + |NGW-CSGN | + +---------+ + + Figure 1: 3GPP Network Architecture + +5. Data Transmission in the 3GPP Architecture + + NB-IoT networks deal with end-to-end user data and in-band signaling + between the nodes and functions to configure, control, and monitor + the system functions and behaviors. The signaling uses a different + path with specific protocols, handling processes, and entities but + can transport end-to-end user data for IoT services. In contrast, + the end-to-end application only transports end-to-end data. + + The recommended 3GPP MTU size is 1358 bytes. The radio network + protocols limit the packet sizes over the air, including radio + protocol overhead, to 1600 bytes; see Section 5.2.3. However, the + recommended 3GPP MTU is smaller to avoid fragmentation in the network + backbone due to the payload encryption size (multiple of 16) and the + additional core transport overhead handling. + + 3GPP standardizes NB-IoT and, in general, the interfaces and + functions of cellular technologies. Therefore, the introduction of + SCHC entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified + in the NB-IoT standard. + + This document identifies the use cases of SCHC over the NB-IoT + architecture. + + The first use case is of the radio transmission (see Section 5.2.1) + where the Dev-UE and the RGW-eNB can use the SCHC functionalities. + + The second is where the packets transmitted over the control path can + also use SCHC when the transmission goes over the NGW-MME or NGW-SCEF + (see Section 5.2.2). + + These two use cases are also valid for any 3GPP architecture and not + only for NB-IoT. And as the 3GPP internal network is involved, they + have been put in the informational part of this section. + + And the third covers the SCHC over Non-IP Data Delivery (NIDD) + connection or at least up to the operator network edge (see + Section 5.1.1). In this case, SCHC functionalities are available in + the application layer of the Dev-UE and the Application Servers or a + broker function at the edge of the operator network. NGW-PGW or NGW- + SCEF transmit the packets that are Non-IP traffic, using IP tunneling + or API calls. It is also possible to benefit legacy devices with + SCHC by using the Non-IP transmission features of the operator + network. + + A Non-IP transmission refers to an L2 transport that is different + from NB-IoT. + +5.1. Normative Scenarios + + These scenarios do not modify the 3GPP architecture or any of its + components. They only use the architecture as an L2 transmission. + +5.1.1. SCHC over Non-IP Data Delivery (NIDD) + + This section specifies the use of SCHC over NIDD services of 3GPP. + The NIDD services of 3GPP enable the transmission of SCHC packets + compressed by the application layer. The packets can be delivered + between the NGW-PGW and the Application Server or between the NGW- + SCEF and the Application Server, using IP-tunnels or API calls. In + both cases, as compression occurs before transmission, the network + will not understand the packet, and the network does not have context + information of this compression. Therefore, the network will treat + the packet as Non-IP traffic and deliver it to the other side without + any other protocol stack element, directly over L2. + +5.1.1.1. SCHC Entities Placing over NIDD + + In the two scenarios using NIDD compression, SCHC entities are + located almost on top of the stack. The NB-IoT connectivity services + implement SCHC in the Dev-UE, an in the Application Server. The IP + tunneling scenario requires that the Application Server send the + compressed packet over an IP connection terminated by the 3GPP core + network. If the transmission uses the NGW-SCEF services, it is + possible to utilize an API call to transfer the SCHC packets between + the core network and the Application Server. Also, an IP tunnel + could be established by the Application Server if negotiated with the + NGW-SCEF. + + +---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+ + | SCHC | XXX XXX | SCHC | + |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)| + +---------+ XX +----+ XX | | +--------+ + | | XX |SCEF+-------+ | | | + | | XXX 3GPP RAN & +----+ XXX +---+ UDP | + | | XXX CORE NETWORK XXX | | | + | L2 +---+XX +------------+ | +--------+ + | | XX |IP TUNNELING+--+ | | + | | XXX +------------+ +---+ IP | + +---------+ XXXX XXXX | +--------+ + | PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY | + +---------+ +--------+ + Dev-UE Application + Server + + Figure 2: End-to-End Compression: SCHC Entities Placed when Using + Non-IP Delivery (NIDD) 3GPP Services + +5.1.1.2. Parameters for Static Context Header Compression and + Fragmentation (SCHC) + + These scenarios MAY use the SCHC header compression capability to + improve the transmission of IPv6 packets. + + * SCHC Context Initialization + + The application layer handles the static context. Consequently, + the context distribution MUST be according to the application's + capabilities, perhaps utilizing IP data transmissions up to + context initialization. Also, the static context delivery may use + the same IP tunneling or NGW-SCEF services used later for the + transport of SCHC packets. + + * SCHC Rules + + For devices acting as a capillary gateway, several rules match the + diversity of devices and protocols used by the devices associated + with the gateway. Meanwhile, simpler devices may have + predetermined protocols and fixed parameters. + + * RuleID + + This scenario can dynamically set the RuleID size before the + context delivery, for example, by negotiating between the + applications when choosing a profile according to the type of + traffic and application deployed. Transmission optimization may + require only one Physical Layer transmission. SCHC overhead + SHOULD NOT exceed the available number of effective bits of the + smallest physical Transport Block (TB) available to optimize the + transmission. The packets handled by 3GPP networks are byte- + aligned. Thus, to use the smallest TB, the maximum SCHC header + size is 12 bits. On the other hand, more complex NB-IoT devices + (such as a capillary gateway) might require additional bits to + handle the variety and multiple parameters of higher-layer + protocols deployed. The configuration may be part of the agreed + operation profile and content distribution. The RuleID field size + may range from 2 bits, resulting in 4 rules, to an 8-bit value, + yielding up to 256 rules for use by operators. A 256-rule maximum + limit seems to be quite reasonable, even for a device acting as a + NAT. An application may use a larger RuleID, but it should + consider the byte alignment of the expected Compression Residue. + In the minimum TB size case, 2 bits of RuleID leave only 6 bits + available for Compression Residue. + + * SCHC MAX_PACKET_SIZE + + In these scenarios, the maximum RECOMMENDED MTU size is 1358 bytes + since the SCHC packets (and fragments) are traversing the whole + 3GPP network infrastructure (core and radio), not only the radio + as in the IP transmissions case. + + * Fragmentation + + Packets larger than 1358 bytes need the SCHC fragmentation + function. Since the 3GPP uses reliability functions, the No-ACK + fragmentation mode MAY be enough in point-to-point connections. + Nevertheless, additional considerations are described below for + more complex cases. + + * Fragmentation Modes + + A global service assigns a QoS to the packets, e.g., depending on + the billing. Packets with very low QoS may get lost before + arriving in the 3GPP radio network transmission, e.g., in between + the links of a capillary gateway or due to buffer overflow + handling in a backhaul connection. The use of SCHC fragmentation + with the ACK-on-Error mode is RECOMMENDED to secure additional + reliability on the packets transmitted with a small trade-off on + further transmissions to signal the end-to-end arrival of the + packets if no transport protocol takes care of retransmission. + Also, the ACK-on-Error mode could be desirable to keep track of + all the SCHC packets delivered. In that case, the fragmentation + function could be activated for all packets transmitted by the + applications. SCHC ACK-on-Error fragmentation MAY be activated in + transmitting Non-IP packets on the NGW-MME. A Non-IP packet will + use SCHC reserved RuleID for non-compressing packets as [RFC8724] + allows it. + + * Fragmentation Parameters + + SCHC profile will have specific Rules for the fragmentation modes. + The rule will identify which fragmentation mode is in use, and + Section 5.2.3 defines the RuleID size. + + SCHC parametrization considers that NB-IoT aligns the bit and uses + padding and the size of the Transfer Block. SCHC will try to reduce + padding to optimize the compression of the information. The header + size needs to be a multiple of 4. The Tiles MAY keep a fixed value + of 4 or 8 bits to avoid padding, except for when the transfer block + equals 16 bits as the Tiles may be 2 bits. The transfer block size + has a wide range of values. Two configurations are RECOMMENDED for + the fragmentation parameters. + + * For Transfer Blocks smaller than or equal to 304 bits using an + 8-bit Header_size configuration, with the size of the header + fields as follows: + + - RuleID from 1 - 3 bits + + - DTag 1 bit + + - FCN 3 bits + + - W 1 bits + + * For Transfer Blocks bigger than 304 bits using a 16-bit + Header_size configuration, with the size of the header fields as + follows: + + - RulesID from 8 - 10 bits + + - DTag 1 or 2 bits + + - FCN 3 bits + + - W 2 or 3 bits + + * WINDOW_SIZE of (2^N)-1 is RECOMMENDED. + + * Reassembly Check Sequence (RCS) will follow the default size + defined in Section 8.2.3 of [RFC8724], with a length equal to the + L2 Word. + + * MAX_ACK_REQ is RECOMMENDED to be 2, but applications MAY change + this value based on transmission conditions. + + The IoT devices communicate with small data transfers and use the + Power Save Mode and the Idle Mode Discontinuous Reception (DRX), + which govern how often the device wakes up, stays up, and is + reachable. The use of the different modes allows the battery to last + ten years. Table 10.5.163a in [TS24008] defines the radio timer + values with units incrementing by N. The units of N can be 1 hour or + 10 hours. The range used for IoT is of N to 3N, where N increments + by one. The Inactivity Timer and the Retransmission Timer can be set + based on these limits. + +5.2. Informational Scenarios + + These scenarios show how 3GPP could use SCHC for their transmissions. + +5.2.1. Use of SCHC over the Radio Link + + Deploying SCHC over the Radio Link only would require placing it as + part of the protocol stack for data transfer between the Dev-UE and + the RGW-eNB. This stack is the functional layer responsible for + transporting data over the wireless connection and managing radio + resources. There is support for features such as reliability, + segmentation, and concatenation. The transmissions use link + adaptation, meaning that the system will optimize the transport + format used according to the radio conditions, the number of bits to + transmit, and the power and interference constraints. That means + that the number of bits transmitted over the air depends on the + selected Modulation and Coding Schemes (MCSs). Transport Block (TB) + transmissions happen in the Physical Layer at network-synchronized + intervals called Transmission Time Interval (TTI). Each TB has a + different MCS and number of bits available to transmit. The MAC + layer [TR36321] defines the characteristics of the TBs. The Radio + Link stack shown in Figure 3 comprises the Packet Data Convergence + Protocol (PDCP) [TS36323], the Radio Link Protocol (RLC) [TS36322], + the Medium Access Control protocol (MAC) [TR36321], and the Physical + Layer [TS36201]. Appendix A gives more details about these + protocols. + + +---------+ +---------+ | + |IP/Non-IP+------------------------------+IP/Non-IP+->+ + +---------+ | +---------------+ | +---------+ | + | PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+ + | (SCHC) + + (SCHC)| + + | | + +---------+ | +---------------+ | +---------+ | + | RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+ + +---------+ | +---------------+ | +---------+ | + | MAC +-------+ MAC | L2 +------+ L2 +->+ + +---------+ | +---------------+ | +---------+ | + | PHY +-------+ PHY | PHY +------+ PHY +->+ + +---------+ +---------------+ +---------+ | + C-Uu/ S1-U SGi + Dev-UE RGW-eNB NGW-CSGN + Radio Link + + Figure 3: SCHC over the Radio Link + +5.2.1.1. Placing SCHC Entities over the Radio Link + + The 3GPP architecture supports Robust Header Compression (ROHC) + [RFC5795] in the PDCP layer. Therefore, the architecture can deploy + SCHC header compression entities similarly without the need for + significant changes in the 3GPP specifications. + + The RLC layer has three functional modes: Transparent Mode (TM), + Unacknowledged Mode (UM), and Acknowledged Mode (AM). The mode of + operation controls the functionalities of the RLC layer. TM only + applies to signaling packets, while AM or UM carry signaling and data + packets. + + The RLC layer takes care of fragmentation except for the TM. In AM + or UM, the SCHC fragmentation is unnecessary and SHOULD NOT be used. + While sending IP packets, the Radio Link does not commonly use the + RLC TM. However, if other protocol overhead optimizations are + targeted for NB-IoT traffic, SCHC fragmentation may be used for TM + transmission in the future. + +5.2.2. Use of SCHC over the Non-Access Stratum (NAS) + + This section consists of IETF suggestions to the 3GPP. The NGW-MME + conveys mainly signaling between the Dev-UE and the cellular network + [TR24301]. The network transports this traffic on top of the Radio + Link. + + This kind of flow supports data transmissions to reduce the overhead + when transmitting infrequent small quantities of data. This + transmission is known as Data over Non-Access Stratum (DoNAS) or + Control Plane CIoT EPS optimizations. In DoNAS, the Dev-UE uses the + pre-established security, can piggyback small uplink data into the + initial uplink message, and uses an additional message to receive a + downlink small data response. + + The NGW-MME performs the data encryption from the network side in a + DoNAS PDU. Depending on the data type signaled indication (IP or + Non-IP data), the network allocates an IP address or establishes a + direct forwarding path. DoNAS is regulated under rate control upon + previous agreement, meaning that a maximum number of bits per unit of + time is agreed upon per device subscription beforehand and configured + in the device. + + The system will use DoNAS when a terminal in a power-saving state + requires a short transmission and receives an acknowledgment or short + feedback from the network. Depending on the size of the buffered + data to be transmitted, the Dev-UE might deploy the connected mode + transmission instead. The connected mode would limit and control the + DoNAS transmissions to predefined thresholds, and it would be a good + resource optimization balance for the terminal and the network. The + support for mobility of DoNAS is present but produces additional + overhead. Appendix B gives additional details of DoNAS. + +5.2.2.1. Placing SCHC Entities over DoNAS + + SCHC resides in this scenario's Non-Access Stratum (NAS) protocol + layer. The same principles as for Section 5.2.1 apply here as well. + Because the NAS protocol already uses ROHC [RFC5795], it can also + adapt SCHC for header compression. The main difference compared to + the Radio Link (Section 5.2.1) is the physical placing of the SCHC + entities. On the network side, the NGW-MME resides in the core + network and is the terminating node for NAS instead of the RGW-eNB. + + +--------+ +--------+--------+ + +--------+ + | IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ | + | Non-IP | | | | Non-IP | Non-IP | | | Non-IP | + +--------+ | | +-----------------+ | +--------+ + | NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U | + |(SCHC) | | | | (SCHC) | | | | | + +--------+ | +-----------+ | +-----------------+ | +--------+ + | RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | | + +--------+ | +-----------+ | +--------+ UDP +-----+ UDP | + | PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | | + +--------+ | +-----------+ | +-----------------+ | +--------+ + | RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP | + +--------+ | +-----------+ | +-----------------+ | +--------+ + | MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 | + +--------+ | +-----------+ | +-----------------+ | +--------+ + | PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY | + +--------+ +-----+-----+ +--------+--------+ | +--------+ + C-Uu/ S1 SGi + Dev-UE RGW-eNB NGW-MME NGW-PGW + + *PDCP is bypassed until AS security is activated TGPP36300. + + Figure 4: SCHC Entities Placement in the 3GPP CIOT Radio Protocol + Architecture for DoNAS Transmissions + +5.2.3. Parameters for Static Context Header Compression and + Fragmentation (SCHC) for the Radio Link and DoNAS Use Cases + + If 3GPP incorporates SCHC, it is recommended that these scenarios use + the SCHC header compression [RFC8724] capability to optimize the data + transmission. + + * SCHC Context Initialization + + The Radio Resource Control (RRC) protocol is the main tool used to + configure the parameters of the Radio Link. It will configure + SCHC and the static context distribution as it has been made for + ROHC operation [RFC5795] [TS36323]. + + * SCHC Rules + + The network operator defines the number of rules in these + scenarios. For this, the network operator must know the IP + traffic the device will carry. The operator might supply rules + compatible with the device's use case. For devices acting as a + capillary gateway, several rules match the diversity of devices + and protocols used by the devices associated with the gateway. + Meanwhile, simpler devices may have predetermined protocols and + fixed parameters. The use of IPv6 and IPv4 may force the operator + to develop more rules to deal with each case. + + * RuleID + + There is a reasonable assumption of 9 bytes of radio protocol + overhead for these transmission scenarios in NB-IoT, where PDCP + uses 5 bytes due to header and integrity protection and where RLC + and MAC use 4 bytes. The minimum physical TBs that can withhold + this overhead value, according to the 3GPP Release 15 + specification [R15-3GPP], are 88, 104, 120, and 144 bits. As for + Section 5.1.1.2, these scenarios must optimize the Physical Layer + where the smallest TB is 12 bits. These 12 bits must include the + Compression Residue in addition to the RuleID. On the other hand, + more complex NB-IoT devices (such as a capillary gateway) might + require additional bits to handle the variety and multiple + parameters of higher-layer protocols deployed. In that sense, the + operator may want flexibility on the number and type of rules + independently supported by each device; consequently, these + scenarios require a configurable value. The configuration may be + part of the agreed operation profile with the content + distribution. The RuleID field size may range from 2 bits, + resulting in 4 rules, to an 8-bit value, yielding up to 256 rules + for use with the operators. A 256-rule maximum limit seems to be + quite reasonable, even for a device acting as a NAT. An + application may use a larger RuleID, but it should consider the + byte alignment of the expected Compression Residue. In the + minimum TB size case, 2 bits of RuleID leave only 6 bits available + for Compression Residue. + + * SCHC MAX_PACKET_SIZE + + The Radio Link can handle the fragmentation of SCHC packets if + needed, including reliability. Hence, the packet size is limited + by the MTU that is handled by the radio protocols, which + corresponds to 1600 bytes for the 3GPP Release 15. + + * Fragmentation + + For the Radio Link (Section 5.2.1) and DoNAS (Section 5.2.2) + scenarios, the SCHC fragmentation functions are disabled. The RLC + layer of NB-IoT can segment packets into suitable units that fit + the selected TB for transmissions of the Physical Layer. The + block selection is made according to the link adaptation input + function in the MAC layer and the quantity of data in the buffer. + The link adaptation layer may produce different results at each + TTI, resulting in varying physical TBs that depend on the network + load, interference, number of bits transmitted, and QoS. Even if + setting a value that allows the construction of data units + following the SCHC tiles principle, the protocol overhead may be + greater or equal to allowing the Radio Link protocols to take care + of the fragmentation intrinsically. + + * Fragmentation in RLC TM + + The RLC TM mostly applies to control signaling transmissions. + When RLC operates in TM, the MAC layer mechanisms ensure + reliability and generate overhead. This additional reliability + implies sending repetitions or automatic retransmissions. + + The ACK-Always fragmentation mode of SCHC may reduce this overhead + in future operations when data transmissions may use this mode. + The ACK-Always mode may transmit compressed data with fewer + possible transmissions by using fixed or limited TBs compatible + with the tiling SCHC fragmentation handling. For SCHC + fragmentation parameters, see Section 5.1.1.2. + +6. Padding + + NB-IoT and 3GPP wireless access, in general, assumes a byte-aligned + payload. Therefore, the L2 Word for NB-IoT MUST be considered 8 + bits, and the padding treatment should use this value accordingly. + +7. IANA Considerations + + This document has no IANA actions. + +8. Security Considerations + + This document does not add any security considerations and follows + [RFC8724] and the 3GPP access security document specified in + [TS33122]. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. + Zuniga, "SCHC: Generic Framework for Static Context Header + Compression and Fragmentation", RFC 8724, + DOI 10.17487/RFC8724, April 2020, + <https://www.rfc-editor.org/info/rfc8724>. + + [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static + Context Header Compression (SCHC) for the Constrained + Application Protocol (CoAP)", RFC 8824, + DOI 10.17487/RFC8824, June 2021, + <https://www.rfc-editor.org/info/rfc8824>. + +9.2. Informative References + + [OMA0116] Open Mobile Alliance, "Common definitions for RESTful + Network APIs", Version 1.0, January 2018, + <https://www.openmobilealliance.org/release/ + REST_NetAPI_Common/V1_0-20180116-A/OMA-TS- + REST_NetAPI_Common-V1_0-20180116-A.pdf>. + + [R15-3GPP] 3GPP, "Release 15", April 2019, <https://www.3gpp.org/ + specifications-technologies/releases/release-15>. + + [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust + Header Compression (ROHC) Framework", RFC 5795, + DOI 10.17487/RFC5795, March 2010, + <https://www.rfc-editor.org/info/rfc5795>. + + [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) + Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, + <https://www.rfc-editor.org/info/rfc8376>. + + [TR-0024] OneM2M, "3GPP_Interworking", TR-0024-V4.3.0, March 2020, + <https://ftp.onem2m.org/work%20programme/WI-0037/TR-0024- + 3GPP_Interworking-V4_3_0.DOCX>. + + [TR23720] 3GPP, "Study on architecture enhancements for Cellular + Internet of Things", 3GPP TR 23.720 V13.0.0, March 2016, + <https://www.3gpp.org/ftp/Specs/ + archive/23_series/23.720/23720-d00.zip>. + + [TR24301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved + Packet System (EPS); Stage 3", 3GPP TS 24.301 V15.8.0, + December 2019, <https://www.3gpp.org/ftp//Specs/ + archive/24_series/24.301/24301-f80.zip>. + + [TR36321] 3GPP, "Evolved Universal Terrestrial Radio Access + (E-UTRA); Medium Access Control (MAC) protocol + specification", 3GPP TS 36.321 V13.2.0, June 2016, + <https://www.3gpp.org/ftp/Specs/ + archive/36_series/36.321/36321-d20.zip>. + + [TS23222] 3GPP, "Functional architecture and information flows to + support Common API Framework for 3GPP Northbound APIs; + Stage 2", 3GPP TS 23.222 V15.6.0, September 2022, + <https://www.3gpp.org/ftp/Specs/ + archive/23_series/23.222/23222-f60.zip>. + + [TS24008] 3GPP, "Mobile radio interface Layer 3 specification; Core + network protocols; Stage 3", 3GPP TS 24.008 V15.5.0, + December 2018, <https://www.3gpp.org/ftp//Specs/ + archive/24_series/24.008/24008-f50.zip>. + + [TS33122] 3GPP, "Security aspects of Common API Framework (CAPIF) + for 3GPP northbound APIs", 3GPP TS 33.122 V15.3.0, March + 2019, <https://www.3gpp.org/ftp//Specs/ + archive/33_series/33.122/33122-f30.zip>. + + [TS36201] 3GPP, "Evolved Universal Terrestrial Radio Access + (E-UTRA); LTE physical layer; General description", 3GPP + TS 36.201 V15.1.0, June 2018, + <https://www.3gpp.org/ftp/Specs/ + archive/36_series/36.201/36201-f10.zip>. + + [TS36322] 3GPP, "Evolved Universal Terrestrial Radio Access + (E-UTRA); Radio Link Control (RLC) protocol + specification", 3GPP TS 36.322 V15.0.1, April 2018, + <https://www.3gpp.org/ftp/Specs/ + archive/36_series/36.322/36322-f01.zip>. + + [TS36323] 3GPP, "Evolved Universal Terrestrial Radio Access + (E-UTRA); Packet Data Convergence Protocol (PDCP) + specification", 3GPP TS 36.323 V13.2.0, June 2016, + <https://www.3gpp.org/ftp/Specs/ + archive/36_series/36.323/36323-d20.zip>. + + [TS36331] 3GPP, "Evolved Universal Terrestrial Radio Access + (E-UTRA); Radio Resource Control (RRC); Protocol + specification", 3GPP TS 36.331 V15.5.1, April 2019, + <https://www.3gpp.org/ftp//Specs/ + archive/36_series/36.331/36331-f51.zip>. + +Appendix A. NB-IoT User Plane Protocol Architecture + +A.1. Packet Data Convergence Protocol (PDCP) + + Each of the Radio Bearers (RBs) is associated with one PDCP entity + [TS36323]. Moreover, a PDCP entity is associated with one or two RLC + entities, depending on the unidirectional or bidirectional + characteristics of the RB and RLC mode used. A PDCP entity is + associated with either a control plane or a user plane with + independent configuration and functions. The maximum supported size + for NB-IoT of a PDCP SDU is 1600 octets. The primary services and + functions of the PDCP sublayer for NB-IoT for the user plane include: + + * Header compression and decompression using ROHC [RFC5795] + + * Transfer of user and control data to higher and lower layers + + * Duplicate detection of lower-layer SDUs when re-establishing + connection (when RLC with Acknowledge Mode is in use for User + Plane only) + + * Ciphering and deciphering + + * Timer-based SDU discard in uplink + +A.2. Radio Link Protocol (RLC) + + RLC [TS36322] is an L2 protocol that operates between the User + Equipment (UE) and the base station (eNB). It supports the packet + delivery from higher layers to MAC, creating packets transmitted over + the air, optimizing the TB utilization. RLC flow of data packets is + unidirectional, and it is composed of a transmitter located in the + transmission device and a receiver located in the destination device. + Therefore, to configure bidirectional flows, two sets of entities, + one in each direction (downlink and uplink), must be configured and + effectively peered to each other. The peering allows the + transmission of control packets (e.g., status reports) between + entities. RLC can be configured for a data transfer in one of the + following modes: + + * Transparent Mode (TM) + + RLC does not segment or concatenate SDUs from higher layers in + this mode and does not include any header with the payload. RLC + receives SDUs from upper layers when acting as a transmitter and + transmits directly to its flow RLC receiver via lower layers. + Similarly, upon reception, a TM RLC receiver would not process the + packets and only deliver them to higher layers. + + * Unacknowledged Mode (UM) + + This mode provides support for segmentation and concatenation of + payload. The RLC packet's size depends on the indication given at + a particular transmission opportunity by the lower layer (MAC) and + is octet-aligned. The packet delivery to the receiver does not + include reliability support, and the loss of a segment from a + packet means a complete packet loss. Also, in lower-layer + retransmissions, there is no support for re-segmentation in case + the radio conditions change and trigger the selection of a smaller + TB. Additionally, it provides PDU duplication detection and + discards, out-of-sequence reordering, and loss detection. + + * Acknowledged Mode (AM) + + In addition to the same functions supported by UM, this mode also + adds a moving windows-based reliability service on top of the + lower-layer services. It also supports re-segmentation, and it + requires bidirectional communication to exchange acknowledgment + reports, called RLC Status Reports, and to trigger + retransmissions. This model also supports protocol-error + detection. The mode used depends on the operator configuration + for the type of data to be transmitted. For example, data + transmissions supporting mobility or requiring high reliability + would be most likely configured using AM. Meanwhile, streaming + and real-time data would be mapped to a UM configuration. + +A.3. Medium Access Control (MAC) + + MAC [TR36321] provides a mapping between the higher layers + abstraction called Logical Channels (which are comprised by the + previously described protocols) and the Physical Layer channels + (transport channels). Additionally, MAC may multiplex packets from + different Logical Channels and prioritize which ones to fit into one + TB if there is data and space available to maximize data transmission + efficiency. MAC also provides error correction and reliability + support through Hybrid Automatic Repeat reQuest (HARQ), transport + format selection, and scheduling information reported from the + terminal to the network. MAC also adds the necessary padding and + piggyback control elements, when possible, as well as the higher + layers data. + + <Max. 1600 bytes> + +---+ +---+ +------+ + Application |AP1| |AP1| | AP2 | + (IP/Non-IP) |PDU| |PDU| | PDU | + +---+ +---+ +------+ + | | | | | | + PDCP +--------+ +-------- +-----------+ + |PDCP|AP1| |PDCP|AP1| |PDCP| AP2 | + |Head|PDU| |Head|PDU| |Head| PDU | + +--------+ +--------+ +--------+--\ + | | | | | | | | |\ `--------\ + +---------------------------+ | |(1)| `-------\(2)\ + RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+ + |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2| + +-------------|-------------+ |Head|Head|PDU| |Head|PDU| + | | | | | +---------|---+ +--------+ + | | | LCID1 | | / / / / / + / / / _/ _// _/ _/ / LCID2 / + | | | | | / _/ _/ / ___/ + | | | | || | | / / + +------------------------------------------+ +-----------+---+ + MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad| + |Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din| + |der|der|der | |der|der | |der|der | | |der|der| |g | + +------------------------------------------+ +-----------+---+ + TB1 TB2 + + (1) Segment One + (2) Segment Two + + Figure 5: Example of User Plane Packet Encapsulation for Two + Transport Blocks + +Appendix B. NB-IoT Data over NAS (DoNAS) + + The Access Stratum (AS) protocol stack used by DoNAS is specific + because the radio network still needs to establish the security + associations and reduce the protocol overhead so that the PDCP is + bypassed until the AS security is activated. By default, RLC uses + the AM. However, depending on the network's features and the + terminal, RLC may change to other modes by the network operator. For + example, the TM does not add any header nor process the payload to + reduce the overhead, but the MTU would be limited by the TB used to + transmit the data, which is a couple of thousand bits maximum. If UM + (only terminals compatible with 3GPP Release 15 [R15-3GPP]) is used, + the RLC mechanisms of reliability are disabled, and only the + reliability provided by the MAC layer by HARQ is available. In this + case, the protocol overhead might be smaller than the AM case because + of the lack of status reporting, but the overhead would have the same + support for segmentation up to 1600 bytes. NAS packets are + encapsulated within an RRC [TS36331] message. + + Depending on the data type indication signaled (IP or Non-IP data), + the network allocates an IP address or establishes a direct + forwarding path. DoNAS is regulated under rate control upon previous + agreement, meaning that a maximum number of bits per unit of time is + agreed upon per device subscription beforehand and configured in the + device. The use of DoNAS is typically expected when a terminal in a + power-saving state requires a short transmission and is receiving an + acknowledgment or short feedback from the network. Depending on the + size of buffered data to be transmitted, the UE might be instructed + to deploy the connected mode transmissions instead, limiting and + controlling the DoNAS transmissions to predefined thresholds and a + good resource optimization balance for the terminal and the network. + The support for mobility of DoNAS is present but produces additional + overhead. + + +--------+ +--------+ +--------+ + | | | | | | +-----------------+ + | UE | | C-BS | | C-SGN | |Roaming Scenarios| + +----|---+ +--------+ +--------+ | +--------+ | + | | | | | | | + +----------------|------------|+ | | P-GW | | + | Attach | | +--------+ | + +------------------------------+ | | | + | | | | | | + +------|------------|--------+ | | | | + |RRC connection establishment| | | | | + |with NAS PDU transmission | | | | | + |& Ack Rsp | | | | | + +----------------------------+ | | | | + | | | | | | + | |Initial UE | | | | + | |message | | | | + | |----------->| | | | + | | | | | | + | | +---------------------+| | | + | | |Checks Integrity || | | + | | |protection, decrypts || | | + | | |data || | | + | | +---------------------+| | | + | | | Small data packet | + | | |-------------------------------> + | | | Small data packet | + | | |<------------------------------- + | | +----------|---------+ | | | + | | Integrity protection,| | | | + | | encrypts data | | | | + | | +--------------------+ | | | + | | | | | | + | |Downlink NAS| | | | + | |message | | | | + | |<-----------| | | | + +-----------------------+ | | | | + |Small data delivery, | | | | | + |RRC connection release | | | | | + +-----------------------+ | | | | + | | + | | + +-----------------+ + + Figure 6: DoNAS Transmission Sequence from an Uplink Initiated Access + + +---+ +---+ +---+ +----+ + Application |AP1| |AP1| |AP2| |AP2 | + (IP/Non-IP) |PDU| |PDU| |PDU| ............... |PDU | + +---+ +---+ +---+ +----+ + | | | | | | | | + | | | | | | | | + | | | | | | | | + | | | | | | | | + | |/ / | \ | | + NAS /RRC +--------+---|---+----+ +---------+ + |NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 | + |RRC |PDU|PDU|PDU|RRC | |RRC |PDU | + +--------+-|-+---+----+ +---------| + | | | | | + | |\ | | | + |<--Max. 1600 bytes-->|__ |_ | + | | \__ \___ \_ \ + | | \ \ \__ \ + | | \ | | \_ + +---------------|+-----|----------+ \ \ + RLC |RLC | NAS/RRC ||RLC | NAS/RRC | +----|-------+ + |Head| PDU(1/2)||Head | PDU (2/2)| |RLC |NAS/RRC| + +---------------++----------------+ |Head|PDU | + | | | \ | +------------+ + | | LCID1 | \ | | / + | | | \ \ | | + | | | \ \ | | + | | | \ \ \ | + +----+----+----------++-----|----+---------++----+---------|---+ + MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| + |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | + +----+----+----------++-----+----+---------++----+---------+---+ + TB1 TB2 TB3 + + Figure 7: Example of User Plane Packet Encapsulation for Data + over NAS + +Acknowledgements + + The authors would like to thank (in alphabetic order): Carles Gomez, + Antti Ratilainen, Pascal Thubert, Tuomas Tirronen, and Éric Vyncke. + +Authors' Addresses + + Edgar Ramos + Ericsson + Hirsalantie 11 + FI-02420 Jorvas, Kirkkonummi + Finland + Email: edgar.ramos@ericsson.com + + + Ana Minaburo + Acklio + 1137A Avenue des Champs Blancs + 35510 Cesson-Sevigne Cedex + France + Email: ana@ackl.io |