idnits 2.17.00 (12 Aug 2021) /tmp/idnits40536/draft-ietf-lpwan-schc-over-nbiot-03.txt: -(957): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 674: '... 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 (13 July 2020) is 677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TGPP23720' is mentioned on line 683, but not defined == Missing Reference: 'TGPP36321' is mentioned on line 689, but not defined == Missing Reference: 'TGPP36323' is mentioned on line 693, but not defined == Missing Reference: 'TGPP36322' is mentioned on line 326, but not defined == Missing Reference: 'TGPP36201' is mentioned on line 328, but not defined == Missing Reference: 'TGPP24301' is mentioned on line 706, but not defined == Missing Reference: 'TGPP36300' is mentioned on line 701, but not defined == Missing Reference: 'TGPP33203' is mentioned on line 686, but not defined == Missing Reference: 'TGPP36331' is mentioned on line 852, but not defined == Missing Reference: 'TGPP24088' is mentioned on line 709, but not defined Summary: 2 errors (**), 0 flaws (~~), 12 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: 14 January 2021 Acklio 6 13 July 2020 8 SCHC over NB-IoT 9 draft-ietf-lpwan-schc-over-nbiot-03 11 Abstract 13 The Static Context Header Compression (SCHC) specification describes 14 a header compression and fragmentation functionalities for LPWAN (Low 15 Power Wide Area Networks) technologies. SCHC was designed to be 16 adapted over any of the LPWAN technologies. 18 This document describes the use of SCHC over the NB-IoT wireless 19 access, and provides elements for an efficient parameterization. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 14 January 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 6 58 5. IP based Data Transmission . . . . . . . . . . . . . . . . . 7 59 5.1. SCHC over User Plane transmissions . . . . . . . . . . . 8 60 5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8 61 5.2. Data Over Control Plane . . . . . . . . . . . . . . . . . 9 62 5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 10 63 5.3. Parameters for Static Context Header Compression 64 (SCHC) . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.3.1. SCHC Context initialization . . . . . . . . . . . . . 11 66 5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 11 67 5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12 69 5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 70 6. Non-IP based Data Transmission . . . . . . . . . . . . . . . 13 71 6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 13 72 6.2. Parameters for Static Context Header Compression . . . . 13 73 6.2.1. SCHC Context initialization . . . . . . . . . . . . . 14 74 6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 14 75 6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 14 76 6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 14 77 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14 78 6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 15 79 6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 15 80 7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 8. Security considerations . . . . . . . . . . . . . . . . . . . 16 82 9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 16 83 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 10.1. NB-IoT User Plane protocol architecture . . . . . . . . 17 85 10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 17 86 10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 17 87 10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 18 88 10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 19 89 11. Informative References . . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 The Static Context Header Compression (SCHC) {RFC8724} defines a 95 header compression scheme and fragmentation functionality, both 96 specially tailored for Low Power Wide Area Networks (LPWAN) networks 97 defined in [RFC8376]. 99 Header compression is needed to efficiently bring Internet 100 connectivity to the node within an NB-IoT network. SCHC uses a 101 static context to performs header compression with specific 102 parameters that need to be adapted into the NB-IoT wireless access. 103 This document assumes functionality for NB-IoT of 3GPP release 15 104 otherwise other versions functionality is explicitly mentioned in the 105 text. 107 This document describes the use of SCHC and its parameterizing over 108 the NB-IoT wireless access. 110 2. Terminology 112 This document will follow the terms defined in [RFC8724], in 113 [RFC8376], and the [TGPP23720]. 115 * CIoT. Cellular IoT 117 * C-SGN. CIoT Serving Gateway Node 119 * UE. User Equipment 121 * eNB. Node B. Base Station that controls the UE 123 * EPC. Evolved Packet Connectivity. Core network of 3GPP LTE 124 systems. 126 * EUTRAN. Evolved Universal Terrestrial Radio Access Network. 127 Radio network from LTE based systems. 129 * MME. Mobility Management Entity. Handle mobility of the UE 131 * NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology 132 based in LTE architecture but with additional optimization for IoT 133 and using a Narrow Band spectrum frequency. 135 * SGW. Serving Gateway. Routes and forwards the user data packets 136 through the access network 138 * HSS. Home Subscriber Server. It is a database that performs 139 mobility management 141 * PGW. Packet Data Node Gateway. An interface between the internal 142 with the external network 144 * PDU. Protocol Data Unit. Data packets including headers that are 145 transmitted between entities through a protocol. 147 * SDU. Service Data Unit. Data packets (PDUs) from higher layers 148 protocols used by lower layer protocols as a payload of their own 149 PDUs that has not yet been encapsulated. 151 * IWK-SCEF. InterWorking Service Capabilities Exposure Function. 152 Used in roaming scenarios and serves for interconnection with the 153 SCEF of the Home PLMN and is located in the Visited PLMN 155 * SCEF. Service Capability Exposure Function. EPC node for 156 exposure of 3GPP network service capabilities to 3rd party 157 applications. 159 3. Architecture 161   +--+ 162 |UE| \ +-----+ +------+ 163 +--+ \ | MME |-----| HSS | 164 \ / +-----+ +------+ 165 +--+ \+-----+ / | 166 |UE| ----| eNB |- | 167 +--+ /+-----+ \ | 168 / \ +------+ 169 / \| | +------+ Service PDN 170 +--+ / | S-GW |--| P-GW |-- e.g. Internet 171 |UE| | | +------+ 172 +--+ +------+ 174 Figure 1: 3GPP network architecture 176 The architecture for 3GPP LTE network has been reused for NB-IoT with 177 some optimizations and simplifications known as Cellular IoT (CIoT). 178 Considering the typical use cases for CIoT devices here are described 179 some of the additions to the LTE architecture specific for CIoT. 180 C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating 181 EPS entities in the control plane and user plane paths (for example, 182 MME + SGW + P-GW) and the external interfaces of the entities 183 supported. The C-SGN also supports at least some of the following 184 CIoT EPS Optimizations: 186 * Control Plane CIoT EPS Optimization for small data transmission. 188 * User Plane CIoT EPS Optimization for small data transmission. 190 * Necessary security procedures for efficient small data 191 transmission. 193 * SMS without combined attach for NB-IoT only UEs. 195 * Paging optimizations for coverage enhancements. 197 * Support for non-IP data transmission via SGi tunneling and/or 198 SCEF. 200 * Support for Attach without PDN (Packet Data Network) connectivity. 202 Another node introduced in the CIOT architecture is the SCEF (Service 203 Capability Exposure Function) that provide means to securely expose 204 service and network capabilities to entities external to the network 205 operator. The northbound APIS are defined by OMA and OneM2M. The 206 main functions of a SCEF are: 208 * Non-IP Data Delivery (NIDD) established through the SCEF. 210 * Monitoring and exposure of event related to UE reachability, loss 211 of connectivity, location reporting, roaming status, communication 212 failure and change of IMEI-IMSI association. 214 +-------+ 215 | HSS | 216 +-+-----+ 217 / 218 +---------+ __/S6a 219 +--------+ | +-----+ +_/ 220 +----+ C-Uu | +---+-+ MME | | T6i+--------+ T7 +----+ 221 |CIOT+--------+ eNB |S1 | | +-+----+IWK-SCEF+----+SCEF| 222 |UE | |(NB-IoT)| | +---+-+ | +--------+ +----+ 223 +----+ +--------+ | | | 224 |C-SGN| | 225 | |S11| 226 +------+ | | | 227 +--------+LTE-Uu| | | +--+-+ | 228 |LTE eMTC|(eMTC)|eNB +---+--+SGW | | S8+---+ +-----------+ 229 | UE +------+(eMTC)|S1 | | +-+---+PGW|SGi |Application| 230 +--------+ +------+ | +----+ | | +----+Server (AS)| 231 +---------+ +---+ +-----------+ 233 Figure 2: 3GPP optimized CIOT network architecture 235 4. Data Transmission 237 3GPP networks deal not only with data transmitted end-to-end but also 238 with in-band signaling that is used between the nodes and functions 239 to configure, control and monitor the system functions and behaviors. 240 The control data is handled using a Control Plane which has a 241 specific set of protocols, handling processes and entities. In 242 contrast, the end-to-end or user data utilize a User Plane with 243 characteristics of its own separated from the Control Plane. The 244 handling and setup of the Control Plane and User Plane spans over the 245 whole 3GPP network and it has particular implications in the radio 246 network (i.e., EUTRAN) and in the packet core (ex., EPC). 248 For the CIOT cases, additionally to transmissions of data over User 249 Plane, 3GPP has specified optimizations for small data transmissions, 250 allowing to transport user data (IP, Non-IP) within signaling on the 251 access network (Data transmission over Control Plane or Data Over 252 NAS). 254 The maximum recommended MTU size is 1358 Bytes. The radio network 255 protocols limit the packet sizes to be transmitted over the air 256 including radio protocol overhead to 1600 Octets. But the value is 257 reduced further to avoid fragmentation in the backbone of the network 258 due to the payload encryption size (multiple of 16) and handling of 259 the additional core transport overhead. 261 NB-IoT and in general the cellular technologies interfaces and 262 functions are standardized by 3GPP. Therefore the introduction of 263 SCHC entities to UE, eNB and C-SGN does need to be specified in the 264 NB-IoT standard. This implies that standard specified SCHC support 265 would not be backwards compatible. A terminal or a network 266 supporting a version of the standard without support of SCHC or 267 without capability implementation (in case of not being standardized 268 as mandatory capability) is not able to utilize the compression 269 services with this approach. 271 SCHC could be deployed differently depending on where the header 272 compression and the fragmentation are applied. The SCHC 273 functionalities could be applied to the packets about to be 274 transmitted over the air, or to the whole end-to-end link. To 275 accomplish the first, it is required to place SCHC compression and 276 decompression entities in the eNB and in the UE for transmissions 277 over the User Plane. Additionally, to handle the case of the 278 transmissions over Control Plane or Data Over NAS, the network SCHC 279 entity has to be placed in the C-SGN as well. For these two cases, 280 the functions are to be standardized by 3GPP. 282 Another possibility is to apply SCHC functionalities to the end-to- 283 end connection or at least up to the operator network edge. In that 284 case, the SCHC entities would be placed in the application layer of 285 the terminal in one end, and either in the application servers or in 286 a broker function in the edge of the operator network in the other 287 end. For the radio network, the packets are transmitted as non-IP 288 traffic, which can be currently served utilizing IP tunneling or SCEF 289 services. Since this option does not necessarily require 3GPP 290 standardization, it is possible to also benefit legacy devices with 291 SCHC by utilizing the non-IP transmission features of the operator 292 network. 294 Accordingly, there are four different scenarios where SCHC can be 295 used in the NB-IoT architecture. IP header compression on the data 296 transmission over User Plane, IP header compression on the optimized 297 transmissions over Control Plane (i.e.,DoNAS), non-IP transmissions 298 of SCHC packets by IP tunneling, and non-IP transmissions of SCHC 299 packets by SCEF forwarding. The following sections describe each of 300 them in more detail. The first two scenarios refer to transmissions 301 using the 3GPP IP transmission capabilities and the last two refers 302 to transmission using the Non-IP capabilities. 304 5. IP based Data Transmission 305 5.1. SCHC over User Plane transmissions 307 Deploying SCHC only over the radio link would require to place it as 308 part of the User Plane data transmission. The User Plane utilizes 309 the protocol stack of the Access Stratum (AS) for data transfer. AS 310 (Access Stratum) is the functional layer responsible for transporting 311 data over wireless connection and managing radio resources. The user 312 plane AS has support for features such as reliability, segmentation 313 and concatenation. The transmissions of the AS make use of link 314 adaptation, meaning that the transport format utilized for the 315 transmissions are optimized according to the radio conditions, the 316 number of bits to transmit and the power and interference constrains. 317 That means that the number of bits transmitted over the air depends 318 of the Modulation and Coding Schemes (MCS) selected. The 319 transmissions in the physical layer happens at network synchronized 320 intervals of times called TTI (Transmission Time Interval). The 321 transmission of a Transport Block (TB) is completed during, at least, 322 one TTI. Each Transport Block has a different MCS and number of bits 323 available to transmit. The Transport Blocks characteristics are 324 defined by the MAC technical specification [TGPP36321]. The Access 325 Stratum for User Plane is comprised by Packet Data Convergence 326 Protocol (PDCP) [TGPP36323], Radio Link Protocol (RLC)[TGPP36322], 327 Medium Access Control protocol (MAC)[TGPP36321] and the Physical 328 Layer [TGPP36201]. More details of this protocols are given in the 329 Appendix. 331 5.1.1. SCHC Entities Placing 333 The current architecture provides support for header compression in 334 PDCP utilizing RoHC [RFC5795]. Therefore SCHC entities can be 335 deployed in similar fashion without need for major changes in the 336 3GPP specifications. 338 In this scenario, RLC takes care of the handling of fragmentation (if 339 transparent mode is not configured) when packets exceeds the 340 transport block size at the time of transmission. Therefore SCHC 341 fragmentation is not needed and should not be used to avoid 342 additional protocol overhead. It is not common to configure RLC in 343 Transparent Mode for IP based user plane data. But given the case in 344 the future, SCHC fragmentation may be used. In that case, a SCHC 345 tile would match the minimum transport block size minus the PDCP and 346 MAC headers. 348 +---------+ +---------+ | 349 |IP/non-IP+------------------------------+IP/non-IP+->+ 350 +---------+ | +---------------+ | +---------+ | 351 | PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+ 352 | (SCHC) + + (SCHC)| + + | | 353 +---------+ | +---------------+ | +---------+ | 354 | RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+ 355 +---------+ | +---------------+ | +---------+ | 356 | MAC +-------+ MAC | L2 +------+ L2 +->+ 357 +---------+ | +---------------+ | +---------+ | 358 | PHY +-------+ PHY | PHY +------+ PHY +->+ 359 +---------+ +---------------+ +---------+ | 360 C-Uu/ S1-U SGi 361 CIOT/ LTE+Uu C-BS/eNB C-SGN 362 LTE eMTC 363 UE 365 Figure 3: SCHC entities placement in the 3GPP CIOT radio protocol 366 architecture for data over user plane 368 5.2. Data Over Control Plane 370 The Non-Access Stratum (NAS), conveys mainly control signaling 371 between the UE and the cellular network [TGPP24301]. NAS is 372 transported on top of the Access Stratum (AS) already mentioned in 373 the previous section. 375 NAS has been adapted to provide support for user plane data 376 transmissions to reduce the overhead when transmitting infrequent 377 small quantities of data. This is known as Data over NAS (DoNAS) or 378 Control Plane CIoT EPS optimization. In DoNAS the UE makes use of 379 the pre-established NAS security and piggyback uplink small data into 380 the initial NAS uplink message, and uses an additional NAS message to 381 receive downlink small data response. 383 The data encryption from the network side is performed by the C-SGN 384 in a NAS PDU. Depending on the data type signaled indication (IP or 385 non-IP data), the network allocates an IP address or just establish a 386 direct forwarding path. DoNAS (Data over NAS) is regulated under 387 rate control upon previous agreement, meaning that a maximum number 388 of bits per unit of time is agreed per device subscription beforehand 389 and configured in the device. 391 The use of DoNAS is typically expected when a terminal in a power 392 saving state requires to do a short transmission and receive an 393 acknowledgment or short feedback from the network. Depending on the 394 size of buffered data to transmit, the UE might be instructed to 395 deploy the connected mode transmissions instead, limiting and 396 controlling the DoNAS transmissions to predefined thresholds and a 397 good resource optimization balance for the terminal and the network. 398 The support for mobility of DoNAS is present but produces additional 399 overhead. Additional details of DoNAS are given in the Appendix. 401 5.2.1. SCHC Entities Placing 403 In this scenario SCHC can be applied in the NAS protocol layer 404 instead of PDCP. The same principles than for user plane 405 transmissions applies here as well. The main difference is the 406 physical placing of the SCHC entities in the network side as the 407 C-SGN (placed in the core network) is the terminating node for NAS 408 instead of the eNB. 410 +--------+ +--------+--------+ + +--------+ 411 | IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ | 412 | Non-IP | | | | Non-IP | Non-IP | | | Non-IP | 413 +--------+ | | +-----------------+ | +--------+ 414 | NAS +-----------------------+ NAS |GTP|C/U +-----+GTP|C/U | 415 |(SCHC) | | | | (SCHC) | | | | | 416 +--------+ | +-----------+ | +-----------------+ | +--------+ 417 | RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | | 418 +--------+ | +-----------+ | +--------+ UDP +-----+ UDP | 419 | PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | | 420 +--------+ | +-----------+ | +-----------------+ | +--------+ 421 | RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP | 422 +--------+ | +-----------+ | +-----------------+ | +--------+ 423 | MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 | 424 +--------+ | +-----------+ | +-----------------+ | +--------+ 425 | PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY | 426 +--------+ +-----+-----+ +--------+--------+ | +--------+ 427 C-Uu/ S1-lite SGi 428 CIOT/ LTE-Uu C-BS/eNB C-SGN PGW 429 LTE eMTC 430 UE 432 *PDCP is bypassed until AS security is activated [TGPP36300]. 434 Figure 4 436 5.3. Parameters for Static Context Header Compression (SCHC) 437 5.3.1. SCHC Context initialization 439 RRC (Radio Resource Control) protocol is the main tool used to 440 configure the operation parameters of the AS transmissions for 3GPP 441 technologies. RoHC operation is configured with this protocol and it 442 is to expect that SCHC will be configured and the static context 443 distributed in similar fashion for these scenarios. 445 5.3.2. SCHC Rules 447 The number of rules in a context are defined by the network operator 448 in these scenarios. For this, the operator must be aware of the type 449 of IP traffic that the device will carry out. This means that the 450 operator might provision sets of rules compatible with the use case 451 of the device. For devices acting as gateways of other devices 452 several rules that match the diversity of devices and protocols used 453 by the devices associated to the gateway. Meanwhile than simpler 454 devices (for example an electricity meter) may have a predetermined 455 set of protocols and parameters fixed. Additionally, the deployment 456 of IPV4 addresses in addition to IPV6 may force to provision separate 457 rules to deal with each of the cases. 459 5.3.3. Rule ID 461 For these transmission scenarios in NB-IoT, a reasonable assumption 462 of 9 bytes of radio protocol overhead can be expected. PDCP 5 bytes 463 due to header and integrity protection, and 4 bytes of RLC and MAC. 464 The minimum physical Transport Block (TB) that can withhold this 465 overhead value according to 3GPP Release 15 specifications are: 88, 466 104, 120 and 144 bits. If it is wished to optimize the number of 467 transmissions of a very small application packet so that in some 468 cases can be transmitted using only one physical layer transmission, 469 then the SCHC overhead should not exceed the available number of bits 470 of the smallest utile physical TB available. The packets handled by 471 3GPP networks are byte-aligned, and therefore the minimum payload 472 possible (including padding) is 8 bits. Therefore in order to 473 utilize the smallest TB the maximum SCHC is 8 bits. This must 474 include the Compression Residue in addition to the Rule ID. In the 475 other hand, it is possible that more complex NB-IoT devices (such as 476 a capillarity gateway) might require additional bits to handle the 477 variety and multiple parameters the of higher layer protocols 478 deployed. In that sense, the operator may want to have flexibility 479 on the number and type of rules supported by each device 480 independently, and consequently a configurable value is preferred for 481 these scenarios. The configuration may be set as part of the 482 operation profile agreed together with the context distribution. The 483 Rule Id field size may range for example from 2 bits resulting in 4 484 rules to a 8 bits value that would yield up to 256 rules which can be 485 used together with the operators and seems quite a reasonable maximum 486 limit even for a device acting as a NAT. More bits could be 487 configured, but it should take in account the byte-alignment of the 488 expected Compression Residue too. In the minimum TB size case, 2 489 bits size of Rule Id leave only 6 bits available for Compression 490 Residue. 492 5.3.4. SCHC MAX_PACKET_SIZE 494 The Access Stratum can handle the fragmentation of SCHC packets if 495 needed including reliability. Hence the packet size is limited by 496 the MTU possible to be handled by the AS radio protocols that 497 corresponds to 1600 bytes for 3GPP Release 15. 499 5.3.5. Fragmentation 501 For these scenarios the SCHC fragmentation functions are recommend to 502 be disabled. The RLC layer of NB-IoT can segment packets in suitable 503 units that fit the selected transport blocks for transmissions of the 504 physical layer. The selection of the blocks is done according to the 505 input of the link adaptation function in the MAC layer and the 506 quantity of data in the buffer. The link adaptation layer may 507 produce different results at each Time Transmission Interval (TTI) 508 resulting in varying physical transport blocks that depends of the 509 network load, interference and number of bits to be transmitted and 510 QoS. Even if setting a value that allows the construction of data 511 units following SCHC tiles principle, the protocol overhead may be 512 greater or equal than allowing the AS radio protocols to take care of 513 the fragmentation natively. 515 5.3.5.1. Fragmentation in Transparent Mode 517 If RLC is configured to operate in Transparent Mode, there could be a 518 case to activate a fragmentation function together with a light 519 reliability function such as the ACK-Always mode. In practice , it 520 is very rare to transmit user plane data using this configuration and 521 it is mainly targeting control plane transmissions. In those cases 522 the reliability is normally ensured by MAC based mechanisms, such as 523 repetitions or automatic retransmissions, and additional reliability 524 might only generate protocol overhead. 526 In future operations, it could be devised the utilization of SCHC to 527 reduce radio network protocols overhead and support the reliability 528 of the transmissions, and targeting small data with the fewer 529 possible transmissions. This could be realized by using fixed or 530 limited set of transport blocks compatible with the tiling SCHC 531 fragmentation handling. 533 6. Non-IP based Data Transmission 535 The Non-IP Data Delivery (NIDD) services of 3GPP enable the 536 possibility of transmitting SCHC packets compressed by the 537 application layer. The packets can be delivered by means of IP- 538 tunnels to the 3GPP network or using SCEF functions (i.e., API 539 calls). In both cases the packet IP is not understood by the 3GPP 540 network since it is already compressed and the network does not has 541 information of the context used for compression. Therefore the 542 network will treat the packet as a Non-IP traffic and deliver it to 543 the UE without any other stack element, directly under the L2. 545 6.1. SCHC Entities Placing 547 In the two scenarios using NIDD, SCHC entities are located almost in 548 top of the stack. In the terminal, it may be implemented by a 549 application utilizing the NB-IoT connectivity services. In the 550 network side, the SCHC entities are located in the Application Server 551 (AS). The IP tunneling scenario requires that the Application Server 552 sends the compressed packet over an IP connection that is terminated 553 by the 3GPP core network. If instead the SCEF services are used, 554 then it is possible to utilize a API call to transfer the SCHC 555 packets between the core network and the AS, also an IP tunnel could 556 be established by the AS, if negotiated with the SCEF. 558 +---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+ 559 | SCHC | XXX XXX | SCHC | 560 |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)| 561 +---------+ XX +----+ XX | | +--------+ 562 | | XX |SCEF+-------+ | | | 563 | | XXX 3GPP RAN & +----+ XXX +---+ UDP | 564 | | XXX CORE NETWORK XXX | | | 565 | L2 +---+XX +------------+ | +--------+ 566 | | XX |IP TUNNELING+--+ | | 567 | | XXX +------------+ +---+ IP | 568 +---------+ XXXX XXXX | +--------+ 569 | PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY | 570 +---------+ +--------+ 571 UE AS 573 Figure 5: SCHC entities placed when using Non-IP Delivery (NIDD) 574 3GPP Sevices 576 6.2. Parameters for Static Context Header Compression 577 6.2.1. SCHC Context initialization 579 The static context is handled in the application layer level, 580 consequently the contexts are required to be distributed according to 581 the applications own capabilities, perhaps utilizing IP data 582 transmissions up to context initialization. Also the same IP 583 tunneling or SCEF services used later for the SCHC packets transport 584 may be used by the applications in both ends to deliver the static 585 contexts to be used. 587 6.2.2. SCHC Rules 589 Even when the transmissions content are not visible for the 3GPP 590 network, the same limitations than for IP based data transmissions 591 applies in these scenarios in terms of aiming to use the minimum 592 number of transmission and minimize the protocol overhead. 594 6.2.3. Rule ID 596 Similarly to the case of IP transmissions, the Rule ID size can be 597 dynamically set prior the context delivery. For example negotiated 598 between the applications when choosing a profile according to the 599 type of traffic and type of application deployed. Same 600 considerations related to the transport block size and performance 601 mentioned for the IP type of traffic has to be follow when choosing a 602 size value for the Rule ID field. 604 6.2.4. SCHC MAX_PACKET_SIZE 606 In these scenarios the maximum recommended MTU size that applies is 607 1358 Bytes, since the SCHC packets (and fragments) are traversing the 608 whole 3GPP network infrastructure (core and radio), and not only the 609 radio as the IP transmissions case. 611 6.3. Fragmentation 613 In principle the fragmentation function should be activated for 614 packets greater than 1358 Bytes. Since the 3GPP reliability 615 functions take great deal care of it, for simple point to point 616 connections may be enough a NO-ACK mode. Nevertheless additional 617 considerations for more complex cases are mentioned in the next 618 subsection to be taken in account. 620 6.3.1. Fragmentation modes 622 Depending of the QoS that has been assigned to the packets, it is 623 possible that packets are lost before they arrive to 3GPP radio 624 network transmission, for example in between the links of a 625 capillarity gateway, or due to buffer overflow handling in a backhaul 626 connection. In consequence, it is possible to secure additional 627 reliability on the packets transmitted with a small trade-off on 628 additional transmissions to signal the packets arrival indication 629 end-to-end if no transport protocol takes care of retransmission. To 630 achieve this, the packets fragmentation is activated with the ACK-on- 631 Error mode enabled. In some cases, it is even desirable to keep 632 track of all the SCHC packets delivered, in that case, the 633 fragmentation function could be active for all packets transmitted by 634 the applications (SCHC MAX_PACKET_SIZE == 1 Byte) and the ACK-on- 635 Error mode. In the NAS stratum, the use of only fragmentation when a 636 non-IP packet is transmitted is possible if this packet is considered 637 as a SCHC packet and is identifyed using the RuleID for non- 638 compressing packets as {RFC8724} allows it, depending on the 639 application an ACK-onError mode may be used. 641 6.3.2. Fragmentation Parameters 643 The Fragmentation Rule ID is given when choosing the profile 644 according to the fragmentation mode, 1 bit can be used to recognize 645 each mode. 647 To adapt SCHC to the NB-IoT constraints, two configuration are 648 proposed to fill the best the transfer block (TB). The Header size 649 needs to be multiple of 4 and the Tiles can keep a fix value of 4 or 650 8 bits to avoid the need of padding. 652 * 8 bits-Header_size configuration, with the size of the header 653 fields as follow: Rule ID 3 bits, DTag 1 bit, FCN 3 bits, W 1 654 bits. This configuration may ne used with TB less than 300 bits. 656 * 16 bits-Header_size configuration, with the size of the header 657 fields as follow: Rules ID 8 - 10 bits, DTag 1 or 2 bits, FCN 3 658 bits, W 2 or 3 bits. This configuration may be used with TB above 659 300 bits. 661 The IoT devices communicates with small data transfer and have a 662 battery life of 10 years. To minise the power consumption these 663 devices use the Power Save Mode and the Idle Mode DRX which govern 664 how often the device wakes up, stays up and are reachable. The 665 Table 10.5.163a in {3GPP-TS_24.088} specifies a range for the radio 666 timers as N to 3N in increments of one where the units of N can be 1 667 hour or 10 hours. To adapt SCHC to the NB-IoT activities, the 668 Innactivity Timer may be above 1h or 10h and the Retransmission Timer 669 may be below than 1h or 10h. 671 7. Padding 673 NB-IoT and 3GPP wireless access, in general, assumes byte aligned 674 payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits 675 and the treatment of padding should use this value accordingly. 677 8. Security considerations 679 3GPP access security is specified in (TGPP33203). 681 9. 3GPP References 683 * [TGPP23720] 3GPP, "TR 23.720 v13.0.0 - Study on architecture 684 enhancements for Cellular Internet of Things", 2016. 686 * [TGPP33203] 3GPP, "TS 33.203 v13.1.0 - 3G security; Access 687 security for IP-based services", 2016. 689 * [TGPP36321] 3GPP, "TS 36.321 v13.2.0 - Evolved Universal 690 Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) 691 protocol specification", 2016 693 * [TGPP36323] 3GPP, "TS 36.323 v13.2.0 - Evolved Universal 694 Terrestrial Radio Access (E-UTRA); Packet Data Convergence 695 Protocol (PDCP) specification", 2016. 697 * [TGPP36331] 3GPP, "TS 36.331 v13.2.0 - Evolved Universal 698 Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); 699 Protocol specification", 2016. 701 * [TGPP36300] 3GPP, "TS 36.300 v15.1.0 - Evolved Universal 702 Terrestrial Radio Access (E-UTRA) and Evolved Universal 703 Terrestrial Radio Access Network (E-UTRAN); Overall description; 704 Stage 2", 2018 706 * [TGPP24301] 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS) 707 protocol for Evolved Packet System (EPS); Stage 3", 2018 709 * [TGPP24088] 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface 710 Layer 3 specification;Core network protocols; Stage 3", 2015. 712 10. Appendix 714 10.1. NB-IoT User Plane protocol architecture 716 10.1.1. Packet Data Convergence Protocol (PDCP) 718 Each of the Radio Bearers (RB) are associated with one PDCP entity. 719 And a PDCP entity is associated with one or two RLC entities 720 depending of the unidirectional or bi-directional characteristics of 721 the RB and RLC mode used. A PDCP entity is associated either control 722 plane or user plane which independent configuration and functions. 723 The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. 724 The main services and functions of the PDCP sublayer for NB-IoT for 725 the user plane include: 727 * Header compression and decompression by means of ROHC (Robust 728 Header Compression) 730 * Transfer of user and control data to higher and lower layers 732 * Duplicate detection of lower layer SDUs when re-establishing 733 connection (when RLC with Acknowledge Mode in use for User Plane 734 only) 736 * Ciphering and deciphering 738 * Timer-based SDU discard in uplink 740 10.1.2. Radio Link Protocol (RLC) 742 RLC is a layer-2 protocol that operates between the UE and the base 743 station (eNB). It supports the packet delivery from higher layers to 744 MAC creating packets that are transmitted over the air optimizing the 745 Transport Block utilization. RLC flow of data packets is 746 unidirectional and it is composed of a transmitter located in the 747 transmission device and a receiver located in the destination device. 748 Therefore to configure bi-directional flows, two set of entities, one 749 in each direction (downlink and uplink) must be configured and they 750 are effectively peered to each other. The peering allows the 751 transmission of control packets (ex., status reports) between 752 entities. RLC can be configured for data transfer in one of the 753 following modes: 755 * Transparent Mode (TM). In this mode RLC do not segment or 756 concatenate SDUs from higher layers and do not include any header 757 to the payload. When acting as a transmitter, RLC receives SDUs 758 from upper layers and transmit directly to its flow RLC receiver 759 via lower layers. Similarly, an TM RLC receiver would only 760 deliver without additional processing the packets to higher layers 761 upon reception. 763 * Unacknowledged Mode (UM). This mode provides support for 764 segmentation and concatenation of payload. The size of the RLC 765 packet depends of the indication given at a particular 766 transmission opportunity by the lower layer (MAC) and are octets 767 aligned. The packet delivery to the receiver do not include 768 support for reliability and the lost of a segment from a packet 769 means a whole packet loss. Also in case of lower layer 770 retransmissions there is no support for re-segmentation in case of 771 change of the radio conditions triggering the selection of a 772 smaller transport block. Additionally it provides PDU duplication 773 detection and discard, reordering of out of sequence and loss 774 detection. 776 * Acknowledged Mode (AM). Additional to the same functions 777 supported from UM, this mode also adds a moving windows based 778 reliability service on top of the lower layer services. It also 779 provides support for re-segmentation and it requires bidirectional 780 communication to exchange acknowledgment reports called RLC Status 781 Report and trigger retransmissions is needed. Protocol error 782 detection is also supported by this mode. The mode uses depends 783 of the operator configuration for the type of data to be 784 transmitted. For example, data transmissions supporting mobility 785 or requiring high reliability would be most likely configured 786 using AM, meanwhile streaming and real time data would be map to a 787 UM configuration. 789 10.1.3. Medium Access Control (MAC) 791 MAC provides a mapping between the higher layers abstraction called 792 Logical Channels comprised by the previously described protocols to 793 the Physical layer channels (transport channels). Additionally, MAC 794 may multiplex packets from different Logical Channels and prioritize 795 what to fit into one Transport Block if there is data and space 796 available to maximize the efficiency of data transmission. MAC also 797 provides error correction and reliability support by means of HARQ, 798 transport format selection and scheduling information reporting from 799 the terminal to the network. MAC also adds the necessary padding and 800 piggyback control elements when possible additional to the higher 801 layers data. 803 804 +---+ +---+ +------+ 805 Application |AP1| |AP1| | AP2 | 806 (IP/non-IP) |PDU| |PDU| | PDU | 807 +---+ +---+ +------+ 808 | | | | | | 809 PDCP +--------+ +--------+ +-----------+ 810 |PDCP|AP1| |PDCP|AP1| |PDCP| AP2 | 811 |Head|PDU| |Head|PDU| |Head| PDU | 812 +--------+ +--------+ +--------+--\ 813 | | | | | | | | |\ `----\ 814 +---------------------------+ | |(1)| `-----\(2)'-\ 815 RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+ 816 |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2| 817 +-------------|-------------+ |Head|Head|PDU| |Head|PDU| 818 | | | | | +---------|---+ +--------+ 819 | | | LCID1 | | / / / / / 820 / / / _/ _// _/ _/ / LCID2 / 821 | | | | | / _/ _/ / ___/ 822 | | | | || | | / / 823 +------------------------------------------+ +-----------+---+ 824 MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad| 825 |Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din| 826 |der|der|der | |der|der | |der|der | | |der|der| |g | 827 +------------------------------------------+ +-----------+---+ 828 TB1 TB2 830 Figure 6: Example of User Plane packet encapsulation for two 831 transport blocks 833 10.2. NB-IoT Data over NAS (DoNAS) 835 The AS protocol stack used by DoNAS is somehow special. Since the 836 security associations are not established yet in the radio network, 837 to reduce the protocol overhead, PDCP (Packet Data Convergence 838 Protocol) is bypassed until AS security is activated. RLC (Radio 839 Link Control protocol) is configured by default in AM mode, but 840 depending of the features supported by the network and the terminal 841 it may be configured in other modes by the network operator. For 842 example, the transparent mode does not add any header or does not 843 process the payload in any way reducing the overhead, but the MTU 844 would be limited by the transport block used to transmit the data 845 which is couple of thousand of bits maximum. If UM (only Release 15 846 compatible terminals) is used, the RLC mechanisms of reliability is 847 disabled and only the reliability provided by the MAC layer by Hybrid 848 Automatic Repeat reQuest (HARQ) is available. In this case, the 849 protocol overhead might be smaller than for the AM case because the 850 lack of status reporting but with the same support for segmentation 851 up to 16000 Bytes. NAS packet are encapsulated within a RRC (Radio 852 Resource Control)[TGPP36331] message. 854 Depending of the data type indication signaled (IP or non-IP data), 855 the network allocates an IP address or just establish a direct 856 forwarding path. DoNAS is regulated under rate control upon previous 857 agreement, meaning that a maximum number of bits per unit of time is 858 agreed per device subscription beforehand and configured in the 859 device. The use of DoNAS is typically expected when a terminal in a 860 power saving state requires to do a short transmission and receive an 861 acknowledgment or short feedback from the network. Depending of the 862 size of buffered data to transmit, the UE might be instructed to 863 deploy the connected mode transmissions instead, limiting and 864 controlling the DoNAS transmissions to predefined thresholds and a 865 good resource optimization balance for the terminal and the network. 866 The support for mobility of DoNAS is present but produces additional 867 overhead. 869 +--------+ +--------+ +--------+ 870 | | | | | | +-----------------+ 871 | UE | | C-BS | | C-SGN | |Roaming Scenarios| 872 +----|---+ +--------+ +--------+ | +--------+ | 873 | | | | | | | 874 +----------------|------------|+ | | P-GW | | 875 | Attach | | +--------+ | 876 +------------------------------+ | | | 877 | | | | | | 878 +------|------------|--------+ | | | | 879 |RRC Connection Establishment| | | | | 880 |with NAS PDU transmission | | | | | 881 |& Ack Rsp | | | | | 882 +----------------------------+ | | | | 883 | | | | | | 884 | |Initial UE | | | | 885 | |message | | | | 886 | |----------->| | | | 887 | | | | | | 888 | | +---------------------+| | | 889 | | |Checks Integrity || | | 890 | | |protection, decrypts || | | 891 | | |data || | | 892 | | +---------------------+| | | 893 | | | Small data packet | 894 | | |-------------------------------> 895 | | | Small data packet | 896 | | |<------------------------------- 897 | | +----------|---------+ | | | 898 | | Integrity protection,| | | | 899 | | encrypts data | | | | 900 | | +--------------------+ | | | 901 | | | | | | 902 | |Downlink NAS| | | | 903 | |message | | | | 904 | |<-----------| | | | 905 +-----------------------+ | | | | 906 |Small Data Delivery, | | | | | 907 |RRC connection release | | | | | 908 +-----------------------+ | | | | 909 | | 910 | | 911 +-----------------+ 913 Figure 7: DoNAS transmission sequence from an Uplink initiated access 914 +---+ +---+ +---+ +----+ 915 Application |AP1| |AP1| |AP2| |AP2 | 916 (IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU | 917 +---+ +---+ +---+ +----+ 918 | |/ / | \ | | 919 NAS /RRC +--------+---|---+----+ +---------+ 920 |NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 | 921 |RRC |PDU|PDU|PDU|RRC | |RRC |PDU | 922 +--------+-|-+---+----+ +---------| 923 | |\ | | | 924 |<--Max. 1600 bytes-->|__ |_ | 925 | | \__ \___ \_ \_ 926 | | \ \ \__ \_ 927 +---------------|+-----|----------+ \ \ 928 RLC |RLC | NAS/RRC ||RLC | NAS/RRC | +----|-------+ 929 |Head| PDU(1/2)||Head | PDU (2/2)| |RLC |NAS/RRC| 930 +---------------++----------------+ |Head|PDU | 931 | | | \ | +------------+ 932 | | LCID1 | \ | | / 933 | | | \ \ | | 934 | | | \ \ | | 935 | | | \ \ \ | 936 +----+----+----------++-----|----+---------++----+---------|---+ 937 MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| 938 |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | 939 +----+----+----------++-----+----+---------++----+---------+---+ 940 TB1 TB2 TB3 942 Figure 8: Example of User Plane packet encapsulation for Data 943 over NAS 945 11. Informative References 947 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 948 Header Compression (ROHC) Framework", RFC 5795, 949 DOI 10.17487/RFC5795, March 2010, 950 . 952 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 953 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 954 . 956 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 957 Zúñiga, "SCHC: Generic Framework for Static Context Header 958 Compression and Fragmentation", RFC 8724, 959 DOI 10.17487/RFC8724, April 2020, 960 . 962 Authors' Addresses 964 Edgar Ramos 965 Ericsson 966 Hirsalantie 11 967 FI- 02420 Jorvas, Kirkkonummi 968 Finland 970 Email: edgar.ramos@ericsson.com 972 Ana Minaburo 973 Acklio 974 1137A Avenue des Champs Blancs 975 35510 Cesson-Sevigne Cedex 976 France 978 Email: ana@ackl.io