8
Critical Machine Type Communication

Zexian Li1 and Rainer Liebhart2

1Nokia, Espoo, Finland

2Nokia, Munich, Germany

8.1 Introduction

As outlined in Chapter 1, key differentiators between long‐term evolution (LTE) and 5G are the capability to provide ultra‐low latency and extreme high reliability connectivity service to applications. In this chapter we will describe how these features can be used for divergent use cases and most importantly what kind of solutions in the radio and core network will leverage low latency and high reliability.

With low latency we mean usually a few milliseconds (in the extreme case 1 ms) end‐to‐end (E2E) latency between client and server on the user plane. With ultra‐high reliability of at least 99.999%, 99.999 9% or even higher we mean reliability of the connection interface between device and network. Thus, reliability is an issue for keeping a wireless connection active to reach the device (note that also fronthaul and backhaul connections are relevant for device reachability) allowing for a very high packet reception rate. On the other hand, network availability is also crucial for many applications. This refers to the downtime of the network and its components such as base stations (BSs), core network elements, registers, authentication and application servers (ASs).

8.1.1 Industrial Automation

The most important and well‐known use cases requiring ultra‐low latency and extreme high reliability are remote health‐care and surgery, some industrial applications like collaborative, mobile robots, remote control and autonomous driving. Table 8.1 (see also Table 1.3 in Chapter 1) depicts the relevant key performance indicators (KPIs) of these use cases.

Table 8.1 Low latency and high reliability use cases.

Scenario End‐to‐end latency Jitter Survival time Communication service availability (%) Reliability (%)
Tactile interaction 0.5 ms — — 99.999 99.999
Discrete automation: motion control 1 ms 1 μs 0 ms 99.9999 99.9999
Electricity distribution: high voltage 5 ms 1 ms 10 ms 99.9999 99.9999
Remote control 5 ms — — 99.999 99.999
Discrete automation 10 ms 100 μs 0 ms 99.99 99.99
Intelligent transport systems: infrastructure backhaul 10 ms 20 ms 100 ms 99.9999 99.9999
Process automation: remote control 50 ms 20 ms 100 ms 99.9999 99.9999
Process automation: monitoring 50 ms 20 ms 100 ms 99.9 99.9
Electricity distribution: medium voltage 25 ms 25 ms 25 ms 99.9 99.9

Industrial applications in a limited area or region, e.g. in a factory, harbor, airport, campus and the like seems most promising to achieve a positive business case with low latency and high reliable 5G connectivity. Deploying a nationwide Ultra‐Reliable Low Latency Communication (URLLC) network is too costly as it requires a high density of radio sites and many edge clouds hosting URLLC sensitive applications.

8.1.1.1 Discrete Factory Automation/Motion Control

These are closed‐loop control applications requiring ultra‐low latency and high reliability, e.g. use of collaborative robots in a factory:

  1. – Latency. From <1 to 10 ms.
  2. – Data rate. Low as messages typically small (<50 bytes).
  3. – Reliability. Ultra high, ranging up to <10−9.
  4. – Accuracy. Can be ultra‐high, down to cm range.
  5. – Jitter. Variable though ultra‐high, linked to isochronous operation and telegram delivery – from <1 μs to 10 ms.

8.1.1.2 Process Automation

These are supervisory and open‐loop control applications, as well as process monitoring and tracking operations requiring URLLC for a potentially high number of connected devices.

  1. – Latency. From a few ms to 1 s.
  2. – Data rate. Low as each transaction is typically <100 bytes.
  3. – Reliability. Packet loss rate <10−5.
  4. – Massive number of low power sensors.

8.1.1.3 Tele Operation

These applications require URLLC like remote control of machines and vehicles.

  1. – Latency. ∼50–150 ms, influenced by presence of haptic/tactile feedback.
  2. – Data rate. Low in downlink (DL) for small control commands, potentially very high in uplink (UL) for video.
  3. – Reliability. Variable from 10−3 to 10−5.
  4. – Accuracy. Can be ultra‐high, down to cm range.

8.1.2 V2X

Another future technology where 5G (but also LTE) can play a key role is Vehicle‐to‐X communication (V2X), especially Vehicle‐to‐Vehicle (V2V) and Vehicle‐to‐Network/Vehicle‐to‐Infrastructure (V2N/V2I). While in case of V2V vehicles are broadcasting information directly to their neighbors, e.g. once the vehicle is breaking or detects an obstacle (pedestrian or another vehicle) in front, V2N/V2I allows exchanging information in a wider area, e.g. regarding an accident or obstacle around a corner or junction. For V2V following limitations apply:

  1. – Sensors provide only a local environment support, and cannot “look” beyond other vehicles, obstacles and corners.
  2. – Some sensors can only offer decreased performance or fail in adverse weather conditions.
  3. – Distance meters are limited by a considerable inherent delay.

In contrary, network assisted information sharing

  1. – can take a wide area into account;
  2. – might provide information faster than via sensor measurements;
  3. – can lead to a higher reliability when combining information received via sensors and wireless networks.

The expectation is that V2X communication in general leads to higher road efficiency as cars can maintain lower distances at higher speeds, increased road safety as cars get more, enriched and faster information about their environment and potential hazards, and improved passengers' comfort.

Use cases where application servers may be involved to receive and distribute information to vehicles are e.g.: emergency vehicle priority, traffic light optimal speed advisory, traffic sign in the car, traffic jam warning and Software/map updates. These kind of use cases benefit from Edge Computing capabilities where application servers are hosted in Edge Clouds close (typically 5–25 km) to the radio sites (see Figure 8.1).

Diagram of V2X communication and edge clouds displaying lines labeled V2V and V2N between 3 car icons linked to 2 tower signals labeled 5G, to 2 edge clouds, leading to a private and public cloud.

Figure 8.1 V2X communication and Edge Clouds.

When talking about full autonomous driving (automation level 5, see Chapter 1.5) wireless technologies like 5G can support and complement in‐board systems like sensors and cameras in controlling the vehicle, but not replace them. This means that controlling a vehicle must be possible within and outside network coverage, without declining the safety of passengers and vehicles. The network can allow usage of very dense platoons of vehicles of less than 1 m, e.g. several trucks following each other where on the first truck, the platoon leader, is equipped with a human driver, while outside radio coverage the platoon density is automatically increased to several meters. The smaller the distance in such a platoon, the more vehicles can be “packed” together, the less drivers are needed, the less fuel is needed. Very dense platoons require however extreme high reliable networks and ultra‐low latency (V2V and V2N) communication between the platoon members, which comes only with 5G.

8.1.3 Public Safety

Mission critical communication in the context of Public Safety has several flavors: mission critical push‐to‐talk, mission critical data and mission critical video. Public Safety communication over LTE was specified by 3rd Generation Partnership Project (3GPP) from Rel‐12 onwards. It contains enablers like Group and Device‐to‐Device communication over LTE, as well as Mission Critical Push to Talk (MCPTT) application based on the Internet Protocol Multimedia Subsystem (IMS).

Mission critical communication has more stringent requirements regarding packet delay than normal voice or data communication, e.g. mission critical voice user plane requires 75 ms, mission critical signaling 60 ms for packet delay. With 5G, in general, we can expect much lower latency on the user plane, faster connection setup times, which is important when granting the floor in case of push‐to‐talk, and higher reliability. 3GPP may specify a 5G broadcast solution only in Rel‐16. Based on the experience with LTE based Multimedia Broadcast/Multicast Service (MBMS) the 5G broadcast solution can be designed from the very beginning allowing for more flexible and efficient deployments (e.g. deployments in smaller areas).

Last but not the least 5G Network Slicing allows operators to build dedicated slices for Public Safety networks, fulfilling the specific requirements Public Safety authorities might have. Such a slice is separated from other slices, thus provides not only higher reliability and lower latency for Public Safety services but protects the Public Safety slice against attacks from users of other slices and can provide a higher degree of isolation (e.g. guard the Public Safety slice from user plane traffic generated by other slices, also guard the slice from attacks to other slices etc.) and security by implementing special cryptographic algorithms.

8.2 Key Performance Indicators

Use cases and their requirements regarding throughput, latency, jitter, reliability, availability, etc. are extensively discussed in Chapter 1 of this book (see Sections 1.3–1.5). KPIs for the next generation radio access network were studied by 3GPP in TR 38.913 [1]. Regarding latency and reliability TR 38.913 provides the following target values:

8.2.1 Control Plane Latency

The target for control plane (CP) latency should be 10 ms. Control plane latency in this context means the needed time to move the device from idle to active state.

8.2.2 User Plane Latency

User plane latency refers to the time it takes to successfully deliver an application layer packet from the radio protocol layer 2/3 ingress point to the radio protocol layer 2/3 egress point via the radio interface in both UL and DL directions. For URLLC, the target for user plane latency should be 0.5 ms for both UL and DL transmission. For enhanced Mobile Broadband (eMBB), the target for user plane latency should be 4 ms for both UL and DL transmission.

8.2.3 Latency for Infrequent Small Packets

For infrequent application layer small packet transfer, latency refers to the time it takes to successfully deliver an application layer packet from the radio protocol layer 2/3 ingress point to the radio protocol layer 2/3 egress point, when the mobile device starts from its most “battery efficient” state. This kind of latency shall be no worse than 10 seconds on the UL for a 20‐byte application packet measured at the maximum coupling loss of 164 dB.

8.2.4 Reliability

Reliability refers to the success probability of transmitting several bytes within a certain delay. A general URLLC reliability requirement for one transmission of a packet is 1–10−5 for 32 bytes with a user plane latency of 1 ms.

In case of eV2X (enhanced Vehicle‐to‐X communication), communication availability, resiliency and user plane latency for delivery of a 300 bytes packet, are as follows: Reliability is 1–10−5, user plane latency is 3–10 ms, for direct communication via side link and communication range of a few meters, and the same when the packet is relayed via the base station.

8.3 Solutions

8.3.1 System Design Challenges

Up to now, spectral efficiency has been the main design target for all previous wireless cellular communication systems, including LTE and earlier generations like 2G and 3G. URLLC, which has been widely envisioned as the enabler for supporting various newly emerging vertical services and applications, brings new challenges for the overall 5G system design. As discussed in Chapter 8.2, in 3GPP Rel‐15 New Radio (NR) [1], the design target is to support communication reliability corresponding to Block Error Rate (BLER) of 10−5 and up to 1 ms radio protocol layer latency for delivering short packets with a packet length of 32 bytes. The requirements will become more stringent when considering the coming 3GPP Rel‐16 as discussed for example in TR 22.804 [2]. From design point of view, the difficulty does not come with one stringent requirement, either high reliability or low latency. However, with the simultaneous requirements on ultra‐high reliability and low latency, we are facing much more challenges. As can be easily understood, the stringent requirements will impact the design of data channels, e.g. retransmission schemes, building necessary redundancy and so on. Furthermore, URLLC is putting more strict requirements on the control channel design as well. In this section, we will focus on the requirements of control channels.

Figure 8.2 illustrates a simplified system model for DL data transmission after an URLLC UE (User Equipment) has established the link with the gNB (5G NodeB). In Figure 8.2, it is assumed that with two transmissions the target BLER of 10−5 can be achieved.

Sequence diagram between UE and gNB displaying rightward and leftward arrows labeled DL control (incl. resource allocation info), DL data, NACK, and ACK.

Figure 8.2 Example procedure for DL data transmission.

Potentially all steps in the figure can impact the finally achievable reliability rate. Before data transmission, gNB sends DL control information including resource grant to the UE. Only after correctly decoded control information, the UE can try to decode the data packet sent within the allocated resource and provide feedback to the gNB. The feedback can be either an ACK (Acknowledgment) or a NACK (negative Acknowledgment) to indicate the success or failure in the data packet reception. In the figure it is assumed that NACK is transmitted after the first transmission due to failure decoding at UE side. After receiving NACK, gNB starts to retransmit the same data packet with the same or different transmission format. The gNB again instructs the UE to monitor the allocated resources for the data retransmission by sending a new resource allocation command. In case UE can get the data packet correctly, an ACK is sent.

As discussed in [3], errors in decoding the control channel can significantly reduce the overall E2E communication performance, especially the reliability. To be more specific, in case the UE is not able to decode the control channel information, e.g. resource allocation information, correctly, the UE is not aware of the present transmitted data packet and therefore it will not even try to decode the data packet. Consequently, there is no feedback from the UE, i.e. neither ACK nor NACK will be transmitted and at gNB side, such state could be recognized as a Discontinuous Transmission (DTX) and results in retransmission of the same data packet to the UE. In addition, there is the possibility that the gNB falsely recognizes DTX or NACK feedback (in case the first data packet transmission is not successfully decoded at the UE) as ACK. In this case, gNB will not take any further action including retransmission as it assumes the data packet was correctly received. However, in both cases, UE has not managed to decode the received packet correctly. Another way to improve reliability in such cases is to implement retransmission of the same physical data unit (PDU) at higher layers, e.g. using Radio Link Control (RLC) layer Automatic Repeat Request (ARQ) retransmission. However, this leads to increased latency.

Figure 8.3 illustrates the reliability regions for supporting reliability of 1 − 10−5 in case of cellular communications. In Figure 8.3 we denote ɛRG as the error rate of decoding the resource allocation information, p1 as the BLER of the initial data transmission, and ɛN/A as the error rate of decoding NACK as an ACK and decoding DTX as an ACK. It is assumed that there is sufficient time for two transmissions, i.e. in addition to the first transmission, the second transmission can be utilized to further increase reliability within the latency constraints. A residual BLER of 10−5 upon the data retransmission is assumed. In case NACK is detected, retransmission is done in a way that the residual BLER target is achieved upon soft combining the received information from both the initial transmission and the retransmission. In case of detecting a DTX, the retransmission is performed with more robust transmission to compensate the lack of soft information from the initial transmission at the receiver. Of course, in case NACK is received, it is also possible that a more robust Modulation and Coding Scheme (MCS) is selected to guarantee that the data packet can be decoded correctly after combining the first and second transmission. It is shown that a target with BLER = 10−1 for performing the initial transmission entails at most 10−4 BLER for ɛRG and ɛN/A. Such control channel reliabilities are not supported by LTE and might cause a large signaling overhead in the system. The control channel error rate constraints can be relaxed by performing the initial data transmission using a more conservative MCS. For instance, the BLER constraint for the control signals, i.e. ɛRG and ɛN/A, can be reduced to 10−3 in case of adopting a 10−2 BLER target for the initial data transmission. In other words, there is a certain tradeoff between the reliability of control and data channels, suggesting that the link adaptation for data channels needs to consider the errors of control channels.

Graph illustrating reliability regions for downlink scheduling-based data transmissions displaying 3 shaded curve regions representing p1= 10-3, p1= 10-2, and p1= 10-1 (light to dark shade).

Figure 8.3 Reliability regions for downlink scheduling‐based data transmissions.

In addition to error cases regarding the DL control channel, another type of error which can reduce the overall reliability performance is related to UL ACK/NACK signal detection at the gNB. The erroneous decoding of an ACK as a NACK triggers unnecessary data retransmissions, resulting in waste of resources without any damage from reliability aspect. On the contrary, the erroneous decoding of a NACK as an ACK signal leads to absence of a necessary retransmission, which results in reduced reliability performance. It is easy to understand that the errors of ACK/NACK affect only the retransmission round.

One aspect related to DL data transmission, which has not been included in Figure 8.3, is how the gNB can determine the suitable MCS selection (corresponding to different resource sizes) for the DL data transmission. In the current LTE design, the eNB scheduler can use a certain method to select the MCS index based on the Channel Quality Indicator (CQI) report. For URLLC CQI reporting, the error of decoding a given CQI value wrongly as a lower value results in a lower level of MCS selection, which is not optimal from spectral efficiency point of view, however, there is no penalty on latency and reliability as the success probability rate is increased. On the other hand, the gNB might wrongly decode the received CQI as a higher value. Such an error leads to the selection of a higher MCS level for data transmission and hence a reduced communication reliability. This error type brings much more damage toward reliability.

Similarly, for UL data transmission, there are requirements on various control channels as well, for example scheduling request (SR) in case with scheduling based UL data transmission, resource grant information transmission and feedback. For instance, one source of error is missing the resource grant resulting in not sending the data packet in UL as the UE has no idea about which resource blocks (RBs) can be used for UL data transmission. This error might happen during the initial transmission round and/or retransmission rounds. In UL, the gNB potentially can notify this event when it does not receive any data signal from the UE. In case the gNB identifies the missing of resource grant for the initial transmission round, it can allocate additional radio resources for the retransmission round to compensate the loss of initial transmission.

In the following sections, we will discuss various technology components to improve system performance especially in terms of latency and reliability, which is kind of a tool box for URLLC support. Although, we are discussing latency and reliability aspects separately for an easier understanding, these two aspects are not independent, but rather tightly correlated. For example, the technology components mainly targeted for low latency support could bring more retransmission opportunity as well, which brings gains in terms of reliability.

8.3.2 Low Latency

8.3.2.1 Architecture

Edge Clouds and Edge Computing

Ultra‐low latency on the user plane requires the two endpoints of the communication path, e.g. application client on the device and Application Server (AS) in the network, being close together. Speed of light is limited to 300 000 km s−1 and in fiber it is only 200 000 km s−1. Consequently, (ultra) low latency applications cannot be hosted in the Internet like most of today's applications, but in so‐called Edge Clouds (sometimes referred to as Edge Computing). Assuming a maximum of 1 ms latency on the air interface between device and 5G base station for UL and DL, mainly the distance between Edge Cloud and base station determines the overall latency (an additional factor is the processing time in the evolved nodes). An Edge Cloud in this context consists of one or several small data centers with potentially few racks, which can host local User Plane Functions (UPFs), Multi‐Access Edge Computing platforms (MEC), local Application Servers (e.g. content cashing or video streaming servers) and 5G Radio Central Units (CUs). From 3GPP point of view the MEC platform is considered as an Application Function (AF).

A CU implements non‐realtime higher layers of the radio protocol stack (Packet Data Convergence Protocol [PDCP] and Radio Resource Control [RRC]), while the Distributed Units (DUs) are implementing the realtime lower layer parts of the radio stack (up to the Medium Access Control (MAC) layer). This DU/CU split was specified by 3GPP in Rel‐15 with F1 as interface between DU and CU (see Chapter 4). Core network elements that are part of the control plane are usually hosted in central Telco Clouds. Also, UPFs can be deployed in these central clouds, if they are used to access centralized services in the Internet or IMS where ultra‐low latency plays no role. The next Figure 8.4 provides a logical network view including Edge Clouds and central Telco Clouds and their inter‐connection.

Diagram of logical network view displaying 5G tower signal, fronthaul, DU, midhaul attached to edge cloud connected to backhaul, backbone leading to Telco cloud (right) and edge cloud (left) with backhaul and 5G tower signal.

Figure 8.4 Logical network view with Edge and Telco Clouds.

These Telco Clouds can consist of hundreds or thousands of racks. Depending on the country size only very few or up to tens of them exist. Figure 8.5 shows the typical distances between radio site, DU, CU and central Telco Cloud. Distances may vary depending on transmission capabilities, latency requirements and number of sites.

Diagram of network distances represented by horizontal double-headed arrows labeled 5 to 25 km between tower signal and DU, 200 to 400 km between DU and UPF, and several 100 to several 1000 km between UPF and AS and 5GC.

Figure 8.5 Network distances.

To allow for 1 ms latency between device and application server a different configuration is necessary where DU, CU are collapsed and hosted with a local UPF, potentially MEC and a local application server in the same Edge Cloud. This deployment is shown in Figure 8.6.

Diagram of low latency configuration represented by 2 horizontal double-headed arrows labeled 1 ms latency and 10-20 ms latency from a phone to boxes labeled AS and 5GC.

Figure 8.6 Low latency configuration.

Micro‐Operator Networks

Deployment of Edge Clouds is one way to reduce latency. Another way is deployment of local or private networks (in a factory, at a harbor or airport) by micro‐operators providing URLLC capabilities as e.g. required by safety critical applications. One example illustration of a micro‐operator for vertical usage is illustrated in Figure 8.7.

Diagram of micro-operator for vertical usage displaying a 5G tower signal connected to factory and to another tower, to an edge cloud branching to a private and a private cloud.

Figure 8.7 Micro‐operator network for verticals.

As shown, the micro‐operator can deploy a dedicated network to support specific services that might have very strict requirements in terms of latency and reliability. At the same time, there could be data traffic, for example maintenance traffic (SW updates), that is destined to a wide area or public network. Using the concept of micro‐operators, the overall E2E latency among devices within the restricted area can be significantly reduced by moving the application layer processing close to end users. Micro‐operator networks can be deployed and maintained by different parties: the public mobile network operator, the factory owner, specialized networking companies, 3rd parties running the factory infrastructure, etc.

Multi‐Access Edge Computing

MEC in general is meant to bring computing and IT capabilities to the edge of the (mobile) network, close to the consumers, thus becoming the “cloud” for real‐time and personalized mobile services and improving user experience. However, from deployment perspective MEC is not limited to the network edge, it can also be deployed at Enterprise premises or at central locations (central Telco Cloud), depending on the application needs. MEC deployments allow for reduced latency and support local context delivery, which is key to provide critical communication capabilities, robust and highly responsive connectivity to Internet of Thing (IoT) applications. The MEC platform consists of Application Enablement, enabling authorized applications to access the network, Application Programming Interfaces (APIs) and management capabilities to run applications as software‐only entities within a network or part of it. APIs can provide access to radio network information (allowing relocation of applications in case of user mobility), location information, bandwidth management data and UE identities. Figure 8.8 shows the principle MEC platform components.

Diagram of MEC platform architecture displaying 4 shaded boxes labeled Management Layer, Applications, 7 unshaded boxes labeled API on top of Application Enablement Layer, and Virtualization Layer (top-bottom).

Figure 8.8 MEC platform architecture.

8.3.2.2 Radio Network

In this section our objective is to discuss the latency reduction technology components, which have been accepted or are discussed within 3GPP with regards to the radio network. Table 8.2 summarizes the key technology components, which have been specified in 3GPP Rel‐15 or are currently under discussion.

Table 8.2 List of technology components for latency reduction.

Technology components Short description
New numerology, short Transmission Time Interval (TTI) Short TTI size to ensure fast transmission of data packets. 3GPP NR supports reduced slot length with flexible subcarrier spacing (SCS) and further non‐slot transmission of 1–13 symbols.
Maximum data burst size Largest amount of data the 5G‐AN is required to transmit within a period of 5G‐AN PDB, the 5G‐AN part of the packet delay budget.
Frame structure with bi‐directional slots By introducing one or multiple switching points within one slot, the time division multiplexing of DL/UL control symbols and data symbols in one slot is possible, allowing fast and energy efficient pipeline processing of control and data in the receiver.
Scheduling policy Non‐slot based scheduling: minimum scheduling unit is not on slot level, but on symbol(s) level (mini‐slot level).
Preemption scheduling: Prioritized scheduling of data packets with low latency constraints to minimize gNB queuing delays. Pre‐emption of eMBB traffic for URLLC data packet transmissions.
Grant‐free UL transmission Grant‐free UL transmission scheme avoids regular handshake delays between UE and gNB including at least scheduling request and UL resource grant allocation, and moreover relaxes the stringent requirements on the reliable resource grant.
UE and gNB processing time Reduced UE and gNB processing time to ensure fast creation of transport blocks for transmission as well as fast processing at the receiver end for feedback transmission.
New Numerology and Short TTI Duration

3GPP has introduced a very flexible frame structure for 5G NR which offers different possibilities to shorten the Transmission Time Interval (TTI) duration compared to LTE. For instance, the subcarrier spacing can be flexibly configured to support 5G operation in different frequency bands. The 15 kHz Sub‐Carrier Spacing (SCS) (same as in LTE) corresponds to the baseline configuration, and can be scaled with a factor of 2N, where N∈[0, 1, 2, 3, 4, 5]. Based on the current agreement sub‐carrier spacings of between 15 and 120 kHz are defined in Release 15. In later releases, sub‐carrier spacing greater than 480 kHz could be accommodated as well, especially in the context of higher operating frequency like in mmWave bands. With higher sub‐carrier spacing, more symbols can be accommodated in a sub‐frame, resulting in lower acquisition time. Table 8.3 illustrates the current agreed OFDM (Orthogonal Frequency‐Division Multiplexing) numerologies for 5G NR with normal CP length.

Table 8.3 OFDM numerologies for 5G NR (normal CP length).

Subcarrier spacing (kHz) 15 30 60 120 240
Symbol duration (μs) 66.7 33.3 16.7  8.33  4.17
Nominal normal CP (μs)  4.7  2.3  1.2  0.59  0.29
Min scheduling interval (symbols) 14 14 14 14 28
Min scheduling interval (slots)  1  1  1  1  2
Min scheduling interval (ms)  1  0.5  0.25  0.125  0.125

On top of this, the number of OFDM symbols per TTI can also vary. Within NR, both slot based and non‐slot based scheduling mechanisms are supported. To be more specific, the users can be scheduled with resource on slot level of 14 OFDM symbols, and/or on non‐slot level (mini‐slot based scheduling) where the length of a mini‐slot can be configured between 1 and 13 symbols. Short TTIs can therefore be built by reducing the symbol duration (increasing the SCS) and/or reducing the number of symbols per TTI. For example, a TTI duration of 0.125 ms can be obtained by scheduling users on a slot resolution in case of 120 kHz subcarrier spacing (N = 3). As another alternative, it is also possible to use 15 kHz SCS (N = 0) and schedule users with a non‐slot based resource of one to three symbols (∼71–222 μs), leaving room for processing time and HARQ (Hybrid Automatic Repeat Request) feedback transmissions within 1 ms (see [4]). The non‐slot based scheduling is therefore useful for time‐critical services, while other less time‐critical services can still be served with longer TTI durations.

Maximum Data Burst Volume

When there is a need to transmit packets with latency in the order of 1 ms to 10 ms and to support reliability in the order of 10−5, it is essential to define the largest amount of data the 5G‐AN is required to transmit within a period of the 5G‐AN Packet Delay Budget (PDB), the 5G‐AN part of the PDB. This is referred to as Maximum Data Burst Volume. Each Delay Critical Guaranteed Bitrate (GBR) Quality of Service (QoS) flow is associated with a Maximum Data Burst Volume. The Maximum Data Burst Volume may be signaled together with 5G Quality of Service Identifiers (5QIs) to the (R)AN, and if it is not signaled, default values apply for standardized 5QIs QoS characteristics.

For delay critical GBR QoS flows, a packet delayed greater than the PDB is counted as lost packet, if the transmitted data burst is less than the Maximum Data Burst Volume within the period of PDB and the data rate for the QoS flow is not exceeding the Guaranteed Flow Bitrate (GFBR). The PER (Packet Error Rate) also defines a value for reliability of the latency target set by the PDB.

Frame Structure with Bi‐directional Slots

As shown in Table 8.3, 5G NR frames can be built on the configurable slot types on a scalable numerology designed for a wide range of scenarios and use cases fulfilling a variety of requirements. So far three types of slots were specified: DL only slot, UL only slot and bi‐directional slot (see Figure 8.9) providing low latency support for both Frequency Division Duplex (FDD) and Time Division Duplex (TDD). Bi‐directional slots are a viable option to achieve low latency in TDD where multiple switching points can be configured within one slot. The time division multiplexing of DL/UL control and data symbols in one slot allows fast and energy efficient pipeline processing of control and user data in the receiver. Decoupling the control and user data provides flexible and rapid UL/DL scheduling and enables very low latency of HARQ acknowledgements without dependency on the control channels from predetermined TDD UL/DL configurations. Depending on UE capabilities and the support of aggressive processing time requirements, a very short time delay in symbols for the gap between DL assignment and DL data transmission, the gap between DL data and acknowledgement for DL data and the gap between UL assignment and UL data transmission could be supported.

Diagram for 3 types of slot structures displaying 4 horizontal bars representing DL only slot, UL only slot, and 2 Bi-directional slot, each bar having discrete shaded sections for DL data, DL control, UL data, and UL control.

Figure 8.9 Flexible slot structure in 5G NR.

In addition to the low latency slot structure, dynamic TDD would allow for flexible assignment of UL and DL resources, further reducing the end user experienced latency.

Scheduling Policy

During the design of 5G NR, the stringent URLLC requirements were considered at the very beginning of the design phase. Scheduling is another key element for latency reduction and below we will discuss a group of technology components especially for latency reduction based on scheduling algorithms.

Non‐slot Based Scheduling

As mentioned before, non‐slot based scheduling (mini‐slot) is a key enabler within 5G NR which is useful in various scenarios including low latency transmission, multi‐beam operation in the millimeter wave spectrum and transmission in unlicensed spectrum. It is widely envisioned that non‐slot based scheduling is an essential enabler to fulfill the challenging latency targets in low frequency bands of TDD and FDD NR. Providing better delay spread performance with a low subcarrier spacing in wide area use cases, non‐slot based transmission is preferred over slot based transmission.

As the smallest scheduling unit, mini‐slot supports the transmissions with a duration in symbols, providing in‐built low latency as processing time at both UE and gNB side are reduced significantly. The mini‐slot length of two, four or seven symbols is part of the 3GPP recommendation in Rel‐15. Supporting of front‐load Demodulation Reference Signal (DMRS) in mini‐slot scenarios allows the DMRS based channel estimation being performed earlier, upon which the UE and gNB data reception processing is dependent on, while the support of code blocks interleaving over frequency in mini‐slots allows processing of the symbol as soon as it is received over‐the‐air.

As shown in Figure 8.10, there are at least two different approaches for the scheduling of a mini‐slot. The self‐scheduling of a mini‐slot (as illustrated in case a of the figure) is made from the Physical Downlink Control Channel (PDCCH) location at the beginning of each DL mini‐slot, which enables immediate transmission without waiting for the start of a slot boundary and has no constraints from DL/UL switching point alignment in a slot of static TDD system on additional PDCCHs. The cross‐scheduling of a mini‐slot (as illustrated in case b of the figure) is made from the PDCCH location at the beginning of the slot, which is attractive for UE power consumption savings.

2 Diagrams of mini-slot PDSCH scheduling displaying alternate shaded sections of PDSCH and PDCCH for K0= 0, one-symbol mini-slot (top) and clustered sections for K0>0, two-symbol mini-slot (bottom).

Figure 8.10 Mini‐slot PDSCH scheduling.

Efficient URLLC and eMBB Multiplexing

Dynamic multiplexing between URLLC and non‐URLLC traffic including traditional eMBB traffic is preferred due to the flexibility of resource usage and better spectral efficiency. However, this is a challenging task given the very different requirements of the services. Taking URLLC traffic and eMBB traffic as an example, URLLC traffic is typically bursty and sporadic and must be immediately scheduled preferably with short TTI to fulfill the strict latency requirements. On the contrary, eMBB traffic transferring large data packets would benefit from the usage of 1 ms or even longer TTIs leading to smaller control signaling overhead and avoiding fragmentation of packets into multiple smaller ones. One solution for multiplexing is to statically reserve certain radio resources for URLLC data transmissions exclusively. However, this results in waste of radio resources when there is no URLLC traffic to transfer. A more efficient solution is to use dynamic multiplexing, for example preemptive scheduling following [5,6]: eMBB traffic is scheduled on all the available radio resources with a long TTI, e.g. 1 ms. When URLLC data arrives at the gNB, it is immediately transmitted to the corresponding UE by overwriting part of an ongoing eMBB transmission, using mini‐slot transmission, as illustrated in Figures 8.11 and 8.12. This has the advantage that the URLLC data packet is transmitted right away without waiting for ongoing scheduled transmissions to be completed and without the need for pre‐reserving radio resources for URLLC traffic. The drawback of the preemptive scheduling scheme is the performance of the impacted eMBB service whose transmission is partly removed, hence the decoding performance will suffer. To minimize this negative impact, the study in [5] proposes including an indication to the “victim” UE to give the information that part of its transmission has been overwritten by high priority URLLC traffic. This enables the eMBB UE to take this effect into account when decoding the transmission, i.e. it knows that part of the transmission is corrupted. To further improve the performance, various enhancements have been proposed, e.g. applying smart HARQ retransmission mechanisms, where only the overwritten part of the initial transmission is retransmitted.

Frequency (PRBs) vs. time displaying a grid with discrete shaded regions having 2 arrows marking the puncturing scheduling.

Figure 8.11 Resource allocation framework for URLLC and eMBB multiplexing: downlink multi‐service multiplexing example.

Diagram of the example of preemptive scheduling displaying a rightward arrow labeled Time with a horizontal bar having 14 sections on top. On top of the bar are arrows indicating URLCC data… and Scheduled eMBB resource.

Figure 8.12 Example of preemptive scheduling.

Similarly, the concept can be extended to cover the UL direction as well. The UL scheduling is conducted by the gNB sending scheduling grants in the DL to the UEs. Among others, the scheduling grant includes pointers to time‐frequency UL resources that the UEs shall use for their UL transmission. The gNB can choose to schedule UEs with different TTI sizes; e.g. on slot or mini‐slot resolution level, given the options and constraints offered by the 5G NR flexible frame structure. For UL multiplexing between eMBB and URLLC services, one scheme which has been proposed and discussed in 3GPP is the pause‐resume scheme (see [7]). To be more specific:

A gNB can selectively configure certain eMBB users that are scheduled in the UL over one or multiple slots to still monitor DL physical control channels carrying the scheduling grants for URLLC UEs at the beginning of every mini‐slot (or a sub‐set of those) during the ongoing UL eMBB transmission.

In case the capacity becomes an issue and there is need for urgent scheduling of URLLC traffic for UL data transmission, the gNB will send a pause‐resume signaling message to one or multiple eMBB users that have an ongoing UL transmission and where already allocated resources are overlapping with the resources the gNB intends to allocate to URLLC UEs for UL transmission.

The pause‐resume signaling message informs the eMBB UEs to put ongoing UL transmission on pause for a short duration, where‐after it shall continue (resume) its UL transmission.

This approach requires that these eMBB UEs have the capability to monitor the DL control channel more frequently on mini‐slot level, and the processing time for the DL control is comparable to that of URLLC UEs. In this case, the pause‐resume signaling message can be sent in the same symbol(s) as the UL grant for URLLC. The pause‐resume signaling is sent in parallel with the scheduling grant to the URLLC UE. The pause‐resume signaling message is assumed to be sent on PDCCH, being either (group‐)common or UE‐specific.

In the example shown in Figure 8.13, the gNB first schedules an eMBB UE to transmit with a TTI size corresponding to six subframes (or slots) in the UL. The eMBB UE starts UL transmission with the allocated resource based on the corresponding scheduled transmission. During UL transmission, the eMBB UE continuously monitors the DL control channel on mini‐slot level. In case the UE receives a pause‐resume message, it will stop the ongoing eMBB transmission for a period specified in the DL control channel, e.g. one or multiple mini‐slots, while afterwards resuming the eMBB transmission to transmit the last two subframes of the TTI. During the mini‐slot (or slot) where the ongoing eMBB transmission is put on pause, the gNB schedules the latency critical URLLC transmission. Alternatively, the URLLC transmission can puncture the eMBB transmission. Another possibility is that a eMBB UE does not need to be configured to monitor the URLLC resource allocation, and it transmits as in normal operation. The URLLC UE will transmit its UL data packet using the same resource as the eMBB UE, but possibly with a higher Tx power. This scheme is referred to as superposition transmission. This may lead to interference between URLLC and eMBB UEs and more advanced receivers such as interference cancelation receivers are necessary to achieve an acceptable reliability performance.

Diagram of the pause-resume scheduling mechanism displaying a horizontal bar having 14 sections on top a rightward arrow for Time. On top of the bar are arrows indicating gNB issues…, gNB sending…, etc.

Figure 8.13 Pause‐resume scheduling mechanism in uplink.

In addition to inter‐UE multiplexing, intra‐UE multiplexing between URLLC and eMBB services could be a potential problem as well. It is possible that the UE could prioritize different logical channels (LCHs) between URLLC and eMBB in case URLLC data arrives before eMBB data transmission. Below we are mainly discussing the case that one URLLC UE has ongoing UL transmission of eMBB data when URLLC data arrives or in another case the UE has an upcoming scheduled UL transmission but does not have sufficient time to prepare URLLC data for this transmission. There are different situations which should be studied further in the coming 3GPP Rel‐16 or even future releases because UL URLLC data transmission can use either granted resources or configured UL grant‐free resources or both.

Logical Channel (LCH) Based Scheduling Request (SR)

For grant‐based transmission, when scheduling URLLC UL data, the gNB needs to provide proper amount of spectrum resources and MCS. In Rel‐15 it is already supported that the time interval between SR resources configured for a UE can be smaller than a slot, which means, depending on the latency requirement, it is possible that there is SR resource available for the UE per mini‐slot. Furthermore, multiple SR configurations can be configured for one UE. Which SR configuration is used depends on the LCH that triggers the SR. This enables the gNB to be aware of the critical transmission and to make e.g. proper scheduling decisions. Different ways including multi‐bit SR or multiple SR configurations to indicate information for critical latency transmissions were discussed in 3GPP. Following 3GPP agreements, the SR format can be kept similar as in LTE. But the gNB can configure multiple resources with different periodicity and resources for different services, for example one set of dedicated resources for URLLC services and another set for eMBB services which have relaxed requirement on latency. In this way, the gNB can get information of service type based on the resources where SR is received. The additional information is carried implicitly.

Consider the scenario that different SR resources are configured to request resources for UL transmission with different QoS requirements. One simple example is to configure two set of resources, one for latency critical services and another one for non‐latency critical service as illustrated in Figure 8.14 (see [8]).

Frequency vs. time displaying adjacent boxes with shades representing SR resource for non-URLLC services and SR resource for URLLC services depicting the example of multiple SR resource configuration.

Figure 8.14 Example of multiple SR resource configuration.

This figure assumes that two sets of resource blocks are configured, one for low latency services (per‐slot) and another one for non‐URLLC services which takes place at every 10 slots. In this way, the gNB can learn the required service type easily.

URLLC Transmission with UL Grant Free Resource

Assuming frequent UL grant free resources are available (e.g. in every mini‐slot) and if allowed, the UE could transmit both URLLC and eMBB data, as shown in Figure 8.15a, if there is no issue with Tx power since the grant free resource and the granted resource are overlapping in time, but not in frequency. In this case, UE transmission power might become a bottleneck. When the UE Tx power becomes as an issue or if simultaneous transmission is not supported, one straightforward solution can be that UL grant free transmission has the highest priority and eMBB data transmission is stopped or punctured as shown in Figure 8.15b. This is like the DL puncturing case where puncturing indication or some similar signaling to the receiver (i.e. gNB) would be necessary to reduce negative impacts on decoding and possible retransmission of packets.

2 Graphs for simultaneous URLLC and eMBB transmission (left) and URLLC transmission only (right) both displaying grant-free resources connected to 5 boxes on top of a shaded box for scheduled eMBB resource.

Figure 8.15 URLLC transmission with UL grant free resource.

URLLC Transmission with UL Granted Resource

In this case, a straightforward solution is the UE is requesting dedicated resources for URLLC UL data transmission which certainly will bring more latency due to the involved scheduling procedure: SR transmission, DL control channel reception and all necessary processing time.

Another option is sending URLLC data packet without waiting while using the already allocated eMBB resource as shown in Figure 8.16. This operation is like inter‐UE punctured scheduling in DL. The benefit of this operation is reduced latency since URLLC data packets can be transmitted right away with the already allocated resources for eMBB transmission without any collision possibility. The potential problem related to this mechanism is the corrupted eMBB data. Similar as for DL preemptive operation, sending puncturing information to the gNB might be necessary to minimize the impact on eMBB performance. The problem to be solved in this case is how to send the puncturing information, e.g. together with URLLC data as in‐band control signaling or as dedicated control signaling.

Graph for intra-UE puncturing displaying 3 adjacent boxes (a shaded box between 2 unshaded boxes) labeled Scheduled eMBB resource with the shaded section marked by a line indicating URLLC data transmission.

Figure 8.16 Intra‐UE puncturing.

UL Grant‐Free Transmission

Reserving radio resources for delivering the SR is not efficient for applications that generate sporadic data traffic. For the extreme low latency and reliability requirements, it is desirable to support a grant‐free UL transmission scheme that avoids the regular handshake delay between SR and UL grant allocation and relaxes the stringent requirements on the reliable grant.

There are two types of configuration schemes supported in 3GPP Rel‐15 ([9]). For the UL grant‐free type 1, UL data transmission without grant is based on RRC (re‐)configuration without any L1 signaling which is suitable for deterministic URLLC traffic patterns whose properties can be well matched by appropriate resource configuration. The UL grant‐free type 2 allows additional L1 signaling for a fast modification of semi‐persistently allocated resources, which enables flexibility of grant‐free UL operation in terms of URLLC traffic properties including but not limited to the variable packet arrival time and/or packet size.

The resources configured for grant‐free UL transmission can be shared or not among UEs of both type 1 or type 2 depending on network decision. Supporting a non‐contention based scheme or a contention based scheme of resource allocation depends whether to match the requirements of spectrum efficiency and performance requirements for the given use cases. For predictive traffic, non‐contention based allocation provides efficient resources dedicated to UEs with short access delay requirements, while keeping the high reliability gain from orthogonality. For sporadic small packet transfer and aperiodic transmissions in light load conditions, configuring grant‐free UL transmission on shared resources in a contention‐based manner is more efficient, but advanced Multiuser Detection (MUD) receivers would be required to ensure high reliability and to cope with resource collision of multiple users. The concept of contention‐based access is shown in Figure 8.17.

2 Sequence diagrams of UL grant free transmission. Left: Type 1 with 4 arrows labeled RRC configuration, UL data transmission, etc., between UE and gnB. Right: Type 2 with 6 arrows labeled RRC configuration, PHY activation, etc., between UE and gNB.

Figure 8.17 UL grant free transmission.

UL grant‐free transmission enables low latency access to data channels. To improve the reliability in case of collisions, diversity transmission, e.g. repetitions over time, can be utilized where packet replicas are sent multiple times to reduce the collision probability. It offers prominent gains and lower implementation complexity in comparison to multi‐user detection. However, how to set the optimal size of the grant‐free resource is a key problem to be solved. Depending on the network scenario, e.g. UE population and traffic pattern, the network may adopt various strategies to minimize or resolve collisions in the contention resource as indicated in [10].

Grant‐free based transmission is in general more efficient for small packet UL transmission in terms of lower latency and lower overhead. While for medium to large packets, due to limited flexibility of link adaptation and power control for grant‐free, it might result in higher latency to fully use grant‐free for transmitting such kind of packets. One promising way to solve this problem is supporting efficient mode switching from grant‐free to grant based, adaptively meeting requirements of incoming packets with different size.

Reduced UE Processing Time

The baseline UE processing time capability in NR Release 15 for slot‐based scheduling, including Carrier Aggregation (CA) case with no cross‐carrier scheduling and with single numerology for PDCCH, Physical Downlink Shared Channel (PDSCH), and Physical Uplink Shared Channel (PUSCH) and no Uplink Control Information (UCI) multiplexing, is given by Table 8.4.

Table 8.4 Reduced processing time for slot‐based scheduling.

HARQ timing parameter Units 15 kHz SCS 30 kHz SCS 60 kHz SCS 120 kHz SCS
Front‐loaded DMRS only N1 Symbols  8 10 17 20
Front‐loaded and additional DMRS N1 Symbols 13 13 20 24
Frequency‐first re‐mapping N2 Symbols 10 12 23 36

Within 3GPP, there are ongoing discussions about the non‐slot based processing. Compared to slot‐based processing, the processing time can be further reduced and there is a strong trend that the value of N1 would be three symbols only.

8.3.3 High Reliability and Availability

8.3.3.1 Core Network

Many services like Mission Critical Public Safety services require (extreme) high‐availability and reliability. Also, other services, e.g. traditional voice, chat, web browsing, video streaming, benefit from features that guarantee a high degree of network resilience. While network resilience can be increased by proper SW design or following certain Hardware (HW) deployment options (e.g. hot and cold stand‐by of nodes), 5G comes also with some built‐in network resilience and load balancing features.

One such feature is the concept of Access and Mobility Management Function (AMF) Sets and the enablers introduced for AMF resiliency, such as enablers for state‐efficient AMF deployments, planned AMF maintenance (e.g. frequent SW upgrades in case of micro‐services support) and AMF auto‐recovery. The AMF Region concept is like the concept of Mobility Management Entity (MME) pools in the Evolved Packet Core (EPC). Pooling of elements (hot and cold standby) and respective load balancing between core network elements improves system reliability and guarantees network service availability, even if a single Network Function (NF) instance fails. An AMF Set (see [11]) consists of AMFs that serve a given area and network slice. An AMF Region consists of one or more AMF Sets. AMF Region and AMF Set identifiers are encoded in the Globally Unique Access and Mobility Management Function Identity (GUAMI), which identifies the AMF assigned to a UE.

The AMF Set concept is used to allow an AMF storing its UE context and session data in the Unstructured Data Storage Function (UDSF) or in other backup AMFs belonging to the same AMF Set (called “backup AMF”). The backup AMF is determined based on the GUAMI of the failed AMF. The GUAMI assigned to the UE indicates the corresponding AMF Region and Set. Once an AMF fails and it peer nodes (e.g. 5G base stations, other AMF) detect the AMF failure, the connected 5G base stations are informed, release the UE specific signaling connection toward this AMF and mark the AMF as failed. However, the UE's RRC connection and possible user plane connection are maintained. In a failure case the base stations direct subsequent messages to a backup AMF, if available. If no backup AMF is available, the base stations select an AMF from the same AMF Set. The selected AMF must inform its peer nodes that it is now serving the UEs of the failed AMF. The selected AMF can process UE's transaction. Thus, the failure of the AMF instance does not impact services offered to the UE.

While the Region concept is not new (it is like the MME pool concept in EPC), 3GPP has newly introduced many features in Rel‐15 enabling auto‐recovery of an AMF, allowing easier software upgrades, load balancing of AMFs without any impact to the UEs. In Evolved Packet System (EPS), MME restoration requires release of RRC and S1 connections for all connected UEs and it requires UEs in idle mode to be paged almost simultaneously to perform load balancing tracking are update (TAU). This is both service impacting and may cause excessive signaling load in the network. However, with the new enablers specified for AMF resiliency, AMF planned maintenance and AMF failures are handled in a completely seamless manner to the UEs (see Chapter 4 for more details). One of the important enablers includes the ability for an UE to provide the AMF Set Identity (ID) as part of the 5G S‐Temporary Mobile Subscription Identifier (5G‐S‐TMSI) in the RRC signaling to the 5G base station. This allows the base station to dynamically select an AMF from the given AMF Set. Furthermore, an AMF pointer can point to multiple AMF instances allowing the base station to select any AMF instance and forward Non‐Access Stratum (NAS) messages to this AMF. In EPC, the UE provides only the S‐Temporary Mobile Subscriber Identity (S‐TMSI) including the MMEC (pointing to a single MME) in RRC signaling sent to the eNB. Thus, it is not possible for an eNB to know which other MME is able to process the UE transaction without requiring a re‐registration. Manual configuration of MMEGI in the eNB to map to an MMEC could be done in a proprietary manner however this may result in constraints on the number of unique MMECs available for a deployment (especially for big networks) as the MMECs must be unique across all MMEGIs in the network. Additional enablers allowing support for AMF scalability, load balancing and resiliency are explained in Chapter 4 of this book.

Instead of using another AMF from the same AMF Set as backup, the AMF can also store the context data in the UDSF (see Chapter 4) allowing any AMF in the AMF Set to retrieve the UE's context data and process UE's transactions. The UDSF is part of the data layer (like the Unified Data Repository UDR) and allows storing and retrieval of context and session data, or more generally of any unstructured data, by any NF from the control plane of the 5G Core. UPFs and application servers can optionally also store their session data in the UDSF. Figure 8.18 shows how the UDSF fits into the 5G Core architecture.

Diagram of UDSF as part of the 5G core architecture depicting with lines labeled N18/Nudsf linking to UDM, AMF, SMF, PCF, AF, AS, and UPF.

Figure 8.18 UDSF as part of the 5G core architecture.

The UDSF can be a standalone function or e.g. collocated with the UDR. The interface between UDSF and NFs N18/Nudsf is not specified by 3GPP in Rel‐15. Introduction of the UDSF for storing/fetching context and session data follows the data driven model known from cloud architectures with a clear separation between compute logic and data layer. Context storing and retrieval between similar NFs (e.g. AMFs of one AMF Region and Set) is no longer needed. The concept of storing session data in a data base external to the NFs can impose high demands regarding performance, e.g. very low delays when writing/reading in the data base, and availability on the data base. Thus, deployments and actual NF implementation should ensure that the frequency of storage and retrieval of data is balanced to enable high availability and resiliency of the NFs, at the same time ensure that there is no performance impact due to storage of UE context in the (external) UDSF. If the context is stored at the end of a procedure, this will not impact the performance of any real‐time and dynamic procedure and transaction ongoing in the network for a given UE, but allows for improved resiliency, scalability and availability (allowing any compute instance to process a UE transaction). For an AMF, it can be expected that a state‐efficient implementation concept is followed, i.e. storing a stable version of the UE context at the end of a certain procedure, and not storing UE context at the end of every single transaction.

Load balancing between AMFs of a certain Set is achieved by assigning a weight factor to each AMF according its capacity. The AMF provides this weight factor to connected 5G base stations so that the base station can select an AMF based on its weight factor. Without going into details, it should be noted that also overload control mechanisms were specified by 3GPP for AMF (e.g. N2 interface overload control and NAS level mobility management congestion control) and Session Management Function (SMF) (NAS level session management congestion control). These control mechanisms can lead to rejection of signaling messages and push back of UEs with a back‐off timer, i.e. a UE is only allowed connecting to the network after a certain time. Overload control mechanisms help avoiding failure and restart of a network element, thus leading to higher service availability.

In addition, from user plane perspective, 3GPP has standardized several new 5G QoS values and characteristics allowing delay and reliability critical applications to be delivered over 5G Core and Radio network. A detailed description of these 5G QoS values can be found in Chapter 6. Table 8.5 provides an overview of the standardized 5G QoS values for delay critical services.

Table 8.5 Standardized delay critical 5G QoS values.

5G QoS identifier Default priority level Packet delay budget (ms) Packet error rate Default maximum data burst volume (Bytes)
81 11  5 10−5  160
82 12 10 10−5  320
83 13 20 10−5  640
84 19 10 10−4  255
85 22 10 10−4 1358

8.3.3.2 Radio Network

It is obvious that the quality of the radio link between transmitter and receiver directly affects the overall system reliability. In most of the research related work, if not all, Signal to Interference plus Noise Ratio (SINR) is used to measure the quality of the radio link. The higher the SINR, the lower is the packet error probability, and hence the higher is reliability and the lower is latency. It is therefore important that URLLC UEs experience a SINR above a certain threshold with very high probability. On the high‐level, there are two ways to increase SINR:

  1. (1) enhancing the signal power, for example with increased redundancy, diversity, and
  2. (2) reducing the interference power via interference management, e.g. interference aware scheduling, interference cancelation receivers and so on.

Table 8.6 lists example technology components for enhancing reliability in the radio system.

Table 8.6 List of technology components for enhancing reliability.

Micro‐diversity Higher order SU‐MIMO diversity to reduce the probability of experiencing deep fades.
Macro‐diversity: multi‐connectivity Data duplication macroscopic transmission from multiple cells to the same UE to improve reliability. Robustness against shadow fading and cell failures.
Hybrid ARQ Enhanced time‐diversity and frequency‐diversity (in case of frequency hopping) by using HARQ with soft combining. Adding robustness toward potential link adaption imperfections. Blind repetition.
Enhanced control channel reliability High reliability of downlink control carrying resource grant, as well as uplink control carrying feedback information such as ACK/NACK and CSI. Achieved by using stronger coding, power boosting and asymmetric signal detection techniques.
Interference mitigation Advanced UE interference mitigation receivers (e.g. MMSE‐IRC or NAICS). Network‐based inter‐cell interference coordination.
Micro‐diversity

Having multiple antennas at either the transmitter or the receiver side or both is a resource efficient way to improve the SINR via spatial diversity. Particularly, single‐user (SU) single‐stream (i.e. Rank 1) transmission modes are the most relevant for URLLC use cases, as the goal is to improve performance on the lower tails of the SINR distribution. As reported in [12], URLLC devices should operate with at least 2 × 2 (preferably 4 × 4) SU single‐stream transmission schemes, i.e. maximizing the diversity order of the wireless link. After discussion in 3GPP, 4 × 4 scheme was selected to get sufficient diversity orders. To be more specific, with micro‐diversity:

  1. – Multiple antennas can be deployed at both transmitter and receiver side with single‐stream single‐user transmission modes to achieve high diversity order and related power gain, and decrease the SINR outage probability.
  2. – Support for both closed‐loop and open‐loop schemes. Closed‐loop typically offers the best performance but it is sensitive to feedback errors and out‐of‐date Channel State Information (CSI) reports. Therefore, the most appropriate transmission mode should be selected on a per‐user basis, depending on its speed, reliability requirements, among other relevant parameters.
  3. – Microscopic diversity is applicable to both data and control channels.

From concept level, the following high‐level Figure 8.19 illustrates how it works in general. With the assumption of independent fading channels among different antenna pairs, high diversity gain can be achieved.

Schematic of micro-diversity operation depicting 4 diodes with arrows from 2 boxes with box inside labeled precoding (left) and combining (right). An arrow labeled PMI is pointing from the right box to the left box.

Figure 8.19 Example of micro‐diversity operation.

Macro‐diversity

There is a variant of multi‐connectivity schemes providing a macroscopic diversity for increasing reliability. Macroscopic diversity, i.e. data duplication and redundant transmission/reception from multiple cells/TRPs (Total Radiated Power), is also required to combat the slow fading effects (or shadowing and/or blocking) and to provide mobility robustness during handovers as discussed later. In this regard, data duplication at the PDCP layer has been agreed for NR in 3GPP Rel‐15 [13]. At the lower layers, inter‐cell non‐coherent joint transmission is among the candidate transmission schemes. Macroscopic diversity also provides benefits in terms of resilience against failures of the cellular infrastructure.

Multiple‐cells

  • Different cells can allocate different resources to the same UE for the same packet, i.e. independent schedulers are used among cells. At the receiver side, soft combining of received data packets from multiple cells is performed. This applies to both UL and DL data.

Multiple‐TRPs

  • Use of multiple TRPs has been agreed with a focus on providing high data rate and diversity. For URLLC, multi‐TRP communication can be one of the potential enablers of high reliability of URLLC services in low frequency and high frequency bands. In multiple TRPs, data or control information can be shared among multiple TRPs to URLLC UEs by applying joint transmission schemes, where different versions of the same data packet or control information can be received jointly. The UE can combine them in the physical layer. Therefore, the diversity gain is achieved.

As an example, inter‐cell non‐coherent joint transmission can be implemented in diverse ways as discussed in [14]. Three well‐known techniques to increase robustness of a communication link are revisited for applications in the addressed scenario, namely Single‐Frequency Network (SFN), narrowband muting and macro‐diversity with soft combining as shown in Figure 8.20. Based on [14], it can be observed from simulation results that in a dense indoor deployments, inter‐cell coordination is a powerful approach to increase the reliability of the transmissions without incurring longer delays as it is the case with retransmissions.

4 Graphs of frequency vs. time, each depicts 4x3 table with 2 shaded boxes labeled UE1 and UE2. Graph d has 2 dark shaded boxes.

Figure 8.20 Example of baseline transmission and joint‐transmission: (a) baseline; (b) macro‐diversity/soft combining; (c) SFN; and (d) Narrow‐band muting.

We will now look at the performance for outdoor scenarios. In case of noise‐limited scenarios, soft combining is an appropriate solution candidate. Therefore, we will focus on the scheme with soft combing. In this scheme, non‐coherent transmission of the desired packet is done by cooperating TRPs, as depicted in Figure 8.20 b. The same data packet is sent from multiple TRPs independently. The UE applies soft combining on the received data packets. Such non‐coherent transmission can be done independently, such that each TRP performs independent scheduling and with multiple PDCCHs, one per cooperating TRPs.

One benefit of this technique is that it gives redundancy against some effects of the channel which are correlated over time and frequency, like blocking or radio link failure. Because the same packets are transmitted from multiple sources independently, it is less likely that all of them will be lost. Also, multiple independent simultaneous transmissions reduce the need for retransmission and thus the probability of long delays.

The following Figure 8.21 shows the performance difference between regular single TRP transmission and the studied multiple TRP transmission with soft combing at UE side. The 3GPP outdoor simulation environment is adopted, and it is assumed that 20% of the UEs are indoor. From the simulation results, we can see that with soft‐combing, the offered URLLC load is about 2.6 Mbps and in case with regular transmission, the value is about 1.8 Mbps which means more than 40% capacity gain due to the joint transmission from multiple TRPs.

Graph of delay vs. offered load depicting 6 coinciding ascending curves, each with markers representing for Baseline QPSK 1/3 (diamond), Softcomb QPSK 1/3 (asterisk), Baseline QPSK 2/3 (square), etc.

Figure 8.21 Performance comparison between baseline (regular unicast based transmission) and soft combining scheme.

High Reliable Control Channels

URLLC service requires tight latency and high reliability simultaneously. The data can be correctly received only, if the control channel is decoded correctly. Therefore, the control channel should have even higher reliability for URLLC services or at least on the same level as the data channel. There are many methods for improving the reliability of control channels. Due its importance, we will discuss various ways to increase the reliability of different control channels or control messages.

High Aggregation Level

With higher aggregation level (AL), the control information can be transmitted with more physical control channel resource elements, resulting in lower code rate coding schemes and lower order of modulation schemes which can be adopted for reducing the bit/symbol error rate. High aggregation levels up to 16 have been already supported in 3GPP Rel‐15 for URLLC control channels. Performance gain due to higher AL is obvious as indicated in Table 8.7.

Table 8.7 SINR gain due to higher AL with 40‐bit DCI.

SINR gain (dB) 4GHz, 4Rx 700 MHz, 2Rx
TDL‐A 30 ns TDL‐C 300 ns TDL‐A 30 ns TDL‐C 300 ns
AL 8 vs. AL 16 ∼2.4 ∼2.8 ∼3 ∼3.5
Compact Downlink Control Information (DCI)

Reducing unnecessary control bits in control information for URLLC services allows to further improve the reliability of control channels on top of high aggregation level or relax the bandwidth requirements for transmitting the control information.

Link level simulations are used to evaluate the potential performance gains coming from compact Downlink Control Information (DCI) design [15] with the following simulation parameters in Table 8.8 as agreed in 3GPP:

Table 8.8 Simulation parameters for compact DCI.

Parameter Value
DCI payload (excluding 24 bits Cyclic Redundancy Check [CRC]) 40 bits, 30 bits
System bandwidth 20 MHz
Carrier Frequency 4 GHz, 700 MHz
Number of symbols for CORESET (Control Resource Set) 2
CORESET BW (contiguous physical resource block [PRB] allocation) 20 MHz
Subcarrier spacing 30 kHz
Aggregation level Compact DCI study: 8, 16
Transmission type Interleaved
REG bundling size 6
Modulation QPSK (Quaternary Phase‐Shift Keying)
Channel coding Polar code (DCI)
Transmission scheme 1‐port precoder cycling
Channel estimation Realistic
Channel model TDL‐A (delay spread: 30 ns)
TDL‐C (delay spread: 300 ns)
UE speed 3 km h−1
Number of BS antennas 2Tx
Number of UE antennas 4Rx for 4G, 2Rx for 700 MHz
Residual target BLER 10−5
Deployment Urban macro as listed in 3GPP 38.802

Main objective of the system level simulation is comparing the performance of normal DCI (assumed to be 40 bits) and compact DCI (assumed to be 30 bits) with two‐symbol length CORESET (Control Resource Set).

The performance gain due to the 30‐bit compact DCI is summarized in Table 8.9. The comparison is based on the SINR at BLER = 10−4 as the curves have better statistical convergence at this level. We do not expect significant difference at BLER = 10−5 as the curves have a similar slope. Table 8.9 shows that less performance gain is observed for higher AL.

Table 8.9 SINR gain with 30‐bit DCI versus 40‐bit DCI.

SINR gain (dB) 4GHz, 4Rx 700 MHz, 2Rx
TDL‐A 30 ns TDL‐C 300 ns TDL‐A 30 ns TDL‐C 300 ns
AL 8 ∼0.4 ∼0.8 ∼0.4 ∼0.8
AL 16 ∼0.3 ∼0.3 ∼0.3 ∼0.4

Based on simulation results it can be observed that 0.4∼0.8 dB gain can be achieved with compact DCI (30 bits versus 40 bits) with AL 8 at BLER = 10−4. And for AL 16, even less gain around 0.3∼0.4 dB can be achieved with compact DCI with AL 16 at BLER = 10−4.

The potential impact on the overall system design, especially regarding flexibility, should be considered before making decisions of whether specifying compact DCI in 3GPP or not. In other words, both the performance gain and restrictions due to compact DCI need to be considered. To be more specific, depending on which information field(s) will be modified in compact DCI format comparing to regular DCI format, various adverse impacts can be expected. For example, reducing the size of the resource allocation fields in either time domain, frequency domain or both would limit the scheduling flexibility, which may result in reduced spectral efficiency. Similar impacts can be observed from other fields, e.g. MCS, HARQ ID, Redundancy Version (RV), etc.

One more aspect that need to be considered is the impact on the number of DCI format sizes and the number of blind decoding attempts when a UE is expected to monitor other DCI formats, e.g. when a UE supports both eMBB and URLLC services. A new compact DCI format will increase the UE complexity, introduces additional constraints on the monitored DCI formats and affects the blind decoding budget for the different formats.

Considering only up to ∼0.4 dB gain for AL16 (most likely to be used for URLLC services) with compact DCI and the possibly severe performance degradation due to various restrictions, it may not worth the effort to specify compact DCI unless more clear use cases and benefits can be identified which is an open topic for the coming Rel‐16 work in 3GPP.

Asymmetric Detection of ACK/NACK

As discussed earlier, protecting the NACK signal is more important than protecting the ACK signal, this is because erroneous NACK detection degrades the communication reliability (see [16,17]). On the other hand, wrongly decoding an ACK as a NACK message will not result in performance degradation in terms of reliability, only reducing the spectral efficiency due to unnecessary retransmission. This leads to the idea of using enhanced NACK protection by applying e.g. asymmetric signal detection. For this purpose, the threshold v for the binary hypothesis testing can be set in a way that the correct detection of NACK is favored as shown in Figure 8.22. Of course, the drawback of this approach is the higher probability of wrong detection of an ACK as a NACK compared to the case of symmetric signal detection, in which the same error probability is achieved for the miss detection of ACK and NACK. This results in unnecessary retransmissions. The performance gains due to asymmetric ACK/NACK detection can be found in [18].

Graph illustrating the decoding ACK/NACK signals depicted by 2 overlapping bell-shaped curves labeled P(y|NACK). At the middle of the curves are shaded regions with arrows labeled PAN and PNA.

Figure 8.22 Illustration of decoding ACK/NACK signals.

Adaptive Configuring CQI Report

The high reliability of existing transmission schemes of CQI report is not satisfied at low SINR. When a reported CQI value is decoded wrongly as higher value, it will result in selecting a higher level of MCS by the base station leading to reduced communication reliability. Different ways to increase the reliability of CQI report itself have been proposed, e.g. changing the allocated radio resource for sending CQI report or reducing the content of CQI report.

To improve the overall reliability, CQI report for URLLC services should be transmitted in a very reliable manner. In the operating principle specified for LTE (NR related discussion in 3GPP is ongoing), a fixed amount of radio resources is used for delivering CQI report over PUCCH. However, the achievable reliability with such a method is not sufficient, especially considering that there is a high chance that a reported wideband CQI value is decoded wrongly as higher value, which results in higher MCS selection and the before mentioned reduced communication reliability. Obviously, one way to increase the reliability is to repeat the same CQI information over time, however, the increased latency might be a problem. Other potential enhancements are the following:

  1. – Increased physical resource for URLLC UE CQI reporting while keeping the same CQI payload size as for eMBB UEs, e.g. 4 bits: with the increased resource, the effective coding rate can be reduced which leads to higher reliable CQI decoding at the gNB.
  2. – Define a smaller CQI payload while keeping the same resources between URLLC UEs and eMBB UEs: in this case the number of CQI values for URLLC UEs is smaller compared to eMBB UEs which leads to a reduced granularity of reported channel quality. With the same resource for CQI reporting, the reliability performance for CQI decoding can be improved.

In Figure 8.23 we compare the error probability of decoding CQI values as higher CQI values with a smaller CQI payload (Figure 8.23a: 3‐bit versus 4‐bit CQI, normal resources) or with utilizing double resources for CQI transmission (Figure 8.23b: 4‐bit CQI). The simulation assumptions from TS 36.104 [19] are used and the SINR is set at −3.9 dB. It can be seen from Figure 8.23 that double the resource will give more benefit as expected, while the gain from reduced CQI payload size (3‐bit versus 4‐bit) is not neglectable either considering the URLLC use case. In addition, it should be noted that the current LTE CQI performance requirement in 3GPP (1%) is not sufficient for NR URLLC. As a summary, it would be beneficial to consider ways for improving the reliability of CQI report itself from both standard and implementation point of view.

2 Graphs illustrating the performance of CQI report depicted by clustered bars representing for 4bit-CQI and 3bit-CQI (top) and Normal resources and Double resources (bottom).

Figure 8.23 Performance of CQI report.

Repetition of Scheduling Information

There are several ways to repeat scheduling information, e.g., repeating within the same CORESET, across different CORESETs, across different monitoring occasions and so on. We are focusing on the scenario where PDSCH is repeated. For this scenario, reliability of resource assignment messages can be increased by including the resource allocation information of the current transmission and sub‐sequent retransmissions, in case data repetition is supported as currently agreed in 3GPP Rel‐15, into the messages. In this case, even if a UE is missing one assignment message, the allocated resource could be identified with the subsequent assignment message or the previous assignment message.

For example, in case of blind repetition (i.e. continuous transmission without waiting for feedback) without time domain PDCCH repetition, if the UE missed a single multi‐TTI DCI (DCI scheduling K‐repetitions), it will miss the PDSCH transmission in all the scheduled TTIs for the data packet since the UE has no idea that the gNB has already started to send a data packet. In Figure 8.24 DL data transmission is taken as one example for illustration, with the assumption of K = 4. This scheme is called Option 1. With Option 1, a single DCI is used to indicate the PDSCH resource information over multiple concessive TTIs. Option 1 has smaller signaling overhead compared to other options discussed below where several types of repetitions are considered. However, from reliability point of view, it suffers from high error probability as it depends on a single shot transmission only. To be more specific, in case the UE misses the PDSCH scheduling information at the very beginning, it will miss all the following data packet repetitions as well.

Scheme of DL HARQ processing with multi-slot scheduling (Option 1) depicting 2 horizontal lines with southeast arrows in the middle from PDCCH to DCI (1,2,3,4), from PDSCH to D1, from PDSCH to D2, from PDSCH to D3, etc.

Figure 8.24 Example of DL HARQ processing with multi‐slot scheduling (Option 1).

A solution to avoid this situation is using the independent DL assignment message to schedule the resource for the current TTI only as shown below in Figure 8.25 (Option 2). Option 2 has at least two advantages: the higher PDCCH reliability as having several, separate DCIs and the ability to enable some type of frequency hopping or dynamic resource allocation. This comes with the drawback of increased signaling overhead due to several DL DCIs for the same data transmission.

Scheme of individual scheduling for each blind repetition independently (Option 2) depicting 2 horizontal lines with southeast arrows in the middle from PDCCH to DCI (1), from PDSCH to D1, from PDCCH to DCI (2), etc.

Figure 8.25 Example of individual scheduling for each blind repetition independently (Option 2).

One way to further improve reliability is to enable a gNB combining Option 1 and Option 2 in a way that DCI indicates the number of repetitions but also sends a DL assignment together with the repetition as illustrated in Figure 8.26 (Option 3).

Scheme of reliable transmission of DL assignment information (Option 3) depicting 2 horizontal lines with southeast arrows in the middle from PDCCH to DCI (1,2,3,4), from PDSCH to D1, from PDCCH to DCI (2,3,4), etc.

Figure 8.26 Reliable transmission of DL assignment information (Option 3).

Taking the example shown in the Figure 8.26 above where it is assumed to have maximal four transmissions and no ACK received during this period, the first assignment message includes the resource allocation information for all four transmissions. In the second slot, the resource assignment information is updated with three transmissions only, i.e. from the 2nd to the 4th transmission. Following the same principle, the last scheduling message includes the resource information for the last transmission only, i.e. the 4th transmission. The benefit of this method is the increased reliability of assignment messages. In case a UE misses one assignment message, the allocated resource could still be identified with the subsequent or the previous assignment message. The same principle can be applied for scheduling K transmissions for PUSCH. For this option, the gNB does not necessarily have to transmit PDCCH with every repetition. The gNB can choose the number of repetitions for PDCCH depending on the reliability target. Furthermore, the number of repetitions can be flexibly configured for the different UEs.

Another alternative of PDCCH repetition is shown in Figure 8.27 (Option 4) where the PDSCH resource assignment information is repeated before the first data transmission occurs. Under the assumption that the content of the repeated DCI is the same, it is sufficient if the UE can successfully decode only one PDCCH. Basically, the gNB can transmit the same DCI message multiple times using multiple PDCCH candidates in the search space.

Scheme of PDCCH repetition before data transmission (Option 4) depicting horizontal lines with southeast arrows in the middle from sets of PDCCH to m times and from sets of PDSCH to D1, D2, D3, and D4.

Figure 8.27 PDCCH repetition before data transmission (Option 4).

Regarding Option 4, there are a few factors that may limit the number of PDCCH repetitions in a TTI. Firstly, there could be PDCCH capacity and/or increased blocking probability, if PDCCH with large AL must be repeated a few times within the limited control resource. Secondly, there is a limit on the number of Control Channel Elements (CCEs) per slot where a UE can do channel estimation for PDCCH. According the current agreements in 3GPP Rel‐15, the maximum number of CCEs one UE can monitor within one slot is 56 in case of 15 and 30 kHz SCS, 48 in case of 60 kHz SCS and 32 in case of 120 kHz SCS. This would practically allow at most two repetitions for AL = 16 (or no repetition for 120 kHz SCS) considering that the UE also needs to monitor the CSS (Common Search Space) and possibly other candidates.

The successful PDSCH decoding probability of all four options can be derived as shown in Table 8.10.

Table 8.10 Overall error probability for different options of PDCCH repetition.

Option 1: P = (1 − ɛDCI)(1 − ɛD, K)
Option 2: images
Option 3: images
Option 4: P = (1 − (ɛDCI)m)(1 − ɛD, n)

ɛDCI: Probability of missing a DCI; ɛD, n: BLER of decoding data with n receptions; K: Maximum number of data transmissions; P: Overall PDSCH reliability; and m: number of PDCCH repetitions in Option 4.

From the analysis results shown in the above Figure 8.28 where K = 4 (ɛD, 1=10−2, ɛD, 2=10−3, ɛD, 3=10−4, ɛD, 4=10−5) is assumed, Option 1 (i.e. the option without any repetition) results in the worst performance putting strict requirements on control channel reliability. For the other options, in case the error probability of DCI decoding is low, there is no clear performance difference. When the error probability of DCI increases, for example to 10−2, Option 3 and Option 4 (with m = 3 and m = 4) still have similar performance, while Option 2 and Option 4 with m = 2 are not on the same level any more. If the error probability of DCI further increases, Option 4 with m = 4 gives the best performance followed by Option 3. From the results illustrated in the Figure 8.28 it can be concluded that in case the repetition number is the same, Option 4 performs best, followed by Option 3. However, in case the maximum number of repetitions cannot be achieved with Option 4 due to the limited number of CCEs which can be monitored by a UE within a slot as specified in 3GPP, then Option 3 becomes the best candidate solution.

Graph of Pfailure vs. ϵDCI depicting an ascending line (Option 1) and 5 ascending curves with markers representing for Option 2, Option 3, Option 4 (m=2), Option 4 (m=3), and Option 4 (m=4).

Figure 8.28 Error probability for PDSCH decoding.

HARQ Enhancements

As in all previous cellular systems, scheduling based transmission will be supported in both DL and UL in 5G NR. With dynamic scheduling, the network can assign resources to the UE in a very flexible manner according to the amount of data in the buffer and hence optimize radio resource utilization. Furthermore, URLLC traffic can be flexibly multiplexed together with eMBB traffic. URLLC traffic can be offered with a higher priority than eMBB traffic to minimize queuing latency. Considering URLLC traffic, one potential concern is the additional latency in UL due to the SR and resource grant before UL data transmission occurs. This delay is prolonged by potential HARQ retransmissions using dynamic scheduling. As discussed earlier, non‐slot based transmission can reduce the overall latency compared to slot based processing.

From latency point of view, TDD is more challenging than FDD. Non‐slot based scheduling based HARQ operation is discussed below. As an example, we consider now a 7‐symbol mini‐slot (GAP symbol is included in the DL mini‐slot just for illustration purposes) and only one switching point in the 14‐symbol slot.

The above Figure 8.29 illustrates one example with dynamic scheduling based UL transmission where the data packet arrives at a time instant in the 1st slot (UL mini‐slot) and the SR can be conveyed in the 2nd slot. Under the assumption that there is sufficient time for the gNB to process SR and scheduling UL resources, the first data transmission can take place in the 3rd slot. Due to very limited processing time between the 1st data transmission in slot #3 and the DL control in slot #4, slot #4 must be used for processing and preparing for feedback and resource allocation for potential retransmissions. Hence, slot #4 cannot be used for retransmission and the second transmission can only take place in slot #5 leading to additional latency. As a result, within a 1 ms time window, there could be no retransmission opportunity. This might not be sufficient for URLLC UEs at the cell edge, especially in case time duration for the transmissions is important to achieve high reliability within a very short time window, e.g. with limited UE Tx power in UL. It should be noted that with the agreement of allowing more than one DL/UL switching point within a 14‐symbol slot, there is a chance that latency can be reduced further, especially if processing time is not an issue.

Image described by caption and surrounding text.

Figure 8.29 Example of UL HARQ processing.

Different enhancements are under investigation to reduce retransmission latency, e.g. proactive repetition (aggregated retransmission or blind retransmission for URLLC). This is also referred to as the support of K repetitions for an UL transmission scheme with grant access. In case of proactive repetition, multiple resources in adjacent slots can be allocated to the same TB as illustrated in Figure 8.28 where two different scheduling options are shown. According to Option 1, after receiving SR in the second slot, the gNB can allocate resources for both initial transmission and potential retransmissions (for example up to K repetitions). Comparing to Figure 8.29, slot #4 can be utilized for the 2nd transmission. In the example given in Figure 8.30, the 1st transmission is sufficient and ACK is sent in slot #5. ACK can also serve the purpose of requesting the UE to stop all following transmissions of the same TB, and the pre‐allocated resources are released. The multi‐slot scheduling method shown in Figure 8.30 can be understood as one type of slot aggregation scheduling options, i.e. the same TB in multiple slots (with the same or different RVs). Multi‐slot scheduling can not only be used for reducing signaling overhead, but also for reducing the overall latency.

Schematic of UL HARQ processing with multi-slot scheduling with arrows marking GAP and packet arrival under Slot #1; SR transmission under Slot #2; etc. and ACK and stopping retransmission under Slot #5.

Figure 8.30 Example of UL HARQ processing with multi‐slot scheduling.

Another alternative (Option 2 in Figure 8.28) to achieve the goal of blind retransmission is sending UL resource information in each slot. Compared to Option 1, multiple independent DL signals (up to K under the assumption that one packet can be sent up to K times) are needed which can lead to signaling overhead and negatively impacts the transmission reliability.

In case of DL transmission, the proactive retransmission can be implemented as shown in the following Figure 8.31 (Option 1 only) with the help of multi‐slot scheduling. It is assumed that the 1st transmission is successfully received.

Schematic of DL HARQ processing with multi-slot scheduling with arrows marking packet arrival under Slot #1; DL data transmission, 1st transmission, etc. under Slot #2; 2nd transmission under Slot #3; etc.

Figure 8.31 Example of DL HARQ processing with multi‐slot scheduling.

Interference Mitigation

Either network‐based or terminal‐based techniques can be used for mitigating interference, which has been identified as a promising complementary solution to improve the SINR. Reducing the received interference from neighboring cells or terminals improves SINR. As a rule of thumb, canceling the strongest or the two strongest interference sources is usually sufficient to achieve most of the potential gain. In LTE, for example with Inter‐Cell Interference Coordination (ICIC) and Enhanced Inter‐Cell Interference Coordination (eICIC), interference cancelation methods are proactive and semi‐statically configured. Beamforming is another efficient way to reduce interference, especially considering high frequency bands. In 5G, more dynamic solutions tailored for increasing the reliability are recommended instead increasing the average capacity as done in LTE.

Seamless (Make‐Before‐Break) Handover

The requirement of 0 ms handover interruption time is considered for 3GPP Rel‐15 as part of the mobility enhancements for dual‐connectivity, but the simultaneous transmission to or reception from two intra‐frequency cells in either synchronous or asynchronous network mode may not be supported in Rel‐15.

From concept perspective, make‐before‐break type of handover can be considered on the base of path duplication operation. In DL, the same data packet will be transferred from both source and target cell during handover. In UL, objective is to have both source and target cell receiving the same data packet from the UE with one UL transmission only. The cell from which the UE receives a correct timing advance (TA) command is referred to as master cell, the other cell as slave cell. Before RACH (Random Access Channel) in the target cell, the source cell can be the master. After UE gets TA from the target cell, the target cell becomes the master cell. Since TA parameter is not available from both cells, extra guard is needed to protect in case of potential interference. As the same resource transmission cannot happen twice in UL, the UE does not need to have multiple Transmitter Exchange (TX) chains supporting reliable handover, possibly adding delay. The received UL data can be combined at either source cell, target cell or even at the mobility anchor in the core network (Serving Gateway (S‐GW)) depending on the operation mode. The following Figure 8.32 illustrates one example signaling diagram for enhanced handover to achieve 0 ms user plane interruption time.

Signaling diagram for enhanced handover depicting vertical lines labeled UE, Source cell, Target cell, and Mobility Anchor having arrows in between labeled Measurement report, HO request, HO ACK, Packet forwarding, etc.

Figure 8.32 Example of make‐before‐break handover.

References

All 3GPP specifications can be found under http://www.3gpp.org/ftp/Specs/latest. The acronym “TS” stands for Technical Specification, “TR” for Technical Report.

  1. 1 3GPP TR 38.913: “Technical Specification Group Radio Access Network; Study on Scenarios and Requirements for Next Generation Access Technologies”, 2017.
  2. 2 3GPP TR 22.804: “Study on Communication for Automation in Vertical domains (CAV)”, 2018.
  3. 3 H. Shariatmadari, Z. Li, S. Iraji, M. Uusitalo, and Riku Jantti: “Control channel enhancements for ultra‐reliable low‐latency communications”, Proc. IEEE International Conference on Communications Workshops (ICC), May 2017, pp 1‐6.
  4. 4 G. Pocovi, B. Soret, K. I. Pedersen, and P. Mogensen: “MAC Layer Enhancements for Ultra‐Reliable Low‐Latency Communications in Cellular Networks”, Proc. IEEE International Conference on Communications Workshops (ICC), May 2017, pp 1‐6.
  5. 5 K.I. Pedersen, G. Pocovi, and J. Steiner: “Punctured Scheduling for Critical Low Latency Data on a Shared Channel with Mobile Broadband”, Proc. IEEE Vehicular Technology Conference, September 2017, pp 1‐6.
  6. 6 3GPP TR 38.802: “Study on New Radio (NR) Access Technology; Physical Layer Aspects", 2017.
  7. 7 3GPP R1‐1804618: “On UL multiplexing between eMBB and URLLC”, 2018.
  8. 8 3GPP R1‐1710992: “Discussion on multiple SR configuration”, 2017.
  9. 9 3GPP TS 38.214: “Physical layer procedures for data”, 2018.
  10. 10 Singh, B., Tirkkonen, O., Li, Z., and Uusitalo, M.A. (2018). Contention‐based access for ultra‐reliable low latency uplink transmissions. IEEE Wireless Communications Letters 7 (2): 182–185.
  11. 11 3GPP TS 23.501: “Technical Specification Group Services and System Aspects; System Architecture for the 5G System", 2018.
  12. 12 G. Pocovi, M. Lauridsen, B. Soret, K. I. Pedersen, and P. Mogensen: “Signal Quality Outage Analysis for Ultra‐Reliable Communications in Cellular Networks”, Proc. IEEE Globecom Workshops (GC Workshops), December 2015, pp 1‐6.
  13. 13 3GPP TR 38.323: “Packet Data Convergence Protocol (PDCP) specification”, 2018.
  14. 14 V. Hytönen, Z. Li, B. Soret, and V. Nurmela: “Coordinated multi‐cell resource allocation for 5G ultra‐reliable low latency communications”, 2017 European Conference on Networks and Communications (EuCNC), June 2017.
  15. 15 3GPP R1‐1804616: “On further study of compact DCI for URLLC”, 2018.
  16. 16 H. Shariatmadari et al: “Control channel enhancements for ultra‐reliable low‐latency communications”, Proc. IEEE ICC Workshops, 2017.
  17. 17 Shariatmadari, H. et al. (2017). Resource allocations for ultra‐reliable low‐latency communications. International Journal of Wireless Information Networks 24 (3): 317–327.
  18. 18 H. Shariatmadari et al.: “Asymmetric ACK/NACK detection for Ultra‐Reliable Low‐Latency Communications”, to be published at EuCNC'18, June 2018.
  19. 19 3GPP TS 36.104: “Base Station (BS) radio transmission and reception”, 2018.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset