The Growth Story of Telecom Infrastructure and Applications
If 2G added text messaging and 3G brought in mobile internet, 4G introduced us to multimedia, especially video. 4G infrastructure provided multimedia support across streaming platforms, collaboration platforms and unified communications platforms. Essentially, the primary catalyst behind the success of commercial 4G was multimedia technologies.
With 5G, we are expecting higher bandwidth and lower latency, and the catalyst we are looking to is Telco edge. The industry can build ultra-low latency applications, mission-critical applications and security applications using Telco edge. These applications will have to be “edge-aware” applications that are built to leverage Telco edge.
Multi-Access Edge Computing (MEC), network slicing, CBRS and Control and User Plan separation (CUPS) architecture are playing critical roles in achieving this success.
In view of the importance of CUPS and MEC, most operators, vendors and communities (SDOs, OSDs) have started creating specifications, reference architectures and sample deployment of CUPS, MEC and applications. Many of them have successfully rolled out trial versions across continents and operators. SDOs are also joining hands to solve common problems. GS Lab has participated in this evolution with multiple bodies and OSDs to work toward successful CUPS and MEC.
Let’s talk about the key challenges for the deployment of CUPS and MEC, some of which are already being discussed on various forums and SDOs.
CUPS – Background
The control and user plane separation (CUPS) concept in telecom core started formulating from 3GPP release 14. CUPS plays a key role in achieving high performance and close-to-user data planes, which is critical for the success of MEC and edge aware applications. The sole purpose for separating both control and user channels was to create a scalable, independent and performing architecture, which can leverage multiple factors like hardware-independent and data traffic-based high speed user planes, scaling user planes separately than control planes, distributed deployment of user planes across operators, sites, and edge nodes.
There are three variants of CUPS deployment —
1. 4G – SGW and PGW split into control and user planes
2. 4G – Combined SGW and PGW architecture, for control plane and user plane
3. 5G – SMF-UPF, which is analogous to option-2 of 4G with combined SGW and PGW architecture
While 3GPP specification has options 1 and 3 detailed out in the specifications (refer 3GPP – 23.214 – Diagram 4.2.1-1 and 3GPP – 23.501), for option 2 (3GPP 23.214 – Diagram 4.2.2-1) specifications are not very clear on the various communication parameters, protocol and procedures. In addition, evolving 3GPP standards pose a significant testing challenge.
Here are some deployment modes possible with CUPS:
For details refer – ETSI white paper no 28 – MEC in 5G Networks
1. MEC and local UPF collocated at base station
2. MEC collocated with transmission nodes
3. MEC and UPF collocated at network aggregation point
4. MEC collocated with network functions at data center or center office
Here are the deployment models for MEC [1]
For details refer []
1. Non dedicated DN
2. Edge-dedicated DN
3. Use of LADN with each Edge-dedicated DN configured with unique DNNs.
Challenges in a CUPS Deployment
Given clarity of specifications for the protocol and procedure level details, here are some critical points to address while conducting ground deployments of CUPS gateways for different scenarios mentioned above.
1. User plane segregation
When UE connects to the network, a decision needs to be made on which user plane in the CUPS deployment this UE traffic should be diverted to. This decision can be based on multiple factors as mentioned in 23.003, e.g., UE operator, location, APN, home/roaming etc. UE’s traffic can be targeted towards a specialized data plane, based on APN for which UE connection is requested. In this case, UE needs to define a specialized APN to connect with specialized data services. If UE is going to use edge applications, MEC needs to be mapped to APN, and in turn the selected user plane. With 5G, the same applies to the DNN to be used for connection establishment.
2. DNS installation/update, DNAI, DNN, Service area
The user plane selection based on the parameters mentioned above can be triggered by DNS or other similar systems. In a distributed user plane deployment, DNS entries will need to be updated continuously for user plane. Mappings of DNN, APN, service areas and other selection parameters should be auto-updated. 23.003 has specified which entries in DNS can be stored, but keeping them up to date to handle new, deleted, updated remote entities needs defined or customized mechanisms. User planes also need to support PFCP mechanisms for association to work across vendors. PFCP has few functional changes from release 15 to 16, some of which are not backward compatible e.g., IP address assignment freedom.
3. Interfaces for application deep edge to edge
There are versions of applications which will be installed at a deep edge site or satellite site, and another high feature version of such applications running at a telco center office cloud. Both applications will need to be synchronized for supporting distributed deployments, and utilizing central services. For such applications, communication from the deep edge site to the telco center cloud will need segregated and secured connectivity.
4. Routing for app and other traffic
For user planes deployed at the edge sites, the following are different types of traffic to be handled.
- Application traffic, which will be handled locally
- Application/internet traffic, which will be diverted to SGi
- Traffic to be forwarded to a telco central site
While routing and traffic isolation needs to be managed at deep edge, traffic handling needs to be managed based on factors such as destination MEC, service and application.
5. Billing and LI at CUPS
Passing charging information securely and reliably from edge sites to central systems is a pressing concern that needs to be addressed. PFCP can pass charging information to a control plane, but reliability and security factors in remote site deployments are still open. Charging for the data traffic and charging for edge applications are two different factors to serve by edge node.
6. Application dependencies
Most edge aware applications provide specialized services and many need access to specific hardware resources, federated networks and application traffic segregations, among others. Application resource demands needs to be supplied dynamically at limited capacity edge nodes.
7. Application Orchestration
Edge aware applications will be from various domains like enterprise, critical communications, entertainment, and consumers, which will be developed by common application developers. Procedures to upload, install, configure, monitor applications is the need of the hour, and so the orchestrator needs to work across multiple CUPS sites to manage such applications and provide their required services.
8. Cloudlet architecture
Each cloudlet will run limited hardware resources for CPU, memory and networking, and each application will have its own demands for certain types of resources. Cloudlets need to be designed either for specialized applications with specific hardware, or generalized applications with a commodity hardware support. Application decisions will be runtime, whereas cloudlet decisions will be at the time of deployment.
9. Distributed cloud – Multiple edge sites working together
The operator platform deployed at multiple edge sites needs to be monitored and orchestrated centrally, just like the application orchestration. All edge sites need to run as a distributed cloud platform. Each edge site needs to provide a cloudlet management capability.
Challenges in MEC Deployment
An MEC platform (also called the operator platform-OP, Telco edge) will be deployed either at a central office or a satellite site, and will be hosting various edge aware applications. The above-mentioned challenges pertaining to the CUPS deployment also apply to MEC, although the following are some common, on-ground, platform-specific challenges to address for MEC deployment.
1. Standardization
The MEC/Operator Platform is an upcoming area flooded with questions on interfaces, APIs, components, workflows, orchestration, security et al. There are open source and proprietary reference implementations available. At the same time, SDOs are working on standardizing the platform. At recent events, SDOs like GSMA, ETSI, 3GPP have come together to brainstorm, share efforts and references to arrive at a common ground. Watch this video for detailed insights on standardization – https://www.youtube.com/watch?v=U027jFv0SS0
2. Application development – Reference model for app developers
Edge aware application developers will be working more independently than MEC platform developers, and hence their expectations will be to utilize common services for application development, orchestration, APIs, workflow and more. Since this is a new platform, a reference model, and a framework for application development will be expected by application vendors.
3. MEC services for app
Application developers will expect services analogous to services being offered when an application is developed for public cloud such as AWS, Azure, and GCP. Application developers expect these services’ compatibility across operator platforms to ensure same edge application can work across operators.
4. DC services, with heavy application offloading
Deep edge applications may have to restrict heavy analytical operations and processing due to restrictions at deep edge sites. As a result, they may need to offload some of these services to either edge application hosted at the central operator platform, or on the public cloud. Provisions for utilizing such services and interfaces to these services from a deep edge site is required.
5. Roaming, handover scenarios
Application continuity in a handover scenario, when the application is served from a satellite edge site, needs to be managed with equal responsiveness and application session continuity across handovers. A seamless handover within edges is expected.
In case of roaming, applications can be hosted on home network operator platform, and services might need access from a visited network within given performance metrics. Availability zone checks, federated interfaces, its detailing, and assurance are all key requirements in this case.
6. Application detection and handling
Detecting an application and its service locations, connecting the right application to right edge site (EDN), and its authentication need to be managed by the operator platforms. 29.558 has started drafting workflows around these (EEC-ECS provisioning and registration).
7. Deep edge vs. edge applications
Two types of applications will evolve — applications which are very sensitive and need to be hosted at satellite (deep) edge site, and applications/counter-applications which are comparatively less sensitive and can be hosted from central operator platform. Deep edge application needs to conduct critical operations and a central edge application may be able to complete heavy operations due to the resource availability at a central site.
8. Resource reservation, management and pool
Application scaling will happen once deployment begins. Scaling requirements will be needed for each deep edge site operator platform and central site operator platform. Hardware resources pool planning, especially for deep edge site, will be key. However, certain satellite site may get more load dynamically due to the handover scenarios.
9. Security
Authentication and encryption will be required in two parts for applications. The first is for operator platforms by service providers, where UE will connect to the operator hosted platform. This security will be managed at the UE registration level. The second is for application context level security, with credential and transmission of data between client application hosted on UE and edge aware application hosted on the operator platform.
Other extended security requirements will be around segregation of application traffic, local processing, and shared cloud resources.
Resolving present-day challenges
Various forums, SDOs, operators, cloud providers and application developers are collaborating to solve the problems stated above. GSMA, ETSI, 3GPP, and forums like 5GAA, ONF, TIP, Magma are working on building open source, reference architectures and mainly on ground deployments to address the issues listed. And software leaders like GS Lab are participating in various initiatives on different forums to build open source applications and contribute to the engineering experience.
Recently, operators have been running trials, aided by vendors and applications providers for launching edge cloud, sample applications, and making it available across geographies. However, widespread production, user acceptance, and the application development industry still have a long way to go.
The future is calling… and 5G is waiting
Private LTE deployments for industrial solutions and limited areas of experience (stadium) scenarios, with the respective private cloud hosting enterprise applications, IIOT platforms, AIML, and XR services, are closer to realization than the deployment at an operator level with applications for large user bases. The user requirements with such use cases are clear. Hence there is more scope of addressing challenges sooner.
Later, this experience can help address challenges in a large-scale deployment for operators that cater to large-scale and varying requirements. Hence on-ground experiments, deployments and making it work in focused areas such as (P-LTE with IIOT, CBRS) will be critical for the success of edge application and operator platform in 5G.
The blog was originally posted on GS Lab's Website.
References
3gpp – 23.558 –https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3723
Etsi – https://www.etsi.org/technologies/multi-access-edge-computing
Gsma – https://www.gsma.com/futurenetworks/resources/operator-platform-concept-whitepaper/
ONF Connect, Gslab – https://www.youtube.com/watch?v=U027jFv0SS0&feature=youtu.be
Onf – aether – https://opennetworking.org/aether/
Facebook Magma – https://connectivity.fb.com/magma/
Author:
Vikram Barate, Engineering Director at GS Lab
