ETSI GR NGP 008 V1.1.1 (2019-01)

Next Generation Protocol (NGP) Mobile Deterministic Networking

DGR/NGP-008

General Information

• Status: Published
• Publication Date: 23-Jan-2019
• Technical Committee: NGP - Next Generation Protocols
• Current Stage: 12 - Completion
• Due Date: 31-Jan-2019
• Completion Date: 24-Jan-2019

Standards Content (Sample)

GROUP REPORT
Next Generation Protocols (NGP);
Mobile Deterministic Networking
Disclaimer
The present document has been produced and approved by the Next Generation Protocols (NGP) ETSI Industry Specification
Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR NGP 008 V1.1.1 (2019-01)

Reference
DGR/NGP-008
Keywords
mobile, next generation protocol, requirements

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR NGP 008 V1.1.1 (2019-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 5
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Background and Motivation . 10
4.1 Determinism in fixed networks . 10
4.2 Introduce determinism to mobile network . 12
5 Gap analysis . 13
5.1 General . 13
5.2 Lack of support for precise time synchronization in the air interface . 13
5.3 Lack of support for deterministic air interface . 14
5.4 Lack of support for deterministic delivery in 3GPP network elements . 14
5.5 Lack of support for performance budget decomposition . 14
5.6 Lack of support for ultra-high reliability . 14
5.7 Lack of support for deterministic handover. 15
5.8 Lack of support for interworking with legacy Industrial Ethernet . 15
6 Main challenges . 16
6.1 General . 16
6.2 Air interface enhancement on synchronization . 16
6.3 Air interface enhancement on determinism . 17
6.4 End-to-end QoS model for determinism . 17
6.5 Ultra-high reliability assurance . 17
6.6 Interruption limitation of handover . 18
7 Key issues . 18
7.1 General . 18
7.2 Time synchronization over air interface . 18
7.3 QoS budget decomposition. 18
7.4 Achieving determinism in air interface . 19
7.5 Achieving determinism within the 3GPP network elements . 19
7.6 Maintaining determinism during handover . 19
7.7 Interworking with Industrial Ethernet . 20
8 Potential Solutions . 20
8.1 General . 20
8.2 Time synchronization over radio . 21
8.3 E2E QoS decomposition . 22
8.4 Conflict avoidance . 23
8.5 Path redundancy . 24
8.6 On-time delivery . 25
8.7 Interworking with industrial network . 27
Annex A: Authors & contributors . 28
ETSI
4 ETSI GR NGP 008 V1.1.1 (2019-01)
Annex B: Change History . 29
History . 30

ETSI
5 ETSI GR NGP 008 V1.1.1 (2019-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Next Generation Protocols
(NGP).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document focuses on how to achieve determinism in 3GPP mobile networks. The goal is to ensure the
percentage value of the amount of sent network layer packets successfully delivered to a given node within the time
constraint required by the targeted service is not less than reliability. The work aims to analyze gaps, discuss challenges,
and identify the key issues to realize deterministic transmission in mobile network. Moreover, some recommendations
and solutions will be proposed.
Introduction
URLLC is one of three major usage scenarios that need to be supported in 5G. As defined in 3GPP TS 22.261 [i.1],
though some applications come with moderate performance requirements, some applications demand stringent
performance, especially those in the industry.
ETSI
6 ETSI GR NGP 008 V1.1.1 (2019-01)
One of the most important visions of URLLC is to change the industry fundamentally. Take mobile robots as an
example, which have numerous applications in the future factories. The mobile robots are programmable machine that
can execute variety of tasks, e.g. assistance in work steps and transport of goods, materials around industrial
environment with large scale. They are monitored and controlled by a guidance control system. The stringent
requirements of control message transmission are necessary to get an up-to-date process information to avoid collisions
between mobile robots, to assign driving jobs to the robots and to manage the operations of robots. A typical mobile
robot in industry is AGV (Automatic Guided Vehicle). It can transport goods and materials in a large manufacturing
facility (the length and width may be up to hundreds of meters). The mobile network is the most promising
communication technology due to the large-scale mobility of the vehicles. In order to ensure a collision free movement,
the high-speed vehicles need to exchange real-time messages with controller. In addition, the vehicles are demand to
transport the semi-manufactured goods from one assembly line to another in time; therefore, the control messages
should be delivered to those vehicles with small jitter, which can make sure that the goods are transported accurately so
as to improve the efficiency. More specifically, the communication in some mobile robot scenarios may require the
transmission latency to be 1 to 10 ms, jitter be less than 50 % of latency and the reliability should be above six nines
(99,9999 %) [i.17]. Another yet more stringent example in industry is the motion control, which is responsible for
controlling moving and/or rotating parts of machines in a critical manner. Due to the movements/rotations of
components in a wide area, mobile network is a feasible approach. As illustrated in 3GPP TR 22.804 [i.17], this
application requires that the end-to-end latency to be as low as 1 ms, the jitter as low as 1 us, and reliability as high as
six nines, ideally even eight nines.
The time synchronization with high accuracy between UEs or between UE and application server is also required. In
3GPP TR 22.804 [i.17], it has been agreed that the 5G system should support a very high synchronicity between a
communication group of UEs with the accuracy of 1 µs or below. In discrete manufacturing, different UEs are required
to cooperate at exactly the same time. Any unsynchronized actions between the UEs may lead to a damage or
interruption in the production line with possibly huge financial loss and safety problem. For example, the motion
controller sends a command to the mechanical arm and informs how to act at specified time instant. If it is not
synchronized with the controller, the arm will act in a wrong manner over time, which may fail to work or even hurt
people. Smart grid is another important use case which benefits from time synchronization. For example, as more and
more distributed power source is used, determination of fault location in high-voltage lines is very important for system
stability in distribution electricity. The electricity fault will generate two electricity waves at the fault location
transmitted towards both ends of the electricity line. The waves can be detected by two UEs in both sides of the fault
location. The two UEs record the time of receiving the wave and send the time to the server. As the two waves are
generated simultaneously at the fault location, given that the two UEs are synchronized and the distance between them
is known, the server can calculate the fault location by the time information. The accuracy of synchronization between
the UEs impacts the error of the fault location. Generally, 900 m deviation in the distance is brought in as a result of
3 μs accuracy.
When a network can provide end-to-end ultra-reliable packet transmission with bounded small values of latency/jitter, it
is said to be a deterministic network. And in some applications, the deterministic networks are also required to provide
precise end-to-end time synchronization.
With respect to current mobile network, the application scenarios described above cannot be satisfied. The queuing in
forwarding nodes may introduce large latency and jitter. The theoretical reliability of a single device is usually below
six nines, which, even without packet loss, definitely cannot meet the required reliability of end-to-end path. Moreover,
There is no mechanism to realize high-accuracy (<1 us) time synchronization between UE and RAN node. As a result,
the mobile network cannot guarantee determinism yet, but in order to support URLLC applications, the mobile network
has to expand its capability and support deterministic networking.

ETSI
7 ETSI GR NGP 008 V1.1.1 (2019-01)
1 Scope
The present document specifies the gaps, challenges, issues and potential solutions of achieving mobile deterministic
networking in 5G system.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] 3GPP TS 22.261 (V16.0.0): "Service requirements for the 5G system".
[i.2] IEEE: "Time-Sensitive Networking Task Group".
NOTE: Available at http://www.ieee802.org/1/pages/tsn.html.
[i.3] IETF: "Deterministic Networking Working Group".
NOTE: Available at https://datatracker.ietf.org/wg/detnet/about/.
[i.4] 3GPP TS 38.300 (V1.1.1): "NR and NG-RAN Overall Description".
[i.5] 3GPP TS 23.501 (V1.2.0): "System Architecture for the 5G System".
[i.6] 3GPP TS 23.502 (V1.2.0): "Procedures for the 5G System".
[i.7] 3GPP TSG-RAN WG2 #99, R2-1710272: "Inter MN handover without SN change".
[i.8] IEEE: "TSN Components".
NOTE: Available at http://www.ieee802.org/1/files/public/docs2017/tsn-farkas-def-0317-v01.pptx.
[i.9] IEEE Std 1588™ (2008) (Revision of IEEE Std 1588 (2002)): "IEEE Standard for a Precision
Clock Synchronization Protocol for Networked Measurement and Control Systems".
[i.10] ETSI GS MEC 002 (V2.1.1): "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[i.11] ETSI TR 138 913 (V15.0.0): "Study on Scenarios and Requirements for Next Generation Access
Technologies".
[i.12] IEEE SA - 802.1Qav™ (2009): "IEEE Standard for Local and metropolitan area networks -
Virtual Bridged Local Area Networks Amendment 12: Forwarding and Queuing Enhancements for
Time-Sensitive Streams".
[i.13] IEEE SA - 802.1Qbv™ (2015): "IEEE Standard for Local and metropolitan area networks -
Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic".
ETSI
8 ETSI GR NGP 008 V1.1.1 (2019-01)
[i.14] IEEE 802.1CM™: "Time-Sensitive Networking for Fronthaul".
NOTE: Available at http://www.ieee802.org/1/pages/802.1cm.html.
[i.15] IETF draft-dt-detnet-dp-sol-02: "DetNet Data Plane Encapsulation".
NOTE: Available at https://www.ietf.org/archive/id/draft-dt-detnet-dp-sol-02.txt.
[i.16] 3GPP TSG RAN #81, RP-182089: "New SID on Physical Layer Enhancements for NR Ultra-
Reliable and Low Latency Communication (URLLC)".
NOTE: Available at http://www.ieee802.org/1/pages/802.1cc.html.
[i.17] 3GPP TR 22.804 (V1.2.0): "Study on Communication for Automation in Vertical Domains".
[i.18] ETSI GS NGP 013: "Next Generation Protocols (NGP); Flexilink: efficient deterministic packet
forwarding in user plane for NGP; Packet formats and forwarding mechanisms".
[i.19] 3GPP TR 36.842 (V12.0.0):" Study on Small Cell enhancements for E-UTRA and E-UTRAN;
Higher layer aspects".
[i.20] OPC Foundation: "OPC-Unified Architecture".
NOTE: Available at https://opcfoundation.org/about/opc-technologies/opc-ua/.
[i.21] ETSI GR NGP 003: "NGP Next Generation Protocol; Packet Routing Technologies".
[i.22] IEEE Std 802.3br™ (2016): "Standard for Ethernet Amendment 5: Specification and Management
Parameters for Interspersing Express Traffic".
[i.23] IEEE Std 802.1Qbu™: "IEEE Standard for Local and metropolitan area networks - Bridges and
Bridged Networks - Amendment 26: Frame Preemption".
[i.24] IEEE Std 802.1Qch™: "IEEE Standard for Local and metropolitan area networks - Bridges and
Bridged Networks - Amendment 29: Cyclic Queuing and Forwarding".
[i.25] IEEE Std 802.1Qcr™: "Bridges and Bridged Networks Amendment: Asynchronous Traffic
Shaping".
[i.26] IEEE Std 802.1CB™: "IEEE Standard for Local and metropolitan area networks - Frame
Replication and Elimination for Reliability".
[i.27] IEEE Std 802.1Qca™: "IEEE Standard for Local and metropolitan area networks - Bridges and
Bridged Networks - Amendment 24: Path Control and Reservation".
[i.28] IEEE Std 802.1Qci™ (2017): "IEEE Standard for Local and metropolitan area networks - Bridges
and Bridged Networks - Amendment 28: Per-Stream Filtering and Policing".
[i.29] IEEE Std P802.1AS-Rev™ (2017): "IEEE Draft Standard for Local and Metropolitan Area
Networks - Timing and Synchronization for Time-Sensitive Applications".
[i.30] IEEE Std 802.1AS™ (2011): " IEEE Standard for Local and Metropolitan Area Networks -
Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks".
[i.31] IEEE Std 802.1Qat™: "IEEE Standard for Local and Metropolitan Area Networks - Amendment
14: Stream Reservation Protocol (SRP)".
[i.32] IEEE Std 802.1Qcp™ (2018): "IEEE Standard for Local and metropolitan area networks - Bridges
and Bridged Networks - Amendment 30: YANG Data Model".
[i.33] IEEE Std 802.1CS™: "Link-local registration protocol".
ETSI
9 ETSI GR NGP 008 V1.1.1 (2019-01)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purpose of the present document, the following terms apply:
determinism/deterministic transmission: end-to-end ultra-reliable packet transmission with bounded small values of
latency/jitter, i.e. the percentage value of the amount of sent network layer packets successfully delivered to a given
node within the time constraint required by the targeted service is not less than reliability
NOTE: It is similar to the objectives of IEEE TSN TG [i.2] and IETF DetNet WG [i.3].
3.2 Symbols
For the purposes of the present document, the following symbols apply:
d max delay value required
j max jitter value required
r min reliability value required
d’ target delay value
3.3 Abbreviations
For the purpose of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
5QI 5G QoS Indicator
AF Application Function
AGV Automatic Guided Vehicle
BLER BLock Error Rate
CBS Credit Based Shaper
CN Core Network
CP Control Plane
CPRI Common Public Radio Interface
CU Central Unit
DASH Dynamic Adaptive Streaming over HTTP
DC Dual Connectivity
DetNet Deterministic Networking
DN Data Network
DU Distributed Unit
DU/CU Distributed Unit/Central Unit
E2E End-to-End
eMBMS evolved Multimedia Broadcast/Multicast Service
eNB evolved NodeB
ERP Enterprise Resource Planning
GNSS Global Navigation Satellite System
GPS Global Positioning System
HARQ Hybrid Automatic Repeat reQuest
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
LTE Long Term Evolution
MEC Multi-access Edge Computing
MES Manufacturing Execution System
NG Next Generation
NGP Next Generation Protocols
NR New Radio
NSI Network Slicing Instance
ETSI
10 ETSI GR NGP 008 V1.1.1 (2019-01)
NSSI Network Slicing Subnet Instance
OPC-UA Open Platform Communications Unified Architecture
PCF Policy Control Function
PDU Protocol Data Unit
PLC Programmable Logic Controller
PRACH Physical Random Access CHannel
QFI QoS Flow Identify
QoS Quality of Service
RAN Radio Access Network
RRC Radio Resource Control
RRU Remote Radio Unit
SCADA Supervisory Control And Data Acquisition
SFN System Frame Number
SIB System Information Block
TA Timing Advance
TAS Time-Aware Shaper
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/Internet Protocol
TN Transport Network
TR Technical Report
TS Technical Specification
TSN Time-Sensitive Networking
UE User Equipment
UP User Plane
UPF User Plane Function
URLLC Ultra-Reliable and Low-Latency Communication
UTC Coordinated Universal Time
VM Virtual Machine
4 Background and Motivation
4.1 Determinism in fixed networks
In contrast to the newly issued deterministic networking in mobile network, the determinism realization in fixed
networks has been well studied. In order to discuss determinism in mobile network, it is necessary to review those
works first.
ETSI
11 ETSI GR NGP 008 V1.1.1 (2019-01)
Time synchronization:
Synchronization
• Timing and Synchronization (802.1AS) Includes a profile of IEEE 1588
Bounded low latency and jitter:
• Credit Based Shaper(802.1Qav)
• Frame preemption (802.3br & 802.1Qbu)
Latency & jitter • Time-Aware Shaper (802.1Qbv)
• Cyclic Queuing and Forwarding (802.1Qch)
TSN
• Asynchronous Traffic Shaping (P802.1Qcr)
Components
Failover:
Failover • Frame Replication and Elimination (P802.1CB)
• Path Control and Reservation (802.1Qca)
• Per-Stream Filtering and Policing (802.1Qci)
Reliability
• Reliability for time sync (P802.1AS-Rev)
Zero
congestion loss
Dedicated resources & API:
• Stream Reservation Protocol (802.1Qat)
• TSN configuration (P802.1Qcc)
• YANG (P802.1Qcp)
Resource mgmt
• Link-local Registration Protocol (P802.1CS)

Figure 1: The protocol family of TSN
The IEEE Time-Sensitive Networking (TSN) Task Group [i.2] realizes determinism over IEEE 802 networks. It is a
protocol family rather than a invariable method to satisfy the same requirements of several particular applications, as
illustrated in Figure 1 [i.8]. There are many protocols proposed, and the cost of realizing different TSN features varies.
Take CBS (Credit Based Shaper [i.12]) and TAS (Time-Aware Shaper [i.13]) as an example. Both of those two
protocols are proposed to support bounded latency/jitter. In contrast to CBS, TAS can achieve lower latency and jitter.
Nevertheless, it takes more to enable TAS in the network. TAS demands precise time synchronization and the time-
aware schedule of every node from end to end, while the CBS does not require time synchronization or a
comprehensive schedule. Thus, with the requirements of an application, a subset of TSN features should by carefully
selected so as to satisfy the critical communications with lowest cost. One example is IEEE 802.1CM [i.14], which is
proposed to enable the transport of time sensitive fronthaul streams in Ethernet bridged networks. It will collect the
requirements for fronthaul networks and provide guidance for meeting those requirements, which includes the selection
TSN features in order to build networks capable of transmitting fronthaul streams like CPRI and the description how the
selected TSN features and components can be combined, configured and applied to meet the requirements of fronthaul.
ETSI
12 ETSI GR NGP 008 V1.1.1 (2019-01)
TSN
TSN
service service
End-to-end DetNet service
TSN end Edge Relay Edge TSN end
system node node node system
Emulated TSN service
Figure 2: TSN over DetNet
In contrast to the TSN, which realizes determinism in Layer 2, the IETF Deterministic Networking (DetNet) Work
Group [i.3] focuses on deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where
such paths can provide bounds on latency and jitter, and with high reliability. The purposes of DetNet are as follows. In
the wide area network environment, due to the well-known problems of over-large broadcast domains of Layer 2
networks, the combination of routed/bridged solutions is preferred. Moreover, it is important to integrate components of
existent Industrial Ethernet systems and components of deterministic networks (e.g. TSN-based system), since there is a
very large base of installed equipment which utilizes differing technologies. Figure 2 illustrates a scenario of how
DetNet works. It provides services for TSN end systems over a DetNet enabled network. The end systems are two TSN
islands in two distant location, and DetNet enables the long-distance, deterministic communication between the those
two end systems with edge nodes and relay nodes [i.15].
The Flexilink proposed to ETSI GR NGP 003 [i.21] and ETSI GS NGP 013 [i.18] can also be applied to QoS-
guaranteed service. Instead of complying with existing TCP/IP protocol suite, Flexilink introduces a new network
architecture, in which the information needed to route packets is carried separately from the packets themselves. The
links between network elements are formatted into slots with 64 octets in length and the slots are grouped into
allocation periods. During the transmission, the packets of each deterministic flow are assigned to one or more slots per
allocation periods, which will not be occupied by other flow. Moreover, the packets of each flow are switched
separately within the network elements. Therefore, there is no interference between deterministic flows and the QoS can
be guaranteed.
The principles of above-mentioned works can be referenced, but they cannot entirely solve the problems in the mobile
network since they are proposed to achieve determinism in fixed networks. Nevertheless, there are some big differences
between mobile network and fixed network, e.g. the time-varying air interface and the mobility that needed to support.
Therefore, in order to support URLLC applications, it is necessary to introduce determinism to mobile network.
4.2 Introduce determinism to mobile network
CP
Edge
UE DU F1-U CU UP N3 UP
3GPP
APP
RRU
Beyond
Virtual
(e)CPRI APP
switching
3GPP
Cloud
Figure 3: The basic model of mobile network
NOTE: The mobile network model presented above intends to cover all the networking scenarios. For a particular
mobile network, not all the network elements and user plane (UP) interfaces are necessary. For example,
in small cell scenario, the RRU, DU and CU will be one single node.
ETSI
13 ETSI GR NGP 008 V1.1.1 (2019-01)
It is of great importance to support URLLC applications in 5G network. The existent works on achieving determinism
in fixed network is not applicable in mobile network. In order to enable 5G to support critical traffic, the Mobile
Deterministic Networking is proposed, which aims to support deterministic service in mobile network from an end-to-
end perspective.
As depicted in Figure 3, there may be multiple parts, i.e. 3GPP network elements and UP interfaces, in the user plane of
mobile network from UE to UP. The interfaces between those 3GPP elements (e.g. F1-U, N3) can be radio, or those
networks beyond 3GPP (transport networks, TNs), such as packet switching networks or virtual switching in the cloud
(CloudRAN, data center, etc.). The operation procedures and technologies of the UP interfaces and 3GPP elements are
different from each other, and it may be difficult to realize over all determinism by one management/control entity and
with only one deterministic technology.
The requirements of URLLC applications is described end-to-end; therefore, the Mobile Deterministic Networking
should also provide determinism from an end-to-end perspective. Reforming and coordinating all the 3GPP elements
and UP interfaces from end to end is inevitable. It can realize the determinism in each of them by enhancing air
interface for URLLC or using TSN networks to replace conventional best-effort networks, and they become
deterministic islands just like TSN islands, which are disconnected. Those technologies are necessary but not sufficient.
An additional solution should be proposed to coordinate those islands, like DetNet.
There are many gaps and challenges to realize deterministic networking in mobile network. clause 5 and clause 6 will
discuss them respectively. Then, based on the previous discussion, clause 7 and clause 8 will present the key issues and
potential solutions.
5 Gap analysis
5.1 General
The 3GPP network elements and the UP interfaces between them may operate differently and be managed/controlled by
different entities. Therefore, it is not practical to utilize an entity to directly manage or control all the nodes from end to
end to realize determinism. The basic idea of Mobile Deterministic Networking is to ensure that the packet delivery
within them is deterministic, and then coordinate them to achieve end-to-end determinism. The TSN-like methods are
proposed to achieve determinism in each part of mobile network, and the DetNet-like methods to coordinate those parts
to realize end-to-end deterministic transmission.
Regarding to current mobile network, several gaps which are important to achieve deterministic networking are
analyzed in following clauses.
5.2 Lack of support for precise time synchronization in the air
interface
RAN nodes can obtain high precision time from GPS or through time synchronization with other RAN nodes or
application server by IEEE 1588 [i.9]. The RAN nodes then can act as the common time synchronization sources to
UEs, and the time synchronization between UEs or between UE and application server can be realized.
The time synchronization discussed here means the alignment of absolute time, which is different from the
synchronization with synchronization signals. In LTE, the synchronization with physical synchronization signals
between UE and eNB is used for demodulation by aligning the boundary of the symbol and the frame. The UE and the
eNB have a common understanding of the frame number and frame boundary but without the alignment of absolute
time.
In LTE, the UE can perform absolute time synchronization with the eNB by receiving SystemInformationBlockType16
(SIB16) introduced in Release 11 [i.16]. Broadcasting system time via SIB16 is beneficial to various use cases such as
GNSS, eMBMS, DASH and local time provisioning. In the SIB16, the field timeInfoUTC is the coordinated universal
time corresponding to the SFN boundary at or immediately after the ending boundary of the SI-window in which SIB16
is transmitted. Based on timeInfoUTC, UE can also obtain local time and GPS time with the other fields in SIB16.
Nevertheless, the timeInfoUTC counts the number of UTC seconds since 00:00:00 on Gregorian calendar date
1 January, 1900 in 10 ms units. Thus, none of those time can satisfy the time synchronization requirements of industrial
applications.
ETSI
14 ETSI GR NGP 008 V1.1.1 (2019-01)
5.3 Lack of support for deterministic air interface
The air interface is the most important and unique part in the mobile network. In order to realize determinism from end
to end, the wireless channels should be with high reliability as well as bounded latency and jitter.
The essential difference between wireless and cable transmission is that a cable is a closed environment in which
transmission characteristics are stable, whereas wireless transmission is susceptible to variation as the UE and objects in
the environment move. Causes include spatial dispersion of radio waves, delay spread, Doppler spread, angle spread,
and signal fading, as well as interference from other radio sources. Those effects will lead to the increase of BLER
(Block Error Rate), and reduce the transmission reliability. Currently, the retransmission, i.e. HARQ, is the method
applied in LTE to get rid of the influence of lost packets and ensure the reliability. But it may introduce large latency
and jitter, and violate the determinism. What is more, even if the retransmission can be finished within a very short
time, the resulting reliability may not meet the requirement once the interference lasts long enough and causes large loss
rate.
5.4 Lack of support for deterministic delivery in 3GPP network
elements
To realize deterministic networking, all the 3GPP network elements in a mobile network should support deterministic
delivery, which allows the packets that need to be forwarded to stay in queues with bounded time. Otherwise, the end-
to-end latency cannot be bounded.
One of the mechanisms to achieve deterministic delivery in TSN is Time-Aware Shaping defined in IEEE
802.1Qbv [i.13]. According to the protocol, the sender and the intermediate nodes are time-synchronized and have pre-
configured schedules, they know the time that packets arrive (except the sender) and the time the packets should be
delivered, i.e. the packet forwarding time within a TSN node is bounded. And the end-to-end latency and jitter are
bounded once all the nodes are with bounded delivery time.
The similar principles can be applied for achieving determinism in a mobile network. All the 3GPP network elements
should make sure that the critical packets pass them with bounded time. However, the functionality descriptions of gNB
and UPF in 3GPP TS 38.300 [i.4] and 3GPP TS 23.501 [i.5] do not support deterministic delivery, and nor does the UE.
Due to the queuing of best-effort traffic, after a packet arrived, they cannot ensure that the packet is sent within a
specific interval.
5.5 Lack of support for performance budget decomposition
Due to their diverse control/management procedures, all the 3GPP elements and UP interfaces along the transmission
path need to know their own performance budgets to provide end-to-end deterministic service. They requires to be
aware of the allowed latency or jitter interval it takes for a packet to transit through them, i.e. the performance budgets
of them, and make sure that all the 3GPP elements and UP interface adhere to their own budgets. Otherwise, they
cannot cooperate to achieve the end-to-end determinism.
However, the QoS characteristics in 5G system only describe the end-to-end performance requirements, and each of
3GPP elements or UP interfaces cannot infer its own performance budget from that. According to the 5G QoS model
described in 3GPP TS 23.501 [i.5], the control plane (CP) in 5G maintains the QoS parameters of every QoS flow,
which only contains the end-to-end performance requirements. And there is no mechanism defined in 3GPP to
decompose the end-to-end performance. Moreover, there is no control interface or message defined to distribute the
specific budget to them.
5.6 Lack of support for ultra-high reliability
The reliability is defined as the percentage value of the amount of sent network layer packets successfully delivered to a
given node within the time constraint required by the targeted service, divided by the total number of sent network layer
packets. As illustrated in 3GPP TS 22.261 [i.1], some URLLC applications in industry may require ultra-high end-to-
end reliability, e.g. as high as six nines.
ETSI
15 ETSI GR NGP 008 V1.1.1 (2019-01)
Despite the air interface, there is no mechanism to ensure the reliability of the rest part of a mobile network. And the
packet failure detection and response mechanism can only be employed by the layer above PDU layer of mobile
network, for example the retransmission of TCP. However, it may not be applicable for some URLLC scenarios, due to
unacceptable latency and jitter introduced. Therefore, the packets of those applications should be delivered with
extremely high reliability to avoid potential retransmission. However, the reliability can be reduced by equipment
failures, congestion losses, etc. and may not satisfy the ultra-high reliability required by some URLLC applications.
In some use cases, a looser requirement of reliability is presented. In industry automation, a safety function is enabled
by safety message exchange between controller and actuator. This message exchange is periodic. Packet loss is not
allowed in consecutive periods. If two consecutive packets fail, the application will think the current communication
unreliable and releases the connection. For example, there are two robots cooperating with each other. The master robot
sends safety data to the slave robot in periodic patterns. If two consecutive safety messages are not successfully
delivered, the connection between the automation functions in the two robots discontinued. However, as described in
ETSI TR 138 913 [i.11], the current reliability is defined and considered for one packet but not for consecutive packets.
And there is no mechanism to ensure the reliability of two consecutive packets now.
5.7 Lack of support for deterministic handover
The significant superiority of Mobile Deterministic Networking over the fixed network solutions is the support of
mobility, which may lead to the execution of handover procedure. And the determinism should be maintained before,
during or after the execution of procedure.
However, the currently defined handover procedure cannot meet the requirement. The handover procedure will change
the transmission paths, and the switching between those two paths may violate the determinism. As described in 3GPP
TS 38.300 [i.4] and 3GPP TS 23.502 [i.6], after UE already switches to target RAN, the downlink UP packets that had
already sent to the source RAN will be forwarded to the target RAN and then sent to UE. During this process, the
packets sent to the target RAN has to be buffered, and cannot be forwarded until the last packet (end marker) from
source RAN has been sent to UE. That will lead to large latency and jitter (e.g. tens of milliseconds in LTE), and may
not be acceptable.
The mobility support in MEC environment may also violate determinism. The MEC (Multi-access Edge Computing) is
a promising way to reduce the end-to-end latency. As described in ETSI GS MEC 002 [i.10], the mobile edge system
should be able to maintain connectivity between a UE and an application instance. If the target RAN after the handover
is associated with the same mobile edge host as the source RAN or the application is state-independent, the switching
between different paths may face the same problems of conventional handover discussed a
...