Federated 3GPP Mobile Edge Computing Systems: A Transparent Proxy for Third Party Authentication with Application Mobility Support

There are multiple MNOs in the world and they likely have their own MEC servers deployed in their infrastructure. The subscribers of these MNOs would be able to access the services provided by the deployed MEC servers. In the early deployment stage, individual MNOs may not be able to provide MEC coverage in all areas. Different MNOs would cover different areas, depending upon the location of MEC servers. Therefore, a user will not be able to get complete coverage and, if there is no collaboration among multiple MNOs, a subscriber would have to buy a subscription from multiple MNOs and create multiple accounts for multiple application servers deployed in different MNOs. Furthermore, having to provide login credentials every time a user tries to access an application would greatly increase the latency and reduce a user’s experience.

Hence, it would be more advantageous for both the service providers and their subscribers, if the service providers could form a federation among themselves. This kind of federation is already in practice for cloud service providers [6]. Such a federation would encourage MNOs to collaborate and share resources among themselves in order to provide multiple services and better coverage to all their users. Such a federation among MNOs is better as compared to a federation among MNOs and cloud or fog networks because the base stations of MNOs are closer to each other. Therefore, a federation among MNOs would allow them to share resources and provide faster mobility to their users. Furthermore, a federation among MNOs would provide extended MEC service coverage.

The advantages of such a federation are twofold: MNOs would be able to serve more users and users will have access to continuous low latency MEC services without having to rely on cloud or fog. Users would be able to obtain MEC services from such a federation using just a single SIM card without having to buy subscriptions from different MNOs, and they would also be able to switch between networks in order to get the best services. A federated system would also open doors to more modularised services and applications that can be shared by multiple networks.

We have explored literature that addresses authentication and application mobility issues in federated mobile networks. To the best of our knowledge, no study in the current literature provides solutions to both the issues identified in the previous section. There are two different ways to solve the two issues we have identified; one is to propose a new protocol that provides authentication and application mobility across multiple MNOs and the other way is to use the existing 3GPP standard protocols and build the solution using the existing protocols. The latter is better as it does not involve any modifications in the existing protocols and provides transparency.

Solutions have been proposed for developing a transparent, low latency system that provides Authentication, Authorization, and Accounting (AAA) functionality in a MEC system in a single network [10]. Transparent solutions have also been proposed for third-party authentication and application mobility between MEC platforms in a single network [11]. Our proposal integrates these solutions and provides solutions to authentication and application mobility problems in federated 3GPP inter-MNO MECs, is transparent, and meets the low latency requirements in a federated 3GPP MEC System.

We propose a Federated State transfer and 3rd-party Authentication (FS3A) mechanism that makes use of a transparent proxy that can transfer the authentication and application state information across the MNOs to provide 3rd-party authentication and application mobility. The basic design idea is based on a proxy network that keeps inter-MNO communications close to the ground and leverages roaming based cellular authentication to provide 3rd party application authentication in foreign networks. The proxy is consists of virtual counterparts, so as to avoid any changes to the existing MEC and 4G/5G cellular network architectures. UEs are authentication by a foreign MEC network by inspecting cellular traffic during roaming authentication in the foreign cellular network. The MEC network can then provide access tokens to the UEs for accessing its application servers. FS3A also provides scope for reusing application access tokens across the MECs that belong to other MNOs for faster authentication. In FS3A, MEC-tier application state transfer is done using MEC host and system-level entities to manage the application mobility in the federation. Subscription data and application state data prefetching are done to further reduce the authentication and application mobility latencies. The main contributions of this work are summarized as follows:

• •

  We propose a federation between MECs deployed by different MNOs and develop an FS3A mechanism for solving the third-party authentication and application mobility issues in the proposed federation.

• •

  The FS3A makes use of a proxy network, host and system level MEC entities to transfer the authentication and application state information across MECs in different MNOs. These adaptations are compliant with current MEC specifications, existing 4G LTE network standards and will be compatible with 5G standards as well.

• •

  FS3A demonstrates how low-latency application authentication is provided in foreign MEC systems by inspecting roaming cellular authentication. FS3A provides scope for reusing application access token without re-authentication through MEC system, reducing application down-time while moving across networks.

• •

  FS3A performs subscription data and application state data prefetching to further reduce the authentication and application mobility latency.

The rest of the paper is organised as follows. In Section 2, we review the 3GPP and ETSI standards, look into the threat model for our problem and explore relevant literature to learn how similar problems were solved. In Section 3, we state the problem and provide some examples to illustrate various scenarios, and in Section 4 we described in detail our approach, architecture design, and message flows. Section 5 covers the details of the implementation, modules, and testbed. Section 6 reflects the results and evaluation them. We conclude the paper in Section 7 and present some points to be investigated in the future.

4G-LTE is the most widespread mobile network in the world and is a prime candidate for an underlying cellular network within which MEC systems will function. Designs developed for an LTE network will also have to be compatible with future 5G networks. An UE, eNodeB (eNB), and an Evolved Packet Core (EPC) constitute an LTE system. EPC consists of a Home Subscriber Server (HSS), Mobility Management Entity (MME), and Serving and Packet Gateway (SPGW). An UE is the end-device through which a user communicates with an EPC via eNB. The HSS acts as the database of all cellular information of subscribers. The MME manages the access and mobility aspects of each UE. MEC servers can be deployed in 4G LTE network through different architectures provided by ETSI [12]. In order to achieve lower latency, we used the Bump-in-the-wire approach where the MEC platforms are deployed in between the eNBs and the EPC.

An MEC system consists of different host- and system-level entities which manage the functionalities within a single MEC platform, and the functionalities across all the platforms in the system. The MEC manager is a host level entity that manages the components inside the MEC platform. An MEC Orchestrator (MEO) is a system-level entity that maintains an overview of the MEC system based on deployed mobile edge hosts, available resources, available mobile edge services, and the topology. An MEO also triggers application instantiation, termination, and application relocation at different MEC platforms in order to provide the best services based on the available resources [9]. As per ETSI standards, application mobility services are to be provided by an MEC systems. MEC systems need to provide necessary information to the MEC applications about when and where to transfer user context during application mobility [13]. This overview of the MEC system explains the functionality of different components and helps to identify how the functionality of these components can be extended to accommodate federated authentication and mobility.

In this work, a cellular network and an MEC system are considered as benign. However, UEs are considered to be malicious. A malicious UE may or may not be a user of the underlying cellular network. Malicious traffic sent by UEs can be handled by the core of an LTE network, but since MEC traffic does not go through the core network, malicious UEs can pose different threats to MEC systems. A malicious user may steal user IDs from other users or may reuse an ID that has already been used by itself or by others to get unauthorized access to MECs. Users may also hijack session IDs of others and may generate large amounts of traffic to incapacitate an MEC system. A federated MEC system should be resilient against these attacks. In section IV, we will see how our design copes against these problems.

In order to find solutions to the proposed problem, we examined studies that have proposed solutions to at least one of these problems, either 3rd party authentication in federated systems, multi-network authentications, or application mobility across networks. We analyzed the transparency of these proposals according to existing LTE protocols and MEC standards. Our findings are summarized in Table I. Some studies [14] propose third-party authentication through the cloud. There are also studies [15]-[19] that use blockchain, mutual key exchanges, Reinforcement learning (RL), and federated IDs to manage Multi-network authentication. A study [20] provides handover authentication by improving the existing EAP-AKA protocol and another study [21] makes use of tokens to provide service access control in 5G MEC. A few studies [22][23] also use SDNs to manage authentication and application mobility in federated networks, while another [24] provides application driven handover while retaining transparency.

We also looked into studies that propose solutions for application relocation and most of them focus on VM migration, for example [25] and [26]. On the other hand, recent literature also provides transparent, low-latency solutions for authentication and mobility within a single edge network [11][27][28], anonymous mutual authentication in MEC platforms [29], and third-party authentication between cloud and edge [30]. Some work has also been done on the deployment of a secure MEC system in a cellular network that can itself provide authentication for its applications [10]. We use this MEC deployment method in our work and extend it further across federated MNOs.

An earlier study from some of us [11] provides low-latency authentication and state transfer while moving from one MEC platform to another by using two approaches, termed TC3A and TS3A. In order to compare this work with [11], we summarize the differences in Table II. It can be seen that TC3A, TS3A, and our proposed FS3A provide third-party authentication and application mobility but FS3A does that in a federated MEC system. The major advantage of FS3A over TS3A and TC3A is that it solves the challenges of subscription and state data prefetching and provides the Inter-MNO MEC connectivity, while TS3A and TC3A work for Intra-MNO MECs that are deployed by the same MNO.

Our survey shows that previous studies have provided solution to authentication and application mobility issues independently in the MECs deployed by an MNO but, no previous study provides solutions for authentication and application mobility issues together while maintaining transparency and latency requirements in federated MEC systems across multiple MNOs. It should be noted that we do not try to solve the call and data roaming problems as they have already been addressed by various studies [31] [32] [33]. We solely focus on solving the problems of third party authentication and application mobility for a user that roams between MECs deployed by different MNOs. To the best of our knowledge, ours is the first work that provides a complete solution to the problems at hand, i.e., third-party authentication and application mobility in federated MEC systems while meeting transparency and latency requirements. We adopt the transparent, low-latency authentication solutions from Intra-MNO MEC [10][11] and enhance them to solve the problem of third-party authentication and state transfer in an Inter-MNO MEC federation.

Consider two 4G-LTE MNOs in a federation which provide MEC services. We assume that they use an MECSec design [10] to manage authentication, authorization, and access control. We assume too that an UE is the subscriber of one of the MNOs (referred as the home network). The HSS in the home network contains the subscription, authentication, and other information about the UE. The other networks where the UE does not have a subscription are termed foreign networks. In this work, we consider two scenarios. In the first scenario, we assume that the UE wants to access the MEC services provided by a foreign network, and where the UE needs to obtain authenticated in the foreign MEC with the authentication credentials from the home network, as shown in Fig. 1(a).

In the second scenario, as shown in Fig. 1(b), we assume that the UE has moved to the foreign network while using an MEC service in the home network. In this case, the foreign network derives authentication information either from the home cellular network or from the home MEC system. Application state information also needs to be carried from the application instance in the home network to its foreign counterpart. In this work, we will only consider the scenario where the UE moves from the home to the foreign network. Cases where the user moves from the foreign to the home network have not been considered here, because the UE is already authenticated with the home network and application mobility in this case works the same as the home to foreign networks scenario. We have assumed that the underlying LTE networks are connected for providing roaming cellular services to their users.

Some challenges arise when an UE moves in a federated MEC system as it is important for the UE to be identified by the MEC systems in all networks by means of a common ID. The ID for each user must be unique and unchangeable. A UE is then given a unique temporary ID by the cellular network. The entities in the cellular networks also use different temporary IDs to keep track of the tunnels formed to serve the user. The UE is also given an IP address after it has attached to the cellular network. Since the MEC platform sits between the EPC and eNBs, it can only inspect the packets in the S1 interface. An UE may come into an MEC platform either by attaching for the first time by service resumption, or via handover. In these cases the UE attaches to the cellular networks using different IDs. Under all these circumstances, it must be made sure that the traffic from a user is uniquely identified by the MEC system.

The application mobility in MEC systems belonging to different MNOs also creates some challenges. The MEC system must have the following information before it does application state transfer: from where the application state is to be transferred, to whom is it to be transferred, and when to transfer. Since the user becomes completely detached from the home network and attaches to the foreign network, the home network has no way of knowing beforehand to which foreign network the user will move, and so the MEC platform in the home MEC system cannot initiate the application handover. It is therefore important to solve this state transfer challenge with the lowest possible latency. Another major challenge is to keep the system design transparent so that no modification of the current cellular and MEC infrastructure is required. In summary, our objective is to provide transparent 3rd-party authentication for the UEs in the foreign networks along with seamless application mobility with minimal latency.

The FS3A has two parts, one is for third-party authentication and other is for application mobility via state transfer. For authentication in the foreign network, the MEC system picks up UE authentication information from the underlying cellular network. We propose adding a system-wide datastore for each individual MEC system for storing all authentication information and user information, making it possible for the MEC system to store and share user information among MEC host platforms during its lifetime in the network. For application mobility via state transfer, we included two mobility functions, the host level Application Mobility Service (AMS) and the system level Application Mobility Coordinator (AMC) in the MEC system. AMCs exchange user context and state transfer information through the proxy that provides the means for inter-MNO communication. FS3A ensures that no changes are required in the existing protocols and design of the underlying cellular network.

FS3A places most of the responsibility of application state transfer on the mobility management functions (AMS and AMC) which reduces the burden on the MEC applications and UEs. FS3A does not require any assistance or intervention from the user, making it highly secure and fast as all the processes are run in the MEC tier. The proposed FS3A solution also makes use of few optimizations such as the token reuse instead of re-authentication at the foreign network and data prefetching in order to further reduce the latency. Overall, FS3A is transparent in design, fast, and secure from the attacks of malicious users, and it is also easy to deploy. In the next subsection, we look at the architecture design and individual components that are required for FS3A in more detail.

FS3A provides MEC-tier authentication and state transfer via a transparent proxy. The following components have been added or extended in the MEC system to accommodate FS3A: a system-wide datastore for each MEC system and mobility functional components, host-level AMC, and system level AMS. Fig. 2 shows an MEC system with the relevant components for FS3A. The entities highlighted in blue are the ones we have added or extended in our proposed solution. The proxy system consists of distributed, interconnected proxy entities through which MEC systems and their underlying cellular networks connect to foreign networks via virtual counterparts so that the transparency is maintained. The MME and HSS communicate through the S6a interface which uses the Diameter protocol. In the MEC domain, virtual AMCs transfer messages related to user context from one network to another. To route the messages, the virtual AMCs have tables which store routing information for each of the networks.

The message flows for Federated 3rd-party authentication and state transfer in the FS3A procedure are elaborated as follows:

We test our proposed solution on an OpenAirInterface (OAI) based 4G-LTE network. The solution is equally feasible for the 5G cellular network as it does not propose any changes to the underlying cellular network architecture. We set up two networks for the prototype, each consisting of an LTE cellular network and an MEC system integrated with it. To run the experiment, we set up an MEC application server in each network. The MEC applications authenticate their users through cellular OIDC, and behave the same as any OIDC Client. The cellular OIDC Identity Provider provides IMSI information to the MEC application as the user ID. The proxy consists of a FreeDiameter s6a relay and a custom relay for MEC information transfer.

OpenAirInterface [34] implementations provide the LTE cellular network platform. We used a ueltesimulator [35] to simulate the UE. Roaming support was added to the LTE networks so that S6a traffic of roaming users were redirected to their home networks. The dataplane dispatcher routes the MEC data towards the MEC servers and the GTP tunnelling module decapsulates the data packets before they are sent to the MEC servers. libgtpnl library [36] was used to handle GTP tunnels. The control plane dispatcher, implemented in C, sits between the S1AP interface between the eNB and the MME and acts as a proxy. It sends a copy of the packets to the MEC Manager.

The MEC Manager was implemented with python via using the pycrate [37] library, and it parses the messages and sends the information relevant for MEC authentication to the cellular OIDC module, which in turn accumulates them in a Dictionary. The cellular OIDC module, AMS, AMC and the MEC server application were implemented using Node.js. The front end application and back end MEC server applications are simple React and Express Node.js applications respectively. The MEC relay component of the proxy was implemented using Node.js, and the information of different networks was stored and managed by this component. They have persistent socket connections in between them for faster data transfers. The detailed architecture with all the modules are shown in Fig. 5.

Our testbed was set up on 2 PCs, both with same hardware configuration and Linux Ubuntu Operating System. The UE and eNB of both cellular networks was set up in PC-1, while PC-2 was set up with the EPC and MEC components. Proxy components were set up in PC-1 to make communication between two EPC more realistic. Docker was used to containerize the components and docker networks were used to create virtual networks in each PC. Both the PCs were connected to the same LAN through a router/switch. We also deployed the authentication server which was an OIDC IdP provider written in Node.js. The cloud components were hosted in Google Cloud Platform (GCP) in order to test the latency difference between the scenario where the authentication server was deployed in the cloud and the scenario where the authentication server was deployed in the MEC. The location of the GCP server was set at asia-southeast-1 (Singapore) which was the closest available server to the rest of the testbed in Bangladesh. The bandwidth of the network between the MEC setup and the cloud was 20Mbps.

For the first set of results, we investigated the UE authentication latency by dividing it into three steps: authentication with the foreign MEC, access control, and registration. We also considered multiple scenarios to calculate the UE authentication latency in order to determine the efficiency of FS3A. The authentication time was calculated for 8 possible scenarios, as shown in Table III. We designed these scenarios by placing the authentication server in the cloud or the MEC, by fetching the subscription data during UE authentication or prefetching, and by carrying out the UE re-authentication at the target MEC or reusing the authentication token provided to the UE by the application server in the home MEC.

We calculated the UE authentication latency for all 8 scenarios, as can be seen in Fig. 6. It was evident that the MPT scenario (FS3A) took the least amount of time as it used the subscription data prefetching and reused the authentication tokens while the authentication server was in the MEC. The results also show that placing the authentication server in the MEC reduced the latency by 28–58% compared to placing the authentication server in the cloud. It was also seen that the token reuse and the subscription data prefetching reduced the authentication latency by 53–65%, compared to the complete re-authentication and subscription data fetching during UE authentication. This clearly shows the importance of the proposed token reuse and data prefetching optimizations.

For the second set of results, we calculated the state transfer latency to see how much time was taken to fetch the application state from the UE’s home network in order to resume the application in the target network. We measured this latency for the states of different sizes in three different cases. In the first case, the state was downloaded from the cloud, which might be required if there is no FS3A in place to transfer the state from one MEC to another MEC. In the second case, the state was transferred via MEC proxy without using the state data prefetching, while in the third case, state was transferred via MEC proxy along with the state data prefetching.

Fig. 7 shows the state transfer latency comparison of the above mentioned three cases for the state sizes of 10 KB, 1 MB, and 10 MB. It is clear from Fig. 7 that, as the states size increased, the latency for the state transfer via the cloud server during handover increased considerably. Therefore, we suggest that Mobile Network Operators avoid using the cloud for state transfer as it leads to poor user experience. Our proposed FS3A (without state prefetching) took much less time compared to state transfer via the cloud as it transferred the state via the MEC proxy. It can also be seen that, by using state prefetching, we further reduced the state transfer latency by 51.4%, 80.6% and 91.3% for state sizes of 10 KB, 1 MB, and 10 MB, respectively, compared to state transfer without prefetching.

For the third set of results, we analyzed the overall application resumption latency for the UE with and without our proposed token reuse and data prefetching optimizations. The key stages involved in the MEC application resumption are listed in Table IV. The UE attached to the MEC in the U1 stage, became authenticated in the U2 stage, and application was resumed for the UE in the U3 stage. The U2 stage required the MEC in the foreign network to fetch the subscription data from the UE’s home network (M1). Similarly, the U3 stage required the MEC to fetch the state data from the UE’s home network (M2). M3 stage was not involved in the MEC application resumption time and was needed for the UE to move to another MEC later. Fig. 8 shows the time taken by each stage for the two scenarios; without and with our proposed token reuse and data prefetching optimizations.

In both the scenarios, the authentication server was located in the MEC and the state size was 1 MB. Without optimizations, the M1 stage took place during the U2 stage while the M2 and the M3 took place during the U3 stage. As Fig. 8 shows, the M1 and the M2 stages induced the additional latency of 321 ms and 297 ms, respectively. We started the M1 and the M2 stages earlier during the U1 stage to reduce the time taken by the U2 and U3 stages, as seen in the lower half of Fig. 8. It can also be seen that the M1 and M2 stages were completed before they were needed by the U2 and the U3 stages. The reuse of the authentication token of the app server further reduced the latency of the U2 stage. The rest of the time taken by the U2 and the U3 stages was mainly because of the communication between UE and application server which could not be further reduced. Therefore, we suggest that mobile network operators deploy the proposed token reuse and data prefetching optimizations as they reduce the latency of the U2 and the U3 stages by 56.3% and 28.3%, respectively.

When the UE detached from one MEC and attached to the MEC in another MNO, the service was interrupted until the application was for the UE resumed. The service interruption latency was divided into four stages: UE attach, UE authentication, MEC to MEC communication for state transfer, and MEC to UE communication. We calculated this service interruption latency for three different scenarios described in Table V. The first scenario considered the authentication server in cloud and transferred the state via the cloud without data prefetching and token reuse optimizations. The second scenario considered the authentication server in MEC and transferred the state via MEC proxy without data prefetching and token reuse optimizations. The third scenario considered the authentication server in MEC and transferred the state via MEC proxy with data prefetching and token reuse optimizations (i.e. our proposed FS3A).

The comparison of service interruption latency for these three scenarios is shown in Fig. 9, which shows that, with our proposed architecture and token reuse and data prefetching optimizations (scenario 3), service interruption latency was 2.96 seconds, that is 73.6% and 33.1% less compared to the scenarios 1 and 2 respectively as a result of the MEC proxy, token reuse, and data prefetching. It should be noted that the UE attach and the MEC to UE communication stages took almost the same amount of time in all three scenarios as they mostly depended upon propagation delay and could not be reduced. It can be seen that we considerably reduced the UE authentication time and MEC to MEC communication time by token reuse and data prefetching optimizations. If we ignore the time taken by the UE attach and the MEC to UE communication stages, the latency for scenario 3 can be further be reduced by 59.7% compared to the scenario 2, which is a considerable decrease in service interruption latency.