EP4740574A1

EP4740574A1 - Methods for mobility management of compute activity offloading in mobile communications

Info

Publication number: EP4740574A1
Application number: EP24835214.8A
Authority: EP
Inventors: Nathan Edward Tenny; Mehrdad Shariat
Original assignee: Mediatek Inc; MediaTek Inc
Current assignee: Mediatek Inc; MediaTek Inc
Priority date: 2023-07-05
Filing date: 2024-06-17
Publication date: 2026-05-13
Also published as: WO2025007731A1; CN121444529A

Abstract

Various solutions for mobility management of compute activity offloading in mobile communications are described. An apparatus hosting a composition management function (CMF) may transmit a relocation indication to a source compute server function (CSF). The relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. The apparatus may receive a confirmation indication from the source CSF or the target CSF. The confirmation indication indicates that the relocation of the compute offload point is completed. The apparatus may transmit a first instruction to the client device. The first instruction indicates a transfer of a compute offload activity of the client device from the source CSF to the target CSF.

Description

METHODS FOR MOBILITY MANAGEMENT OF COMPUTE ACTIVITY OFFLOADING IN MOBILE COMMUNICATIONS

CROSS REFERENCE TO RELATED PATENT APPLICATION (S)
The present disclosure is part of a non-provisional application claiming the priority benefit of U.S. Provisional Patent Application No. 63/511,912, filed 5 July 2023, the content of which herein being incorporated by reference in its entirety.

TECHNICAL FIELD

The present disclosure is generally related to mobile communications and, more particularly, to mobility management of compute activity offloading in mobile communications.

BACKGROUND

Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.
In a mobile communication environment, a mobile device such as a user equipment (UE) may be provided with radio connectivity by one or more radio nodes. The radio nodes may include base station (s) (BS) of a wireless network, and/or peer mobile device (s) (e.g., other UEs) . The radio nodes may provide connectivity for the mobile device to obtain mobile services, including services offered by an operator’s network (which may include a radio access network (RAN) and/or a core network (CN) ) , services offered by remote network nodes such as Internet nodes or servers in a cloud environment, and/or services offered by one or more peer devices. In some cases, services offered to the mobile device may be computationally demanding, and there are diverse circumstances in which it is beneficial for the mobile device to be able to offload some compute activities/tasks to other nodes in the wireless system. Such nodes with the capacity to accept offloaded compute activity may be referred to as compute servers, and the mobile device may be referred to as a client device. Each compute server may include an actual server (e.g., a computational engine that performs offloaded tasks) as well as logically separate aspects such as a function that exposes an interface between the server and the wireless system (i.e., such a function may serve as a communication point between the server and the wireless system.
For example, the mobile device may operate a user-facing service with computational demands that exceed what the mobile device can provide efficiently due to various reasons, such as the limitations in the compute power and/or battery reserves of the mobile device, the user preference, and/or the network policy on compute offload preferences, etc. Some parts of the service may require very low-latency computation, giving rise to tasks that should be performed at a node topologically close to the mobile device, such as a server located at a distributed unit (DU) of the BS serving the mobile device, or another device (e.g., a peer device) with a direct radio link (e.g., sidelink (SL) ) to the mobile device. Some parts of the service may give rise to tasks that are computationally demanding but less latency-sensitive, which may be performed at a node topologically further from the mobile device but having high computational capabilities, such as a server located at a centralized unit (CU) of the BS serving the mobile device, or a server in the CN, etc. Some parts of the service may require computation that can conveniently be performed by the mobile device itself without offloading, while other parts of the service may benefit from computation at a central location such as a server in the cloud. That is to say, a single service may involve compute tasks that can productively be performed at diverse locations throughout the system.
However, a challenge for compute activity offloading is that in case of occurrence of a mobility event associated with the client device’s radio connection (e.g., a handover of the client device from one radio node to another) , there may need proper coordination of the compute offload activities among compute servers.

SUMMARY

The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.
One objective of the present disclosure is proposing schemes, concepts, designs, systems, methods and/or apparatus pertaining to mobility management of compute activity offloading in mobile communications. It is believed that the above-described issue would be avoided or otherwise alleviated by implementing one or more of the proposed schemes described herein.
In one aspect, a method may involve an apparatus, which hosts a composition management function (CMF) , transmitting a relocation indication to a source compute server function (CSF) , wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. The method may also involve the apparatus receiving a confirmation indication from the source CSF or the target CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed. The method may further involve the apparatus transmitting a first instruction to the client device, wherein the first instruction indicates a transfer of a compute offload activity of the client device from the source CSF to the target CSF.
In one aspect, a method may involve an apparatus, which hosts a CSF, receiving a relocation indication from a CMF in an event that the CSF is a source CSF, wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. The method may also involve the apparatus transmitting a confirmation indication to the CMF in an event that the CSF is the source CSF or the targe CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed.
In one aspect, a method may involve a client device transmitting a compute offload activity to a source CSF. The method may also involve the client device receiving a first instruction from a CMF, wherein the first instruction indicates a transfer of the compute offload activity from the source CSF to a target CSF.
It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as Long-Term Evolution (LTE) , LTE-Advanced, LTE-Advanced Pro, 5th Generation (5G) , New Radio (NR) , Internet-of-Things (IoT) and Narrow Band Internet of Things (NB-IoT) , Industrial Internet of Things (IIoT) , beyond 5G (B5G) , and 6th Generation (6G) , the proposed concepts, schemes and any variation (s) /derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies. Thus, the scope of the present disclosure is not limited to the examples described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation in order to clearly illustrate the concept of the present disclosure.
FIG. 1 is a diagram depicting an example scenario of a wireless system in which various solutions and schemes in accordance with the present disclosure may be implemented.
FIG. 2 is a diagram depicting an example scenario of a user-plane-based architecture for compute activity offloading in accordance with an implementation of the present disclosure.
FIG. 3 is a diagram depicting an example scenario of a control-plane-based architecture for compute activity offloading in accordance with an implementation of the present disclosure.
FIG. 4 is a diagram depicting an example scenario of control protocols used among a client device, a CMF, and a CSF in accordance with an implementation of the present disclosure.
FIG. 5 is a diagram depicting an example scenario of a wireless system in which a CMF and a CSF are located at mobile devices in accordance with an implementation of the present disclosure.
FIG. 6 is a diagram depicting an example scenario of a mobility event of a client device between two radio nodes of a wireless network in accordance with an implementation of the present disclosure.
FIG. 7 is a diagram depicting an example scenario of a mobility event along with a transfer of compute offload activity in accordance with an implementation of the present disclosure.
FIG. 8 is a diagram depicting an example scenario of a mobility event followed by a relocation of the compute offload point in accordance with an implementation of the present disclosure.
FIG. 9 is a diagram depicting an example scenario of a message sequence chart for a relocation of the compute offload point in accordance with an implementation of the present disclosure.
FIG. 10 is a diagram depicting an example scenario of a message sequence chart for a relocation of the compute offload point in accordance with an implementation of the present disclosure.
FIG. 11 is a diagram depicting an example scenario of extensions upon the procedure of FIG. 10 to incorporate the ability to process tasks at both CSF A and CSF B during a transitional period in accordance with an implementation of the present disclosure.
FIG. 12 is a diagram depicting an example scenario of an alternative approach to the context synchronization problem of FIG. 11 in accordance with an implementation of the present disclosure.
FIG. 13 is a diagram depicting an example scenario of a message sequence chart for compute activity offloading between two CSFs in accordance with an implementation of the present disclosure.
FIG. 14 is a block diagram of an example communication system in accordance with an implementation of the present disclosure.
FIG. 15 is a flowchart of an example process in accordance with an implementation of the present disclosure.
FIG. 16 is a flowchart of another example process in accordance with an implementation of the present disclosure.
FIG. 17 is a flowchart of another example process in accordance with an implementation of the present disclosure.
DETAILED DESCRIPTION OF PREFERRED IMPLEMENTATIONS
Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.
Overview
Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and/or solutions pertaining to mobility management of compute activity offloading in mobile communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another.
To coordinate the distribution of compute activities/tasks among compute servers, the mobile device may behave as a client of a function that manages compute resources throughout a portion of the system, and such a function may be referred to as a CMF and the mobile device may be referred to as a client device. For example, the CMF may be embodied in a network node, a second device, or the client device itself, etc. A CMF may also be considered as a compute control node, an orchestrator of compute activities, or a manager of compute resources, etc. The client device may communicate with the CMF via a control protocol or an application programming interface (API) , e.g., to support behaviors such as registration of the client device with the CMF, association of compute resources with a CSF, allocation of compute activity to a suitable CSF, and so on. In one example, a client device may communicate with a plurality of CMFs, which may be instantiated in different locations throughout the system, with each CMF brokering access to compute resources at a set of CSFs.
The actual delivery of compute tasks to the CSFs (and hence to the servers they represent) and the delivery of compute results back to the client device may be carried out over various transport layers. In some embodiments, a CSF may be a termination point of a data session, and the compute task image and/or associated data for computation may be represented by user-plane data. In some embodiments, a CSF may be considered as a control-plane node, and the compute task image and/or associated data for computation may be carried in a control-plane protocol which may be represented as, e.g., a protocol on a reference point between nodes, or as an API of a service-based interface (SBI) . In some embodiments, the communication between the client device and the CSF (s) may be modelled as a “compute plane” that provides a data connection between the client device and the CSF without anchoring to any external data network. These different embodiments may nonetheless admit a common transaction structure, in which the client device issues a computation request to a CSF and receives a computation result. For purposes of this discussion, we abstract the communication between the client device and the CSF to be represented by a compute offload protocol (COP) , including at least a task offload request message and a task offload response message, but it should be understood that alternative models of communicating substantially similar information between the endpoints can be considered as equivalent.
In view of that a mobility event (e.g., a handover of the client device from one radio node to another) may occur during the operations of compute activity offloading, the present disclosure proposes a number of schemes pertaining to mobility management of compute activity offloading in mobile communications.
Under a first proposed scheme of the present disclosure, a CMF may transmit a relocation indication to a source CSF (e.g., a server/CSF associated with the source radio node of the handover) . The relocation indication indicates a relocation of a compute offload point associated with the client device from the source CSF to a target CSF (e.g., the server/CSF associated with the target radio node of the handover) . Then, the CMF may receive a confirmation indication from the source CSF or the target CSF. The confirmation indication indicates that the relocation of the compute offload point is completed. After that, the CMF may transmit a first instruction to the client device. The first instruction indicates a transfer of a compute offload activity of the client device from the source CSF to the target CSF.
In some implementations, the CMF may determine whether to trigger the transmission of the relocation indication based on at least one of the following: (i) a performance monitoring of the compute offload activity between the client device and the source CSF; (ii) a load balancing between the source CSF and the target CSF; and (iii) a mobility event associated with a radio connection of the client device.
In some implementations, the CMF may receive an acknowledgement of the first instruction from the client device.
In some implementations, the CMF may transmit an admission query to the target CSF, wherein the admission query indicates a request for admission of the compute offload activity of the client device. Additionally, the CMF may receive an admission confirmation from the target CSF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
In some implementations, the CMF may transmit a release indication to the source CSF, wherein the release indication indicates the source CSF to release a compute context of the client device.
In some implementations, the CMF may transmit a second instruction to the client device, wherein the second instruction indicates the client device to transmit the compute offload activity to the target CSF.
In some implementations, the apparatus hosting the CMF may include a network node or a mobile device.
Under a second proposed scheme of the present disclosure, a source CSF may receive a relocation indication from a CMF, wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. Then, the source/target CSF may transmit a confirmation indication to the CMF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed.
In some implementations, the target CSF may receive an admission query from the CMF, wherein the admission query indicates a request for admission of the compute offload activity of the client device. Additionally, the target CSF may transmit an admission confirmation to the CMF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
In some implementations, the source CSF may receive a release indication from the CMF, wherein the release indication indicates the source CSF to release a compute context of the client device.
In some implementations, the target CSF may receive a compute context of the client device from the source CSF, and transmit an acceptance indication of the compute context to the source CSF.
In some implementations, the source CSF may receive a compute offload activity of the client device from the client device, forward a copy of the compute offload activity to the target CSF, and transmit a result of the compute offload activity to the client device.
In some implementations, the target CSF may receive a compute offload activity of the client device from the client device and transmit a result of the compute offload activity to the client device.
In some implementations, the result of the compute offload activity from the source CSF may be transmitted via a first radio node, the result of the compute offload activity from the target CSF may be transmitted via a second radio node, and the transmissions of the result of the compute offload activity may be scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.
In some implementations, the apparatus hosting the source/target CSF may include a network node or a mobile device.
Under a third proposed scheme of the present disclosure, the client device may transmit the compute offload activity to the source CSF. Then, the client device may receive the first instruction from the CMF, wherein the first instruction indicates the transfer of the compute offload activity from the source CSF to the target CSF.
In some implementations, the client device may transmit an acknowledgement of the first instruction to the CMF.
In some implementations, the client device may receive a second instruction from the CMF, wherein the second instruction indicates the client device to transmit the compute offload activity to the target CSF, and the first instruction includes an instruction to stop transmitting the compute offload activity to the source CSF.
In some implementations, the client device may receive a result of the compute offload activity from at least one of the source CSF and the target CSF.
In some implementations, the result of the compute offload activity from the source CSF may be received via a first radio node, the result of the compute offload activity from the target CSF may be received via a second radio node, and the transmissions of the result of the compute offload activity may be scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.
Accordingly, by applying the schemes of the present disclosure, coordination of compute offload activities among compute servers may be realized to facilitate the relocation of compute offload point (along with the transfer of compute offload activity between compute servers) , such that the operations of compute activity offloading may be well adapted to handle the occurrence of mobility event.
FIG. 1 illustrates an example scenario 100 of a wireless system in which various solutions and schemes in accordance with the present disclosure may be implemented. The wireless system involves a variety of mobile devices, radio nodes, and compute nodes. The mobile devices include a cluster of devices in radio communication with one another (the links labelled 0 in FIG. 1) and in radio communication with a set of (radio) nodes (the link labelled 1 in FIG. 1, which may represent, e.g., a Uu interface of a cellular system, or an airlink of a wireless-fidelity (Wi-Fi) system, etc. ) . The mobile devices and (radio) nodes are shown as constituent parts of a “hyperlocal cloud” , e.g., a network of nodes in communication in an “edge of the network” region where communication does not depend on traversing a core network, an external packet data network (e.g., the Internet) , or the like. The hyperlocal cloud includes an example of a client device (location A in FIG. 1) and at least one peer device capable of offering compute services and accepting offload of compute activities (location B in FIG. 1) , as well as a multi-access edge computing (MEC) node (location C in FIG. 1) that supports compute services and accepts offload of compute activities. In one example, the MEC node may be a non-radio node (i.e., such a node does not provide radio communication) and it may be collocated or near-collocated with a BS/DU. In addition, the wireless system involves a core network (location D in FIG. 1) and an external packet data network (PDN) (location E in FIG. 1) , either or both of which may include one or more compute nodes that supports compute services and accepts offload of compute activities. The client device A may take part in the distribution of compute activities to any combination of locations A, B, C, D, and/or E. The distribution of compute tasks may be under the control of one or more CMFs, which are not shown in FIG. 1, but which may be instantiated singly or multiply at various locations throughout the system.
FIG. 2 illustrates an example scenario 200 of a user-plane-based architecture for compute activity offloading in accordance with an implementation of the present disclosure. In one example, such user-plane-based architecture for compute activity offloading may be applied in a wireless system (e.g., a 6G cellular system) . Scenario 200 involves a client device (e.g., a UE) exchanging user-plane (UP) traffic and/or control signaling with a DU of a BS. The DU is in correspondence with a CU, which may be disaggregated into a UP part (CU-UP) and a control-plane (CP) part (CU-CP) . The DU is further connected to a hyperlocal-user plane function (HL-UPF) which serves as an anchor for the transfer of UP traffic to one or more destinations (e.g., compute servers) within an HL cloud. The DU may be connected to the HL-UPF via a “short” GPRS tunnelling protocol-user (GTP-U) tunnel which is “short” in the sense that it traverses a comparatively small distance in terms of the network topology. That is, the HL-UPF is instantiated in a location close to the DU. In addition, the CU-UP may be connected to a UPF which serves as an anchor for the transfer of UP traffic to one or more destinations (e.g., compute servers) outside the HL cloud (for example, in an external PDN) . The CU-UP may be connected to the UPF via a “long” GTP-U tunnel, i.e., a tunnel that traverses a comparatively large distance (larger than the “short” GTP-U tunnel described previously) in the network topology. In this example, the CU-CP is shown as connected to a CMF with control signaling carried between the client device and the CMF in a manner described as “fast NAS” , by analogy with the non-access stratum (NAS) protocols carried in various cellular systems between a UE and a control node in the network. The CMF protocol, which may, for instance, be a compute control protocol (CCP) , is “fast” in the sense that it is delivered to a CMF location relatively close to the CU-CP, without depending on traversing additional interfaces to the CN, but similar to NAS in that it may be realized as an end-to-end protocol above one or more access stratum (AS) protocols such as a radio resource control (RRC) protocol. It should be noted that other locations for the CMF are possible. For example, a CMF may be collocated with a DU, or a peer device, etc., and FIG. 2 illustrates only one possible variant of the architecture.
FIG. 3 illustrates an example scenario 300 of a control-plane-based architecture for compute activity offloading in accordance with an implementation of the present disclosure. In one example, such control-plane-based architecture for compute activity offloading may be applied in a wireless system (e.g., a 6G cellular system) . Scenario 300 involves a client device (e.g., a UE) exchanging control signaling with a DU of a BS. The DU is connected to an HL server offering compute services within an HL cloud. The DU is further connected to a CU-CP of the BS, which offers connectivity to a local server offering compute services outside the HL cloud. In this example, the DU is connected directly to a CMF, suggesting that control signaling is carried between the client and the CMF with only the DU as an intermediary, e.g., without traversing the CU-CP. This routing for control signaling may be achieved by various protocol architectures. In addition, it should be noted that other locations for the CMF are possible. For example, a CMF may be collocated with a CU-CP, or a peer device, etc., and FIG. 3 illustrates only one possible variant of the architecture. While scenario 300 is described here in terms of the control plane, it should be appreciated that substantially the same architecture may be modelled wholly or partly in terms of a separate “compute plane” . That is, the communication between the client device and the CMF, and/or between the client device and the CSF, may be considered as being carried over a separate type of “compute bearer” .
FIG. 4 illustrates an example scenario 400 of control protocols used among a client device, a CMF, and a CSF in accordance with an implementation of the present disclosure. Scenario 400 involves a client device communicating with a CMF using a CCP, the client device communicating with a CSF using a COP, and the CMF communicating with the CSF using a compute management protocol (CMP) . It should be understood that the protocols shown are abstractions of a set of functions that may be invoked by messages or transactions of a control protocol, invocations of an API, or others.
FIG. 5 illustrates an example scenario 500 of a wireless system in which a CMF and a CSF are located at mobile devices in accordance with an implementation of the present disclosure. Scenario 500 involves UE 1 being the client device running an application that benefits from compute activity offloading. More specifically, UE 1 has direct radio links with UE 2 which hosts a CMF, and with UE 3 which hosts a CSF. These direct radio links may use any of a variety of communication technologies, such as a cellular sidelink (also known as a PC5 interface) or a cellular short-range communication link, a device-to-device Wi-Fi technology, or Bluetooth technology, etc. The protocols used between the devices for compute activity management and offloading may resemble those of FIG. 4. For example, UE 1 may communicate with UE 2 using a CCP, UE 1 may communicate with UE 3 using a COP, and UE 2 may communicate with UE 3 using a CMP. The transactions or operations of the respective protocols may be similar to those in the network-based cases previously illustrated, so that, for instance, a client device may communicate by exchanging a particular protocol with a CMF, without regard to whether the CMF is hosted in a UE, a DU, a CU, or some other node of the system. It should be appreciated that one or more CMFs and/or one or more CSFs, instantiated at a mix of network nodes and mobile devices, may interoperate in a variety of configurations beyond those shown in the figures. For example, a CMF may be located at a network node and support compute offload activity among a client device and a set of CSFs that may be located at network nodes and/or mobile devices. Similarly, a CMF may be located at a mobile device and support compute offload activity among a client device and a set of CSFs that may be located at network nodes and/or mobile devices.
FIG. 6 illustrates an example scenario 600 of a mobility event of a client device between two radio nodes of a wireless network in accordance with an implementation of the present disclosure. Scenario 600 involves a UE being initially served over a radio interface by radio node X, and due to changes of radio conditions, decisions of the network, or other factors, the UE is transferred by a handover or mobility process to a radio node Y. The radio node X hosts CSF A, and the radio node Y hosts CSF B. Before the mobility event, the UE has a direct radio connection with the radio node X, which can be used to communicate with CSF A, such that the UE may offload some latency-sensitive compute activities/tasks to CSF A, as compared to other CSFs located at more distant points of the system. After the mobility event, the UE’s direct radio connection is with the radio node Y, which may not have direct access to CSF A and/or may be topologically distant from CSF A, and thus, it may be preferable for the UE to offload compute activity to CSF B rather than CSF A or other more distant CSFs. In some embodiments, the radio nodes X and Y may have a direct interface between them. For example, if the radio nodes X and Y are CUs of different BSs in a cellular network, they may be connected by an inter-BS interface (such as an Xn interface in a 5G cellular system) . In other embodiments, the radio nodes X and Y may not be directly connected to one another and may need to rely on other nodes to support any needed communication between them.
FIG. 7 illustrates an example scenario 700 of a mobility event along with a transfer of compute offload activity in accordance with an implementation of the present disclosure. Scenario 700 involves a client device (e.g., a UE) communicating with either a radio node X associated with a CSF A, or a radio node Y associated with a CSF B, depending on the change of radio conditions as the UE moves towards or away from the radio node X/Y. In step 701, the UE is served by the radio node X hosting CSF A, and the UE may offload one or more compute activities/tasks to CSF A over the direct link between the UE and the radio node X. Then, after step 701, a radio handover (denoted as “Radio HO” in FIG. 7) occurs, transferring the UE’s radio connectivity to the radio node Y. After the radio handover, in step 702, the UE is served by the radio node Y, but its compute offload activity is still anchored at CSF A, as shown by the connector in step 702. This topology implies that it is possible for a control protocol (e.g., COP) , invocations of an API, and/or user-plane traffic for compute activity offloading to be routed between the UE and CSF A via the radio node Y. It is noted that this routing may be inferior in performance when compared to using a CSF located at the radio node Y itself, because the communication between the UE and CSF A must traverse at least one additional hop compared to communication between the UE and CSF B. Next, in step 703, the routing for compute activity offloading switches to CSF B (located at the radio node Y) , and the UE is again anchored for compute activity offloading at the same node that serves its radio connection. It should be appreciated that FIG. 7 does not embed an assumption about whether compute activity offloading takes place over the user plane, the control plane, or a new “compute plane” , and it is only necessary that the UE be able to communicate with the CSFs over an airlink via some communication model. Similarly, there is no assumption about whether offload operations are brokered by a protocol on a reference point, an API on an SBI, routing of user-plane traffic, or other means.
FIG. 8 illustrates an example scenario 800 of a mobility event followed by a relocation of the compute offload point in accordance with an implementation of the present disclosure. Scenario 800 involves a client device (e.g., a UE) communicating with either a radio node X associated with a CSF A, or a radio node Y associated with a CSF B, depending on the change of radio conditions as the UE moves towards or away from the radio node X/Y. In step 801, the UE performs compute activity offloading with CSF A which is associated with (e.g., collocated with) the radio node X. Between step 801 and step 802, a mobility event occurs to transfer the UE’s radio connectivity to the radio node Y, wherein the mobility event may be a handover between BSs, an inter-DU mobility procedure, a lower-layer-triggered mobility procedure, or a path switch between peer mobile devices, etc. The mobility event may occur without affecting the location of compute activity offloading, resulting in the arrow shown in step 802, in which the UE continues to perform compute activity offloading with CSF A, even though the UE is now served by the radio node Y. It is noted that CSF B, which is associated with (e.g., collocated with) the radio node Y, may be more advantageously positioned than CSF A for the UE’s compute activity offloading. However, the compute offload point may be under the control of a CMF rather than directly linked to the client’s radio service. In step 803, the CMF determines to relocate the compute offload point and triggers the start of a relocation procedure, for example, by communicating with CSF A, which currently hosts the client’s compute offload. The determination of relocating the compute offload point may be based on at least one of the following factors: (i) quality of service (QoS) monitoring of the performance of a service that utilizes the compute activity offloading mechanism, (ii) load balancing between CSFs, (iii) the mobility event associated with the client’s radio connection, and (iv) criteria determined by the CMF implementation, etc. In step 804, the CMF triggers the completion of the relocation preparation, for example, by communicating with CSF B and inducing CSF B to begin hosting the client’s compute offload. In step 805, CSF A and CSF B may optionally communicate with each other to facilitate the relocation process, e.g., to transfer a context of the compute offload activity from CSF A to CSF B. More specifically, if step 805 occurs, it may take place over an inter-CSF interface, or it may be factored through one or more additional nodes such as the radio nodes X and Y, the CMF, or others. In one example, step 805 may occur through communication between the radio nodes X and Y over an inter-radio-node interface (e.g., if the radio nodes X and Y are UEs, step 805 may occur over a UE-to-UE radio interface, and if the radio nodes X and Y are network nodes, they may be connected by a direct interface, through a third node, etc. ) . In another example, step 805 may occur through communication between CSFs A and B and the CMF. In some embodiments, the service for which computation is being performed may have no context requirements, and communication between the CSFs may be unnecessary, i.e., step 805 may not occur. In step 806, the UE continues compute activity offloading, now with CSF B associated with the radio node Y.
FIG. 9 illustrates an example scenario 900 of a message sequence chart for a relocation of the compute offload point in accordance with an implementation of the present disclosure. Scenario 900 depicts a message flow for a relocation operation similar to the one described in FIG. 8. In step 901, a client device (e.g., a UE) is initially in radio service with a radio node X (not shown in FIG. 9) associated with (e.g., collocated with) CSF A. In step 902, the client device performs compute activity offloading with CSF A. It is noted that a CMF may monitor the performance of the compute offload activity, by applying, e.g., QoS criteria for the required compute performance. In step 903, the client device experiences a mobility event which triggers a transfer of the client’s radio connectivity to a radio node Y (not shown in FIG. 9) associated with CSF B. Each of the radio nodes X and Y may be a network node (e.g., a BS, a CU or DU of a BS, or the like) , a mobile device (e.g., a UE) , or any other type of node capable of providing radio service to the client device. In step 904, given that the client device has not received any indication that it should transfer the destination of its compute offload activity, the client device continues compute activity offloading with CSF A, but now via the radio node Y. In step 905, the CMF takes the determination/decision (e.g., based on QoS criteria, evaluation of compute performance, load balancing, or implementation-dependent criteria in the CMF, etc. ) to relocate the client’s compute offload service from CSF A to CSF B. In step 906, the CMF indicates to CSF A that it should release the client device’s compute offload activity, e.g., to allow the compute offload activity to be transferred to CSF B. In step 907, the compute offload activity (or called compute service) is transferred from CSF A to CSF B. It should be understood that in FIG. 9, step 907 is shown as an optional direct communication between CSFs A and B, but as noted previously, it may be realized in several different ways, such as communication via the radio nodes X and Y, or communication via the CMF, etc. Additionally, or optionally, step 907 may further include admission of the client device to compute offload service with CSF B, and a request to CSF B to start accepting compute offload activities from the client device, etc., and the details of this step will be further explored below. In step 908, CSF A indicates to the CMF that it has released the client device’s compute offload activity, and this indication may be understood to mean that the relocation of compute offload point is complete and the compute offload activity between the client device and CSF B can begin. In step 909, the CMF instructs the client device to begin compute offload activity with CSF B, and this instruction may also include, or be accompanied by, an instruction to stop the compute offload activity with CSF A. In one example, the relocation instruction in step 909 may be a message of a CCP or an invocation of an API between the client device and the CMF. In step 910, the client device optionally acknowledges the reception of the relocation instruction to the CMF. It should be understood that step 910 may not be necessary in all embodiments, but it allows the CMF to confirm that the client device has received and executed the relocation instruction. In one example, step 910 may be performed as an aspect of reliable transport for a protocol (e.g., CCP) between the client device and the CMF. In one example, the relocation instruction in step 910 may be a response to an invocation of an API between the client device and the CMF. In step 911, the client device performs compute activity offloading with CSF B via the radio node Y. It is noted that monitoring of compute offload activity by the CMF may continue during and after step 911, allowing the CMF to evaluate whether the compute offload service is performed according to requirements, for example.
FIG. 10 illustrates an example scenario 1000 of a message sequence chart for a relocation of the compute offload point in accordance with an implementation of the present disclosure. Scenario 1000 depicts the details of the interactions between a CMF, a source CSF (e.g., CSF A) , and a target CSF (e.g., CSF B) for the transfer of a compute offload activity, corresponding to steps 905-908 of FIG. 9. FIG. 10 may be seen as an expansion of the steps of FIG. 9, filling in potential additional details of the high-level procedure. In step 1001, CSF A is supporting the compute offload activity for the client device (not shown in FIG. 10) . In step 1002, the CMF takes the determination to relocate the compute offload point from CSF A to CSF B. As described previously in FIG. 9, this determination may be motivated by a variety of criteria, such as QoS monitoring, compute performance, a mobility event, load balancing, and/or criteria dependent on the CMF implementation, etc. In step 1003, the CMF transmits an admission query to CSF B to make sure if CSF B can accept the additional compute offload activity of the client device. In step 1004, CSF B transmits an admission confirmation to the CMF, indicating that it can accept the additional compute offload activity of the client device. In step 1005, the CMF transmits a relocation indication to CSF A, instructing CSF A to release the compute resources that are reserved for the client device, and potentially to transfer any compute context to CSF B. In step 1006, CSF A optionally transfers the compute context of the client device to CSF B, as described above. In step 1007, CSF B establishes a local compute context for the client device, which may include, e.g., reserving compute resources at the compute server represented by CSF B for the use of the client device. In step 1008, CSF B optionally indicates acceptance of the compute context that was transferred in step 1006. In step 1009, CSF B confirms to the CMF that the establishment of the client device’s compute context at CSF B (potentially by transfer from CSF A) is successful and CSF B is ready to accept compute offload activity from the client device. Alternatively, step 1009 may be replaced by a confirmation message from CSF A, indicating to the CMF that the relocation of the compute offload point from CSF A to CSF B (and potentially the transfer of the compute offload activity and the compute context from CSF A to CSF B) is successful.
FIG. 11 illustrates an example scenario 1100 of extensions upon the procedure of FIG. 10 to incorporate the ability to process tasks at both CSF A and CSF B during a transitional period in accordance with an implementation of the present disclosure. This scenario may depend, for example, on maintaining two copies of a computational context for the task (s) , one copy at CSF A and the other copy at CSF B. Scenario 1100 depicts a message flow of the extensions upon the procedure of FIG. 10, with the objective of keeping the two copies of the computational context synchronized. FIG. 11 begins with step 1105 (equivalent to step 1005 of FIG. 10) . Steps 1105-1109 are the same as steps 1005-1009 in FIG. 10, steps 1110-1113 are additional steps beyond those shown in FIG. 10, and steps A to D constitute an asynchronous procedure for duplicating a compute task between CSFs A and B. In step 1105, the CMF transmits a relocation instruction to CSF A, instructing CSF A to trigger relocation of compute offload point to CSF B, which may, e.g., include transferring the compute context of the client device to CSF B. For the purpose of illustration, we assume that context maintenance and transfer for the compute service are required, and thus, in step 1106, CSF A transfers the compute context to CSF B. In step 1107, CSF B uses the transferred information to establish a compute context for the client device. Alternatively, if a compute context is not required for the compute activity being offloaded, steps 1106 and 1107 may not occur. In step A (which may occur asynchronously with respect to the numbered steps) , the client device delivers a compute activity/task for processing to CSF A (it should be noted that from the client’s perspective, its offloading configuration has not been updated and it is still configured to offload compute activities/tasks to CSF A) . As shown in FIG. 11, step A may occur before step 1108, and at the time of step A, CSF A does not know if CSF B will accept the transfer of compute context. As such, CSF A may buffer one or more compute activities/tasks to be forwarded to CSF B after step 1108. In step 1108, CSF B accepts the transfer of context from CSF A. In step B, CSF A forwards to CSF B a copy of the compute activity/task from step A. In steps C1 and C2, each of CSF A and CSF B executes the compute activity/task. It is noted that provided the execution of the compute task is deterministic, the two copies of the client device’s compute context at CSF A and CSF B may be expected to remain synchronized. (Even if there is pseudorandom behavior embedded in the computational task, such as pseudorandom number generation, the engine responsible for the pseudorandom behavior may be transferred as part of the computational context, allowing the two copies of the context to remain synchronized. As an example, the commonly used class of designs for pseudorandom number generation based on modular arithmetic can be expected to maintain synchronization between the two copies of the context, as long as the original seed value is common and the engine is invoked the same number of times in the two copies. ) In step D, CSF A returns to the client device a result of executing the compute task. CSF B may not return its computation result to the client device, since it executes the task only to keep its copy of the compute context in-sync with the copy at CSF A. In step 1109, CSF B confirms to the CMF that it accepts the relocation of compute offload point from CSF A to CSF B. In step 1110, the CMF transmits to the client device a switch instruction indicating that the client should begin delivering compute activity/tasks to CSF B instead of CSF A. As such, any subsequently generated compute activity/task from the client device may be expected to be delivered to CSF B. In step 1111, the CMF transmits a release indication to CSF A, which signifies that CSF A may release the compute context for the client device. In step 1112, CSF A transmits to CSF B an indication that all pending compute tasks for this client device at CSF A have been completed and forwarded. Step 1112 may be characterized as an “end marker” for the forwarding of compute tasks from CSF A to CSF B. In step 1113a, CSF A releases the compute context for the client device, and in step 1113b, CSF B activates the compute context for the client device. In one example, steps 1113a and 1113b may occur at substantially the same time. Step 1113b may mark the point at which CSF B will begin responding to compute tasks from the client device by executing them and returning the results to the client device, for example.
FIG. 12 illustrates an example scenario 1200 of an alternative approach to the context synchronization problem of FIG. 11 in accordance with an implementation of the present disclosure. Scenario 1200 depicts an alternative approach to address the context synchronization problem, by duplicating compute tasks by the client device instead of by CSF A. The organization of steps is similar to FIG. 11; steps 1205-1209 are aligned with steps 1005-1009 of FIG. 10 and steps 1105-1109 of FIG. 11, steps 1210-1212 represent additional steps beyond step 1209, and steps A to C represent an asynchronous procedure for offloading a compute activity/task from the client device during a transitional period between CSF A and CSF B. In step 1205, the CMF triggers relocation of compute offload point, by sending a relocation indication to CSF A (step 1205a) and an instruction to the client device to add task routing to CSF B (step 1205b) . In step 1206, CSF A transfers the client device’s compute context to CSF B, and in step 1207, CSF B establishes a compute context for the client device to enable execution of compute activities/tasks. Asynchronously, in step A, the client device transmits a compute activity/task to both CSF A (step A1) and CSF B (step A2) . The intention is that both CSF A and CSF B will execute the compute task, thus maintaining their copies of the client device’s compute context in-sync with one another. In step 1208, CSF B indicates to CSF A that CSF B accepts the transfer of compute context from step 1206. In step B, CSFs A (step B1) and B (step B2) execute the compute task that was delivered in step A. In step C, one or both of CSF A (step C1) and CSF B (step C2) may return the respective computation results of steps B1 and B2 to the client device. (It is noted that the two results should be identical, since the compute contexts are being maintained in a synchronized condition. ) Alternatively, coordination may occur between CSF A and CSF B to avoid duplication of the result in step C. For example, the CSF that finishes the compute task first may notify the other CSF that it does not need to return the result to the client device. In step 1209, CSF B indicates to the CMF that CSF B confirms the relocation of compute offload point from CSF A to CSF B (along with the transfer of the client device’s compute offload activity to CSF B) . In step 1210, CSF B optionally activates the compute context of the client device, i.e., this step may be unnecessary if CSF B is already processing compute tasks for the client device. In step 10, the CMF sends to the client device an instruction to stop task routing to CSF A. In step 1212, the CMF transmits a release indication to CSF A, allowing CSF A to release the compute context of the client device. In step 1213, CSF A releases the compute context of the client device.
FIG. 13 illustrates an example scenario 1300 of a message sequence chart for compute activity offloading between two CSFs in accordance with an implementation of the present disclosure. Scenario 1300 depicts the details of the interactions between a client device (e.g., a UE) , two radio nodes X and Y, and two CSFs respectively associated with the radio nodes X and Y, where both CSFs handle compute tasks simultaneously as described previously, both send compute results to the client device, and the client device combines the compute results. In steps 1301a and 1301b, the client device transmits a compute task to both CSF A (associated with the radio node X) and CSF B (associated with the radio node Y) , respectively (i.e., steps 1301a and 1301b are the same as steps A1 and A2 of FIG. 12) . For example, the radio nodes X and Y may be BSs of a wireless system, DUs or CUs of BSs of a wireless system, UEs, or other mobile devices, etc. In one example, the radio nodes X and Y may be nodes of two different types (for example, the radio node X may be a BS or BS component, while the radio node Y may be a UE or another mobile device) . In steps 1302a and 1302b, CSF A and CSF B, respectively, perform the compute task and generate task results. Since the client’s compute contexts held at CSF A and CSF B are being maintained in a synchronized state, it is anticipated that the task results computed by CSF A and CSF B will be identical. In steps 1303a and 1303b, CSF A and CSF B, respectively, deliver their task results to the radio nodes X and Y, respectively, for scheduling. Steps 1303a and 1303b may be transactions of a specified protocol or API, or they may be proprietary interactions based on the implementation of the CSFs and the radio nodes. It is noted that in many cases, the radio nodes X and Y will have a high degree of implementation discretion in determining what radio resources and radio configurations to use to transmit the task results (or any other data) to the client device over the air. For example, the radio nodes X and Y may make independent and potentially different decisions regarding modulation and coding state (MCS) , selection of radio resources in the time, frequency, and/or spatial domains, etc. However, in the case of identically matched compute results received from CSF A and CSF B, the radio nodes X and Y are scheduling identical data for transmission to the client device, and thus, it may be beneficial for the radio nodes X and Y to coordinate their transmissions and allow the client device to combine data received from both of them. Hence, in some embodiments, as shown in optional step 1304, a first one of the radio nodes (e.g., radio node X) may transmit to a second one of the radio nodes (e.g., radio node Y) scheduling coordination information regarding the radio configuration with which the first one of the radio nodes intends to schedule the transmission to the client device of the task result received from the CSF corresponding to the first one of the radio nodes. In optional step 1305, the second one of the radio nodes may reply to the first one of the radio nodes with a confirmation that it accepts the scheduling coordination information, which may indicate, e.g., that the second one of the radio nodes will schedule its transmission to the client device of the task result using a radio configuration compatible with the radio configuration selected by the first one of the radio nodes. In one example, the second one of the radio nodes may select the same MCS as indicated by the first one of the radio nodes. In another example, the second one of the radio nodes may indicate the radio resources it will use to schedule transmission to the client device of the task result, e.g., in the time, frequency, and/or spatial domains. In step 1307, the client device combines the received transmissions from steps 1306a and 1306b, to support improved decoding of the transmissions. In some embodiments, the radio nodes X and Y may use the information exchanged in steps 1304 and 1305 to schedule bit-identical transmissions in a lower layer of an air interface, such as a physical (PHY) layer or a medium access control (MAC) layer, which may allow the client device to perform in step 1307 a lower-layer combining operation on the received transmissions to allow decoding of a transmission that might otherwise be undecodable due to low signal-to-interference-plus-noise ratio (SINR) , for instance. In other embodiments, the radio nodes X and Y may coordinate bit-identical transmissions at a higher layer of the air interface, such as a radio link control (RLC) layer or a packet data control protocol (PDCP) layer, for example, which may allow the client device to perform in step 1307 an upper-layer combining operation on the received transmissions. In some cases, the scheduling information provided to the client device as part of steps 1306a and 1306b may include an indication of what radio resources may be combined. In other cases, the radio nodes X and Y may align their transmissions in multiple domains (for example, in time, frequency, and spatial domains) so that the client device can automatically combine the energy from the transmissions by receiving the common radio resources, similar to the operation of a single-frequency network transmission; in such cases, step 1307 may be a transparent process to the client device, which may simply see a high SINR on certain radio resources and thus experience an enhanced ability to decode data in those radio resources. In step 1308, the client device passes the combined task result to an application layer.
Illustrative Implementations
FIG. 14 illustrates an example communication system 1400 having an example apparatus 1410 and an example apparatus 1420 in accordance with an implementation of the present disclosure. Each of apparatus 1410 and apparatus 1420 may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to mobility management of compute activity offloading in mobile communications, including scenarios/schemes described above as well as processes 1500, 1600, and 1700 described below.
Each of apparatus 1410 and apparatus 1420 may be a communication apparatus, such as a part of an electronic apparatus, which may be a UE such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus or a computing apparatus. For instance, apparatus 1410/1420 may be implemented in a smartphone, a smartwatch, a personal digital assistant, an electronic control unit (ECU) in a vehicle, a digital camera, or a computing equipment such as a tablet computer, a laptop computer or a notebook computer. Apparatus 1410/1420 may also be a part of a machine type apparatus, which may be an IoT, NB-IoT, enhanced machine-type communication (eMTC) , IIoT UE such as an immobile or a stationary apparatus, a home apparatus, a roadside unit (RSU) , a wire communication apparatus or a computing apparatus. For instance, apparatus 1410/1420 may be implemented in a smart thermostat, a smart fridge, a smart door lock, a wireless speaker or a home control center. Each of apparatus 1410 and apparatus 1420 may be a network apparatus, such as a part of an electronic apparatus, which may be a network node such as a satellite, a BS, a small cell, a router or a gateway of an IoT network. For instance, apparatus 1410/1420 may be implemented in a satellite or an evolved Node-B (eNB) , a Next Generation Node-B (gNB) , or a transmission/reception point (TRP) in a 4G/5G, NR, IoT, NB-IoT or IIoT network. Alternatively, apparatus 1410/1420 may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. Apparatus 1410/1420 may include at least some of those components shown in FIG. 14 such as a processor 1412/1422, for example. Apparatus 1410/1420 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and/or user interface device) , and, thus, such component (s) of apparatus 1410/1420 are neither shown in FIG. 14 nor described below in the interest of simplicity and brevity.
In one aspect, each of processor 1412 and processor 1422 may be implemented in the form of one or more single-core processors, one or more multi-core processors, or one or more CISC processors. That is, even though a singular term “a processor” is used herein to refer to processor 1412 and processor 1422, each of processor 1412 and processor 1422 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of processor 1412 and processor 1422 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and/or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of processor 1412 and processor 1422 is a special-purpose machine specifically designed, arranged and configured to perform specific tasks, including mobility management of compute activity offloading, in a mobile device (e.g., as represented by apparatus 1410) and a network node (e.g., as represented by apparatus 1420) in accordance with various implementations of the present disclosure.
In some implementations, apparatus 1410 may also include a transceiver 1416 coupled to processor 1412 and capable of wirelessly transmitting and receiving data. In some implementations, transceiver 1416 may be capable of wirelessly communicating with different types of UEs and/or wireless networks of different radio access technologies (RATs) , such as 4G/5G/B5G/6G. In some implementations, transceiver 1416 may be equipped with a plurality of antenna ports (not shown) such as, for example, four antenna ports. That is, transceiver 1416 may be equipped with multiple transmit antennas and multiple receive antennas for multiple-input multiple-output (MIMO) wireless communications. In some implementations, apparatus 1420 may also include a transceiver 1426 coupled to processor 1422. Transceiver 1426 may include a transceiver capable of wirelessly transmitting and receiving data. In some implementations, transceiver 1426 may be capable of wirelessly communicating with different types of UEs of different RATs. In some implementations, transceiver 1426 may be equipped with a plurality of antenna ports (not shown) such as, for example, four antenna ports. That is, transceiver 1426 may be equipped with multiple transmit antennas and multiple receive antennas for MIMO wireless communications.
In some implementations, apparatus 1410 may further include a memory 1414 coupled to processor 1412 and capable of being accessed by processor 1412 and storing data therein. In some implementations, apparatus 1420 may further include a memory 1424 coupled to processor 1422 and capable of being accessed by processor 1422 and storing data therein. Each of memory 1414 and memory 1424 may include a type of random-access memory (RAM) such as dynamic RAM (DRAM) , static RAM (SRAM) , thyristor RAM (T-RAM) and/or zero-capacitor RAM (Z-RAM) . Alternatively, or additionally, each of memory 1414 and memory 1424 may include a type of read-only memory (ROM) such as mask ROM, programmable ROM (PROM) , erasable programmable ROM (EPROM) and/or electrically erasable programmable ROM (EEPROM) . Alternatively, or additionally, each of memory 1414 and memory 1424 may include a type of non-volatile random-access memory (NVRAM) such as flash memory, solid-state memory, ferroelectric RAM (FeRAM) , magnetoresistive RAM (MRAM) and/or phase-change memory.
Each of apparatus 1410 and apparatus 1420 may be a communication entity capable of communicating with each other using various proposed schemes in accordance with the present disclosure. For illustrative purposes and without limitation, a description of capabilities of apparatus 1410, as one of a CMF, a CSF, and a client device, and apparatus 1420, as another one of the CMF, the CSF and the client device, is provided below.
According to the first proposed scheme of the present disclosure, processor 1412 of apparatus 1410 hosting a CMF may transmit, via transceiver 1416, a relocation indication (e.g., step 906 of FIG. 9, or step 1005 of FIG. 10) to a source CSF, wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. Then, processor 1412 may receive, via transceiver 1416, a confirmation indication (e.g., step 908 of FIG. 9, or step 1009 of FIG. 10) from the source CSF or the target CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed. After that, processor 1412 may transmit, via transceiver 1416, a first instruction (e.g., step 909 of FIG. 9, or step 1110 of FIG. 11, or step 1211 of FIG. 12) to the client device, wherein the first instruction indicates a transfer of a compute offload activity of the client device from the source CSF to the target CSF.
In some implementations, processor 1412 may also determine (e.g., step 905 of FIG. 9) whether to trigger the transmission of the relocation indication based on at least one of the following: (i) a performance monitoring of the compute offload activity between the client device and the source CSF; (ii) a load balancing between the source CSF and the target CSF; and (iii) a mobility event associated with a radio connection of the client device.
In some implementations, processor 1412 may also receive, via transceiver 1416, an acknowledgement (e.g., step 910 of FIG. 9) of the first instruction from the client device.
In some implementations, processor 1412 may also transmit, via transceiver 1416, an admission query (e.g., step 1003 of FIG. 10) to the target CSF, wherein the admission query indicates a request for admission of the compute offload activity of the client device. Additionally, processor 1412 may also receive, via transceiver 1416, an admission confirmation (e.g., step 1004 of FIG. 10) from the target CSF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
In some implementations, processor 1412 may also transmit, via transceiver 1416, a release indication (e.g., step 1111 of FIG. 11, or step 1212 of FIG. 12) to the source CSF, wherein the release indication indicates the source CSF to release a compute context of the client device.
In some implementations, processor 1412 may also transmit, via transceiver 1416, a second instruction (e.g., step 1205b of FIG. 12) to the client device, wherein the second instruction indicates the client device to transmit the compute offload activity to the target CSF.
In some implementations, apparatus 1410 hosting the CMF may include a network node or a mobile device.
According to the second proposed scheme of the present disclosure, processor 1412 of apparatus 1410 hosting a CSF may receive, via transceiver 1416, a relocation indication (e.g., step 906 of FIG. 9, or step 1005 of FIG. 10) from a CMF in an event that the CSF is a source CSF, wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. Then, processor 1412 may transmit, via transceiver 1416, a confirmation indication (e.g., step 908 of FIG. 9) to the CMF in an event that the CSF is the source CSF or the targe CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed.
In some implementations, processor 1412 may also receive, via transceiver 1416, an admission query (e.g., step 1003 of FIG. 10) from the CMF in an event that the CSF is the target CSF, wherein the admission query indicates a request for admission of the compute offload activity of the client device. Additionally, processor 1412 may also transmit, via transceiver 1416, an admission confirmation (e.g., step 1004 of FIG. 10) to the CMF in an event that the CSF is the target CSF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
In some implementations, processor 1412 may also receive, via transceiver 1416, a release indication (e.g., step 1111 of FIG. 11, or step 1212 of FIG. 12) from the CMF in an event that the CSF is the source CSF, wherein the release indication indicates the source CSF to release a compute context of the client device.
In some implementations, processor 1412 may also receive, via transceiver 1416, a compute context (e.g., step 1006 of FIG. 10) of the client device from the source CSF in an event that the CSF is the target CSF, and transmit, via transceiver 1416, an acceptance indication (e.g., step 1008 of FIG. 10) of the compute context to the source CSF in an event that the CSF is the target CSF.
In some implementations, processor 1412 may also receive, via transceiver 1416, a compute offload activity (e.g., step A of FIG. 11) of the client device from the client device in an event that the CSF is the source CSF, forward, via transceiver 1416, a copy of the compute offload activity (e.g., step B of FIG. 11) to the target CSF in an event that the CSF is the source CSF, and transmit, via transceiver 1416, a result of the compute offload activity (e.g., step D of FIG. 11) to the client device in an event that the CSF is the source CSF.
In some implementations, processor 1412 may also receive, via transceiver 1416, a compute offload activity (e.g., step A2 of FIG. 12) of the client device from the client device in an event that the CSF is the target CSF, transmit, via transceiver 1416, a result of the compute offload activity (e.g., step C1 of FIG. 12) to the client device in an event that the CSF is the source CSF, and transmit, via transceiver 1416, the result of the compute offload activity (e.g., step C2 of FIG. 12) to the client device in an event that the CSF is the target CSF.
In some implementations, the result of the compute offload activity from the source CSF may be transmitted via a first radio node, the result of the compute offload activity from the target CSF may be transmitted via a second radio node, and the transmissions of the result of the compute offload activity may be scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.
In some implementations, apparatus 1410 hosting the CSF may include a network node or a mobile device.
According to the third proposed scheme of the present disclosure, processor 1412 of apparatus 1410 (e.g., a client device) may transmit, via transceiver 1416, the compute offload activity (e.g., step 902/904 of FIG. 9) to a source CSF. Then, processor 1412 may receive, via transceiver 1416, a first instruction (e.g., step 909 of FIG. 9, or step 1110 of FIG. 11, or step 1211 of FIG. 12) from a CMF, wherein the first instruction indicates a transfer of the compute offload activity from the source CSF to a target CSF.
In some implementations, processor 1412 may also transmit, via transceiver 1416, an acknowledgement (e.g., step 910 of FIG. 9) of the first instruction to the CMF.
In some implementations, processor 1412 may also receive, via transceiver 1416, a second instruction from the CMF, wherein the second instruction (e.g., step 1205b of FIG. 12) indicates the client device to transmit the compute offload activity to the target CSF, and the first instruction includes an instruction (e.g., step 1211 of FIG. 12) to stop transmitting the compute offload activity to the source CSF.
In some implementations, processor 1412 may also receive, via transceiver 1416, a result of the compute offload activity (e.g., step D of FIG. 11, or step C1/C2 of FIG. 12) from at least one of the source CSF and the target CSF.
In some implementations, the result of the compute offload activity from the source CSF may be received via a first radio node, the result of the compute offload activity from the target CSF may be received via a second radio node, and the transmissions of the result of the compute offload activity may be scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.
Illustrative Processes
FIG. 15 illustrates an example process 1500 in accordance with an implementation of the present disclosure. Process 1500 may be an example implementation of above scenarios/schemes, whether partially or completely, with respect to mobility management of compute activity offloading in mobile communications. Process 1500 may represent an aspect of implementation of features of apparatus 1410/1420 hosting a CMF. Process 1500 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1510 to 1530. Although illustrated as discrete blocks, various blocks of process 1500 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1500 may be executed in the order shown in FIG. 15 or, alternatively, in a different order. Process 1500 may be implemented by apparatus 1410/1420 or any suitable mobile devices or network nodes. Solely for illustrative purposes and without limitation, process 1500 is described below in the context of apparatus 1410. Process 1500 may begin at block 1510.
At 1510, process 1500 may involve processor 1412 of apparatus 1410 transmitting, via transceiver 1416, a relocation indication to a source CSF, wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. Process 1500 may proceed from 1510 to 1520.
At 1520, process 1500 may involve processor 1412 receiving, via transceiver 1416, a confirmation indication from the source CSF or the target CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed. Process 1500 may proceed from 1520 to 1530.
At 1530, process 1500 may involve processor 1412 transmitting, via transceiver 1416, a first instruction to the client device, wherein the first instruction indicates a transfer of a compute offload activity of the client device from the source CSF to the target CSF.
In some implementations, process 1500 may further involve processor 1412 determining whether to trigger the transmission of the relocation indication based on at least one of the following: (i) a performance monitoring of the compute offload activity between the client device and the source CSF; (ii) a load balancing between the source CSF and the target CSF; and (iii) a mobility event associated with a radio connection of the client device.
In some implementations, process 1500 may further involve processor 1412 receiving, via transceiver 1416, an acknowledgement of the first instruction from the client device.
In some implementations, process 1500 may further involve processor 1412 transmitting, via transceiver 1416, an admission query to the target CSF, wherein the admission query indicates a request for admission of the compute offload activity of the client device. Additionally, process 1500 may further involve processor 1412 receiving, via transceiver 1416, an admission confirmation from the target CSF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
In some implementations, process 1500 may further involve processor 1412 transmitting, via transceiver 1416, a release indication to the source CSF, wherein the release indication indicates the source CSF to release a compute context of the client device.
In some implementations, process 1500 may further involve processor 1412 transmitting, via transceiver 1416, a second instruction to the client device, wherein the second instruction indicates the client device to transmit the compute offload activity to the target CSF.
In some implementations, apparatus 1410 hosting the CMF may include a network node or a mobile device.
FIG. 16 illustrates an example process 1600 in accordance with an implementation of the present disclosure. Process 1600 may be an example implementation of above scenarios/schemes, whether partially or completely, with respect to mobility management of compute activity offloading in mobile communications. Process 1600 may represent an aspect of implementation of features of apparatus 1410/1420 hosting a CSF. Process 1600 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1610 and 1620. Although illustrated as discrete blocks, various blocks of process 1600 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1600 may be executed in the order shown in FIG. 16 or, alternatively, in a different order. Process 1600 may be implemented by apparatus 1410/1420 or any suitable mobile devices or network nodes. Solely for illustrative purposes and without limitation, process 1600 is described below in the context of apparatus 1410. Process 1600 may begin at block 1610.
At 1610, process 1600 may involve processor 1412 of apparatus 1410 receiving, via transceiver 1416, a relocation indication from a CMF in an event that the CSF is a source CSF, wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF. Process 1600 may proceed from 1610 to 1620.
At 1620, process 1600 may involve processor 1412 transmitting, via transceiver 1416, a confirmation indication to the CMF in an event that the CSF is the source CSF or the targe CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed.
In some implementations, process 1600 may further involve processor 1412 receiving, via transceiver 1416, an admission query from the CMF in an event that the CSF is the target CSF, wherein the admission query indicates a request for admission of the compute offload activity of the client device. Additionally, process 1600 may further involve processor 1412 transmitting, via transceiver 1416, an admission confirmation to the CMF in an event that the CSF is the target CSF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
In some implementations, process 1600 may further involve processor 1412 receiving, via transceiver 1416, a release indication from the CMF in an event that the CSF is the source CSF, wherein the release indication indicates the source CSF to release a compute context of the client device.
In some implementations, process 1600 may further involve processor 1412 receiving, via transceiver 1416, a compute context of the client device from the source CSF in an event that the CSF is the target CSF, and transmitting, via transceiver 1416, an acceptance indication of the compute context to the source CSF in an event that the CSF is the target CSF.
In some implementations, process 1600 may further involve processor 1412 receiving, via transceiver 1416, a compute offload activity of the client device from the client device in an event that the CSF is the source CSF, forwarding, via transceiver 1416, a copy of the compute offload activity to the target CSF in an event that the CSF is the source CSF, and transmitting, via transceiver 1416, a result of the compute offload activity to the client device in an event that the CSF is the source CSF.
In some implementations, process 1600 may further involve processor 1412 receiving, via transceiver 1416, a compute offload activity of the client device from the client device in an event that the CSF is the target CSF, transmitting, via transceiver 1416, a result of the compute offload activity to the client device in an event that the CSF is the source CSF, and transmitting, via transceiver 1416, the result of the compute offload activity to the client device in an event that the CSF is the target CSF.
In some implementations, the result of the compute offload activity from the source CSF may be transmitted via a first radio node, the result of the compute offload activity from the target CSF may be transmitted via a second radio node, and the transmissions of the result of the compute offload activity may be scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.
In some implementations, apparatus 1410 hosting the CSF may include a network node or a mobile device.
FIG. 17 illustrates an example process 1700 in accordance with an implementation of the present disclosure. Process 1700 may be an example implementation of above scenarios/schemes, whether partially or completely, with respect to mobility management of compute activity offloading in mobile communications. Process 1700 may represent an aspect of implementation of features of apparatus 1410/1420 as a client device. Process 1700 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1710 and 1720. Although illustrated as discrete blocks, various blocks of process 1700 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks of process 1700 may be executed in the order shown in FIG. 17 or, alternatively, in a different order. Process 1700 may be implemented by apparatus 1410/1420 or any suitable mobile devices. Solely for illustrative purposes and without limitation, process 1700 is described below in the context of apparatus 1410. Process 1700 may begin at block 1710.
At 1710, process 1700 may involve processor 1412 of apparatus 1410 transmitting, via transceiver 1416, the compute offload activity to a source CSF. Process 1700 may proceed from 1710 to 1720.
At 1720, process 1700 may involve processor 1412 receiving, via transceiver 1416, a first instruction from a CMF, wherein the first instruction indicates a transfer of the compute offload activity from the source CSF to a target CSF.
In some implementations, process 1700 may further involve processor 1412 transmitting, via transceiver 1416, an acknowledgement of the first instruction to the CMF.
In some implementations, process 1700 may further involve processor 1412 receiving, via transceiver 1416, a second instruction from the CMF, wherein the second instruction indicates the client device to transmit the compute offload activity to the target CSF, and the first instruction includes an instruction to stop transmitting the compute offload activity to the source CSF.
In some implementations, process 1700 may further involve processor 1412 receiving, via transceiver 1416, a result of the compute offload activity from at least one of the source CSF and the target CSF.
In some implementations, the result of the compute offload activity from the source CSF may be received via a first radio node, the result of the compute offload activity from the target CSF may be received via a second radio node, and the transmissions of the result of the compute offload activity may be scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.
Additional Notes
The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected" , or "operably coupled" , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and/or physically interacting components and/or wirelessly interactable and/or wirelessly interacting components and/or logically interacting and/or logically interactable components.
Further, with respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. The various singular/plural permutations may be expressly set forth herein for sake of clarity.
Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an, " e.g., “a” and/or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations, " without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”
From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

A method, comprising:

transmitting, by a processor of an apparatus hosting a composition management function (CMF) , a relocation indication to a source compute server function (CSF) , wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF;

receiving, by the processor, a confirmation indication from the source CSF or the target CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed; and

transmitting, by the processor, a first instruction to the client device, wherein the first instruction indicates a transfer of a compute offload activity of the client device from the source CSF to the target CSF.
The method of Claim 1, further comprising:

determining, by the processor, whether to trigger the transmission of the relocation indication based on at least one of the following:

a performance monitoring of the compute offload activity between the client device and the source CSF;

a load balancing between the source CSF and the target CSF; and

a mobility event associated with a radio connection of the client device.
The method of Claim 1, further comprising:

receiving, by the processor, an acknowledgement of the first instruction from the client device.
The method of Claim 1, further comprising:

transmitting, by the processor, an admission query to the target CSF, wherein the admission query indicates a request for admission of the compute offload activity of the client device; and

receiving, by the processor, an admission confirmation from the target CSF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
The method of Claim 1, further comprising:

transmitting, by the processor, a release indication to the source CSF, wherein the release indication indicates the source CSF to release a compute context of the client device.
The method of Claim 1, further comprising:

transmitting, by the processor, a second instruction to the client device, wherein the second instruction indicates the client device to transmit the compute offload activity to the target CSF.
The method of Claim 1, wherein the apparatus comprises a network node or a mobile device.
A method, comprising:

receiving, by a processor of an apparatus hosting a compute server function (CSF) , a relocation indication from a composition management function (CMF) in an event that the CSF is a source CSF, wherein the relocation indication indicates a relocation of a compute offload point associated with a client device from the source CSF to a target CSF; and

transmitting, by the processor, a confirmation indication to the CMF in an event that the CSF is the source CSF or the targe CSF, wherein the confirmation indication indicates that the relocation of the compute offload point is completed.
The method of Claim 8, further comprising:

receiving, by the processor, an admission query from the CMF in an event that the CSF is the target CSF, wherein the admission query indicates a request for admission of the compute offload activity of the client device; and

transmitting, by the processor, an admission confirmation to the CMF in an event that the CSF is the target CSF, wherein the admission confirmation indicates that the request for admission of the compute offload activity of the client device is accepted.
The method of Claim 8, further comprising:

receiving, by the processor, a release indication from the CMF in an event that the CSF is the source CSF, wherein the release indication indicates the source CSF to release a compute context of the client device.
The method of Claim 8, further comprising:

receiving, by the processor, a compute context of the client device from the source CSF in an event that the CSF is the target CSF; and

transmitting, by the processor, an acceptance indication of the compute context to the source CSF in an event that the CSF is the target CSF.
The method of Claim 8, further comprising:

receiving, by the processor, a compute offload activity of the client device from the client device in an event that the CSF is the source CSF;

forwarding, by the processor, a copy of the compute offload activity to the target CSF in an event that the CSF is the source CSF; and

transmitting, by the processor, a result of the compute offload activity to the client device in an event that the CSF is the source CSF.
The method of Claim 8, further comprising:

receiving, by the processor, a compute offload activity of the client device from the client device in an event that the CSF is the target CSF;

transmitting, by the processor, a result of the compute offload activity to the client device in an event that the CSF is the source CSF; and

transmitting, by the processor, the result of the compute offload activity to the client device in an event that the CSF is the target CSF.
The method of Claim 13, wherein the result of the compute offload activity from the source CSF is transmitted via a first radio node, the result of the compute offload activity from the target CSF is transmitted via a second radio node, and the transmissions of the result of the compute offload activity are scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.
The method of Claim 8, wherein the apparatus comprises a network node or a mobile device.
A method, comprising:

transmitting, by a processor of a client device, a compute offload activity to a source compute server function (CSF) ; and

receiving, by the processor, a first instruction from a composition management function (CMF) , wherein the first instruction indicates a transfer of the compute offload activity from the source CSF to a target CSF.
The method of Claim 16, further comprising:

transmitting, by the processor, an acknowledgement of the first instruction to the CMF.
The method of Claim 16, further comprising:

receiving, by the processor, a second instruction from the CMF, wherein the second instruction indicates the client device to transmit the compute offload activity to the target CSF, and the first instruction comprises an instruction to stop transmitting the compute offload activity to the source CSF.
The method of Claim 16, further comprising:

receiving, by the processor, a result of the compute offload activity from at least one of the source CSF and the target CSF.
The method of Claim 19, wherein the result of the compute offload activity from the source CSF is received via a first radio node, the result of the compute offload activity from the target CSF is received via a second radio node, and the transmissions of the result of the compute offload activity are scheduled based on a scheduling coordination information negotiated between the first radio node and the second radio node.