---

5.4.3 Mobility

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

The terminal is likely to be a mobile device and the current MEC host of the user session may not be the best choice due to a change in the device’s location. The MEC system allows the relocation of the user context for a session from one application instance to another running in a MEC host closer to the user. This facilitates service continuity and offers programmers the opportunity to design their applications with the capability to leverage and optimize the user context relocation procedure. Such capabilities include monitoring the application KPIs to assist the relocation decision, mechanisms to determine the right relocation timing and data synchronization. Details of what constitutes user context are provided later in this section.

Application mobility may be triggered by a change in the device bearer path in the underlying transport network. For example, device handover from one 4G or 5G cell to another associated with a different MEC host. This situation requires the MEC system to make the application instance available in this new MEC host to ensure the optimum lowest latency service to this device. If a user context existed in the source application instance, it must be transferred to the new target application instance.

Support by the MEC system for application mobility is aimed at optimizing the performance of applications and reducing service latency by relocating user sessions to the application instance closest to the end user. This facilitated through the MEC application mobility service API. This service allows applications to manage the relocation of user sessions between application instances by informing the source instance of the target instance and by enabling user context transfer between the two instances.

The entities involved in application mobility are highlighted in Figure 12. Here, the client app runs on a device such as a mobile phone or on equipment installed in vehicle. The device hosting the client app can communicate via cellular network with the MEC hosts, i.e. MEC Host (A) and (B). These hosts are where the MEC app’ and app’’ instances run. At the remote level, the application is implemented in the cloud backend to serve the client app. The client app can communicate with either the edge level MEC application instances or the application instance(s) in cloud backend via the underlying network to receive the service produced by the application.

Initially, the client app may communicate with the remote level application. Then when the MEC system identifies that the device is within the serving area of MEC Host (B) it may create an edge level application instance (e.g. MEC app’’) to serve the user and offer an enhanced service to the client app, e.g. contextual based on the device location with overall lower latency. If the MEC system identifies device handover to a new location associated with MEC Host (A) through the application mobility service, it will then create another new application instance (i.e. MEC app’) to continue serving the user. The application may need to synchronize the user context between application instances if they are running on the cloud backend, MEC Host (A) or (B) to ensure that the application service continuity is maintained.

Figure 12: Application mobility support transferring the service between the Cloud back-end and MEC instance User context is the application-specific runtime data maintained by the MEC application that is associated with a specific user or a group of users being serviced by that application. It may contain the client application identifier, the status of the application instance serving the user, the communication link and other runtime information. Such information is specific to and belongs only to the application. User context synchronization depends on the application implementation:

• For a stateless application, i.e. an application that does not retain the service state or recorded data about the user for use in the next service session, the application can be relocated to another MEC host without using the mobility service.
• For a stateful application, i.e. an application that stores information about service state during an application session change, it will require further application logic to transfer the user context from the source to the target application instance to maintain the service continuity.

MEC application mobility service can facilitate the support of service continuity for stateful applications, specifically by providing the necessary communication connections and support information exchange between application instances. However, the synchronization of application service state and other specific runtime information relies on the application SW implementation, which could take one of two approaches:

• Store it in the client app of user device
• Store it in the MEC application instance

If the user context is stored in the client app, the client app may be required to send the user context to the target application instance after the application service is moved to another MEC host.

If the user context is stored in the MEC application, the application is required to support the capability to transfer the user context between MEC application instances. In this case the MEC application mobility service API can assist since it allows the application to subscribe to notifications on relevant mobility events. This enables the application to prepare the user context for transfer to the target instance in a timely manner. The mobility service can also be used to notify the source application instance of the address of its peer target instance and therefore where the user context needs to be transferred.