Content uploaded by Madhusanka Liyanage
Author content
All content in this area was uploaded by Madhusanka Liyanage on Jul 20, 2020
Content may be subject to copyright.
Local 5G Operator Architecture for Delay Critical Telehealth
Applications
Rakshitha De Silva∗, Yushan Siriwardhana†, Tharaka Samarasinghe‡, Mika Ylianttila§, Madhusanka Liyanage¶
∗‡ Department of Electronic and Telecommunication Engineering, University of Moratuwa, Sri Lanka.
†§ ¶Centre for Wireless Communications, University of Oulu, Finland.
‡Department of Electrical and Electronic Engineering, University of Melbourne, Australia.
¶School of Computer Science, University College Dublin, Ireland.
Email: 169221f@uom.lk∗,{firstname.lastname}@oulu.fi†§ ¶, tharakas@uom.lk‡, madhusanka@ucd.ie¶
Abstract—Network softwarization enables the novel concept
of Local 5G Operator (L5GO) networks, for deploying localized
5G solutions to serve case and location specific communication
needs. This paper proposes a L5GO network architecture for
delay critical future telehealth services, considering two use cases
on augmented reality assisted and robotic aided surgery. The
paper compares the latency performance of the proposed L5GO
architecture with a traditional legacy network and a network
equipped with Multi-access Edge Computing (MEC). The results
highlight the unique advantages of utilizing an L5GO to cater
the communication needs of delay critical telehealth, compared
to a traditional network.
Index Terms—3GPP, 5G, e-health, Local 5G Operator,
URLLC.
I. INTRODUCTION
Telehealth, which allows access to health care services
remotely, is considered to be a key application in next gen-
eration wireless networks [1]. The Coronavirus Disease 2019
(COVID-19) pandemic, has made telehealth a focal point, due
to the critical requirement of minimizing personal interactions
for decelerating the spread of the virus [2]. Furthermore,
ensuring the health of the healthcare personnel has become
paramount with healthcare facilities operating at their capacity.
This paper focuses on delay critical telehealth applications
that may have inherent constraints in terms of direct personal
interactions, and studies how the fifth generation wireless
technology for digital communications, also known as 5G, can
be used effectively in such a setting.
5G is envisioned to bring about a paradigm shift in commu-
nications, providing ultra-low latency, higher bandwidth and
massive connectivity. Innovative use cases that stem on the
capabilities of 5G are expected to emerge, with more emphasis
on case and location specific communications. Facilities such
as hospitals, shopping malls, sports arenas, universities, and
factories, already demand for customized wireless connectivity
solutions, with varying levels of reliability, data rates, latency
and security [3]. Most of these differential Quality-of-Service
(QoS) demands are beyond the capabilities of the conventional
legacy Mobile Network Operator (MNO) based networks.
The focus of traditional MNOs is providing generic mobile
communication services to mass geographical areas such as
countries or provinces. The investment cycles of MNOs are
generally long with a high infrastructure cost. Therefore,
additional capital and operational expenditure, and increased
effort, prevent the deployment of case and location specific
network services by MNOs.
Multi-access Edge Computing (MEC) brings the computing
capabilities to the edge of the network, enabling latency as-
pects in 5G, while supporting high bandwidth. As MEC oper-
ates closer to the location of the applications, real-time altering
of application aware performance optimization is possible.
This is useful in medical applications that need low latency.
However, most MEC configurations will fail to provide Ultra
Reliability and Low Latency Communication (URLLC), which
is mandatory for many telehealth use cases. These stringent
QoS demands have made way to new players such as Local
5G Operators (L5GOs), to enter the market with an aim of
providing case and location specific communication services
[4], [5].
The intention of L5GOs is to deploy localized communi-
cation services to satisfy the context-aware extreme service
requirements for a selected group of users. Even though the
L5GOs serve confined locations, they need to collaborate
with the 5G MNOs, thus the L5GO deployments must follow
the standards defined by standardization organizations such
as the 3rd Generation Partnership Project (3GPP)[3] [6]. In
addition, the L5GO should lease spectrum from a regulator or
an MNO, in the form of local spectrum licenses. The L5GO
may maintain its own infrastructure or lease the infrastructure
owned by an infrastructure vendor. The L5GO can provide
roaming services to subscribers of other MNOs, upon the their
arrival to the L5GO coverage area, given that an agreement is
in place between the two parties.
Due to the communication demands of a L5GO network
being highly variable, a tailored custom architecture that is
ready to serve user needs is preferred over a universal network
architecture. This paper presents a modified architecture for
an emerging L5GO network, which provides ultra-low latency
communication services suited for telehealth. The study is
based on two such use cases that require URLLC defined by
3GPP. They are, Augmented Reality (AR) assisted surgery and
robotic aided surgery. The proposed architecture comprises of
both the core and the access 5G network functions needed to
support communication.
The paper compares the latency performance of the pro-
posed L5GO architecture with a traditional MNO network
and a network equipped with MEC. The paper highlights
the unique advantages of utilizing an L5GO to cater the
communication needs of the two use cases of interest. We also
present the modifications that should be made to the MNO or
the MEC networks to enable them satisfy such delay critical
use cases. We show that the required upgrades have serious
concerns in terms of financial feasibility, to further highlight
the utility of the proposed L5GO architecture for delay critical
telehealth applications.
The remainder of the paper is organized as follows: Section
II presents the two delay critical telehealth use cases. Section
III describes the L5GO network registration process and the
Protocol Data Unit (PDU) session establishment, and presents
the proposed L5GO architecture. Section IV presents three
network deployment models, which are compared in Section
V through numerical results. Section VI concludes the paper.
II. US E CAS ES
The study considers two use cases in telehealth that have
stringent latency constraints, thus requiring a network with
ultra-low latency. Moreover, the use cases involve the delivery
of critical care in a healthcare facility, where the medical
team and the patients are not in close proximity (no physical
contact). Both use cases require 99.9999% communication
service availability [7].
A. Augmented Reality Assisted Surgery
3D imaging methods such as Magnetic Resonance (MR) and
Computer Tomography (CT) scans are already being used to
assist doctors in diagnostics. Image guided surgery is gaining
popularity in the healthcare industry with the increasing pen-
etration of technologies like AR. Although there are several
ways of generating AR views to identify and follow the exact
3D position of a human body [7], this study considers only a
generic scenario where AR can be used in assisting surgeries.
To this end, let us consider a scenario where AR im-
ages are generated by a device at the patient’s end, and
transferred to an image processing server for augmentation.
The augmented images are then transferred to a viewing
console at the surgeon’s physical location. The high-quality
images that necessitate complex processing create latency in
the communication process. A Grand Master Clock (GMC) is
used to synchronize the entire setup.
B. Robotic Aided Surgery
Robotic aided surgery is important in invasive surgical pro-
cedures such as delicate tissue replacements and in situations
where accessibility to internal organs is difficult. In a robotic
aided surgery, the patient’s end is equipped with complex
instruments that replicate the surgeon’s hand movements.
These instruments can perform high precision manoeuvres.
The control console at the surgeon’s end is fed with haptic
feedback, to create the experience of a real surgery [7].
All equipment including the surgeon’s console are synchro-
nized with the GMC with an accuracy of 1µs. Robotic Aided
Kidney Transplant (RAKT) is a typical surgery performed
using this method. Such a surgery requires the transfer of 240
images per second over the network. Having two repetitive
errors in any direction is fatal, as they may result in an
incorrect command being sent to the actuators. By taking this
into account, 3GPP specifies the message error rate to be lower
than 0.0001 %, which sets the minimum requirement in terms
of reliability, for a network utilized for a RAKT type surgical
procedure [7].
III. THE L5GO NE TWORK ARCHITECTURE
This section proposes a possible L5GO network archi-
tectural model that facilitates delay critical 5G telehealth
applications. The architectural model is set up to support the
communication requirements of the two use cases presented
in Section II. The network registration, which handles the
registration of the terminal devices in the 5G network, and
PDU session establishment procedures, which creates a data
session between two hosts in the 5G network, are set based
on the 3GPP specifications [8].
A. The L5GO Network Registration
Surgical
Device AN AMF UPF SMF PCF UDM
1. PDU Session
Establishment Request 2. SM Context
Request
SM Context
Resonse
8. Authen ca on Response
9. AMF Policy Associa on
Establishment/ Modi ca on
N1 N2 message transfer
PDU session Request
AN resource setup
Server
Subscrip on retrieval/ update
7. SM Policy Associa on
Establishment
7. N4 session establishment/
modi ca on Request / Response
PDU session Response
First Uplink Data
PDU session update / SM context request
N4 session modi ca on request/
response
First Downlink Data
Fig. 1: The message flow diagram for device registration.
The console sends the registration request via the L5GO
Access Network (AN) to the next generation NodeB (gNB),
and generates a registration request at the Access and Mobility
Management Function (AMF). As an L5GO typically serves
a location specific small user group, it is unlikely to have
multiple AMFs in the network, thus eliminating the AMF
selection procedure. The AMF exchanges identity request mes-
sages with the console in order to establish a connection. Then,
the AMF validates the device through the Equipment Identity
Register (EIR), and communicates with the Authentication
Server Function (AUSF) for device authentication. The AUSF
authenticates the device after communicating with the Unified
Data Management (UDM) and retrieving the authentication
data. The AUSF completes the authentication process with
a response to the AMF. Upon successful authentication, the
AMF contacts the Policy Control function (PCF) for the
respective policy association for the console. Then, the AMF
sends an update to the Session Management Function (SMF)
to notify the session context. The AMF generating and sending
a registration accept message to the console follows. The
console replies with a registration complete message to the
AMF, and completes the registration process [8].
B. The Protocol Data Unit Session Establishment
Surgical
Device AN AMF UPF SMF PCF UDM
1. PDU Session
Establishment
Request
2. SM Context
Request
SM Context
Resonse
8. Authen ca on Response
9. AMF Policy Associa on
Establishment/ Modi ca on
N1 N2 message transfer
PDU session Request
AN resource setup
Server
Subscrip on
retrieval/ update
7. SM Policy Associa on
Establishment
7. N4 session establishment/
modi ca on Request / Response
PDU session Response
First Uplink Data
PDU session update / SM context request
N4 session modi ca on request/ response
First Downlink Data
PDU Session Authen ca on/ Authoriza on
Fig. 2: The message flow diagram for the PDU session
establishment.
Upon successful registration, the console initiates the PDU
session establishment procedure with the image processing
server, according to the 3GPP specifications [8]. Firstly, the
PDU session establishment request by the console is forwarded
to the AMF via the L5GO gNB. The AMF generates and sends
a PDU session create/session management context request to
the SMF. The SMF interacts with the UDM for subscription
retrieval, and updates related attributes for this particular
session. Then, the SMF responds to the AMF with a session
management context. Afterwards, the PDU session authenti-
cation/authorization takes place through message exchanges
between the NFs in the surgical device and the imaging
server, as shown in Fig. 2. The SMF coordinates with the
PCF for policy association for the session. The SMF and
the UPF exchange session establishment/modification requests
and responses. Then, an authentication response is sent to
the AMF by the PCF. The AMF policy association estab-
lishment/modification messages interchange between the AMF
and the UPF follows. Next, the SMF and the AMF initiate a
message transfer session. The AMF transfers the PDU session
ID details to the gNB so that the gNB can coordinate with
the surgical device for the gNB defined resource setup. Based
on that, the L5GO’s AN sends a PDU session response to
the AMF, and the AMF sends a PDU session update/session
management context request to the SMF. The SMF then sends
a request message to the UPF for session modification. Upon
retrieval of this message by the UPF, the SMF transmits
the response of the PDU session update to the AMF, which
concludes the PDU session establishment process [8].
C. The Proposed Architecture
Fig. 3: The proposed network architecture.
The proposed L5GO network architecture for delay critical
telehealth applications is illustrated in Fig. 3. It uses the Time
Sensitive Network (TSN) logical bridge architecture defined
by 3GPP [9] as the base, together with the IEEE 802.1AS time
aware system. The IEEE 802.1 TSN enables transmission of
various types of critical data over a bridged Ethernet network.
Transmitted data can be of different Quality of Service (QoS)
levels, regardless of the low latency end-to-end connectivity
provided by the TSN [10].
The TSN bridge is between the Device-side TSN transla-
tor (DS-TT) and Network-side TSN translator (NW-TT) [9].
When operating the 5G core network elements, the RAN
and the communication links are invisible to the TSN bridge
because it works as an end-to-end tunnel. The entire system
is synchronized by a GMC. The Time Sensitive Network
Application Function (TSN AF) establishes the end-to-end
tunnel connectivity and maintains it throughout the session,
whereas the rest of the 5G network functions serve their
original purpose.
A 5G network equipped with the TSN bridge features is
equipped to deliver ultra-low latency services to the sub-
scribers. As the use cases of interest are for surgeries of
stationary organs, their End-to-End (E2E) delay requirement
is considered to be below 18 ms [7]. However, when it comes
to cases with moving organs, the delay threshold decreases
drastically.
IV. THE NE TW OR K DEP LOY ME NT MO DE LS
The study considers three possible network deployment
models;
•L5GO network
•Traditional MNO
•MEC enabled MNO network.
The image generating devices, the image processing server and
the surgical devices are located inside the hospital premises in
all three models. The study only focuses on the communication
process associated with the data transfer, as it is the most
critical stage with regards to ultra-low latency. This means,
the delays associated with the device registration and the
PDU session establishment are neglected. During the data
transfer process, the generated data gets transferred to the
image processing server via the access network and the core
network function UPF. The image processing server augments
the required information and sends the augmented information
to the AR consoles, with the involvement of the UPF.
Fig. 4: Deployment model for a L5GO serving a hospital
premises
In the L5GO deployment model, a single L5GO provides
connectivity to the hospital premises, through a multitude of
gNBs with small coverage areas. The communication require-
ments of the surgical devices, the image processing server and
the monitor consoles are catered through different gNBs, as
illustrated in Fig. 4. Most importantly, the L5GO core network
is also located inside the hospital premises.
In the MNO deployment model, the MNO provides connec-
tivity to all communicating devices in the hospital premises
through its 5G network. Fig. 5 depicts the MNO deployment
model. The core network of the MNO resides outside the
hospital facility. In a practical setting, there can be Nsuch
healthcare facilities located in a geographically distributed
manner, and served by the same MNO.
The third deployment model, which is the MEC network,
has a similar access network as the MNO model, but the
core network functions are located at the edge, thus located
closer to the hospital premises. The study assumes that M
healthcare facilities with the similar setup are served by
the MEC network, similar to the MNO model. We assume
M≤N.
Fig. 5: Deployment model for a MNO serving a hospital
premises
Fig. 6: (a) Latency breakdown for use case II-A
(b) Latency breakdown for use case II-B
The different latency components of the two use cases
are illustrated in Fig. 6. We assume Frequency Division
Duplexing (FDD), and a 120 kHz, 7 s mini-slot bandwidth
for the access network deployment. Moreover, we assume a
fiber backbone for the backhaul links to support high data
rates and achieve ultra-low latency. Table I tabulates general
calculation parameters considered for the two use cases.
TABLE I: General calculation parameters
Parameter Value
Latency between the terminal devices and the AN TAN 0.33 ms [11]
Latency between the AN and the core network TBH 0.05 ms per km [12]
Mean service time of a gNB TNB 0.1 ms
Mean service time of the access router TAR 0.1 ms
Mean service time of the core router TCR 0.05 ms
Mean service time of the 5G NF TNF 0.01 ms
Maximum acceptable AR imaging system latency 14 ms [7]
Maximum acceptable Robotic Aided Surgery system latency 20 ms [7]
Distance to the L5GO core network 100 m [7]
Healthcare facilities served by the MNO (N) 10
Healthcare facilities served by the MEC (M) 3
V. RE SU LTS A ND DISCUSSION
A. The Impact of the Distance to the Core Network
The E2E latency of the system comprises of the image gen-
eration and processing delay, the operating time of the surgical
devices and the latency of the communication infrastructure
as illustrated in Fig. 6. The human reaction time is neglected.
According to the latency breakdown in Fig. 6, the total E2E
latency is given by
Tlat =
5
X
r=1
Tr,(1)
where Trdenotes the latency of the r-th stage, and r∈
{1,...,5}. For AR assisted surgery, the threshold value for
Tlat is 14 ms [7], given that the surgery is performed on static
organs, where the only moving object is the surgeon’s hand. If
the surgery is performed on a moving organ such as the heart,
the threshold for Tlat should be lower than 14 ms to achieve
sufficient precision. Further, it is known that T1+T3+T5= 11
ms for AR assisted surgery use cases [7]. The tolerable latency
threshold for robotic aided surgery is slightly higher at 20
ms. This threshold also decreases when moving organs are
considered. For robotic aided surgery, T1+T3+T5= 16 ms
[7]. The latency in the 5G network can be calculated by
T2=T4=TAN +TBH +TN B +TAR +TCR +TN F ,(2)
where the symbols are defined in Table I.
The E2E latency values for various network settings are pre-
sented in Fig. 7 and Fig. 8, for AR assisted surgery and robotic
aided surgery, respectively. In particular, the figures show how
the latency changes with the distance to the core network. For
both use cases, three MEC core network distances (10 km, 25
km and 50 km) are considered. All these three settings will not
satisfy the required average latency threshold for AR assisted
surgery, whereas for robotic aided surgery, the setting with a
distance of 10 km to the core network satisfies the latency
constraint. We can observe that for the MNO network setting
to work, the distance to the core network should be brought
down to 100 m. Any distance greater than this violates the
latency constraint. Finally, we can observe that the L5GO best
suits the two use cases.
10
12
14
16
18
20
22
24
26
28
30
End to End System Latency (ms)
10
12
14
16
18
20
22
24
26
28
30
MEC core at 10 km
MEC core at 25 km
MEC core at 50 km
MNO core at 0.1 km
MNO core at 40 km
MNO core at 707 km
L5GO
Maximum Acceptance Latency
Fig. 7: E2E latency of use case II-A with respect to distance
to core network
B. Impact of the Network Function Processing Delay
The Network Function (NF) processing delay TNF is a
crucial component in E2E latency. The NF processing delay
mainly depends on the operator resources and the network
traffic load. To this end, we have
TNF ∝network load
operator r esources .(3)
15
20
25
30
35
End to End System Latency (ms)
15
20
25
30
35
MEC core at 10 km
MEC core at 25 km
MEC core at 50 km
MNO core at 0.1 km
MNO core at 40 km
MNO core at 70 km
L5GO
Maximum Acceptance Latency
Fig. 8: E2E latency of use case II-B with respect to distance
to core network
Therefore, the latency values related to the 5G network can
be written as
T2=T4=TAN +TBH +TN B +TAR +TCR
+K. network load
operator r esources ,(4)
where K= 1 according to the proposed architecture in Section
III.
An MNO typically possess higher computational and net-
work resources compared to an L5GO, whereas an MEC pos-
sess more resources compared to an L5GO, but comparatively
less resources compared to an MNO. Since the NF processing
delay is inversely proportional to the operator resources, we
consider four different resource levels for the MNO and the
MEC networks as outlined in Table II, where Jis the resource
multiplier. The total resources for an MNO or an MEC with
a resource multiplier J, can be written as J×RL5GO, where
RL5GO denotes the total resources in the L5GO network. We
check whether tolerable latency is achievable with the MNO
and the MEC networks by increasing their resource levels
compared to the L5GO.
TABLE II: Increased resource levels at the MNO and the MEC
networks compared to the L5GO
Resource Level Resource Multiplier for the MNO/MEC
L1J= 1
L2J= 10
L3J= 100
L4J= 1000
We consider values of 0.01 ms and 0.05 ms for the TNF
of the L5GO. Note that an MNO has N= 10 L5GOs in the
network, and an MEC has M= 3 L5GOs in the network.
Thus, it is not hard to see that the TN F of an MNO can
be calculated by multiplying the TN F of the L5GO network
by N
R. Similarly, the TNF of an MEC can be calculated by
multiplying the TN F of the L5GO network by a factor M
R.
Then, we calculate the maximum distance that the networks
with the additional resources can have to their core networks,
that is the length of the fiber backhaul. These values are
tabulated in Table III for a TN F of 0.01 ms at the L5GO,
and in Table IV for a TN F of 0.05 ms at the L5GO. The
length of the backhaul is denoted by DBH .
It is clear that the length of the backhaul, that is, where the
core network can be deployed, varies based on the resource
availability. It is possible for the MNO to support the required
E2E latency, under all four resource levels. This is due to the
underlying reason that the increased resource levels lead to
a lower TNF value at the MNO. However, it is interesting
to consider the distance values to the core network although
the delay constraints are satisfied. Obviously, the distance to
the core network monotonically increases with the network
resources at the MNO. However, it can be noted that the
gradient of this increasing slope is rather small, thus the gain
is not significant compared to the additional costs. As an
example, considering the AR assisted surgery use case, for
J= 100,DBH is 2.2859 km, and for J= 1000 DB H is
2.40985 km. The gain is approximately 120 m, which does
not justify a 100-fold resource upgrade. It can also be seen
that the backhaul delay TBH is more prominent compared to
the NF processing delay TN F for the two use cases of interest.
Since the MEC only serves 3 health facilities simultane-
ously, it shows a higher gain in terms of DBH compared to
the MNO for similar resource levels. The MEC too satisfies
the required latency thresholds when the resource levels are
increased. For Robotic aided surgery, DBH is 7.76625 km for
J= 10, and DBH is 7.8557 km for J= 100. Similar to
the MNO, the change is insignificant when taking the cost
of resource upgrade (increase of 90 m from 10-fold resource
upgrade). At TN F = 0.01 ms, the gain is about 170 m for AR
assisted surgery, for the same 10-fold resource upgrade.
TABLE III: Distance to core network when L5GO TNF = 0.01
ms for use case II-A and II-B
MNO MEC
Level TNF
(ms)
AR
DBH (km)
Robotic
DBH (km)
TNF
(ms)
AR
DBH (km)
Robotic
DBH (km)
L10.1 1.8024 7.1372 0.03 2.32045 7.76625
L20.01 1.95065 7.1907 0.003 4.9829 7.8557
L30.001 2.2859 7.3603 0.0003 2.7495 7.9232
L40.0001 2.40985 7.57005 0.00003 2.91955 8.07075
TABLE IV: Distance to core network when L5GO TN F =
0.05 ms for use case II-A and II-B
MNO MEC
Level TNF
(ms)
AR
DBH (km)
Robotic
DBH (km)
TNF
(ms)
AR
DBH (km)
Robotic
DBH (km)
L10.5 0.67635 6.5351 0.15 1.47935 5.78545
L20.05 1.7324 6.6696 0.015 1.99245 6.04125
L30.005 1.806 7.29235 0.0015 2.126 7.6696
L40.0005 2.0823 7.5262 0.00015 2.2269 8.26105
Overall, our results show that increasing resources at the
MNO and the MEC networks is not a financially feasible
investment for delay critical telehealth applications. The results
also further highlight the importance of the proposed L5GO
architecture for delay critical telehealth applications.
VI. CONCLUSIONS
This paper has proposed a Local 5G Operator (L5GO) ar-
chitecture for delay critical telehealth applications, considering
two delay critical healthcare use cases, i.e., Augmented Reality
(AR) assisted surgery and robotic aided surgery. The proposed
architecture has been designed based on the 5G Time Sensitive
Network (TSN) architecture. The paper has highlighted the
performance gains from the proposed L5GO network com-
pared to the conventional Mobile Network Operator (MNO)
based networks, and the Multi-access Edge Computing (MEC)
based MNO networks, through an End-to-End (E2E) latency
study. Numerical results have shown that the proposed L5GO
architecture satisfies the stringent latency constraints of both
use cases. On the other hand, the MNO or the MEC based
network architectures fail to satisfy these constraints. It has
also been shown that if it is required to use the MNO or
the MEC networks for such delay critical use cases, the
distance to the core network should be considerably decreased,
and the total network resource levels should be considerably
increased. The upgrade deems infeasible financially, which
further highlights the utility of the proposed L5GO architecture
for delay critical telehealth applications.
ACK NOW LE DG EM EN T
This work is supported by Academy of Finland in 6Genesis
Flagship (grant no. 318927) and 5GEAR projects, and Euro-
pean Union in RESPONSE 5G (Grant No: 789658) project.
REFERENCES
[1] E. Liu, E. Effiok, J. Hitchcock, ”Survey on health care applications in
5G networks”, IET Communications, vol. 14, no. 7, pp. 1073-1080, Apr.
2020.
[2] D. Soldani, ”Fighting COVID-19 with 5G enabled technologies”. White
paper, Huawei Technologies. Apr. 2020.
[3] Y. Siriwardhana, P. Porambage, M. Liyanage, J. S. Waliay, M.
Matinmikko-Blue, M. Ylianttila, “Micro-operator driven local 5G net-
work architecture for industrial internet,” in. proc. IEEE Wireless Com-
munications and Networking Conference, Marrakech, Morocco, Apr.
2019
[4] S. Kekki et al., ”MEC in 5G networks,” ETSI White Paper No. 28, First
edition, Jun. 2018
[5] T. Taleb, K. Samdanis, B. Mada, H. Flinck, S. Dutta, D. Sabella, ”On
Multi-Access edge computing: A Survey of the emerging 5G network
edge cloud architecture and orchestration,” IEEE Communications Sur-
veys & Tutorial , Vol. 19, No. 3, pp 1667-1681, May 2017
[6] M. Matinmikko, M. Latva-aho , P. Ahokangas, S. Yrjola, T. Koivumaki,
” Micro operators to boost local service delivery in 5G,” Wireless
Personal Communications, pp 69-82 , May 2017
[7] 3GPP, ”3GPP TR 22.826 ; Study on communication services
for critical medical applications (Release 17),” Technical report,
Aug. 2019. [Online]. Available:https://portal.3gpp.org/desktopmodules/
Specifications/SpecificationDetails.aspx?specificationId=3546
[8] 3GPP, ”3GPP TS 23.502 ; System Aspects;System architecture for
the 5G System (5GS);Stage 2 (Release 16),” Technical specification,
Dec. 2019, [Online]. Available:https://portal.3gpp.org/desktopmodules/
Specifications/SpecificationDetails.aspx?specificationId=3546
[9] 3GPP, ”3GPP TS 23.501 ;System architecture for the 5G
system (5GS);Stage 2 (Release 16),” technical specification, Dec.
2019, [Online]. Available:https://portal.3gpp.org/desktopmodules/
Specifications/SpecificationDetails.aspx?specificationId=3546
[10] J.Farkas, L.L Bello, C. Gunther, ”Time-sensitive networking standards”,
IEEE Communications Standards Magazine, Jun. 2018
[11] J. Sachs, G. Wikstr¨
om, T. Dudda, R. Baldemair, K. Kittichokechai,
”5G radio network design for ultra-reliable low-latency communication,”
IEEE Network, vol. 32, No. 2, Mar./Apr. 2018
[12] M. Jaber, M. A. Imran, R. Tafazolli, A. Tukmanov, “5G backhaul
challenges and emerging research directions: A survey,” IEEE Access
vol. 4, pp. 1743–1766, Apr. 2016.