Enabling offload plan exchange between network nodes

Abstract

A method may include determining, by a first network node, a need for offloading at the first network node. The first request may be sent to the second network node for a cost metric associated with one or more user equipments connected to the first network node and to be offloaded. The cost metric may be received with a list of one or more user devices. The second request, and the list of one or more user equipments, may be sent to a third network node for a predicted cost metric associated with one or more user equipments in the list. In response to the second request, a predicted cost metric may be received. The offload of one or more user equipments in the list may be offloaded to the second network node or the third network node based on which node has the lowest cost metric.

Description

Technical Field

[0001] Some example embodiments generally relate to mobile or wireless telecommunication systems (such as Long Term Evolution (LTE), or fifth generation (5G) New Radio (NR) access technology), or above 5G, or other communication systems. For example, certain example embodiments may relate to apparatus, systems, and / or methods for enabling exchange of offload plans between network nodes. Background Art

[0002] Examples of mobile or wireless telecommunication systems may include Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), Advanced LTE (LTE-A), Professional LTE-A, and / or fifth generation (5G), or new radio (NR) telecommunication systems, and future generation telecommunication systems. The fifth generation (5G) telecommunication system refers to the next generation (NG) radio access network and the network architecture for the core network. The 5G telecommunication system is mainly based on the new radio (NR) radio access technology (5G NR), but the 5G (or NG) network can also be built on E-UTRAN. It is estimated that 5G NR will provide a bit rate of about 10-20Gbit / s or higher, and will support at least enhanced mobile broadband (eMBB) and ultra-reliable low latency communication (URLLC) and massive machine type communication (mMTC). 5G NR is expected to provide ultra-high bandwidth, ultra-strong stability, low latency connectivity, and large-scale networks to support the Internet of Things (IoT). Summary of the invention

[0003] Some example embodiments may be directed to a method. The method may include: determining, by a first network node, a need for offloading at the first network node. The method may also include: sending a first request to a second network node for a cost metric associated with one or more user devices that are connected to the first network node and are to be offloaded. The method may also include: receiving the cost metric, and a list of one or more user devices associated with the cost metric. In addition, the method may include: sending a second request to a third network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the third network node. In addition, the method may also include: receiving the predicted cost metric in response to the second request. The method may also include: initiating offloading of one or more user devices in the list to the second network node or the third network node based on which node has the lowest cost metric.

[0004] Other example embodiments may be directed to an apparatus. The apparatus may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may also be configured to, together with the at least one processor, cause the apparatus to at least: determine a need for offloading at the apparatus. The apparatus may also be caused to: send a first request to a first network node for a cost metric associated with one or more user devices connected to the apparatus and to be offloaded. The apparatus may also be caused to: receive a cost metric, and a list of one or more user devices associated with the cost metric. In addition, the apparatus may be caused to: send a second request to a second network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the second network node. In addition, the apparatus may be caused to: receive the predicted cost metric in response to the second request. The apparatus may also be caused to: initiate an offloading of one or more user devices in the list to the second network node or a third network node based on which node has the lowest cost metric.

[0005] Other example embodiments may be directed to an apparatus. The apparatus may include: a component for determining a need for offloading at the apparatus. The apparatus may also include: a component for sending a first request to a first network node for a cost metric associated with one or more user devices that are connected to the apparatus and are to be offloaded. The apparatus may also include: a component for receiving a cost metric and a list of one or more user devices associated with the cost metric. In addition, the apparatus may include: a component for sending a second request to a second network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the second network node. In addition, the apparatus may include: a component for receiving a predicted cost metric in response to the second request. The apparatus may also include: a component for initiating an offloading of one or more user devices in the list to a second network node or a third network node based on which node has the lowest cost metric.

[0006] According to other example embodiments, a non-transitory computer-readable medium may be encoded with instructions that, when executed in hardware, may perform a method. The method may include: determining, by a first network node, a need for offloading at the first network node. The method may also include: sending a first request to a second network node for a cost metric associated with one or more user devices that are connected to the first network node and are to be offloaded. The method may also include: receiving the cost metric and a list of one or more user devices associated with the cost metric. In addition, the method may include: sending a second request to a third network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the third network node. In addition, the method may include: receiving the predicted cost metric in response to the second request. The method may also include: initiating an offloading of one or more user devices in the list to the second network node or the third network node based on which node has the lowest cost metric.

[0007] Other example embodiments may be directed to a computer program product for performing a method. The method may include: determining, by a first network node, a need for offloading at the first network node. The method may also include: sending a first request to a second network node for a cost metric associated with one or more user devices that are connected to the first network node and are to be offloaded. The method may also include: receiving the cost metric, and a list of one or more user devices associated with the cost metric. In addition, the method may include: sending a second request to a third network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the third network node. In addition, the method may include: receiving the predicted cost metric in response to the second request. The method may also include: initiating an offloading of one or more user devices in the list to the second network node or the third network node based on which node has the lowest cost metric.

[0008] Other example embodiments may be directed to an apparatus that may include a circuit system configured to determine a need for offloading at the apparatus. The apparatus may also include a circuit system configured to send a first request to a first network node for a cost metric associated with one or more user devices that are connected to the apparatus and are to be offloaded. The apparatus may also include a circuit system configured to receive the cost metric and a list of one or more user devices associated with the cost metric. In addition, the apparatus may include a circuit system configured to send a second request to a second network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the second network node. In addition, the apparatus may include a circuit system configured to receive the predicted cost metric in response to the second request. The apparatus may also include a circuit system configured to initiate offloading of one or more user devices in the list to the second network node or the third network node based on which node has the lowest cost metric.

[0009] Certain example embodiments may be directed to a method. The method may include: receiving, at a second network node, a request from a first network node, and a list of one or more user devices, for a predicted cost metric associated with the one or more user devices in the list when connected to the second network node. The method may also include: checking, at the second network node, resource availability of the one or more user devices in the list. The method may also include: sending a response to the request to the first network node, wherein the response includes: a predicted cost metric associated with the one or more user devices in the list. In addition, the method may include: receiving, from the first network node, an uninstallation of the one or more user devices in the list.

[0010] Other example embodiments may be directed to an apparatus. The apparatus may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured to, together with the at least one processor, cause the apparatus to at least: receive a request from a first network node, and a list of one or more user devices, for a predicted cost metric associated with the one or more user devices in the list when connected to the apparatus. The apparatus may also be caused to: at the apparatus, check for resource availability of the one or more user devices in the list. The apparatus may also be caused to: send a response to the request to the first network node, wherein the response may include: a predicted cost metric associated with the one or more user devices in the list. In addition, the apparatus may be caused to: receive an uninstallation of the one or more user devices in the list from the first network node.

[0011] Other example embodiments may be directed to an apparatus. The apparatus may include: a component for receiving a request from a first network node, and a list of one or more user devices, for a predicted cost metric associated with the one or more user devices in the list when connected to the apparatus. The apparatus may also include: a component for checking resource availability of the one or more user devices in the list at the apparatus. The apparatus may also include: a component for sending a response to the request to the first network node, wherein the response includes the predicted cost metric associated with the one or more user devices in the list. In addition, the apparatus may include: a component for receiving an uninstallation of the one or more user devices in the list from the first network node.

[0012] According to other example embodiments, a non-transitory computer readable medium may be encoded with instructions that, when executed in hardware, may perform a method. The method may include: receiving, at a second network node, a request from a first network node, and a list of one or more user devices for a predicted cost metric associated with the one or more user devices in the list when connected to the second network node. The method may also include: checking, at the second network node, resource availability of the one or more user devices in the list. The method may also include: sending a response to the request to the first network node, wherein the response includes: a predicted cost metric associated with the one or more user devices in the list. In addition, the method may include: receiving an uninstallation of the one or more user devices in the list from the first network node.

[0013] Other example embodiments may be directed to a computer program product for performing a method. The method may include: receiving, at a second network node, a request from a first network node, and a list of one or more user devices for a predicted cost metric associated with the one or more user devices in the list when connected to the second network node. The method may also include: checking, at the second network node, resource availability of the one or more user devices in the list. The method may also include: sending a response to the request to the first network node, wherein the response includes: a predicted cost metric associated with the one or more user devices in the list. In addition, the method may include: receiving, from the first network node, an uninstallation of the one or more user devices in the list.

[0014] Other example embodiments may be directed to an apparatus that may include circuitry configured to: receive a request from a first network node, and a list of one or more user devices, for a predicted cost metric associated with the one or more user devices in the list when connected to the apparatus. The apparatus may also include circuitry configured to: check resource availability of the one or more user devices in the list at the apparatus. The apparatus may also include circuitry configured to: send a response to the request to the first network node, wherein the response includes: a predicted cost metric associated with the one or more user devices in the list. In addition, the apparatus may include circuitry configured to: receive an unload of the one or more user devices in the list from the first network node. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] For a proper understanding of the example embodiments, reference should be made to the accompanying drawings, in which:

[0016] Figure 1 An example functional framework for radio access network intelligence is illustrated.

[0017] Figure 2 An example signal flow diagram for offloading traffic between cells is illustrated in accordance with certain example embodiments.

[0018] Figure 3 An example uninstall planning process is illustrated in accordance with certain example embodiments.

[0019] Figure 4 An example signal diagram for distributed inter-unit offloading is illustrated in accordance with certain example embodiments.

[0020] Figure 5 An example user device context group establishment request message is illustrated in accordance with certain example embodiments.

[0021] Figure 6 An example flow diagram of a method according to certain example embodiments is illustrated.

[0022] Figure 7 An example flow diagram of another method according to certain example embodiments is illustrated.

[0023] Figure 8 A collection of apparatuses according to certain example embodiments is illustrated. DETAILED DESCRIPTION

[0024] It should be understood that, as generally described and illustrated herein in the accompanying drawings, the components of certain example embodiments may be arranged and designed in a variety of different configurations. The following is a detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for enabling exchange of offload plans between network nodes. For example, some example embodiments may be directed to artificial intelligence (AI) or machine learning (ML) use cases that enable offload planning.

[0025] The features, structures, or characteristics of the example embodiments described throughout this specification may be combined in any suitable manner in one or more example embodiments. For example, the use of the phrases "certain embodiments," "example embodiments," "some embodiments," or other similar language throughout this specification means that the specific features, structures, or characteristics described in conjunction with the embodiments may be included in at least one embodiment. Therefore, the phrases "in certain embodiments," "example embodiments," "in some embodiments," "in other embodiments," or other similar language appearing throughout this specification do not necessarily all refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In addition, the terms "cell," "node," "gNB," or other similar language may be used interchangeably throughout this specification.

[0026] As used herein, “at least one of: ” and “at least one of ” and similar expressions, where a list of two or more elements is connected by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.

[0027] According to the technical standards of the Third Generation Partnership Project (3GPP), energy-saving functionality has been introduced to minimize network energy consumption and energy-related operating expenses. Energy-saving deployments can consider capacity enhancement cells deployed on top of coverage cells to enhance the capacity of Evolved Universal Mobile Telecommunications System (UMTS) E-UTRA or NR in single connectivity or dual connectivity. These cells are allowed to be optimized by being shut down when capacity is not needed and reactivated on demand. Shutting down cells can be done by operations, administration and maintenance (OAM), as well as by the next generation radio access network (NG-RAN) node that owns the capacity cell, which can use, for example, cell load information to automatically shut down the cell.

[0028] Offloading is an essential element / component in multiple AIML-enabled use cases. For example, 3GPP Rel-17 has defined three use cases - energy saving, load balancing, and mobility optimization. All three use cases involve offloading one or more UEs to one or more suitable cells to ensure that the overall performance objectives are met. Although this document describes the idea in the context of energy saving, the concept can also be applied to other use cases such as load balancing and mobility optimization.

[0029] The NG-RAN node can initiate a handover to unload traffic from the cell that is being shut down (and the reason for the handover can be indicated to assist the node in future actions). The cell owner notifies neighbors about the shutdown decision via Xn. Additionally, idle mode user equipment (UE) can be prevented from camping on a cell that is being shut down, and incoming handovers can also be prevented. Neighbors can retain cell configuration data even when the cell is inactive. In addition, if there is a capacity requirement, an NG-RAN node that does not own a capacity enhancement cell can request reactivation of a capacity cell from a neighbor via Xn. In this case, a cell activation procedure can be used. Neighbors can also be notified about the turn-on (reactivation) decision on the Xn interface via Xn, and the turn-on can also be decided by OAM.

[0030] According to 3GPP, data required by the AI ​​function may be identified in the input, and data produced may be identified in the output. Figure 1 An example AI / ML workflow is illustrated. The purpose of the example AI / ML workflow is to identify the (input) data required by the AI / ML algorithm provided by data collection for model training (training data), and model reasoning (inference data). Additionally, output information and the operations that participants will perform based on the results of model reasoning can represent such data for collection and for model training.

[0031] In particular, Figure 1 An example functional framework for RAN intelligence is shown. Figure 1 As shown in , data collection 100 is a function that provides input to model training 105 and model reasoning function 110. Data preparation (e.g., preprocessing and cleaning, formatting, and conversion) specific to the AI / ML algorithm may not be performed in the data collection function 100. Examples of input data may include measurements from UEs or different network entities, feedback from participants 115, and / or output from AI / ML models. Additionally, training data may include data required as input to the AI / ML model training function, and reasoning data may include data required as input to the AI / ML model reasoning function.

[0032] like Figure 1As shown in , the model training function 105 can perform AI / ML model training, validation, and testing, which can generate model performance indicators as part of the model testing process. If necessary, the model training function 105 can also be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and conversion) based on the training data provided by the data collection function 100. From the model training function 105, model deployment / update can be performed to deploy the trained, validated, and tested AI / ML model to the model reasoning function 110, or to deliver an updated model to the model reasoning function 110.

[0033] The model reasoning function 110 may be operable to provide AI / ML model reasoning output (e.g., predictions or decisions). In addition, the model reasoning function 110 may provide model performance feedback to the model training function 105 when applicable. Additionally, if necessary, the model reasoning function 110 may be responsible for data preparation (e.g., data preprocessing and cleaning, formatting, and conversion) based on the reasoning data delivered by the data collection function 100. In some cases, when available, model performance feedback may be used to monitor the performance of the AI / ML model.

[0034] refer to Figure 1 , the actuator 115 may be a function that receives output from the model reasoning function 110 and triggers or executes corresponding actions. The actuator 115 may also trigger actions for other entities or itself. Figure 1 The feedback shown in can correspond to information that may be needed to obtain training data, inference data, or monitor the performance of the AI / ML model and its impact on the network by updating key performance indicators (KPIs) and performance counters.

[0035] In 5G, the handover process may include handover preparation and handover execution. In handover preparation, resources in the target node may be prepared. In handover execution, a handover command may be sent from the source node to the UE and the UE connected to the target node. The conventional process is designed to consider L3 mobility use cases, where a specific UE (i.e., a single UE) reports to the network radio resource management (RRM) measurements that trigger handover preparation, execution, and context release processes.

[0036] In some cases, it may be preferable if the source node is prepared to handover a collection of UEs to another neighboring cell. This can help determine the cumulative effect of AI / ML operations on network performance. In this case, rather than deciding on handover operations based on individual UEs, the offloading plan can offload all UEs that meet certain criteria to the energy gNB to a neighboring gNB. These UEs may meet priority in offloading. The criteria can depend on the cost or reward / benefit that the offloading operation will bring to the relevant node. Generally, the goal is to reduce the "cost" or maximize the "reward / benefit". A given use case may focus on either. For example, in terms of energy saving, the cost is the additional throughput caused by the offloaded UEs to the target node, while the reward / benefit is the maximization of energy efficiency for a given number of UEs served. Similarly, for the load balancing use case, the cost is the number of UEs served by each cell, while the reward / benefit is the maximization of the aggregate cell throughput. In some cases, only actions / offloading plans that bring cost reduction should be selected by the source gNB. In this way, if all UEs in a cell (belonging to one or more offloading plans) can be offloaded to another cell, the gNB can guarantee that the cell can be shut down because this will be the offloading plan that minimizes the energy saving cost (by allowing the source node (capacity cell) to shut down).

[0037] The energy saving cost may be calculated based on the energy spent per the transmitted load. The cost of the offloading action may depend on the optimization sought by the offloading plan. Other examples of costs may include the overall delay experienced by the set of offloaded UEs in the target gNB. This may avoid a situation where a UE is offloaded to a gNB but the cell cannot be shut down if other UEs remain connected to the cell. In other examples, energy efficiency may be another metric that may be used. For example, energy efficiency may be estimated using data volume (amount of data transmitted) and energy consumption. Alternatively, energy efficiency may also be calculated using coverage area and energy consumption.

[0038] Minimizing cost may be equivalent to maximizing reward. Therefore, the criteria may also depend on the corresponding reward that the offloading action will produce for the nodes involved. Similarly, only actions / offloading plans that produce an increase in reward should be selected by the source gNB. An example of such a reward could be the amount of load sent for a given energy consumption for a certain number of UEs. The reward of the offloading action may depend on the optimization sought by the offloading plan. Other examples of rewards may be the overall achievable (total) throughput of the set of UEs in the target gNB. The cost or reward may be adjusted based on the priority of the UEs participating in the offloading plan. For example, the reward for a UE with a higher priority will have a higher multiplier compared to the reward from a UE with a lower priority. Another example of energy saving reward may include maximizing the amount of data or minimizing energy consumption, which may be considered as rewards. In the load balancing use case, maximizing the system performance (aggregate cell throughput) across all load balanced cells may be considered as a reward. Furthermore, if the cost is based on DU-related information ((predicted) throughput, (predicted) data volume, (predicted) beam failure recovery (BFR), and / or (predicted) traffic), the gNB-CU may need to obtain the cost from its DU through a new F1AP procedure.

[0039] However, even though an offload plan may be required, current specifications do not provide any support for exchanging the offload plan between the energy node and the target node before performing the handover process required for many use cases, including AI / ML energy saving and AI / ML load balancing. Therefore, as described herein, certain example embodiments provide mechanisms for offload plan preparation and triggering offload plan exchange between multiple network nodes, such as a source node and a target node (e.g., between two centralized unit gNBs (gNB-CU) or between two distributed unit gNBs (gNB-DU)).

[0040] According to certain example embodiments, a mechanism for offloading plan preparation may be performed within a source node (e.g., within a gNB or gNB-CU). According to some example embodiments, the mechanism may be triggered when UE measurements have been collected at the source node to identify candidate target nodes for offloading. According to other example embodiments, a mechanism for triggering the exchange of offloading plans between a source node and a target node may be provided. For example, in the mechanism, the source node may indicate to the target node candidate offloading plans (e.g., the number of UEs and optionally the total resources required), as well as requests from neighboring gNBs to determine how much it would cost if these UEs were offloaded to it. The mechanism for triggering an offloading plan may also include a mechanism for the source node to determine an optimal list of switching UEs that minimizes the cost of the offloading plan (or maximizes the benefit / return).

[0041] Figure 2An example signal flow diagram for offloading traffic between cells according to certain example embodiments is illustrated. Figure 2 As shown in , at 200, the model reasoning function may trigger a cell offload from a gNB-CU2, where the gNB-CU2 corresponds to a CU of a capacity cell that enters energy saving mode. This may trigger a need to offload multiple UEs from the gNB-CU2. According to certain example embodiments, the gNB-CU2 may determine a cost for a set of UEs connected thereto. The cost may be determined based on a metric, which in some cases may depend on lower layers (e.g., it may depend on throughput, BFR, predicted traffic, etc.). In certain example embodiments, at 205, the gNB-CU2 may obtain the cost or predicted cost via a request from an actual DU (where the UE is connected). The cost may also be calculated internally by the gNB-CU, in which case the gNB-CU may calculate its cost without any signaling (e.g., if the cost is CU-based and can be calculated by the CU itself, such as the number of radio resource control (RRC) connections, the amount of uplink (UL) cell packet data convergence protocol (PDCP) service data unit (SDU) data, etc.). According to certain example embodiments, the request may include criteria for determining the cost, including, for example, UE throughput, data volume, BFR, cell load, etc. as described above. At 210, gNB-DU2 may send an offload plan response, which may include a handover UE candidate list (including a list of UEs that meet the criteria specified in the request), and the determined cost.

[0042] like Figure 2 As shown in , at 215, gNB-CU2 may request from the neighboring gNB-CU1 the expected (predicted) cost according to the same metric of the request sent at 205, i.e., the cost that the identified set of UEs would incur if offloaded at the neighboring gNB (i.e., gNB-CU1). Upon receiving the request, gNB-CU1 may calculate the predicted cost according to the criterion at 220. At 225, gNB-CU1 may also return the predicted cost to gNB-CU2 as a response. Alternatively, in other example embodiments, at 220a, gNB-CU1 may send a predicted cost request to gNB-DU1 to determine the predicted cost. Additionally, at 220b, gNB-DU1 may send a response to gNB-CU1 including the predicted cost.

[0043] At 230, if the predicted cost is less than the cost incurred by the UE to the requesting node, the latter may initiate a handover of the offloading plan to the neighboring gNB-CU1 at 235. However, if the predicted cost is higher, the requesting node may request another candidate gNB to obtain the expected cost for its offloading plan. The costs of offloading plans for different neighbors may be considered and the neighbor with the smallest cost (lowest cost) may be selected. In addition to comparing two costs to determine whether one cost value is strictly smaller than the other cost value, a threshold may be introduced to create different ways of comparing the costs, i.e., one cost value is different (smaller or larger) than the threshold of the other cost value. If none of the neighbors is a good offloading candidate, the requesting gNB may update the list of UEs in the offloading plan.

[0044] In response to the handover request sent by gNB-CU2, gNB-CU1 may send a UE context batch establishment request to gNB-DU1 at 240. According to certain example embodiments, the UE context batch establishment request may identify the number of UEs associated with the identified UEs, the (predicted) total guaranteed bit rate (GBR) resource requirement, the (predicted) total non-GBR resource requirement, and / or the (predicted) reservation time window. At 245, gNB-DU1 may send a response to the UE context batch establishment request, and the response includes the (predicted) total GBR resource availability and / or the (predicted) total non-GBR resource availability associated with the identified UEs. At 250, gNB-CU1 may send a response with a handover UE candidate list to gNB-CU2. At 255, for the candidate UE, a traditional per-UE handover preparation and execution process may be performed, the execution process including: a UE context establishment process between gNB-CU1 and gNB-DU1 at 260, and an RRC reconfiguration process between gNB-CU1 and (multiple) UEs at 265.

[0045] Figure 3 An example uninstallation planning process is illustrated in accordance with certain example embodiments. Figure 3 As shown in , the source node can prepare the offloading plan and group preparation at 300 and 305. The source node can also iteratively perform offloading plan exchanges with one or more targets (at different granularity levels) to ultimately achieve offloading plan completion with the minimum cost according to a metric (i.e., a cost metric). At 310, a traditional handover process for the candidate UE can be performed.

[0046] As described above, the offloading implementation may include: a mechanism for offloading plan preparation, and a mechanism for triggering the exchange of offloading plans between nodes. The source node may decide that there is a need for AI / ML actions (e.g., related to AI / ML load balancing or AI / ML energy saving). Upon deciding, the source node may prepare the offloading plan. According to some example embodiments, this may involve predicting the expected cost that a set of UEs will incur to the gNB to which they will be offloaded, and comparing that cost with the cost of these UEs in the current node. The source node may also perform batch resource reservation predictions (between two gNBs or two gNB-CUs via the Xn interface, or between a gNB-CU and a gNB-DU via the F1 interface), and finalize the candidate UE list and target cells. Upon finalization, the source node may trigger a traditional handover process for the candidate cells.

[0047] In offloading planning preparation (within the source node gNB or gNB-CU), the gNB may identify a set of UEs that are the most (or least) costly UEs for ML network operations. This may be evaluated by an (expected) cost (or reward / benefit) metric and may involve signaling between the gNB-CU and the gNB-DU in a split architecture. According to certain example embodiments, the UEs may be the UEs that contribute the most or least (cost) to the network energy consumption for a given load, or they are expected to contribute the most (cost) based on their movement towards the cell edge. Additionally, these UEs may be UEs located at the cell border with very little load to transmit. Therefore, the effective cost for these UEs with respect to energy efficiency may be very high. This may alternatively correspond to these UEs having very little benefit / reward with respect to energy efficiency.

[0048] In certain example embodiments, the identified UEs may be generating the largest load, or they may be expected to generate the largest load compared to other UEs. In addition, these UEs may include UEs whose load exceeds a threshold D(x) Mbps of data for UEEx in a given cell. In order to be able to identify these UEs, the gNB-CU may send a request to its gNB-DU to identify the N most costly UEs according to a cost metric, or to identify the N best (least costly) UEs according to a reward metric. As described above, the cost or reward metric may be (predicted) throughput, (predicted) latency, (predicted) amount of data, (predicted) BFR, (predicted) traffic, (predicted) energy efficiency, (predicted) energy consumption, (predicted) load, etc. These metrics may be related to the UEs identified as having the highest "cost". In certain example embodiments, some of the above metrics correspond to rewards (e.g., the offload action containing the UE that will result in the highest predicted energy efficiency is selected, etc.). In other example embodiments, some of these metrics correspond to costs (e.g., the offload action containing the UE that will result in the lowest (predicted) latency, lowest (predicted) BFR, or lowest (predicted) energy consumption is selected, to name a few). Along with the request, the gNB-CU may provide a threshold to the gNB-DU to allow the gNB-DU to return N UEs whose cost exceeds the threshold. For example, in certain example embodiments, if the threshold is set to D Mbps, then all UEs whose load is greater than D may be described as the most costly UEs to operate with respect to the network according to the load cost metric.

[0049] According to certain example embodiments, each gNB-DU may respond with a list of UEs corresponding to a handover candidate UE list, and the most costly UEs may be identified based on a cost metric. In certain example embodiments, these identified UEs may represent candidate UEs for offloading. The list may be a list ordered according to priority with respect to cost, i.e., the most costly UEs are listed first. According to certain example embodiments, the cost may also be expressed in terms of performance loss (e.g., due to a power down action at the gNB) for the set of UEs, such that the most impacted UEs are prioritized.

[0050] In certain example embodiments, the predicted cost may be related to an energy efficiency cost corresponding to a class of UEs. For example, in some example embodiments, the energy efficiency cost may be the (predicted) energy efficiency at a gNB (source or target) corresponding to a given class of UEs. The energy efficiency may be lower for UEs at the edge of a cell that require higher power to transmit a given amount of data. It may also be measured in terms of performance loss (e.g., throughput or latency, or the number of radio link failures (RLFs) experienced by a certain UE (or UE type) due to energy saving decisions (e.g., after a cell shutdown).

[0051] According to certain example embodiments, the load balancing cost corresponding to a class of UEs may correspond to the amount of (predicted) traffic or the (predicted) load at the gNB (source or target). In particular, UEs with a large amount of traffic may be classified as contributing more to the load balancing cost than other UEs.

[0052] As previously mentioned, in certain example embodiments, the offloading plan may be exchanged at different levels of granularity. For example, according to some example embodiments, one option for the offloading plan granularity may include an offloading plan with total resource requirements. Here, the source node may prepare an offloading plan including, for example, a specific subset of UEs and the total amount of resources required at the target cell. Additionally, the source node may trigger a group preparation process to the target node. For example, the group preparation process includes sending a UE list to the target node, as well as total GBR / non-GBR resource requirements, and the duration for which resources should not be allocated for other purposes (L3 mobility, etc.). In addition, according to this option, the target node may send a response after checking resource availability and a UE candidate list (considering the throughput of the UEs in the list). The source node may also trigger a handover preparation and execution process for a specific UE after receiving a response from the target node and selecting a suitable target node.

[0053] As another option for exchanging offloading plans at different levels of granularity, the offloading plan can be performed at the resource group level. For example, according to certain example embodiments, the source node may analyze the offloading plan based on resource usage and classify the UE into groups by the resource requirements of the UE. For example, the resource requirements may be related to the UE's demand for GBR resources and / or UEs with non-GBR resources. In some example embodiments, the group may be classified by group 1 (UE list, GBR-5Mps), group 2 (UE list, GBR-10Mbps), group 3 (UE list, non-GBR), etc. After classification, the source node may send (multiple) classified UE groups to the target node, after which the target node may check the resource availability of each group and the UE candidate list considering the throughput of the UE. In some example embodiments, the classification of the UE list itself may be optional. The target node may then send a response to the source node of the result (multiple) of the target node checking the resource availability of each group and the candidate list of the UE. After the source node receives the response from the target node, the source node may trigger the specific UE handover preparation and execution process of the candidate UE in the list (executed after selecting a suitable target node).

[0054] According to certain example embodiments, an offload plan exchange may occur between a source node and a target node. Here, the source node may identify a need to offload some or all UEs to a target node for some reason (e.g., AI / ML energy saving or AI / ML load balancing use case). This may be accomplished by a request by the gNB from a neighboring gNB to determine the expected cost that these UEs will incur to the target node if they are offloaded to the neighboring gNB. The cost may be evaluated based on the same metric that these UEs are evaluated for. In certain example embodiments, the gNB-CU may also request the expected cost of offloading from another gNB-DU to determine the best gNB-DU in the case of inter-DU offloading. The request may optionally or additionally include an option to provide the expected cost, assuming that only an "epsilon" cost will be incurred at the target node (e.g., an amount by which the cost exceeds a threshold). In certain example embodiments, the "epsilon" cost that will be incurred at the target node may cover the case where the cost at the target node is slightly above the threshold. In this option, the gNB-DU may be able to report this option as an optional or additional feature as well.

[0055] Upon receiving the request, the target node may perform additional reasoning on the use case-specific AI / ML model to ensure whether the group preparation is acceptable. With additional reasoning, the target node may perform reasoning from other AI / ML models (such as cell load prediction). This may help decide whether the node can accept the offloading plan. In other example embodiments, whether the group preparation is acceptable may refer to whether the offloading plan is acceptable. Additionally, group preparation may apply to offloading plans of any granularity. In certain example embodiments, the reasoning data may refer to a received load balancing handover resource reservation. The target node may also trigger mobility, load balancing, or energy saving (ES) handover reasoning. When performing these functions, the predicted load may be checked for other reasons (such as load balancing or energy saving). Such a prediction may be required before deciding whether the load generated by the offloading plan is acceptable. Additionally, considering the predicted mobility and ES switching, the target node can determine whether the load balancing handover resource reservation request is acceptable.

[0056] According to certain example embodiments, if, for one or more UEs, a neighboring gNB (e.g., a gNB-CU) responds with an expected / predicted cost that is less than the current cost, the gNB may add that UE (and possibly other UEs) to the offloading plan for the given neighboring gNB. In the case of inter-CU offloading, the source gNB (e.g., a gNB-CU) may initiate offloading of the identified UE(s) to the target gNB (e.g., a gNB-CU). However, in other example embodiments, in the case of inter-DU offloading, the source gNB-CU may initiate offloading of the identified UE(s) to another gNB-DU. In this case, the request (i.e., an offload request) may also indicate from the receiving node the amount of offloaded traffic (D(x)) that needs to be offloaded.

[0057] In certain example embodiments, before performing the UE-level handover execution process, certain processes may be required to enable end-to-end group-level preparation (including resource reservation at the DU of the corresponding target cell). For example, these processes may include an F1AP corresponding to an offload planning process (CU requested or DU triggered), an XnAP corresponding to a group handover request process, and an F1AP corresponding to a group context establishment process. According to certain example embodiments, group-level resource preparation may enable the CU to create a group (i.e., a UE list) to a target cell based on a resource status availability prediction (i.e., resource status availability at the target cell).

[0058] Figure 4 An example signal diagram for inter-DU offloading according to certain example embodiments is illustrated. In the case of intra-CU offloading, the gNB-CU may be able to determine the cost incurred by a set of UEs for a given DU to which they are connected. The gNB-CU may obtain cost information predicted by the gNB-DU, or the gNB-CU may obtain measurement information corresponding to the cost and perform the prediction itself.

[0059] At 400, the UE may camp on the cells of gNB-DU1 and gNB-DU2. At 405, the model reasoning function may trigger an offload from the cell of DU2 to the cell of DU1. At 410, the gNB-CU may send an offload plan request to gNB-DU2, and the request may include a handover UE candidate list (a list of UEs with the highest cost) and criteria for handover for each of the UEs in the list. At 415, gNB-DU2 may predict a cost metric based on the selected criteria included in the request from the gNB-CU. At 420, gNB-DU2 may send an offload plan response to the gNB-CU including the predicted cost, and include in the response a list of handover candidate UEs that meet the criteria set by the gNB-CU. At 425, the gNB-CU may send another predicted cost request to gNB-DU1, which may also include: a handover UE candidate list (a list of UEs with the highest cost), and criteria for handover for each of the UEs in the list. At 430, gNB-DU1 may predict the cost metric based on the selected criteria included in the second request from the gNB-CU. At 435, gNB-DU1 may send the predicted cost to the gNB-CU and include in the response a list of handover candidate UEs that meet the criteria set by the gNB-CU.

[0060] At 440, the gNB-CU may determine whether the predicted cost from gNB-DU1 is less than the predicted cost from gNB-DU2. At 445, if the predicted cost from gNB-DU1 is less than the predicted cost from gNB-DU2, the gNB-CU may initiate a handover offload plan to gNB-DU1. In certain example embodiments, the cost comparison may also be related to a threshold, i.e., comparing whether the predicted cost from gNB-DU1 is less than the predicted cost from gNB-DU2 by the threshold. In certain example embodiments, this may be accomplished by sending a UE Context Group Setup Request to gNB-DU1, which may include: the number of UEs, the total GBR resource requirement, the total non-GBR resource requirement, and / or a reserved time window for each of the UEs. In some example embodiments, the total GBR resource requirement, the total non-GBR resource requirement, and the reserved time window may all be predicted values. At 450, gNB-DU1 may send a UE Context Group Setup Response in response to the request from the gNB-CU. The UE context group establishment response may include: the (predicted) total GBR resource availability at gNB-DU1, and / or the (predicted) total non-GBR resource availability. At 455, the gNB-CU may prepare a handover UE candidate list. In other example embodiments, using the UE candidate list, the gNB-CU may perform offload plan exchange, as well as target node selection, offload plan preparation, and traditional handover. Operation 455 may represent the last step of performing a traditional handover procedure with a selected target for a given offload plan (set of UEs). At 460, a traditional handover preparation and execution procedure may be initiated for each UE. As Figure 4 As shown in , the conventional per-UE handover preparation and execution process may include a UE context establishment process between the gNB-CU and the gNB-DU1 at 465, and an RRC reconfiguration process between the gNB-CU and the UE at 470. In certain example embodiments, the UE may correspond to one of the UEs for which the conventional handover process is performed.

[0061] Figure 5 An example UE context group establishment request message according to certain example embodiments is illustrated. Specifically, Figure 5 The example message relates to a UE Context Group Establishment Request sent by the gNB-CU to the gNB-DU to enable group preparation. Figure 5 The table in presents the F1AP signaling message between the gNB-CU and the gNB-DU, which can be used to convey the total resource requirements corresponding to the offloading plan.

[0062] According to certain example embodiments, the AI / ML model is trained to maximize the spectral efficiency for the UE, and the energy efficiency for (multiple) cells, or to minimize the load of a given cell subject to UE performance constraints and minimize the energy consumption of the cell. In some example embodiments, the AI / ML model may identify specific UE distribution patterns that may lead to suboptimal spectral efficiency, as well as the reasons for suboptimal spectral efficiency (cell edge, etc.). Additionally, the AI / ML model may predict specific UE distribution patterns that may lead to suboptimal energy efficiency, as well as the reasons for suboptimal energy efficiency (more UEs at the cell edge, etc.). In certain example embodiments, the AI / ML may have the ability to infer an effective UE distribution that maximizes UE-level spectral efficiency and cell-level energy efficiency. The AI / ML may also have the ability to infer candidates for switching and monitor model performance by observing UE-level spectral efficiency and cell-level energy efficiency.

[0063] In certain example embodiments, for model training of AI / ML models, the criteria for the "most costly" UE may include: expected energy consumption or expected energy efficiency at the target, expected load at the target, spectral efficiency (i.e., a measure of the number of bits / second / Hz), and performance loss due to actions (e.g., energy saving). In other example embodiments, for model training of AI / ML models, cell-level energy efficiency PM counters may include the average number of RRC-connected UEs, UE distribution in cell coverage (cell center / cell edge), cell power, UE throughput PM counters, and ULPDCP SDU data volume measurements. Other target data collection for training and inference phases may include: UE RRM measurements, and resource status of neighboring cells.

[0064] Figure 6 An example flow chart of a method according to certain example embodiments is illustrated. In an example embodiment, Figure 6 Method 6 may be performed by a network entity or a group of multiple network elements in a 3GPP system (such as LTE or 5G-NR). For example, in an example embodiment, Figure 6 The method may be performed by the network, a network node, a gNB, or a similar Figure 8 The method is performed by an apparatus of one of the apparatuses 10 or 20 shown in FIG.

[0065] According to certain example embodiments, Figure 6The method may include: at 600, determining, by a first network node, a need for offloading at the first network node. In certain example embodiments, mobility optimization may include: offloading one or more UEs triggered by one of AIML-enabled use cases (e.g., network energy saving, load balancing, and mobility optimization). At 605, the method may include: sending a first request to a second network node for a cost metric associated with one or more user devices connected to the first network node and to be offloaded. In addition, at 610, the method may include: receiving a cost metric and a list of one or more user devices associated with the cost metric. In addition, at 615, the method may include: sending a second request to a third network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the third network node. However, in other example embodiments, the offloading requests may be triggered in parallel. For example, in an example embodiment, after receiving responses from all nodes, the first network node may select the UE to be offloaded. At 620, the method may also include: receiving the predicted cost metric in response to the second request. Additionally, at 625, the method may include initiating offloading of one or more user equipment in the list to the second network node or the third network node based on which node has the lowest cost metric.

[0066] According to some example embodiments, the cost metric corresponds to at least one of the following: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or corresponds to a reward corresponding to at least one of the following: a cell-level data volume, an energy efficiency, or a traffic load. According to some example embodiments, the first request may be sent with a threshold value, the threshold value being related to the cost metric. According to other example embodiments, the list may be an ordered list according to a priority of the cost metric for each of the one or more user equipment.

[0067] In certain example embodiments, offloading may include: a subset of one or more user devices, and a total amount of resources required at the second network node, or one or more categories of user devices, wherein each of the categories is separated based on resource usage, and the resource requirements of the one or more user devices include: user devices based on resource categories, such as guaranteed bit rate resources; or user devices with non-guaranteed bit rate resources. In some cases, when the predicted cost metric is greater than the cost metric, the method may also include: requesting the expected cost of offloading to the fourth network node from the fourth network node. In other example embodiments, the method may also include: updating the list of one or more user devices when there is no acceptable offloading candidate network node for the one or more user devices.

[0068] Figure 7 An example of a flow chart of another method according to certain example embodiments is shown. In an example embodiment, Figure 7 The method may be performed by a network entity or a plurality of network element groups in a 3GPP system (such as LTE or 5G-NR). For example, in an example embodiment, Figure 7 The method can be similar to Figure 8 The method is performed by a network, a network node, or a gNB of one of the devices 10 or 20 shown in FIG.

[0069] According to certain example embodiments, Figure 7 The method may include, at 700, receiving, at a second network node, from a first network node a request and a list of one or more user devices for a predicted cost metric associated with the one or more user devices in the list when connected to the second network node. At 705, the method may include, at the second network node, checking resource availability of the one or more user devices in the list. In addition, at 710, the method may include sending a response to the request to the first network node. In certain example embodiments, the response may include a predicted cost metric associated with the one or more user devices in the list. At 715, the method may include receiving, from the first network node, an uninstallation of the one or more user devices in the list.

[0070] According to some example embodiments, the predicted cost metric corresponds to at least one of the following: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or corresponds to a reward corresponding to at least one of the following: a cell-level data volume, an energy efficiency, or a traffic load. According to some example embodiments, the list may be an ordered list according to a priority of the cost metric with respect to each of the one or more user equipment. According to other example embodiments, the offloading may include: a subset of the one or more user equipment, and a total amount of resources required at the second network node, or one or more categories of user equipment, wherein each of the categories is separated based on resource usage, and the resource requirements of the one or more user equipment include: user equipment with guaranteed bit rate resources, or user equipment with non-guaranteed bit rate resources.

[0071] Figure 8 1 shows a collection of apparatuses 10 and apparatuses 20 according to some example embodiments. In some example embodiments, apparatus 10 may be a node or element in a communication network or associated with such a network, such as a UE, a mobile device (ME), a mobile station, a mobile device, a fixed device, an IoT device, or other device. It should be noted that a person skilled in the art will understand that apparatus 10 may include Figure 8 Components or features not shown.

[0072] In some example embodiments, the apparatus 10 may include: one or more processors, one or more computer-readable storage media (e.g., memory, storage, etc.), one or more radio access components (e.g., modems, transceivers, etc.), and / or a user interface. In some example embodiments, the apparatus 10 may be configured to operate using one or more radio access technologies (such as GSM, LTE, LTE-A, NR, 5G, WLAN, WiFi, NB-IoT, Bluetooth, NFC, MulteFire, and / or any other radio access technology). It should be noted that a person of ordinary skill in the art will understand that the apparatus 10 may include Figure 8 Components or features not shown.

[0073] like Figure 8 As shown in the example of , the device 10 may include or be coupled to a processor 12 for processing information and executing instructions or operations. The processor 12 may be any type of general or special purpose processor. In fact, as an example, the processor 12 may include one or more of the following: a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and a processor based on a multi-core processor architecture. Although Figure 8 A single processor 12 is shown in FIG. 1 , but multiple processors may be used according to other example embodiments. For example, it should be understood that in some example embodiments, the apparatus 10 may include two or more processors capable of forming a multiprocessor system that can support multiprocessing (e.g., in which case the processor 12 may represent a multiprocessor). According to some example embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).

[0074] Processor 12 may perform functions associated with the operation of device 10, which may include, for example, precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming communication messages, formatting of information, and overall control of device 10, including Figures 1 to 5 The process is shown in the figure.

[0075] The device 10 may also include or be coupled to a memory 14 (internal or external), which may be coupled to the processor 12 for storing information and instructions that may be executed by the processor 12. The memory 14 may be one or more memories and any type suitable for the local application environment, and may be implemented using any suitable volatile or non-volatile data storage technology (such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and / or removable memory). For example, the memory 14 may be composed of any combination of random access memory (RAM), read-only memory (ROM), static memory (such as a magnetic or optical disk, a hard disk drive (HDD)), or any other type of non-transitory machine or computer readable medium. The instructions stored in the memory 14 may include program instructions or computer program code that, when executed by the processor 12, enables the device 10 to perform the tasks described herein.

[0076] In certain example embodiments, the apparatus 10 may also include or be coupled to a (internal or external) drive or port configured to accept and read an external computer-readable storage medium, such as an optical disk, a USB drive, a flash drive, or any other storage medium. For example, the external computer-readable storage medium may store a computer program or software for execution by the processor 12 and / or the apparatus 10 to perform operations in the Figures 1 to 5 Any method shown in .

[0077] In some example embodiments, the apparatus 10 may also include or be coupled to one or more antennas 15 for receiving downlink signals from the apparatus 10 and for transmitting from the apparatus 10 via an uplink. The apparatus 10 may also include a transceiver 18 configured to send and receive information. The transceiver 18 may also include a radio interface (e.g., a modem) coupled to the antenna 15. The radio interface may correspond to a variety of radio access technologies including one or more of the following: GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, Bluetooth, BT-LE, NFC, RFID, UWB, etc. The radio interface may include other components (such as filters, converters (e.g., digital-to-analog converters, etc.), symbol demappers, single shaping components, inverse fast Fourier transform (IFFT) modules, etc.) to process symbols (such as OFDMA symbols) carried by a downlink or uplink.

[0078] For example, the transceiver 18 may be configured to modulate information onto a carrier waveform for transmission by (multiple) antennas 15, and to demodulate information received via (multiple) antennas 15 for further processing by other elements of the apparatus 10. In other example embodiments, the transceiver 18 may be capable of directly sending and receiving signals or data. Additionally or alternatively, in some example embodiments, the apparatus 10 may include input and / or output devices (I / O devices). In certain example embodiments, the apparatus 10 may also include a user interface, such as a graphical user interface or a touch screen.

[0079] In certain example embodiments, the memory 14 may store software modules that provide functionality when executed by the processor 12. The software modules may include, for example, an operating system that provides operating system functionality for the device 10. The memory may also store one or more functional modules (such as applications or programs) to provide additional functionality for the device 10. The components of the device 10 may be implemented in hardware, or as any suitable combination of hardware and software. According to certain example embodiments, the device 10 may optionally be configured to communicate with the device 20 via a wireless or wired communication link 70 according to any radio access technology (such as NR).

[0080] According to some example embodiments, processor 12 and memory 14 may be included in, or may form part of, processing circuitry or control circuitry. In addition, in some example embodiments, transceiver 18 may be included in, or may form part of, transceiver circuitry.

[0081] like Figure 8 As shown in the example of , the device 20 may be a network, a core network element, or an element in a communication network or associated with such a network or network node (such as a gNB). It should be noted that a person skilled in the art will understand that the device 20 may include Figure 8 Components or features not shown.

[0082] like Figure 8 As shown in the example of , the device 20 may include a processor 22 for processing information and executing instructions or operations. The processor 22 may be any type of general or special purpose processor. For example, as an example, the processor 22 may include one or more of the following items: a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), and a processor based on a multi-core processor architecture. Although Figure 8A single processor 22 is shown in FIG. 1 , but multiple processors may be utilized according to other example embodiments. For example, it should be understood that in some example embodiments, the apparatus 20 may include two or more processors capable of forming a multiprocessor system that can support multiprocessing (e.g., in which case the processor 22 may represent a multiprocessor). In some example embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).

[0083] According to certain example embodiments, processor 22 may perform functions associated with the operation of device 20, which may include, for example, precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming communication messages, formatting of information, and overall control of device 20, including Figures 1 to 7 The process is shown in the figure.

[0084] The device 20 may also include or be coupled to a memory 24 (internal or external), which may be coupled to the processor 22 for storing information and instructions that can be executed by the processor 22. The memory 24 may be one or more memories and any type suitable for the local application environment, and may be implemented using any suitable volatile or non-volatile data storage technology (such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and / or removable memory). For example, the memory 24 may be composed of any combination of random access memory (RAM), read-only memory (ROM), static memory (such as a magnetic or optical disk, a hard disk drive (HDD)), or any other type of non-transitory machine or computer readable medium. The instructions stored in the memory 24 may include program instructions or computer program codes that, when executed by the processor 22, enable the device 20 to perform the tasks described herein.

[0085] In certain example embodiments, the apparatus 20 may also include or be coupled to a (internal or external) drive or port configured to accept and read an external computer-readable storage medium, such as an optical disk, a USB drive, a flash drive, or any other storage medium. For example, the external computer-readable storage medium may store a computer program or software for execution by the processor 22 and / or the apparatus 20 to perform Figures 1 to 7 The method shown in .

[0086] In certain example embodiments, the apparatus 20 may also include or be coupled to one or more antennas 25 for sending and receiving signals and / or data to and from the apparatus 20. The apparatus 20 may also include or be coupled to a transceiver 28 configured to send and receive information. The transceiver 28 may include, for example, a plurality of radio interfaces that may be coupled to (a plurality of) antennas 25. The radio interfaces may correspond to a variety of radio access technologies, including one or more of the following: GSM, NB-IoT, LTE, 5G, WLAN, Bluetooth, BT-LE, NFC, Radio Frequency Identification (RFID), Ultra-Wideband (UWB), MulteFire, etc. The radio interfaces may include components such as filters, converters (e.g., digital-to-analog converters, etc.), mappers, Fast Fourier Transform (FFT) modules, etc., to generate symbols for transmission via one or more downlinks, and to receive symbols (e.g., via an uplink).

[0087] Thus, the transceiver 28 may be configured to modulate information onto a carrier waveform for transmission by the antenna(s) 25, and to demodulate information received via the antenna(s) 25 for further processing by other elements of the apparatus 20. In other example embodiments, the transceiver 18 may be capable of directly sending and receiving signals or data. Additionally or alternatively, in some example embodiments, the apparatus 20 may include input and / or output devices (I / O devices).

[0088] In certain example embodiments, memory 24 may store software modules that provide functionality when executed by processor 22. The software modules may include, for example, an operating system that provides operating system functionality for apparatus 20. The memory may also store one or more functional modules, such as applications or programs, to provide additional functionality for apparatus 20. The components of apparatus 20 may be implemented in hardware, or as any suitable combination of hardware and software.

[0089] According to some example embodiments, processor 22 and memory 24 may be included in processing circuitry or control circuitry, or may form part of processing circuitry or control circuitry. In addition, in some example embodiments, transceiver 28 may be included in transceiver circuitry, or may form part of transceiver circuitry.

[0090] As used in this application, the term "circuitry" may refer to a hardware circuit implementation only (e.g., analog and / or digital circuitry); a combination of hardware circuitry and software; a combination of analog and / or digital hardware circuitry and software / firmware; any portion of a (multiple) hardware processor (including a digital signal processor) with software that works together to enable a device (e.g., device 10 and device 20) to perform various functions; and / or (multiple) hardware circuits and / or (multiple) processors or portions thereof that require software to operate, but where the software may not be present. As a further example, as used in this application, the term "circuitry" also encompasses an implementation of only a hardware circuit or processor (or multiple processors) or portions of a hardware circuit or processor and their accompanying software and / or firmware. The term circuitry also encompasses, for example, a baseband integrated circuit in a server, a cellular network node or device, or other computing or network device.

[0091] For example, in certain example embodiments, the apparatus 20 may be controlled by the memory 24 and the processor 22 to determine a need for offloading at the apparatus. The apparatus 20 may also be controlled by the memory 24 and the processor 22 to send a first request to a first network node for a cost metric associated with one or more user devices connected to the apparatus and to be offloaded. The apparatus 20 may also be controlled by the memory 24 and the processor 22 to receive a cost metric and a list of one or more user devices associated with the cost metric. The apparatus 20 may also be controlled by the memory 24 and the processor 22 to send a second request to a second network node, and a list of one or more user devices, for a predicted cost metric associated with one or more user devices in the list when connected to the second network node. In addition, the apparatus 20 may be controlled by the memory 24 and the processor 22 to receive the predicted cost metric in response to the second request. In addition, the apparatus 20 may be controlled by the memory 24 and the processor 22 to initiate offloading of one or more user devices in the list to the second network node or the third network node based on which node has the lowest cost metric.

[0092] In other example embodiments, the apparatus 20 may be controlled by the memory 24 and the processor 22 to receive a request from a first network node, and a list of one or more user devices, the predicted cost metrics associated with the one or more user devices in the list when connected to the apparatus. The apparatus 20 may also be controlled by the memory 24 and the processor 22 to check resource availability of the one or more user devices in the list at the apparatus. The apparatus 20 may also be controlled by the memory 24 and the processor 22 to send a response to the request to the first network node. According to certain example embodiments, the response may include: a predicted cost metric associated with the one or more user devices in the list. The apparatus 20 may also be controlled by the memory 24 and the processor 22 to receive an uninstallation of the one or more user devices in the list from the first network node.

[0093] In some example embodiments, an apparatus (e.g., apparatus 10 and / or apparatus 20) may include a component for performing a method, process, or any variant discussed herein. Examples of the component may include one or more processors, memories, controllers, transmitters, receivers, and / or computer program codes for causing operations to be performed.

[0094] Certain example embodiments may be directed to an apparatus including components for performing any of the methods described herein, the apparatus including, for example, components for determining a need for offloading at the apparatus. The apparatus may also include components for sending a first request to a first network node for a cost metric associated with one or more user devices that are connected to the apparatus and are to be offloaded. The apparatus may also include components for sending a second request to a second network node, and a list of one or more user devices, for predicted cost metrics associated with one or more user devices in the list when connected to the second network node. In addition, the apparatus may include components for receiving the predicted cost metric in response to the second request. In addition, the apparatus may include components for initiating offloading of one or more user devices in the list to the second network node or a third network node based on which node has the lowest cost metric.

[0095] Certain example embodiments may also be directed to an apparatus, the apparatus comprising: means for receiving a request from a first network node, and a list of one or more user devices, for a predicted cost metric associated with the one or more user devices in the list when connected to the apparatus. The apparatus may also include: means for checking resource availability of the one or more user devices in the list at a second network node. The apparatus may also include: means for sending a response to the request to the first network node, according to certain example embodiments, the response may include: the predicted cost metric associated with the one or more user devices in the list. In addition, the apparatus may include: means for receiving, from the first network node, an uninstallation of the one or more user devices in the list.

[0096] Certain example embodiments described herein provide several technical improvements, enhancements, and / or advantages. For example, in some example embodiments, the AIML model can maximize the spectral efficiency of the UE and the energy efficiency of (multiple) cells, or minimize the load of a given cell limited by UE performance. In other example embodiments, the AIML model can identify specific UE distribution patterns and their causes (cell edges, etc.) that may lead to suboptimal spectral efficiency. Additionally, in some example embodiments, the AIML model can predict specific UE distribution patterns and their causes (e.g., more UEs at the cell edges, etc.) that may lead to suboptimal energy efficiency.

[0097] Certain example embodiments may also simplify the specification and gNB and UE operations. For example, for certain example embodiments, since the DCI size is fixed, the gNB and UE do not need to calculate all possible DCI sizes (through all possible scheduling combinations) before decoding the DCI based on the latest status of the schedulable DL (or UL) serving cells. Additionally, since the DCI size is constant, the implementation and operation of the gNB DL control scheduler may be simplified.

[0098] According to further example embodiments, the gNB may be allowed to schedule a larger or smaller number of cells depending on the current number of required cell-specific DCI bits for each of the scheduled cells. Additionally, certain example embodiments may allow the gNB to trade off cell-specific scheduling flexibility (in terms of common / cell-specific DCI fields, and number of scheduled cells) while having full control over the associated DCI size, and the associated required number of DL control resources, and the associated DCI decoding reliability.

[0099] The computer program product may include one or more computer executable components that are configured to perform some example embodiments when the program is run. The one or more computer executable components may be at least one software code or part thereof. Modifications and configurations required to implement the functionality of some example embodiments may be performed as (multiple) routines, which may be implemented as added or updated (multiple) software routines. (Multiple) software routines may be downloaded to a device.

[0100] As an example, software or computer program code or part thereof may be in source code form, object code form, or some intermediate form, and it may be stored in some carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. For example, such carriers may include recording media, computer memory, read-only memory, optoelectronic and / or electrical carrier signals, telecommunication signals, and software distribution packages. Depending on the processing power required, the computer program may be executed in a single electronic digital computer or distributed among multiple computers. The computer readable medium or computer readable storage medium may be a non-transitory medium.

[0101] In other example embodiments, the functionality may be performed by hardware or circuitry included in a device (e.g., device 10 or device 20), such as by using an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In another example embodiment, the functionality may be implemented as a signal, a non-tangible component that may be carried by an electromagnetic signal downloaded from the Internet or other network.

[0102] According to certain example embodiments, an apparatus (such as a node, a device or a corresponding component) may be configured as a circuit system, a computer, or a microprocessor (such as a single-chip computer element), or a chipset, which includes at least a memory for providing storage capacity for arithmetic operations, and an operation processor for performing arithmetic operations.

[0103] A person of ordinary skill in the art will readily appreciate that the disclosure as discussed above may be implemented using processes in a different order, and / or using hardware elements in a different configuration than that disclosed. Therefore, although some implementations have been described based on these example embodiments, a person of ordinary skill in the art will appreciate that certain modifications, variations, and alternative structures will be apparent while remaining within the spirit and scope of the example embodiments. Although the above embodiments relate to 5G NR and LTE technologies, the above embodiments may also be applicable to any other existing or future 3GPP technologies, such as Advanced LTE and / or fourth generation (4G) technologies.

[0104] Partial glossary:

[0105] 3GPP Third Generation Partnership Project

[0106] 5G Fifth Generation

[0107] 5GCN 5G Core Network

[0108] 5GS 5G System

[0109] BFR Beam Failure Recovery

[0110] BS Base Station

[0111] CU Centralized Unit

[0112] DL Downlink

[0113] DU Distributed Unit

[0114] gNB 5G or Next Generation NodeB

[0115] HO Switchover

[0116] LTE Long Term Evolution

[0117] NR New Radio

[0118] RAN Radio Access Network

[0119] RRC Radio Resource Control

[0120] UE User Equipment

[0121] UL Uplink

Claims

1. A method comprising: determining, by a first network node, a need for offloading at the first network node; sending a first request to a second network node for a cost metric associated with one or more user equipment connected to the first network node and to be offloaded; receiving the cost metric and a list of the one or more user devices associated with the cost metric; sending a second request, together with the list of the one or more user equipment, to a third network node for a predicted cost metric associated with the one or more user equipment in the list when connected to the third network node; receiving, in response to the second request, the predicted cost metric; as well as Offloading of the one or more user equipments in the list is initiated towards the second network node or a third network node based on which node has the lowest cost metric.

2. The method according to claim 1, wherein the cost metric corresponds to at least one of: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or The cost metric corresponds to a reward corresponding to at least one of: data volume, energy efficiency, or traffic load at a cell level.

3. The method according to claim 1 or 2, wherein the first request is sent together with a threshold value, the threshold value being related to the cost metric.

4. The method according to any one of claims 1 to 3, wherein the list is an ordered list according to a priority of the cost metric for each of the one or more user equipments.

5. The method according to any one of claims 1 to 4, wherein the uninstalling comprises: a subset of the one or more user equipments, and the total amount of resources required at the second network node, or The one or more user equipment categories, wherein each of the categories is separated based on resource usage, and the resource requirements of the one or more user equipment include: user equipment based on resource category, such as guaranteed bit rate resources; or user equipment with non-guaranteed bit rate resources.

6. The method according to any one of claims 1 to 5, when the predicted cost metric is greater than the cost metric, the method further comprises: An expected cost of offloading to the fourth network node is requested from the fourth network node.

7. The method according to any one of claims 1 to 6, further comprising: When there are no acceptable offloading candidate network nodes for the one or more user equipments, the list of the one or more user equipments is updated.

8. A method comprising: receiving, at a second network node, a request from a first network node and a list of one or more user equipment for a predicted cost metric associated with the one or more user equipment in the list when connected to the second network node; checking, at the second network node, resource availability of the one or more user equipments in the list; sending a response to the request to the first network node, wherein the response comprises: the predicted cost metric associated with the one or more user equipment in the list; as well as An uninstallation of the one or more user equipments in the list is received from the first network node.

9. The method according to claim 8, wherein the predicted cost metric corresponds to at least one of: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or The cost metric corresponds to a reward corresponding to at least one of: data volume, energy efficiency, or traffic load at a cell level.

10. The method of claim 8 or 9, wherein the list is an ordered list according to a priority of the cost metric for each of the one or more user equipments.

11. The method according to any one of claims 8 to 10, wherein the uninstalling comprises: a subset of the one or more user equipments, and the total amount of resources required at the second network node, or The one or more categories of user equipment, wherein each of the categories is separated based on resource usage, and resource requirements of the one or more user equipment include: user equipment with guaranteed bit rate resources or user equipment with non-guaranteed bit rate resources.

12. An apparatus comprising: at least one processor; as well as at least one memory including computer program code, The at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to at least perform: determining a need for offloading at the device; sending a first request to a first network node for a cost metric associated with one or more user equipment connected to the apparatus and to be offloaded; receiving the cost metric and a list of the one or more user devices associated with the cost metric; sending a second request, together with the list of the one or more user equipment, to a second network node for predicted cost metrics associated with the one or more user equipment in the list when connected to the second network node; receiving, in response to the second request, the predicted cost metric; as well as Offloading of the one or more user equipments in the list is initiated towards the second network node or a third network node based on which node has the lowest cost metric.

13. The device according to claim 12, wherein the cost metric corresponds to at least one of: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or The cost metric corresponds to a reward corresponding to at least one of: data volume, energy efficiency, or traffic load at a cell level.

14. An apparatus according to claim 12 or 13, wherein the first request is sent together with a threshold value, the threshold value being related to the cost metric.

15. The apparatus according to any one of claims 12 to 14, wherein the list is an ordered list according to a priority of the cost metric for each of the one or more user equipments.

16. The apparatus according to any one of claims 12 to 15, wherein the unloading comprises: a subset of the one or more user equipments, and the total amount of resources required at the second network node, or The one or more user equipment categories, wherein each of the categories is separated based on resource usage, and the resource requirements of the one or more user equipment include: user equipment based on resource category, such as guaranteed bit rate resources; or user equipment with non-guaranteed bit rate resources.

17. The apparatus of any one of claims 12 to 16, when the predicted cost metric is greater than the cost metric, the at least one memory and the computer program code are further configured to store instructions that, when executed by the at least one processor, cause the apparatus to at least perform: An expected cost of offloading to the third network node is requested from the third network node.

18. The apparatus according to any one of claims 12 to 17, wherein the at least one memory and the computer program code are further configured to store instructions which, when executed by the at least one processor, cause the apparatus to at least perform: When there are no acceptable offloading candidate network nodes for the one or more user equipments, the list of the one or more user equipments is updated.

19. An apparatus comprising: at least one processor; as well as at least one memory including computer program code, The at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to at least perform: receiving a request from a first network node, and a list of one or more user equipment for a predicted cost metric associated with the one or more user equipment in the list when connected to the apparatus; at the apparatus, checking resource availability of the one or more user equipment in the list; sending a response to the request to the first network node, wherein the response comprises: the predicted cost metric associated with the one or more user equipment in the list; as well as An uninstallation of the one or more user equipments in the list is received from the first network node.

20. The device according to claim 19, wherein the predicted cost metric corresponds to at least one of: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or The cost metric corresponds to a reward corresponding to at least one of: data volume, energy efficiency, or traffic load at a cell level.

21. The apparatus of claim 19 or 20, wherein the list is an ordered list according to a priority of the cost metric for each of the one or more user equipments.

22. The apparatus according to any one of claims 19 to 21, wherein the unloading comprises: a subset of the one or more user equipments, and the total amount of resources required at the apparatus, or The one or more categories of user equipment, wherein each of the categories is separated based on resource usage, and resource requirements of the one or more user equipment include: user equipment with guaranteed bit rate resources or user equipment with non-guaranteed bit rate resources.

23. A non-transitory computer readable medium comprising stored thereon program instructions for performing a method, the method comprising: determining a need for offloading at the device; sending a first request to a first network node for a cost metric associated with one or more user equipment connected to the apparatus and to be offloaded; receiving the cost metric and a list of the one or more user devices associated with the cost metric; sending a second request, together with the list of the one or more user equipment, to a second network node for predicted cost metrics associated with the one or more user equipment in the list when connected to the second network node; receiving, in response to the second request, the predicted cost metric; as well as Offloading of the one or more user equipments in the list is initiated towards the second network node or a third network node based on which node has the lowest cost metric.

24. The non-transitory computer readable medium of claim 23, wherein the cost metric corresponds to at least one of: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or The cost metric corresponds to a reward corresponding to at least one of: data volume, energy efficiency, or traffic load at a cell level.

25. The non-transitory computer readable medium of claim 23 or 24, wherein the first request is sent with a threshold value, the threshold value being related to the cost metric.

26. The non-transitory computer-readable medium of any one of claims 23 to 25, wherein the list is an ordered list according to a priority of the cost metric for each of the one or more user devices.

27. The non-transitory computer readable medium of any one of claims 23 to 26, wherein the unloading comprises: a subset of the one or more user equipments, and the total amount of resources required at the first network node, or The one or more user equipment categories, wherein each of the categories is separated based on resource usage, and the resource requirements of the one or more user equipment include: user equipment based on resource category, such as guaranteed bit rate resources; or user equipment with non-guaranteed bit rate resources.

28. The non-transitory computer readable medium of any one of claims 23 to 27, when the predicted cost metric is greater than the cost metric, the at least one memory and the method further comprising: An expected cost of offloading to the third network node is requested from the third network node.

29. The non-transitory computer readable medium of any one of claims 23 to 28, wherein the method further comprises: When there are no acceptable offloading candidate network nodes for the one or more user equipments, the list of the one or more user equipments is updated.

30. A non-transitory computer readable medium comprising stored thereon program instructions for performing a method, the method comprising: receiving a request from a first network node, and a list of one or more user equipment for a predicted cost metric associated with the one or more user equipment in the list when connected to the apparatus; at the apparatus, checking resource availability of the one or more user equipment in the list; sending a response to the request to the first network node, wherein the response comprises: the predicted cost metric associated with the one or more user equipment in the list; as well as An uninstallation of the one or more user equipments in the list is received from the first network node.

31. The non-transitory computer readable medium of claim 30, wherein the predicted cost metric corresponds to at least one of: a throughput value, a data volume, or a beam failure recovery metric associated with one or more user equipment in the list, or The cost metric corresponds to a reward corresponding to at least one of: data volume, energy efficiency, or traffic load at a cell level.

32. The non-transitory computer readable medium of claim 30 or 31, wherein the list is an ordered list according to a priority of the cost metric for each of the one or more user devices.

33. The non-transitory computer readable medium of any one of claims 30 to 32, wherein the unloading comprises: a subset of the one or more user equipments, and the total amount of resources required at the apparatus, or The one or more categories of user equipment, wherein each of the categories is separated based on resource usage, and resource requirements of the one or more user equipment include: user equipment with guaranteed bit rate resources or user equipment with non-guaranteed bit rate resources.

34. An apparatus comprising circuitry configured to cause the apparatus to perform a process according to any one of claims 1 to 11.

Images