idnits 2.17.1 draft-ietf-lpwan-schc-over-nbiot-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 20) being 84 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 359: '... These scenarios MUST use SCHC header ...' RFC 2119 keyword, line 362: '... IoT application MUST be considered to...' RFC 2119 keyword, line 497: '... application MUST be considered to i...' RFC 2119 keyword, line 599: '... word for NB-IoT MUST be considered 8 ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 May 2022) is 708 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TGPP36322' is mentioned on line 251, but not defined == Missing Reference: 'TGPP36201' is mentioned on line 252, but not defined ** Downref: Normative reference to an Informational RFC: RFC 8376 -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPP23720' -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPP33203' -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPP36321' -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPP36323' -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPP24301' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group E. Ramos 3 Internet-Draft Ericsson 4 Intended status: Standards Track A. Minaburo 5 Expires: 20 November 2022 Acklio 6 19 May 2022 8 SCHC over NBIoT 9 draft-ietf-lpwan-schc-over-nbiot-08 11 Abstract 13 The Static Context Header Compression and Fragmentation (SCHC) 14 specification describes header compression and fragmentation 15 functionalities for LPWAN (Low Power Wide Area Networks) 16 technologies. The Narrowband Internet of Things (NB-IoT) 17 architecture may adapt SCHC to improve its capacities. 19 This document describes the use of SCHC over the NB-IoT wireless 20 access and provides use-cases for efficient parameterization. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 20, 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Data Transmission in the 3GPP Architecture . . . . . . . . . 5 59 4.1. Use of SCHC over the Radio link . . . . . . . . . . . . . 6 60 4.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 6 61 4.2. Use of SCHC over the No-Access Stratum (NAS) . . . . . . 7 62 4.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8 63 4.2.2. Parameters for Static Context Header Compression and 64 Fragmentation (SCHC) for the Section 4.1 and 65 Section 4.2. . . . . . . . . . . . . . . . . . . . . 9 66 4.3. End-to-End Compression . . . . . . . . . . . . . . . . . 11 67 4.3.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 11 68 4.3.2. Parameters for Static Context Header Compression and 69 Fragmentation (SCHC) . . . . . . . . . . . . . . . . 12 70 5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 6. Security considerations . . . . . . . . . . . . . . . . . . . 14 72 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.1. NB-IoT User Plane protocol architecture . . . . . . . . . 14 74 7.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . . 14 75 7.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . . 15 76 7.1.3. Medium Access Control (MAC) . . . . . . . . . . . . . 16 77 7.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 17 78 8. Normative References . . . . . . . . . . . . . . . . . . . . 19 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 81 1. Introduction 83 The Static Context Header Compression (SCHC) [RFC8724] defines a 84 header compression scheme, and fragmentation functionality, suitable 85 for the Low Power Wide Area Networks (LPWAN) networks described in 86 [RFC8376]. 88 In a Narrowband Internet of Things (NB-IoT) network, header 89 compression efficiently brings Internet connectivity to the Device - 90 User Equipment (Dev-UE). This document describes the SCHC parameters 91 used to support the static context header compression and 92 fragmentation over the NB-IoT wireless access. This document assumes 93 functionality for NB-IoT of 3GPP release 15 (3GPPR15). Otherwise, 94 the text explicitly mentions other versions' functionality. 96 2. Terminology 98 This document will follow the terms defined in [RFC8724], in 99 [RFC8376], and the [TGPP23720]. 101 * CIoT. Cellular IoT. 103 * NGW-C-SGN. Network Gateway - CIoT Serving Gateway Node. 105 * Dev-UE. Device - User Equipment. 107 * RGW-eNB. Radio Gateway - Node B. Base Station that controls the 108 UE. 110 * EPC. Evolved Packet Connectivity. Core network of 3GPP LTE 111 systems. 113 * EUTRAN. Evolved Universal Terrestrial Radio Access Network. 114 Radio access network of LTE-based systems. 116 * NGW-MME. Network Gateway - Mobility Management Entity. An entity 117 in charge of handling mobility of the Dev-UE. 119 * NB-IoT. Narrowband IoT. A 3GPP LPWAN technology based on the LTE 120 architecture but with additional optimization for IoT and using a 121 Narrowband spectrum frequency. 123 * NGW-SGW. Network Gateway - Serving Gateway. It routes and 124 forwards the user data packets through the access network. 126 * HSS. Home Subscriber Server. It is a database that performs 127 mobility management. 129 * NGW-PGW. Network Gateway - Packet Data Node Gateway. An 130 interface between the internal with the external network. 132 * PDU. Protocol Data Unit. A data packet including headers that 133 are transmitted between entities through a protocol. 135 * SDU. Service Data Unit. A data packet (PDU) from higher layer 136 protocols used by lower layer protocols as a payload of their own 137 PDUs. 139 * IWK-SCEF. InterWorking Service Capabilities Exposure Function. 140 It is used in roaming scenarios, it is located in the Visited PLMN 141 and serves for interconnection with the SCEF of the Home PLMN. 143 * NGW-SCEF. Network Gateway - Service Capability Exposure Function. 144 EPC node for exposure of 3GPP network service capabilities to 3rd 145 party applications. 147 3. Architecture 149 The Narrowband Internet of Things (NB-IoT) architecture has a complex 150 structure. It relies on different NGWs from different providers and 151 can send data via different paths, each path with different 152 characteristics in terms of bandwidths, acknowledgments, and layer 153 two reliability and segmentation. 155 Figure 1 shows this architecture, where the Network Gateway Cellular 156 Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co- 157 locating entities in different paths. For example, a Dev-UE using 158 the path formed by the Network Gateway Mobility Management Entity 159 (NGW-MME), the NGW-CSGW, and Network Gateway Packet Data Node Gateway 160 (NGW-PGW) may get a limited bandwidth transmission from few bytes/s 161 to one thousand bytes/s only. 163 Another node introduced in the NB-IoT architecture is the Network 164 Gateway Service Capability Exposure Function (NGW-SCEF), which 165 securely exposes service and network capabilities to entities 166 external to the network operator. OMA and OneM2M define the 167 northbound APIS [TGPP33203]. In this case, the path is small for 168 data transmission. The main functions of the NGW-SCEF are: 169 Connectivity path and Device Monitoring. 171 +---+ +------+ 172 |Dev| \ +-----+ ----| HSS | 173 |-UE| \ | NGW | +------+ 174 +---+ | |-MME |\__ 175 \ / +-----+ \ 176 +---+ \+-----+ / | +------+ 177 |Dev| ----| RGW |- | | NGW- | 178 |-UE| |-eNB | | | SCEF |---------+ 179 +---+ /+-----+ \ | +------+ | 180 / \ +------+ | 181 / \| NGW- | +-----+ +-----------+ 182 +---+ / | CSGW |--| NGW-|---|Application| 183 |Dev| | | | PGW | | Server | 184 |-UE| +------+ +-----+ +-----------+ 185 +---+ 187 Figure 1: 3GPP network architecture 189 4. Data Transmission in the 3GPP Architecture 191 NB-IoT networks deal with end-to-end user data and in-band signalling 192 between the nodes and functions to configure, control, and monitor 193 the system functions and behaviors. The signalling data uses a 194 different path with specific protocols, handling processes, and 195 entities but can transport end-to-end user data for IoT services. In 196 contrast, the end-to-end application only transports end-to-end data. 198 The maximum recommended 3GPP MTU size is 1358 Bytes. The radio 199 network protocols limit the packet sizes over the air, including 200 radio protocol overhead, to 1600 Bytes. However, the recommended MTU 201 is smaller to avoid fragmentation in the network backbone due to the 202 payload encryption size (multiple of 16) and the additional core 203 transport overhead handling. 205 3GPP standardizes NB-IoT and, in general, the cellular technologies 206 interfaces and functions. Therefore the introduction of SCHC 207 entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified in 208 the NB-IoT standard, which implies that standard specifying SCHC 209 support would not be backward compatible. A terminal or a network 210 supporting a version of the standard without SCHC or without an 211 implementation capability (in case of not being standardized as 212 mandatory capability) cannot utilize SCHC with this approach. 214 SCHC could be deployed differently depending on where the header 215 compression and the fragmentation are applied. The SCHC 216 functionalities can be used over the radio transmission only, between 217 the Dev-UE and the RGW-eNB. Alternatively, the packets transmitted 218 over the path can use SCHC. Else, when the transmissions go over the 219 NGW-MME or NGW-SCEF, the NGW-CSGN uses SCHC entity. For these two 220 cases, the functions need to be standardized by 3GPP. 222 Another possibility is to apply SCHC functionalities to the end-to- 223 end connection or at least up to the operator network edge. SCHC 224 functionalities are available in the application layer of the Dev-UE 225 and the Application Servers or a broker function at the edge of the 226 operator network. The radio network transmits the packets as non-IP 227 traffic using IP tunnelling or SCEF services. Since this option does 228 not necessarily require 3GPP standardization, it is possible to also 229 benefit legacy devices with SCHC by using the non-IP transmission 230 features of the operator network. 232 4.1. Use of SCHC over the Radio link 234 Deploying SCHC only over the radio link would require placing it as 235 part of the protocol stack for data transfer between the Dev-UE and 236 the RGW-eNB. This stack is the functional layer responsible for 237 transporting data over the wireless connection and managing radio 238 resources. There is support for features such as reliability, 239 segmentation, and concatenation. The transmissions use link 240 adaptation, meaning that the system will optimize the transport 241 format used according to the radio conditions, the number of bits to 242 transmit, and the power and interference constraints. That means 243 that the number of bits transmitted over the air depends on the 244 Modulation and Coding Schemes (MCS) selected. The transmissions of 245 Transport Block (TB) happen in the physical layer at network 246 synchronized intervals called Transmission Time Interval (TTI). Each 247 Transport Block has a different MCS and number of bits available to 248 transmit. The MAC layer [TGPP36321] defines the Transport Blocks 249 characteristics. The Radio link stack shown in Figure 2 comprises 250 the Packet Data Convergence Protocol (PDCP) [TGPP36323], Radio Link 251 Protocol (RLC) [TGPP36322], Medium Access Control protocol (MAC) 252 [TGPP36321], and the Physical Layer [TGPP36201]. The 253 Appendix gives more details of these protocols. 255 4.1.1. SCHC Entities Placing 257 The current architecture provides support for header compression in 258 the PDCP layer using RoHC [RFC5795]. Therefore SCHC header 259 compression entities can be deployed similarly without the need for 260 significant changes in the 3GPP specifications. 262 In this scenario, the RLC layer takes care of fragmentation unless 263 for the Transparent Mode. When packets exceed the Transport Block 264 size at transmission, SCHC fragmentation is unnecessary and should 265 not be used to avoid the additional protocol overhead. The RLC 266 Transparent Mode is not commonly used while sending IP packets in the 267 Radio link. However, given the case in the future, SCHC 268 fragmentation may be used. In that case, a SCHC tile would match the 269 minimum transport block size minus the PDCP and MAC headers. 271 +---------+ +---------+ | 272 |IP/non-IP+------------------------------+IP/non-IP+->+ 273 +---------+ | +---------------+ | +---------+ | 274 | PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+ 275 | (SCHC) + + (SCHC)| + + | | 276 +---------+ | +---------------+ | +---------+ | 277 | RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+ 278 +---------+ | +---------------+ | +---------+ | 279 | MAC +-------+ MAC | L2 +------+ L2 +->+ 280 +---------+ | +---------------+ | +---------+ | 281 | PHY +-------+ PHY | PHY +------+ PHY +->+ 282 +---------+ +---------------+ +---------+ | 283 C-Uu/ S1-U SGi 284 Dev-UE RGW-eNB NGW-CSGN 285 Radio Link 287 Figure 2: SCHC over the Radio link 289 4.2. Use of SCHC over the No-Access Stratum (NAS) 291 The NGW-MME conveys mainly control signaling between the Dev-UE and 292 the cellular network [TGPP24301]. The network transports this 293 traffic on top of the radio link. 295 This kind of flow supports data transmissions to reduce the overhead 296 when transmitting infrequent small quantities of data. This 297 transmission is known as Data over No-Access Stratum (DoNAS) or 298 Control Plane CIoT EPS optimization. In DoNAS, the Dev-UE uses the 299 pre-established security and can piggyback small uplink data into the 300 initial uplink message and uses an additional message to receive a 301 downlink small data response. 303 The NGW-MME performs the data encryption from the network side in a 304 DoNAS PDU. Depending on the data type signaled indication (IP or 305 non-IP data), the network allocates an IP address or establishes a 306 direct forwarding path. DoNAS is regulated under rate control upon 307 previous agreement, meaning that a maximum number of bits per unit of 308 time is agreed upon per device subscription beforehand and configured 309 in the device. 311 The system will use DoNAS when a terminal in a power-saving state 312 requires a short transmission and receives an acknowledgment or short 313 feedback from the network. Depending on the size of buffered data to 314 transmit, the Dev-UE might deploy the connected mode transmissions 315 instead, limiting and controlling the DoNAS transmissions to 316 predefined thresholds and a good resource optimization balance for 317 the terminal and the network. The support for mobility of DoNAS is 318 present but produces additional overhead. The Appendix gives 319 additional details of DoNAS. 321 4.2.1. SCHC Entities Placing 323 In this scenario, SCHC may reside in the Non-Access Stratum (NAS) 324 protocol layer. The same principles as for Radio link transmissions 325 apply here as well. Because the NAS protocol already uses RoHC it 326 can adapt SCHC for header compression too. The main difference 327 compared to the radio link is the physical placing of the SCHC 328 entities. On the network side, the NGW-MME resides in the core 329 network and is the terminating node for NAS instead of the RGW-eNB. 331 +--------+ +--------+--------+ + +--------+ 332 | IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ | 333 | Non-IP | | | | Non-IP | Non-IP | | | Non-IP | 334 +--------+ | | +-----------------+ | +--------+ 335 | NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U | 336 |(SCHC) | | | | (SCHC) | | | | | 337 +--------+ | +-----------+ | +-----------------+ | +--------+ 338 | RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | | 339 +--------+ | +-----------+ | +--------+ UDP +-----+ UDP | 340 | PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | | 341 +--------+ | +-----------+ | +-----------------+ | +--------+ 342 | RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP | 343 +--------+ | +-----------+ | +-----------------+ | +--------+ 344 | MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 | 345 +--------+ | +-----------+ | +-----------------+ | +--------+ 346 | PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY | 347 +--------+ +-----+-----+ +--------+--------+ | +--------+ 348 C-Uu/ S1-lite SGi 349 Dev-UE RGW-eNB NGW-MME NGW-PGW 351 *PDCP is bypassed until AS security is activated TGPP36300. 353 Figure 3: SCHC entities placement in the 3GPP CIOT radio protocol 354 architecture for DoNAS transmissions 356 4.2.2. Parameters for Static Context Header Compression and 357 Fragmentation (SCHC) for the Section 4.1 and Section 4.2. 359 These scenarios MUST use SCHC header compresion capability to improve 360 the transmission of IPv6 packets. The 3GPP Architecture currently 361 provides Header Compression using the [RFC5795] but the use of SCHC 362 for IoT application MUST be considered to improve the devices 363 connectivity. 365 * SCHC Context initialization RRC (Radio Resource Control) protocol 366 is the main tool used to configure the parameters of the Radio 367 link. It will configure SCHC and the static context distribution 368 as it has made for RoHC operation [TGPP36323]. 370 * SCHC Rules The network operator in these scenarios defines the 371 number of rules in a context. The operator must be aware of the 372 type of IP traffic that the device will carry out. Implying that 373 the operator might use provision sets of rules compatible with the 374 use case of the device. For devices acting as gateways of other 375 devices, several rules may match the diversity of devices and 376 protocols used by the devices associated with the gateway. 377 Meanwhile, simpler devices (for example, an electricity meter) may 378 have a predetermined set of fixed protocols and parameters. 379 Additionally, the deployment of IPv6 addresses may force different 380 rules to deal with each case. 382 * RuleID There is a reasonable assumption of 9 bytes of radio 383 protocol overhead for these transmission scenarios in NB-IoT, 384 where PDCP uses 5 bytes due to header and integrity protection, 385 and RLC and MAC use 4 bytes. The minimum physical Transport 386 Blocks (TB) that can withhold this overhead value according to 387 3GPP Release 15 specifications are 88, 104, 120, and 144 bits. A 388 transmission optimization may require only one physical layer 389 transmission. SCHC overhead should not exceed the available 390 number of effective bits of the smallest physical TB available. 391 The packets handled by 3GPP networks are byte-aligned, and 392 therefore the minimum payload possible (including padding) is 8 393 bits. Therefore in order to use the smallest TB, the maximum SCHC 394 header size is 12 bits. These 12 bits must include the 395 Compression Residue in addition to the RuleID. On the other hand, 396 more complex NB-IoT devices (such as a capillarity gateway) might 397 require additional bits to handle the variety and multiple 398 parameters of higher-layer protocols deployed. In that sense, the 399 operator may want to have flexibility on the number and type of 400 rules supported by each device independently, and consequently, 401 these scenarios require a configurable value. The configuration 402 may be part of the operation profile agreed together with the 403 content distribution. The RuleID field size may range from 2 404 bits, resulting in 4 rules to an 8-bit value that would yield up 405 to 256 rules that can be used together with the operators and 406 seems quite a reasonable maximum limit even for a device acting as 407 a NAT. More bits could be configured, but it should consider the 408 byte-alignment of the expected Compression Residue. In the 409 minimum TB size case, 2 bits of RuleID leave only 6 bits available 410 for Compression Residue. 412 * SCHC MAX_PACKET_SIZE The Radio Link can handle the fragmentation 413 of SCHC packets if needed, including reliability. Hence the 414 packet size is limited by the MTU handled by the radio protocols 415 which corresponds to 1600 bytes for 3GPP Release 15. 417 * Fragmentation For the Section 4.1 and Section 4.2 scenarios, the 418 SCHC fragmentation functions are disabled. The RLC layer of NB- 419 IoT can segment packets in suitable units that fit the selected 420 transport blocks for transmissions of the physical layer. The 421 blocks selection is made according to the link adaptation input 422 function in the MAC layer and the quantity of data in the buffer. 423 The link adaptation layer may produce different results at each 424 Time Transmission Interval (TTI), resulting in varying physical 425 transport blocks that depend on the network load, interference, 426 number of bits transmitted, and QoS. Even if setting a value that 427 allows the construction of data units following the SCHC tiles 428 principle, the protocol overhead may be greater or equal than 429 allowing the Radio link protocols to take care of the 430 fragmentation natively. 432 * Fragmentation in RLC Transparent Mode If RLC operates in 433 Transparent Mode, there could be a case to activate a 434 fragmentation function together with a light reliability function 435 such as the ACK-Always mode. In practice, it is uncommon to 436 transmit radio link data using this configuration. It mainly 437 targets signaling transmissions. In those cases, the MAC layer 438 mechanisms ensure reliability, such as repetitions or automatic 439 retransmissions, and additional reliability might only generate 440 protocol overhead. 442 SCHC may reduce radio network protocols overhead in future 443 operations, support reliable transmissions, and transmit compressed 444 data with fewer possible transmissions by using fixed or limited 445 transport blocks compatible with the tiling SCHC fragmentation 446 handling. For SCHC fragmentation parameters see section 447 Section 4.3.2. 449 4.3. End-to-End Compression 451 The Non-IP Data Delivery (NIDD) services of 3GPP enable the 452 transmission of SCHC packets compressed by the application layer. 453 The packets can be delivered using IP-tunnels to the 3GPP network or 454 NGW-SCEF functions (i.e., API calls). In both cases, as compression 455 occurs before transmission, the network will not understand the 456 packet, and the network does not have context information of this 457 compression. Therefore the network will treat the packet as Non-IP 458 traffic and deliver it to the other side without any other protocol 459 stack element, directly under the L2. 461 4.3.1. SCHC Entities Placing 463 In the two scenarios using End-to-End compression, SCHC entities are 464 located almost on top of the stack. The NB-IoT connectivity services 465 implement SCHC in the Dev, an in the Application Server. The IP 466 tunneling scenario requires that the Application Server send the 467 compressed packet over an IP connection terminated by the 3GPP core 468 network. If the transmission uses the NGW-SCEF services, it is 469 possible to utilize an API call to transfer the SCHC packets between 470 the core network and the Application Server. Also, an IP tunnel 471 could be established by the Application Server if negotiated with the 472 NGW-SCEF. 474 +---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+ 475 | SCHC | XXX XXX | SCHC | 476 |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)| 477 +---------+ XX +----+ XX | | +--------+ 478 | | XX |SCEF+-------+ | | | 479 | | XXX 3GPP RAN & +----+ XXX +---+ UDP | 480 | | XXX CORE NETWORK XXX | | | 481 | L2 +---+XX +------------+ | +--------+ 482 | | XX |IP TUNNELING+--+ | | 483 | | XXX +------------+ +---+ IP | 484 +---------+ XXXX XXXX | +--------+ 485 | PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY | 486 +---------+ +--------+ 487 UE AS 489 Figure 4: SCHC entities placed when using Non-IP Delivery (NIDD) 490 3GPP Sevices 492 4.3.2. Parameters for Static Context Header Compression and 493 Fragmentation (SCHC) 495 These scenarios may use SCHC header compresion capability to improve 496 the transmission of IPv6 packets. The use of SCHC for IoT 497 application MUST be considered to improve the devices connectivity. 499 * SCHC Context initialization. The application layer handles the 500 static context; consequently, the context distribution must be 501 according to the application's capabilities, perhaps utilizing IP 502 data transmissions up to context initialization. Also, the static 503 contexts delivery may use the same IP tunneling or NGW-SCEF 504 services used later for the SCHC packets transport. 506 * SCHC Rules. Even when the transmission content is not visible for 507 the 3GPP network, the same limitations as for Section 4.1 and 508 Section 4.2 transmissions apply in these scenarios in terms of 509 aiming to use the minimum number of transmissions and minimize the 510 protocol overhead. 512 * Rule ID Similar to the case of Section 4.1 and Section 4.2, the 513 RuleID size can be dynamically set before the context delivery. 514 For example, negotiated between the applications when choosing a 515 profile according to the type of traffic and application deployed. 516 The same considerations related to the transport block size and 517 performance mentioned for the Section 4.1 and Section 4.2 must be 518 followed when choosing a size value for the RuleID field. 520 * SCHC MAX_PACKET_SIZE In these scenarios, the maximum recommended 521 MTU size that applies is 1358 Bytes since the SCHC packets (and 522 fragments) are traversing the whole 3GPP network infrastructure 523 (core and radio), not only the radio as the IP transmissions case. 525 * Fragmentation Packets larger than 1358 bytes need the SCHC 526 fragmentation function. Since the 3GPP uses reliability 527 functions, the No-ACK fragmentation mode may be enough in point- 528 to-point connections. Nevertheless, additional considerations are 529 described below for more complex cases. 531 * Fragmentation modes A global service assigns a QoS to the packets 532 depending on the billing. Packets with very low QoS may get lost 533 before they arrive in the 3GPP radio network transmission, for 534 example, in between the links of a capillarity gateway or due to 535 buffer overflow handling in a backhaul connection. The use of 536 SCHC fragmentation with the ACK-on-Error mode is recommended to 537 secure additional reliability on the packets transmitted with a 538 small trade-off on additional transmissions to signal the end-to- 539 end arrival of the packets if no transport protocol takes care of 540 retransmission. 541 Also, the ACK-on-Error mode is even desirable to keep track of all 542 the SCHC packets delivered. In that case, the fragmentation 543 function could be active for all packets transmitted by the 544 applications. SCHC ACK-on-Error fragmentation may be active in 545 transmitting non-IP packets on the NGW-MME. A non-IP packet will 546 use SCHC reserved RuleID for non-compressing packets as [RFC8724] 547 allows it. 549 * Fragmentation Parameters SCHC profile will have specific Rules for 550 the fragmentation modes. The rule will identify, which 551 fragmentation mode is in use, and section Section 4.2.2 defines 552 the RuleID size. 554 SCHC parametrization considers that NBIoT aligns the bit and uses 555 padding and the size of the Transfer Block. SCHC will try to reduce 556 padding to optimize the compression of the information. The Header 557 size needs to be multiple of 4, and the Tiles may keep a fixed value 558 of 4 or 8 bits to avoid padding except for transfer block equals 16 559 bits where Tiles may be of 2 bits. The transfer block size has a 560 wide range of values. Two configurations may be used for the 561 fragmentation parameters. 563 * For Transfer Blocks smaller or equal to 300bits using a 8 bits- 564 Header_size configuration, with the size of the header fields as 565 follows: 567 - RuleID from 1 - 3 bits, 569 - DTag 1 bit, 571 - FCN 3 bits, 573 - W 1 bits. 575 * For Transfer Blocks bigger than 300 bits using a 16 bits- 576 Header_size configuration, with the size of the header fields as 577 follows: 579 - RulesID from 1 to 8 or 10 bits, 581 - DTag 1 or 2 bits, 583 - FCN 3 bits, 585 - W 2 or 3 bits. 587 The IoT devices communicate with small data transfer and have a 588 battery life of 10 years. These devices use the Power Save Mode and 589 the Idle Mode DRX, which govern how often the device wakes up, stays 590 up, and is reachable. Table 10.5.163a in {3GPP-TS_24.088} specifies 591 a range for the radio timers as N to 3N in increments of one where 592 the units of N can be 1 hour or 10 hours. To adapt SCHC to the NB- 593 IoT activities, the Inactivity Timer and the Retransmission Timer be 594 set based on these limits. 596 5. Padding 598 NB-IoT and 3GPP wireless access, in general, assumes byte-aligned 599 payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits, 600 and the padding treatment should use this value accordingly. 602 6. Security considerations 604 This document does not add any security considerations and follows 605 the [RFC8724] and the 3GPP access security document specified in 606 [TGPP33203]. 608 7. Appendix 610 7.1. NB-IoT User Plane protocol architecture 612 7.1.1. Packet Data Convergence Protocol (PDCP) 614 Each of the Radio Bearers (RB) is associated with one PDCP entity. 615 Moreover, a PDCP entity is associated with one or two RLC entities 616 depending on the unidirectional or bi-directional characteristics of 617 the RB and RLC mode used. A PDCP entity is associated with either a 618 control plane or a user plane with independent configuration and 619 functions. The maximum supported size for NB-IoT of a PDCP SDU is 620 1600 octets. The primary services and functions of the PDCP sublayer 621 for NB-IoT for the user plane include: 623 * Header compression and decompression using ROHC (Robust Header 624 Compression) 626 * Transfer of user and control data to higher and lower layers 628 * Duplicate detection of lower layer SDUs when re-establishing 629 connection (when RLC with Acknowledge Mode in use for User Plane 630 only) 632 * Ciphering and deciphering 634 * Timer-based SDU discard in uplink 636 7.1.2. Radio Link Protocol (RLC) 638 RLC is a layer-2 protocol that operates between the UE and the base 639 station (eNB). It supports the packet delivery from higher layers to 640 MAC, creating packets transmitted over the air, optimizing the 641 Transport Block utilization. RLC flow of data packets is 642 unidirectional, and it is composed of a transmitter located in the 643 transmission device and a receiver located in the destination device. 644 Therefore to configure bi-directional flows, two sets of entities, 645 one in each direction (downlink and uplink), must be configured and 646 effectively peered to each other. The peering allows the 647 transmission of control packets (ex., status reports) between 648 entities. RLC can be configured for data transfer in one of the 649 following modes: 651 * Transparent Mode (TM). RLC does not segment or concatenate SDUs 652 from higher layers in this mode and does not include any header to 653 the payload. RLC receives SDUs from upper layers when acting as a 654 transmitter and transmits directly to its flow RLC receiver via 655 lower layers. Similarly, a TM RLC receiver would only deliver 656 without processing the packets to higher layers upon reception. 658 * Unacknowledged Mode (UM). This mode provides support for 659 segmentation and concatenation of payload. The RLC packet's size 660 depends on the indication given at a particular transmission 661 opportunity by the lower layer (MAC) and is octets aligned. The 662 packet delivery to the receiver does not include reliability 663 support, and the loss of a segment from a packet means a complete 664 packet loss. Also, in the case of lower layer retransmissions, 665 there is no support for re-segmentation in case of change of the 666 radio conditions triggering the selection of a smaller transport 667 block. Additionally, it provides PDU duplication detection and 668 discards, reordering of out-of-sequence, and loss detection. 670 * Acknowledged Mode (AM). In addition to the same functions 671 supported by UM, this mode also adds a moving windows-based 672 reliability service on top of the lower layer services. It also 673 supports re-segmentation, and it requires bidirectional 674 communication to exchange acknowledgment reports called RLC Status 675 Report and trigger retransmissions. This model also supports 676 protocol error detection. The mode used depends on the operator 677 configuration for the type of data to be transmitted. For 678 example, data transmissions supporting mobility or requiring high 679 reliability would be most likely configured using AM. Meanwhile, 680 streaming and real-time data would be mapped to a UM 681 configuration. 683 7.1.3. Medium Access Control (MAC) 685 MAC provides a mapping between the higher layers abstraction called 686 Logical Channels comprised by the previously described protocols to 687 the Physical layer channels (transport channels). Additionally, MAC 688 may multiplex packets from different Logical Channels and prioritize 689 what to fit into one Transport Block if there is data and space 690 available to maximize data transmission efficiency. MAC also 691 provides error correction and reliability support through HARQ, 692 transport format selection, and scheduling information reporting from 693 the terminal to the network. MAC also adds the necessary padding and 694 piggyback control elements when possible and the higher layers data. 696 697 +---+ +---+ +------+ 698 Application |AP1| |AP1| | AP2 | 699 (IP/non-IP) |PDU| |PDU| | PDU | 700 +---+ +---+ +------+ 701 | | | | | | 702 PDCP +--------+ +--------+ +-----------+ 703 |PDCP|AP1| |PDCP|AP1| |PDCP| AP2 | 704 |Head|PDU| |Head|PDU| |Head| PDU | 705 +--------+ +--------+ +--------+--\ 706 | | | | | | | | |\ `----\ 707 +---------------------------+ | |(1)| `-----\(2)'-\ 708 RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+ 709 |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2| 710 +-------------|-------------+ |Head|Head|PDU| |Head|PDU| 711 | | | | | +---------|---+ +--------+ 712 | | | LCID1 | | / / / / / 713 / / / _/ _// _/ _/ / LCID2 / 714 | | | | | / _/ _/ / ___/ 715 | | | | || | | / / 716 +------------------------------------------+ +-----------+---+ 717 MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad| 718 |Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din| 719 |der|der|der | |der|der | |der|der | | |der|der| |g | 720 +------------------------------------------+ +-----------+---+ 721 TB1 TB2 723 Figure 5: Example of User Plane packet encapsulation for two 724 transport blocks 726 7.2. NB-IoT Data over NAS (DoNAS) 728 The Access Stratum (AS) protocol stack used by DoNAS is somehow 729 particular. Since the security associations are not established yet 730 in the radio network, to reduce the protocol overhead, PDCP (Packet 731 Data Convergence Protocol) is bypassed until AS security is 732 activated. RLC (Radio Link Control protocol) uses by default the AM 733 mode, but depending on the network's features and the terminal, it 734 may change to other modes by the network operator. For example, the 735 transparent mode does not add any header or process the payload to 736 reduce the overhead, but the MTU would be limited by the transport 737 block used to transmit the data, which is a couple of thousand bits 738 maximum. If UM (only Release 15 compatible terminals) is used, the 739 RLC mechanisms of reliability are disabled, and only the reliability 740 provided by the MAC layer by Hybrid Automatic Repeat reQuest (HARQ) 741 is available. In this case, the protocol overhead might be smaller 742 than the AM case because of the lack of status reporting but with the 743 same support for segmentation up to 16000 Bytes. NAS packets are 744 encapsulated within an RRC (Radio Resource Control) TGPP36331 745 message. 747 Depending on the data type indication signaled (IP or non-IP data), 748 the network allocates an IP address or establishes a direct 749 forwarding path. DoNAS is regulated under rate control upon previous 750 agreement, meaning that a maximum number of bits per unit of time is 751 agreed upon per device subscription beforehand and configured in the 752 device. The use of DoNAS is typically expected when a terminal in a 753 power-saving state requires a short transmission and receiving an 754 acknowledgment or short feedback from the network. Depending on the 755 size of buffered data to transmit, the UE might be instructed to 756 deploy the connected mode transmissions instead, limiting and 757 controlling the DoNAS transmissions to predefined thresholds and a 758 good resource optimization balance for the terminal the network. The 759 support for mobility of DoNAS is present but produces additional 760 overhead. 762 +--------+ +--------+ +--------+ 763 | | | | | | +-----------------+ 764 | UE | | C-BS | | C-SGN | |Roaming Scenarios| 765 +----|---+ +--------+ +--------+ | +--------+ | 766 | | | | | | | 767 +----------------|------------|+ | | P-GW | | 768 | Attach | | +--------+ | 769 +------------------------------+ | | | 770 | | | | | | 771 +------|------------|--------+ | | | | 772 |RRC Connection Establishment| | | | | 773 |with NAS PDU transmission | | | | | 774 |& Ack Rsp | | | | | 775 +----------------------------+ | | | | 776 | | | | | | 777 | |Initial UE | | | | 778 | |message | | | | 779 | |----------->| | | | 780 | | | | | | 781 | | +---------------------+| | | 782 | | |Checks Integrity || | | 783 | | |protection, decrypts || | | 784 | | |data || | | 785 | | +---------------------+| | | 786 | | | Small data packet | 787 | | |-------------------------------> 788 | | | Small data packet | 789 | | |<------------------------------- 790 | | +----------|---------+ | | | 791 | | Integrity protection,| | | | 792 | | encrypts data | | | | 793 | | +--------------------+ | | | 794 | | | | | | 795 | |Downlink NAS| | | | 796 | |message | | | | 797 | |<-----------| | | | 798 +-----------------------+ | | | | 799 |Small Data Delivery, | | | | | 800 |RRC connection release | | | | | 801 +-----------------------+ | | | | 802 | | 803 | | 804 +-----------------+ 806 Figure 6: DoNAS transmission sequence from an Uplink initiated access 807 +---+ +---+ +---+ +----+ 808 Application |AP1| |AP1| |AP2| |AP2 | 809 (IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU | 810 +---+ +---+ +---+ +----+ 811 | |/ / | \ | | 812 NAS /RRC +--------+---|---+----+ +---------+ 813 |NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 | 814 |RRC |PDU|PDU|PDU|RRC | |RRC |PDU | 815 +--------+-|-+---+----+ +---------| 816 | |\ | | | 817 |<--Max. 1600 bytes-->|__ |_ | 818 | | \__ \___ \_ \_ 819 | | \ \ \__ \_ 820 +---------------|+-----|----------+ \ \ 821 RLC |RLC | NAS/RRC ||RLC | NAS/RRC | +----|-------+ 822 |Head| PDU(1/2)||Head | PDU (2/2)| |RLC |NAS/RRC| 823 +---------------++----------------+ |Head|PDU | 824 | | | \ | +------------+ 825 | | LCID1 | \ | | / 826 | | | \ \ | | 827 | | | \ \ | | 828 | | | \ \ \ | 829 +----+----+----------++-----|----+---------++----+---------|---+ 830 MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| 831 |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | 832 +----+----+----------++-----+----+---------++----+---------+---+ 833 TB1 TB2 TB3 835 Figure 7: Example of User Plane packet encapsulation for Data 836 over NAS 838 8. Normative References 840 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 841 Header Compression (ROHC) Framework", RFC 5795, 842 DOI 10.17487/RFC5795, March 2010, 843 . 845 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 846 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 847 . 849 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 850 Zuniga, "SCHC: Generic Framework for Static Context Header 851 Compression and Fragmentation", RFC 8724, 852 DOI 10.17487/RFC8724, April 2020, 853 . 855 [TGPP23720] Meredith, J., "TR 23.720 v13.0.0 - Study on architecture 856 enhancements for Cellular Internet of Things", TR 23.720 857 v13.0.0, 2015, 858 . 861 [TGPP33203] Soveri, M., "TR 33.203 v13.0.1 : 3G security; Access 862 security fro IP-based services", TR 33.203 v13.0.1, 2020 863 . 866 [TGPP36321] Chung, Y., "TR 36.321 v13.2.0 : Evolved Universal 867 Terrestrial Radio Access (E-UTRA); Medium Access Control 868 (MAC) protocol specification", TR 36.321 V13.2.0, 2016, 869 . 872 [TGPP36323] Chung, Y., "TS 36.323 v13.2.0 : Evolved Universal 873 Terrestrial Radio Access (E-UTRA); Packet Data Convergence 874 Protocol (PDCP) specification", TS 36.323 v13.2.0, 2016, 875 . 878 [TGPP24301] Firmin. F., "TS 24.301 v13.2.0 : Non-Access-Stratum (NAS) 879 protocol for Evolved Packet System (EPS); Stage 3, TS 880 24.301 v13.2.0, 2015. 881