R17 adds native MEC support by defining an edge app architecture
The 3GPP R15 specifications completed in 2018 provided the not only the foundations for 5G architecture, but also the basics for 5G MEC deployment as well. R16 provided features and functionality aimed at additional use cases, including edge computing, cellular IoT and Ultra-Reliable Low Latency Communications (URLLC), which are intimately intwined with MEC enablement. Release 17 provides even more integrated MEC functionality through the definition of an architecture to enable edge apps.
“In Release 17, we aim to provide native support of Edge Computing in 3GPP networks,” wrote Suresh Chitturi, 3GPP Working Group SA6 Chair.
The functionalities defined in Release 17 combined the efforts of several 3GPP working groups focusing on application layer architecture, core network enhancement, security, media processing and management aspects.
R17 defines an enabling layer for edge computing that bridges communication between Application Clients (ACs), or apps running on user equipment (UE) and Edge Application Servers (EAS) deployed on the MEC data network. This includes service provisioning and EAS discovery functionality.
According to Chitturi, the application architecture is based on five guiding architectural principles:
- Application Client portability: Changes in logic of AC to interact with EAS, compared to existing cloud environment, are avoided.
- Edge Application Server portability: Changes in logic of application servers when edge-resident, compared to an existing cloud environment, are avoided. An EAS should be able to run in hosting of multiple edge computing service providers (ECSPs), without any modification.
- Service differentiation: The CSP can provide service differentiation (e.g., by enabling/disabling the MEC features).
- Flexible deployment: There can be multiple ECSPs within a single Public Land Mobile Network (PLMN) operator network. The MEC can be a subarea of a PLMN.
- Interworking with 3GPP network: To provide MEC features, already developed or to be developed in 3GPP network (features like location service, Quality of Service (QoS), application function traffic influence), to the EAS, the application architecture supports interworking with 3GPP networks using existing capability exposure functions such as Network Exposure Function (NEF) and Policy Control Function (PCF).
It also defines an Edge Application Server Discovery Function (EASDF) to support MEC session breakouts. Within the functionality of the EASDF is Domain Name Service (DNS) resolution to the UE, thus resolving to application servers closer to the UE’s physical location.
The 3GPP’s SA6 working group says that its architectural principles provide benefits both for “edge-aware” and “edge-unaware” apps operating on MEC environments. With the support of the enabling layer exposed in R17, the 3GPP notes native support for several MEC-related capabilities:
- Rich discovery: On-demand service provisioning by the Edge Configuration Server (ECS) and the support of query filters on the Edge Enabler Server (EES) to allow rich discovery.
- Dynamic availability: EAS capabilities can vary for multiple reasons, including deployment changes and UE mobility. The UE can subscribe to such dynamic changes to fine tune the services offered to the AC.
- Network capability exposure: The EASs can utilize service Application Programing Interfaces (APIs) exposed by the EES, which in turn are built on the capabilities of northbound NEF APIs, enabling EASs to access 3GPP network capability exposure functions.
- Support for service continuity: With UE mobility, the serving MEC or cloud instance may change or become more suitable for serving the AC. To enable continuity of service in such scenarios, the architecture supports transfer of the UE’s application context between MEC for seamless service continuity.
For more insights and expert commentary on Multi-Access Edge Computing, download our editorial report, MEC: Key 5G architectural considerations when milliseconds matter.
