Patent Description:
European Telecommunications Standards Institute (ETSI) industry specification group (ISG) on multi-access edge computing (MEC; sometimes also mobile edge computing) aims to provide information technology (IT) and cloud-computing capabilities close to the edge of a network, e.g., at the access network (AN) of a network. Due to the close proximity between MEC hardware such as MEC servers and the user equipment (UE; or terminal), MEC facilitates low latency applications. MEC is an example implementation of edge computing (EC). EC, in general, facilitates low-latency EC applications.

MEC is described in <NPL>), which is hereby incorporated herein by reference in its entirety by cross-reference. MEC is further described by ETSI ITS (<NUM>)01_038: ISG MEC#<NUM> Minutes of Plenary Meeting, which is also hereby incorporated herein by reference in its entirety.

For example, due to the mobility of the terminal, relocation of applications or specifically user contexts between different EC servers may be required. For example, due to user mobility, the EC system may detect that the current EC server executing the EC application as a host (source EC server) is not optimal and may need to relocate - sometimes also referred to as migrating or transferring - the EC application or, at least, a given user context of the EC application to a new EC server (target EC server). The target EC server may be more appropriate in terms of, e.g., geographical location, load balancing, latency etc. if compared to the source EC server. For facilitating such relocation in view of UE mobility, sometimes a control node of the EC system - also referred to as orchestrator node - is employed. The control node may track mobility of the UE and may control the relocation, e.g., to avoid or reduce impacts on the user experience associated with the application. Generally, the control node - beyond mobility management - may be responsible for further control functionality.

Some EC applications involve participation of multiple users. Such multi-user EC applications may include, e.g., video conferencing between multiple users, online games with multiple players, etc.. For example, in a video game, several players are playing in the same level and they are able to see each other in the game. A further example includes a multi-user chatroom.

It has been observed that relocation in a multi-user EC application scenario faces certain restrictions and drawbacks. For example, a flexibility in relocation may be limited, e.g., if the user contexts for multiple users have to be relocated one after another. Furthermore, control signaling overhead can be significant when relocating in a multi-user EC application scenario.

Document ETSI GR MEC <NUM>, V1. <NUM> titled "Mobile Edge Computing (MEC); End to End Mobility Aspects", dated October <NUM> and published by ETSI, discloses mobility support provided by MEC and documents mobility use cases and end to end information flows to support UE and application mobility for MEC. The document further identifies gaps to support mobility that are not covered by existing Wls, documents these gaps and recommends the necessary normative work to close these gaps.

Therefore, a need exists for advanced EC techniques. Specifically, a need exists for EC techniques which overcome or mitigate at least some of the above-identified restrictions and drawbacks.

This need is met by the features of the independent claims which define the present invention.

A method of operating a source EC server of an EC system includes executing a multi-user EC application between the source EC server and a first UE for a first user and between the source EC server and a second UE for a second user. Said executing is based on a first user context based on a first user context of the first user comprising a first set of parameters having values specific to the multi-user EC application being executed for the first user between the first UE and the source EC server, a second user context of the second user comprising a second set of parameters having values specific to the multi-user EC application being executed for the second user between the second UE and the source EC server, and a group context of the first user and the second user comprising group parameters having values shared between the first user and the second user available to the source EC server for executing the multi-user EC application for the first user and the second user between the first UE and the second UE and the source EC server. The method also includes relocating the first user context from the source EC server to a target EC server. The method also includes providing the group context form the source EC server to the target EC server.

By providing the group context from the source EC server to the target EC server, it is possible to facilitate full or partial relocation of the multi-user EC application at low latency and with limited control-signaling overhead.

A computer program or a computer program product includes program code. The program code can be executed by at least one processor. Executing the program code causes the at least one processor to perform a method of operating a source EC server of an EC system. The method includes executing a multi-user EC application between the source EC server and a first UE for a first user and between the source EC server and a second UE for a second user. Said executing is based on a first user context of the first user comprising a first set of parameters having values specific to the multi-user EC application being executed for the first user between the first UE and the source EC server, a second user context of the second user comprising a second set of parameters having values specific to the multi-user EC application being executed for the second user between the second UE and the source EC server, and a group context of the first user and the second user comprising group parameters having values shared between the first user and the second user available to the source EC server for executing the multi-user EC application for the first user and the second user between the first UE and the second UE and the source EC server. The method also includes relocating the first user context from the source EC server to a target EC server. The method also includes providing the group context form the source EC server to the target EC server.

A source EC server of an EC system, the source EC server comprising control circuitry configured to perform: executing a multi-user EC application between the source EC server and a first UE for the first user and between the source EC server and a second UE for the second user based on a first user context of the first user comprising a first set of parameters having values specific to the multi-user EC application being executed for the first user between the first UE and the source EC server, a second user context of the second user comprising a second set of parameters having values specific to the multi-user EC application being executed for the second user between the second UE and the source EC server, and a group context of the first user and the second user comprising group parameters having values shared between the first user and the second user available to the source EC server for executing the multi-user EC application for the first user and the second user between the first UE and the second UE and the source EC server; and relocating the first user context from the source EC server to a target EC server; and providing the group context from the source EC server to the target EC server.

A method of operating a target EC server of an EC system includes relocating a first user context of a first user of a multi-user EC application from a source EC server to the target EC server, the first user context comprising a first set of parameters having values specific to the multi-user EC application being executed for the first user between a first user UE and the source EC server. The method also includes obtaining a group context of the first user and of a second user of the multi-user EC application from the source EC server, the group context comprising group parameters having values shared between the first user and the second user for the multi-user EC application being executed for the first user and the second user between the source EC server and the first UE of the first user and a second UE of the second user. The method also includes executing the multi-user EC application for the first user, based on the first user context and the group context available to the target EC server.

By obtaining the group context from the source EC server to the target EC server, it is possible to facilitate full or partial relocation of the multi-user EC application at low latency and with limited control-signaling overhead.

A computer program or a computer program product includes program code. The program code can be executed by at least one processor. Executing the program code causes the at least one processor to perform a method of operating a target EC server of an EC system. The method includes relocating a first user context of a first user of a multi-user EC application from a source EC server to the target EC server, the first user context comprising a first set of parameters having values specific to the multi-user EC application being executed for the first user between a first user UE and the source EC server. The method also includes obtaining a group context of the first user and of a second user of the multi-user EC application from the source EC server, the group context comprising group parameters having values shared between the first user and the second user for the multi-user EC application being executed for the first user and the second user between the source EC server and the first UE of the first user and a second UE of the second user. The method also includes executing the multi-user EC application for the first user, based on the first user context and the group context available to the target EC server.

A target EC server of an EC system, the target EC server comprising control circuitry configured to perform: relocating a first user context of first user of a multi-user EC application from a source EC server to the target EC server, the first user context comprising a first set of parameters having values specific to the multi-user EC application being executed for the first user between a first user UE and the source EC server; and obtaining a group context of the first user and of a second user of the multi-user EC application from the source EC server, the group context comprising group parameters having values shared between the first user and the second user for the multi-user EC application being executed for the first user and the second user between the source EC server and the first UE of the first user and a second UE of the second user; and based on the first user context and the group context available to the target EC server: executing the multi-user EC application for the first user.

It is to be understood that the features mentioned above and those yet to be explained below may be used not only in the respective combinations indicated, but also in other combinations or in isolation without departing from the scope of the invention as defined by the claims.

In the following, examples of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of examples is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the examples described hereinafter or by the drawings, which are taken to be illustrative only.

Hereinafter, techniques of EC are described. EC can facilitate providing ultra-low latency applications to UEs. An EC system providing EC applications is often associated with access nodes such as base stations (BSs) or access points of a wireless network. An example of a wireless network is a cellular network. For example, EC often relies on deployment of EC servers on which an EC application is executed within a radio AN (RAN) or close to equipment of a RAN of a cellular network. For example, the EC servers may be co-located with BSs of the RAN. EC systems may also be implemented for fixed-wire networks. For example, the EC servers may be operated by the same operator as the associated network. For example, the EC servers may have a high-throughput backbone connection to the AN. For example, the EC servers may offer applications such as cloud-based computing. The EC applications offered by the EC servers to a UE may benefit from low latency. For example, the latency may be less than <NUM>, optionally less than <NUM>. Due to such low latency, latency-sensitive applications may be provided. For example, the EC applications may relate to server-based gaming or augmented reality.

An example use case for an EC system includes virtual-reality <NUM>-D EC applications hosted by the EC server; such techniques may enable VR applications also on simpler UEs, such as lower end mobile phones. VR typically requires a very low latency feedback loop between the user input, e.g., moving the head, and the rendered VR 3D frames being shown on the display, e.g., the display in VR glasses. Preferably the total system round trip latency should be less than <NUM>. The EC servers, being placed closer to the users, have the potential to enable low latency applications such as VR.

A further example use case for an EC system includes videoconference EC applications hosted by the EC server. Other EC applications may not be low-latency related and may rather focusing on, e.g., reducing bandwidth etc.. A further example use case for an EC system includes multi-user gaming EC applications.

In some examples, the EC servers together with an EC control node implement an EC system. An EC system may have one or more proxy nodes that facilitate access by UEs. For example, the EC control node may perform control functionality with respect to the EC servers. Such control functionality may include: facilitating and, in particular, triggering relocation of EC applications between the EC servers of the EC system, i.e., from a source EC server to a target EC server; load balancing; deployment of additional EC servers; etc..

According to various examples, relocation of an EC application from a source EC server to a target EC server is described. Relocation can correspond to at least partly moving execution of the EC application from the source EC server to the target EC server, during runtime of the EC application.

In one example, in response to fully relocating the EC application from the source EC server to the target EC server, execution of the EC application at the source EC server stops. Fully relocating corresponds to mobbing the EC application. However, in further scenarios, the EC application is partly relocated from the source EC server to the target EC server; then, both, the source EC server, as well as the target EC server may be executing the EC application, e.g., for different users in case of a multi-user EC application. Such partial relocation may also be referred to as copying the EC application.

In greater detail, according to various examples, the user context of one or more users of a multi-user EC application is relocated from the source EC server to the target EC server. These users are relocated. The user contexts of one or more further users of the multi-user EC application may remain at the source EC server. These one or more further users are not relocated. Then, in response to this relocation, the multi-user EC application is executed, both, at the source EC server, as well as the target EC server, for different users. Hence, both the source EC server, as well as the target EC server can host the EC application. According to various examples, such partial or full relocation of the multi-user EC application is facilitated by relying on a group context of the multi-user EC application.

The group context is different from the user contexts. According to the present invention, values of one or more group-specific parameters of the group context may be shared between EC servers executing the multi-user EC application for different users. There may be shared access the values of the group-specific parameters. Hence, a single value per group-specific parameter may be sufficient for executing the EC application. This may be in contrast to the user contexts. Here, values of user-specific parameters of user contexts of different users of the multi-user EC application may not be shared between EC servers executing the multi-user EC application for the different users. Multiple values may be required for a given parameter, because the value may differ from user to user. To provide an example, the group-specific parameters for a videoconferencing EC application may include: server address of a central server hosting the video conference; time duration of the video conference; number of participants of the video conference; shared documents available to all users of the video conference; etc. It will be appreciated that such group-specific parameters do not vary from user to user. Examples of user-specific parameters of the videoconferencing EC application include: compression standard used for the back-end connection of each computer of the various users; individual connection time of each user; proprietary data associated with each user; user name; etc. Here, e.g., the user name takes different values for different user contexts.

According to various examples, the group context is provided from the source EC server to the target EC server. Thereby, the target EC server obtains the group context. Based on the group context provided by the source EC server and obtained by the target EC server, the target EC server can commence executing the multi-user EC application. By relying on the group context when relocating, it is possible to reduce control signaling overhead and reduce complexity. This, in turn, also helps to reduce latency.

Hence, in other words, according to various examples, an interface between EC servers is defined which supports transmission of the group context. Specifically, such an interface may be implemented on application-level. The EC application level may be defined in the EC servers; the interface may be logically defined on the same protocol stack layer as the EC application. Thus, the EC application itself may check whether the group context is available at the target EC server. According to various examples, said providing of the group context by the source EC server may include control signaling between the source EC server and the target EC server, e.g., is part of a negotiation whether providing of the group context is required. For example, according to certain implementations, it may be determined whether the group context is already available to the target EC server.

Upon the determining being negative, i.e., if the group context is not available to the target EC server, it is possible to provide the group context to the target EC server. Hence, if the user context for a given user of the multi-user EC application is relocated and the group context of the multi-user EC application is not yet available to the target EC server to which the user context is relocated, then it is possible to provide the group context to the target EC server. Such determining whether the group context is available to the target EC server may include control signaling between the source EC server and the target EC server. Again, this control signalling may logically be implemented on the same protocol stack layer as the EC application. Hence, different instances of the EC application - being executed by the various EC servers including the source EC server and the target EC server - can determine whether the group context is already available to the target EC server. For example, a request/response message pair may be exchanged between the source EC server and the target EC server. This reduces overall control signaling overhead, because unnecessary provisioning of group context may be avoided.

<FIG> illustrates aspects with respect to the cellular network. In particular, <FIG> illustrates aspects with respect to a RAN <NUM> of the cellular network. In the example of <FIG>, three BSs <NUM> - <NUM> form the RAN <NUM>. In other examples, a larger number of BSs could be used.

While various examples are described herein in the context of cellular networks, respective techniques may also be applied for other types of networks, e.g., adhoc wireless networks or fixed-wire networks.

Example implementations include 3GPP-specified networks such as <NUM> or <NUM> and WLAN or LAN.

The BS <NUM> serves a cell <NUM> of the cellular network. As such, the BS <NUM> is sometimes referred to as serving BS for UEs <NUM> located within the cell <NUM> and connected with the cellular network via the BS <NUM>. The BS <NUM> serves and adjacent cell <NUM> and, hence, is the serving BS <NUM> for the UE <NUM>. Also, the BS <NUM> serves an adjacent cell <NUM>.

Due to mobility of the UE <NUM>, the UE <NUM> may at one point in time come close to the cell edge of the cell <NUM>. Typically, in such a cell edge scenario, the quality of communicating on a radio channel between the UE <NUM> and the BS <NUM> deteriorates. For example, at one point in time the quality of communicating on the radio channel may fall below a certain threshold. This may be due, e.g., the UE <NUM> moving away from the BS <NUM> and towards the BS <NUM>. Then, a handover from the initially serving BS <NUM> - which, in the context of the handover is often referred to as the source BS - to the BS <NUM> (target BS) may occur. Once the handover is completed, the UE <NUM> is connected with the cellular network via the BS <NUM>, which is then the new serving BS. Handovers, or generally the mobility of the UE <NUM>, can be one example why a relocation of the EC application can be required.

<FIG> illustrates aspects with respect to the cellular network <NUM>. In <FIG>, the wireless link <NUM> via which the UE <NUM> is communicating with the BS <NUM> is illustrated. The communication on the wireless link <NUM> can be bidirectional including downstream communication from the BS <NUM> to the UE <NUM> and upstream communication from the UE <NUM> to the BS <NUM>. This also applies for the UE <NUM>.

<FIG> illustrates a core network <NUM> of the cellular network <NUM>. The BSs <NUM> - <NUM> are connected by core network interfaces <NUM> with each other and the core network <NUM>.

<FIG> illustrates aspects with respect to an EC system <NUM>. The EC system <NUM> is associated with the RAN <NUM> of the network <NUM>. The EC system <NUM> includes EC servers <NUM> - <NUM>. The EC server <NUM> is associated with the BS <NUM> and with the BS <NUM>; the EC server <NUM> is associated with a further BS <NUM>; and the EC server <NUM> is associated with the BS <NUM>. Applications hosted by a given one of the EC servers <NUM>-<NUM> are typically provided to UEs connected to the respectively associated BS <NUM>-.

For example, the EC servers <NUM> - <NUM> could be co-located at the same site as the associated BS <NUM> - <NUM>. By deploying the EC servers <NUM> -<NUM> in or close to the RAN <NUM>, a comparably low latency for communicating between the EC servers <NUM> - <NUM> and the associated BSs <NUM> - <NUM> may be achieved. For example, the latency of communicating between a given EC server <NUM> - <NUM> and the associated BS <NUM> - <NUM> may be below <NUM> milliseconds, preferably below <NUM> microseconds, more preferably below <NUM> microsecond. Sometimes, such a dimensioning of the latency is also referred to as ultra-low latency.

Control of the EC system <NUM> is provided by an EC control node <NUM>. For example, the local control node <NUM> can perform tasks of load balancing between the various EC servers <NUM> - <NUM>. For example, the local control node <NUM> can keep track of a computational load imposed to the various EC servers <NUM> - <NUM>. For example, the local control node <NUM> can control relocation of EC applications between the various EC servers <NUM>-<NUM> and, hence, implement mobility management.

For example, the local control node <NUM> can perform tasks with respect to relocating an application from a source EC server <NUM> - <NUM> to a target EC server <NUM> - <NUM> of the EC system <NUM>. For example, relocation of the EC application may be triggered due to mobility of the UE to which the EC application is provided. For example, relocation of the EC application may be due to a handover between cells <NUM> - <NUM> of the radio access network <NUM> of the cellular network <NUM>. For example, relocation of the EC application may be triggered due to load balancing.

<FIG> illustrates aspects with respect to relocation of an EC application. Specifically, <FIG> illustrates aspects with respect to relocation of a user context of the user X associated with the UE <NUM>. As such, <FIG> illustrates aspects with respect to partial relocation of a multi-user EC application.

Specifically, <FIG> illustrates aspects with respect to the source EC server <NUM> providing the group context of the EC application. <FIG> also illustrates aspects with respect to the target EC server <NUM> obtaining this group context.

In <FIG>, initially, the EC application is executed by the source EC server <NUM> for, both, the user X of the UE <NUM> and the user Y of the UE <NUM>. The source EC server <NUM> executes the EC application based on the user context <NUM> for the user X of the UE <NUM>, further based on the user context <NUM> for the user Y of the UE <NUM>, and further based on the group context <NUM>. The source EC server <NUM> hosts the EC application.

Initially, the target EC server <NUM> does not host the EC application.

The EC application is also executed by the UE <NUM> and the UE <NUM>.

Execution of the EC application includes local processing at the devices <NUM>, <NUM>, <NUM>. Execution of the EC application also involves communication of application data <NUM> (sometimes also referred to as payload data or user data) between the UE <NUM> and the source EC server <NUM> at <NUM> and, furthermore, between the UE <NUM> and the source EC server <NUM> at <NUM>. Generally, uplink application data and/or downlink application data <NUM> may be communicated.

Next, at <NUM>, a status control message <NUM> is transmitted by the source EC server <NUM> and received by the EC control node <NUM>. For example, the status control message <NUM> may be indicative of mobility measurements associated with the UE <NUM> and/or associated with the UE <NUM>.

At <NUM>, the control node <NUM> takes a relocation decision. In detail, a decision is taken to partly relocate the EC application from the source EC server <NUM> to the target EC server <NUM>. In further detail, the decision is taken to relocate the user context <NUM> from the source EC server <NUM> to the target EC server <NUM>. This may be referred to as relocating the user X.

At <NUM>, the control node <NUM> transmits corresponding relocation control messages <NUM> to the EC servers <NUM>, <NUM>.

As a general rule, the decision-making process and the implementation of the relocation decision and trigger according to <NUM> - <NUM> may vary in various implementations. Hence, the particular scenario illustrated in <FIG> is an example only. For example, in further scenarios, there may not be required an involvement of a central control node <NUM>. The relocation decision may be taken, e.g., at the source EC server <NUM>. For further illustration, in some scenarios, if there is involvement of the control node <NUM>, then the control node <NUM> may not communicate with the target EC server <NUM>, but merely communicate with the source EC server <NUM>. It follows that the specific details of the decision-taking process and the implementation of the relocation are not germane of the function of the techniques described herein and may be varied in other implementations. As a further example, while in the illustrated the EC server <NUM> provides the control message <NUM> to the control node <NUM>, in other scenarios such a control message may be alternatively or additionally provided by other nodes of the EC system <NUM>, e.g., a host node, a platform node, a platform manager node.

Next, at <NUM>, control signaling <NUM> is implemented between the source EC server <NUM> and the target EC server <NUM>. The control signaling <NUM> is for preparing the partial relocation of the EC application. The control signaling <NUM> is for preparing relocation of the user X.

For example, the control signaling <NUM> can include preparation of the target EC server <NUM> to receive the user context <NUM> of the user X at <NUM>. <NUM> corresponds to relocating the user context <NUM> from the source EC server <NUM> to the target EC server <NUM>.

At <NUM>, the group context <NUM> is provided by the source EC server <NUM> to the target EC server <NUM>. The target EC server <NUM>, at <NUM>, obtains the group context <NUM> from the source EC server <NUM>.

<NUM> and <NUM> are executed within a short timeframe, i.e., time-correlated. This is to facilitate low-latency relocation.

The control signaling <NUM> may also prepare this transfer of the group context <NUM> at <NUM>. For example, the control signaling <NUM>, at <NUM>, may be to determine whether the group context <NUM> is already available to the target EC server <NUM>. In the scenario of <FIG>, in response to the determining being negative, the group context <NUM> is the provided, at <NUM>, to the target EC server <NUM>.

In the scenario of <FIG>, the EC application is partly relocated from the source EC server <NUM> to the target EC server <NUM>, but not fully relocated. Hence, the group context <NUM> is not deleted from the source EC server <NUM>. The source EC server <NUM> rather continues to host the EC application. As such, <NUM> may correspond to copying the group context <NUM> from the source EC server <NUM> to the target EC server <NUM>, said copying resulting in multiple instances of the group context <NUM>, a first instance at the source EC server <NUM> and a second instance at the target EC server <NUM>.

The source EC server <NUM> may clear resources previously associated with the user context <NUM>, in response to relocating the user context <NUM>.

Then, the source EC server <NUM> can stop executing the EC application for the user X associated with the UE <NUM>, but can continue to execute the EC application for the user Y associated with the UE <NUM>. This is based on the user context <NUM> and the group context <NUM>, i.e., the local instance of the group context <NUM> available to the source EC server <NUM>.

At the same time, the target EC server <NUM> can commence executing the EC application for the userX associated with the UE <NUM> based on the relocated user context <NUM> as well as the instance of the group context <NUM> available to the target EC server <NUM>.

As illustrated in <FIG>, this execution of the EC application at, both, the source EC server <NUM> and the target EC server <NUM>, includes communicating application data <NUM> between the UE <NUM> and the source EC server <NUM> at <NUM>; and further includes communicating application data <NUM> between the UE <NUM> and the target EC server <NUM> at <NUM>.

At <NUM>, the group context <NUM> is synchronized between the source EC server <NUM> and the target EC server <NUM>, by means of respect of control signaling <NUM>. This synchronization helps to avoid divergence between the multiple instances of the group context <NUM> at the source EC server <NUM> and at the target EC server <NUM>.

There are various techniques available to implement the synchronizing of the group context <NUM>. For example, upon detecting a change at one of the instances of the group context <NUM>, the correspondingly updated group context <NUM> may be propagated to one or more other EC servers <NUM>, <NUM>. Bi-directional synchronization is possible, e.g., between synchronization peers. Master/slave synchronization is possible. For example, control signaling <NUM> may be implemented at the predefined timing, e.g., with a certain periodicity. As a general rule, said synchronizing may include incremental updates. For example, it may be determined which portions of the group context have changed since the last synchronization; then, the group context may be synchronized based on such determination. Incremental updates limit control signaling overhead.

In the scenario of <FIG>, once the partial relocation of the EC application has completed, i.e., once the target EC server <NUM> commences execution of the EC application for the user X, it is possible to stop execution of the EC application for the user X at the source EC server <NUM>. Corresponding resources can be released or cleared at the source EC server <NUM>.

<FIG> is a signaling diagram illustrating aspects with respect to partial relocation of an EC application. The scenario of <FIG> can be implemented as an extension of the scenario of <FIG>. Hence, the signaling according to <FIG> may begin upon completion of the signaling according to <FIG> (as indicated by the arrows in <FIG> and <FIG>).

Thus, initially, in the scenario of <FIG>, the EC application is executed at the source EC server <NUM> for the user Y of the UE <NUM> based on the user context <NUM> and the group context <NUM>. The EC application is also executed at the target EC server <NUM> for the user X of the UE <NUM> based on the user context <NUM> and the group context <NUM>. Both, the source EC server <NUM>, as well as the target EC server <NUM> host the EC application.

<NUM> - <NUM> generally correspond to <NUM> - <NUM>, this time for user Y of UE <NUM>. Specifically, at <NUM>, a relocation decision for the user Y is taken.

As such, <NUM> corresponds to <NUM>, and a preparation for relocating the user context <NUM> is taken.

At <NUM>, the user context <NUM> is relocated from the source EC server <NUM> to the target EC server <NUM>.

The control signaling <NUM> at <NUM> can again be used to determine whether the group context <NUM> is already available to the target EC server <NUM>. In the scenario of <FIG>, the group context <NUM> is already available to the target EC server <NUM>. Hence, there is no need for the source EC server <NUM> again providing the group context <NUM>, or the target EC server <NUM> again obtaining the group context <NUM>.

Furthermore, due to synchronization (cf. <FIG>: <NUM>), the group context <NUM> available to the target EC server <NUM> is up-to-date (while in <FIG> and <FIG> synchronization is indicated at <NUM>, for sake of simplicity, using a single repetition of the control signaling <NUM>, generally, multiple repetitive instances of control signaling <NUM> for synchronization are possible, to provide up-to-date group contexts <NUM> at the participating EC servers <NUM>, <NUM>).

In response to relocating the user context <NUM> at <NUM>, the source EC server <NUM> is not required to serve any remaining users. The EC application has now fully been relocated. Hence, in response to relocating the user context <NUM> at <NUM>, execution of the EC application at the source EC server <NUM> is stopped. The source EC server <NUM> does not anymore host the EC application. Corresponding resources may be released or cleared.

Further, there is no need to update or maintain the group context <NUM>. Respective resources can be released or cleared. The group context <NUM> could be deleted at the source EC server <NUM>. Then, also the synchronization of the group context <NUM> between the source EC server <NUM> and the target EC server <NUM> stops.

Finally, the target EC server <NUM> executes the EC application for the user X of the UE <NUM> and the user Y of the UE <NUM>, based on the user context <NUM>, the user context <NUM>, as well as based on the group context <NUM>. Corresponding application data <NUM> is communicated at <NUM>, <NUM> between the UE <NUM> and the target EC server <NUM> and between the UE <NUM> and the target EC server <NUM>.

As will be appreciated from <FIG> and <FIG>, scenarios have been described in which the group context is not fully relocated initially, but rather copied from the source EC server <NUM> to the target EC server <NUM>. In other scenarios, it would also be possible to move the group context <NUM> from the source EC server <NUM> to the target EC server <NUM>. Such a scenario may be applicable where full relocation of the EC application from the source EC server <NUM> to the target EC server <NUM> is desired.

<FIG> illustrates aspects with respect to the EC servers <NUM> - <NUM>. The EC server <NUM> -<NUM> includes control circuitry, implemented, in <FIG>, by a processor <NUM>, an interface <NUM>, and a memory <NUM>. Communication with other nodes is possible via the interface <NUM>. Program code can be stored in the memory <NUM> and then be executed by the processor <NUM>. Executing the program code causes the processor <NUM> to perform techniques as described herein, e.g.: executing an EC application; partly or fully relocating an EC application; relocating user contexts; copying and/or relocating (providing) group contexts, synchronizing group contexts, etc..

<FIG> is a flowchart of a method according to various examples. For example, the method according to <FIG> may be executed by the control circuity <NUM> - <NUM> of an EC server <NUM> - <NUM> (cf. This EC server acts as source EC server.

At block <NUM>, the EC application is executed for multiple users. The EC application is a multi-user EC application.

The EC application, at block <NUM>, is executed based on user contexts for each user, and further based on a group context. Values of group-specific parameters of the group context are shared between executing the EC application for different users; while values of user-specific parameters of the user contexts are different from user to user.

Next, at block <NUM>, one or more user contexts are relocated (cf. <FIG>: <NUM>; <FIG>: <NUM>). Relocating can include control signaling between the source EC server and a target EC server of the relocation.

As a general rule, various trigger criteria for relocating one or more user contexts at block <NUM> are available, e.g., mobility measurements, load balancing, resilience operation, etc..

Next, at optional block <NUM>, it is determined whether the group context of the multi-user EC application is available to the target EC server, to which the one or more user contexts have been relocated at block <NUM>. Block <NUM> may involve respective control signaling between the source EC server and the target EC server (cf. <FIG>: <NUM>; and <FIG>: <NUM>).

In response to the determining at block <NUM> being negative, at optional block <NUM>, it is checked whether any users remain being served by the source EC server, block <NUM>. For example, if, at block <NUM>, the user contexts of all users of the EC application have been relocated, then, at block <NUM>, no remaining users are detected. Such a scenario would correspond to a full relocation of the EC application. In such a scenario, at block <NUM>, the group context is moved from the source EC server to the target EC server: it is not required to maintain multiple instances of the group context.

At block <NUM>, next, execution of the EC application can be stopped at the source EC server. Corresponding resources may be released or cleared at the source EC server. Hence, the EC application has been fully relocated from the source EC server to the target EC server.

If, however, at block <NUM>, it is judged that users remain to be served by the source EC server, then, at block <NUM>, the group context is copied. Hence, instances of the group context are available to, both, the source EC server as well as the target EC server. Both act as hosts for the EC application. This scenario corresponds to a partial relocation of the EC application.

At block <NUM>, the EC application is executed for any users remaining at the source EC server. This is based on the respective user context(s) and the group context.

At block <NUM>, multiple instances of the group context are synchronized between the source EC server and the target EC server. This is to implemented up-to-date group contexts at, both, the source EC server and the target EC server. <NUM> may include repetitive control signaling to provide freshness of the group context.

Eventually, block <NUM> can be executed at some point in time.

If, at block <NUM>, it is judged that the group context is already available to the target EC server, optional block <NUM> is executed. Block <NUM> corresponds to block <NUM>.

If at block <NUM> it is judged that no users remain being served by the source EC server, then, at block <NUM>, execution of the EC application at the source EC server stops. Otherwise, at block <NUM>, execution of the EC application for the remaining users commences.

As will be appreciated, overhead control signaling is avoided by determining whether the group context is already available to the target EC server, at block <NUM>, and conditionally executing in <NUM> and <NUM>.

<FIG> is a flowchart of a method according to various examples. For example, the method of <FIG> could be executed by the control circuity <NUM> - <NUM> of the EC server <NUM> - <NUM> of <FIG>. The executing EC server may act as a target EC server. As such, the method of <FIG> may be inter-related to the method of <FIG>.

At block <NUM>, one or more user contexts are relocated to a target EC server from a source EC server. As such, block <NUM> can be inter-related with <NUM> of <FIG>.

Next, at block <NUM>, a group context is obtained. This may include copying the group context (cf. <FIG>; block <NUM>) or moving the group context (cf. <FIG>: block <NUM>).

Next, at block <NUM>, the EC application is executed for one or more users for which the user contexts have been relocated at block <NUM>, based on the one or more user contexts and the group context of block <NUM>.

In optional block <NUM>, the group context is synchronized between the source EC server and the target EC server. As such, block <NUM> can be inter-related with the block <NUM> of <FIG>.

Although the invention has been shown and described with respect to certain preferred embodiments, equivalence and modifications will occur to others skilled in the art upon the reading and understanding of the specification. The present invention includes all such equivalence and modifications and is limited only by the scope of the independent claims.

For example, various scenarios have been described with respect to an intra-EC-System relocation of an EC application, i.e., from a source EC server to a target EC server of the same EC system. Similar scenarios may be readily applied with respect to inter-EC-System relocation.

For further illustration, above, various scenarios have been described in which a group context is provided by a source EC server by copying the group context. Similar scenarios may be readily applied with respect to a scenario in which the group context is provided by the source EC server by moving the group context to a target EC server. Here, resources previously associated with the group context at the source EC server may be cleared in response to moving of the group context.

For still further illustration, various scenarios have been described above with respect to EC in connection with a cellular network. However, similar scenarios may be readily applied to other kinds and types of networks, e.g., a fixed-wire local area network, etc..

Claim 1:
A method of operating a source edge computing server (<NUM>) of an edge-computing system (<NUM>), comprising:
executing a multi-user edge computing application between the source edge computing server (<NUM>) and a first user equipment -UE- (<NUM>) for a first user and between the source edge computing server (<NUM>) and a second UE (<NUM>) for a second user based on:
a first user context (<NUM>) of the first user comprising a first set of parameters having values specific to the multi-user edge computing application being executed for the first user between the first UE (<NUM>) and the source edge computing server (<NUM>);
a second user context (<NUM>) of the second user comprising a second set of parameters having values specific to the multi-user edge computing application being executed for the second user between the second UE (<NUM>) and the source edge computing server (<NUM>); and
a group context (<NUM>) of the first user and the second user comprising group parameters having values shared between the first user and the second user available to the source edge computing server (<NUM>) for executing the multi-user edge computing application for the first user and the second user between the first UE (<NUM>) and the second UE (<NUM>) and the source edge computing server (<NUM>);
- relocating the first user context (<NUM>) from the source edge computing server (<NUM>) to a target edge computing server (<NUM>), and
- providing the group context (<NUM>) from the source edge computing server (<NUM>) to the target edge computing server (<NUM>).