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