edge-based evolved packet core (epc) refactoring for high

Vol.:(0123456789)

SN Computer Science (2021) 2:343 https://doi.org/10.1007/s42979-021-00718-1

SN Computer Science

ORIGINAL RESEARCH

Edge‑Based Evolved Packet Core (EPC) Refactoring for High Speed Mobility

Wei‑Kuo Chiang1 · Ming‑Wei Wang1

Received: 29 December 2020 / Accepted: 20 May 2021 / Published online: 19 June 2021 © The Author(s), under exclusive licence to Springer Nature Singapore Pte Ltd 2021

AbstractThe current design of long-term evolution (LTE) deploys Evolved Packet Core (EPC) components in a core network, while data traffic from User Equipment (UEs) is converged to these components. As the number of internet devices increases, this design causes network congestion and inefficiencies. One distributed way to solve the network burden is to deploy the on-demand EPC components close to the edge of network (near the base station; known as Edge-based EPC). At present, some researches directly use current EPC components for edge deployment, which is problematic. When a UE moves between two edge networks, it will face the inter-edge procedures to change serving edge components. The procedure involves many message exchanges between components of the connection re-establishment, which will affect the UE’s experience. Thus, the current EPC architecture is not suitable for edge deployment. In on our previous study, we had derived a Refactored EPC (R-EPC) architecture (Chiang and Chen in A quantitative approach for refactoring NFV-based Mobile Core Networks. In: 2019 IEEE 30th international conference on application-specific systems, architectures and processors (ASAP), New York, pp 135, 2019. https:// doi. org/ 10. 1109/ ASAP. 2019. 00- 17). Then, we determine the deployment of R-EPC components based on their responsibilities and coined the term “architecture edge-based refactored EPC” (E-R-EPC). In E-R-EPC, we deploy service triggering-related components and the gateway responsible for trafficking data to the edge network, while deploying components that record the location of UE to the core network. Thus, the UE can utilize the low-latency data traffic services in the edge network. As the served recording location components are the same, the signaling cost for updating the location information is reduced. In addition, we propose a new handover procedure named inter-edge handover. Furthermore, we compare the signaling cost and queuing delay of E-R-EPC with other architectures. The results of the proposed architecture demonstrate good performance, especially in managing frequent movements of UE between two edge networks (e.g.: high-speed mobility). The results of the present study indicate that E-R-EPC is a suitable reference for edge-designed networks.

This article is part of the topical collection “Applications of Cloud Computing, Data Analytics and Building Secure Networks” guest edited by Rajnish Sharma, Pao-Ann Hsiung and Sagar Juneja.

* Wei-Kuo Chiang [email protected]

Ming-Wei Wang [email protected]

1 Department of Computer Science and Information Engineering, National Chung Cheng University, Chiayi 621, Taiwan, R.O.C.

http://orcid.org/0000-0002-4400-4797

https://doi.org/10.1109/ASAP.2019.00-17

http://crossmark.crossref.org/dialog/?doi=10.1007/s42979-021-00718-1&domain=pdf

SN Computer Science (2021) 2:343343 of 26

SN Computer Science

Graphical abstract

Keywords Edge deployment · Refactor · Session continuity · Signaling cost · Queuing delay

Introduction

With an increasing popularity of various types of internet devices, mobile networks are expected to serve a wide range of verticals, resulting in diverse and growing use cases. Cur-rently, there are many enabling technologies that are mod-eling the network of the future. However, the key problem is that the current design of Evolved Packet Core (EPC) leads user traffic to converge to the core network, causing con-gestion and inefficiencies. Recently, some researches have proposed to deploy EPC components close to the edge of the network to distribute the traffic burden of the EPC. How-ever, deploying the current Long Term Evolution (LTE)/

EPC components in the edge network does not offer compre-hensive solutions to address events, such as User Equipment (UE) moving between two edge networks. Therefore, the researchers of the present study analyzed and refactored the EPC components and proposed an edge-based EPC archi-tecture named edge-based refactored EPC (E-R-EPC). E-R-EPC is capable of solving the above problems while have the benefits of low latency services at edge networks.

Background

LTE/EPC is an innovative mobile network technology that provides a range of real-time, non-real-time, and high-speed

Table 1 Summary of current LTE/EPC developments

Reference Main concept Contribution Specification modification

Carrier Cloud [6], 2014 NFV Proposing a virtualized LTE/EPC network ×EPCaaS [7], 2015 NFV Proposing the concept of EPC as a service (EPCaaS) ○Lindholm et al. [3], 2014Sama et al. [10], 2016

NFV Providing the concepts of splitting and grouping EPC functions ○

Yousaf et al. [8], 2015 NFV Proposing a two-tier decomposed MME architecture ○Prados-Garzon et al. [9], 2017 NFV Proposing a three-tier decomposed MME architecture, queuing model ○OEPC [12], 2015 SDN Proposing an SDN-based EPC architecture ○Sama et al. [11], 2015 SDN + NFV Proposing an SDN with EPC architecture ×Tran et al. [13], 2017 MEC Providing the MEC concept for the advancement of 5G technology ×Coronado et al. [14], 2020 MEC Mapping the Evolution of MEC solution for 4G and 5G Networks ×Moradi et al. [15], 2021 MEC Moving Core to the

Edge for Untethered and ReliableUAV-Based LTE Networks

×

SN Computer Science (2021) 2:343 of 26 343

SN Computer Science

data transmission rate services to mobile users. To meet the growing demands for mobile users, some emerging tech-nologies have been applied to mobile network issues. The European Telecommunications Standards Institute (ETSI) proposed the concept of network function virtualization (NFV) [2], under which the network functions are separated from the dedicate hardware. The separated-network func-tions (virtual network functions; VNFs) can be implemented on the general commodity server. Therefore, the operators can expand the specific overloaded functions without having to expand other non-essential ones, which reduces the cost of deployment.

Another technology, software-defined networking (SDN), is complementary to NFV. SDN serves NFV by providing programmable network connectivity between VNFs to achieve optimized traffic engineering and steering [3]. By enabling programmability, SDN decouples the network Con-trol plane from the User plane forwarding to provide a cen-tralized controller [4]. In the system, all control signals are passed to the SDN controller, which centrally manages the underlying network devices. Network devices such as routers and switches only need to perform data forwarding based on the flow table entries instructed by the SDN controller.

With the development of edge computing, the Multi-access Edge Computing (formerly known as Mobile Edge Computing; MEC) initiative was proposed [5]. The main concept of Multi-access Edge Computing is to bring infor-mation technology (IT) services originally processed in the core network and the cloud to the edge of the mobile network, thereby reducing the latency of user data trans-mission and the consumption of network resources. Data processing and computing can be completed near the users, which ensures that the data computing results are obtained more quickly and the user experience is improved. MEC is regarded as an important technology that serves the devel-opment of 5G.

We reviewed iconic papers that have mentioned the above technologies, and listed them in Table 1, after which we briefly discuss the contents of these studies. In Taleb et al. [6], provided the concept of carrier cloud, and gave the step-by-step description of how to instantiate virtual machines (VMs) as the network functions to deploy an entire LTE/EPC network. Moreover, Taleb et al., indicated in [7] that current EPC components are not designed with elasticity in mind, and further proposed the concept of EPC as a service (EPCaaS), where each EPC VNF [e.g., mobility manage-ment entity (MME) VNF] can be decomposed into three element types: a front-end, a worker, and a session database. Similar concepts that focused on splitting MME have been proposed in [8] and [9]. In [3] and [10], the authors proposed the concepts to re-designing EPC components. The authors started by splitting the component into several functions, and then grouping the related parts to increase the operational

efficiency of the architecture. In Sama et al. [11], presented a software-defined control architecture of a virtualized EPC network. They deployed the gateway control function on an SDN controller to manage the OpenFlow-enabled switches. These switches acted as gateways for the User plane function (UPF). The other EPC control functions, including MME, HSS, and PCRF, were virtualized as VNFs connected to the SDN controller. Unlike the design in [11], Yazici et al. in [12] proposed to deploy the MME on the SDN controller, which significantly reduces the signaling load when com-pared to [11]. With the development of the edge comput-ing, Tran et al. in [13] envisioned a framework comprising MEC servers and demonstrated the promising benefits of the proposed approaches in facilitating the evolution to 5G networks.

Recently, Coronado et al. in [14] proposed LightEdge, a lightweight, European Telecommunications Standards Institute (ETSI)-compliant MEC solution for 4G and 5G networks. The main goal of LightEdge is to provide mobile network operators (MNOs) with an MEC platform that can immediately bring the advantages of edge computing to the 4G end users, while enabling a seamless transition over the evolutionary path from 4G toward a full 5G architecture. In Moradi et al. [15] proposed an alternate, radical edge EPC design, called SkyCore that pushes the EPC functionality to the extreme edge of the core network—collapses the EPC into a single, lightweight, self-contained entity that is collo-cated with each of the unmanned aerial vehicle (UAV) base station (BS). SkyCore embodies the Edge-EPC architecture while introducing two key pillars in its design to address the associated challenges: a complete software refactoring of the EPC for compute-efficient deployment on a UAV and a new inter-EPC communication interface to enable fully functional operation in a multi-UAV environment.

Motivation

Despite being able to adopt NFV, SDN, and MEC, not eve-rything about the EPC architecture is beneficial. Although NFV is a promising solution for telecommunications service providers, it faces certain challenges such as interconnec-tion of VNFs and coexistence with legacy networks. These problems could potentially degrade the performance of EPC architecture and hinder its implementation in the tel-ecommunications industry [3]. In reality, SDN is difficult to deploy on the entire networks, because the controller cannot accommodate the huge number of messages from the SDN switches of the entire network. Moreover, the overhead of installing rules and communicating with the controller at the switches must be carefully considered in SDN-based EPC designs [16]., Although there can be an MEC server at the edge network in the design of LTE/EPC with MEC to accelerate the computing and processing of applications,


SN Computer Science

the processed data traffic still needs to be transmitted to the core network. The best way to provide users with better ser-vice quality in the mobile network is to shorten the distance between the user and the core network and to distribute the traffic burden of the core network components.

Pozza et al. in [17] indicated that LTE networks require users to tightly interact with the MME for many purposes, such as authentication and exchanging of security and location records. In addition, [17] suggested that Evolved Node B (eNB) act as a relay for these messages. Therefore, the authors of [17] coalesced eNB with the control enti-ties, resulting in a great reduction in the number of mes-sage exchanges. However, the authors did not consider the implementation aspect of this design. If the control entities

are deployed in eNB, the served users need to register with the new control entities again as long as they move and connect to another eNB, which results in substantial sign-aling costs and delay time associated with performing the re-registration.

In Cau et al. [18], proposed a design that deploys EPC components to the edge network. The authors of [16] placed the gateway components that data trafficks close to the users, which can lead to short data paths and reduced transmission delays. The drawback of this design is that users will have to change served gateway and may even experience session interruption during moving between two edge networks. The design of [19] solved the above problems by deploying the gateways to the core network as an anchor point for moving users; however, the improvement lost the advantage of short-data path transmission. In addition, the authors in both stud-ies [1, 19] suggested to deploy the MME to the edge network but failed to consider that users may move out of scope, resulting in the MME change and additional bringing costs. Therefore, there are tradeoffs regarding the deployment of current EPC components to the edge network.

Contribution

In this article, we propose an edge-based EPC architecture capable of addressing the above challenges. We discuss the deployment of refactored EPC(R-EPC) components with the objective of maximizing architecture effectiveness. This architecture was named by the authors of the present study as edge-based refactored EPC.

Due to the design of edge deployment, the Session Anchor (PGW) is deployed at the edge, causing the ongoing session to be interrupted when the UE moves between two edge networks. Therefore, the issue of session continuity for edge-moving UE is proposed. We design a procedure called inter-edge handover, under which the UE can main-tain an uninterrupted session even if it reaches to another edge network. In addition, we compare the performance of

Table 2 Acronyms and terms

NFV Network Function VirtualizationSDN Software-defined NetworkingMEC Mobile Edge ComputingLTE Long Term EvolutionEPC Evolved Packet CoreMME Mobility Management EntitySGW Serving GatewayPGW Packet Data Network(PDN) GatewayeNB Evolved Node BS-eNB Source eNBT-eNB Target eNBHSS Home Subscriber ServerGTP GPRS Tunneling ProtocolTEID Tunnel Endpoint IdentifierTA Tracking areaTAU Tracking area updateR-EPC Refactored EPCCUPS Control and User Plane Separation of EPC nodesARM Authentication and Registration ManagementSMC Session Management controlS/PGW-U User serving/packet gateway-user planeE-R-EPC Edge-based Refactored EPC

Fig. 1 LTE/EPC architecture

UE

HSSMME

eNBSGW PDNPGWS1-U S5/S8

S11

SGi

RAN Evolved Packet Core (EPC)

X2


SN Computer Science

the E-R-EPC in terms of signaling cost and queuing delay with designs proposed by other studies.

The remainder of the article is structured as follows. In section “Related Work”, we introduce important technolo-gies used in this article. We propose a quantitative-analysis approach to refactor the EPC and evaluate the effectiveness of distinct edge deployment in section “The Edge-Based Refactored EPC”. In section “Performance Comparison”, we compare the performance of the E-R-EPC with other designs in terms of signaling cost and queuing delay. In addition, we evaluate the delay time performance of gateways deployed at the edge network. Finally, section “Conclusions” concludes this article and offers suggestions for future research.

Related Work

In this section, we briefly describe the LTE/EPC architec-ture defined in 3GPP Specification [20] and the refactored EPC architecture proposed in [1]. Discuss the idea of edge deployment for EPC architecture, and introduce designs pro-posed by other researches. The acronyms and terms used in this paper are listed in Table 2.

Long‑Term Evolution/Evolved Packet Core (LTE/EPC)

Long-term evolution (LTE) is a 3GPP collection of stand-ards for high-speed wireless communication. In this sec-tion, we provide a brief introduction to this system, includ-ing its architecture, functional components, and processes. In addition, relevant charging components such as Policy and Charging Rules Function (PCRF) and Subscriber Pro-file Repository (SPR) of the operator are not included. Inter-ested readers can consult the 3GPP technical specifications TS 23.401 for complete descriptions [20].

LTE/EPC Architecture

LTE networks consist of two sub-networks: the Radio Access Network (RAN) and Evolved Packet Core (EPC), as shown in Fig. 1. The key network component in RAN is the eNB. The eNBs use the Lte-Uu interface to communicate with mobile devices called User Equipment (UEs). Fur-thermore, eNBs may connect to a certain number of other eNBs through the X2 interface for the handover procedure. An eNB is also connected to two network functions of the EPC: the Mobile Management component (MME) via the S1-MME interface, and Serving Gateway (SGW) via the S1-U interface. The components in EPC include the MME, SGW, Packet Data Network Gateway (PGW) and Home Sub-scriber Server (HSS). The MME connects to the SGW and HSS through the S11 and S6a interface. The SGW uses S5/S8 to connect with the PGW.

The components that are mainly responsible for the pro-cess operations are detailed as follows:

• The HSS is a subscriber repository that contains all user subscription information. It also provides support func-tions for user authentication and access authorization.

• The MME is responsible of all control signaling func-tions related to the subscriber and session management. It also handles handover procedures.

• The SGW routes and forwards data traffic, while also acting as the Mobility Anchor for handover.

• The PGW acts as the Session Anchor for sending the packets to the external network. It also performs func-tions such as policy enforcement, packet filtering, charg-ing, and IP address allocation.

Packet Delivery The transmission in the EPC system can be mainly divided into a control plane and user plane, where the former is responsible for the control signals and the lat-ter is in charge of data traffic. The GPRS Tunneling Protocol (GTP) [21] is used as the communication protocol to sup-port traffic tunneling in LTE networks [22]. GTP transmis-sion mainly depends on the bearer established by the end-to-end. Each bearer is associated with a tunnel, the endpoint of which is identified by a tunnel endpoint identifier (TEID).

Location Update Mechanism In an EPC system, the MME uses a Tracking area (TA) to record the user’s registered location. A TA consists of a set of cells in eNBs coverage. If a UE enters a new TA range, the procedure of Tracking area update (TAU) must be performed to update the UE location recorded by the MME. To avoid frequently TAUs when the UE is mobile, the mechanism of the TA list, which contains many TAs, was invented. During UE registration, the MME allocates a TA list, and the UE does not need to perform TAU under the coverage of the TA list.

In another case, when a UE enters a new TA while there is no UE context stored in the new corresponding MME. The new MME finds the pre-existing MME according to the UE’s information to obtain the UE context, after which it informs the HSS that the UE has now moved to the new MME. Following the update, the HSS cancels the UE con-text in the pre-existing MME.

Basic Procedures in LTE/EPC

Here, we give a brief introduction to the basic procedures used in LTE/EPC, which should provide a comprehensive overview of some of the most important use cases. The seven basic procedures include Initial Attach, Active to Idle (S1 Release), Service Request (UE triggered), Service Request (Network triggered), Tracking area update (TAU),


SN Computer Science

X2-based handover, and S1-based handover. The following illustrates the definitions of TAU, X2-based, and S1-based handover procedures, and the differences between X2-based and S1-based handover procedures.

Tracking Area Update (TAU) The procedure occurs when a UE enters a new TA that is not in the assigned TA list, or when the TAU timer expires [23].

X2‑Based Handover (X2 HO) The procedure occurs when a UE moves in the session and the connection eNB needs to be changed. At this time, there is an X2 interface between the source eNB (S-eNB) and the target eNB (T-eNB); there-fore, the X2 bearer is used to complete the handover proce-dure. In the design of the X2-based handover, we assume both Source and Target eNBs connect to the same MME and SGW and are locate in the same TA [19, 24].

S1‑Based Handover (S1 HO) The procedure occurs when a UE moves in the session and the connection eNB needs to be changed. At this time, there is no X2 interface between

the source eNB and the target eNB; therefore, the procedure needs to be completed by communicating with the MME. In the design of the S1-based handover, we assume both Source and Target eNBs connect to the same MME and SGW and are located in same TA [19, 25].

LTE/EPC Edge Deployment

A number of studies proposed to deploy EPC components at the edge of network. In the transmission of LTE, the inter-action between EPC and UE relies on eNB for deploying components to the edge network and effectively reducing the transmission delays. We categorized two deployment meth-ods and, respectively, named them full edge architecture and partial edge architecture. Both methods keep HSS in the core network. In the following paragraph, we introduce and compare the designs proposed by other studies.

Fig. 2 Full-edge EPC archi-tecture

UE

HSSE-MME

eNB

E-SGW

Edge network Core network

External Network

PDNE-PGW

S1-MME

S1-U S5/S8 SGi

S11

Fig. 3 Partial-edge EPC archi-tecture

UE

HSSE-MME

eNB

SGW


External Network

PDN

PGW

S1-MME

S1-U S5/S8

SGi


SN Computer Science

Full‑Edge EPC

In Cau et al.[18], leveraged the concepts of NFV and MEC in the deployment of EPC components. They deployed Control plane functions of EPC on the edge cloud infrastructure (i.e., edge node) to address end-to-end service delays and net-work congestion. We considered deploying the User plane components in [18] to the edge network. The architecture is shown in Fig. 2. We refer to this architecture as full-edge EPC. The advantage of this design is that most of the proce-dures can be completed in the edge network. Moreover, the UE can directly connect to the external network and obtain services from the edge network while transmission delays are significantly reduced. However, the drawbacks appear when the UE moves between two edge networks. When leav-ing the management scope of the edge MME (E-MME), a procedure for E-MME change and HSS update are required, which demands the components to communicate between two edge networks and core network, resulting in a substan-tial transmission cost.

Partial‑Edge EPC

In Patel et al. [19], proposed a VNF placement method for EPC to reduce the latency when serving users. Figure 3 shows the architecture proposed, HSS, which was not con-sidered by the authors of [17], was added to the architecture. In this article, we refer to this architecture as partial-edge EPC. Compared to Full-edge EPC, the advantage of partial-edge EPC is evident when the UE moves and the handover procedure occurs. Because the gateways are deployed in the core network, there are no gateway changes in the procedure, hence reducing the cost of the control signal that requires reconfiguration. However, the authors of [17] did not con-sider the following shortages: (1) all user plane traffic needs to be connected to the external network via the core network. (2) partial-edge EPC presents problems that are identical to those of full-edge EPC.

Refactored EPC (R‑EPC)

In Chiang et al. [1] proposed a quantitative approach for refactoring EPC architecture, denoted by R-EPC. The archi-tecture is based on control and user plane separation of EPC nodes (CUPS) proposed by 3GPP Release 14 [26], which allows for a more streamlined and flexible gateway com-ponent function during deployment. First, we identified the functions that each component used in the LTE/EPC procedure. Subsequently, listed the corresponding strings according to the sequence of functions in the seven basic procedures. From the corresponding strings, we consider the possible combinations of merging any two consecutive functions, and then evaluated the effect of merging the two consecutive functions using three indicators, namely, mes-sage exchange reduction (MER), message handling number (MHN), and scaling side effect (SSE) [1]. After the evalu-ation, we proposed the Refactored EPC (R-EPC) architec-ture, which achieves the best balance between MER, MHN, and SSE. The R-EPC differs from the CUPS EPC in that the components of MME and S/PGW-C are refactored to ARM (i.e., manages authentication, registration and location update messages) and SMC (i.e., manages session manage-ment messages). Figure 4 shows the R-EPC architecture and details new components and interfaces that differ from the CUPS EPC architecture [25, 27].

UE

HSSARM

eNB

SMC

PDNS/PGW-U

S6a

SGiS1-U

ARM-SMC

Sx

Fig. 4 Refactored EPC architecture with interfaces

UE

HSSARM

eNBE-S/P-GW-U


SMCS1-MME

Sx

PDNSGi

External Network

Fig. 5 Refactoring R-EPC with ARM at core

UE

HSSARM

eNBE-S/P-GW-U


SMC

PDNSGi

External Network

ARM-SMC

Sx

Fig. 6 Refactoring R-EPC with ARM at edge


SN Computer Science

In terms of an S1-MME interface, we allocated an S1-AP ID [26, 27] to uniquely identify the ARM and SMC in R-EPC. When an eNB receives an S1AP ID, the eNB will store the S1AP ID of the corresponding ARM or SMC for transmitting S1 control signaling messages.

ARM-SMC interface provides the signaling service between ARM and SMC and has the following functions according to 3GPP specification [26, 27]: Initial UE mes-sage, transfer function, Update Location Answer (ULA) transfer function, and Tracking Area Update (TAU) Request/Accept transfer function.

SMC is a control plane component responsible for the signaling transmission between the UE and the core network. It acts as an endpoint for receiving Non-Access Stratum (NAS) messages from the eNB and forwards registration and location update messages to ARM. The main responsibil-ity of SMC is to manage the Evolved Packet System (EPS) bearer, including creating and deleting connections, as well as assigning UE IP addresses. In addition, SMC handles paging to UEs in the Idle state and handover messages. SMC connects the eNB and ARM through S1-MME and ARM-SMC, and S/PGW-U via Sx.

ARM is responsible for UE authentication, registration, and UE location value handling, and it communicates with the HSS. In basic procedures, ARM mainly process the con-trol messages in the Initial Attach and Tracking area update. ARM connects the eNB and HSS through S1-MME and S6a, and SMC via ARM-SMC.

The Edge‑Based Refactored EPC

In this section, we discuss the edge deployment of the EPC components. Subsequently, we introduce the E-R-EPC archi-tecture and design the message exchange procedures.

The E‑R‑EPC Architecture

In the consideration of the deployment, HSS is kept in the core network because it needs to manage the entire carrier’s UE subscription.

In terms of user plane gateway, the gateway should be deployed in the edge network, as shown in Fig. 5. The serv-ing/packet gateway-user plane (S/PGW-U) is deployed near the eNB, which is called the edge S/PGW-U (E-S/PGW-U). As a result, each edge network has an anchor that can enable UE to connect to the PDN. This prevents the need for deliv-ering traffic to the core network for the purpose of reducing network congestion and transmission delays.

The SMC acts as an access point to the EPC network and is responsible for managing E-S/PGW-U, which is also deployed in the edge network to reduce the propagation delay caused by frequent transmissions with the eNB.

Next, we discuss the deployment of ARM. If ARM that manages the location of UE is deployed in the core network, as shown in Fig. 5. The problem of the frequent change of served MME when the UE moves between two edge net-works under full-edge EPC and partial-edge EPC can be resolved. However, if the UE only moves within an edge net-work, the above problem will not occur. The design of ARM in the edge network (see Fig. 6) can shorten the data path between SMC and ARM, which creates lower transmission delays. Therefore, further analysis from different points of view are required to determine the most appropriate deploy-ment method. In the following section, we design basic pro-cedures based on the two E-R-EPC sub-architectures, ARM at core and ARM at edge.

The Basic Procedures of E‑R‑EPC

In this section, we refer to [23–27] and propose the design of the basic procedures employed by the E-R-EPC. The basic procedures include Initial Attach, Active to Idle (S1 Release), Service Request (UE triggered), Service Request (Network triggered), Tracking area update (TAU), X2-based handover, and S1-based handover. Due to the space limita-tion, we only present the S1-based handover procedure in the E-R-EPC architectures as shown in Fig. 7. The message flows of the S1-based handover scenario are demonstrated in the following steps for details.

Step 1: A UE periodically sends a Measurement Report to the S-eNB. Whether the S-eNB decides to handover depends on the report.

Step 2: The S-eNB sends Handover Required (with a T-eNB ID) to the Source SMC. Handover Required includes a T-eNB ID and necessary UE information (with the preex-isting UE IP address).

Steps 3–4: The Source SMC sends a Handover Request to the T-eNB. Upon the T-eNB receiving an uplink S1 TEID, it establishes an uplink S1 bearer, then the responding ACK message includes an assigned downlink S1 TEID and a downlink S1 indirect tunnel TEID.

Steps 5–6: The Source SMC sends an Sx Session Estab-lishment Request (with the downlink S1 indirect tunnel TEID) to the Target E-S/PGW-U for creating a downlink S1 indirect tunnel. The Target E-S/PGW-U responds with the assigned uplink S1 indirect tunnel TEID.

Step 7: The Source SMC sends a Handover Command (with the uplink S1 indirect tunnel TEID) to the S-eNB. Upon the S-eNB receiving the uplink S1 indirect tunnel TEID, it establishes an uplink S1 indirect tunnel, then starts to buffer downlink packets.

Steps 8–9: Once the S-eNB becomes ready for a hand-over, it commands the UE to perform a handover to the T-eNB.


SN Computer Science

Step 10: The T-eNB sends a Handover Notify to the Source SMC. The message includes an E-UTRAN Cell Global Identifier (ECGI) and a Tracking Area Identifier (TAI).

Steps 11–12: The Source SMC sends an Sx Session Modi-fication Request (with the downlink S1 bearer TEID) to the Target E-S/PGW-U for modifying the downlink S1 bearer.

Steps 13–14: When the timer expires, the Source SMC sends a UE Context Release Command to the S-eNB, which

UEE-S/PGW-USMC

S-eNB T-eNB

1. Measurement Report2. Handover Required

9. Handover Confirm

DRB Bearer(UL/DL)

11. Sx Session Modificaton Request

12. Sx Session Modificaton Response

3. Handover Request

S1 Bearer(UL)

4. Handover Request Ack

S1 Bearer for Indirect tunnel(DL)

7. Handover Command

S1 Bearer(DL)

S1 Bearer for Indirect tunnel(UL)

S1 Bearer for Indirect tunnel(DL)Buffer

packets

PDN

8. Handover Command

10. Handover No�fy

S1 Bearer(UL/DL)DRB Bearer(UL/DL)

13. UE Context Release Command

14. UE Context Release Complete

5. Sx Session Establishment Request

6. Sx Session Establishment Response

15. Sx Session Release Request

16. Sx Session Release Response

Fig. 7 S1-based handover in the E-R-EPC architecture


SN Computer Science

informs the UE context that is to be released, then the S-eNB returns the Release Complete message.

Steps 15–16: The Source SMC sends an Sx Session Release Request to the Source E-S/PGW-U to release the S1 Indirect Tunnel.

Inter‑edge Mobility

In general, service continuity is seen as a crucial problem in wireless communications [28]. If we consider radio access and packet core network-level handover without worry-ing about the aspects of service and session continuity, the subsequent possible handover combinations can be found

within E-R-EPC accesses: inter-edge mobility and intra-edge mobility. In this section, we discuss issues that occur when the UE moves between two edge networks, during which the process of relocating the Session Anchor will be triggered. This procedure causes the UE’s session to be interrupted. Therefore, Session Anchor relocation is explored in this sec-tion, and the design of a new procedure for handling the handover between two edge networks is present.

Session Anchor Relocation for Inter‑edge Mobility

In the E-R-EPC architecture, the UE must perform Detach and Re-registration more frequently when moving between two edge networks, resulting in increased signaling costs and poor performance.

To solve the above problem, we referred to the 3GPP 5G specifications: Change PDU Session Anchor with differ-ent PDU Sessions [29]. Based on the Change PDU Session Anchor procedure, we then add the X2-based handover or S1-based handover procedure, which includes the mecha-nisms of indirect tunnel establishment and packet buffering. Hence, the UE can maintain the ongoing session after the serving Session Anchor is changed. We refer to this proce-dure as an inter-edge handover.

In the X2-based handover procedure, the UE can directly connect to the Target eNB as long as the X2 bearer between the Source eNB and Target eNB is established during hando-ver preparation, and then, see Fig. 8 for details. However, since the connection setup has not passed EPC compo-nents, it cannot obtain a new IP address from Target Session Anchor, so the UE will not be able to use the new edge net-work. Therefore, we adopted S1-based handover approach

Fig. 8 The establishment of two types of handover

UE S-eNB

Handover Request Ack

Handover Request

Sequence Number Status Transfer

Handover Confirm

X2 Bearer(DL)

UEMME

Handover Request

Handover Required

Handover Command

Handover Confirm

Handover Request Ack

Handover Command

noitaraperprevodnaH

Handover Command

noitucexErevodnaH

Hand

over

pre

para

�on

Hand

over

Exe

cu�o

n

(Omi�edЙ) (Omi�edЙ)

X2-based Handover S1-based Handover

T-eNB T-eNBS-eNB

UE

Target Session Anchor

Source Session Anchor

Src: PDN server IPDst IP: old UE IP

Src: PDN server IPDst IP: new UE IP

Packets

PDN server

Src: PDN server IPDst IP: old UE IP

Fig. 9 The mechanism of forwarding the downlink packets

UE

Target Session Anchor

Packets

PDN server

Src: old UE IPDst IP: PDN server IP

Src: new UE IPDst IP: PDN server IP

Fig. 10 The mechanism of forwarding the uplink packets


SN Computer Science

to establish a connection with the new edge network during handover preparation.

When the UE uses the new IP connection after handover, the ongoing session will be interrupted because there is no mechanism to inform the downlink sender that the IP of the UE has been changed. To ensure the session to be continued, a mechanism on the Session Anchor that is responsible for forwarding the packets must be design.

During inter-edge handover preparation, the MME informs the Source Session Anchor the IP used by the UE and the newly acquired IP to establish the rule to perform the packets encapsulation. When the Source Session Anchor receives the packets, the packets are encapsulated into a new UE IP address and sent to the Target Session Anchor, where the UE is located, see Fig. 9 for details.

In addition, we allowed UE supports to have multiple IPs, the concept that is also defined in [18]. After the UE performs inter-edge handover, it will not release the pre-existing UE IP, because the subsequent downlink packets

include the sessions established prior to handover, as well as the new starting sessions. The UE must be able to rec-ognize these different IP sessions. In consideration of the uplink transmission, the UE needs to send the packets by the preexisting UE IP, which enables the receiver to recognize that the transmission belongs to the same session. However, the UE has by now switched to the new edge network. Thus, the packets need to be further encapsulated into new UE IP, which then allows the packets to be transmitted at the new edge network, see Fig. 10 for details.

Subsequently, we introduce the operations of inter-edge handover. Establishment of the session paths and rule in downlink and uplink transmission must be completed by the procedure. The transmission is divided into two cases and further discussed below: (1) Maintaining the original session and (2) starting a new session with the new edge network.

1. The session paths are established by the procedure dur-ing handover preparation: Establish a downlink tunnel

Fig. 11 Maintaining the original session (downlink)

T-eNB

TargetSession AnchorS1-U

S-eNB

SourceSession AnchorS1-U

Edge network

SGi

SGi

PDNmove

Src IP: 2.2.2.2Dst IP: 1.1.1.1

Src IP: 2.2.2.2Dst IP: 1.1.1.1

Src IP: 2.2.2.2Dst IP: 1.1.1.1

UE

UE

Session...

Get new IP

External network

Src IP: 2.2.2.2Dst IP: 3.3.3.3

Src IP: 2.2.2.2Dst IP: 3.3.3.3

Packets

tunnel path bearer path

: Encapsula�on

UE old IP: 1.1.1.1

PDN IP: 2.2.2.2

UE new IP: 3.3.3.3

UE old IP: 1.1.1.1

Src IP: 2.2.2.2Dst IP: 1.1.1.1

Fig. 12 Maintaining the original session (uplink)

T-eNB

TargetSession AnchorS1-U

S-eNB

SourceSession AnchorS1-U

Edge network

SGi

SGi

PDNmove

Src IP: 1.1.1.1Dst IP: 2.2.2.2

Packets

UE

UE

Get new IP

External network

Src IP: 1.1.1.1Dst IP: 2.2.2.2

Src IP: 3.3.3.3Dst IP: 2.2.2.2

tunnel path bearer path

: Encapsula�on

UE old IP: 1.1.1.1

PDN IP: 2.2.2.2

UE new IP: 3.3.3.3

UE old IP: 1.1.1.1

Src IP: 3.3.3.3Dst IP: 2.2.2.2


SN Computer Science

& uplink bearer between the T-eNB and Target Session Anchor.

Downlink Transmission When connecting to the new edge network, an IP session between two peers is simply torn down if the IP address of any of the two peers changes dur-ing the course of the session. This is a result of IP address and Session Anchor relocation and the restraints of current networking solutions [30]. The reason for the interruption of the session is that the downlink sender is not aware of the fact that the Target Session Anchor of the receiver has been relocated. Thus, the sender continues to send the pack-ets to the original Session Anchor, resulting in packet loss. Therefore, we establish a rule of packet encapsulation and a tunnel to transmit this session during handover preparation, as shown in Fig. 11. The Source Session Anchor encapsu-

lates the downlink packets into new UE IP and sends them to the Target Session Anchor. When the Target Session Anchor receives the packets, it will send them to the UE by the established tunnel.

Uplink Transmission Unlike downlink transmission, the uplink transmission is not required to pass through a spe-cific Session Anchor. As long as the PDN network receiver’s IP address is entered correctly, transmission is feasible. To facilitate the receiver in recognizing that the transmission belongs to the same session, the UE must send the packets by the preexisting UE IP and encapsulate them into a new UE IP. The operation is shown in Fig. 12.

2. The session paths are established by the procedure dur-ing handover preparation: Establish a uplink bearer or a downlink bearer between the T-eNB and Target Ses-

Fig. 13 The handover for ARM at core for inter-edge mobility

UE S-eNB

ARM


UE T-eNB

TargetSMC

TargetE-S/PGW-U

Sx

S1-U

PDN

SGi

SGi

SourceE-S/PGW-U

SourceSMC

Sx

S1-U

External network

S1-MME

S1-MME

move

HSS

Fig. 14 The handover for ARM at edge for inter-edge mobility

UE S-eNB

SourceARM


UE T-eNB

TargetSMC

TargetE-S/PGW-U

PDN

SGi

SGi

SourceE-S/PGW-U

SourceSMC

S1-U

External network

ARM-SMC

TargetARM

ARM-SMC

HSSS10

S1-U

S1-MME

S1-MME

move


SN Computer Science

sion Anchor. At this point, the transmission uses the new IP address and new Session Anchor. Therefore, the uplink traffic of the UE can directly communicate with the PDN network via the Target Session Anchor, and the downlink traffic can also directly pass through the Target

Session Anchor and reach the UE. Setting up the tunnel and encapsulating the packets is not necessary.

The differences between inter-edge handover and S1-based handover:

UE

Target SMC

TargetARM

SourceARM

TargetE-S/PGW-U

SourceE-S/PGW-US-eNB T-eNB

HSSSource SMC

S1 Bearer for Indirect tunnel(DL)

PDN

Buffer packets

Create Uplink TEID

Create Downlink tunnel TEID

S1 Bearer(UL/DL)

Create Downlink TEID

Create Uplink tunnel TEID

Encapsulate packets into UE's new IP address

1. Measurement Report2. Handover Required

3. Forward Reloca�on Request


5. Sx Session Establishment Response6. Handover Request

7. Handover Request ACK



10. Forward Reloca�on Response



13. Handover Command

14. Handover Command

Get new UE IP

UE

DRB Bearer(UL/DL) S1 Bearer(UL/DL)

start a new session

S1 Bearer(UL)

keep the original session

Use the old UE IP and encapsulate packets

into UE's new IP address

15. Handover Confirm

16. Handover No�fy

17. Forward Reloca�on Complete No�fica�on

18. Forward Reloca�on Complete ACK

19. Tracking Area Update(TAU) Request20. Tracking Area Update(TAU) Request

21. Sx Session Modifica�on Request

22. Sx Session Modifica�on Response

24. Update Loca�on Request

25. Cancel Loca�on

26. Cancel Loca�on ACK

27. Update Loca�on ACK

29. Tracking Area Update(TAU) Accept

30. Tracking Area Update(TAU) Accept

Fig. 15 Inter-edge handover in E-R-EPC


SN Computer Science

(a) During the preparation of inter-edge handover, the new UE IP is generated to assist the UE in connecting to the new edge network.

(b) The tunnels created in the S1-based handover and the old downlink bearer resource will be released at the end of the procedure. However, there is no need to release tunnels and bearers to maintain connection with the original session during inter-edge handover. Instead, we configured the timers while creating the rule and trans-mission tunnels on Session Anchors; when the Session Anchors do not receive any packets in the timers, they release the rule and tunnels.

(c) The S1-based handover completes new bearer setup during handover execution, while the inter-edge hand-over completes this setup during handover prepara-tion. The reason for the difference is that the S1-based handover will not change the Session Anchor; rather, it only needs to wait for the UE to connect with the T-eNB, and then perform Modify Bearer Request to guide the traffic to the new gateway. Because the inter-edge handover needs to relocate the Session Anchor, it must establish a bearer before the UE connects with the T-eNB, otherwise the new session cannot be started immediately.

The Handover Procedure for Inter‑edge Mobility

In the following paragraphs, we introduce the inter-edge handover process of E-R-EPC. As the procedure involves UEs moving between two edge networks, distinct procedures exist in the sub-architectures that are ARM at edge and ARM at core, which are discussed separately below. In addition, we designed an interface between SMC and SMC (SMC-SMC), which is responsible for the transmission of the ses-sion management messages between two edge networks.

The handover situation for ARM at core is demonstrated in Fig. 13, where we assume both Source and Target eNBs connect to distinct SMC and E-S/PGW-U but connect to the same ARM and are located in the same target area (TA).

The handover situation in ARM at edge is shown in Fig. 14, where we assume both Source and Target eNBs connect to distinct SMC, ARM, and E-S/PGW-U but con-nect to the same HSS. Due to a change in the ARM, the process must include an update to the HSS concerning in which ARM the UE is located.

The proposed handover procedure of E-R-EPC for inter-edge mobility is shown in Fig. 15. The red thick dotted lines (steps 23 and 28) indicate the additional message exchanges between Target SMC and Source ARM, and the red thick dotted frame (steps 19–30) represent the inter-edge process for ARM at edge. The step-by-step message flow of the handover scenario is demonstrated as follows.

Step 1: an UE periodically sends a Measurement Report to the S-eNB. Whether the S-eNB decides to handover or not depends on the report.

Step 2: The S-eNB sends Handover Required to the Source SMC. Handover Required includes a T-eNB ID and necessary UE information (with the pre-existing UE IP address).

Step 3: Based on the network topology, the Source SMC selects the suitable Target SMC for the UE, and then trans-mits the handover information to the Target SMC through a Forward Relocation Request.

Steps 4–5: The Target SMC sends an Sx Session Estab-lishment Request to the Target E-S/PGW-U for creating a PDU session for the UE. The Target E-S/PGW-U responses with an assigned uplink S1 TEID.

Steps 6–7: The Target SMC sends a Handover Request to the T-eNB. Upon receival of the uplink S1 TEID, the T-eNB establishes an uplink S1 bearer, after which it generates a response ACK message that includes an assigned downlink S1 TEID and a downlink S1 indirect tunnel TEID.

Steps 8–9: The Target SMC sends an Sx Session Estab-lishment Request to the Target E-S/PGW-U for creating a downlink S1 indirect tunnel and downlink S1 bearer. At this time, a timer for release resources is configured. When the Target E-S/PGW-U does not receive any packets in the timer, the tunnel is released.

Step 10: The Target SMC sends a Forward Relocation Response to the Source SMC as a response to the handover request in Step 3, the message includes a new IP for the UE.

Steps 11–12: The Source SMC sends an Sx Session Establishment Request (with a pre-existing and a new UE IP) to the Source E-S/PGW-U for creating a connection between two edge networks. Subsequently, the Source E-S/PGW-U responds with the assigned uplink S1 indirect tunnel TEID. The Source E-S/PGW-U creates the packet encapsu-lation rule based on the obtained UE IP information, and the connection between two edge networks is established. At this time, the timer for releasing resources is configured. When the Source E-S/PGW-U does not receive any packets in the timer, the rule and tunnel are released.

Step 13: The Source SMC sends a Handover Command (with a new UE IP and uplink S1 indirect tunnel TEID) to the S-eNB. Upon the S-eNB receiving the uplink S1 indirect tunnel TEID, it establishes an uplink S1 indirect tunnel, then begins to buffer the downlink packets.

Steps 14–15: Once the S-eNB is ready for a handover, it commands the UE to perform a handover by sending a Handover Command message. This message includes the assigned new UE IP, which enables the UE to successfully connect to the new edge network.

Step 16: The T-eNB sends Handover Notify (with ECGI and TAI) to the Target SMC.


SN Computer Science

Steps 17–18: Target SMC sends a Forward Relocation Complete Notification to the Source SMC to inform the completion of handover, and the resource may be released. This step differs from the 3GPP standard. As a pre-existing session may still be ongoing, we modified the message to ensure that resources are not released.

Steps 19–30: (only for ARM at edge case) Because the UE moves from the Source ARM to the Target ARM, the TAU procedure must be performed to update the location recorded by the HSS.

Table 3 Comparison of number of message exchanges for basic procedures in the two architectures (with hop counts)

Frequency

(per hour per RRC connected E)[31]

E-R-EPC

(ARM at edge)

E-R-EPC

(ARM at core)Probability

Initial Attach 0.5 17S: 13

17S: 11

1

A: 4 A: 6

Active to Idle 34 5S: 5

5S: 5

1

A: 0 A: 0

Idle to Active

(UE triggered)19 5

S: 55

S: 51

A: 0 A: 0

Idle to Active (Network triggered)

15 8S: 8

8S: 8

1

A: 0 A: 0

TAU (intra-edge)

2

6S: 6

6S: 4

1 −

A: 0 A: 2

TAU (inter-edge) 14S: 10

6S: 4

A: 4 A: 2

X2-based HO − 4S: 4

4S: 4

1

A: 0 A: 0

S1-based HO

(intra-edge). +

13S: 13

13S: 13

1 −

A: 0 A: 0

S1-based HO

(inter-edge)27

S: 2315

S: 15

A: 4 A: 0

Total 99S: 87

79S: 69

A: 12 A: 10

Table 4 The bandwidth cost of E-R-EPC (ARM at edge)

p = 0.05 p = 0.1 p = 0.15 p = 0.2

f = 0.5 463.67 468.74 473.81 478.88f = 1 469.22 475.34 481.46 487.58f = 1.5 474.77 481.94 489.11 496.28f = 2 480.32 488.54 496.76 504.98


SN Computer Science

ARM Deployment

We analyze the appropriate deployment of ARM in E-R-EPC by three indicators of procedures operated, including the bandwidth consumption, transmission delay, and hando-ver time variability.

Comparison of Bandwidth Consumption

We use the number of message exchanges on each proce-dure transmission path to indicate the bandwidth consump-tion requirement of the two architectures (ARM at edge and ARM at core), as shown in Figs. 4 and 5. The number of message exchanges of E-R-EPC is listed in Table 3. Only the number of message exchanges between the eNB and EPC, and the communication of EPC components are consid-ered. Subsequently, the message exchanges are divided into two categories, S and A, based on communication scope. “S” indicates that the message exchange takes place under the same area (edge or core network), while “A” indicates that the message exchange takes place across distinct areas (edge to core or core to edge). If the transmission of the across messages are greater, more signaling cost is incurred because of the longer transmission path. The frequency for which each basic procedure occurs is also listed [31]; how-ever, these data do not include the concept of the edge net-work, that is, hence, reference values adjustments should be

considered. The frequency of user movement between two edge networks is defined as f (per hour per RRC connected UE) [31]. In terms of TAU, there is no extant case that involves inter-edge. Thus, two procedures (intra-edge and inter-edge) were concurrently considered as the frequency of occurrence of TAU. Regarding the handover, we believe that based on the definition of the handovers in the edge net-work, the frequency of inter-edge handover that belongs to the S1-based handover is considered to be greater; therefore, we adjusted the frequency of the original S1-based handover from 0.2 to 0.2 + f . Subsequently, the frequency of X2-based handover will decrease because the UE must perform inter-edge handover when it moves between two edge networks, thus, we adjusted the frequency of X2-based handover from 8 to 8 − f . On the right side of the table, the probability of the UE moving to another edge network under the system is defined. In TAU and S1-based handover procedures, the inter-edge case probability is set top , the intra-edge case to 1 − p , and remaining procedures are set to 1.

Next, the total bandwidth cost of E-R-EPC (ARM at edge) and E-R-EPC (ARM at core) in the procedures is calculated by multiplying the number of message exchanges with hop counts by the frequency of the procedure and the switching edge probability, as shown in the following formula:

In (1), NS and NA , respectively, represent the number of message exchanges under the same area and the number of message exchanges across distinct areas. Regarding the hop values of “S” and “A”, we referred to [31] and define hopS = 1 ; hopA = 8. Fprocedure indicates the frequency of the procedure; Pprocedure indicates the probability of switching edge in the procedure. The bandwidth cost for all procedures is summed up and the total bandwidth cost of the architec-ture is determined.

Tables 4 and 5 show the bandwidth cost of E-R-EPC (ARM at edge) and E-R-EPC (ARM at core). We determined the reasonable probability of switching edge at ≤ 1/5; thus, we inferred that p ≤ 0.2. f is assumed to be the sum of the frequency of the X2-based handover and S1-based handover, and multiplied by 1/5, which is approximately equal to 2

(1)

Total bandwidth cost

=∑

[(

NS*hopS+NA*hopA)

∗Fprocedure∗Pprocedure

]

.

Table 5 The bandwidth cost of E-R-EPC (ARM at core)

p = 0.05 p = 0.1 p = 0.15 p = 0.2

f = 0.5 493.67 493.74 493.81 493.88f = 1 498.22 498.34 498.46 498.58f = 1.5 502.77 502.94 503.11 503.28f = 2 507.32 507.54 507.76 507.98

Table 6 Delay time of E-R-EPC (ARM at edge)

p = 0.05 p = 0.1 p = 0.15 p = 0.2

f = 0.5 441.04 441.98 442.92 443.86f = 1 445.89 447.18 448.47 449.76f = 1.5 450.74 452.38 454.02 455.66f = 2 455.59 457.58 459.57 461.56

Table 7 Delay time of E-R-EPC (ARM at core)

p = 0.05 p = 0.1 p = 0.15 p = 0.2

f = 0.5 440.12 440.14 440.16 440.18f = 1 444.67 444.74 444.81 444.88f = 1.5 449.22 449.34 449.46 449.58f = 2 453.77 453.94 454.11 454.28

Table 8 Comparison of the variability in the number of message exchanges for the S1-based handover

E-R-EPC (ARM at edge)

E-R-EPC (ARM at core)

S1-based HO (intra-edge) 13 13S1-based HO (inter-edge) 25 15Rate (inter-edge HO/S1-based HO) 1.923 1.115


SN Computer Science

(8.2/5 ≅ 2, rounded to the nearest integer); thus, f ≤ 2. Based on these results, the bandwidth cost under the ARM at edge design is relatively low. However, as p and f values increase, the gap between the two designs will narrow.

Comparison of Transmission Delay

As the delay time is proportional to the number of mes-sage exchanges, evaluating the transmission delay time required in the two architectures for completing the message exchanges is similar to calculating the number of message exchanges for basic procedures.

Delay time is calculated by multiplying the number of message exchanges in the procedure by the frequency of the process and probability of switching edges. The formula is as follows:

In (2), N represents the number of message exchanges in the procedure, and the remaining parameter definitions are identical to (1). The delay time for all procedures is summed up and the total delay time of the architecture is determined.

(2)Total delay time =∑

(

N ∗ Fprocedure ∗ Pprocedure

)

.

Tables 6 and 7 show the delay time of E-R-EPC (ARM at edge) and E-R-EPC (ARM at core). The f and p values are identical as presented in Tables 4 and 5. Based on these results, the delay time results under the ARM at core design

Table 9 Features of the three architectures

Full-edge EPC Partial-edge EPC E-R-EPC

User plane routing path Short Long ShortData traffic transmission latency Low High LowSupport handover between two edge networks N/A Yes YesThe change of MME (ARM) when UE moving

between two edge networksNeed Need No need

Fig. 16 The concept of hop distance

UE eNB

Edge network components

Core network componentshops: 2 hops: 8hop: 1

hop: 1hop: 1

Table 10 Frequency of the basic procedures for EPC (per busy hour per RRC connected UE) [31]

Procedure Notation Frequency

Initial attach Fia 0.5Active to Idle transition Fati 34Idle to Active transition (UE triggered) Fitaue 19Idle to Active transition (Network triggered) Fitanet 15Tracking area update Ftau 2X2 handover Fx2 8 − f

S1 handover Fs1 0.2 + f

Table 11 The signaling cost per procedure (with frequency), ( p = 0.1

; f = 1)

Signaling cost per procedure

Full-edge Partial-edge E-R-EPC

Initial Attach 8593.5 11,246.5 8027Active to Idle 28,594 69,292 28,594Idle to Active(UE triggered) 15,998 43,928 15,998Idle to Active (Network trig-

gered)18,630 61,680 18,630

TAU 4336.8 6884.8 7692X2 handover 3738 12,656 2702S1 handover 3520.4 7284.1 1572.6Total 83,410.7 212,971.4 83,215.6

Table 12 The signaling cost per procedure (with frequency), ( p = 0.2

; f = 2)

Signaling cost per procedure

Full-edge Partial-edge E-R-EPC

Initial Attach 8593.5 11,246.5 8027Active to Idle 28,594 69,292 28,594Idle to Active(UE triggered) 15,998 43,928 15,998Idle to Active (Network trig-

gered)18,630 61,680 18,630

TAU 6805.6 9353.6 7692X2 handover 3204 10,848 2316S1 handover 9799.7 16,500.4 2983.2Total 91,624.8 222,848.5 84,240.2


SN Computer Science

is relatively small, and as the p value increases, the delay time increases by less than that of the ARM at edge design.

Comparison of Handover Delay Time Variability

The handover time depends on the number of message exchanges required to complete the procedure. Therefore, the number of message exchanges for the S1-based handover of E-R-EPC (ARM at edge) and E-R-EPC (ARM at core) are listed, as shown in Table 8. In Table 8, Rate (inter-edge HO/S1-based HO) is employed for calculating the respective handover time variabilities.

After the above indicators were compared, we decided to deploy ARM at core in E-R-EPC. Despite a possible poor bandwidth consumption of the procedure, this approach results in a relatively low transmission delay and minimal handover time variability. Moreover, the advantages of the ARM deployed at core design will become more signifi-cant as the inter-edge probability and frequency continue to increase, such as in high speed moving scenarios.

Comparison of Architectures

In this section, we intuitively compared the performance of the number of message exchanges and the architectural fea-tures of the Full-edge EPC, Partial-edge EPC, and E-R-EPC as shown in Table 9. The results indicate that in addition to exhibiting superior performance in User plane handling, E-R-EPC also provides session continuity service when the UE moves between two edge networks. In Full-edge EPC and Partial-edge EPC, the UE will trigger the change of MME process when it moves between two edge networks. However, the E-R-EPC solves the above shortcomings by deploying the ARM in core network, reducing additional message exchanges in the handover procedures.

Performance Comparison

We evaluated and compared the E-R-EPC performance with full-edge EPC and partial-edge EPC in terms of signaling cost and queueing delay.

Signaling Cost

The signaling cost of basic procedures and inter-edge proce-dures in the three architectures were analyzed. Based on the definition in [33], the signaling cost is the product of the size of the signaling message and the weighted distance (hops).

Table 13 Notation of queuing delay

Notation Description

�procedure Arrival rate in the procedure�component Service rate of the componentNcomponent Number of UEs handled by the component�architecurecomponent

Arrival rate of the component in architecture

Tarchitecturecomponent(procedure)

Queuing delay of the component in architec-ture in procedure

Qarchitectureprocedure

Queuing delay of architecture in the procedure

Table 14 Notation of arrival rate in each procedure

Procedure Notation

Initial Attach �IA

Active to Idle �AtI

Idle to Active (UE triggered) �ItA_UE

Idle to Active (Network triggered) �ItA_Net

Tracking area update �TAU

X2 handover �X2

S1 handover �S1

Table 15 Notation of service rate in each component

Component Notation

UE �UE

eNB �eNB

E-MME �EMME

SGW/E-SGW �SGW∕�ESGW

PGW/E-PGW �PGW∕�EPGW

HSS �HSS

ARM �ARM

SMC �SMC

E-S/PGW-U �ESPGW−U

Table 16 Notation of the number of UEs handled by each component

Component Notation

eNB Naccess

E-SGW NE−SGW

E-MME, E-PGW, SMC, E-S/PGW-U

Nedge

SGW NSGW

PGW, HSS, ARM Ncore


SN Computer Science

For message size, we referred to the 3GPP specifications [20, 34], and [35].

For the values of hop distance, we referred to [35]. The concept in Fig. 16 shows 1 hop between the UE and eNB; 2 hops between the eNB and edge network components, and 8 hops between the edge and the core network components. Whether the components communicate under the edge net-work or core network, the hop is equal to 1.

As shown in Table 10, we referred to [31] for the fre-quency of each basic procedure. The frequency was then added to the evaluation for a more comprehensive analysis. In addition, the same message exchanges which are common to the three architectures, such as RRC and X2 messages, were ignored.

Tables 11 and 12 show the signaling costs of different procedures under the three architectures. The two value sets of inter-edge probability and frequency defined in sec-tion “ARM Deployment” were employed for analysis. The values are ( p = 0.1 ; f = 1 ) and ( p = 0.2 ; f = 2).

Based on the results of the above tables, the signaling costs of E-R-EPC are the lowest. The costs of Partial-edge EPC are the highest because of the design of the E-MME at edge network and gateways at core network, which results in substantial transmission costs when communications between Edge and Core are frequently needed. When com-paring of E-R-EPC and Full-edge EPC, although E-R-EPC has more across area messages, it is associated with lower signaling costs. The reason is that the largest message size originates from communication with the HSS, and a long hop count is required for the E-MME in Full-edge EPC to carry the messages. In fact, the main influences on signal-ing cost depend on the inter-edge procedures of the TAU and S1-based handover. As Full-edge EPC must handle the change of E-MME and the update with the HSS, the number of message exchanges exceed that of E-R-EPC. Therefore, as the inter-edge probability and frequency increase ( p and f ), the cost of Full-edge EPC grows rapidly, while E-R-EPC shows a slight rise. Based on the above comparison, we have proven that the proposed method of firstly refactoring EPC and then determining the deployment of the components effectively reduces message exchanges while lowing the cost of transmission.

Control Plane Queuing Delay

The Jackson Network [36] of the queuing network [37] was employed to analyze the processing efficiency of the three architectures in different procedures. In the Jackson Net-work, every node is considered as an M/M/1 queue, and a node has a Poisson process arrival from other nodes. The service time of all nodes exhibits exponential distribution. The M/M/1 queuing model was applied and the required parameters were listed to calculate the queuing delay of the architectures.

This section lists the parameters used to calculate the queuing delay. The parameters are used to present the queu-ing delay formulas for the basic procedures in the E-R-EPC architecture. Table 13 shows the notation description used in the queuing delay. Tables 14 and 15 present the notations of the arrival rate in each procedure and the service rate of each component.

Table 16 shows the notation of the number of UEs han-dled by each component, which is based on the deployment scope in the network. The scope includes the access network, edge network, and core network, and SGW is deployed in the middle of these scopes.

Table 16 shows the notation of number of UEs handled by each component, which is based on its deployment scope in network; the scopes include access network, edge network, and core network, and SGW is deployed in the middle of these scopes.

Next, the arrival rate of each component in the queuing model of the three architectures is calculated. The approach is centered on multiplying the arrival rate of each procedure (see Table 14) by the number of messages handled by the component, which includes the probability of inter-edge and intra-edge ( p and 1 − p , mentioned in section “ARM Deploy-ment”). Subsequently, we multiply the above results by the number of UEs handled by each component according to Table 16 as shown in Table 17.

Table 17 The arrival rate of each component

Parameter Arrival rate (times/day)

�ERPECUE

6�IA + 1�AtI + 4�ItA_UE + 5�ItA_Net + (3 ∗ (1 − p) + 3 ∗ p)�TAU + 1�X2 + (1 ∗ (1 − p) + 1 ∗ p)�S1

�ERPECeNB

{10�IA + 2�AtI + 6�ItA_UE + 7�ItA_Net + (4 ∗ (1 − p) + 4 ∗ p)�TAU + (3 + 4)∕2 ∗ �X2 + [(3 + 2)∕2 ∗ (1 − p) + (2 + 2)∕2 ∗ p)]�S1} ∗ Naccess

�ERPECARM

[5�IA + (1 ∗ (1 − p) + 1 ∗ p)�TAU] ∗ Ncore

�ERPECSMC

{5�IA + 3�AtI + 3�ItA_UE + 4�ItA_Net + (3 ∗ (1 − p) + 3 ∗ p)�TAU + 2�X2 + [(7 ∗ (1 − p) + (4 + 6)∕2 ∗ p)�S1]} ∗ Nedge

�ERPECESPGW−U

{2�IA + 1�AtI + 1�ItA_UE + 2�ItA_Net + (1 ∗ (1 − p) + 1 ∗ p)�TAU + 1�X2 + [(3 ∗ (1 − p) + (1 + 2)∕2 ∗ p)�S1]} ∗ Nedge

�ERPECHSS

2�IA ∗ Ncore


SN Computer Science

Control Plane Queuing Delay Formulas for the E‑R‑EPC Architecture

Due to length constrains, the above parameters were used to list the formulas of queuing delay for basic procedures in the E-R-EPC only. To estimate the system queuing delay, we hypothesized that there is a single Poisson arrival stream with arrival rate λ that represents the Control plane mes-sages sent to the architecture. The M/M/1 queuing model was employed to calculate the delay time of each component ( Tcomponent ) visited in a procedure. Subsequently, the delay time of each component was summed up and the queuing delay of the procedure was determined.

In addition, the formulas of the TAU and S1-based hando-vers first list the respective queuing delays of intra-edge and inter-edge with the probabilities 1 − p and p , after which both are summed up to determine the queuing delay of the seven basic procedures.

• Initial Attach:

• Active to Idle (S1 Release) transition:

• Idle to Active transition (UE triggered):

(3)

QEREPC

IA= T

EREPC

UE(IA)+TEREPC

eNB(IA)+TEREPC

ARM(IA)+TEREPC

SMC(IA)

+TEREPC

ESPGW - U(IA)+ T

EREPC

HSS(IA)

=6

�UE

− �EREPCUE

+10

�eNB

− �EREPCeNB

+5

�ARM

− �EREPCARM

+5

�SMC

− �EREPCSMC

+2

�EPGW - U

− �EREPCESPGW - U

+2

�HSS

− �EREPCHSS

.

(4)

QEREPC

AtI=TEREPC

UE(AtI)+ T

EREPC

eNB(AtI)+ T

EREPC

SMC(AtI)+ T

EREPC

ESPGW - U(AtI)

=1

�UE

− �EREPCUE

+2

�eNB

− �EREPCeNB

+3

�SMC

− �EREPCSMC

+1

�ESPGW - U


.

Table 18 Number of UEs handled by each component

Component Notation Number of UEs

eNB Naccess 1000E-SGW NE−SGW 5000E-MME, E-PGW, SMC, E-S/

PGW-UNedge 20,000

SGW NSGW 25,000PGW, HSS, ARM Ncore 100,000

Table 19 Service rate of each component

Parameter Service rate (messages/s)

μUE�eNB 1000 [38]�EMME�SGW∕�ESGW�PGW∕�EPGWμHSS 10,000 [38]�ARM�SMC�ESPGW−U 10,000

• Idle to Active transition (Network triggered):

• Tracking area update (TAU):

• X2-based handover:

(5)

QEREPC

ItA_UE= T

EREPC

UE(ItA_UE)+ T

EREPC

eNB(ItA_UE)+ T

EREPC

SMC(ItA_UE)

+ TEREPC

ESPGW−U(ItA_UE)

=4

�UE

− �EREPCUE

+6

�eNB

− �EREPCeNB

+3

�SMC

− �EREPCSMC

+1

�ESPGW - U


.

(6)

QEREPC

ItA_Net=TEREPC

UE(ItA_Net)+ T

EREPC

eNB(ItA_Net)+ T

EREPC

SMC(ItA_Net)

+ TEREPC

ESPGW - U(ItA_Net)

=5

�UE

− �EREPCUE

+7

�eNB

− �EREPCeNB

+4

�SMC

− �EREPCSMC

+1

�ESPGW - U

− �EREPCESPGW−U

.

(7)

QEREPC

TAU_intra= T

EREPC

UE(TAU_intra)+ T

EREPC

eNB(TAU_intra)+ T

EREPC

ARM(TAU_intra)

+ TEREPC

SMC(TAU_intra)+ T

EREPC

ESPGW−U(TAU_intra)

=3

�UE − �EREPCUE

+4

�eNB − �EREPCeNB

+1

�ARM − �EREPCARM

+3

�SMC − �EREPCSMC

+1

�EPGW - U − �EREPCESPGW - U

,

(8)

QEREPC

TAU_inter=TEREPC

UE(TAU_inter)+ T

EREPC

eNB(TAU_inter)

+ TARM + TSMC + TESPGW - U

=3


+4


+1

�ARM − �EREPCARM

+3


+1

�EPGW - U − �EREPCESPGW - U

,

(9)QEREPCTAU

= QEREPCTAU_intra

∗(1 − p) + QEREPCTAU_inter

∗p.


SN Computer Science

• S1-based handover:(10)

QEREPC

X2=TEREPC

UE(X2)+ T

EREPC

SeNB(X2)+ T

EREPC

TeNB(X2)+ T

EREPC

SMC(X2)

+ TEREPC

ESPGW−U(X2)

=1


+3


+3


+2


+1

�EPGW−U − �EREPCESPGW−U

.

(11)

QEREPC

S1_intra=TEREPC

UE(S1_intra)+ T

EREPC

SeNB(S1_intra)+ T

EREPC

TeNB(S1_intra)

+ TEREPC

SMC(S1_intra)+ T

EREPC

ESPGW - U(S1_intra)

=1


+3


+2


+7


+3

�EPGW−U − �EREPCESPGW−U

,

(12)

QEREPC

S1inter=TEREPC

UE(S1inter)+ T

EREPC

SeNB(S1inter)+ T

EREPC

TeNB(S1inter)

+ TEREPC

SSMC(S1inter)+ T

EREPC

TSMC(S1inter)+ T

EREPC

SESPGW−U(S1inter)

+ TEREPC

TESPGW−U(S1inter)

=1

μUE − λEREPCUE

+2

μeNB − λEREPCeNB

+2

μeNB − λEREPCeNB

+4

μSMC − λEREPCSMC

+6

μSMC − λEREPCSMC

+1

μEPGW−U − λEREPCESPGW−U

+2

μEPGW−U − λEREPCESPGW−U

,

Control Plane Queuing Delay Parameter Settings

Values stated in other studies were referenced and utilized in the proposed queuing formulas to calculate the delay time. Subsequently, the results are discussed.

Table 18 shows the assumed number of UE that each component needs to handle. The researchers of the present study assume that the components of the core network are required to handle more UEs when compared to the compo-nents of the edge network.

Table 19 reports the service rate of each component; for which we referred to [9] and [38]. We assume that the ser-vice rates of E-R-EPC components are identical to those of EPC components.

Table 20 presents the arrival rate value of each proce-dure. These values are obtained by using information from [9] to estimate the arrival rate of the handover, after which the frequency of each procedure [32] was used as a ratio to calculate the arrival rate values. However, these data do not include the concept of the edge network, indicat-ing that certain reference values should be considered for adjustment. First, we defined that the frequency of user movement between two edge networks is f , after which the following steps are similar to the concept discussed in sec-tion “ARM Deployment”. The frequency of the X2-based handover is assumed to be 8 − f , which yields an arrival rate of 2 ∗ (8 − f ) ∼ 18 ∗ (8 − f ) . The frequency of the S1-based handover is 0.2 + f , yielding an arrival rate will of 2 ∗ (0.2 + f ) ∼ 18 ∗ (0.2 + f ).

Comparison and Discussion of Queuing Delays in the Three Architectures

The queuing delay results of the basic procedures in the three architectures are discussed. Calculations were con-ducted and results were printed using MATLAB software. We then analyzed the four value sets of inter-edge probabil-ity and frequency defined in section “ARM Deployment”; the values were ( p = 0.1 ; f = 1 ), ( p = 0.1 ; f = 2 ), ( p = 0.2 ; f = 1 ) and ( p = 0.2 ; f = 2).

The results can be divided into two major categories: the non-mobility processes (Initial Attach, Active to Idle, and Idle to Active) and mobility processes (TAU, X2-based handover, and S1-based handover). In the non-mobility pro-cesses, the performance results in the three architectures are similar, because according to the analysis in section “ARM Deployment”, the three architectures experience the same number of message exchanges in these processes.

Due to length concerns, only the results of the TAU, X2-based handover, and S1-based handover procedure in

(13)QEREPCS1

= QEREPCS1_intra

∗(1 − p) + QEREPCS1_inter

∗p.Table 20 Arrival rate of each procedure

Procedure Notation Arrival rate (times/day)

Initial attach �IA 1–9Active to idle �AtI 68–612Idle to active (UE triggered) �ItA_UE 38–342Idle to active (network trig-

gered)�ItA_Net 30–270

Tracking area update �TAU 4–36X2 handover �X2 2∗(8 − f )−18 ∗ (8 − f )

S1 handover �S1 2∗(0.2 + f )−18∗(0.2 + f )


SN Computer Science

Fig. 17 a A comparison of queuing delay for the TAU pro-cedure in the three architectures. b A comparison of queuing delay for the X2-based handover in the three architectures. c A comparison of queuing delay for the S1-based handover in the three architectures


SN Computer Science

the three architectures are presented and discussed. First, we analyzed the results of the TAU procedure. The queuing delay of E-R-EPC is the highest in Fig. 17a, which is due to the design of architecture, the UE location value handling in our architecture is ARM and the EPC access point is the SMC. Unlike the others, which are only handled by E-MME, the TAU message is passed to the SMC and then forwarded to ARM for processing. The steps mentioned above result in a longer delay. However, considering the inter-edge situ-ation, Full-edge EPC and Partial-edge EPC are required to handle the change of E-MME and the update with HSS, resulting in more message exchanges compared to E-R-EPC. Therefore, as the p and f values rise, the gap in queu-ing delays between E-R-EPC and the others will become smaller.

The X2-based handover and S1-based handover dem-onstrate the advantages of the proposed E-R-EPC design. As shown in Fig. 17b and c, their processes need only to pass the SMC and E-S/PGW-U for the procedure to com-plete. In comparison, Full-edge EPC and Partial-edge EPC are required to pass through MME, SGW, and PGW. In the S1-based handover (inter-edge), the E-R-EPC is not required to perform TAU procedures frequently toward the end of the process. Therefore, the delay of E-R-EPC only rises slightly when the p and f values increase, while the delays for the other designs increase significantly. The above analysis con-cludes that E-R-EPC is able to maintain a level of perfor-mance that is as good as that of the other architectures in the non-mobility processes. In terms of the mobility processes, although the performance of E-R-EPC in TAU is less ideal, this procedure mainly occurs when UE is in the Idle state. The X2 and S1-based handover procedures have the biggest influence on user experience, and the E-R-EPC exhibits the est performance in both categories.

User Plane Latency

This section focuses on the user plane of E-R-EPC. We cal-culated the user plane latency to evaluate the performance of deploying R-EPC’s gateway to the edge network. The total delay time for the User plane was calculated by first analyzing the gateway queuing delay and the propagation delay during transmission. Subsequently, we compared the performance of the total delay time of R-EPC and E-R-EPC.

Delay Time Parameters

In terms of the User plane, the main differences between R-EPC and E-R-EPC are the distance of transmission path between the eNB and gateway, and the number of packets that are handled by the gateway. Here we mainly evalu-ated the performance of these differences, and we ignored remaining traits that are identical.

Table 21 The queuing delay parameters [39]

Notation Value (packets/s)

Arrival rate �User_plane 1,533,000–5,533,000Service rate of gateway �

User_plane

GW6,578,947.37

Table 22 The propagation delay of R-EPC and E-R-EPC [40]

Notation Propagation delay, ms

MAD Propa-gation delay, ms

R-EPC PREPC 29.4 1.05E-R-EPC PEREPC 6.25 0.35

Fig. 18 a Comparison of queuing delays in the user plane. b Com-parison of total delays in the user plane


SN Computer Science

We referred to the parameters defined in [39] to calcu-late the queuing delay; the authors in [39] mention that the arrival rate of the User plane is 5.333 million packets per second (MPPS). Thus, we set the arrival rate range from 1.533 to 5.533 MPPS. The authors in [39] consider the ser-vice time of the gateway (SGW + PGW) for each packet as 1∕�u = 152 ns. Therefore, we employed these parameters and converted the unit to packet/sec and listed these parameters in Table 21.

Considering the propagation delay between the eNB and gateway, the authors in [40] used emulation tools to obtain the round-trip time (RTT) of the UE transmitting packets to the PDN network. Then, the authors proposed the con-cept of Fog gateway, which deploys the gateway near the eNB to reduce the transmission time between the UE and core network, which is similar to the design of E-R-EPC. In the current LTE/EPC, the Median RTT value is measured at 58.8 ms, and the median average deviation RTT (MAD RTT) is 2.1 ms. By employing the Fog gateway, the Median RTT is 12.5 ms and MAD RTT is 0.7 ms. We considered the above parameters from LTE/EPC and Fog gateway as the delay times of R-EPC and E-R-EPC and divided these RTT values by 2 to obtain their respective propagation delays, as shown in Table 22.

Delay Time Formulas

Here, we employed the above parameters to list the total delay time formulas of R-EPC and E-R-EPC. Concerning the User plane arrival rate of E-R-EPC, as the gateway is deployed in the edge network, we assume that the E-R-EPC needs to handle a traffic of 1/5 of R-EPC (this idea is similar to section “Control Plane Queuing Delay” Table 18: Number of UEs handled by each component).

R-EPC total delay time:

E-R-EPC total delay time:

Delay Time Results

According to these formulas, we employed the MATLAB tool to calculate the user plane delay time of the two archi-tectures. The results of the respective queuing delay and the total delay time after adding the propagation delay are

(14)

TotalREPCUser_plane

= QREPCUser_plane

+ PREPC

QREPCUser_plane

=1

�User_plane

GW− �User_plane

.

(15)

TotalEREPCUser_plane

= QEREPCUser_plane

+ PEREPC

QEREPCUser_plane

=1

�User_plane

GW− �User_plane∕5

.

displayed below. Figure 18a contains a comparison of the queuing delay; Fig. 18b presents a comparison of the total delay time.

Based on the results of the queuing delay, the delay time of E-R-EPC is the lowest. Since the gateway is deployed to the edge network, it is not required to handle substantial data traffic as the gateway at the core network does. However, the numerical differences between the two results are minimal at less than ten to the negative seventh power. After adding the propagation delay, a significant change in the total delay time comparison is observed. Therefore, we can determine that the impact of queuing delay is relatively small in terms of the User plane. Furthermore, the deployment of the gate-way to edge network can effectively reduce transmission latencies.

Conclusions

In this article, we proposed an Edge-based Refactored LTE/EPC architecture, denoted by E-R-EPC. We consider deploying an SMC that acts as an EPC access point and gateway in the edge network to ensure that most of the pro-cedures and data traffic transmissions can be processed in the edge network. In terms of the deployment of ARM that is responsible for UE registration, authentication, and loca-tion value handling, we decided to deploy the ARM at the core network by using three indicators, namely, bandwidth consumption, transmission delay, and handover time vari-ability. The design can effectively reduce the number of mes-sage exchanges and transmission delays when the UE moves between two edge networks.

In addition, the issue of changing Session Anchor (PGW) and maintaining session continuity when the UE moves between two edge networks was discussed, and we proposed an inter-edge handover procedure. With this procedure, the UE can use the new IP address in the new edge network while maintaining the existing IP session. With this proce-dure, the E-R-EPC can achieve a similar number of mes-sage exchanges for the S1-based handover while exhibiting a small handover time variability.

The signaling cost and queuing delay of the proposed architecture and other existing alternatives such as Full-edge EPC and Partial-edge EPC were compared. In terms of signaling cost, E-R-EPC exhibits the best performance. The queuing delay of the E-R-EPC non-mobility procedures yield similar results when compared with other architec-tures. Furthermore, the performance of the mobility-related procedures of E-R-EPC are the best.

The present study considered deploying LTE/EPC components to the edge network. Future studies can con-sider modifying the edge components with greater flexibly without having to change the entire network architecture.


SN Computer Science

In future, the SDN concept can be further introduced into E-R-EPC architecture, and the SDN controller can be used to manage the User plane gateways. As a result, the opera-tor can directly optimize the entire edge network by adding new functions on the SDN controller to meet the demands of different edge areas of the network and provide customized regional network services.

Acknowledgements We would like to thank the editors and the anony-mous reviewers for their valuable comments and suggestions. Their efforts have significantly improved the quality of this article.

Funding This work was sponsored in part by the Ministry of Science and Technology, Taiwan (Grant no. MOST109-2221-E-194-023-MY2).

Declarations

Conflict of interest The authors declare that they have no conflict of interest.

References

1. Chiang W-K, Chen H-X. A quantitative approach for refactoring NFV-based Mobile Core Networks. In: 2019 IEEE 30th interna-tional conference on application-specific systems, architectures and processors (ASAP), New York; 2019. pp. 135. https:// doi. org/ 10. 1109/ ASAP. 2019. 00- 17.

2. ETSI, White Paper, Network functions virtualization—introduc-tory white paper. 2013. https:// portal. etsi. org/ NFV/ NFV_ White_ Paper. pdf. Accessed 28 Feb 2021.

3. Hawilo H, Shami A, Mirahmadi M, Asal R. NFV: state of the art, challenges, and implementation in next generation mobile net-works (vEPC). IEEE Netw. 2014;2014:18–26.

4. Li Y, Chen M. Software-defined network function virtualization: a survey. IEEE Access. 2015;3:2542–53.

5. ETSI, White Paper, Mobile Edge Computing, A key technol-ogy towards 5G. 2015. http:// www. etsi. org/ images/ files/ ETSIW hiteP apers/ etsi_ wp11_ mec_a_ key_ techn ology_ towar ds_ 5g. pdf. Accessed 28 Feb 2021.

6. Taleb T. Toward carrier cloud: potential, challenges, and solutions. IEEE Wirel Commun Mag. 2014;21(3):80–91.

7. Taleb T, Corici M, Parada C, Jamakovic A, Ruffino S, Karagian-nis G, Magedanz T. EASE: EPC as a service to ease mobile core network deployment over cloud. IEEE Netw. 2015;2015:78–88.

8. Yousaf FZ, Loureiro P, Zdarsky F, Taleb T, Liebsch M. Cost analysis of initial deployment strategies for virtualized mobile core network functions. IEEE Commun Mag. 2015;53(12):60–6.

9. Prados-Garzon J, Ramos-Munoz JJ, Ameigeiras P, Andres-Mal-donado P, Lopez-Soler JM. Modeling and dimensioning of a vir-tualized MME for 5G mobile networks. IEEE Trans Veh Technol. 2017;66(5):4383–95.

10. Sama MR, An X, Wei Q, Beker S. Reshaping the mobile core network via function decomposition and network slicing for the 5G Era. IEEE Wirel Commun Netw Conf. 2016;2016:1–7.

11. Sama MR, Contreras LM, Kaippallimalil J, Akiyoshi I, Qian H, Ni H. Software-defined control of the virtualized mobile packet core. IEEE Commun Mag. 2015;53(2):107–15.

12. Nguyen V-G, Kim Y. Proposal and evaluation of SDN-based mobile packet core networks. EURASIP J Wirel Commun Netw. 2015;2015:1–18.

13. Tran TX, Hajisami A, Pandey P, Pompili D. Collaborative mobile edge computing in 5G networks: new paradigms, scenarios, and challenges. IEEE Commun Mag. 2017;55(4):54–61.

14. Coronado E, Yousaf Z, Riggio R. LightEdge: mapping the evo-lution of multi-access edge computing in cellular networks. IEEE Commun Mag. 2020;58(4):24–30. https:// doi. org/ 10. 1109/ MCOM. 001. 19006 90.

15. Moradi M, Sundaresan K, Chai E, Rangarajan S, Mao ZM. Sky-Core: moving core to the edge for untethered and reliable UAV-based LTE networks. Commun ACM. 2021;64(1):24–30. https:// doi. org/ 10. 1145/ 34341 61.

16. Jain A, Sadagopan NS, Lohani SK, Vutukuru M (2016) A com-parison of SDN and NFV for re-designing the LTE Packet Core. In: IEEE conference on network function virtualization and soft-ware defined networks (NFV-SDN); 2016. pp. 74–80.

17. Pozza M, Rao A, Bujari A, Flinck H, Palazzi CE, Tarkoma S. A Refactoring Approach for Optimizing Mobile Networks. IEEE Int Conf Commun. 2017;2017:1–6.

18. Cau E, Corici M, Bellavista P, Foschini L, Carella G, Edmonds A, Bohnert TM. Efficient exploitation of mobile edge computing for virtualized 5G in EPC architectures. In: 4th IEEE international conference on mobile cloud computing, services, and engineering (MobileCloud); 2016. pp. 100–9.

19. Patel A, Vutukuru M, Krishnaswamy D. Mobility-aware VNF placement in the LTE EPC. In: IEEE conference on network func-tion virtualization and software defined networks (NFV-SDN), pp 1–7; 2017.

20. 3GPP TS 23.401 version 15.2.0. Technical specification group services and system aspects; general packet radio service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 15). 2017.

21. 3GPP TS 29.060 version 15.2.0. Technical Specification Group Core Network And Terminals; General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface (Release 15). 2018.

22. An X, Kiess W, Perez-Caparros D. Virtualization of cellular net-work EPC gateways based on a scalable SDN architecture. IEEE Glob Commun Conf. 2014;2014:2295–301.

23. Netmanias Technical Documents. EMM Procedure 5. Periodic TAU. 2014. https:// www. netma nias. com/ en/?m= view& id= techd ocs& no= 6193. Accessed 1 Jul 2019.

24. Netmanias Technical Documents. EMM Procedure 6. Handover without TAU—Part 2. X2 Handover. 2014. https:// www. netma nias. com/ en/?m= view& id= techd ocs& no= 6257. Accessed 9 Jul 2019.

25. Netmanias Technical Documents. EMM Procedure 6. Handover without TAU—Part 3. S1 Handover. 2014. https:// www. netma nias. com/ en/?m= view& id= techd ocs& no= 6286. Accessed 19 Jul 2019.

26. 3GPP TS 23.214. Architecture enhancements for control and user plane separation of EPC nodes, Stage 2. Version 0.0.0 (Release 14). 2016.

27. 3GPP TS 29.244. Interface between the control plane and the user plane nodes, Stage 3. Version 0.1.0 (Release 14). 2016.

28. Chiang W-K, Kuo P-C. IMS-based centralized service continu-ity. Wireless Pers Commun. 2013;68:1177–95. https:// doi. org/ 10. 1007/ s11277- 012- 0503-z.

29. 3GPP TS 23.502. Procedures for the 5G System (5GS) (Release 15), Valbonne, France, V15.0.0, Dec. 2017. https:// portal. 3gpp. org/ deskt opmod ules/ Speci ficat ions/ Speci ficat ionDe tails. aspx? speci ficat ionId= 3145. Accessed 1 Jun 2019.

30. Taleb T, Ksentini A. Follow me cloud: interworking feder-ated clouds and distributed mobile networks. IEEE Netw. 2013;27(5):12–9.

31. Metsälä EM, Salmelin JTT. LTE Backhaul: planning and opti-mization. In: 2016 John Wiley & Sons, Chapter 5, Planning and



https://portal.etsi.org/NFV/NFV_White_Paper.pdf

https://portal.etsi.org/NFV/NFV_White_Paper.pdf

http://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp11_mec_a_key_technology_towards_5g.pdf

http://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp11_mec_a_key_technology_towards_5g.pdf

https://doi.org/10.1109/MCOM.001.1900690

https://doi.org/10.1109/MCOM.001.1900690

https://doi.org/10.1145/3434161

https://doi.org/10.1145/3434161

https://www.netmanias.com/en/?m=view&id=techdocs&no=6193






https://doi.org/10.1007/s11277-012-0503-z

https://doi.org/10.1007/s11277-012-0503-z

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3145




SN Computer Science

Optimizing Mobile Backhaul for LTE. 2015. https:// doi. org/ 10. 1002/ 97811 18924 655.

32. Wang H, Chen S, Ai M, Hui Xu. Localized mobility manage-ment for 5G ultra dense network. IEEE Trans Veh Technol. 2017;66(9):8535–52.

33. Lee J-H, Ernst T, Chung T-M. Cost analysis of IP mobility man-agement protocols for consumer mobile devices. IEEE Trans Con-sum Electron. 2010;56(2):1010–7.

34. 3GPP TS 29.274 version 15.4.0, Technical specification group core network and terminals; 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Proto-col for Control plane (GTPv2-C); Stage 3 (Release 15). 2018.

35. 3GPP TS 29.281 version 15.2.0, Technical specification group core network and terminals; general packet radio system (GPRS) Tunnelling Protocol User Plane (GTPv1-U) (Release 15). 2018.

36. Kleinrock L. Queueing systems, vol. I, Theory. New York: Wiley; 1975.

37. Bolch G, Greiner S, Meer H, Trivedi K. Queueing networks and markov chains: modeling and performance evaluation with com-puter science applications, Second Edition. 2006. https:// doi. org/ 10. 1002/ 04717 91571.

38. Hasegawa G, Murata M. Joint bearer aggregation and control-data plane separation in LTE EPC for increasing M2M communication capacity. In: IEEE global communications conference (GLOBE-COM); 2015. pp. 1–6.

39. Rajan AS, Gobriel S, Maciocco C, Ramia KB, Kapury S, Singhy A, Ermanz J, Gopalakrishnanz V, Janaz R. Understanding the Bottlenecks in Virtualizing cellular core network functions. In: The 21st IEEE international workshop on local and metropolitan area networks; 2015. pp. 1–6.

40. García-Pérez CA, Merino P. Experimental evaluation of fog com-puting techniques to reduce latency in LTE networks. Trans Emerg Telecommun Technol Special Issue: Fog Mobile Edge Comput (FMEC). 2018;29:4.

Publisher’s Note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Wei‑Kuo Chiang received his B.S., M.S., and Ph.D. degrees in Computer Science and Informa-tion Engineering from National Chiao Tung University (CSIE/NCTU), Taiwan, R.O.C., in 1989, 1991 and 1996, respec-tively. In February 2004, he joined the Department of Com-puter Science and Information Engineering, National Chung Cheng University (CSIE/CCU), Chiayi, Taiwan, as an Assistant Professor. Currently, he is an Associate Professor in CSIE/CCU. Prior to joining CSIE/

CCU, he worked for the Information and Communications Research Laboratories, Industrial Technology Research Institute (ICL/ITRI), Hsinchu, Taiwan, during 1996-2004, where his final position was Sec-tion Manager. Dr. Chiang holds 10 patents. His recent research interests include SIP-based mobility management, service technologies in next generation networks, 4G/5G mobile core networks, and network func-tion virtualization.

Ming‑Wei Wang received his B.S. degree in Computer Science and Information Engineering from Tamkang University, Taiwan, R.O.C., in 2016, and his M.S. degree in Computer Science and Information Engineering from National Chung Cheng Univer-sity, Taiwan, R.O.C., in 2018. He is currently working as a Plat-form Application Engineer in Intel Corporation, Taipei, Tai-wan. His research interest include Network Function Virtu-alization (NFV), and Next gen-eration network technologies.

https://doi.org/10.1002/9781118924655

https://doi.org/10.1002/9781118924655

https://doi.org/10.1002/0471791571

https://doi.org/10.1002/0471791571