---

5.3.2 Phase 2: MEC app instance instantiation and operation

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

In this section we describe how the developer can get the MEC application instantiated in the MEC system and then make it available to the target audience (the final customers, or in general the app users).

Application initialization may be triggered from a device or from the Operation Support System (OSS). With the first option (figure 4 below), a developer is able to interact directly with the MEC system using a device with a client supporting the Mx2 API (see ETSI GS MEC 016 [4]). In MEC parlance such a client is referred to as a device application. This also requires the MEC system to support the MEC standards defined UserApps feature. The User Application LifeCycle Management Proxy (UALCMP) exposes the Mx2 API to the device application (see Figure 4). It allows the device application to request the following application lifecycle management operations from the MEC system: query the available applications, instantiation and deletion of an application and update of an existing application context.

Figure 5: MEC app instantiation options

The other option for the application instantiation is via direct interaction between the developer/service provider and the MEC operator without the involvement of a device application. The MEC operator then triggers the application on-boarding and instantiation directly through the OSS. With this approach the application developer does not have to concern themselves with this initial phase.

The following two subsections describe the instantiation process from a client (external) perspective and give a brief overview of how this is performed from a MEC platform (internal) perspective.

The client perspective

In real life scenarios, for direct interaction with the MEC system, the device application needs a subscription or some other contract with the MEC operator. The subscription authorizes the device application to make use of the MEC services. The ETSI MEC specification relies on OAuth 2.0 in securing the device application’s access to MEC system resources. The device application first authenticates and then gets authorized in operator’s AA server, which will provide the necessary credential for Mx2 API operations, i.e. the access token. Once it has those and has discovered the UALCMP it can then invoke Mx2 API. In each API call the device application is expected to include the access token in the "Authorization" header field as a bearer token as defined in IETF RFC 6750 [6]. The exact methodology for the device application to acquire the token is beyond the scope of the MEC specification. It is also noteworthy that any given MEC operator may support other means of authentication and authorization, which are also beyond the scope of MEC standard.

With the Mx2 API there are different application instantiation options. If the application image is already available in the MEC system, the developer can request it to be instantiated directly. The Mx2 API also supports querying of all available applications and then pick the one to be instantiated. If, however, the application image is not yet in the MEC system, the developer can provide the MEC system with a link to the application package that contains the image and the descriptor. Using this link, the system can retrieve and then instantiate it. In this latter option, if at all supported by the MEC operator, the image repository most likely will have to be trusted by the operator, or the operator may even have a repository of its own where the developers can make their application images available. In both options the MEC system’s response to a successful instantiation includes the address of the instantiated application. The attribute ReferenceURI in the Application Context in the response body from the UALCMP conveys the address of the application instance. Once the device application has received the address for the MEC application, the developer can disseminate it among the target audience through their own chosen means. During the lifetime of the application instance the device application will receive notifications of the change, if any, of the application address.

According to the ETSI MEC terminology and specifications, a MEC application that was instantiated in the MEC system in response to a request of a user over Mx2 API is called a user application. In addition to instantiation, the Mx2 API also supports the deletion of the user application. The developer can request the application context to be deleted, resulting in a termination of the application and removal of the application’s resources in the MEC system for application context in question.

At this point it is worth emphasizing a couple of essential aspects on the application instantiation in MEC:

1. All operations between the authorized device application and the system proxy (UALCMP) on Mx2 API are management plane operations. There the application instance is referred to via the identifier of the context that was created by the MEC system for this application instance. Data type AppContext in ETSI GS MEC 016 [4] represents the information on application context, and there the attribute contextId is the identifier of the said application context. Each application
2. On the user plane any user with a connected device can attempt to contact the application by using the application’s address (the one originally found in the ReferenceURI, e.g. an IP address) as is the case with any internet application. As the MEC system can also configure the DNS server, the application instance may also be addressed by its FQDN (Fully Qualified Domain Name), if available. Any security, authentication, authorization, etc. related to accessing the instantiated application on the user plane is beyond the scope of the MEC specification and will have to be provided by the application/service provider.
3. The developers requesting an application to be instantiated cannot select the location where the application is instantiated, but they shall describe the requirements of the application. These requirement attributes are defined in the Application descriptor data type in ETSI MEC GS 010-2 [5] and they include the C/S/N requirements but also the maximum latency tolerated by the application. It is then the MEC system Management & Orchestration (MANO) that selects the ideal location for the application instance. For an application image made available in a repository for the MEC system to fetch it, the application descriptor is expected to be included in the application package.

开发者不能选择应用具体位置，它是由MANO完成的，它可以通过描述应用的需求包括最大时延容忍等给MEC做选择。

The MEC platform perspective

As explained earlier, the instantiation of a MEC application on a MEC host is initiated by the OSS, e.g. in response to a request from the device application, or via direct interaction between the service provider and MEC operator. The OSS forwards the granted instantiation to the MEO, which is responsible for oversight of available MEC apps/services, and app termination. The MEO selects the target MEC platform (MEP) and forwards the request to selected MEPM, which configures the MEP accordingly.

An instantiation request contains information about the application to run, application rules and requirements and possibly other information, such as the target location where the application is to be deployed. MEPM can send lifecycle requests to the VIMs for allocating virtualized resources (compute, storage and networking) and for instantiating the MEC application. Once set up, the MEC application is enabled to interact with MEP over Mp1 to perform certain support procedures related to the lifecycle of the application, such as indicating availability, preparing relocation of user state, etc. MEPM also receives virtualized resources fault reports and performance measurements from VIM for further processing and updates the initial set-up information accordingly.

After an application has been instantiated, the following operations can be performed on the application instance through the application lifecycle management APIs (see ETSI GS MEC 010-2 [5]):

• Start: instruct the application instance to run and produce the service
• Stop: instruct the application instance to stop running and producing service

When an operation on the application instance is invoked, the application lifecycle management will trigger a special task, i.e. Application lifecycle Operation Occurrence, to track the operation and send a notification to the application lifecycle management once the operation finishes. The application lifecycle management then updates the operational state of the application instance accordingly.

The MEC platform and MEC applications or services can subscribe to the notification on application instance operational state change through the application lifecycle management APIs.