idnits 2.17.1 draft-farkas-5g-raw-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 March 2020) is 1499 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW J. Farkas, Ed. 3 Internet-Draft T. Dudda 4 Intended status: Informational A. Shapin 5 Expires: 10 September 2020 S. Sandberg 6 Ericsson 7 9 March 2020 9 5G - Ultra-Reliable Wireless Technology with Low Latency 10 draft-farkas-5g-raw-00 12 Abstract 14 This document describes the features of 5G that make it a wireless 15 technology providing ultra-reliability, high availability, and low 16 latency; and looks out to possibilities on the application of 5G 17 together with IETF Deterministic Networking (DetNet). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 10 September 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Provenance and Documents . . . . . . . . . . . . . . . . . . 2 54 3. General Characteristics . . . . . . . . . . . . . . . . . . . 4 55 4. Deployment and Spectrum . . . . . . . . . . . . . . . . . . . 5 56 5. Applicability to Deterministic Flows . . . . . . . . . . . . 6 57 5.1. System Architecture . . . . . . . . . . . . . . . . . . . 6 58 5.2. Overview of The Radio Protocol Stack . . . . . . . . . . 8 59 5.3. Radio (PHY) . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.4. Scheduling and QoS (MAC) . . . . . . . . . . . . . . . . 10 61 5.5. Time-Sensitive Networking (TSN) Integration . . . . . . . 12 62 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 66 10. Informative References . . . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 69 1. Introduction 71 5G is a highly predictable scheduled wireless technology. Equipped 72 with Ultra-Reliable Low-Latency Communication (URLLC) features, 5G 73 provides ultra reliability and high availability as well as low 74 latency for critical communications. That is, 5G is a Reliable 75 Available Wireless (RAW) technology. Its characteristics make 5G 76 perfectly suitable to be part of deterministic networks, e.g., 77 industrial automation networks. Furthermore, 5G already includes 78 features and capabilities for integration with deterministic wireline 79 technologies such as IEEE 802.1 Time-Sensitive Networking (TSN) 80 [IEEE802.1TSN] and IETF Deterministic Networking (DetNet) [RFC8655]. 82 2. Provenance and Documents 84 The 3rd Generation Partnership Project (3GPP) incorporates many 85 companies whose business is related to cellular network operation as 86 well as network equipment and device manufacturing. All generations 87 of 3GPP technologies provide scheduled wireless segments, primarily 88 in licensed spectrum which is beneficial for reliability and 89 availability. 91 In 2016, the 3GPP started to design New Radio (NR) technology 92 belonging to the fifth generation (5G) of cellular networks. NR has 93 been designed from the beginning to not only address enhanced Mobile 94 Broadband (eMBB) services for consumer devices such as smart phones 95 or tablets but is also tailored for future Internet of Things (IoT) 96 communication and connected cyber-physical systems. In addition to 97 eMBB, requirement categories have been defined on Massive Machine- 98 Type Communication (M-MTC) for a large number of connected devices/ 99 sensors, and Ultra-Reliable Low-Latency Communication (URLLC) for 100 connected control systems and critical communication as illustrated 101 in Figure 1. It is the URLLC capabilities that make 5G a great 102 candidate for reliable low-latency communication. With these three 103 corner stones, NR is a complete solution supporting the connectivity 104 needs of consumers, enterprises, and public sector for both wide area 105 and local area, e.g. indoor deployments. A general overview of NR 106 can be found in [TS38300]. 108 enhanced 109 Mobile Broadband 110 ^ 111 / \ 112 / \ 113 / \ 114 / \ 115 / 5G \ 116 / \ 117 / \ 118 / \ 119 +-----------------+ 120 Massive Ultra-Reliable 121 Machine-Type Low-Latency 122 Communication Communication 124 Figure 1: 5G Application Areas 126 As a result of releasing the first NR specification in 2018 (Release 127 15), it has been proven by many companies that NR is a URLLC-capable 128 technology and can deliver data packets at 10^-5 packet error rate 129 within 1ms latency budget [TR37910]. Those evaluations were 130 consolidated and forwarded to ITU to be included in the [IMT2020] 131 work. 133 In order to understand communication requirements for automation in 134 vertical domains, 3GPP studied different use cases [TR22804] and 135 released technical specification with reliability, availability and 136 latency demands for a variety of applications [TS22104]. 138 As an evolution of NR, multiple studies have been conducted in scope 139 of 3GPP Release 16 including the following two, focusing on radio 140 aspects: 142 1. Study on physical layer enhancements for NR ultra-reliable and 143 low latency communication (URLLC) [TR38824]. 145 2. Study on NR industrial Internet of Things (I-IoT) [TR38825]. 147 In addition, several enhancements have been done on system 148 architecture level which are reflected in System architecture for the 149 5G System (5GS) [TS23501]. 151 3. General Characteristics 153 The 5G Radio Access Network (5G RAN) with its NR interface includes 154 several features to achieve Quality of Service (QoS), such as a 155 guaranteeably low latency or tolerable packet error rates for 156 selected data flows. Determinism is achieved by centralized 157 admission control and scheduling of the wireless frequency resources, 158 which are typically licensed frequency bands assigned to a network 159 operator. 161 NR enables short transmission slots in a radio subframe, which 162 benefits low-latency applications. NR also introduces mini-slots, 163 where prioritized transmissions can be started without waiting for 164 slot boundaries, further reducing latency. As part of giving 165 priority and faster radio access to URLLC traffic, NR introduces 166 preemption where URLLC data transmission can preempt ongoing non- 167 URLLC transmissions. Additionally, NR applies very fast processing, 168 enabling retransmissions even within short latency bounds. 170 NR defines extra-robust transmission modes for increased reliability 171 both for data and control radio channels. Reliability is further 172 improved by various techniques, such as multi-antenna transmission, 173 the use of multiple frequency carriers in parallel and packet 174 duplication over independent radio links. NR also provides full 175 mobility support, which is an important reliability aspect not only 176 for devices that are moving, but also for devices located in a 177 changing environment. 179 Network slicing is seen as one of the key features for 5G, allowing 180 vertical industries to take advantage of 5G networks and services. 181 Network slicing is about transforming a Public Land Mobile Network 182 (PLMN) from a single network to a network where logical partitions 183 are created, with appropriate network isolation, resources, optimized 184 topology and specific configuration to serve various service 185 requirements. An operator can configure and manage the mobile 186 network to support various types of services enabled by 5G, for 187 example eMBB and URLLC, depending on the different customers' needs. 189 Exposure of capabilities of 5G Systems to the network or applications 190 outside the 3GPP domain have been added to Release 16 [TS23501]. Via 191 exposure interfaces, applications can access 5G capabilities, e.g., 192 communication service monitoring and network maintenance. 194 For several generations of mobile networks, 3GPP has considered how 195 the communication system should work on a global scale with billions 196 of users, taking into account resilience aspects, privacy regulation, 197 protection of data, encryption, access and core network security, as 198 well as interconnect. Security requirements evolve as demands on 199 trustworthiness increase. For example, this has led to the 200 introduction of enhanced privacy protection features in 5G. 5G also 201 employs strong security algorithms, encryption of traffic, protection 202 of signaling and protection of interfaces. 204 One particular strength of mobile networks is the authentication, 205 based on well-proven algorithms and tightly coupled with a global 206 identity management infrastructure. Since 3G, there is also mutual 207 authentication, allowing the network to authenticate the device and 208 the device to authenticate the network. Another strength is secure 209 solutions for storage and distribution of keys fulfilling regulatory 210 requirements and allowing international roaming. When connecting to 211 5G, the user meets the entire communication system, where security is 212 the result of standardization, product security, deployment, 213 operations and management as well as incident handling capabilities. 214 The mobile networks approach the entirety in a rather coordinated 215 fashion which is beneficial for security. 217 4. Deployment and Spectrum 219 The 5G system allows deployment in a vast spectrum range, addressing 220 use-cases in both wide-area as well as local networks. Furthermore, 221 5G can be configured for public and non-public access. 223 When it comes to spectrum, NR allows combining the merits of many 224 frequency bands, such as the high bandwidths in millimeter Waves 225 (mmW) for extreme capacity locally, as well as the broad coverage 226 when using mid- and low frequency bands to address wide-area 227 scenarios. URLLC is achievable in all these bands. Spectrum can be 228 either licensed, which means that the license holder is the only 229 authorized user of that spectrum range, or unlicensed, which means 230 that anyone who wants to use the spectrum can do so. 232 A prerequisite for critical communication is performance 233 predictability, which can be achieved by the full control of the 234 access to the spectrum, which 5G provides. Licensed spectrum 235 guarantees control over spectrum usage by the system, making it a 236 preferable option for critical communication. However, unlicensed 237 spectrum can provide an additional resource for scaling non-critical 238 communications. While NR is initially developed for usage of 239 licensed spectrum, the functionality to access also unlicensed 240 spectrum was introduced in 3GPP Release 16. 242 Licensed spectrum dedicated to mobile communications has been 243 allocated to mobile service providers, i.e. issued as longer-term 244 licenses by national administrations around the world. These 245 licenses have often been associated with coverage requirements and 246 issued across whole countries, or in large regions. Besides this, 247 configured as a non-public network (NPN) deployment, 5G can provide 248 network services also to a non-operator defined organization and its 249 premises such as a factory deployment. By this isolation, quality of 250 service requirements, as well as security requirements can be 251 achieved. An integration with a public network, if required, is also 252 possible. The non-public (local) network can thus be interconnected 253 with a public network, allowing devices to roam between the networks. 255 In an alternative model, some countries are now in the process of 256 allocating parts of the 5G spectrum for local use to industries. 257 These non-service providers then have a choice of applying for a 258 local license themselves and operating their own network or 259 cooperating with a public network operator or service provider. 261 5. Applicability to Deterministic Flows 263 5.1. System Architecture 265 The 5G system [TS23501] consists of the User Equipment (UE) at the 266 terminal side, and the Radio Access Network (RAN) with the gNB as 267 radio base station node, as well as the Core Network (CN). The core 268 network is based on a service-based architecture with the central 269 functions: Access and Mobility Management Function (AMF), Session 270 Management Function (SMF) and User Plane Function (UPF) as 271 illustrated in Figure 2. 273 The gNB's main responsibility is the radio resource management, 274 including admission control and scheduling, mobility control and 275 radio measurement handling. The AMF handles the UE's connection 276 status and security, while the SMF controls the UE's data sessions. 277 The UPF handles the user plane traffic. 279 The SMF can instantiate various Packet Data Unit (PDU) sessions for 280 the UE, each associated with a set of QoS flows, i.e., with different 281 QoS profiles. Segregation of those sessions is also possible, e.g., 282 resource isolation in the RAN and in the CN can be defined (slicing). 284 +----+ +---+ +---+ +---+ +---+ +---+ 285 |NSSF| |NEF| |NRF| |PCF| |UDM| |AF | 286 +--+-+ +-+-+ +-+-+ +-+-+ +-+-+ +-+-+ 287 | | | | | | 288 Nnssf| Nnef| Nnrf| Npcf| Nudm| Naf| 289 | | | | | | 290 ---+------+-+-----+-+------------+--+-----+-+--- 291 | | | | 292 Nausf| Nausf| Nsmf| | 293 | | | | 294 +--+-+ +-+-+ +-+-+ +-+-+ 295 |AUSF| |AMF| |SMF| |SCP| 296 +----+ +++-+ +-+-+ +---+ 297 / | | 298 / | | 299 / | | 300 N1 N2 N4 301 / | | 302 / | | 303 / | | 304 +--+-+ +--+--+ +--+---+ +----+ 305 | UE +---+(R)AN+--N3--+ UPF +--N6--+ DN | 306 +----+ +-----+ ++----++ +----+ 307 | | 308 +-N9-+ 310 Figure 2: 5G System Architecture 312 To allow UE mobility across cells/gNBs, handover mechanisms are 313 supported in NR. For an established connection, i.e., connected mode 314 mobility, a gNB can configure a UE to report measurements of received 315 signal strength and quality of its own and neighbouring cells, 316 periodically or event-based. Based on these measurement reports, the 317 gNB decides to handover a UE to another target cell/gNB. Before 318 triggering the handover, it is hand-shaked with the target gNB based 319 on network signalling. A handover command is then sent to the UE and 320 the UE switches its connection to the target cell/gNB. The Packet 321 Data Convergence Protocol (PDCP) of the UE can be configured to avoid 322 data loss in this procedure, i.e., handle retransmissions if needed. 323 Data forwarding is possible between source and target gNB as well. 324 To improve the mobility performance further, i.e., to avoid 325 connection failures, e.g., due to too-late handovers, the mechanism 326 of conditional handover is introduced in Release 16 specifications. 327 Therein a conditional handover command, defining a triggering point, 328 can be sent to the UE before UE enters a handover situation. A 329 further improvement introduced in Release 16 is the Dual Active 330 Protocol Stack (DAPS), where the UE maintains the connection to the 331 source cell while connecting to the target cell. This way, potential 332 interruptions in packet delivery can be avoided entirely. 334 5.2. Overview of The Radio Protocol Stack 336 The protocol architecture for NR consists of the L1 Physical layer 337 (PHY) and as part of the L2, the sublayers of Medium Access Control 338 (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol 339 (PDCP), as well as the Service Data Adaption Protocol (SDAP). 341 The PHY layer handles signal processing related actions, such as 342 encoding/decoding of data and control bits, modulation, antenna 343 precoding and mapping. 345 The MAC sub-layer handles multiplexing and priority handling of 346 logical channels (associated with QoS flows) to transport blocks for 347 PHY transmission, as well as scheduling information reporting and 348 error correction through Hybrid Automated Repeat Request (HARQ). 350 The RLC sublayer handles sequence numbering of higher layer packets, 351 retransmissions through Automated Repeat Request (ARQ), if 352 configured, as well as segmentation and reassembly and duplicate 353 detection. 355 The PDCP sublayer consists of functionalities for ciphering/ 356 deciphering, integrity protection/verification, re-ordering and in- 357 order delivery, duplication and duplicate handling for higher layer 358 packets, and acts as the anchor protocol to support handovers. 360 The SDAP sublayer provides services to map QoS flows, as established 361 by the 5G core network, to data radio bearers (associated with 362 logical channels), as used in the 5G RAN. 364 Additionally, in RAN, the Radio Resource Control (RRC) protocol, 365 handles the access control and configuration signalling for the 366 aforementioned protocol layers. RRC messages are considered L3 and 367 thus transmitted also via those radio protocol layers. 369 To provide low latency and high reliability for one transmission 370 link, i.e., to transport data (or control signaling) of one radio 371 bearer via one carrier, several features have been introduced on the 372 user plane protocols for PHY and L2, as explained in the following. 374 5.3. Radio (PHY) 376 NR is designed with native support of antenna arrays utilizing 377 benefits from beamforming, transmissions over multiple MIMO layers 378 and advanced receiver algorithms allowing effective interference 379 cancellation. Those antenna techniques are the basis for high signal 380 quality and effectiveness of spectral usage. Spatial diversity with 381 up to 4 MIMO layers in UL and up to 8 MIMO layers in DL is supported. 382 Together with spatial-domain multiplexing, antenna arrays can focus 383 power in desired direction to form beams. NR supports beam 384 management mechanisms to find the best suitable beam for UE initially 385 and when it is moving. In addition, gNBs can coordinate their 386 respective DL and UL transmissions over the backhaul network keeping 387 interference reasonably low, and even make transmissions or 388 receptions from multiple points (multi-TRP). Multi-TRP can be used 389 for repetition of data packet in time, in frequency or over multiple 390 MIMO layers which can improve reliability even further. 392 Any downlink transmission to a UE starts from resource allocation 393 signaling over the Physical Downlink Control Channel (PDCCH). If it 394 is successfully received, the UE will know about the scheduled 395 transmission and may receive data over the Physical Downlink Shared 396 Channel (PDSCH). If retransmission is required according to the HARQ 397 scheme, a signaling of negative acknowledgement (NACK) on the 398 Physical Uplink Control Channel (PUCCH) is involved and PDCCH 399 together with PDSCH transmissions (possibly with additional 400 redundancy bits) are transmitted and soft-combined with previously 401 received bits. Otherwise, if no valid control signaling for 402 scheduling data is received, nothing is transmitted on PUCCH 403 (discontinuous transmission - DTX),and the base station upon 404 detecting DTX will retransmit the initial data. 406 An uplink transmission normally starts from a Scheduling Request (SR) 407 - a signaling message from the UE to the base station sent via PUCCH. 408 Once the scheduler is informed about buffer data in UE, e.g., by SR, 409 the UE transmits a data packet on the Physical Uplink Shared Channel 410 (PUSCH). Pre-scheduling not relying on SR is also possible (see 411 following section). 413 Since transmission of data packets require usage of control and data 414 channels, there are several methods to maintain the needed 415 reliability. NR uses Low Density Parity Check (LDPC) codes for data 416 channels, Polar codes for PDCCH, as well as orthogonal sequences and 417 Polar codes for PUCCH. For ultra-reliability of data channels, very 418 robust (low spectral efficiency) Modulation and Coding Scheme (MCS) 419 tables are introduced containing very low (down to 1/20) LDPC code 420 rates using BPSK or QPSK. Also, PDCCH and PUCCH channels support 421 multiple code rates including very low ones for the channel 422 robustness. 424 A connected UE reports downlink (DL) quality to gNB by sending 425 Channel State Information (CSI) reports via PUCCH while uplink (UL) 426 quality is measured directly at gNB. For both uplink and downlink, 427 gNB selects the desired MCS number and signals it to the UE by 428 Downlink Control Information (DCI) via PDCCH channel. For URLLC 429 services, the UE can assist the gNB by advising that MCS targeting 430 10^-5 Block Error Rate (BLER) are used. Robust link adaptation 431 algorithms can maintain the needed level of reliability considering a 432 given latency bound. 434 Low latency on the physical layer is provided by short transmission 435 duration which is possible by using high Subcarrier Spacing (SCS) and 436 the allocation of only one or a few Orthogonal Frequency Division 437 Multiplexing (OFDM) symbols. For example, the shortest latency for 438 the worst case in DL can be 0.23ms and in UL can be 0.24ms according 439 to (section 5.7.1 in [TR37910]). Moreover, if the initial 440 transmission has failed, HARQ feedback can quickly be provided and an 441 HARQ retransmission is scheduled. 443 Dynamic multiplexing of data associated with different services is 444 highly desirable for efficient use of system resources and to 445 maximize system capacity. Assignment of resources for eMBB is 446 usually done with regular (longer) transmission slots, which can lead 447 to blocking of low latency services. To overcome the blocking, eMBB 448 resources can be pre-empted and re-assigned to URLLC services. In 449 this way, spectrally efficient assignments for eMBB can be ensured 450 while providing flexibility required to ensure a bounded latency for 451 URLLC services. In downlink, the gNB can notify the eMBB UE about 452 pre-emption after it has happened, while in uplink there are two pre- 453 emption mechanisms: special signaling to cancel eMBB transmission and 454 URLLC dynamic power boost to suppress eMBB transmission. 456 5.4. Scheduling and QoS (MAC) 458 One integral part of the 5G system is the Quality of Service (QoS) 459 framework [TS23501]. QoS flows are setup by the 5G system for 460 certain IP or Ethernet packet flows, so that packets of each flow 461 receive the same forwarding treatment, i.e., in scheduling and 462 admission control. QoS flows can for example be associated with 463 different priority level, packet delay budgets and tolerable packet 464 error rates. Since radio resources are centrally scheduled in NR, 465 the admission control function can ensure that only those QoS flows 466 are admitted for which QoS targets can be reached. 468 NR transmissions in both UL and DL are scheduled by the gNB 469 [TS38300]. This ensures radio resource efficiency, fairness in 470 resource usage of the users and enables differentiated treatment of 471 the data flows of the users according to the QoS targets of the 472 flows. Those QoS flows are handled as data radio bearers or logical 473 channels in NR RAN scheduling. 475 The gNB can dynamically assign DL and UL radio resources to users, 476 indicating the resources as DL assignments or UL grants via control 477 channel to the UE. Radio resources are defined as blocks of OFDM 478 symbols in spectral domain and time domain. Different lengths are 479 supported in time domain, i.e., (multiple) slot or mini-slot lengths. 480 Resources of multiple frequency carriers can be aggregated and 481 jointly scheduled to the UE. 483 Scheduling decisions are based, e.g., on channel quality measured on 484 reference signals and reported by the UE (cf. periodical CSI reports 485 for DL channel quality). The transmission reliability can be chosen 486 in the scheduling algorithm, i.e., by link adaptation where an 487 appropriate transmission format (e.g., robustness of modulation and 488 coding scheme, controlled UL power) is selected for the radio channel 489 condition of the UE. Retransmissions, based on HARQ feedback, are 490 also controlled by the scheduler. If needed to avoid HARQ round-trip 491 time delays, repeated transmissions can be also scheduled beforehand, 492 to the cost of reduced spectral efficiency. 494 In dynamic DL scheduling, transmission can be initiated immediately 495 when DL data becomes available in the gNB. However, for dynamic UL 496 scheduling, when data becomes available but no UL resources are 497 available yet, the UE indicates the need for UL resources to the gNB 498 via a (single bit) scheduling request message in the UL control 499 channel. When thereupon UL resources are scheduled to the UE, the UE 500 can transmit its data and may include a buffer status report, 501 indicating the exact amount of data per logical channel still left to 502 be sent. More UL resources may be scheduled accordingly. To avoid 503 the latency introduced in the scheduling request loop, UL radio 504 resources can also be pre-scheduled. 506 In particular for periodical traffic patterns, the pre-scheduling can 507 rely on the scheduling features DL Semi-Persistent Scheduling (SPS) 508 and UL Configured Grant (CG). With these features, periodically 509 recurring resources can be assigned in DL and UL. Multiple parallels 510 of those configurations are supported, in order to serve multiple 511 parallel traffic flows of the same UE. 513 To support QoS enforcement in the case of mixed traffic with 514 different QoS requirements, several features have recently been 515 introduced. This way, e.g., different periodical critical QoS flows 516 can be served together with best effort transmissions, by the same 517 UE. Among others, these features (partly Release 16) are: 1) UL 518 logical channel transmission restrictions allowing to map logical 519 channels of certain QoS only to intended UL resources of a certain 520 frequency carrier, slot-length, or CG configuration, and 2) intra-UE 521 pre-emption, allowing critical UL transmissions to pre-empt non- 522 critical transmissions. 524 When multiple frequency carriers are aggregated, duplicate parallel 525 transmissions can be employed (beside repeated transmissions on one 526 carrier). This is possible in the Carrier Aggregation (CA) 527 architecture where those carriers originate from the same gNB, or in 528 the Dual Connectivity (DC) architecture where the carriers originate 529 from different gNBs, i.e., the UE is connected to two gNBs in this 530 case. In both cases, transmission reliability is improved by this 531 means of providing frequency diversity. 533 In addition to licensed spectrum, a 5G system can also utilize 534 unlicensed spectrum to offload non-critical traffic. This version of 535 NR is called NR-U, part of 3GPP Release 16. The central scheduling 536 approach applies also for unlicensed radio resources, but in addition 537 also the mandatory channel access mechanisms for unlicensed spectrum, 538 e.g., Listen Before Talk (LBT) are supported in NR-U. This way, by 539 using NR, operators have and can control access to both licensed and 540 unlicensed frequency resources. 542 5.5. Time-Sensitive Networking (TSN) Integration 544 The main objective of Time-Sensitive Networking (TSN) is to provide 545 guaranteed data delivery within a guaranteed time window, i.e., 546 bounded low latency. IEEE 802.1 TSN [IEEE802.1TSN] is a set of open 547 standards that provide features to enable deterministic communication 548 on standard IEEE 802.3 Ethernet [IEEE802.3]. TSN standards can be 549 seen as a toolbox for traffic shaping, resource management, time 550 synchronization, and reliability. 552 A TSN stream is a data flow between one end station (Talker) to 553 another end station (Listener). In the centralized configuration 554 model, TSN bridges are configured by the Central Network Controller 555 (CNC) [IEEE802.1Qcc] to provide deterministic connectivity for the 556 TSN stream through the network. Time-based traffic shaping provided 557 by Scheduled Traffic [IEEE802.1Qbv] may be used to achieve bounded 558 low latency. The TSN tool for time synchronization is the 559 generalized Precision Time Protocol (gPTP) [IEEE802.1AS]), which 560 provides reliable time synchronization that can be used by end 561 stations and by other TSN tools, e.g., Scheduled Traffic 562 [IEEE802.1Qbv]. High availability, as a result of ultra-reliability, 563 is provided for data flows by the Frame Replication and Elimination 564 for Reliability (FRER) [IEEE802.1CB] mechanism. 566 3GPP Release 16 includes integration of 5G with TSN, i.e., specifies 567 functions for the 5G System (5GS) to deliver TSN streams such that 568 the meet their QoS requirements. A key aspect of the integration is 569 the 5GS appears from the rest of the network as a set of TSN bridges, 570 in particular, one virtual bridge per User Plane Function (UPF) on 571 the user plane. The 5GS includes TSN Translator (TT) functionality 572 for the adaptation of the 5GS to the TSN bridged network and for 573 hiding the 5GS internal procedures. The 5GS provides the following 574 components: 576 1. interface to TSN controller, as per [IEEE802.1Qcc] for the fully 577 centralized configuration model 579 2. time synchronization via reception and transmission of gPTP PDUs 580 [IEEE802.1AS] 582 3. low latency, hence, can be integrated with Scheduled Traffic 583 [IEEE802.1Qbv] 585 4. reliability, hence, can be integrated with FRER [IEEE802.1CB] 587 Figure 2 shows an illustration of 5G-TSN integration where an 588 industrial controller (Ind Ctrlr) is connected to industrial Input/ 589 Output devices (I/O dev) via 5G. The 5GS can directly transport 590 Ethernet frames since Release 15, thus, end-to-end Ethernet 591 connectivity is provided. The 5GS implements the required interfaces 592 towards the TSN controller functions such as the CNC, thus adapts to 593 the settings of the TSN network. A 5G user plane virtual bridge 594 interconnects TSN bridges or connect end stations, e.g., I/O devices 595 to the network. Note that the introduction of 5G brings flexibility 596 in various aspects, e.g., more flexible network topology because a 597 wireless hop can replace several wireline hops thus significantly 598 reduce the number of hops end-to-end. [ETR5GTSN] dives more into the 599 integration of 5G with TSN. 601 +------------------------------+ 602 | 5G System | 603 | +---+| 604 | +-+ +-+ +-+ +-+ +-+ |TSN|| 605 | | | | | | | | | | | |AF |......+ 606 | +++ +++ +++ +++ +++ +-+-+| . 607 | | | | | | | | . 608 | -+---+---++--+-+-+--+-+- | . 609 | | | | | | +--+--+ 610 | +++ +++ +++ +++ | | TSN | 611 | | | | | | | | | | |Ctrlr+.......+ 612 | +++ +++ +++ +++ | +--+--+ . 613 | | . . 614 | | . . 615 | +..........................+ | . . 616 | . Virtual Bridge . | . . 617 +---+ | . +--+--+ +---+ +---+--+ . | +--+---+ . 618 |I/O+----------------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ . 619 |dev| | . |TT| | | | | |TT| . | |bridge| | . 620 +---+ | . +--+--+ +---+ +---+--+ . | +------+ | . 621 | +..........................+ | . +-+-+-+ 622 | | . | Ind | 623 | +..........................+ | . |Ctrlr| 624 | . Virtual Bridge . | . +-+---+ 625 +---+ +------+ | . +--+--+ +---+ +---+--+ . | +--+---+ | 626 |I/O+--+ TSN +------+DS|UE+---+RAN+-+UPF|NW+------+ TSN +----+ 627 |dev| |bridge| | . |TT| | | | | |TT| . | |bridge| 628 +---+ +------+ | . +--+--+ +---+ +---+--+ . | +------+ 629 | +..........................+ | 630 +------------------------------+ 632 <----------------- end-to-end Ethernet -------------------> 634 Figure 3: 5G - TSN Integration 636 NR supports accurate reference time synchronization in 1us accuracy 637 level. Since NR is a scheduled system, an NR UE and a gNB are 638 tightly synchronized to their OFDM symbol structures. A 5G internal 639 reference time can be provided to the UE via broadcast or unicast 640 signaling, associating a known OFDM symbol to this reference clock. 641 The 5G internal reference time can be shared within the 5G network, 642 i.e., radio and core network components. For the interworking with 643 gPTP for multiple time domains, the 5GS acts as a virtual gPTP time- 644 aware system and supports the forwarding of gPTP time synchronization 645 information between end stations and bridges through the 5G user 646 plane TTs. These account for the residence time of the 5GS in the 647 time synchronization procedure. One special option is when the 5GS 648 internal reference time in not only used within the 5GS, but also to 649 the rest of the devices in the deployment, including connected TSN 650 bridges and end stations. 652 Redundancy architectures were specified in order to provide 653 reliability against any kind of failure on the radio link or nodes in 654 the RAN and the core network, Redundant user plane paths can be 655 provided based on the dual connectivity architecture, where the UE 656 sets up two PDU sessions towards the same data network, and the 5G 657 system makes the paths of the two PDU sessions independent as 658 illustrated in Figure 5. There are two PDU sessions involved in the 659 solution: the first spans from the UE via gNB1 to UPF1, acting as the 660 first PDU session anchor, while the second spans from the UE via gNB2 661 to UPF2, acting as second the PDU session anchor. The independent 662 paths may continue beyond the 3GPP network. Redundancy Handling 663 Functions (RHFs) are deployed outside of the 5GS, i.e., in Host A 664 (the device) and in Host B (the network). RHF can implement 665 replication and elimination functions as per [IEEE802.1CB] or the 666 Packet Replication, Elimination, and Ordering Functions (PREOF) of 667 IETF Deterministic Networking (DetNet) [RFC8655]. 669 +........+ 670 . Device . +------+ +------+ +------+ 671 . . + gNB1 +--N3--+ UPF1 |--N6--+ | 672 . ./+------+ +------+ | | 673 . +----+ / | | 674 . | |/. | | 675 . | UE + . | DN | 676 . | |\. | | 677 . +----+ \ | | 678 . .\+------+ +------+ | | 679 +........+ + gNB2 +--N3--+ UPF2 |--N6--+ | 680 +------+ +------+ +------+ 682 Figure 4: Reliability with Single UE 684 An alternative solution is that multiple UEs per device are used for 685 user plane redundancy as illustrated in Figure 5. Each UE sets up a 686 PDU session. The 5GS ensures that those PDU sessions of the 687 different UEs are handled independently internal to the 5GS. There 688 is no single point of failure in this solution, which also includes 689 RHF outside of the 5G system, e.g., as per FRER or as PREOF 690 specifications. 692 +.........+ 693 . Device . 694 . . 695 . +----+ . +------+ +------+ +------+ 696 . | UE +-----+ gNB1 +--N3--+ UPF1 |--N6--+ | 697 . +----+ . +------+ +------+ | | 698 . . | DN | 699 . +----+ . +------+ +------+ | | 700 . | UE +-----+ gNB2 +--N3--+ UPF2 |--N6--+ | 701 . +----+ . +------+ +------+ +------+ 702 . . 703 +.........+ 705 Figure 5: Reliability with Dual UE 707 Note that the abstraction provided by the RHF and the location of the 708 RHF being outside of the 5G system make 5G equally supporting 709 integration for reliability both with FRER of TSN and PREOF of DetNet 710 as they both rely on the same concept. 712 Note also that TSN is the primary subnetwork technology for DetNet. 713 Thus, the DetNet over TSN work, e.g., [I-D.ietf-detnet-ip-over-tsn], 714 can be leveraged via the TSN support built in 5G. 716 6. Summary 718 5G technology enables deterministic communication. Based on the 719 centralized admission control and the scheduling of the wireless 720 resources, licensed or unlicensed, quality of service such as latency 721 and reliability can be guaranteed. 5G contains several features to 722 achieve ultra-reliable and low latency performance, e.g., support for 723 different OFDM numerologies and slot-durations, as well as fast 724 processing capabilities and redundancy techniques that lead to 725 achievable latency numbers of below 1ms with reliability guarantees 726 up to 99.999%. 728 5G also includes features to support Industrial IoT use cases, e.g., 729 via the integration of 5G with TSN. This includes 5G capabilities 730 for each TSN component, latency, resource management, time 731 synchronization, and reliability. Furthermore, 5G support for TSN 732 can be leveraged when 5G is used as subnet technology for DetNet, in 733 combination with or instead of TSN, which is the primary subnet for 734 DetNet. In addition, the support for integration with TSN 735 reliability was added to 5G by making DetNet reliability also 736 applicable, thus making 5G DetNet ready. Moreover, providing IP 737 service is native to 5G. 739 Overall, 5G provides scheduled wireless segments with high 740 reliability and availability. In addition, 5G includes capabilities 741 for integration to IP networks. 743 7. IANA Considerations 745 This document does not require IANA action. 747 8. Security Considerations 749 5G includes security mechanisms as defined by 3GPP. 751 9. Acknowledgments 753 The authors acknowledge the work of all from Ericsson Research who 754 contributed to the subject in any form. 756 10. Informative References 758 [TR37910] "3GPP TR 37.910, Study on self evaluation towards IMT-2020 759 submission", 760 . 763 [TR38824] "3GPP TR 38.824, Study on physical layer enhancements for 764 NR ultra-reliable and low latency case (URLLC)", 765 . 768 [TR38825] "3GPP TR 38.825, Study on NR industrial Internet of Things 769 (IoT)", 770 . 773 [TS22104] "3GPP TS 22.104, Service requirements for cyber-physical 774 control applications in vertical domains", 775 . 778 [TR22804] "3GPP TR 22.804, Study on Communication for Automation in 779 Vertical domains (CAV)", 780 . 783 [TS23501] "3GPP TS 23.501, System architecture for the 5G System 784 (5GS)", 785 . 788 [TS38300] "3GPP TS 38.300, NR Overall description", 789 . 792 [IMT2020] "ITU towards IMT for 2020 and beyond", 793 . 796 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 797 "Deterministic Networking Architecture", RFC 8655, 798 DOI 10.17487/RFC8655, October 2019, 799 . 801 [I-D.ietf-detnet-ip-over-tsn] 802 Varga, B., Farkas, J., Malis, A., and S. Bryant, "DetNet 803 Data Plane: IP over IEEE 802.1 Time Sensitive Networking 804 (TSN)", Work in Progress, Internet-Draft, draft-ietf- 805 detnet-ip-over-tsn-02, 6 March 2020, 806 . 809 [IEEE802.1TSN] 810 IEEE 802.1, "Time-Sensitive Networking (TSN) Task Group", 811 . 813 [IEEE802.1AS] 814 IEEE, "IEEE Standard for Local and metropolitan area 815 networks -- Timing and Synchronization for Time-Sensitive 816 Applications", IEEE 802.1AS-2020, 817 . 820 [IEEE802.1CB] 821 IEEE, "IEEE Standard for Local and metropolitan area 822 networks -- Frame Replication and Elimination for 823 Reliability", DOI 10.1109/IEEESTD.2017.8091139, IEEE 824 802.1CB-2017, 825 . 827 [IEEE802.1Qbv] 828 IEEE, "IEEE Standard for Local and metropolitan area 829 networks -- Bridges and Bridged Networks -- Amendment 25: 830 Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, 831 . 833 [IEEE802.1Qcc] 834 IEEE, "IEEE Standard for Local and metropolitan area 835 networks -- Bridges and Bridged Networks -- Amendment 31: 837 Stream Reservation Protocol (SRP) Enhancements and 838 Performance Improvements", IEEE 802.1Qcc-2018, 839 . 841 [IEEE802.3] 842 IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, 843 . 845 [ETR5GTSN] Farkas, J., Varga, B., Miklos, G., and J. Sachs, "5G-TSN 846 integration meets networking requirements for industrial 847 automation", Ericsson Technology Review, Volume 9, No 7, 848 August 2019, . 852 Authors' Addresses 854 Janos Farkas (editor) 855 Ericsson 856 Budapest 857 Magyar tudosok korutja 11 858 1117 859 Hungary 861 Email: janos.farkas@ericsson.com 863 Torsten Dudda 864 Ericsson 865 Ericsson Allee 1 866 52134 Herzogenrath 867 Germany 869 Email: torsten.dudda@ericsson.com 871 Alexey Shapin 872 Ericsson 873 Laboratoriegrand 11 874 SE-977 53 Lulea 875 Sweden 877 Email: alexey.shapin@ericsson.com 879 Sara Sandberg 880 Ericsson 881 Laboratoriegrand 11 882 SE-977 53 Lulea 883 Sweden 885 Email: sara.sandberg@ericsson.com