idnits 2.17.1 draft-ietf-lpwan-schc-over-nbiot-07.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: ---------------------------------------------------------------------------- No issues found here. 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.) ** 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 596: '... 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 (22 February 2022) is 793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TGPP33203' is mentioned on line 602, but not defined == Missing Reference: 'TGPP36321' is mentioned on line 267, but not defined == Missing Reference: 'TGPP36323' is mentioned on line 374, but not defined == Missing Reference: 'TGPP36322' is mentioned on line 267, but not defined == Missing Reference: 'TGPP36201' is mentioned on line 268, but not defined == Missing Reference: 'TGPP24301' is mentioned on line 307, but not defined Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: Informational A. Minaburo 5 Expires: 26 August 2022 Acklio 6 22 February 2022 8 SCHC over NB-IoT 9 draft-ietf-lpwan-schc-over-nbiot-07 11 Abstract 13 The Static Context Header Compression (SCHC) specification describes 14 header compression and fragmentation functionalities for LPWAN (Low 15 Power Wide Area Networks) technologies. The Narrow Band Internet of 16 Things (NB-IoT) architecture may adapt SCHC to improve its 17 capacities. 19 This document describes the use of SCHC over the NB-IoT wireless 20 access and provides elements 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 26 August 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 5 59 5. IP based Data Transmission . . . . . . . . . . . . . . . . . 6 60 5.1. SCHC over the Radio link . . . . . . . . . . . . . . . . 6 61 5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 6 62 5.2. SCHC over No-Access Stratum (NAS) . . . . . . . . . . . . 7 63 5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8 64 5.3. Parameters for Static Context Header Compression 65 (SCHC) . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.3.1. SCHC Context initialization . . . . . . . . . . . . . 9 67 5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 9 68 5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 10 70 5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 10 71 6. End-to-End Compression . . . . . . . . . . . . . . . . . . . 10 72 6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 11 73 6.2. Parameters for Static Context Header Compression . . . . 11 74 6.2.1. SCHC Context initialization . . . . . . . . . . . . . 11 75 6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 12 76 6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12 78 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12 79 6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 12 80 6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 13 81 7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8. Security considerations . . . . . . . . . . . . . . . . . . . 13 83 9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 13 84 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 10.1. NB-IoT User Plane protocol architecture . . . . . . . . 14 86 10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 14 87 10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 15 88 10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 16 89 10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 17 90 11. Normative References . . . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 The Static Context Header Compression (SCHC) [RFC8724] defines a 96 header compression scheme, and fragmentation functionality suitable 97 for the Low Power Wide Area Networks (LPWAN) networks defined in 98 [RFC8376]. 100 In an NB-IoT network, header compression efficiently brings Internet 101 connectivity to the node. This document describes the SCHC 102 parameters used to performs the static context header compression 103 into the NB-IoT wireless access. This document assumes functionality 104 for NB-IoT of 3GPP release 15. Otherwise, the text explicitly 105 mentions other versions' functionality. 107 2. Terminology 109 This document will follow the terms defined in [RFC8724], in 110 [RFC8376], and the TGPP23720. 112 * CIoT. Cellular IoT 114 * NGW-C-SGN. Network Gateway - CIoT Serving Gateway Node 116 * Dev-UE. Device - User Equipment 118 * RGW-eNB. Radio Gateway - Node B. Base Station that controls the 119 UE 121 * EPC. Evolved Packet Connectivity. Core network of 3GPP LTE 122 systems. 124 * EUTRAN. Evolved Universal Terrestrial Radio Access Network. 125 Radio network from LTE based systems. 127 * NGW-MME. Network Gateway - Mobility Management Entity. Handle 128 mobility of the UE 130 * NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology 131 based in LTE architecture but with additional optimization for IoT 132 and using a Narrow Band spectrum frequency. 134 * NGW-SGW. Network Gateway - Serving Gateway. Routes and forwards 135 the user data packets through the access network 137 * HSS. Home Subscriber Server. It is a database that performs 138 mobility management 140 * NGW-PGW. Network Gateway - Packet Data Node Gateway. An 141 interface between the internal with the external network 143 * PDU. Protocol Data Unit. Data packets including headers that are 144 transmitted between entities through a protocol. 146 * SDU. Service Data Unit. Data packets (PDUs) from higher layers 147 protocols used by lower layer protocols as a payload of their own 148 PDUs that has not yet been encapsulated. 150 * IWK-SCEF. InterWorking Service Capabilities Exposure Function. 151 Used in roaming scenarios and serves for interconnection with the 152 SCEF of the Home PLMN and is located in the Visited PLMN 154 * NGW-SCEF. Network Gateway - Service Capability Exposure Function. 155 EPC node for exposure of 3GPP network service capabilities to 3rd 156 party applications. 158 3. Architecture 160 +---+ +------+ 161 |Dev| \ +-----+ ----| HSS | 162 +---+ \ | NGW | +------+ 163 | |-MME |\__ 164 \ / +-----+ \ 165 +---+ \+-----+ / | +------+ 166 |Dev| ----| RGW |- | | NGW- | 167 +---+ |-eNB | | | SCEF |---------+ 168 /+-----+ \ | +------+ | 169 / \ +------+ | 170 / \| NGW- | +-----+ +-----------+ 171 +---+ / | CSGW |--| NGW-|---|Application| 172 |Dev| | | | PGW | | Server | 173 +---+ +------+ +-----+ +-----------+ 175 Figure 1: 3GPP network architecture 177 The Narrow Band Internet of Things (NB-IoT) architecture has a more 178 complex structure. It relies on different NGWs from different 179 providers and can send data by different paths, each path with 180 different characteristics such as bandwidths, acknowledgments, and 181 layer two reliability and segmentation. 183 Figure 1 shows this architecture where the Network Gateway Cellular 184 Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co- 185 locating entities in different paths. For example, a Dev using the 186 path form by the Network Gateway Mobility Management Entity (NGW- 187 MME), the NGW-CSGW, and Network Gateway Packet Data Node Gateway 188 (NGW-PGW) may get a limited bandwidth transmission from few bytes/s 189 to one thousand bytes/s only. 191 Another node introduced in the NBIoT architecture is the Network 192 Gateway Service Capability Exposure Function (NGW-SCEF), which 193 securely exposes service and network capabilities to entities 194 external to the network operator. OMA and OneM2M define the 195 northbound APIS [TGPP33203]. In this case, the path is small for 196 data transmission. The main functions of the NGW-SCEF are: 198 * Connectivity path 200 * Device Monitoring 202 4. Data Transmission 204 NB-IoT networks deal with end-to-end user data and in-band signaling 205 between the nodes and functions to configure, control, and monitor 206 the system functions and behaviors. The signaling data uses a 207 different path with specific protocols, handling processes, and 208 entities but can transport end-to-end user data for IoT services. In 209 contrast, the end-to-end application only transports end-to-end data. 211 The maximum recommended MTU size is 1358 Bytes. The radio network 212 protocols limit the packet sizes over the air, including radio 213 protocol overhead to 1600 Bytes. However, the MTU is smaller to 214 avoid fragmentation in the network backbone due to the payload 215 encryption size (multiple of 16) and the additional core transport 216 overhead handling. 218 3GPP standardizes NB-IoT and, in general, the cellular technologies 219 interfaces and functions. Therefore the introduction of SCHC 220 entities to Dev, RGW-eNB, and NGW-CSGN needs to be specified in the 221 NB-IoT standard, which implies that standard specifying SCHC support 222 would not be backward compatible. A terminal or a network supporting 223 a version of the standard without SCHC or without capability 224 implementation (in case of not being standardized as mandatory 225 capability) cannot utilize the compression services with this 226 approach. 228 SCHC could be deployed differently depending on where the header 229 compression and the fragmentation are applied. The SCHC 230 functionalities can be used over the radio transmission only, between 231 the Dev and the RGW-eNB. Alternatively, the packets transmitted over 232 the end-to-end link can use SCHC. Else, when the transmissions over 233 the NGW-MME or NGW-SCEF, the NGW-CSGN uses SCHC entity. For these 234 two cases, the functions are to be standardized by 3GPP. 236 Another possibility is to apply SCHC functionalities to the end-to- 237 end connection or at least up to the operator network edge. SCHC 238 functionalities are available in the application layer of the Dev and 239 the Application Servers or a broker function at the edge of the 240 operator network. The radio network transmits the packets as non-IP 241 traffic using IP tunneling or SCEF services. Since this option does 242 not necessarily require 3GPP standardization, it is possible to also 243 benefit legacy devices with SCHC by using the non-IP transmission 244 features of the operator network. 246 5. IP based Data Transmission 248 5.1. SCHC over the Radio link 250 Deploying SCHC only over the radio link would require placing it as 251 part of the protocol stack for data transfer between the Dev and the 252 RGW-eNB. This stack is the functional layer responsible for 253 transporting data over the wireless connection and managing radio 254 resources. There is support for features such as reliability, 255 segmentation, and concatenation. The transmissions use link 256 adaptation, meaning that the system will optimize the transport 257 format used according to the radio conditions, the number of bits to 258 transmit, and the power and interference constraints. That means 259 that the number of bits transmitted over the air depends on the 260 Modulation and Coding Schemes (MCS) selected. A Transport Block (TB) 261 transmissions happen in the physical layer at network synchronized 262 intervals called Transmission Time Interval (TTI). Each Transport 263 Block has a different MCS and number of bits available to transmit. 264 The MAC layer [TGPP36321] defines the Transport Blocks 265 characteristics. The Radio link Figure 2 stack comprises the Packet 266 Data Convergence Protocol (PDCP) [TGPP36323], Radio Link Protocol 267 (RLC) [TGPP36322], Medium Access Control protocol (MAC) [TGPP36321], 268 and the Physical Layer [TGPP36201]. The Appendix gives more details 269 of these protocols. 271 5.1.1. SCHC Entities Placing 273 The current architecture provides support for header compression in 274 PDCP with RoHC [RFC5795]. Therefore SCHC entities can be deployed 275 similarly without the need for significant changes in the 3GPP 276 specifications. 278 In this scenario, RLC takes care of fragmentation unless for the 279 transparent mode. When packets exceed the transport block size at 280 the time of transmission, SCHC fragmentation is unnecessary and 281 should not be used to avoid the additional protocol overhead. It is 282 not common to configure RLC in Transparent Mode for IP-based data. 283 However, given the case in the future, SCHC fragmentation may be 284 used. In that case, a SCHC tile would match the minimum transport 285 block size minus the PDCP and MAC headers. 287 +---------+ +---------+ | 288 |IP/non-IP+------------------------------+IP/non-IP+->+ 289 +---------+ | +---------------+ | +---------+ | 290 | PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+ 291 | (SCHC) + + (SCHC)| + + | | 292 +---------+ | +---------------+ | +---------+ | 293 | RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+ 294 +---------+ | +---------------+ | +---------+ | 295 | MAC +-------+ MAC | L2 +------+ L2 +->+ 296 +---------+ | +---------------+ | +---------+ | 297 | PHY +-------+ PHY | PHY +------+ PHY +->+ 298 +---------+ +---------------+ +---------+ | 299 C-Uu/ S1-U SGi 300 Dev RGW-eNB NGW-CSGN 302 Figure 2: SCHC over the Radio link 304 5.2. SCHC over No-Access Stratum (NAS) 306 The NGW-MME conveys mainly control signaling between the Dev and the 307 cellular network [TGPP24301]. The network transports this traffic on 308 top of the radio link. 310 This kind of flow supports data transmissions to reduce the overhead 311 when transmitting infrequent small quantities of data. This 312 transmission is known as Data over No-Access Stratum (DoNAS) or 313 Control Plane CIoT EPS optimization. In DoNAS, the Dev uses the pre- 314 established security and piggyback small uplink data into the initial 315 uplink message and uses an additional message to receive downlink 316 small data response. 318 The NGW-MME performs the data encryption from the network side in a 319 DoNAS PDU. Depending on the data type signaled indication (IP or 320 non-IP data), the network allocates an IP address or establishes a 321 direct forwarding path. DoNAS is regulated under rate control upon 322 previous agreement, meaning that a maximum number of bits per unit of 323 time is agreed upon per device subscription beforehand and configured 324 in the device. 326 The system will use DoNAS when a terminal in a power-saving state 327 requires a short transmission and receives an acknowledgment or short 328 feedback from the network. Depending on the size of buffered data to 329 transmit, the Dev might deploy the connected mode transmissions 330 instead, limiting and controlling the DoNAS transmissions to 331 predefined thresholds and a good resource optimization balance for 332 the terminal and the network. The support for mobility of DoNAS is 333 present but produces additional overhead. The Appendix gives 334 additional details of DoNAS. 336 5.2.1. SCHC Entities Placing 338 SCHC may reside in the Non-Access Stratum (NAS) protocol layer in 339 this scenario. The same principles as for Radio link transmissions 340 apply here as well. The main difference is the physical placing of 341 the SCHC entities on the network side as the NGW-MME resides in the 342 core network and is the terminating node for NAS instead of the eNB. 344 +--------+ +--------+--------+ + +--------+ 345 | IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ | 346 | Non-IP | | | | Non-IP | Non-IP | | | Non-IP | 347 +--------+ | | +-----------------+ | +--------+ 348 | NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U | 349 |(SCHC) | | | | (SCHC) | | | | | 350 +--------+ | +-----------+ | +-----------------+ | +--------+ 351 | RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | | 352 +--------+ | +-----------+ | +--------+ UDP +-----+ UDP | 353 | PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | | 354 +--------+ | +-----------+ | +-----------------+ | +--------+ 355 | RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP | 356 +--------+ | +-----------+ | +-----------------+ | +--------+ 357 | MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 | 358 +--------+ | +-----------+ | +-----------------+ | +--------+ 359 | PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY | 360 +--------+ +-----+-----+ +--------+--------+ | +--------+ 361 C-Uu/ S1-lite SGi 362 Dev RGW-eNB NGW-MME NGW-PGW 364 *PDCP is bypassed until AS security is activated TGPP36300. 366 Figure 3 368 5.3. Parameters for Static Context Header Compression (SCHC) 369 5.3.1. SCHC Context initialization 371 RRC (Radio Resource Control) protocol is the main tool used to 372 configure the parameters of the Radio link. It will configure SCHC 373 and the static context distribution as it has made for RoHC operation 374 [TGPP36323]. 376 5.3.2. SCHC Rules 378 The network operator in these scenarios defines the number of rules 379 in a context. The operator must be aware of the type of IP traffic 380 that the device will carry out. Implying that the operator might use 381 provision sets of rules compatible with the use case of the device. 382 For devices acting as gateways of other devices, several rules may 383 match the diversity of devices and protocols used by the devices 384 associated with the gateway. Meanwhile, simpler devices (for 385 example, an electricity meter) may have a predetermined set of fixed 386 protocols and parameters. Additionally, the deployment of IPv4 387 addresses and IPv6 may force different rules to deal with each case. 389 5.3.3. Rule ID 391 There is a reasonable assumption of 9 bytes of radio protocol 392 overhead for these transmission scenarios in NB-IoT, where PDCP uses 393 5 bytes due to header and integrity protection, and RLC and MAC use 4 394 bytes. The minimum physical Transport Blocks (TB) that can withhold 395 this overhead value according to 3GPP Release 15 specifications are 396 88, 104, 120, and 144 bits. A transmission optimization may require 397 only one physical layer transmission. SCHC overhead should not 398 exceed the available number of effective bits of the smallest 399 physical TB available. The packets handled by 3GPP networks are 400 byte-aligned, and therefore the minimum payload possible (including 401 padding) is 8 bits. Therefore in order to use the smallest TB, the 402 maximum SCHC header is 12 bits. These 12 bits must include the 403 Compression Residue in addition to the Rule ID. On the other hand, 404 more complex NB-IoT devices (such as a capillarity gateway) might 405 require additional bits to handle the variety and multiple parameters 406 of higher-layer protocols deployed. In that sense, the operator may 407 want to have flexibility on the number and type of rules supported by 408 each device independently, and consequently, these scenarios require 409 a configurable value. The configuration may be part of the operation 410 profile agreed together with the content distribution. The Rule ID 411 field size may range from 2 bits, resulting in 4 rules to an 8 bits 412 value that would yield up to 256 rules that can be used together with 413 the operators and seems quite a reasonable maximum limit even for a 414 device acting as a NAT. More bits could be configured, but it should 415 consider the byte-alignment of the expected Compression Residue. In 416 the minimum TB size case, 2 bits of Rule Id leave only 6 bits 417 available for Compression Residue. 419 5.3.4. SCHC MAX_PACKET_SIZE 421 The Radio Link can handle the fragmentation of SCHC packets if 422 needed, including reliability. Hence the packet size is limited by 423 the MTU handled by the radio protocols that correspond to 1600 bytes 424 for 3GPP Release 15. 426 5.3.5. Fragmentation 428 For these scenarios, the SCHC fragmentation functions are disabled. 429 The RLC layer of NB-IoT can segment packets in suitable units that 430 fit the selected transport blocks for transmissions of the physical 431 layer. The blocks selection is made according to the link adaptation 432 input function in the MAC layer and the quantity of data in the 433 buffer. The link adaptation layer may produce different results at 434 each Time Transmission Interval (TTI), resulting in varying physical 435 transport blocks that depend on the network load, interference, 436 number of bits transmitted, and QoS. Even if setting a value that 437 allows the construction of data units following the SCHC tiles 438 principle, the protocol overhead may be greater or equal than 439 allowing the Radio link protocols to take care of the fragmentation 440 natively. 442 5.3.5.1. Fragmentation in Transparent Mode 444 If RLC operates in Transparent Mode, there could be a case to 445 activate a fragmentation function together with a light reliability 446 function such as the ACK-Always mode. In practice, it is uncommon to 447 transmit radio link data using this configuration. It mainly targets 448 signaling transmissions. In those cases, the MAC layer mechanisms 449 ensure reliability, such as repetitions or automatic retransmissions, 450 and additional reliability might only generate protocol overhead. 452 SCHC may reduce radio network protocols overhead in future 453 operations, support reliable transmissions, and transmit small data 454 with fewer possible transmissions by using fixed or limited transport 455 blocks compatible with the tiling SCHC fragmentation handling. 457 6. End-to-End Compression 459 The Non-IP Data Delivery (NIDD) services of 3GPP enable the 460 transmission of SCHC packets compressed by the application layer. 461 The packets can be delivered using IP-tunnels to the 3GPP network or 462 NGW-SCEF functions (i.e., API calls). In both cases, as compression 463 occurs before transmission, the network will not understand the 464 packet, and the network does not have context information of this 465 compression. Therefore the network will treat the packet as Non-IP 466 traffic and deliver it to the Dev without any other stack element, 467 directly under the L2. 469 6.1. SCHC Entities Placing 471 In the two scenarios using End-to-End compression, SCHC entities are 472 located almost on top of the stack. In the Dev, an application using 473 the NB-IoT connectivity services may implement SCHC and the 474 Application Server. The IP tunneling scenario requires that the 475 Application Server send the compressed packet over an IP connection 476 terminated by the 3GPP core network. If the transmission uses the 477 NGW-SCEF services, it is possible to utilize an API call to transfer 478 the SCHC packets between the core network and the Application Server. 479 Also, an IP tunnel could be established by the Application Server if 480 negotiated with the NGW-SCEF. 482 +---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+ 483 | SCHC | XXX XXX | SCHC | 484 |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)| 485 +---------+ XX +----+ XX | | +--------+ 486 | | XX |SCEF+-------+ | | | 487 | | XXX 3GPP RAN & +----+ XXX +---+ UDP | 488 | | XXX CORE NETWORK XXX | | | 489 | L2 +---+XX +------------+ | +--------+ 490 | | XX |IP TUNNELING+--+ | | 491 | | XXX +------------+ +---+ IP | 492 +---------+ XXXX XXXX | +--------+ 493 | PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY | 494 +---------+ +--------+ 495 UE AS 497 Figure 4: SCHC entities placed when using Non-IP Delivery (NIDD) 498 3GPP Sevices 500 6.2. Parameters for Static Context Header Compression 502 6.2.1. SCHC Context initialization 504 The application layer handles the static context; consequently, the 505 context distribution must be according to the application's 506 capabilities, perhaps utilizing IP data transmissions up to context 507 initialization. Also, the static contexts delivery may use the same 508 IP tunneling or NGW-SCEF services used later for the SCHC packets 509 transport. 511 6.2.2. SCHC Rules 513 Even when the transmission content is not visible for the 3GPP 514 network, the same limitations as for IP-based data transmissions 515 applies in these scenarios in terms of aiming to use the minimum 516 number of transmission and minimize the protocol overhead. 518 6.2.3. Rule ID 520 Similar to the case of IP transmissions, the Rule ID size can be 521 dynamically set before the context delivery. For example, negotiated 522 between the applications when choosing a profile according to the 523 type of traffic and application deployed. The same considerations 524 related to the transport block size and performance mentioned for the 525 IP type of traffic must be followed when choosing a size value for 526 the Rule ID field. 528 6.2.4. SCHC MAX_PACKET_SIZE 530 In these scenarios, the maximum recommended MTU size that applies is 531 1358 Bytes since the SCHC packets (and fragments) are traversing the 532 whole 3GPP network infrastructure (core and radio), not only the 533 radio as the IP transmissions case. 535 6.3. Fragmentation 537 In principle, packets larger than 1358 bytes need the fragmentation 538 function. Since the 3GPP uses reliability functions, the No-ACK 539 fragmentation mode may be enough in point-to-point connections. 540 Nevertheless, additional considerations are described below for more 541 complex cases. 543 6.3.1. Fragmentation modes 545 A global service assigns a QoS to the packets depending on the 546 billing. Packets with very low QoS may get lost before they arrive 547 in the 3GPP radio network transmission, for example, in between the 548 links of a capillarity gateway or due to buffer overflow handling in 549 a backhaul connection. The use of SCHC fragmentation with the ACK- 550 on-Error mode is recommended to secure additional reliability on the 551 packets transmitted with a small trade-off on additional 552 transmissions to signal the end-to-end arrival of the packets if no 553 transport protocol takes care of retransmission. Also, the ACK-on- 554 Error mode is even desirable to keep track of all the SCHC packets 555 delivered. In that case, the fragmentation function could be active 556 for all packets transmitted by the applications. SCHC ACK-on-Error 557 fragmentation may be active for the transmission of non-IP packets on 558 the NGW-MME. If these packets are considering to use SCHC with the 559 RuleID for non-compressing packets as {RFC8724} allows it. 561 6.3.2. Fragmentation Parameters 563 SCHC profile with the fragmentation mode will have specific Rules. 564 The Rule ID will identify the fragmentation mode used, and it is 565 defined in section Section 5.3.3. 567 SCHC parametrization considers that NBIoT aligns the bit and uses 568 padding and the size of the Transfer Block. SCHC will try to reduce 569 padding to optimize the compression of the information. The Header 570 size needs to be multiple of 4, and the Tiles may keep a fixed value 571 of 4 or 8 bits to avoid padding except for transfer block equals 16 572 bits where Tiles may be of 2 bits. For the other parameters, the 573 transfer block size has a wide range that needs two configurations. 575 * For Transfer Blocks smaller than 300bits: 8 bits-Header_size 576 configuration, with the size of the header fields as follows: Rule 577 ID from 1 - 3 bits, DTag 1 bit, FCN 3 bits, W 1 bits. 579 * For Transfer Blocks bigger than 300 bits: 16 bits-Header_size 580 configuration, with the size of the header fields as follows: 581 Rules ID from 1 to 8 or 10 bits, DTag 1 or 2 bits, FCN 3 bits, W 2 582 or 3 bits. 584 The IoT devices communicate with small data transfer and have a 585 battery life of 10 years. These devices use the Power Save Mode and 586 the Idle Mode DRX, which govern how often the device wakes up, stays 587 up, and is reachable. Table 10.5.163a in {3GPP-TS_24.088} specifies 588 a range for the radio timers as N to 3N in increments of one where 589 the units of N can be 1 hour or 10 hours. To adapt SCHC to the NB- 590 IoT activities, the Inactivity Timer and the Retransmission Timer may 591 use these limits. 593 7. Padding 595 NB-IoT and 3GPP wireless access, in general, assumes byte-aligned 596 payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits, 597 and the padding treatment should use this value accordingly. 599 8. Security considerations 601 This document does not add any security considerations and follows 602 the 3GPP access security document specified in [TGPP33203]. 604 9. 3GPP References 605 * TGPP23720 3GPP, "TR 23.720 v13.0.0 - Study on architecture 606 enhancements for Cellular Internet of Things", 2016. 608 * TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security 609 for IP-based services", 2016. 611 * TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial 612 Radio Access (E-UTRA); Medium Access Control (MAC) protocol 613 specification", 2016 615 * TGPP36323 3GPP, "TS 36.323 v13.2.0 - Evolved Universal Terrestrial 616 Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) 617 specification", 2016. 619 * TGPP36331 3GPP, "TS 36.331 v13.2.0 - Evolved Universal Terrestrial 620 Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol 621 specification", 2016. 623 * TGPP36300 3GPP, "TS 36.300 v15.1.0 - Evolved Universal Terrestrial 624 Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio 625 Access Network (E-UTRAN); Overall description; Stage 2", 2018 627 * TGPP24301 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS) 628 protocol for Evolved Packet System (EPS); Stage 3", 2018 630 * TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer 631 3 specification;Core network protocols; Stage 3", 2015. 633 10. Appendix 635 10.1. NB-IoT User Plane protocol architecture 637 10.1.1. Packet Data Convergence Protocol (PDCP) 639 Each of the Radio Bearers (RB) is associated with one PDCP entity. 640 Moreover, a PDCP entity is associated with one or two RLC entities 641 depending on the unidirectional or bi-directional characteristics of 642 the RB and RLC mode used. A PDCP entity is associated with either a 643 control plane or a user plane with independent configuration and 644 functions. The maximum supported size for NB-IoT of a PDCP SDU is 645 1600 octets. The primary services and functions of the PDCP sublayer 646 for NB-IoT for the user plane include: 648 * Header compression and decompression using ROHC (Robust Header 649 Compression) 651 * Transfer of user and control data to higher and lower layers 652 * Duplicate detection of lower layer SDUs when re-establishing 653 connection (when RLC with Acknowledge Mode in use for User Plane 654 only) 656 * Ciphering and deciphering 658 * Timer-based SDU discard in uplink 660 10.1.2. Radio Link Protocol (RLC) 662 RLC is a layer-2 protocol that operates between the UE and the base 663 station (eNB). It supports the packet delivery from higher layers to 664 MAC, creating packets transmitted over the air, optimizing the 665 Transport Block utilization. RLC flow of data packets is 666 unidirectional, and it is composed of a transmitter located in the 667 transmission device and a receiver located in the destination device. 668 Therefore to configure bi-directional flows, two sets of entities, 669 one in each direction (downlink and uplink), must be configured and 670 effectively peered to each other. The peering allows the 671 transmission of control packets (ex., status reports) between 672 entities. RLC can be configured for data transfer in one of the 673 following modes: 675 * Transparent Mode (TM). RLC does not segment or concatenate SDUs 676 from higher layers in this mode and does not include any header to 677 the payload. RLC receives SDUs from upper layers when acting as a 678 transmitter and transmits directly to its flow RLC receiver via 679 lower layers. Similarly, a TM RLC receiver would only deliver 680 without processing the packets to higher layers upon reception. 682 * Unacknowledged Mode (UM). This mode provides support for 683 segmentation and concatenation of payload. The RLC packet's size 684 depends on the indication given at a particular transmission 685 opportunity by the lower layer (MAC) and is octets aligned. The 686 packet delivery to the receiver does not include reliability 687 support, and the loss of a segment from a packet means a complete 688 packet loss. Also, in the case of lower layer retransmissions, 689 there is no support for re-segmentation in case of change of the 690 radio conditions triggering the selection of a smaller transport 691 block. Additionally, it provides PDU duplication detection and 692 discards, reordering of out-of-sequence, and loss detection. 694 * Acknowledged Mode (AM). In addition to the same functions 695 supported by UM, this mode also adds a moving windows-based 696 reliability service on top of the lower layer services. It also 697 supports re-segmentation, and it requires bidirectional 698 communication to exchange acknowledgment reports called RLC Status 699 Report and trigger retransmissions. This model also supports 700 protocol error detection. The mode used depends on the operator 701 configuration for the type of data to be transmitted. For 702 example, data transmissions supporting mobility or requiring high 703 reliability would be most likely configured using AM. Meanwhile, 704 streaming and real-time data would be mapped to a UM 705 configuration. 707 10.1.3. Medium Access Control (MAC) 709 MAC provides a mapping between the higher layers abstraction called 710 Logical Channels comprised by the previously described protocols to 711 the Physical layer channels (transport channels). Additionally, MAC 712 may multiplex packets from different Logical Channels and prioritize 713 what to fit into one Transport Block if there is data and space 714 available to maximize data transmission efficiency. MAC also 715 provides error correction and reliability support through HARQ, 716 transport format selection, and scheduling information reporting from 717 the terminal to the network. MAC also adds the necessary padding and 718 piggyback control elements when possible and the higher layers data. 720 721 +---+ +---+ +------+ 722 Application |AP1| |AP1| | AP2 | 723 (IP/non-IP) |PDU| |PDU| | PDU | 724 +---+ +---+ +------+ 725 | | | | | | 726 PDCP +--------+ +--------+ +-----------+ 727 |PDCP|AP1| |PDCP|AP1| |PDCP| AP2 | 728 |Head|PDU| |Head|PDU| |Head| PDU | 729 +--------+ +--------+ +--------+--\ 730 | | | | | | | | |\ `----\ 731 +---------------------------+ | |(1)| `-----\(2)'-\ 732 RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+ 733 |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2| 734 +-------------|-------------+ |Head|Head|PDU| |Head|PDU| 735 | | | | | +---------|---+ +--------+ 736 | | | LCID1 | | / / / / / 737 / / / _/ _// _/ _/ / LCID2 / 738 | | | | | / _/ _/ / ___/ 739 | | | | || | | / / 740 +------------------------------------------+ +-----------+---+ 741 MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad| 742 |Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din| 743 |der|der|der | |der|der | |der|der | | |der|der| |g | 744 +------------------------------------------+ +-----------+---+ 745 TB1 TB2 747 Figure 5: Example of User Plane packet encapsulation for two 748 transport blocks 750 10.2. NB-IoT Data over NAS (DoNAS) 752 The Access Stratum (AS) protocol stack used by DoNAS is somehow 753 particular. Since the security associations are not established yet 754 in the radio network, to reduce the protocol overhead, PDCP (Packet 755 Data Convergence Protocol) is bypassed until AS security is 756 activated. RLC (Radio Link Control protocol) uses by default the AM 757 mode, but depending on the network's features and the terminal, it 758 may change to other modes by the network operator. For example, the 759 transparent mode does not add any header or process the payload to 760 reduce the overhead, but the MTU would be limited by the transport 761 block used to transmit the data, which is a couple of thousand bits 762 maximum. If UM (only Release 15 compatible terminals) is used, the 763 RLC mechanisms of reliability are disabled, and only the reliability 764 provided by the MAC layer by Hybrid Automatic Repeat reQuest (HARQ) 765 is available. In this case, the protocol overhead might be smaller 766 than the AM case because of the lack of status reporting but with the 767 same support for segmentation up to 16000 Bytes. NAS packets are 768 encapsulated within an RRC (Radio Resource Control) TGPP36331 769 message. 771 Depending on the data type indication signaled (IP or non-IP data), 772 the network allocates an IP address or establishes a direct 773 forwarding path. DoNAS is regulated under rate control upon previous 774 agreement, meaning that a maximum number of bits per unit of time is 775 agreed upon per device subscription beforehand and configured in the 776 device. The use of DoNAS is typically expected when a terminal in a 777 power-saving state requires a short transmission and receiving an 778 acknowledgment or short feedback from the network. Depending on the 779 size of buffered data to transmit, the UE might be instructed to 780 deploy the connected mode transmissions instead, limiting and 781 controlling the DoNAS transmissions to predefined thresholds and a 782 good resource optimization balance for the terminal the network. The 783 support for mobility of DoNAS is present but produces additional 784 overhead. 786 +--------+ +--------+ +--------+ 787 | | | | | | +-----------------+ 788 | UE | | C-BS | | C-SGN | |Roaming Scenarios| 789 +----|---+ +--------+ +--------+ | +--------+ | 790 | | | | | | | 791 +----------------|------------|+ | | P-GW | | 792 | Attach | | +--------+ | 793 +------------------------------+ | | | 794 | | | | | | 795 +------|------------|--------+ | | | | 796 |RRC Connection Establishment| | | | | 797 |with NAS PDU transmission | | | | | 798 |& Ack Rsp | | | | | 799 +----------------------------+ | | | | 800 | | | | | | 801 | |Initial UE | | | | 802 | |message | | | | 803 | |----------->| | | | 804 | | | | | | 805 | | +---------------------+| | | 806 | | |Checks Integrity || | | 807 | | |protection, decrypts || | | 808 | | |data || | | 809 | | +---------------------+| | | 810 | | | Small data packet | 811 | | |-------------------------------> 812 | | | Small data packet | 813 | | |<------------------------------- 814 | | +----------|---------+ | | | 815 | | Integrity protection,| | | | 816 | | encrypts data | | | | 817 | | +--------------------+ | | | 818 | | | | | | 819 | |Downlink NAS| | | | 820 | |message | | | | 821 | |<-----------| | | | 822 +-----------------------+ | | | | 823 |Small Data Delivery, | | | | | 824 |RRC connection release | | | | | 825 +-----------------------+ | | | | 826 | | 827 | | 828 +-----------------+ 830 Figure 6: DoNAS transmission sequence from an Uplink initiated access 831 +---+ +---+ +---+ +----+ 832 Application |AP1| |AP1| |AP2| |AP2 | 833 (IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU | 834 +---+ +---+ +---+ +----+ 835 | |/ / | \ | | 836 NAS /RRC +--------+---|---+----+ +---------+ 837 |NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 | 838 |RRC |PDU|PDU|PDU|RRC | |RRC |PDU | 839 +--------+-|-+---+----+ +---------| 840 | |\ | | | 841 |<--Max. 1600 bytes-->|__ |_ | 842 | | \__ \___ \_ \_ 843 | | \ \ \__ \_ 844 +---------------|+-----|----------+ \ \ 845 RLC |RLC | NAS/RRC ||RLC | NAS/RRC | +----|-------+ 846 |Head| PDU(1/2)||Head | PDU (2/2)| |RLC |NAS/RRC| 847 +---------------++----------------+ |Head|PDU | 848 | | | \ | +------------+ 849 | | LCID1 | \ | | / 850 | | | \ \ | | 851 | | | \ \ | | 852 | | | \ \ \ | 853 +----+----+----------++-----|----+---------++----+---------|---+ 854 MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| 855 |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | 856 +----+----+----------++-----+----+---------++----+---------+---+ 857 TB1 TB2 TB3 859 Figure 7: Example of User Plane packet encapsulation for Data 860 over NAS 862 11. Normative References 864 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 865 Header Compression (ROHC) Framework", RFC 5795, 866 DOI 10.17487/RFC5795, March 2010, 867 . 869 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 870 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 871 . 873 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 874 Zuniga, "SCHC: Generic Framework for Static Context Header 875 Compression and Fragmentation", RFC 8724, 876 DOI 10.17487/RFC8724, April 2020, 877 . 879 Authors' Addresses 881 Edgar Ramos 882 Ericsson 883 Hirsalantie 11 884 02420 Jorvas, Kirkkonummi 885 Finland 886 Email: edgar.ramos@ericsson.com 888 Ana Minaburo 889 Acklio 890 1137A Avenue des Champs Blancs 891 35510 Cesson-Sevigne Cedex 892 France 893 Email: ana@ackl.io