idnits 2.17.1 draft-minaburo-lpwan-nbiot-hc-01.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 591: '... 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 (September 04, 2018) is 2032 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'TGPP24301' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'TGPP36300' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'TGPP36321' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'TGPP36323' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'TGPP36331' is defined on line 674, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lpwan-ipv6-static-context-hc-16 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: March 8, 2019 Ericsson 6 S. Shanmugalingam 7 Acklio 8 September 04, 2018 10 LPWAN Static Context Header Compression (SCHC) over NB-IoT 11 draft-minaburo-lpwan-nbiot-hc-01 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 March 8, 2019. 40 Copyright Notice 42 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Data Transmission . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Data Transmission over User Plane . . . . . . . . . . . . 6 62 3.2.1. Packet Data Convergence Protocol (PDCP) . . . . . . . 7 63 3.2.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . . 7 64 3.2.3. Medium Access Control (MAC) . . . . . . . . . . . . . 8 65 3.3. Data Over Control Plane . . . . . . . . . . . . . . . . . 9 66 3.4. SCHC entities . . . . . . . . . . . . . . . . . . . . . . 13 67 4. Static Context Header Compression . . . . . . . . . . . . . . 13 68 4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.2. Packet processing . . . . . . . . . . . . . . . . . . . . 13 70 4.3. SCHC Context . . . . . . . . . . . . . . . . . . . . . . 13 71 5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. Fragmentation modes . . . . . . . . . . . . . . . . . . . 14 73 5.2. Fragmentation Parameters . . . . . . . . . . . . . . . . 14 74 6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 7. Security considerations . . . . . . . . . . . . . . . . . . . 14 76 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8.1. NB-IoT example with mobility . . . . . . . . . . . . . . 15 78 9. Informative References . . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 The Static Context Header Compression (SCHC) 84 [I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression 85 scheme and fragmentation functionality, both specially tailored for 86 Low Power Wide Area Networks (LPWAN) networks defined in 87 [I-D.ietf-lpwan-overview]. 89 Header compression is needed to efficiently bring Internet 90 connectivity to the node within an NB-IoT network. SCHC uses an 91 static context to performs header compression with specific 92 parameters that need to be adapted into the NB-IoT wireless access. 93 This document assumes functionality for NB-IoT of 3GPP release 15 94 otherwise other versions functionality is explicitly mentioned in the 95 text. 97 This document describes the use of SCHC and its parameterizing over 98 the NB-IoT wireless access. 100 2. Terminology 102 This document will follow the terms defined in 103 [I-D.ietf-lpwan-ipv6-static-context-hc], in 104 [I-D.ietf-lpwan-overview], and the TGPP23720. 106 o CIoT. Cellular IoT 108 o C-SGN. CIoT Serving Gateway Node 110 o UE. User Equipment 112 o eNB. Node B. Base Station that controls the UE 114 o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE 115 systems. 117 o EUTRAN. Evolved Universal Terrestrial Radio Access Network. 118 Radio network from LTE based systems. 120 o MME. Mobility Management Entity. Handle mobility of the UE 122 o NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology 123 based in LTE architecture but with additional optmization for IoT 124 and using a Narrow Band spectrum frequency. 126 o SGW. Serving Gateway. Routes and forwards the user data packets 127 through the access network 129 o HSS. Home Subscriber Server. It is a database that performs 130 mobility management 132 o PGW. Packet Data Node Gateway. Interface between the internal 133 with the external network 135 o PDU. Protocol Data Unit. Data packets including headers that are 136 transmitted between entities through a protocol. 138 o SDU. Service Data Unit. Data packets (PDUs) from higher layers 139 protocols used by lower layer protocols as payload of their own 140 PDUs that has not yet been encapsulated. 142 o IWK-SCEF. InterWorking Service Capabilities Exposure Function. 143 Used in roaming scenarios and serves for interconnection with the 144 SCEF of the Home PLMN and is located in the Visited PLMN 146 o SCEF. Service Capability Exposure Function. EPC node for 147 exposure of 3GPP network service capabilities to 3rd party 148 applications. 150 3. Architecture 152 ## NB-IoT entities 154 +--+ 155 |UE| \ +------+ +------+ 156 +--+ \ | MME |------| HSS | 157 \ / +------+ +------+ 158 +--+ \+-----+ / | 159 |UE| ----| eNB |- | 160 +--+ /+-----+ \ | 161 / \ +--------+ 162 / \| | +------+ Service PDN 163 +--+ / | S-GW |----| P-GW |---- e.g. Internet 164 |UE| | | +------+ 165 +--+ +--------+ 167 Figure 1: 3GPP network architecture 169 The architecture for 3GPP LTE network has been reused for NB-IoT with 170 some optimizations and simplifications known as Cellular IoT (CIoT). 171 Considering the typical use cases for CIoT devices here are described 172 some of the additions to the LTE architecture specific for CIoT. 173 C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating 174 EPS entities in the control plane and user plane paths (for example, 175 MME + SGW + P-GW) and the external interfaces of the entities 176 supported. The C-SGN also supports at least some of the following 177 CIoT EPS Optimizations: * Control Plane CIoT EPS Optimization for 178 small data transmission. * User Plane CIoT EPS Optimization for 179 small data transmission. * Necessary security procedures for 180 efficient small data transmission. * SMS without combined attach for 181 NB-IoT only UEs. * Paging optimizations for coverage enhancements. 182 * Support for non-IP data transmission via SGi tunneling and/or SCEF. 183 * Support for Attach without PDN (Packet Data Network) connectivity. 185 Another node introduced in the CIOT architecture is the SCEF (Service 186 Capability Exposure Function) that provide means to securely expose 187 service and network capabilities to entities external to the network 188 operator. The northbound APIS are defined by OMA and OneM2M. The 189 main functions of a SCEF are: * Non-IP Data Delivery (NIDD) 190 established through the SCEF. * Monitoring and exposure of event 191 related to UE reachability, loss of connectivity, location reporting, 192 roaming status, communication failure and change of IMEI-IMSI 193 association. 195 +---------+ 196 | HSS | 197 +---------+ 198 / 199 +-----------+ /S6a 200 +--------+ | |/ 201 +----+ C-Uu | +----+ | T6i +--------+ T7 +----+ 202 |CIOT+--------+ eNB | S1 | +------+IWK-SCEF+----+SCEF| 203 |UE | |(NB-IoT)| | | +--------+ +----+ 204 +----+ +--------+ | | +------------+ 205 | C-SGN |SGd | SMS-GMSC/ | 206 | +------+ IWMSC/SMS | 207 +--------+ | | | router | 208 +----+ LTE-Uu | | | | +------------+ 209 |LTE | (eMTC) | eNB +---+ | S8 +---+ +------+ 210 |eMTC+---------+(eMTC) | S1| +------+PGW|SGi |Appli.| 211 | UE | +--------+ | | | +----+Server| 212 +----+ +-----------+ +---+ | (AS) | 213 +------+ 215 Figure 2: 3GPP optimized CIOT network architecture 217 3.1. Data Transmission 219 3GPP networks deals not only with data transmitted end-to-end but 220 also with in-band signaling that is used between the nodes and 221 functions to configure, control and monitor the system functions and 222 behaviors. The control data is handled using a Control Plane which 223 has an specific set of protocols, handling processes and entities. 224 In contrast the end-to-end or user data utilize a User Plane with 225 characteristics of its own separated from the Control Plane. The 226 handling and setup of the Control Plane and User Plane spans over the 227 whole 3GPP network and it has particular implications in the radio 228 network (i.e., EUTRAN) and in the packet core (ex., EPC). 230 For the CIOT cases, additionally to transmissions of data over User 231 Plane, 3GPP has specified optimizations for small data transmissions 232 that allows to transport user data (IP, Non-IP) within signaling on 233 the access network (Data transmission over Control Plane or Data Over 234 NAS). 236 The maximum recommended MTU size is 1358 Bytes. The radio network 237 protocols limits the packet sizes to be transmitted over the air 238 including radio protocol overhead to 1600 Octets. But the value is 239 reduced further to avoid fragmentation in the backbone of the network 240 due to the payload encryption size (multiple of 16) and handling of 241 the additional core transport overhead. 243 3.2. Data Transmission over User Plane 245 The User Plane utilizes the protocol stack of the Access Stratum (AS) 246 for data transfer. AS (Access Stratum) is the functional layer 247 responsible for transporting data over wireless connection and 248 managing radio resources. The user plane AS has support for features 249 such as reliability, segmentation and concatenation. The 250 transmissions of the AS utilize link adaptation, meaning that the 251 transport format utilized for the transmissions are optimized 252 according to the radio conditions, the number of bits to transmit and 253 the power and interference constrains. That means that the number of 254 bits transmitted over the air depends of the Modulation and Coding 255 Schemes (MCS) selected. The transmissions in the physical layer 256 happens at network synchronized intervals of times called TTI 257 (Transmission Time Interval). The transmission of a Transport Block 258 (TB) is completed during, at least, one TTI. Each Transport Block 259 has a different MCS and number of bits available to transmit. The 260 Transport Blocks characteristics are defined by the MAC technical 261 specification {TGPP36321}. The Access Stratum for User Plane is 262 comprised by Packet Data Convergence Protocol (PDCP) {TGPP36323}, 263 Radio Link Protocol (RLC){TGPP36322}, Medium Access Control protocol 264 (MAC){TGPP36321} and the Physical Layer {TGPP36201}. 266 +---------+ +---------+ | 267 |IP/non-IP+--------------------------------+IP/non-IP+->+ 268 +---------+ | +----------------+ | +---------+ | 269 | PDCP +-------+ PDCP | GTP|U +-------+ GTP-U |->+ 270 +---------+ | +----------------+ | +---------+ | 271 | RLC +-------+ RLC |UDP/IP +-------+ UDP/IP +->+ 272 +---------+ | +----------------+ | +---------+ | 273 | MAC +-------+ MAC | L2 +-------+ L2 +->+ 274 +---------+ | +----------------+ | +---------+ | 275 | PHY +-------+ PHY | PHY +-------+ PHY +->+ 276 +---------+ +----------------+ +---------+ | 277 C-Uu/ S1-U SGi 278 CIOT/ LTE+Uu C-BS/eNB C-SGN 279 LTE eMTC 280 UE 282 Figure 3: 3GPP CIOT radio protocol architecture for data over user 283 plane 285 3.2.1. Packet Data Convergence Protocol (PDCP) 287 Each of the Radio Bearers (RB) are associated with one PDCP entity. 288 And a PDCP entity is associated with one or two RLC entities 289 depending of the unidirectional or bi-directional characteristics of 290 the RB and RLC mode used. A PDCP entity is associated either control 291 plane or user plane which independent configuration and functions. 292 The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. 293 The main services and functions of the PDCP sublayer for NB-IoT for 294 the user plane include: * Header compression and decompression by 295 means of ROHC (Robust Header Compression) * Transfer of user and 296 control data to higher and lower layers * Duplicate detection of 297 lower layer SDUs when re-establishing connection (when RLC with 298 Acknowledge Mode in use for User Plane only) * Ciphering and 299 deciphering * Timer-based SDU discard in uplink 301 3.2.2. Radio Link Protocol (RLC) 303 RLC is a layer-2 protocol that operates between the UE and the base 304 station (eNB). It supports the packet delivery from higher layers to 305 MAC creating packets that are transmitted over the air optimizing the 306 Transport Block utilization. RLC flow of data packets is 307 unidirectional and it is composed of a transmitter located in the 308 transmission device and a receiver located in the destination device. 309 Therefore to configure bi-directional flows, two set of entities, one 310 in each direction (downlink and uplink) must be configured and they 311 are effectively peered to each other. The peering allows the 312 transmission of control packets (ex., status reports) between 313 entities. RLC can be configured for data transfer in one of the 314 following modes: * Transparent Mode (TM). In this mode RLC do not 315 segment or concatenate SDUs from higher layers and do not include any 316 header to the payload. When acting as a transmitter, RLC receives 317 SDUs from upper layers and transmit directly to its flow RLC receiver 318 via lower layers. Similarly, an TM RLC receiver would only deliver 319 without additional processing the packets to higher layers upon 320 reception. * Unacknowledged Mode (UM). This mode provides support 321 for segmentation and concatenation of payload. The size of the RLC 322 packet depends of the indication given at a particular transmission 323 opportunity by the lower layer (MAC) and are octets aligned. The 324 packet delivery to the receiver do not include support for 325 reliability and the lost of a segment from a packet means a whole 326 packet loss. Also in case of lower layer retransmissions there is no 327 support for re-segmentation in case of change of the radio conditions 328 triggring the selection of a smaller transport block. Additionally 329 it provides PDU duplication detection and discard, reordering of out 330 of sequence and loss detection. * Acknowledged Mode (AM). 331 Additional to the same functions supported from UM, this mode also 332 adds a moving windows based reliability service on top of the lower 333 layer services. It also provides support for re-segmentation and it 334 requires bidirectional communication to exchange acknowledgment 335 reports called RLC Status Report and trigger retransmissions is 336 needed. Protocol error detection is also supported by this mode. 337 The mode uses depends of the operator configuration for the type of 338 data to be transmitted. For example, data transmissions supporting 339 mobility or requiring high reliability would be most likely 340 configured using AM, meanwhile streaming and real time data would be 341 map to a UM configuration. 343 3.2.3. Medium Access Control (MAC) 345 MAC provides a mapping between the higher layers abstraction called 346 Logical Channels comprised by the previously described protocols to 347 the Physical layer channels (transport channels). Additionally, MAC 348 may multiplex packets from different Logical Channels and prioritize 349 what to fit into one Transport Block if there is data and space 350 available to maximize the efficiency of data transmission. MAC also 351 provides error correction and reliability support by means of HARQ, 352 transport format selection and scheduling information reporting from 353 the terminal to the network. MAC also adds the necessary padding and 354 piggyback control elements when possible additional to the higher 355 layers data. 357 358 +-----+ +---+ +---------+ 359 Application | AP1 | |AP1| | AP2 | 360 (IP/non-IP) | PDU | |PDU| | PDU | 361 +-----+ +---+ +---------+ 362 | | | | | | 363 PDCP +----------+ +--------+ +--------------+ 364 |PDCP| AP1 | |PDCP|AP1| |PDCP| AP2 | 365 |Head| PDU | |Head|PDU| |Head| PDU | 366 +----------+ +--------+ +---------+----\ 367 | | | | | | | | |\ \_____ 368 | | | | | | | | | \ \ 369 +----------------------------+ | | (1)| \_____(2) \ 370 RLC |RLC|PDCP| AP1 |RLC |PDCP|AP1| +--------------+ +----|----+ 371 |Head|Head|PDU |Head|Head|PDU| |RLC |PDCP| AP2| |RLC | AP2| 372 +--------------|-------------+ |Head|Head| PDU| |Head| PDU| 373 | | | | | +---------|----+ +---------+ 374 | | | LCID1 | | / / / | | 375 | | | | |/ / /LCID2| | 376 | | | | | | | | | 377 | | | | | | | | | 378 +----------------------------------------------+ +---------+------+ 379 M |MAC|RLC|PDCP| AP1 |RLC |PDCP|AP1|RLC |PDCP|AP2| |MAC |RLC | AP2|P| 380 A |Hea|Hea|Hea-| PDU |Hea-|Hea-|PDU|Hea-|Hea-|PDU| |Hea-|Hea-| PDU|a| 381 C |der|der| der| |der |der | |der |der |PDU| |der |der | |d| 382 +----------------------------------------------+ +--------------+-+ 383 TB1 TB2 385 Figure 4: Example of User Plane packet encapsulation for two 386 transport blocks 388 3.3. Data Over Control Plane 390 The Non-Access Stratum (NAS), conveys mainly control signaling 391 between the UE and the cellular network {TGPP24301}. NAS is 392 transported on top of the Access Stratum (AS) already presented in 393 the previous sections. 395 +---------+ +---------+---------+ | 396 |IP/non-IP|---|-----------------------|---|IP/non-IP|IP/non-IP|->| 397 +---------+ | | +---------+---------+ >| 398 | NAS |---|-----------------------|---| NAS | GTP-C/U |->| 399 +---------+ | +------+------+ | +---------+---------+ | 400 | RRC |---|----| RRC | S1-AP|----|---| S1-AP | | | 401 +---------+ | +------+------+ | +---------+ UDP |->| 402 | PDCP* |---|----| PDCP*| SCTP |----|---| SCTP | | | 403 +---------+ | +------+------+ | +---------+---------+ | 404 | RLC |---|----| RLC | IP |----|---| IP | IP |->| 405 +---------+ | +------+------+ | +---------+---------+ | 406 | MAC |---|----| MAC | L2 |----|---| L2 | L2 |->| 407 +---------+ | +------+------+ | +---------+---------+ | 408 | PHY |---|----| PHY | PHY |----|---| PHY | PHY |->| 409 +--------- +------+------+ +---------+---------+ | 410 C-Uu/ S1-lite SGi 411 CIOT/ LTE-Uu C-BS/eNB C-SGN 412 LTE eMTC 413 UE 415 *PDCP is bypassed until AS security is activated TGPP36300. 417 Figure 5: 3GPP CIOT radio protocol architecture for DoNAS 418 transmissions 420 NAS has been adapted to provide support for user plane data 421 transmissions to reduce the overhead when transmitting infrequent 422 small quantities of data. This is known as Data over NAS (DoNAS) or 423 Control Plane CIoT EPS optimization. In DoNAS the UE makes use of 424 the pre-established NAS security and piggyback uplink small data into 425 the initial NAS uplink message, and uses an additional NAS message to 426 receive downlink small data response. The data encryption from the 427 network side is performed by the C-SGN in a NAS PDU. The AS protocol 428 stack used by DoNAS is somehow special. Since the security 429 associations are not established yet in the radio network, to reduce 430 the protocol overhead, PDCP (Packet Data Convergence Protocol) is 431 bypassed until AS security is activated. RLC (Radio Link Control 432 protocol) is configured by default in AM mode, but depending of the 433 features supported by the network and the terminal it may be 434 configured in other modes by the network operator. For example, the 435 transparent mode does not add any header or does not process the 436 payload in any way reducing the overhead, but the MTU would be 437 limited by the transport block used to transmit the data which is 438 couple of thousand of bits maximum. If UM (only Release 15 439 compatible terminals) is used, the RLC mechanisms of reliability is 440 disabled and only the reliability provided by the MAC layer by Hybrid 441 Automatic Repeat reQuest (HARQ) is available. In this case, the 442 protocol overhead might be smaller than for the AM case because the 443 lack of status reporting but with the same support for segmentation 444 up to 16000 Bytes. NAS packet are encapsulated within a RRC (Radio 445 Resource Control){TGPP36331} message. 447 Depending of the data type indication signaled (IP or non-IP data), 448 the network allocates an IP address or just establish a direct 449 forwarding path. DoNAS is regulated under rate control upon previous 450 agreement, meaning that a maximum number of bits per unit of time is 451 agreed per device subscription beforehand and configured in the 452 device. The use of DoNAS is typically expected when a terminal in a 453 power saving state requires to do a short transmission and receive an 454 acknowledgment or short feedback from the network. Depending of the 455 size of buffered data to transmit, the UE might be instructed to 456 deploy the connected mode transmissions instead, limiting and 457 controlling the DoNAS transmissions to predefined thresholds and a 458 good resource optimization balance for the terminal and the network. 459 The support for mobility of DoNAS is present but produces additional 460 overhead. 462 +--------+ +--------+ +--------+ 463 | | | | | | +------------------+ 464 | UE | | C-BS | | C-SGN | | Roaming Scenarios| 465 +----|---+ +--------+ +--------+ | +--------+ | 466 | | | | | | | 467 +----------------|------------|+ | | P-GW | | 468 | Attach | | +--------+ | 469 +------------------------------+ | | | 470 | | | | | | 471 +------|------------|--------+ | | | | 472 |RRC Connection Establishment| | | | | 473 |with NAS PDU transmission | | | | | 474 |& Ack Rsp | | | | | 475 +----------------------------+ | | | | 476 | | | | | | 477 | |Initial UE | | | | 478 | |message | | | | 479 | |----------->| | | | 480 | | | | | | 481 | | +---------------------+| | | 482 | | |Checks Integrity || | | 483 | | |protection, decrypts || | | 484 | | |data || | | 485 | | +---------------------+| | | 486 | | | Small data packet | 487 | | |--------------------------------> 488 | | | Small data packet | 489 | | |<-------------------------------- 490 | | +----------|---------+ | | | 491 | | Integrity protection,| | | | 492 | | encrypts data | | | | 493 | | +--------------------+ | | | 494 | | | | | | 495 | |Downlink NAS| | | | 496 | |message | | | | 497 | |<-----------| | | | 498 +-----------------------+ | | | | 499 |Small Data Delivery, | | | | | 500 |RRC connection release | | | | | 501 +-----------------------+ | | | | 502 | | 503 | | 504 +------------------+ 506 Figure 6: DoNAS transmission sequence from an Uplink initiated access 508 3.4. SCHC entities 510 SCHC could be deployed differently depending of the placing of the 511 entities in the architecture. NB-IoT and in general the cellular 512 technologies interfaces are standardized by 3GPP. Therefore the 513 introduction of SCHC entities in the RAN (Radio Access Network) would 514 require support from both the network and terminal entities. If SCHC 515 entities are to be placed in RAN it would require to be added to be 516 specified as an option for the UE - Base Station/C-SGN interfaces. 517 Another option is to place the SCHC entities in the applications 518 layer, and the SCHC packets would be transmitted as non-IP packets. 519 The first option allows the deployment of IP for routing and 520 addressing as well. 522 4. Static Context Header Compression 524 TBD (Edgar) 526 4.1. SCHC Rules 528 TBD (Ana) * Depending of SCHC deployment case * End-2-end * Global 529 rules to fetch customized rules * Minimum rule set for applying 530 functions * Fragmentation, compression, NATing 532 o Size of rule id 534 o 1 fragment rule And at least one Rule ID may be reserved to the 535 case where no SCHC C/D nor SCHC fragmentation were possible. 537 4.2. Packet processing 539 (Ana) *Operation over top vs 3gpp entities how to recognize a schc 540 packet 542 4.3. SCHC Context 544 o NATing 546 o What protocols can be identified for compression depending of the 547 deployument 549 5. Fragmentation 551 The RLC layer of NB-IoT can segment packets in suitable units that 552 fits the selected transport blocks for transmissions of the physical 553 layer. The selection of the blocks is done according to the input of 554 the link adaptation function in the MAC layer and the quantity of 555 data in the buffer. The link adaptation layer may produce different 556 results at each Time Transmission Interval (TTI) for what is very 557 difficult to set a fragmentation value according to the transport 558 block that is selected for each transmission. Instead for NB-IoT 559 SCHC must take care of keeping the application packets with a 560 suitable size that do not exceed the MTU (1600 bytes). 562 5.1. Fragmentation modes 564 (Sothy) Look a the different options of reliability and see the 565 implications for NB-IoT for the different deployment modes 567 5.2. Fragmentation Parameters 569 (Edgar) Headers sizes Example for the end2end case and check what is 570 operator defined * Rule ID 572 o DTag 574 o FCN 576 o Retransmission Timer 578 o Inactivity Timer 580 o MAX_ACK_Retries 582 o MAX_ATTEMPS 584 o MIC (Ana) 586 TBD 588 6. Padding 590 NB-IoT and 3GPP wireless access in general assumes byte aligned 591 payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits 592 and the treatment of padding should use this value accordingly. 594 7. Security considerations 596 3GPP access security is specified in [TGPP33203]. 598 8. Appendix 600 ## NB-IoT with data over NAS 601 +---+ +---+ +----+ +--+ 602 Applications |AP1| |AP1| | AP2| |AP2| 603 (IP/non-IP) |PDU| |PDU| | PDU|~~~~~~~~~~~~~~~~~~~|PDU| 604 +---+ +---+ +----+ +---+ 605 | |/ / / | | 606 NAS /RRC +-------+---|-----+-----+ +--------+ 607 |NAS|AP1|AP1| AP2 |NAS/ | |NAS/|AP2| 608 |RRC|PDU|PDU| PDU |RRC | |RRC |PDU| 609 +---+---|---+-----+-----+ +--------| 610 | | \ | | | 611 |<----Max. 1600 bytes-->| |_ |_ 612 | | \ \ \ \ 613 | | --\ -\ \_ \_ 614 +-------------| +-----|----------+ \ \ 615 RLC |RLC |NAS/RRC| |RLC | NAS/RRC | +----|-------+ 616 |Head | PDU | |Head | PDU (2/2)| |RLC |NAS/RRC| 617 | | (1/2) | |Head | PDU (2/2)| |RLC |NAS/RRC| 618 +-------------+ +-----+----------+ |Head|PDU | 619 | | | \ \ +------------+ 620 | | LCID1 | \ \ | | 621 | | | \ \ | | 622 | | | \ \ \ | 623 | | | \ \ \ | 624 +-------------------+ +----|-----------------+ +----+---------|-+ 625 MAC |MAC |RLC | RLC | |MAC |RLC | RLC | |MAC | RLC |P| 626 |Head |Head |PAYLOAD| |Head|Head| PAYLOAD | |Head| PDU |a| 627 | | | | | | | | | | |d| 628 +-------------------+ +----------------------+ +----+---------+-+ 629 TB1 TB2 TB3 631 Figure 7: Example of User Plane packet encapsulation for Data over 632 NAS 634 8.1. NB-IoT example with mobility 636 ## LTE-M considerations 638 9. Informative References 640 [I-D.ietf-lpwan-ipv6-static-context-hc] 641 Minaburo, A., Toutain, L., Gomez, C., and D. Barthel, 642 "LPWAN Static Context Header Compression (SCHC) and 643 fragmentation for IPv6 and UDP", draft-ietf-lpwan-ipv6- 644 static-context-hc-16 (work in progress), June 2018. 646 [I-D.ietf-lpwan-overview] 647 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 648 overview-10 (work in progress), February 2018. 650 [TGPP24301] 651 "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS) protocol for 652 Evolved Packet System (EPS); Stage 3", n.d.. 654 [TGPP33203] 655 "TS 33.203 v13.1.0 - 3G security; Access security for IP- 656 based services", n.d.. 658 [TGPP36300] 659 "TS 36.300 v15.1.0 - Evolved Universal Terrestrial Radio 660 Access (E-UTRA) and Evolved Universal Terrestrial Radio 661 Access Network (E-UTRAN); Overall description; Stage 2", 662 n.d.. 664 [TGPP36321] 665 "TS 36.321 v13.2.0 - Evolved Universal Terrestrial Radio 666 Access (E-UTRA); Medium Access Control (MAC) protocol 667 specification", n.d.. 669 [TGPP36323] 670 "TS 36.323 v13.2.0 - Evolved Universal Terrestrial Radio 671 Access (E-UTRA); Packet Data Convergence Protocol (PDCP) 672 specification", n.d.. 674 [TGPP36331] 675 "TS 36.331 v13.2.0 - Evolved Universal Terrestrial Radio 676 Access (E-UTRA); Radio Resource Control (RRC); Protocol 677 specification", n.d.. 679 Authors' Addresses 681 Ana Minaburo 682 Acklio 683 2bis rue de la Chataigneraie 684 35510 Cesson-Sevigne Cedex 685 France 687 Email: ana@ackl.io 688 Edgar Ramos 689 Ericsson 690 Hirsalantie 11 691 02420 Jorvas 692 Finland 694 Email: edgar.ramos@ericsson.com 696 Sivasothy Shanmugalingam 697 Acklio 698 2bis rue de la Chataigneraie 699 35510 Cesson-Sevigne Cedex 700 France 702 Email: sothy@ackl.io