Understanding 5G, A Practical Guide to Deploying and Operating 5G Networks, Edge Computing (Part 5)

5G is an essential element enabling the “sixth technological revolution,” referred to in the?introductory Part as the “AI era.” This revolution is about connected things enabling new verticals and full automation using machine learning and artificial intelligence. 5G is designed and architected to enable this revolution and in particular, the uses cases that will require Ultra-Reliable Low Latency Communications. Following the 5G architecture design?as explained in Part 1, it can be concluded that many of the intelligent computations?needed from the network to react and enable these new real-time services will move to?the edge of the network, hence the term “edge computing.”

More specifically, edge computing refers to the practice of offering cloud computing capabilities at the edge of a communications network, near end-users, and coupled with the service provider’s network infrastructure. These computing resources can then be used to process user data close to where it is being generated, rather than relying on the centralized data-processing warehouses that form the traditional cloud environment. Since data is processed near its source, the transmission latency can be

significantly reduced, while also minimizing the volume of data that must be hauled across the transport network to the cloud. Local processing also offers an additional level of security, since sensitive data need never enter the public cloud. This reduces the likelihood of it being compromised or even corrupted, during transport.

To understand the significant advances enabled by edge computing, let us take a quick walk down the memory lane of computing history and discover how it all began.

In the late ’60s and early ’70s, “mainframe” computers were invented. You needed a?physical data center filled with these computers to be able to run your application. “Dumb”?terminals were used to enter application data and retrieve results.

Then in the ’80s and ’90s, the invention and adoption of microprocessors led to the rise of local, powerful servers and desktop computers. Those computers were used by many companies to run their business and IT applications. We also saw the emergence of the personal computer (PC) and subsequently portable laptops.

With the turn of the century, the term “cloud computing” was being used to refer to applications that ran remotely in a data center, accessible through the Internet. This setup offered small- and medium-sized companies the ability to scale without having to spend much CapEx on office IT computers and applications. Then, with the introduction of smartphones and the associated app frenzy, cloud computing became the norm to manage access to a large amount of computational and storage resources in the cloud.

And now, with the need for real-time applications requiring Ultra-Reliable Low Latency?Communications for decision-making (think connected cars), these cloud-based

computational and storage resources need to move closer to the edge of the network; we are witnessing the start of the multi-access edge computing (MEC) era. Applicable use cases for this era include pervasive video; media sharing; tactile Internet; automated traffic control and driving; collaborative robots; and remote object manipulation. Subsequently, 3GPP, the standards development organization (SDO) partnership project, developing the?5G System (5GS) specifications, has identified edge computing as a key technology enabler for achieving the required low latency.

This Part focuses on edge computing standardization activities, including those within the European Telecommunications Standards Institute (ETSI) and the linkage to 3GPP. It then takes a more specific look at testing in this developing ecosystem, considering the transition from lab to field for edge-related products and services.

?

1. Standardization Overview

Established in late 2014, ETSI Industry Specification Group (ISG) MEC is the only SDO group solely focused on developing technical standards for edge computing. The goal of the?ISG is to specify a set of standardized APIs that enable application and content providers to utilize computing capabilities located at the edge of the network (mobile or otherwise). A?high-level view of the architecture is provided in the framework depicted in Figure 1.

Figure 1. Multi-access edge computing framework

The overall MEC system provides the capability to run MEC applications within a service?provider’s network and is made up of the following components:

• MEC platform (MEP): A collection of essential functionalities required to run (locally hosted or remote) MEC applications on virtualization infrastructure, enabling them to provide and consume MEC services. It is deployed as a virtual network function (VNF) in a network functions virtualization (NFV) environment.
• MEC applications: Instantiated on the virtualization infrastructure based on configuration or requests validated by the MEC management. As with the MEP, these are deployed as a VNF in an NFV environment. The application packaging is inextricably linked to the run-time environment of the MEC system. It is run and packaged accordingly as a virtualized application, such as a virtual machine (VM), or as a containerized application, such as a Docker container or Kubernetes template. MEC applications form part of a new development model, which has three distinct locations:?client, near the server, and far server (Figure 2). The client location could be a traditional smartphone or other wireless-connected computer elements, for instance within a car, smart home, or industrial location. The near server refers to the edge component with a set of operations that the application performs at the edge cloud; for instance, for terminal device computational offload while still leveraging very low latency and predictable performance, or offloading bandwidth demands from the network backbone, or making use of local contextual information from the location or network information APIs. The remote components implement operations that are carried out in the remote data center/traditional cloud, where increased storage and database access are most practically supported.
• MEC service: Services offered by MEC applications, or the MEP directly and exposed via RESTful-based APIs.
• MEC platform manager (MEPM): Manages the MEP and MEC application rules, requirements, and lifecycle. Lifecycle management responsibilities are delegated to a VNFM for the deployment of MEC in an NFV environment.
• MEC system-level management Includes the service provider’s operations support system (OSS) and the MEC orchestrator (MEO). All requests for application instantiation or termination are made via the OSS, which decides on whether to grant those requests. If successful, those requests are forwarded to the MEO for further processing. The MEO maintains an up-to-date view of the overall MEC system. It is responsible for onboarding application packages and deciding on where they should be instantiated. Components of the MEO are delegated to an NFVO for the deployment of MEC in an NFV environment.
• Virtualization infrastructure: the totality of all hardware and software components that build up the environment in which VNFs are deployed, managed, and executed.
• Virtualization infrastructure manager (VIM): Manages the virtualized (compute, storage, and networking) resources of the virtualization infrastructure, including the necessary preparation to run a software image on the infrastructure.

It also provides virtualized resource performance and fault information to the MEPM.

As highlighted above, the MEC architectural framework has very much been developed with the NFV architecture in mind. Within MEC, there is a specific reference architecture variant for MEC in NFV, providing the function entity and reference point mapping between the two architectures.

Figure 2. New application development paradigm introduced by MEC.

2. MEC Application Enablement Framework

The MEP is at the core of the standardized MEC application enablement framework, as depicted in Figure 3. This provides the Mp1 reference point, through which MEC applications can be authenticated and authorized. Such applications may consume MEC services or may even provide services themselves (more detail in the next section). The service-producing applications must be registered with the MEP, which maintains the service registry, via the Mp1 reference point. The registry facilitates service discovery, advertisement, and service-related notifications, e.g., state change.

Figure 3, Multi-access edge computing service enablement

Additional capabilities offered by the MEP are the ability to receive traffic rules and DNS records from the MEPM. The traffic rules may also be received from MEC applications or services and are applied to the underlying data plane. This allows IP traffic routing, or tapping, to the MEC applications, or locally accessible networks (e.g., enterprise network, Internet access, etc.). Based on configuration or following an activation request from the MEC application, the DNS records are used to configure the DNS proxy/server, accordingly, providing the mapping between an IP address and its fully qualified domain name (FQDN).?Overall, the MEC application enablement framework has wide-ranging applicability, since it is generic in nature and extendable. The result is that MEC can support any application and any application can run in MEC. However, MEC offers additional benefits to those applications that have been designed to be MEC-aware. Such benefits can be realized through MEC’s ability to open up the service provider’s network to authorized external applications and provide the means to expose pertinent information to them. This is considered a key value-add feature of the MEC specification since it offers applications the ability to gain contextual information and real-time awareness of their local environment through standardized RESTful service APIs. The resulting service environment can be used to tremendously improve the user experience. For example, through the network information service APIs, it is possible to precisely monitor events and performance of the network (e.g., radio) connection to the end-user device.

Such contextual information may be leveraged by a suitably designed MEC application to drive the behavior of the client application in the user device, as well as application components in a central cloud. The adjustments in behavior can be performed at runtime according to the prevailing conditions, where the proximity to the end-users means the environment can be better predicted. In this manner, the network characteristics can be accounted for during the design of the end-to-end service. This permits edge applications to benefit from low latency and high throughput in a more predictable and controllable way. Knowing that this information is available means that it can be leveraged during service design to optimize the end-to-end service architecture during runtime. The overall network itself may also benefit from the MEC services provided by applications; for instance, a scheduler within the network could also make use of user behavior predictions based on edge analytics, to maximize the network efficiency.

The MEC-specified APIs follow a generic set of specified design principles and patterns. Consistency has been achieved across the ISG MEC APIs through compliance to these principles, which helps facilitate APIs that are inherently application-developer friendly and straightforward to implement, particularly since OpenAPI specification compliance descriptions have been made available. Furthermore, the overall framework is extendable, since additional third-party service APIs may be offered as long as they adhere to these API guidelines.

3. MEC Services

It was highlighted in the previous section that MEC applications, supported by the standardized application enablement framework, may consume or produce services via RESTful-based APIs conforming to the MEC guidelines. This is depicted in Figure 4, which highlights that such services may be offered by third parties:

• MEC Application A: consumes the third-party service offered by MEC Application C.?It also produces a MEC-specified radio network information (RNI) service, which may offer supplementary information compared to the same service offered by the MEP (where not all MEP implementations will offer RNI). The MEC-specific services, including the RNI service, are detailed later in this section;
• MEC Application B: consumes the MEP-provided Location Service (LS) and RNI service.?It also consumes the third-party provided RNIs from Application A;
• MEC Application C: produces a third-party API, which adheres to the MEC API guidelines;

MEC Application D: as with all MEC applications, makes use of the Mp1 application enablement API, but neither produces nor consumes MEC, or third-party services.

Figure 4. MEC service producing and consuming applications

3.1. Network Information Services

ETSI ISG MEC has specified the number of access network-focused information service APIs. The first among those was the RNI Service, specified in. This provides near real-time 3GPP radio access network (RAN) information relating to the user equipment (UE) connected to the network. The RNI service, as with the majority of MEC service APIs, offers information via both approaches specified in the API guidelines: first, via direct query (request/response mechanism); second, via a notification (subscribe/publish mechanism). The information available in each case is summarized in Figure 5, which collectively provides significant insight into the connections supported by the access network, including the prevailing channel conditions for UEs on the air interface and their mobility events. For maximum interoperability, the API may use JSON as the data format with the HTTP message exchanges. This approach is reasonable for simple queries. However, scenarios will likely exist in which the amount of information, and update frequency, is so high that RESTful methods no longer scale. In this case, information may be shared using an “alternate transport,” e.g., over-the-message broker of the MEC platform. This is also more efficient support for one-to-many communications. To discover and use such alternate transports, a MEC application queries the MEP for details on a message broker via the transport information query procedure as defined in. Alternatively, such transport information may be pre-provisioned via configuration.

Figure 5. MEC radio network information service

A wireless local area network (WLAN) information service is also specified in GS MEC 028 [not yet published], which emulates the 3GPP mobile access focused RNI API, but for WLAN deployments. This provides a rich set of information from WLAN access points (AP) and stations (STA) based on that specified by IEEE and the Wi-Fi Alliance (WFA). The API uses filtering and attribute selection to allow the selection of only the specific information of interest. For APs that information includes the AP ID, WLAN capabilities, Associated STAs, WAN metrics, BSS load, and neighbor information. For STAs that information includes STAS ID, associated apps, PHY rates, and fine time measurements (analogous to timing advance for 3GPP LTE radio access networks).

The last in the set is the fixed access information API GS MEC 029 [not yet published], which has a wider remit to cover fiber, cable, xDSL, and point-to-point fiber Ethernet access to MEC. The goal with this API has been to develop a generic API that provides access to network-related information for the multitude of fixed-access technologies.

?

3.2. Location Service

The LS specified allows applications to exploit user proximity information (e.g., to retrieve and monitor the list of users connected to a specific cell or access point, or even provide their geographical coordinates).

?

3.3. Bandwidth Management Service

The bandwidth management service specified in allows applications the ability to reserve networking resources via the MEP, thereby ensuring that quality of experience (QoE) requirements can be achieved.

?

3.4. UE Identity Service

The UE identity service specified in allows applications to trigger user-specific traffic rules on the MEP, for example steering traffic to a local network.

?

3.5. V2X Service

There are also industry segment-focused APIs such as the V2X API being specified in GS MEC 030 [not yet published], which aims to facilitate interoperability in a multi-vendor, multi-network, and multi-access environment. The API builds are based on the recommendations resulting from the study on the ability of MEC to support V2X based use cases.

?

4. MEC Deployment Options

ETSI ISG MEC was established when the 3GPP LTE 4G architecture was already mature and already deployed in many networks. Therefore, the standardized reference architecture was designed to be agnostic to the evolution of mobile networks. This permits MEC deployments in 4G networks to be re-used in the support of 5G services, providing a smooth migration path for mobile network operators and a means to provide low-latency 5G-like services on their existing 4G networks. Even so, there are two main categories of deployment in a 4G network: S1 based and SGi based.

?

4.1. S1 Based

In this deployment scenario, the MEP is hosted either at the eNB (base station), on the S1 interface of the 4G architecture (Figure 6), or at the edge of the 4G core network. The specific deployment location can be selected based on the target latency while offering the capability to steer traffic on a per session basis, or even down to the packet level.

Figure 6. S1 MEC deployment

If incorporated with the base station, plain IP packets can either be locally switched to/ from MEC applications or routed as GTP-encapsulated packets to/ from the serving gateway (S-GW). This deployment is well suited to CRAN-style deployments, where it is envisaged the MEC could share the same virtualization infrastructure used for the more centralized baseband unit (BBU), rather than the distributed remote radio heads (RRU) and be inserted before S1 encoding. A clear advantage of a CRAN-type approach is the centralization it affords. This allows traffic rules to be applied at the edge of the RAN across a wide area and for many UEs, rather than at an intermediate point along with the S1 interface that would require S1 de-encapsulation and re-encapsulation.

If deployed on the S1 link itself, for instance at an existing aggregation point or the edge of the core network (e.g. in a distributed data center, at a gateway), the MEC host’s data-plane has to process user traffic encapsulated in GTP-U packets and therefore the encryption keys have to be made available. This specific option is known as “bump in the wire,” with the wire referring to the S1 link.

For S1-based deployments, there are further regulatory considerations since operators are required to provide law enforcement agency (LEA) support. This includes lawful interception (LI) and retained data (RD) capabilities for traffic carried on their networks,?which have typically been supported by core network elements, with all data passing through these elements. However, this approach is not appropriate for MEC where a portion of traffic will most likely not traverse the core due to local breakout of connections and local traffic generation. If Control User Plane Separation (CUPS) architecture is assumed for the underlying network, the LI support can be provided based on the available 3GPP?standard. However, if the CUPS architecture is not available, a group specification has been produced detailing the implementation of LI and RD collection functions at the edge of the network.

A significant factor concerning an S1-based approach is that the mobile identity (IMSI) is not inherently available outside of the EPC. The IMSI is generally only exposed within the LTE?EPC and communicated infrequently by the UE. The implication is that a secondary means is required to provide the information necessary to link the traffic flows supported within the RAN with specific UE Identities. The RAN is only aware of temporary identifiers such as the system architecture evolution serving temporary mobile subscriber identity (S-TMSI),?associated Radio and S1-bearer IDs, and S1-application protocol (AP) UE IDs. Therefore, the?MEC platform would need to be provided with the information to link a specific tag with the appropriate temporary identifiers. A solution would be to deploy probe-based agents in the?EPC. Specifically, the role of the agent would be to extract IMSI/IMEI identifiers with their associated temporary identities for each connection session by probing key interfaces within the EPC. The agent would then provide this IMSI-based customer experience management?(CEM) data feed with the necessary pairing information to the MEC platform. Using this information, the MEC platform could then fulfill the UE-specific traffic rules as required.

?

4.2. SGi Based

To achieve proximity to the end-user, this deployment is targeted to the situation in which the edge site logically includes all or part of the 3GPP evolved packet core (EPC) components, and the MEC data plane is placed on the SGi interface. This distributed EPC approach can be used to address enterprise-type use cases. For instance, for machine-to-machine-type networks, or 3GPP R13 mission-critical-push-to-talk (MCPTT),?where the home subscriber server (HSS) could be collocated with the other network elements at the edge site. A working backhaul to a more centralized location is not required to maintain local connectivity.

With this scenario, once the UE subscribes to the EPC at the edge site, the P-GW assigns the IP address and local DNS information to resolve the MEC application’s IP address, after having terminated the original PDN connection. In this manner, the appropriate UP traffic can be steered towards the MEC system. An advantage in this scenario is that fewer changes are required to the operator’s network, since standard 3GPP entities and interfaces are leveraged for operations such as session management, charging, etc. However, it may not be suited to network-wide deployment.

A variant of this deployment is to move only the S-GW and P-GW to the edge site (Figure 7) while maintaining the control plane functionality at the core. Local S-GW selection is then performed by the MME at the core. Traffic offloading is access point name (APN)- based and therefore traffic for certain APNs may not be offloaded, e.g., roamers. Note that the S-GW is the mobility anchor, so this deployment may be problematic for moving users.

Figure 7. S1 MEC deployment

5. CUPS

Standardized by 3GPP in R14 and further developed in R15, control and user plane separation (CUPS) specifies splitting the S-GW, P-GW, and TDF between their control and user plane components. This approach is considered a key enabler for edge computing by allowing a distributed user plane (UP) at the edge with a centralized control plane (CP). Here, a CP function can interface to multiple UP functions and a UP function can be shared by multiple CP functions. This allows for independent scaling of both the CP and UP functions, allowing edge-based UP deployments to be placed as required, and as demand dictates, with minimal impact to the core.

The CP functions continue to support mobility, charging, policy, and LI/ RD. Using rules, it also controls the local UP-based packet processing, namely: packet detection rules for packets inspection; forwarding action rules for packets handling (e.g. forward, duplicate, buffer, drop); QoS enforcement rules for QoS policing enforcement; and usage reporting rules for traffic usage measurements.

6. Edge Computing in 5GS

Next-generation networks based on the 3GPP 5G System (5GS) specifications, detailed throughout this tutorial, are considered a key target environment for MEC deployments. The service-based architecture (SBA), introduced as part of the 5G specifications, leverages interactions between different network functions to align system operations with the network virtualization and Software-Defined Networking (SDN) paradigms. This aligns with the approach taken in defining the ETSI MEC specifications.

While defining the 5G specifications, enablers for edge computing were considered from the outset. This has ensured mechanisms in place to allow MEC and 5G systems to collaboratively interact with one another on operations such as traffic routing and policy control.

The ETSI MEC-defined services introduced earlier in this Part, together with the edge computing-focused technical enablers of the 5GS, facilitate system integration between the two systems and in doing so create a powerful environment for edge computing:

Routing and Traffic Steering: Mechanisms are provided to select PDU Session traffic to be routed to applications, e.g., MEC applications in a local area data network (LADN), via an N6 interface. Note that a PDU session may have multiple N6 interfaces, where a user plane function (UPF) that terminates such an N6 interface is said to support PDU session anchor functionality. Two UPF-based mechanisms are provided to steer traffic:

• The first is to use uplink classifier functionality, which relies on a set of traffic filters (e.g. based on IPv4 address) to identify the appropriate traffic to be steered to each PDU session anchor in the UL direction, and to be merged from multiple PDU session anchors in the DL direction.
• The alternative is to use branching point functionality, which routes sessions to a single DN but via different PDU session anchors. This is applicable for PDU sessions associated with multiple IPv6 prefixes, which are referred to as multi-homed PDU sessions. A motivation for such an approach is to support make-before-break service continuity when switching between UPFs.

Application Function: External to the 3GPP network, an application function is offered the ability to influence UPF (re)selection and traffic routing directly via the policy control function (PCF) or indirectly via the network exposure function (NEF), depending on an operator’s policies.

3Session and Service Continuity (SSC): Three modes are provided for different UE and application mobility scenarios.

Local Area Data Network (LADN): A data network, in which applications (e.g., MEC applications) may be deployed, may be provided to serve a specific “local” service area.

QoS and Charging: Rules for QoS control and charging for traffic routed to the LADN are provided via the PCF.

?

7 MEC Deployment in 3GPP 5GS

As highlighted in, the 3GPP SBA, described in Part 4, and MEC API framework shares a complementary approach and has adopted similar principles, with the SBA focusing on network functions and the services they offer and consume, while the MEC API framework focuses on MEC applications and services. Both frameworks include the functionality needed for efficient use of the services including registration, service discovery, availability notifications, de-registration and authentication, and authorization. Specifically, capabilities include the ability to authenticate the consumer, e.g. a network function, or external application function, and to authorize its service requests. Both frameworks also support flexible procedures to efficiently expose and consume services. A request-response model can be used for simple service or information requests, while a subscribe-notify model is provided for any long-lived processes. The remainder of this section now considers several of the key network functions offered by the SBA and MEC’s relationship to them and potential interactions with them. This leads to Figure 8, which shows how the MEC system can be deployed in an integrated manner in a 5G network.

First, there is the network resource function (NRF) that supports registration of network functions and the services they produce, while in MEC services are registered in the service registry of the MEC platform, a key component of the application enablement functionality. Network functions can directly interact with service-producing network functions if authorized, with the NRF allowing the discovery of available services. Service accessibility may only be offered via the NEF, which is particularly relevant for untrusted entities that are external to the domain. In this manner, the NEF acts as a centralized point for service exposure and plays a key role in authorizing all access requests originating from outside the system.

Next is the PCF, which handles the policies and rules in the 5GS. From a MEC perspective,?acting as an application function (AF), it is the services of the PCF that are requested to influence the traffic steering rules. As with other network functions, depending on whether the AF is considered trusted or not, the PCF can be accessed either directly or via the NEF.

The role UPF plays in routing and traffic steering has already been highlighted, wherefrom the MEC system perspective it is considered as a distributed and configurable data plane. The difference is that the PCF is involved, rather than using the MEC Mp2?reference point to control that data plane for traffic rule configuration. It should be noted that in some specific deployments a local UPF may be part of the MEC system, as depicted in Figure 8.

Another key entity is the session management function (SMF), providing support for session management (including maintenance of the tunnel between the UPF and access network node), UE IP address allocation and management, dynamic host configuration protocol (DHCP) functions, charging (data collection and support for the charging interfaces), roaming, and lawful interception (event collection and interfacing to the LI?system). It also performs UPF selection/ re-selection and configures the traffic rules for the UPF. This latter aspect is particularly important to MEC about steering traffic to the local area data network (LADN). In addition, MEC acting as an AF can manage PDU?sessions, control policy settings, and traffic rules, as well as subscribe to notifications on session management events through the service operations exposed by the SMF.

Figure 8. MEC deployment integrated into the 5G network

As part of the MEC system, reference Figure 8, the MEC orchestrator (MEO) is a MEC?system-level functional entity that can interact with the NEF, or directly with the target?5G NFs if authorized. In this context, it would logically act as an AF. On the MEC host-level, it is the MEC platform that can interact with these 5G NFs, again acting in the role of an?AF. It is anticipated that the MEC host-level functional entities would be deployed in the?5G system’s data network. Although the NEF, as a core network function, is a system-level entity deployed centrally together with similar NFs, it is feasible that a NEF instance could be deployed in the edge to allow low-latency, high-throughput service access from a MEC host.

8. 5GS Common API Framework

Like ETSI ISG MEC, the 5GS SBA has adopted a RESTful design approach for its Application?Programming Interfaces (API). These are being specified for functionality exposure to third parties and well other types of system internal communication.

Functionality exposure to external entities is provided by northbound APIs. There are several northbound API-related specifications, e.g. the APIs for the evolved packet core?(EPCs) service capability exposure function (SCEF) and also the APIs for the 5GC NEF. Therefore, to avoid potential duplication and an inconsistent approach between different API specifications, 3GPP has specified a common API framework (CAPIF) that includes common aspects considered applicable to any northbound service API.

It is possible to map architectural components of the MEC architecture onto CAPIF, which is presented in Figure 9. Specifically, MEC services produced by MEC applications, or the?MEC Platform, can be mapped to the API provider domain in CAPIF. A MEC application?(or MEC Platform consuming a service) is an API invoker in CAPIF. Finally, capabilities and functions of the MEC platform, such as service registration, can be mapped to the 5G CAPIF?core function.

Figure 9. Mapping architectural components of MEC onto the 5G common API framework

In R15 five CAPIF reference points map to MEC’s single Mp1 reference point.?In R16, a sixth is added for inter-Converged Control Plane Function (CCF) communication,?analogous to MEC’s Mp3 reference point. Note the “e” version of each CAPIF reference point refers to the variant covering interactions from outside a CAPIF’s PLMN trust domain.?Briefly:

• CAPIF-1: used for authentication, obtaining authorization, and discovery.
• CAPIF-2: for invoking the service APIs, e.g. SCEF (to AS/SCS), or NEF northbound interface (T8 and RESTful API respectively).
• CAPIF-3: provides service API access policy; provides authentication and authorization info of API invoker for validation, and service API invocation logging and charging.
• CAPIF-4: covers publishing (facilitating discovery, via CAPIF-1) and storing the service?APIs information.
• CAPIF-5: provides service API invocation log for auditing; provides monitoring information on service APIs status, and is used for exchanging API provider policy configurations.

What is not currently covered by CAPIF is the ability MEC offers to support traffic rule control and DNS handling, as described earlier in this Part.

Traffic rule control is instead covered by the NEF, which supports AF's influence on traffic routing. This is a capability that MEC acting as an AF would utilize to influence the data plane, highlighting how MEC’s Mp2 reference point between the MEP and data plane could in practice be realized.

?

9. MEC Impact on Operational Systems

How to operate and manage MEC must be given significant focus considering the architectural impacts of edge computing, which is anticipated to be typically deployed in a virtualized environment. Early functional and capabilities testing must span full lab-to-field deployment to ensure the desired behavior is achieved once the system is rolled out into a commercial network. Such test processes will cover conformance of the product components to the specifications; interoperability between those components, which may be provided by different vendors; a performance assessment of products under real-life load conditions, which will likely assess the reliability and stability of the system; and ongoing network assurance testing, providing insight into the operation of the product once deployed and the quality of experience of users of the system. Closely coupled are security and resilience testing, where the former is focused on identifying vulnerabilities of the system and the latter the system’s ability to recover from failure.

The need for testing has been recognized within ETSI ISG MEC, with specific work items already underway to develop test framework guidelines [not yet published: ETSI GR?MEC 025: “Testing Framework”], and also to define API conformance test procedures?[not yet published: ETSI GS MEC 032: API Conformance]. This work focuses on testing methodologies to test devices implementing the standardized services and leverages

similar activities in NFV{19} and existing ETSI best practices. In this context, the?two main and complementary testing methodologies are considered to be conformance?testing and interoperability testing, which can be summarized as follows:

• Conformance Testing can be used to demonstrate that a product correctly implements a standard and its requirements. The product is formally referred to as an implementation under test (IUT), which forms part of the system under test (SUT). In this instance, the standards are those defined by ETSI ISG MEC and include testing a?product’s use of the MEC APIs. Concerning the APIs, the content and format of each message must be validated, as well as the sequence of message exchanges. Such tests are performed at the open standardized interfaces of the IUT and are generally executed by a dedicated test system that has full control of the SUT as well as the ability to examine all messages originating from, or sent to, the IUT. With its high degree of control over the SUT, the test system can detect both valid and invalid behavior according to a given sequence of messages with specific contents.
• Interoperability Testing can be used to demonstrate that individual functional entities within the MEC architecture will work together as expected. The functional entities are formerly known as functions under test (FUT), with each FUT being offered by a different provider. The collection of FUTs make up the SUT. The tests are aimed at proving that the end-to-end functionality between (at least) two FUTs aligns to the standards on which those functions are based. Tests are performed and observed at functional interfaces, including man-machine interfaces (MMIs), protocol service interfaces, and APIs. The high-level functions were portrayed in Figure 5.1 and include the MEC platform, the platform manager, the orchestrator, and the MEC applications that these entities enable. A limitation of testing at only functional interfaces is that the tests can only describe functional behavior, where sometimes it might not be possible to trigger or test protocol error behavior on the various interfaces Between the FUTs.
• Although conformance and interoperability testing may be performed in isolation due to the distinct differences between them, the two techniques can be performed together to give combined results. This hybrid approach is described as interoperability testing with conformance checks.
• ETSI ISG MEC has taken on the responsibility to define a testing framework and test conformance specifications. This includes the development of test purposes as well as the test cases, which constitute an abstract test suite. These provide the foundation for certification, for which there are dedicated bodies such as the Global Certification Forum?(GCF). The GCF is the logical example since it is recognized as being the principal body in charge of certifying any product incorporating cellular mobile connectivity. Achieving?GCF certification demonstrates that a device conforms to international standards for mobile technologies and helps ensure global interoperability between mobile devices and networks. It was founded in 1999 as a partnership among mobile network operators,?mobile device manufacturers, and the testing industry. It offers an independent certification program for mobile and IoT devices and helps ensure global interoperability and connectivity between mobile devices and networks based on international standards, such as those defined by ETSI and 3GPP.

Those programs continue to evolve, with new additions relevant to MEC use cases including 5G, automotive C-V2X, and mission-critical services. Having a MEC product certification program would further encourage engagement of the ecosystem stakeholders in MEC technology and provide further evidence of the business viability of such products. GCF could be a potential candidate, expanding its remit beyond cellular mobile connectivity.

It has been highlighted that there is an expectation that MEC will be deployed in a?virtualized environment, which offers new assurance challenges. Specifically, not only is the traditional performance monitoring and troubleshooting of the telecom functionality required, but also the performance of the underlying IT infrastructure, which affects the desired telecom functionality and must be included in the monitoring and troubleshooting coverage. To fulfill this requirement, data access agents must be able to operate in virtual environments to collect performance metrics by analyzing live traffic at virtual network interfaces, as well as collecting metrics on the performance of the virtual IT infrastructure.?The MEC platform can aid such agents with its ability to route IP packets.

For instance, in tap mode, data-plane traffic is duplicated and forwarded to a MEC?application that could implement a virtual network probe agent. Such an assurance agent can facilitate the self-configuration of the virtualized environment by providing appropriate performance data/analytics (relating to both the telecom functions and IT infrastructure)?to the policy control function responsible for reconfiguration decisions of the virtualized environment. With the agent running at the network edge, policy decisions can be made in near real-time. This ensures optimal policy control based on the current state, enabling network reconfiguration decisions that are good business decisions as explored in the?“Maximizing Profitability with NFV” TM Forum NFV Catalyst project. The assurance solution must also be self-configure in real-time to match the reconfiguration of the network to ensure that there is no gap in network monitoring and troubleshooting. To receive such reconfiguration information, the assurance solution must have an interface with

the orchestrator of the virtualized environment. In this manner, the assurance solution effectively becomes a part of the operational equipment chain, especially concerning the assurance solution supplying the intelligence critical to ensuring the successful operation of the virtualized environment.

The ETSI ISG MEC-specified network information service APIs, such as RNI service, was introduced earlier in this Part. These service APIs offer information that overlaps with the 3GPP defined trace data, for example, RRC measurement report and handover event information. 3GPP refers to a trace collection entity (TCE) as the termination point for the trace feed, where the TCE may or may not be placed within the operator’s secure zone. However, typically the TCE is located at an operator’s centrally-located network operations center (NOC). This is rather different from the MEC network information service?APIs that offer a trace-like feed to authorized MEC applications at the edge of the network.?These APIs also offer both query and subscription models, where the service consumer?(MEC application) can cherry-pick the specific information of interest in a one-off request?(e.g. current layer 2 performance information) or subscribe to receive event-triggered updates (e.g. handover or measurement events). This allows new use cases to be addressed,?or existing use cases to be addressed in a new and innovative manner, such as distributed,?localized, near real-time radio network assurance. Since the network information services provide connection-level granularity, it is possible to offer subscriber-centric assurance solutions, with application-aware intelligence, that create a true understanding of the customer quality of experience (QoE). This in turn enables monetization of the network and automated edge-focused network optimization.

This section has highlighted that the edge computing environment has its unique challenges and opportunities regarding testing. Such testing has a far wider scope than just the standardized services, particularly about assurance once a MEC system is deployed.

?10. It is Just the Beginning

This Part has provided an overview of edge computing with an in-depth look at the ongoing activities within ETSI ISG MEC at the writing of this tutorial. An architectural overview was provided, highlighting the key components and their purpose. Here the MEC application is perhaps of most interest, with the other entities primarily being made available to create an enablement framework for such applications. It should be clear that the MEC application is one component of the new deployment paradigm, which also has a client component and likely a backend central cloud component. The MEC application has the advantage of being near the end-user, i.e. client, and can exploit the contextual information available at the network edge to offer new and innovative services. Different deployment options for the new edge-based architecture are also considered, including deployment in the 5GS. But this is just the beginning of the MEC?era and the path in front of the full potential of edge computing is becoming clearer. Yet,?as with any new technology innovation, there are new challenges ahead. Security is still a big concern. Distributed systems are always hard to provide security for compared to a centralized one, and, as we mentioned in the introduction, the topic of security in the new era of cloud computing is not included in this tutorial since it deserves an entire tutorial by itself.

?

?

?

?

?