Patent Description:
The development of cloud-based services, operating to assist mobile devices with network-assisted storage and computing, is heavily increasing. Currently, ETSI (European Telecommunication Standards Institute) is promoting a new technology originally denoted Mobile Edge Computing (MEC), which is being standardized in an ETSI Industry Specification Group (ISG) of the same name. In the second phase of ETSI MEC ISG this is replaced by the term Multi-access Edge Computing, using the same acronym MEC, which also includes other types of access besides cellular, e.g. local area wireless connectivity such as wifi and also fixed networks.

MEC is a network architecture concept that enables cloud computing capabilities and an IT service environment at the edge of a communication network. MEC is the term used by ETSI for the concept mobile Edge Computing (EC). MEC allows applications to benefit from ultra-low latency and high bandwidth as well as real-time access to radio network information.

In an EC system, such as MEC, an EC host implemented in a server, also referred to as an EC server may be configured to execute an application for a user operating a client User Equipment (UE). Being an edge device, an EC server may typically be connected close to a communication access node, such as a cellular base station or a wifi access point.

In addition to providing such static EC servers, an EC system may include mobile EC servers. The concept of having a mobile EC server, such as a computing server located in a vehicle such as a car, train, drone etc., provides some challenges for power-efficient operation. In other words, energy efficiency will be a critical parameter, such that a power source associated with the EC server, typically a power source of the vehicle, is not unduly drained.

A suggestion for a solution to this problem has been provided in ETSI document MEC(<NUM>)<NUM>, entitled "MEC002 - Considerations for power management of MEC hosts". This document broadly suggests that MEC hosts are powered down when there are no MEC applications in service, basically meaning that they are turned off when not used. The MEC host may further be configured to wake up upon paging from remote services.

<CIT> discloses a method for managing power consumption of a network. For example, a network device may monitor a set of network area zones of a network coverage area, where each network area zone is associated with a set of edge devices. A first occupancy state may be determined for a first network area zone of the set of network area zones based on usage of a first set of edge devices of the first network area zone. Based on the determined first occupancy state, a first power consumption policy for the first network area zone may be determined. Responsive to determining the first power consumption policy, the determined first power consumption policy may be applied to the first set of edge devices in the first network area zone at least edge changing a power consumption mode of a first edge device in the first set of edge devices.

<CIT> relates to relocation of mobile edge applications. Based on control data indicative of a user engagement in a mobile edge application which is being executed on a source mobile edge server of a mobile edge system and on a terminal, relocation of the mobile edge application from the source mobile edge server to a target mobile edge server is facilitated.

However, there is still room for improvement in the field of power management of mobile EC servers, such as MEC hosts, to provide more sophisticated and efficient energy reduction.

MEC is the term used by ETSI, but other forms of Edge Computing architectures are plausible, such as proprietary systems. For these reasons, the more general term Edge Computing (EC) will predominantly be employed herein, while the term MEC will occasionally be used to illustrate such examples.

Solutions related to the problems associated with power management of mobile EC servers are set out in the claims, that set out the embodiments of the invention.

In the following description, for purposes of explanation and not limitation, details are set forth herein related to various embodiments. However, it will be apparent to those skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In some instances, detailed descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail. The functions of the various elements including functional blocks, including but not limited to those labeled or described as "computer", "processor" or "controller", may be provided through the use of hardware such as circuit hardware and/or hardware capable of executing software in the form of coded instructions stored on computer readable medium. Thus, such functions and illustrated functional blocks are to be understood as being either hardware-implemented and/or computer-implemented and are thus machine-implemented. In terms of hardware implementation, the functional blocks may include or encompass, without limitation, digital signal processor (DSP) hardware, reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) [ASIC], and (where appropriate) state machines capable of performing such functions. In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer and processor and controller may be employed interchangeably herein. When provided by a computer or processor or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, use of the term "processor" or "controller" shall also be construed to refer to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.

Edge Computing (EC) is thought of as a natural development in the evolution of mobile radio stations and the convergence of IT and telecommunication networking. EC is based on a virtualized platform and will enable applications and services to be hosted 'on top' of mobile network elements, i.e. above the network layer. These applications and services can benefit from being in close proximity to the customer and from receiving local radio-network contextual information, e.g. in order to host such applications and services with a lower communication latency and with improved network information awareness than other solutions where the platform is located in other locations than in the close proximity. In general, the environment of EC is characterized by low latency, proximity, high bandwidth, and real-time insight into radio network information and location awareness, accomplished with EC servers hosting operator or 3rd party applications. As such, EC may enable new vertical business segments and services for consumers and enterprise customers. Frequently discussed use cases include video analytics, location services, Internet-of-Things (IoT), augmented reality, optimized local content distribution, data caching, mobile gaming, connected and controlled vehicle services etc. EC will allow software applications to tap into local content and real-time information about local-access network conditions. By deploying various services and caching content at the network edge, mobile core networks are alleviated of further congestion and can efficiently serve local purposes.

<FIG> illustrates an EC system reference architecture, in the form of a MEC network architecture configured according to an embodiment, showing functional elements that comprise the EC system, and the reference points between them.

In a broad context, an EC system comprises one or more EC hosts or servers, which hosts may run or execute EC applications to users, connecting to the EC system through a User Equipment (UE), typically by radio communication. Moreover, the EC system comprises an EC management entity, which is configured to control the EC hosts to instantiate EC applications using one or more services.

For an ETSI MEC system with MEC components, as shown in <FIG>, there are three groups of reference points defined between the system entities:.

In accordance with some embodiments, an MEC system may be divided into an MEC system level <NUM> and an MEC host level <NUM>. The system may comprise one or more MEC hosts <NUM>, <NUM>-<NUM> etc., and MEC management necessary to run MEC applications within an operator network or a subset of an operator network.

The MEC host <NUM> may be an entity that contains an MEC platform <NUM> and a virtualization infrastructure <NUM> which provides compute, storage, and network resources, for the purpose of running MEC applications <NUM>.

The MEC host <NUM>, <NUM>-<NUM>, or more generally an EC server or EC host <NUM>, may comprise an MEC platform <NUM>, which is a collection of essential functionalities required to run MEC applications <NUM>, more generally referred to herein as EC applications, on a particular virtualization infrastructure and enable them to provide and consume MEC services. The MEC platform <NUM> may also provide services. Such services may e.g. include radio network information services, configured to provide authorized EC applications with radio network related information; location services, configured to provide authorized EC applications with location-related information; bandwidth manager services, configured to allow allocation of bandwidth to certain traffic routed to and from EC applications and the prioritization of certain traffic.

EC applications <NUM> are instantiated on the virtualization infrastructure of the MEC server <NUM> based on configuration or requests validated by MEC management. The MEC management may comprise MEC system level management and MEC host level management. Further MEC servers <NUM>-<NUM> may form additional EC servers of the system, which may be configured in a corresponding manner as the MEC server <NUM>.

The MEC system level management includes an MEC orchestrator <NUM> as a core component, which is configured to have an overview of the complete MEC system, and an operations support system <NUM>. The MEC host level management comprises an MEC platform manager <NUM> and a virtualization infrastructure manager <NUM> and is configured to handle management of MEC specific functionality of a particular MEC host <NUM>, and the applications <NUM> running on it.

In an embodiment configured in accordance with the ETSI MEC standard, the system may comprise the following elements or features:.

In the context of the solutions provided herein, an embodiment set out for MEC may include an EC management entity <NUM> which includes at least the orchestrator <NUM>, but the EC management entity may also include one or both of the Operations Support System <NUM> and the mobile edge platform manager <NUM>.

<FIG> schematically illustrates various User Equipment (UE) <NUM> operating as wireless devices <NUM> in an EC system <NUM> connected to a wireless communication network comprising network nodes <NUM>, <NUM>. The wireless communication network may comprise a radio access network, and the network nodes <NUM>, <NUM> may be radio stations in a cellular arrangement. Such a radio communication network may e.g. be a 3GPP LTE network, in which the network nodes <NUM>, <NUM> are denoted eNodeB. Furthermore, in a 3GPP NR network, the network node <NUM>, <NUM> are denoted gNodeB. In an alternative embodiment, the radio communication network may e.g. be a wifi system, such as according to IEEE <NUM>. The network nodes <NUM>, <NUM> may in such a system be denoted access points and are typically not arranged in a cellular arrangement. In various embodiments, various EC servers may be configured to be connectable to UEs using other communication technologies, such as e.g. Bluetooth, LoRa, ZigBee etc..

A first server <NUM> configured to operate as an EC server, such as a MEC host, is located in a movable node or vehicle <NUM>, such a car. The mobile first EC server <NUM> is powered by a power source <NUM>, such as a battery of the vehicle <NUM>. The first EC server is further connected to a communication interface <NUM>, operable for communication with network nodes of the wireless communication network, such as a first radio station <NUM>. A second server <NUM>-<NUM> configured to operate as an EC server is connected to a network node, such as a second radio station <NUM>. The second server <NUM>-<NUM> may e.g. be a stationary server, in the sense that it is physically located in a static place, e.g. wire-connected to the second network node <NUM>.

An EC management entity <NUM> may be configured to control instantiation and relocation of application sessions to and between the EC servers <NUM>, <NUM>-<NUM>. With reference to <FIG>, the EC management entity <NUM> may e.g. comprise a MEC orchestrator <NUM> and an operations support system <NUM>, and optionally also a MEC platform manager <NUM> in various embodiments.

An object of the solutions proposed herein is to provide a solution for power management which not only takes its available current EC application service in to consideration. Specifically, solutions are provided which are configured on the basis of the first EC server being mobile. These are based on inter alia the following considerations:.

For these purposes, it is in various embodiments proposed to introduce a central function for handling the control functionality of power save mode / dormant mode to an EC server. When introducing a power save state of an EC server, this also involves signaling in various embodiments to support the following:.

The overall scenario for the solution of the proposed concept is explained herein with reference to the drawings. <FIG> illustrates inter alia the entities that may be used or consider for managing the power state of an EC server <NUM>, such as the EC management entity <NUM>, including e.g. orchestrator, EC platform, EC platform manager etc., other EC servers nearby, and external entities outside the EC system such as e.g. the radio access network (RAN), power supply management systems <NUM> of the moving node <NUM>, positioning systems <NUM> etc. The properties and status of these entities may influence whether the EC server <NUM> should be controlled to enter a dormant state or not and for taking state change decisions. In case an EC server <NUM> enters a dormant state, this means the EC server <NUM> is no longer available to host any EC applications <NUM>. Correspondingly, these entities may be used or considered for waking up the mobile EC server <NUM> from a dormant state.

The proposed functionality also includes new triggering mechanisms of an EC server (possibly moving) node to change its power state from active to dormant (and vice versa). The trigger mechanism can be used for either centralized decisions of EC power states or distributed decisions. For the centralized case the management entity <NUM> may request an EC server <NUM> to transfer information to the management entity <NUM> to have relevant information to take the decision. In the distributed case the management entity <NUM> is configured to provide information about parameters and rules/trigger criteria for the EC server <NUM> to take into account for deciding and executing a switch between states. Examples of different triggers may be associated with for example power/battery level for the mobile EC server <NUM>, position information, time, network access status, load level and capacity of the mobile EC server and other EC servers in the system <NUM>, etc..

Before discussing function and operation, it may be noted that <FIG> schematically illustrates an embodiment of an EC management entity <NUM> of an EC system <NUM>. The EC management entity <NUM> comprises control circuitry <NUM> being configured to carry out the method steps of any of the embodiments outlined herein. The control circuitry <NUM> may comprise one or more processors <NUM>, and memory storage <NUM> for storing computer code, such as a non-volatile memory, which code the processor <NUM> is configured to execute to carry out the methods presented herein. The management entity <NUM> may further comprise at least one interface <NUM>, for communicative control signaling with at least one EC server <NUM> of the EC system.

Moreover, <FIG> schematically illustrates an embodiment of a mobile EC server <NUM> of an EC system <NUM>. The mobile EC server <NUM> comprises control circuitry <NUM> being configured to carry out the method steps of any of the embodiments outlined herein. The control circuitry <NUM> may comprise one or more processors <NUM>, and memory storage <NUM> for storing computer code, such as a non-volatile memory, which code the processor <NUM> is configured to execute to carry out the methods presented herein. The mobile EC server <NUM> may further comprise or be connected to at least one interface <NUM>, corresponding to interface <NUM> of <FIG>, for communicative control signaling with at least the EC management entity <NUM>, and for communication with UEs <NUM>.

<FIG> describes various steps of different embodiments of a method according to the invention. This relates to method for controlling operation of a mobile first EC server <NUM> configured to provide compute resources to one or more UEs <NUM>, and the method is carried out in the mobile first EC server <NUM>. The mobile first EC server <NUM> is connected to an EC management entity <NUM> configured to manage a plurality of EC servers <NUM>, <NUM>-<NUM>. In a broad context, the method comprises.

Receiving <NUM> status information associated with the first EC server from an external entity.

Determining <NUM> a power state triggering event, based on the received status information.

Controlling <NUM> the power state of the first EC server responsive to the determined power state triggering event.

By means of this method, a mobile EC server <NUM> may be effectively controlled to assume a certain state, or change state, based on relevant information other than just whether or not it is currently used for an application service.

The external entity may for instance include a power source for the mobile EC node <NUM>, such as a power state of a power source <NUM> of a moving node or vehicle <NUM> carrying the mobile EC server <NUM>. The status information may thus for instance be associated with a predefined power state of the mobile first EC server <NUM>.

In some embodiments, the external entity may include a positioning entity <NUM>, and the status information may for example include position information for the mobile first EC server <NUM>, and/or of another EC server <NUM>-<NUM>, and/or of a UE <NUM> running or requesting to run an EC application <NUM>.

In some embodiments, the external entity may include a communication interface <NUM>, such as a radio transceiver, operable by the mobile EC server <NUM> to communicate with one or more of UEs <NUM>, and with the EC management entity and/or other EC servers <NUM>-<NUM> over a communication network. The status information may for example include signal strength level or quality of service QoS parameters, related to such communication.

In various embodiments, the step of determining the triggering event may include applying a location-based rule set, identifying a power state for at least one defined location. The rule set may e.g. include a predetermined power state, such as dormant or active, to a certain location, such as a region or a geofence. In some embodiments, the rule set may be stored in memory storage <NUM> in the mobile EC server <NUM>.

In various embodiments, the method may include receiving <NUM> control information as a message identifying said rule set from the management entity. This message may include location data, and possibly power state information associated with the location data. Alternatively, the message may include location data without identification of power state, whereas the EC server <NUM> is configured to automatically interpret such received location information as associated with a predetermined power state, such as a dormant state.

These embodiments provide distributed decision-making, such that the mobile EC server <NUM> may decide and enter a certain power state without being directly instructed to do so by the EC management entity <NUM>. In such embodiments, the triggering event may thus be determined as a request for the first EC server <NUM> to assume the identified power state based on a position of the first EC server relative to said defined location.

In one variant of such an embodiment, the triggering event is determined as a request for the first EC server <NUM> to assume an active state, responsive to determining that the first EC server <NUM> is present in or enters said defined location, or leaves said location.

In another variant, the triggering event is determined as request for the first EC server <NUM> to assume a dormant state, responsive to determining that no application <NUM> is currently hosted for any UE <NUM> in the first EC server <NUM> and that the first EC server <NUM> is present in or enters said defined location, or leaves said location.

In some embodiments, where the state triggering event is determined as a request for the first EC server to enter a dormant state, the method may further comprise
relocating <NUM> hosting of an EC application for a user of a UE <NUM> to a second EC <NUM>-<NUM>, prior to controlling <NUM> the power state of the first EC server to dormant state.

As opposed to distributed decision-making for setting the power state in the mobile EC server <NUM>, or as a complement to such a solution, the EC server <NUM> may be configured to obtain direct power state control from the EC management entity <NUM>. In such an embodiment, the mobile EC server <NUM> may be configured to.

In some embodiments, the data transmitted <NUM> may thus include information, indication or metric of one or more of the aforementioned types of information for the mobile first EC server <NUM>, such as power or charge level, position or location data, signal strength level or quality of service QoS parameters, EC load level, etc..

In one embodiment, the message may identify a second EC server <NUM>-<NUM> and a request to relocate hosting of an EC application <NUM> for a user of a UE <NUM> between the first <NUM> and second <NUM>-<NUM> EC server.

Specifically, in one embodiment, said message comprises a request to relocate the user of a UE <NUM> to the mobile first EC server <NUM> from the second EC server <NUM>-<NUM>, wherein the power state triggering event is determined as an instruction to enter an active state.

Referring now to <FIG>, corresponding to the embodiments carried out the mobile EC server <NUM>, various embodiments are carried out in the EC management entity <NUM>, configured to manage a plurality of EC servers <NUM>, <NUM>-<NUM>, for handling power states of at least the mobile first EC server <NUM>. Such an embodiment may comprise.

In some embodiments, said message may include a location-based rule set, identifying a power state for at least one defined location. Such an embodiment provides for distributed decision-making, such that the mobile first EC server <NUM> may determined and execute a change of power state without direct execution control by the management entity <NUM>.

In one embodiment, the message may identify a request for the first EC server <NUM> to assume a dormant state, responsive to determining that no application is hosted in the EC server <NUM> for any UE and that the first EC server <NUM> is present in or enters said defined location, or leaves said location.

In various embodiments, the message may identify a second EC server <NUM>-<NUM> and a request to relocate hosting of an EC application <NUM> for a user of a UE <NUM> between the first <NUM> and second <NUM>-<NUM> EC server.

Relocation of hosting may be carried out by the application <NUM> and may include sending user context.

As noted in <FIG>, the method carried out in the management entity may comprise receiving <NUM> data from the mobile first EC server <NUM>, which data is indicative of status information received in the mobile first EC server. The received <NUM> data may include information, indication or metric of one or more of the aforementioned types of information for the mobile first EC server <NUM>, such as power or charge level, position or location data, signal strength level or quality of service QoS parameters, EC load level, etc. In such an embodiment, direct decision-making by the management entity <NUM> may be employed instead of or in addition to distributed decision-making. The management entity <NUM> may thus be configured to transmit <NUM> said message to the mobile first EC server <NUM> based on the received data, so as to control the mobile first server <NUM> to assume a predetermined power state, such as a dormant state or an active state.

Some embodiments will now be described with reference to <FIG> and <FIG> for more specific examples, which fall within the scope discussed above.

Referring to <FIG>, an example of a signaling diagram is shown for various embodiments, where an external entity as mentioned above triggers the mobile EC server <NUM> to assume a certain power state, such as to enter/exit a dormant state. The external entity may for example be one or more of a RAN node, a positioning device <NUM> such as a position estimation unit (e.g. GPS receiver), a power supply device <NUM>, etc. In this example embodiment, the status information includes at least position data related for the present, or a predicted, location of the mobile first EC server <NUM>.

As noted also with reference to <FIG>, control information comprising a rule set <NUM> may be transmitted from the EC management entity <NUM> for receipt <NUM> in the mobile first EC server <NUM>. Alternatively, the rule set may be wholly or at least partly pre-coded in the EC server <NUM>.

Status information including the position data <NUM> is received or obtained in the mobile first EC server <NUM>, such as location (e.g. obtained from GPS) update reporting of the current location obtained from a positioning device <NUM>.

The obtained position, included in or determined from the received status information <NUM>, is compare or correlated with a location data of the rule set <NUM>. In this example the position is determined to correlate with a "sleep" area. A location may e.g. be defined as a sleep area or location based on existence of a stationary EC server <NUM>-<NUM>, or of another mobile EC server, in that area.

Correlation of the obtained position with the rule set is thus interpreted a power state triggering event for the EC server <NUM> to assume or enter <NUM> a dormant state.

The mobile EC server <NUM> sends status data <NUM> to inform the management entity <NUM> that it will enter dormant state.

If the mobile EC server <NUM> is currently providing an application service to a user of a UE <NUM>, the status data <NUM> may initiate a relocation of such a user. This may involve the EC server <NUM> requesting <NUM> the management entity <NUM> or the EC application <NUM> to relocate its users, or the EC management entity controlling the EC server <NUM> to relocate its users. The concept of relocating a user involves relocating user context.

In this example, The EC application <NUM> is controlled from the mobile EC server <NUM> to relocate <NUM> its users to another EC server in the present location area.

Once user context for all application instances in the mobile first EC server <NUM> are relocated, the mobile first EC server <NUM> enters a dormant state <NUM>. In this context, a dormant state may imply shutting off or inactivating resources for computation, while maintaining the possibility to receive status information <NUM>, <NUM>, and possibly control signals from the EC management entity <NUM>, such as paging signals sent through an access node <NUM> of the wireless network.

At some instance, new status information <NUM> is received, indicating a new location. By correlation with the rule set <NUM>, the mobile first EC server <NUM> may thereby be triggered to exit a dormant state <NUM>.

The mobile first EC server <NUM> preferably also sends status data to inform the EC management entity <NUM> of its availability.

The EC management entity <NUM> thus keeps track of EC servers and their availability, both when EC servers <NUM> initiate state switching and informs the EC management as well as by the EC management <NUM> controlled state switching of a mobile EC server <NUM>. This allows e.g. the management system to inform EC servers, such as stationary EC servers <NUM>-<NUM>, when a nearby mobile EC server <NUM>-<NUM> wakes up and becomes available.

<FIG> shows another example embodiment, which provides a specific example which is also usable for understanding other broader elements of the invention as outlined. In this scenario, a mobile EC server <NUM> carried in a moving node or vehicle <NUM> is present in a cell where there is an access node <NUM> which has a connected stationary or static EC server <NUM>-<NUM>. This stationary EC server <NUM>-<NUM> is typically a high capacity EC server, e.g. configured as a MEC host. Some users may be relocated from the stationary EC server <NUM>-<NUM> to the mobile EC server <NUM>, and vice versa, depending on status information such as battery status of power supply <NUM>, location (and mobility) of the mobile first EC server <NUM>.

<FIG> illustrates a signaling diagram illustrating the mechanism of changing of the power state of mobile EC server <NUM> from dormant to active and also the process of relocating of UEs. This represents a scenario wherein UEs <NUM>-<NUM> and the mobile EC server <NUM> are moving together, e.g. same car/train, and both are relatively moving away from the stationary EC server <NUM>-<NUM>.

In the example of <FIG>, a user is running <NUM> an application using an EC application service <NUM> to support the user's in UE <NUM>-<NUM>. The user is in or near a vehicle <NUM>. Even though the vehicle <NUM> incorporates a mobile first EC server <NUM>, the EC system <NUM> may be configured to promote use of the stationary EC server <NUM>-<NUM> at least as long as there is no movement of the mobile first EC server <NUM>, since the stationary EC server <NUM>-<NUM> normally has higher capacity and is nevertheless less affected by power consumption.

The mobile EC server <NUM> may provide status information <NUM> to the EC management entity <NUM>, either upon request by the EC management entity <NUM> or repetitively with a certain period. The status information may e.g. indicate position, battery level, load (such as number of IP connections) etc. of the mobile EC server <NUM>. In the example embodiment, the mobile EC server <NUM> is in a dormant state <NUM>.

The EC management entity be configured to send an availability report (not shown) to the mobile EC server <NUM>, and potentially also to the stationary EC server <NUM>-<NUM>, when it is determined that they are present in a common area, so as to inform the EC servers of their present co-location.

At some point, the user is or starts travelling in the vehicle <NUM>, which causes obtainment of status information including position data. The position information may be obtained using a position estimation unit (e.g. GPS receiver) in the user's UE <NUM>-<NUM>. The UE <NUM>-<NUM> transmits a position report <NUM> to the stationary EC server <NUM>-<NUM> to which it is connected. This may be carried out on request by the serving EC server <NUM>-<NUM>, or triggered by detection of movement in the served UE <NUM>-<NUM>.

The stationary EC server <NUM>-<NUM> provides status data <NUM> to the EC management entity <NUM>, which status data indicates the mobility of the UE <NUM>-<NUM>. The status report may include raw data received from the UE <NUM>-<NUM>, or data processed in the stationary EC server <NUM>-<NUM> to indicate more specific or detailed information.

Based on the status data <NUM> associated with the UE <NUM>-<NUM> of the user running an EC application in the stationary EC server <NUM>-<NUM>, and on received status information <NUM>, the EC management entity may determine that the UE <NUM>-<NUM> and the mobile EC server <NUM> are moving substantially in the same direction and with a common speed, indicating that they are carried in a common vehicle <NUM>. This may cause the EC management entity <NUM> to initiate relocation of the user of UE <NUM>-<NUM>.

The EC management entity <NUM> may transmit a host request <NUM> to the mobile EC server <NUM>. This may indicate or be interpreted in the mobile EC server <NUM>, as a request to exit the dormant state. The host request <NUM> may also indicate requirements of the UE <NUM>-<NUM> with regard to the application <NUM> it is running in the stationary EC server <NUM>-<NUM>. At least in a case where the mobile EC server <NUM> is already in an active state, the host request <NUM> may include a request for the mobile EC server <NUM> to indicate present capacity information, such as number of currently served users, a degree of used available compute resources, power level etc..

The mobile EC server may thus be triggered to report back with a status report <NUM>, and may thereby be triggered to exit, or prepare for exit of, the dormant state.

The availability of the mobile EC server <NUM> to take over hosting of the application for the user of UE <NUM>-<NUM> may then be reported <NUM> from the EC management entity <NUM> to the serving EC server <NUM>-<NUM>. This availability reporting may also involve an instruction to initiate relocation <NUM> of the user of UE <NUM>-<NUM>.

The mobile EC server <NUM> is then, if not already, set into an active state <NUM>, and is thereafter acting as serving host for running <NUM> the application <NUM>.

The proposed embodiments provide a central coordinated function for handling power states of a mobile EC server. In various embodiments, triggering for different power states is based on the following items its own power supply conditions and on location of a mobile EC server relative to any other mobile/stationary EC servers. The mobile EC server may be configured or have access to a database with sleep areas. One example of such implementation could be a managed server, which may be connected to the EC management entity <NUM>, which indicates the edge computing relative needs in different geographical areas. This may as one example be implemented by specifically indicating certain sleep areas where mobile EC servers are not required to operate. These sleep areas for example could already be served by known stationary EC servers. Another alternative is that strong computing need in a specific area may trigger the mobile EC server to wake up.

Claim 1:
A method for controlling operation of a mobile first Edge Computing, EC, server (<NUM>) configured to provide compute resources to User Equipment, UE, (<NUM>), wherein the first EC server is connected to an EC management entity (<NUM>) configured to manage a plurality of EC servers (<NUM>, <NUM>-<NUM>), the method being carried out in the first EC server and comprising:
receiving (<NUM>) status information associated with the first EC server from an external entity, wherein said status information includes position data related to present or predicted location of the first EC server;
receiving (<NUM>,<NUM>) control information from the EC management entity, said control information identifying a power state control instruction;
determining (<NUM>) a power state triggering event in accordance with the power state control instruction, based on the received status information;
controlling (<NUM>) the power state of the first EC server responsive to the determined power state triggering event, comprising assuming a predetermined power state based on said status information.