Cross Border Service Continuity with 5G Mobile Edge

Abstract

One of the core elements for the upcoming generation of wireless cellular networks is the availability of network service access continuity in addition to high-speed internet and low latency. The forthcoming fifth generation (5G) greatly improves users’ demand in terms of faster download rates, exceptional system availability, superb end to end coverage with exceptionally low latency and ultra reliability. One of the solutions to provide end to end low latency is the utilization of Mobile Edge Computing (MEC) in the network. MEC provides cloud advantages to users by setting up a small cloud server in the edge node (i.e. close to the end-user), which decreases the amount of latency in network connections, in this regard, service migration has required as users migrate to the new location. Optimal migration decisions are challenging because they depend on the cloud environment, or edge nodes belong to different orchestrators, and security issues in the migration process must also be resolved in order to prevent unreliable requests. This study provides different approaches to address these challenges by identifying the security implications of migration methods based on the blockchain integration.

1 Introduction

Mobile Edge Computing (MEC) has cloud benefits to network consumers by setting up a small computing node very close to the end-user which, respectively, reducing latency in user connections and required bandwidth. However, as services and network infrastructures are deployed at the edge of the network, every time that users change location, services need to move as well to guarantee seamless service continuity. In cross border scenarios, service continuity becomes even more challenging since it adds the burden to the network re-selection between two adjacent Mobile Network Operators (MNO) with different network configuration in terms of cloud-settings, or edge nodes belong to separate orchestrators and various policies. Additionally, security issues in the migration process also needed to be addressed to protect the network from cyber-attacks. MEC in combination with the expected high-performance New Radio (NR)/5G has a great potential to push back many limitations of the previous wireless cellular networks. Since the utilization of various types of smart equipment in vehicles has become so common, therefore, vehicles are already considered as connected devices. Nonetheless, very shortly, they will also communicate directly with each other (Vehicle to Vehicle (V2V) communication) and communicate with the road infrastructure (Vehicle to Infrastructure (V2I)) or in general, Vehicle to everything (V2X). This interaction requires a Cooperative, Connected, Automated and Autonomous Mobility (CCAM)¹ platform. The European Union (EU) supports projects in this context such as 5G-CARMEN² [1], 5G-CROCO,³ and 5G-MOBIX⁴ which aim to develop a new MEC-centric platform that encourages greener, safer, and more intelligent transport infrastructure through European countries.

The goal of these projects is to ensure Service Continuity (SC) in the cross border scenarios [2]. However, providing a seamless link/connection while users cross boundaries is a major challenge that goes beyond basic techniques such as network re-selection between various MNOs. It requires MEC-coordinated support as well. The main goal is to provide large scale SC for cross organizational boundaries to maximize the level of service availability and reliability with the highest level of transparency to the user. Recent developments in cloud and edge computing in tandem with 5G will bring about a dramatic shift by having the proper infrastructure to provide the required SC structures. In this chapter, we will present the current status of 5G-enabled MEC and our proposed solution for SC. It also highlights the key transparent problems that need to be resolved in the coming years. We show that in order to provide a solution, an ultra-Reliability and Low Latency Communication (uRLLC) MEC is a suitable platform direction. The architecture is based on the European Telecommunications Standards Institute (ETSI) MEC standards, which enables applications through a distributed multi-edge platform built from a range of nodes close to the next generation NodeB (gNB). This study investigates the advantages and disadvantages of migration strategies based on measuring metrics for both views of end-users and service providers, and evaluates our implementation with benchmark running to review blockchain overhead in the verification process.

This chapter book organized as following; Sect. 2 reviews background technologies and literature review of 5G service continuity. Section 3 introduces and discuss security management for service continuity. 5G-CARMEN architecture and different use-cases of that describes in Sect. 4. Video streaming as a selected use-case of 5G-CARMEN for development and implementation describes in Sect. 5. Section 6 provides our future research directions. Finally, Sect. 7 presents our conclusion.

2 Background and Related Work

This section reviews the background techniques, technologies which provides service continuity for cellular networks and literature review.

2.1 Cloud Computing

Cloud computing has been one of the hottest key technical subjects in the last decade. This phenomena has had many wide-ranging implications across digital engineering, data storage, and information technology (IT) [3]. Cloud computing is a sharing of computational power, storage, server and other IT services over the Internet on the basis of users’ demand, which has the ability to be easily created and released with limited management intervention or participation of service providers [4]. In other words, cloud computing is a kind of technique that provides resources with higher efficiency to the end-user through the virtualization techniques. The key features of cloud computing are availability, scalability remote manageability. The main elements in this technique are the services and data that are spread across the network. As a result, it increases availability and reliability, but it is also not close enough to the end-user to minimize the delay. Cloud infrastructure and IoT merging allows a vast range of technology scenarios [5] as one of the potential solutions.

2.2 Edge Computing

The concept of edge computing is primarily to drive services to the edge of the network. In this regard, computation as well as the required storage cloud has located really next to the end user as close as possible. Multi-Access Edge Networking is one of the core cornerstones of 5G broadband networks [6]. The edge cloud is a distributed virtualized services architecture [7, 8]. This offers infrastructure as services in a layered way to create a complete technology stack, including digital systems or software, hardware platforms and applications [9, 10]. With the MEC, all data generated by IoT devices will be stored, analyzed and processed one stage before being moved to the cloud. In certain instances of use such as autonomous driving, vehicle to vehicle communication which they need to have low latency, this may be significantly Improving the efficiency of facilities such as the lightweight edge [11] a lightweight virtualization platform for cooperative, connected and integrated mobility focused on industry-standard innovations such as Message Queuing Telemetry Transport (MQTT) protocol for communication, Prometheus for tracking and Docker swarm for the application of containerized services in combination with openFaas [12].

Aforementioned a MEC is a form of distributed computing that moves computations and data storage away from the centralized cloud center and get closer to users [13]. The main benefit for this architecture from the user point of view is to receive the same service but in the lowest latency and context-aware services which, should be listed as one of the key uses of the 5G network. In the event of a lack of the MEC architecture, the mobile Internet of Things (IoT) devices should send all captured data to the cloud-side for analysis and processing. However, these edge devices are suffering from low computing performance, therefore in the MEC architecture scenario, first of all, the data can be pre-processed and then passed to the cloud side. Another advantage is the collected data can be used for local decision-making or retained for future use. This is the way, MEC provides many advantages and generates situations that optimize interaction among consumer devices and the network, as like as; reducing the use of bandwidth through allowing local decisions.

In the traditional cloud network, to access services, applications have to request to a static host from anywhere, it puts a burden on the main cloud to address several thousand requests per second, and users have to suffer the high response time, so MEC could contribute in the scope by setting up a small server to process user requests with low latency. The MEC node can cover a wide range of mobile network, in order to keep user’s applications always online, we need to cover all possible geographic areas for user activities.

2.3 Service Continuity

Service continuity (SC) should be defined as a continuous service delivery from the end-users point of view while they are moving [14] from one point to another point. The SC process can be addressed at different layers such as network, devices and domains [15], from the network view, SC is called handover or handoff which transfers user sessions to the next Road Site Unit (RSU). In terms of devices, MECs have to communicate to exchange user service data, and the domain layer is related to internet service providers, telecom operators and other parties that participate into the SC process. Figure 1 illustrates the SC concept when users moves from edge node in one country to another edge node in adjacent country. SC is a challenging activity, subject to various variables and over several dimensions. The heterogeneity of the supporting edge cloud, communications infrastructures and the variability in the different cross-domain scenarios call for a reliable architecture.

Fig. 1

Illustration of service continuity

Service migration is a part of the SC concept that presents for the movements in the application layer of MEC, which facilitate the migration of responding services from the current connected MEC to the next one. The two main techniques in this regard are live migration and cold migration [16]. While live migration presents a process of transferring a running service to another host transparently, cold migration has to pause the service and then resume it after this movement. Three cutting-edge researches on service migration are Follow-Me Cloud (FMC) [17], Markov Decision Process (MDP) [18] also Time Window [19]. These three-studies support the migration process by tracking user behaviors to estimate the service movement. FMC optimizes the migration based on geographical distance, workload or operator policies. MDP calculates the next reaching node probability based on Markov model, the solution is genetic to cover any direction of UE moving, other related attributes as distance, migration cost and duration are also obtained. Time Window searches the optimal service placement to reduce the total service down time, the searching problem can be turned to a concern with the shortest path, it is more dynamic for MDP and can be applied in other scenarios.

As the handover process is the key concern in the radio component of the wireless cellular networks, it draws the attention of many researchers. SC for the optimization of the handover has been investigated in [20, 21]. In [22] SC has been deployed as the primary driver of 5G in heterogeneous environments. Seamless SC by moving facilities closer to the user equipment (UE), i.e. near to eNodeB as a potential alternative [2] and studied precisely in [23]. Various traditional and non-conventional methods, as well as protocols for the sake of full SC through in-advance bandwidth reservations, have also been presented in [24], to avoid dropping calls during the active session. The follow-me edge-cloud has been proposed in [25]. The concept is based on the architecture of MEC Mobility Services. End-to-end delay has been defended which considers computations and applied into the changing edge nodes scenario.

2.4 SC for MEC

It is valid that MEC decreases network loads dramatically and improves Quality of service (QoS) for mobile users by deploying services as close as possible to the edge of the network but, The downside to this approach is the constraint of resources and network coverage, and it is also difficult to stabilize SC with the appropriate QoS for given specifications [26]. Today, most of the networking services deployed are built on top of the Transmission Control Protocol (TCP) protocol, that provides reliable and inter-operable services over a non reliable and non cross platform communication transport connectivity mediums.

Authors in [27] come up with a Follow Me edge cloud (FMEC) definition based on mobility design for MEC, which in their proposed model end-to-end latency computations specified and applied to what they were called it as an evolving edge nodes scenario. Their study has demonstrated detailed migration strategies and is similar to our mobility simulation. Nevertheless, their research focuses only on improvements to the access point without any concrete implementation, which contributes to the security problem as discussed above, and our analysis may show possible scenarios when new systems have introduced.

Authors in [28] discussion of a container oriented model for the MEC framework, model which has been proposed is included of two proactive and reactive migration approaches for stateless applications. In this scenario when the user begins moving out of the node field, the first method is to deploy a new container to the next node and transfer all the volume data before switching the user traffic and turn off the original server. The second one demands all neighbor nodes to create replica services in advance, so when the handover event begins, the user just has to pick the nearest one and we can skip all migration time since the service has already begun. However, the second case leads to a resource problem since the replicated services are not used for a long time until they are used, so it is not easy to scale up the models because we have multiple users of different services, these problems are overcome in [29] of optimization techniques for both migration scenarios.

Considering the orchestrator strategy for control containers in [30] the container orchestrator model for auto scaling telecommunications services have been tested. Docker Swarm, Marathon and Kubernetes are selected, only Kubernetes has an incorporated self-scaling mechanism called Horizontal Pod Autoscaling, combined with a Kube-controller. However, the authors argued that such orchestrators often generate inadequate outcomes and that the solutions are not sufficient for real-time telecommunications services. Their research is based on auto-scaling with the already deployed container, but we have to pull the necessary image before we use it in our simulation, so it takes more time to ask the neighbor to pull the images in advance has provided a boost to the migration process, particularly with the orchestrator, when we do not have to test the car ID when the services are restarted.

2.5 Emerging 5G as an Enabling Technology

The coming generation of the cellular network (5G) projects to significantly boost consumer appetite in terms of excellent user coverage, superb end to end connection with low latency, ultra reliability, and higher data rates. While current methods, such as handover and roaming procedures, have already been adopted as potential alternatives in previous generations, mobile users also experience delays during network switching in cross-border scenarios.

In fact, cellular mobile communications have undergone four generations of evolution. The first generation (1G) roll-out has introduced the first version of a wireless service, which has transformed the way mobile phones are used. Almost 10 years later, the second generation (2G) was introduced to meet and resolve the demands of faster and more stable networking. The third generation (3G) arrived to further boost connectivity speed and efficiency by adding broadband connectivity. Often trying to increase the connectivity rates, the fourth generation (4G) came up with a new challenge related to network bandwidth. Alongside the speed of connection, a variety of other characteristics have been researched and developed from generation to generation [31].

Based on the formal definition of 3GPP, 5G is based on New Radio (NR). NR is expected to improve performance to LTE in terms of connection density (mMTC), spectral efficiency (eMBB), latency and reliability of the network (uRLLC), terminal/network energy consumption, data rate, for various application scenarios [32]. Figure 2 depicted three major 5G use cases with descriptions of based services and applications. According to the third Generation Partnership Project (3GPP) plan, future wireless cellular networks are required to handle at least 10 times more traffic while maintaining ultra-low latency and high reliability. Compared with 4G network, coming 5G utilize virtualization techniques that provide system scaling and fast deployment. Figure 3 illustrates architecture of 5G System Service-based.

Fig. 2

Three key scenarios of 5G use with examples of related applications

Fig. 3

5G system service-based network architecture

Requirements of the 5G have been finalized in International Telecommunication Union (ITU) [33] and 3GPP [32]. The technology must be assisted by the 5G in the three major use cases. The key use case of the 5G is as follows:

• enhanced Mobile BroadBand (eMBB): refers to extensible reliance on the Conventional Mobile BroadBand (MBB) via enhanced peak/average/cell-edge data, power and coverage. 10 to 100 times improvement over 4G.

• ultra-Reliable Low Latency Communications (URLLC): focuses on critical technologies in terms of Round-Trip Time (RTT) safety and reliability, such as tactical wireless communication, autonomous driving, and tele surgery around 1 ms end to end latency.

• massive Machine Type Communications (mMTC): Requirements for evolving 5G IoT contexts with a very large range of embedded devices, such as individual sensors which they can be connected to 5G network via various network access to provides about thousands x bandwidth per area per device [33].

The 5G 3GPP system consists primarily of three components; firstly User Equipment (UE) secondly Access Network(AN), and thirdly Core Network(CN). In addition to these three divisions of network, Data Network (DN) or the Internet is the most important element of current networks either cellular or non-cellular wireless as well as fixed networks. Figure 3 illustrates this network division.

As universal access and pervasive communication across large scale areas has already been provided to smartphone users by the previous generation of cellular networks, connectivity with high speed and movement across roads, highways, rail and so on in vehicular network with a stationary access-point is also difficult to provide a smooth SC.

In this regards several techniques related to network management have been considered for 5G-CARMEN. Authors in [34] come with the possibility of MANagement and Orchestration (MANO) system of physical and virtualized resources. Utilization of MEC very close to the RSU to improves the reliability and low-latency-aware results a management platform for Virtual Network Function (VNF) placement and service migration [35]. In the [36] assessment of V2V networks and 5G when the network cannot reach the whole path then should boost network signalling has been analyzed. Authors in [37] have introduced a controlling design that provides both physical and virtual infrastructure to track the network location and current state of remote and virtualized service functions. New architecture for the 5G network integrating the MEC and the network slicing for autonomous and connected vehicles discussed in [38]. Studies on various groups of genome processing services result in a new approach that leverages network replacements caching and thus makes service implementation scalable for all optimization techniques [39]. Sciancalepore et al. in [40] proposed a network management and orchestration architecture supporting network slicing for services and tenants. By providing multi-domain provider collaboration, the framework enables the service deployment over multiple domains and an efficient sharing of resources across network slices. The main corresponding two components in the framework are an inter-slice resource broker which allocates resources over the network based on policies, user demands and service level agreement (SLA), an orchestrator receives requests from tenants to decide the network slice resource.

Considering service controller in 5G-CARMEN, Gand et al. in [11] designed an architecture for server-less container cluster which could be setup in light weight edge node as Raspberry Pi (RPi). OpenFaas deploys on the top of Docker Swarm, If a service is requested, openFaas will distribute it among the available worker RPi. All metric services as CPU or energy controls by Prometheus which triggers auto-scaling and load balancing in the cluster. The paper [41] proposed a MEC-based collision-avoidance system that is used in the mobility environment. Each vehicle has equipped by an OBU (On-Board Unit) device to report the vehicle status as location, speed via basic safety message (BSM) and sends alerts in emergency situations. All BSM sent to the connected MEC to analyse and decide whether we need a notification for collision or not. The main idea is to understand which brute force all received data from the vehicle, but their experiments show good performances in preventing collision without impacting MEC effectiveness or network latency.

3 Security Management for SC

This section has the aim to explain the different technologies which put on together to provide trust and security on the top of service migration from one MNO to adjacent MNO.

3.1 Underlying Technologies

Within this section, we provide an overview of the technologies underpinning our design, these techniques will be combined to create our trust migration framework.

3.1.1 Distributed Ledger Technologies

Distributed Ledger Technologies (DLTs) is a repository for storing transactions, managed in a decentralized peer-to-peer network, without any centralized control. Since the launch of the blockchain, which is considered to be the first implementation of the DLT, numerous other implementations have been introduced. Each of them focuses on specific features or addresses previous limitations. El Ioini et al. compare three major DLT implementations in [42]. The three DTLs mentioned are blockchain, tangle, and hash-graph. The main aim of these DLTs is to create a secure environment without a trusted third party. In our context, we have chosen to explore blockchain because it is more advanced and offers a lot more functionality than others (e.g. smart contracts).

3.1.2 Blockchain

Blockchain is indeed an array of records, called blocks, that are connected and secured by cryptography, where each block header contains a hash pointer to the previous block. Also, consensus between maintaining nodes enhances blockchain and prevents tampering. Generally, blockchain platform has divided in to three different kinds of blockchain networks which are; permission-less, permissioned and last one private platform. Although private blockchain is operated by one organization, the permissioned blockchain is managed by multiple organizations along with the level of controls. Permission-less blockchain instead, operates as a transparent and open network, where anyone can send transactions and is managed by miners. In addition, there are mechanisms within the blockchain that make it secure [43].

The proposed scenario in this study explains authentication and trust activities between various parties and can come from different nations, for instance of Europe, making use of the security system as Hyperledger is a viable solution.

4 5G-CARMEN

The 5G-CARMEN stands for “5G for Connected and Automated Road Mobility in the European unioN”. The project is a part of Horizon 2020 that is the biggest EU Research and Innovation program. 5G-CARMEN’s objective is to develop a 5G network from Bologna, Italy to Munich, Germany to incorporate various scenarios that improve the use of 5G in cross-border mobility, such as situation awareness, cooperative maneuvering, video streaming, and green driving. 5G gives a boost to the entire telecommunication network with low latency for applications and services that keeps their connections with cloud servers.

4.1 Architecture

SC is a challenging operation, susceptible to different variables and over several dimensions. The heterogeneity of support infrastructures and the uncertainty of the various handover situations call for a simplified and more stable architecture. The launch of the 5G certainly has an important part to play. However, questions still need to be adequately resolved in order to have a consistent ending to final solutions. The first issue involves the awareness of placement services, that is, the ability to deliver services in the best places to ensure a high degree of coverage. Here, we are discussing situations in which services literally pursue moving vehicles by deploying them to the nearest MEC nodes. This field needs to be more explored, in particular in connection with the launch of 5G. The second concern involves cross organizational boundary awareness, that is, the ability to deliver facilities separately from the underlying provider or technologies used. Conversely, the idea of rooming service continuity has to be decoupled from the mobile operator or the telecommunications operator. The aim is to establish an abstract model that isolates the services rendered by all the parties concerned. Figure 4 depicts the system migration architecture of mobile edge computing in cross boarder scenario as users are faced with network re-selection. For edge clouds, application and service orchestration may help control and orchestrate systems via containers [13] determine requirements, review technologies and architecture of MEC in 5G-enabled CCAM platforms.

Fig. 4

The system architecture of service migration in MEC between two countries

Figure 4 demonstrates the migration of networks in MEC as connected wireless users use ongoing call and/or data contact with a cellular network within the borders of two adjacent countries. In the presence of international roaming (network reselection), the problem is the migration of session/service between two separate MNOs/networks, that are regulated by two distinct authorities.

4.2 SC in 5G-CARMEN

The proposed architecture is made up of a collection of edge and cloud computing services deployed at the top of the 5G network. This facilitates the creation of a distributed network of non federated large scale MEC networks, able to satisfy the demands of various situations. In this system every MEC node could support a car inside its radius. MEC nodes function independently or cooperation can be formed between MEC nodes belonging to separate providers (clusters). When cars are on the move, the services required will be accompanied by the transfer of resources from one MEC node to the next one. Migration management can vary based on a variety of parameters. Figure 5 presents this message flow for 5G-CARMEN through Lo-Lo interface while the vehicle is moving from country A to the adjacent country (B). In this scenario, the orchestrator is in charge of data migration among different MEC nodes. When the vehicle reaches the border, the country B orchestrator will be aware of the operating services of this specific vehicle in advance and will set up its services to provide smooth operation. Therefore, instead of passing the whole flow of migration to the core of the system and making a network re-selection (local breakout) process that takes more time, this approach to service conversion can be implemented with less time and very close to the end user. In this project (5G-CARMEN) several techniques have been considered such as a MANagement and Orchestration (MANO) system for physical and virtualized resources [34], utilization of mobile (also called multi-access) edge clouds close to the roadside [35], evaluation of V2V infrastructure [36], and blockchain based SC in MEC [44, 45] to reduce latency.

Fig. 5

5G-CARMEN message flow through Lo-Lo interface

4.3 5G-CARMEN Use Cases

For the intent of investigating MEC-oriented SC from different perspectives, four major use-cases shall be considered (which we derive from the 5G-CARMEN project) as following:

4.3.1 Cooperative Maneuvering

Intelligent tactics in circumstances such as shifting directions, overtaking, entering/exiting highways, maximizing traffic movement and minimizing traffic congestion, must be used to ensure secure and effective navigation between various automobiles. Therefore, if this action could take place on the basis of vehicle data gained, decision-making would be very secure and successful. Cooperative maneuvering, except cooperative lane merging, for V2V connectivity [46].

4.3.2 Situation Awareness

Both cases of human drivers and autonomous vehicles are constrained in their ability to ensure safe and effective travel by their understanding of the road traffic situation. In this respect, the use of local sensors for human drives and autonomous vehicles is very essential, e.g. cameras, accelerators, radars, etc. Unfortunately, in most situations, such points of risk remain concealed until the very last second, like road objects, traffic queues, other cars or vulnerable road users, such as motorcyclists or pedestrians. In addition, any other abrupt changes in road conditions or weather conditions such as heavy fog, snow, rain will raise the likelihood of an accident if the driver or Artificial Intelligence (AI) behind the autonomous vehicle has not been aware of all these kinds of details. This project would also present the alternatives for this usage in the event that the vehicles are presented with the above-mentioned condition. The two main circumstances for situations awareness are; (1) Vehicle sensors and state sharing (2) Back situation awareness of an emergency vehicle arrival. Back situation awareness, with special emphasis on emergency situations in which an emergency car is entering to the road, and all drivers are advised to leave the lane for Vehicle to Network (V2N) communication.

4.3.3 Green Driving

In addition to safety and traffic performance, European road operators and authorities have applied their control skills to air quality and air pollution, which may use signalling to limit speed in highly polluted areas. However, 5G-CARMEN has options to facilitate greener driving.

4.3.4 Video Streaming

On-demand broadcasting of content, live streams and high definition (HD) videos is one of the passenger’s requirements for an autonomous vehicle that improves the quality of experience (QoE) anywhere it might be. The two most critical considerations, on the one hand, are the estimation of the predicted QoS network and on the other hand, the constructive adaptation of streaming software in order to prevent interruptions in the infrastructure wherever possible. It is essential to ensure high quality delivery of service, including in cross country border circumstances and inter operator circumstances. This use case aims to provide consumers with a seamless presentation of video content even in difficult situations, such as cross-border and network re-selections.

5 Video Streaming SC Use Case Deployment

In order to demonstrate the accomplishment of 5G-CARMEN we have chosen video streaming use case to present seamless SC. In this regard we have developed a new simulator environment based on two different environments which provide the roaming scenario. As a first try, we have implemented video streaming SC based on Omnet++ simulator,⁵ and the second approach is the implementation of the same requirements on the top of the NS3 simulator. Deployment of SC simulator based on Omnet++ has its advantages but, the main drawback is the SimuLTE⁶ since the developers of this project do not release any update, therefore, the system is not compatible with the new version of Omnte++ and Operating System (OS) respectively. Furthermore, after we investigate more issues based on Omnet++ we have considered to model SC on the top of the NS3.⁷

The second contribution is, propose a new method for prediction algorithm which consequence on the latency reduction with minimum delay or without any delay but just has an impact on the QoS. The third contribution is about exploiting data protection for SC which here possibility of blockchain has been kept to account. The fourth contribution in this stage of the project is, investigate and setup a laboratory environment sandbox based on the Raspberry Pi⁸ IV to indicate new methods and proposed algorithms.

5.1 Software Deployment

In this section mainly we describe how is the software architecture could be applied to support video streaming SC use cases. We have investigated different architecture to find the most adaptable solution. To be specific, Omnet++ and NS3 based solutions are our target since they enable mobility simulator for network communication use cases. Simulator environment is essential to boost the experiment result of building on-top modules.

5.1.1 Omnet++ Software Architecture

Figure 6 illustrates service management architecture, on-car service makes a request for video streaming, the request should be forwarded from eNodeB, PGW and then to service provider cloud. The provider has to verify the user validity before offering a streaming server, in case of acceptance, the nearest physical MEC will be chosen to deploy a server and response the video casting link to the user application. When the user vehicle gets far from the current connected MEC, the application and mobile user will disconnect with the MEC and reconnect with the next nearest one, a new streaming server will be deployed and continued data streaming.

Fig. 6

Video streaming management system architecture

Figure 7 shows in detail our architecture components, orchestrator is built in Nodejs⁹ to control Docker container which is used to simulate servers in MEC. Omnet++ takes a responsibility to build a simulation environment, SIMULTE provides LTE components as eNodeB and Packet Data Network Gateway (PGW), it connects with SUMO simulator¹⁰ for mobility via Veins.¹¹ Requests and signals are forwarded and propagated by protocols in INET framework.¹² We used curl requests and Restful service to make communications between the Omnet++ components and the orchestrator.

Fig. 7

Video streaming simulation system architecture for service migration in mobile edge computing

5.1.1.1 Implementation of Omnetpp++ Based Simulator

In this implementation car/UE in Fig. 6, gathers radio messages from the current connected eNodeB, then convert them to understandable messages applications at high level in term of data processing, for example, in-car multi-media applications. In this simulator, a python-based reader has been developed to receive requests from the car and responses from servers to show into the car screen. To simplify the model, we only set up a simple server to response its current time stamp and then send it to the UEs. For the handover event, the UE will compute the signal power received from eNodeB to activate the migration procedure to the next eNodeB when the UE get far from the current one.

Figure 7 is about the component design, the simulator is composed by many sub-modules to communicate with others, and also communicate with the orchestrator to control real applications, all parts here is built on Ubuntu 16.04 LTS.

5.1.2 NS3 Software Architecture

The second implementation is based on NS3 simulator which is an architecture for crossing domain scenario, the simulator has been published in [47], in the scope of this paper, we only present general concepts and initial results. The main idea of the simulator is to build two LTE networks and facilitate them to communicate via the roaming channel (with interfaces S6d and S8) as the general design in Fig. 8.

Fig. 8

NS3 simulator general design

Originally, NS3 only provides a single LTE-EPC (Long Term Evolution-Evolved Packet Core) which also means that we only have a single LTE network to work with, besides this, all IP configuration in the LTE network is fixed and not flexible. Figure 9 illustrates additional modules. Therefore, we will try to re-configure the model, build more components to fit our design with two LTEs as following:

• EPC Group: Server, PGW, SGW and eNodeB will be separated from the original LTE-EPC code pack, each region will keep an EPC group and it could configure its IP address range independently.

  Fig. 9

  

  Additional modules

• EPC Global: has and control many EPC group along with the right to control the roaming procedure and assign IP address for that. We also configure the tap devices here to make the system consistency even when the UE leaves the current LTE, it is still in the EPC Global.

• APP Controller: only used for simulated application in NS3 like ping, TCP and UDP messages or even video streaming.

• UE Controller: control all UE behaviors as moving velocity and direction, it also supports triggering the migration process by listening the signal changes.

5.1.2.1 Implementation of NS3 Based Simulator

To enable the flexibility of the host machine, we packed the entire simulator environment (only NS3 work) in a single Docker container, other parts as MEC servers also packed in its Docker container respectively. Based on the configuration, we could deploy the simulator in different host environment to check the efficiency. Our NS3 simulator is stored in the Docker Registry.¹³ Based on the architecture of the simulator based environments, we would build other modules on top of it and show preliminary results.

5.2 Security Mechanisms

Security and integrity are important since in multiple parties could join into the process as LTE providers, infrastructure providers, and they will do verification in each step so we need an adaptable system to boost the process while still maintains the provider agreements. MEC is setup in constraint devices with limited resources, MECs are independent, and migrating services to the unknown MEC could lead to security issues in user data, so we need a mechanism to verify incoming requests from UE, check the next MEC status and protect user data in running services. Details of this implementation are explained in [44].

The MEC trust migration, mainly focused on MEC and describes migratory techniques and manages security issues when vehicles change access points within MEC. The architecture proposed in this study provides on-road vehicles to support online connections to servers by maintaining the advantages of operating services close to users when the car starts to keeps distance from the edge node, while the next closest node will trigger a new connection and service to continue the current on-car application. The migration time must be extremely low, especially for real-time services such as mapping, video streaming, but it leads to a security issue that a node can handle unknown requests instead of a re-connecting one from a trusted vehicle. This study also analyzes the overhead of verification in the migration process, to be specific, we evaluate the application of blockchain in checking un-trusted behaviors.

5.3 Proposed Prediction Algorithm Methods for SC

Crossing national borders could take place in a tunnel or in a poor GPS signal covered area, therefore, we go for different approaches; in this study, we use the UE’s received radio signals to determine the movement. The radio signal is in our opinion the only reliable way to determine whether a UE is covered or not. The radio signal threshold determines the exact network migration [48] instant, while the position can change depending on many other factors such as UE’s sensitivity, gain, weather conditions and many others [49]. In this review, two types of methods were suggested with different upsides and downsides based on two different technologies. The first is based on the frequency of the eNodeB signal and cell sectoring. The second approach is the based on GPS utilization for the prediction algorithm to reduce the time of migration and improve the QoE.

gNB/eNodeB Based Prediction Method

This solution is based on the signal strength of UE and signal strength plus correct cell sectoring of gNB/eNodeB. This algorithm relies on allocated resources of base station [50] i.e. in addition to measure the signal level we should detect the location of mobile users. Two thresholds have been considered in this approach. Figure 10 shows this process. When the vehicle/UE reaches the first threshold, migration of apps, running service or resources will be activated and notification will send to the system. Depending on the location of the user (i.e. road way, highway or rail way) we define the user sector used in conjunction with the relevant region (e.g., −80 dBm) to be known until the first and second thresholds are met. Once the second threshold has been passed, a transition phase to migration of services or apps is started to deploy the operation on the adjacent network.

Fig. 10

Prediction method based on the base-station signal level and 120^∘ cell sectoring

GPS Based Prediction Method

Because at the beginning of the journey the majority of drivers use the built-in GPS of the car to find the optimum route in terms of traffic, road maintenance, and so on, therefore, from the beginning of the journey system can use this information and has a rough approximation of the cross-border moment. The network is then in a position to calculate when the car reaches the border and the network has enough time to assess the requirement for the other side of the border. Figure 11 illustrates this prediction method. At the first point after the distance has been chosen, the car’s GPS warning will be sent to the home network and the visiting network will be informed by the orchestrator.

Fig. 11

Prediction method based on the GPS and network information

5.4 Develop and Setup a Lab Environment

To test the proposed algorithm, we setup a cluster of Raspberry Pi as a testbed. Figure 12 presents the current design of cluster of raspberry pi III.

Fig. 12

The cluster of 8 Raspberry Pis III

The new design is under developing and proposed architecture is represented in Fig. 13. This version of edge development is including of 60 raspberry Pi IV  which Table 1 presents the main specifications of this new single board computer.

Fig. 13

Cluster of 60 Raspberry Pis IV

Table 1 Specification of the Raspberry Pi IV

5.5 Assessment

This study has been experimentally tested the efficiency and overhead of the usage of blockchain in the Hyperledger fabric system in terms of blockchain security based. Tables 2 and 3 present the configuration of this experiment. In order to make a reliable test result with Docker images, we set up two separate Ubuntu machines to make sure that pulling Docker images does not have any advantage over the previously drawn Docker packs, for example, if we need to pull a python-based image and our machine already has a python-based image, the pulling time will be faster than the one that does not have python. The testing strategy which considers in this study includes the analysis of migration processes and blockchain. The blockchain application will be applied for both simulators, since it is outside of the scope of simulator environment so in the study just we present the result of evaluating timing aspects effected to total migration time.

Table 2 Configuration for mobility simulator

Table 3 Configuration for Omnet++ Edge node environment

5.5.1 Omnet++ Simulation Evaluation

The environment settings for Omnet++ are described with Fig. 6 (video streaming). Only the two eNodeBs connect the others to activate the handover/network re-selection requests. Each time the car receives signals from eNodeB and then calculates the strongest signal to choose the next closer eNodeB when it gets far away from the current connection. Omnet++ offers three simulation times of normal, fast and express. In the normal mode, it runs slowly, and we can debug and see all logs, the signal streams are clearly previewed in the mode. Fast mode speeds up the normal mode but with lower time waiting and the express mode skips all logs and runs extremely fast. Omnet++ runs based on simulation time (simTime) and this is a discreet event simulator, so running events don’t function at a normal time but have an event list and run events one by one. We activate simulators to communicate with REST servers, so these timelines are different, and in Omnet++ they are too slow compared to real time stamps on REST servers. Therefore, we select the fast mode to drive the simulation process that is closest to the real-time flow. In our experiment, for three cases, we only consider the handover case, and it takes around 3000 ms to adjust the eNodeB. The simulator will become the basic module for our next evaluation.

5.5.1.1 Performance of Resource Allocation

The Omnet++ based environment has showed the execution time during the migration process with stateless applications, the migration procedure starts with the blockchain authentification, and then pull the Docker images from Docker registry after deploying the required service at MEC. Testing was carried out on two computer systems or machine which introduced for two MEC devices, depending on MEC models, we have different configurations, for example, in case of MEC-Swarm, another machine will join and work on behalf of an orchestrator. There are several time metrics during the handover process [26].

Communication channels and mobility simulator configuration are defined in Tables 2 and 3. In order to test the Docker images, we prepared a simple web service packed in an Docker image based Python core and response the current time-stamp via port 3000. It only takes 354 MB in size disk and in deployment, the pulling time is 47,080 ms (PIT). Obviously, a heavier image takes more time in pulling, for instance, a 5.3 Gb Docker image (Jupiter notebook) could take up to 5 min only to download from Docker Hub while a super light image as NodeJs with 55 MB just takes 3 s. The network stability and connection will affect to the PIT value so the revolution of 5G could support here to boost that.

Considering Orchestrator Arrangement Time (OAT), it is always zero for all cases, in Single-MEC, nodes are orchestrated by themselves, as the conventional model, for MEC-Cluster, as nodes already knew others, and find the next node at the first request time, the last technique is also identical, so we can save OAT time in that case.

For the blockchain verification part, smart contract based on the Hyperledger with different functions has been developed, we also have a log function to track all service deployment and user activities why using the services at MEC.

Figure 14 demonstrates the execution time changes for the three selected simulation scenarios i.e. Migration overhead, the key issue is the drawing of the model, while in this scenario, our designed image should be taken into account to be a standard size model, the time investment is around 46,980 ms. It worth to mention that observed the launch time of the container would be shorter if we could have a time interval after pulling, in Single-MEC, it recommended to starts the service right after pulling all sub-parts of images that could take more around 3.1 s, however, with MEC-Cluster and MEC-Swarm, the Deployment Time (DT) is only 1.6 s (a half of that). Besides that, in MEC-Swarm, the verification process of blockchain is already underway in the previous node, so it can save a huge amount of time, for next-step users could be interrupted for about 2 or 3 s in the other strategies. High-security and user-experiment is the trade-off of the network because though the chain is getting longer, we can spend more time on it.

Fig. 14

Migration overhead

5.5.2 NS3 Simulation Evaluation

In NS3 simulator setup, we first defined the experiment settings and then deploy it before evaluate the real applications.

5.5.2.1 Experiment Setting

Figure 8 presented the topology design of our simulator and Fig. 15 illustrates roaming and service migration flow. We have two LTE-EPCs and they connects with others via roaming procedure. In order to run the real applications via the simulator, we applied tap device of NS3 and built bridges to the real world. The tap device will connect with Docker containers and then forward requests through it.

Fig. 15

Roaming and service migration flow

The experiment setting of the simulator only is showed in Table 4, the UE speed here is 10.8 m/s corresponding with 39 km/h as the normal car speed in the road which is reported by the survey [51].

Table 4 Configuration for NS3 mobility simulator

The edge node configuration is demonstrated in Table 5, as we investigated from,¹⁴ the average distance among eNodeBs is around 200 m so in our simulator environment, all eNodeBs will be in the same road with the same distances among each pair of them. Followed by the technical document¹⁵ with the LTE delay as smaller than 100 ms, so all LTE socket delay will be set as 100 ms while the roaming socket (S8) is configured by the propagation delay that is reflected by the distance between the two LTE networks. The roaming and service migration flow are presented in Fig. 15.

Table 5 Configuration for NS3 host environment

5.5.2.2 Measurement

Concerning SC downtime, we also experiment the similar results as Omnet++ in Fig. 14. Besides that, the total latency during the migration process and response time in both roaming and non-roaming situations will be examined with two applications as ping and video streaming, they both run in real Docker services.

5.5.2.2.1 Ping

The two Figs. 16 and 17 presented the signal and latency changes in cases of domain changes. The current time-stamp is in the X axis while the Y2 axis is for the current distance and Y2 axis is about RSRP values and the latency. For the first case in Fig. 16, the average time of response in ping is 18 ms while the maximum one is 24 ms, video streaming service and gaming can run without any issues in this network capacity. In contrast, the ping response average is more than 30 ms in the roaming case and the maximum one is 54 ms, that makes a bit lag for some heavy games and live video streaming. In addition, if we increase the distance between the two LTEs, the S8 delay will be escalated dramatically. Besides that, in case of local server, changing LTE also means modifying the IP address of the user which makes the video streaming of user get a bit pause while updating the IP and make it inconvenient as non-continuous service.

Fig. 16

Roaming server requests

Fig. 17

Local server requests

5.5.2.2.2 Video Streaming Result

The video streaming application will show clearly how the migration process affects user experiment by checking the video frames. We pulled a Firefox browser based on Docker Image to work as a UE screen while a Mist server¹⁶ will run on other Docker containers and stream video frames. The Mist server takes only 310 MB in size disk that is really light weight but support many different types of streaming protocols.

However, in term of statistic, the Mist server does not have many options to check the quality of service, the memory usage, CPU and network bandwidth are the only metrics we could get as Fig. 18. In the graph, the connection becomes unstable, especially in the handover event, at the same time, the CPU is released a bit because it does not have to do streaming.

Fig. 18

Metric statistic in Mist server

5.5.3 Simulator Evaluation Overview

Generally, the both simulator enable a comprehensive environment, nevertheless, from telecommunication networking perspective and reference scenarios, NS3 has more advantages by supporting roaming procedure, while Omnet++ only perform a normal handover. Besides that, based on NS3, we could get a better result in real time service and signal changes during user moving with the graph 16 and 17 that we cannot collect the data in Omnet++. Therefore, NS3 will be our choice for further researches.

6 Future Research Directions

SC is a challenging undertaking, susceptible to different variables and over several dimensions. The heterogeneity of the supporting infrastructures especially in 5G which is based on different technology to deliver high speed and more reliable network connection on the other hand the variability of the various handover situations among these different technologies calls for a simplified and more robust architecture. The launch of 5G certainly plays an important part, but problems do need to be adequately handled in order to provide a stable end to end-to-end solutions. The first issue involves the awareness of placement programs, that is, the ability to deliver services in the best places to ensure a high degree of network coverage. Here we are discussing scenarios like the one outlined in [52], which services basically pursue moving vehicles by installing them at the nearest MEC nodes. This field needs to be more explored, in particular in connection with the launch of 5G. The second issue involves cross-organizational boundary recognition, that is, the necessary to produce facilities separately from the underlying provider or technologies used. Conversely, the idea of rooming SC has to be kept separate from the mobile operator or the telecommunications sector. The aim is to establish an abstraction layer that segregates the services rendered from all the parties concerned.

7 Conclusions

In order to allow broad scale SC to cross organizational and cross-border borders, a combination of technology and techniques needs to be implemented and tuned to satisfy precise functional and quality criteria. The primary aim is to optimize the availability of resources with the maximum degree of transparency for the client. Mobile operators have approached this problem over the past few decades using various methods, most of which have been thwarted by the underlying technologies. However, recent developments in cloud and edge computing in tandem with 5G could bring about a dramatic transition by having the proper networks to provide the channels required for seamless continuity of service.