---

5.3.4 Phase 4: usage of the MEC platform and services

版权声明: 转载请注明出处 http://www.codingsoho.com/

Once the MEC application is up and running and becomes operational, it can consume MEC services. These services may be produced by the MEC platform or be produced by another MEC application. MEC services (e.g. RNI, Location, Bandwidth and UE Identity) are available for the MEC platform and authorized MEC applications.

RESTful design

MEC specific APIs are built upon RESTful APIs. The concept of RESTful programming is widely accepted in the industry and many developers are already familiar with the principles of these APIs. A RESTful API is an application program interface (API) that uses the HTTP protocol as a tunnel or transfer mechanism for interaction between remote entities. RESTful refers to a stateless design through REpresentational State Transfer (REST), an architectural style popular for development of web services ([7]).

ETSI’s design principles for developing RESTful MEC APIs are outlined in ETSI GS MEC 009 [11], along with http methods, templates, conventions and patterns to create RESTful APIs for MEC. MEC APIs are not only documented in ETSI specifications, they are also available in YAML and JSON format in a Git repository at https://forge.etsi.org/, presented via OpenAPI compliant descriptions.

Radio Network Information API

MEC applications run at the edge of the network where the environment is characterized by low latency, proximity, high bandwidth and exposure to location and up-to-date radio network information. While low-level information on current radio conditions is available in the Radio Access Network (RAN), the MEC server is in relative proximity and connected to the base station. The Radio Network Information Service (RNIS) is a service that provides radio network related information to authorized MEC applications and the MEC platform. The provided information originates from the RAN, based on contents defined in 3GPP specifications. The granularity of Radio Network Information desired by the application can be configured per cell, per UE, per QCI/5QI class, or may be requested over a period of time only. Some of the typical information that can be exposed is listed below:

• Up-to-date information about radio network conditions.
• Layer 2 measurement and statistics information based on KPIs of the user plane, according to 3GPP specifications.
• Information about UEs connected to the radio nodes associated with the MEC host, their UE context, related radio bearers, Quality of Service (QoS) information, throughput, neighbour cells, etc.
• Changes on the information above, based on API subscription, for example to provide notifications on cell change, radio bearer release or reconfigurations, updates to carrier aggregation configuration, UE measurement reports, related to UEs connected to the radio nodes associated with the MEC host.

The Radio Network Information (RNI) may be used by MEC applications and/or the MEC platform to optimize the existing services and to provide new services that are based on up-to-date information on radio conditions. For example, RNI can be used to include bitrate recommendations for video or voice calls based on actual real-time throughput available for a specific connection, or the MEC platform can utilize RNI to optimize mobility procedures required to support service continuity. RNI is also used to optimize network operation. The RNIS supports a wide range of use-cases, some of which are described in ETSI GS MEC 002 [12].

The service consumers interact with the RNIS over the RNI API to obtain contextual information from the radio access network. The Radio Network Information API supports both queries and subscriptions (pub/sub mechanism) that are used over the RESTful API or over the message broker of the MEC platform. More information about the RNIS as well as the APIs is available in ETSI GS MEC 012 [9].

Figure 7.2-1 illustrates the resource URI structure of this API. Table 7.2-1 provides an overview of the resources defined by the present document, and the applicable HTTP methods.

Location API

The availability of accurate location information is crucial to a number of services and enables area-specific application data content. MEC’s Location Service (LS) can provide location-related information to a MEC platform or authorized applications.

The LS leverages the Zonal Presence Service described by Small Cell Forum in [16] and [17]. The Location Service is accessible through RESTful APIs originally defined by Open Mobile Alliance (OMA). The incorporated API definitions as well as the full description of the location service are available in ETSI GS MEC 013 [10]. The Location Service is registered and discovered over the Mp1 reference point defined in ETSI GS MEC 003 [13].

Consumers of the Location Service may use the LS API to obtain the location information of a UE, a group of UEs, or the radio nodes associated with a MEC host. For example, the service can perform active device location tracking or provide location-based service recommendations to allow a variety of additional services tightly coupled with a specific place (such as a shopping mall). It is possible to report information such as the distance between a specified UEs or the distance between a specified location and a UE, provide a list of UEs in a particular area of location, or even report when specific UEs move in or out of a particular area.

The service supports both geolocation, such as geographical coordinates, and logical location, such as a Cell ID. Subscriptions to location information are also offered, including periodic location information updates, updates on changes in distance and location updates relating to UEs in a particular area of location, and more. The Location Service API supports both queries and subscriptions (pub/sub mechanism). To facilitate collection of statistics, anonymous location reporting (without related UE ID information) can be used. Operators or third-party services can use the location data for security, safety, and data analytics, or to optimize the network.

Bandwidth Manager API

When a MEC host runs applications in parallel and is using the same network resources, applications are typically competing over available bandwidth. Data traffic associated with different MEC applications (or even specific application sessions) may have different bandwidth requirements with respect to e.g. throughput and priority. A bandwidth management service (BWMS), which likely is produced by the MEC platform, allows a fair distribution of bandwidth resources between applications.

Using the BWMS, different applications, whether managing a single instance or several sessions, may request specific bandwidth requirements for the whole application instance or different bandwidth requirements per session. The BWMS aggregates all the requests to help optimize bandwidth usage and allocates it accordingly.

The Bandwidth Management (BWM) API, described in ETSI GS MEC 015 [14], enables registered MEC applications to request a specific bandwidth allocation. Applications can call the BWM API to register, update or unregister their specific bandwidth requirements (size/priority). It is also possible for the application to query the API to get their configured bandwidth allocation. A specific MEC application or application session is identified using a set of filters within the resource request of the API. The API uses a RESTful API design. Furthermore, the BWMS design might interface with the Radio Network Information Service to use available Layer 2 and QoS information to facilitate the traffic arbitration.

UE Identity API

The MEC platform provides functionality to facilitate the association of IP traffic flows with a particular UE using an externally defined tag rather than the UE Identity directly. The association between a tag and the UE Identity helps preserve user privacy protect identity information at both mobile and enterprise network. A MEC application manages related access control and the integrity of the user content. This is where the UE Identity API, described in ETSI GS MEC 014 [15], comes in.

The UE Identity API provides functionality for a MEC application to register/deregister a tag (representing a UE) or a list of tags in the MEC platform. Each tag has been mapped to a specific UE in the mobile network operator’s system and the MEC platform is provided with the mapping information. The MEC platform uses registered tags to apply traffic filters rules based on that tag. *This enables authorized UEs to get their user plane traffic routed directly to e.g. a local enterprise network without having to pass through the MEC application. *The tag-based traffic filter rules are handled in the MEC platform and described in ETSI GS MEC 011 [3].