Proposal for a New Architecture Enabling Service Policy Control of MEC Applications Under the Control of 5GC

1. Overview of MEC and Service Policies

What is MEC?

MEC (Multi-access Edge Computing) is a set of technologies that leverage computing resources located close to UE (User Equipment) within the network to perform data processing. Traditionally, data processing was handled in the cloud or data centers, which led to communication latency and bandwidth constraints. MEC addresses these issues and offers benefits such as lower latency, more efficient bandwidth usage, and location-aware service delivery. As a result, MEC is expected to be utilized in areas such as gaming, XR (Cross Reality / Extended Reality), autonomous driving, smart cities, and IoT (Internet of Things).

Importance of Service Policies

Service policies play a vital role in delivering services using MEC. This concept defines communication quality (QoS), security, and resource allocation for each application. Specific control parameters include latency, bandwidth, security, and service area. By offering specialized services in specific locations (e.g., support applications in sports stadiums, real-time information notifications at airports and train stations), and applying optimal policies, users can enjoy a seamless service experience.

Thus, MEC is not just about distributed computing but also enabling location-aware application delivery, enhancing overall network usability. However, current networks face the challenges in applying consistent policies that span both MEC and 5GC (5G Core).

2. Challenges of MEC and Policy Management in the Current Mobile Network

5GC C-Plane and UE Policy Management in Mobile Systems

In mobile systems, the C-Plane of the 5GC (5G Core) is responsible for policy management. The C-Plane (control plane) manages UE sessions, authentication, and QoS control, enabling dynamic control. As shown in Figure 1, the 5GC consists of multiple network functions (NFs).

Fig. 1. 5G System Architecture

Particularly, the following key NFs are involved in policy control and management:

• ・SMF (Session Management Function): Establishment and management of sessions, selecting the UPF, and applying policies.

• ・PCF (Policy Control Function): Applying QoS and charging policies.

• ・UPF (User Plane Function): Policy application and transfer of user data.

These functions enable the 5GC to apply unified policy control to communications up to the N3 interface (the section between the RAN and the UPF in Fig. 1). The PCF determines QoS policies and applies them to the UPF via the SMF, controlling communication requirements such as latency, bandwidth, and priority. Even when the UE moves or the access network environment changes, the 5GC has mechanisms for providing consistent policy management for applications running on the UE.

Challenges in Policy Application for MEC Services

There are two major challenges in applying policies to MEC services.

A. Consistent Policy Control Across the Entire Network Including MEC

To maximize the effectiveness of MEC, it is crucial to apply consistent policy control across the entire network, from the UE to MEC. However, MEC is typically located outside the 5GC (at the N6 interface). As a result, policies controlled by the 5GC are not directly applicable to MEC applications as shown in Fig. 1. This necessitates two separate policy control mechanisms: one for the 5GC and one for MEC.
Achieving consistent policy control across the entire network requires closely linking these two mechanisms, resulting in a complex system structure and operations.

B. Implementing Policy Application Functionality to MEC Applications

To implement policy application functionality to MEC applications, there are two potential approaches: either implementing policy enforcement within the applications themselves or having the underlying platform (e.g., Kubernetes) enforce policies on the applications. The former approach, which may involve frameworks like the Camara API that indirectly utilize 5GC, allows applications with less stringent policy control to adapt to MEC services. However, this requires modifications to existing applications, leading to increased development costs. The latter approach can make existing application assets MEC-compliant without awareness of the 5GC, but it demands consistent policy management between the MEC platform and the 5GC, thus encountering the challenges described in Challenge A above.

3. Proposal for a Policy Control Mechanism for MEC Applications Using 5GC

As previously mentioned, MEC applications are typically outside the control of the 5GC, and thus require a different policy enforcement mechanism than UE applications. This has led to the need for individual QoS control and authentication for each MEC platform, complicating the overall network management.

Therefore, we propose an architecture where MEC applications are treated as if they run on virtual UEs (vUEs), utilizing the 5GC C-Plane. Figure 2 provides an overview of this architecture. In this architecture, both UE applications and MEC applications can apply service policies using the same mechanism (i.e., 5GC C-plane), enabling consistent policy management across the entire network.

Fig. 2. Overview of the proposed architecture

Mechanism for Managing MEC Applications with 5GC

The following steps show how to bring MEC applications under the control of 5GC.

1） Assigning an IMSI to a MEC Application

First, to manage MEC applications brought in by service providers under the 5GC, an IMSI (International Mobile Subscriber Identity) is issued for each MEC application. Originally meant for UEs, assigning IMSIs to MEC applications (≒vUE) allows them to be subjected to 5GC policies. This process is similar to individuals confirming and contracting for communication services (policies) with telecom operators and receiving a SIM card (≒IMSI).
The IMSI is registered in the UDR (Unified Data Repository), ensuring automatic application of QoS and security policies. This enables MEC applications to be managed under the same policy framework as traditional UE applications.

2） Deploying a Virtual gNB (vgNB) within the MEC Platform

A virtual gNB (vgNB) is set up within the MEC platform to facilitate interaction between MEC applications and the 5GC. The vgNB transfers communication from the MEC application (≒vUE) to the 5GC, registering it with the 5GC C-Plane just like a regular UE. The vgNB currently exists solely to maintain compatibility with existing 5GC.

3） Registering the MEC Application and Establishing a Session

When the MEC application is launched, it performs Registration with the 5GC to join the network. Subsequently, it establishes a PDU Session, becoming ready for communication. This allows the MEC application to be controlled according to the contracted policy.

4） Applying Policies via the 5GC

Once the MEC application is registered with the 5GC, QoS, bandwidth, and security policies are applied.
The PCF (Policy Control Function) determines these policies and applies them through the SMF (Session Management Function) via the 5GC C-Plane.
The communication of MEC applications is managed under the same system as UE applications, allowing consistent policy application across the entire network for communications that compose MEC services.

4. Benefits of Bringing MEC Applications Under the Control of 5GC

Traditionally, policy management was handled separately by the 5GC and MEC platforms, requiring tight coordination between the two.By bringing MEC applications under the control of the 5GC C-Plane, it eliminates the need to operate different policy control mechanisms for each MEC, reducing the operational burden on telecom operators.

There are also significant benefits for application developers and service providers. In traditional MEC application development, implementing specific settings or APIs to apply 5GC policies was necessary, requiring an understanding of the core mechanisms of mobile networks. However, with the proposed mechanism, policies configured at the time of the contract are automatically applied simply by specifying the IMSI as a label in a Kubernetes manifest file, as shown in Fig. 3.

Fig. 3. Example manifest for the MEC application (in the proposed Method)

By using this mechanism, policies from the 5GC can be applied to applications in the same way as deploying applications on Kubernetes. Even without specialized knowledge of communications or networking, appropriate QoS control and security management can be easily applied, significantly reducing the effort required for application design and operations.

Carrier transport networks (TN: Transport Network) often have pre-deployed logically isolated networks separated by units such as customers or service characteristics. By aligning these segments with the network slices managed by the 5GC, both UE applications and MEC applications can connect to the same network slice via the N6 interface as shown in Fig. 2. By assigning both the customer and MEC service to the same policy contract, consistent 5GC policies can be automatically applied to MEC services.

Verification through PoC

In this Proof-of-Concept (PoC) verification as shown in Fig. 4, we deployed free5GC as the 5GC, UERANSIM as the gNB and vgNB, and UERANSIM UE as the UE and vUE, all on virtual machines (VMs). The MEC platform utilized Kubernetes (k8s).

Fig. 4. PoC Verification Environment

UE1 and UE2 are subscribed to Policy A and Policy B, respectively. The two UEs register and establish connections with the 5GC C-plane on VM1 through the gNB on VM3. As a result, the two UEs are able to communicate with the DN via the UPF on VM4.

The MEC application subscribes to Policy B. When k8s receives a manifest, it initiates a vUE, which is implemented as a CNI (Container Network Interface) plugin. The vUE follows the aforementioned steps to register and establish a connection with the 5GC C-plane on VM1 via vgNB. This setup allows the MEC application's Pod (MEC App Pod) to communicate with the DN via vgNB and the UPF on VM6.

At this point, since UE2 and vUE (≒ MEC application) both subscribe to the same Policy B, they can communicate via DN, enabling UE2 to use MEC services. On the other hand, because UE1 does not subscribe to the same policy as the vUE, they cannot communicate, resulting in UE1 being unable to use MEC services. This setup demonstrates that by bringing MEC applications under the control of the 5GC, it is possible to effectively manage service policies critical for realization of MEC services.

5. Future prospects of MEC services

By applying policies to MEC applications under the control of the 5GC, just as is done with UE applications, the policy control mechanism is simplified, benefiting both service providers and carrier operators. We have implemented and verified this in a PoC environment, confirming that the basic requirements were satisfied. This topic was presented at the IEICE (Institute of Electronics, Information and Communication Engineers)Technical Committee on Network Systems^[1].

Moving forward, we will work on realizing specific policies that control application usage based on not only subscriber information (IMSI) but also user area information (TA: Tracking Area). This will enable flexible application provisioning and usage control based on specific locations. We also plan to verify the impact of policy control from the 5GC on applications and the efficiency of network operations.
Through these efforts, we aim to create a world where telecom operators can build MEC services more easily. To meet the diverse service demands of the future, we will continue to pursue the realization of an architecture that harmonizes MEC and mobile systems, with ongoing verification and improvement.

References

• [1]. “MEC Architecture Supporting Application Service Policy Management with 5GC”, Takumi Ishihara, Hiroki Watanabe, Katsuhiro Horiba, Keisuke Uehara, IEICE Tech. Rep., vol. 124, no. 310, NS2024-158, pp. 86-91, Dec. 2024. (in Japanese)

Writer

Hiroki Watanabe、Takumi Ishihara