CN120730474A

CN120730474A - Support for expected resource management between slices

Info

Publication number: CN120730474A
Application number: CN202510205565.1A
Authority: CN
Inventors: A·潘特利杜; H·海尔默斯; P·戈丁
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2024-03-28
Filing date: 2025-02-24
Publication date: 2025-09-30
Also published as: GB202404534D0; GB2639947A

Abstract

The present invention relates to support for expected resource management between slices, and proposes a method comprising receiving, by a first apparatus, a first message comprising a request for predicted User Equipment (UE) traffic per cell for a second apparatus. The first device determines a predicted UE traffic per cell for the second device and sends a second message to the second device, the second message including a report of the predicted UE traffic per cell.

Description

Support for expected resource management between slices

Technical Field

Various example embodiments relate generally to wireless networks and, more particularly, to support for desired resource management between slices.

Background

Actions that may be used to perform resource management between slices in a next generation radio access network (NG-RAN) include actions that are used for load balancing (e.g., offloading to other frequency layers (inter-frequency handover) or cell activation) in the event that network capacity decreases due to power saving actions. However, such actions may be costly (e.g., in terms of energy consumption and/or temporary service interruption of the UE involved) and may be delayed to allow the required load balancing actions to be performed.

If most of the resources of the NG-RAN node are allocated to slices that require resource isolation, this may result in additional demands on the resource allocation between other supported slices that are not affected by the resource isolation.

Disclosure of Invention

In an aspect of the disclosure, a method includes receiving, by a first apparatus, a first message including a request for predicted User Equipment (UE) traffic per cell of a second apparatus. The first device determines a predicted UE traffic per cell for the second device and sends a second message to the second device, the second message including a report of the predicted UE traffic per cell.

In one aspect of the method, the first message is received from the second device.

In an aspect of the method, the second message includes a report of predicted UE traffic per cell per network slice.

In an aspect of the method, the predicted UE traffic per cell is traffic incoming to the first device and destined for the second device.

In an aspect of the method, the first message includes a request for predicted UE traffic for at least a first UE of the one or more UEs.

In an aspect of the method, the first message includes a request for predicted UE traffic for a specified period of time, and wherein the second message includes an average amount of predicted UE traffic per cell averaged over the specified period of time.

In an aspect of the method, the first message includes a request for predicted UE traffic for a particular time.

In an aspect of the method, the first message comprises a request for predicted UE traffic for a cell list, and wherein the second message comprises predicted UE traffic for a cell indicated by the cell list.

In an aspect of the method, the first message includes a request for predicted UE traffic for a slice list, and wherein the second message includes predicted UE traffic for a slice indicated by the slice list.

In an aspect of the method, predicting UE traffic includes traffic throughput.

In one aspect of the method, the method further includes receiving, by the second apparatus, a second message from the first apparatus, the second message including a report of the predicted UE traffic per cell, and performing load balancing between cells based on the received report of the predicted UE traffic per cell.

In one aspect of the method, the method further includes receiving, by the second apparatus, a second message from the first apparatus, the second message including a report of the predicted UE traffic per cell per slice, and performing a slice reconfiguration or remapping action based on the received report of the predicted UE traffic per cell.

In an aspect of the method, the first message includes a request for predicted UE traffic for at least a first UE of the one or more UEs, wherein the second message includes predicted UE traffic for the first UE for a first cell of the second apparatus, and wherein the second apparatus estimates traffic demand of the first UE in case the first UE enters the first cell of the second apparatus based on the predicted UE traffic for the first UE.

In an aspect of the method, the first device is a first network node controlling a first set of cells and the second device is a second network node controlling a second set of cells, and wherein at least one cell of the first set of cells is a neighboring cell of at least one cell of the second set of cells.

In an aspect of the disclosure, an apparatus includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform at least any of the foregoing methods.

In an aspect of the disclosure, a processor-readable medium stores instructions that, when executed by at least one processor of an apparatus, cause the apparatus to perform at least any of the foregoing methods.

According to some aspects, the subject matter of the independent claims is provided. Further aspects are defined in the dependent claims.

Drawings

Some example embodiments will now be described with reference to the accompanying drawings.

Fig. 1 is a diagram of an example embodiment of wireless networking between a network system and a User Equipment (UE) in accordance with an illustrative aspect of the present disclosure;

FIG. 2 is a diagram of example components of a network system in accordance with one illustrative aspect of the present disclosure;

FIG. 3 is an illustration of an example network that enables reporting per-slice traffic predictions among nodes in accordance with an illustrative aspect of the disclosure;

FIG. 4 is a diagram of an example network implementing per-slice traffic prediction among nodes in accordance with an illustrative aspect of the present disclosure;

Fig. 5 is a diagram of an example embodiment of signals and operations within an NG-RAN in accordance with an illustrative aspect of the present disclosure;

Fig. 6 is a diagram of an example embodiment of signals and operations among a UE, a gNB-CU-CP and a gNB-CU-UP, according to one illustrative aspect of the disclosure;

FIG. 7 is a diagram of an example embodiment of signals and operations in a NG-RAN in accordance with another illustrative aspect of the disclosure, an

Fig. 8 is a diagram of an example embodiment of components of a UE or network device in accordance with one illustrative aspect of the present disclosure.

Detailed Description

In the following description, certain specific details are set forth in order to provide a thorough understanding of the disclosed aspects. One skilled in the relevant art will recognize, however, that aspects may be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures associated with transmitters, receivers, or transceivers have not been shown or described in detail to avoid unnecessarily obscuring the description of the various aspects.

Reference throughout this specification to "one aspect" or "an aspect" means that a particular feature, structure, or characteristic described in connection with the aspect is included in at least one aspect. Thus, the appearances of the phrase "in one aspect" or "in one aspect" in various places throughout this specification are not necessarily all referring to the same aspect. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more aspects.

Embodiments described in this disclosure may be implemented in wireless networking devices such as, but not limited to, devices that utilize global interoperability for microwave access (WiMAX), global system for mobile communications (GSM, 2G), GSM EDGE Radio Access Network (GERAN), general packet radio service (GRPS), universal mobile telecommunications system based on basic wideband code division multiple access (W-CDMA) (UMTS, 3G), high Speed Packet Access (HSPA), long Term Evolution (LTE), LTE-advanced (ehte), 5G new radio (5G NR), 5G advanced, 6G (and above), and 802.11ax (Wi-Fi 6) among other wireless networking systems. The term "eLTE" herein denotes the LTE evolution connected to the 5G core. LTE is also known as Evolved UMTS Terrestrial Radio Access (EUTRA) or Evolved UMTS Terrestrial Radio Access Network (EUTRAN).

The present disclosure may use the term "serving network device" to refer to a network node or network device (or a portion thereof) serving a UE. As used herein, the terms "send to," "receive from," and "cooperate with" (and variations thereof) include communication that may or may not involve through one or more intermediate devices or nodes. The term "acquire" (and variants thereof) includes acquire in the first instance or reacquire after the first instance. The term "connected" may mean either a physical connection or a logical connection.

The present disclosure uses 5G NR as an example of a wireless network, and may use a smartphone and/or an augmented reality headset as an example of a UE. The present disclosure is intended and should be understood that such examples are merely illustrative, and that the present disclosure is applicable to other wireless networks and user equipment.

Fig. 1 is a diagram depicting an example of wireless networking between a network system 100 and a User Equipment (UE) 150. Network system 100 may include one or more network nodes 120, one or more servers 110, and/or one or more network devices 130 (e.g., test devices). The network node 120 will be described in more detail below. As used herein, the term "network device" may refer to any component of network system 100, such as server 110, network node 120, network apparatus 130, any component(s) described previously, and/or any other component(s) of network system 100. Examples of network devices include, but are not limited to, devices implementing 5G NR aspects, and the like. The present disclosure describes embodiments related to 5G NR and embodiments related to aspects defined by the third generation partnership project (3 GPP). However, embodiments related to other wireless networking technologies are contemplated as falling within the scope of the present disclosure.

The following description provides further details of examples of network nodes. In a 5G NR network, gNodeB (also referred to as a gNB) may include, for example, a node that provides New Radio (NR) user plane and control plane protocol terminations towards the UE and that is connected to a 5G core (5 GC) via an NG interface, for example according to section 3.2 of 3GPP TS 38.300V16.6.0 (2021-06), which is incorporated herein by reference.

The gNB supports various protocol layers, e.g., layer 1 (L1) -physical layer, layer 2 (L2), and layer 3 (L3).

Layer 2 (L2) of NR is split into sublayers of Medium Access Control (MAC), radio Link Control (RLC), packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP), where for example:

The o physical layer provides a transport channel to the MAC sublayer;

The oMAC sub-layer provides a logical channel to the RLC sub-layer;

The oRLC sub-layer provides RLC channels to the PDCP sub-layer;

the oPDCP sub-layer provides radio bearers to the SDAP sub-layer;

The oSDAP sub-layer provides quality of service (QoS) flows to the 5 GC;

o control channels include Broadcast Control Channel (BCCH) and Physical Control Channel (PCCH).

Layer 3 (L3) includes Radio Resource Control (RRC), e.g., according to section 6 of 3GPP TS38.300V16.6.0 (2021-06), which is incorporated herein by reference.

The gNB central unit (gNB-CU) includes, for example, logical nodes hosting, for example, radio Resource Control (RRC), service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) protocols of the gNB, or RRC and PDCP protocols of the en-gNB, which controls the operation of one or more gNB distributed units (gNB-DUs). The gNB-CU terminates the F1 interface connected to the gNB-DU. The gNB-CU may also be referred to herein as a CU, a central unit, a centralized unit, or a control unit.

The gNB distributed unit (gNB-DU) includes logical nodes such as Radio Link Control (RLC), medium Access Control (MAC), and Physical (PHY) layers, e.g., hosting a gNB or en-gNB, and its operation is controlled in part by the gNB-CU. One gNB-DU supports one or more cells. One cell is supported by only one gNB-DU. The gNB-DU terminates the F1 interface connected to the gNB-CU. The gNB-DU may also be referred to herein as a DU or a distributed unit.

As used herein, the term "network node" may refer to any one of, or any combination of, a gNB-CU, or a gNB-DU. The RAN (radio access network) node or network node (such as, for example, a gNB-CU or a gNB-DU or part thereof) may be implemented using, for example, an apparatus having at least one processor and/or at least one memory with processor-readable instructions ("procedure") configured to support and/or provide and/or process functionality and/or features related to CU and/or DU, and/or at least one protocol (sub) layer (e.g., layer 2 and/or layer 3) of the RAN (radio access network). Different functional splits between the central unit and the distributed units are possible. An example of such devices and components will be described below in connection with fig. 8.

The gNB-CU and gNB-DU parts may be co-located or physically separated, for example. The gNB-DU may even be further split into e.g. two parts, e.g. a part comprising the processing device and a part comprising the antenna. The Central Unit (CU) may also be referred to as a baseband unit/radio controller/cloud-RAN/virtual-RAN (BBU/REC/C-RAN/V-RAN), an open-RAN (O-RAN) or a part thereof. The Distributed Units (DUs) may also be referred to as remote radio heads/remote radio units/radios/radio units (RRH/RRU/RE/RU) or parts thereof. In the following, in various example embodiments of the present disclosure, the network node supporting at least one of the layer 3 protocol or the central unit functionality of the radio access network may be, for example, a gNB-CU. Similarly, the network node supporting at least one of the layer 2 protocol or the distributed unit functionality of the radio access network may be e.g. a gNB-DU.

The gNB-CU may support one or more gNB-DUs. The gNB-DU may support one or more cells and thus may support a serving cell for a User Equipment (UE) or a candidate cell for handover, dual connectivity and/or carrier aggregation, among other procedures.

The User Equipment (UE) 150 may be or include a wireless or mobile device, an apparatus with a radio interface to interact with a RAN (radio access network), a smart phone, an in-vehicle apparatus, an IoT device, or an M2M device, among other types of user equipment. Such a UE 150 may include at least one processor and at least one memory including program code, where the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform certain operations, such as RRC connection to the RAN. An example of components of the UE will be described in connection with fig. 8. In an embodiment, the UE 150 may be configured to generate a message (e.g., including a cell ID) to be sent (e.g., to reach and communicate with a serving cell) via radio to the RAN. In an embodiment, UE 150 may generate and send and receive RRC messages containing one or more RRC PDUs (packet data units). Those skilled in the art will understand the RRC protocol and other procedures that the UE may perform.

With continued reference to fig. 1, in an example of a 5G NR network, network system 100 provides one or more cells that define a coverage area of network system 100. As described above, the network system 100 may include a gNB of a 5G NR network, or may include any other device configured to control radio communications and manage radio resources within a cell. As used herein, the term "resource" may refer to a radio resource, such as a Resource Block (RB), a Physical Resource Block (PRB), a radio frame, a subframe, a slot, a subband, a frequency region, a subcarrier, a beam, and the like. In an embodiment, the network node 120 may be referred to as a base station.

Fig. 1 provides an example and illustrates only network system 100 and UE 150. Those skilled in the art will appreciate that network system 100 includes components not shown in fig. 1, and will appreciate that other user devices may communicate with network system 100.

Fig. 2 is a block diagram of example components of the network system 100 of fig. 1. The 5G NR network may be described as an example of the network system 100, and it is intended that the aspects described below also apply to other types of network systems. The network system may operate in accordance with the signals and connections shown in fig. 1 such that UE 150 communicates with network system 100 over radio access network 225. In addition, the network system may be divided into user plane components and functions and control plane components and functions, as shown and described herein. Unless otherwise indicated, the terms "component," "function," and "service" may be used interchangeably herein and may refer to and be implemented by instructions executed by one or more processors.

Example functions of the components are described below. The example functions are merely illustrative, and it should be understood that additional operations and functions may be performed by the components described herein. In addition, the connections between components may be virtual connections through a service-based interface such that any component may communicate with any other component. In this way, any component may act as a service "producer" providing services for network functions for any other component that is a service "consumer".

The core network 210 is described, for example, in the control plane of the network system. The core network 210 may include an authentication server function (AUSF) 211, an Access and Mobility Function (AMF) 212, and a Session Management Function (SMF) 213. The core network 210 may also include a Network Slice Selection Function (NSSF) 214, a network opening function (NEF) 215, a Network Repository Function (NRF) 216, and a unified data management function (UDM) 217, which may include a Unified Data Repository (UDR) 224.

Additional components and functions of core network 210 may include an application function 218, a Policy Control Function (PCF) 219, a network data analysis function (NWDAF) 220, an analysis data store function (ADRF) 221, a Management Data Analysis Function (MDAF) 222, and an operations and administration function (OAM) 223.

The user plane includes UE 150, radio Access Network (RAN) 225, user Plane Function (UPF) 226, and Data Network (DN) 227.RAN 225 may include one or more components described in connection with fig. 1, such as one or more network nodes. However, RAN 225 may not be limited to such components. The UPF 226 provides connectivity for data transported through the RAN 225. For example, DN 226 identifies services from service providers, internet access, and third party services.

The AMF 212 handles connectivity and mobility tasks. AUSF 211 receives an authentication request from AMF 212 and interacts with UDM 217 to authenticate and verify the network response for determination of successful authentication. The SMF 213 performs Packet Data Unit (PDU) session management, and manages session context with the UPF 226.

NSSF 214 the 214 may select a Network Slice Instance (NSI) and determine the allowed Network Slice Selection Assistance Information (NSSAI). The selection and determination are utilized to set the AMF 212 to provide services to the UE 150. The NEF 215 protects access to network services by third parties to create private network services. NRF 216 acts as a repository to store network functions to allow the functions to register and discover each other.

UDM 217 generates authentication vectors for use by AUSF and ADM 212 and provides user identification processing. The UDM 217 may be connected to a UDR 224, which UDR 224 stores data associated with authentication, applications, etc. The AF 218 provides application services (e.g., streaming services, etc.) to the user. PCF 219 provides policy control functionality. For example, PCF 219 may assist in network slicing and mobility management, as well as provide quality of service (QoS) and billing functions.

NWDAF 220 collect data (e.g., from the UE 150 and network system) to perform network analysis and utilize the analysis in service provisioning to provide insight into functionality. ADRF 221 allow data and analysis to be stored, retrieved, and removed by the consumer. The MDAF 222 provides additional data analysis services for network functions. OAM 223 provides provisioning and management processing functions to manage elements in or connected to the network (e.g., UE 150, network node, etc.).

Fig. 2 is merely an example of components of a network system, and variations thereof are contemplated as falling within the scope of the present disclosure. In embodiments, the network system may include other components not shown in fig. 2. In an embodiment, the network system may not include every component shown in fig. 2. In an embodiment, the components and connections may be implemented using different connections than those shown in FIG. 2. Such embodiments and other embodiments are contemplated as being within the scope of the present disclosure.

A method is described herein to improve the ability of an NG-RAN node to perform desired resource management between slices by exchanging desired/predicted traffic information between NG-RAN nodes, further details of which will be provided below. A node may predict traffic that is predicted to be processed by itself and intended for one of its neighboring nodes.

In various embodiments, a node may predict traffic based on a UE affected by mobility actions related to a handover or dual connectivity. These mobility actions may be triggered by the node predicting traffic or may be predicted to be triggered by the node and with the purpose of having neighboring nodes. In various embodiments, the predicted traffic information may be determined based on a particular network slice. In various embodiments, the predicted traffic information may be obtained and reported at a cell level granularity. In various embodiments, the predicted traffic information may be obtained and reported at a per-cell slice level granularity. In various embodiments, the predicted traffic information may be obtained and reported at node level granularity.

A node may measure its own incoming traffic from different network nodes and may use this information to evaluate the accuracy or confidence of artificial intelligence/model learning (AI/ML) traffic predictions provided by its neighboring nodes.

In various embodiments, a node may have the ability to measure traffic or predict traffic and exchange information about the measured traffic, incoming traffic towards the network node, or predicted traffic with a neighbor. Thus, the node can allocate resources accordingly to accommodate the incoming traffic. In various embodiments, the NG-RAN node may internally determine whether to reallocate some of its slice resources to account for overload scenarios, for example, if the prediction of incoming traffic exceeds the currently allocated resources for a particular network slice. In various embodiments, the NG-RAN node may anticipate resource management between slices, ensuring that the required resources are available when needed.

In various embodiments used herein, the terms gNB-DU, gNB-CU-CP and gNB-CU-UP may also be understood to cover ng-eNB-DU, ng-eNB-CU-CP and ng-eNB-CU-UP, respectively. Similarly, in various embodiments, the term F1 (corresponding to the F1 interface within the split gNB architecture) may be understood to cover the term W1 (corresponding to the W1 interface within the split ng-eNB architecture).

A signaling is described herein to enable a node (e.g., an NG-RAN node) to request reporting of information about traffic sent or predicted to be sent by the neighboring node to the requesting node from one or more of its neighbors. The traffic is generated by the UE affected by mobility actions (e.g., handover, dual connectivity). Those mobility actions may be triggered by the reporting node, or may be predicted to be triggered by the reporting node, and the requesting node is the target or predicted target for those mobility actions (e.g., the reporting node is the source node in case of a handover, or the secondary node in case of a dual connection). The predicted traffic information may be determined based on a particular network slice.

In various embodiments, the requesting node may request predicted incoming traffic information at a cell level granularity. In this case, the reporting node may estimate the current traffic per cell within a group of cells from which the reporting node collects traffic information. The reporting node may then estimate the number of handovers from the group of cells to the cell of the requesting node. The number of handovers may be based on a known trajectory of UEs in the group of cells, the number of UEs in the group of cells, statistical patterns, historical data, etc. The reporting node may perform a prediction per cell of the requesting device and thus obtain a predicted number of handovers per cell. Based on the predicted number of handovers and the current traffic, the reporting node may predict per-cell traffic information for the requesting node.

In this case, the requesting node may include timing information in the request to define the time configuration at which traffic prediction must occur. If time of day is included in the configuration, the predicted traffic should be predicted by the reporting node at a specific time in the future. If a time interval (window) is included in the configuration, the reporting node may average the predicted traffic over the requested time window. In various embodiments, the reporting node may calculate or measure the evolution of the predicted traffic over the indicated time window and report to the requesting node over the indicated time interval (window).

The NG-RAN node may also receive predicted incoming traffic information at the UE level granularity. In this case, the reporting node may provide predicted incoming traffic information per slice and per cell that is predicted to be accessed by the UE that is affected by the mobility action from the reporting node to the requesting node. In various embodiments, the requesting node may expect with the help of this information a reservation of resources in the first access cell (target cell of mobility action) in the requesting node and in the further predicted access cell contained in the UE predicted trajectory.

As used herein, communication with a Radio Access Network (RAN) may refer to and mean communication with a portion of the RAN, such as with a network node (e.g., DU and/or CU) or another portion of the RAN. As used herein, communication with a core network may refer to and mean communication with one or more services/applications of the core network, such as an AMF or another service of the core network.

As used herein, the terms "first" and "second" and the like may refer to a first or second instance of a message sent/received by a component (e.g., UE, device, etc.) or by a first or second component in a sequence of the described components. Thus, the terms are used in a non-limiting manner and may refer to any message, operation, device, component, etc.

According to a brief description, fig. 3 is an illustration of an example network 300 that enables reporting per-slice traffic predictions among nodes in accordance with an illustrative aspect of the disclosure. As shown in fig. 3, a plurality of nodes (node a, node B, node C, node D) operating in respective cells communicate with each other.

As can be seen from fig. 3, node B requests and receives information about predicted incoming traffic from nodes C and D. Node B may use the information that the traffic originated from node C or node D to determine the portion of the traffic that would be forwarded further to node a. In various embodiments, node a requests predicted incoming traffic per slice through node B to node a, and node B provides predicted incoming traffic through node B to node a using inputs from node C and node D.

Fig. 4 is an illustration of an example network 400 implementing per-slice traffic prediction among nodes in accordance with an illustrative aspect of the disclosure. To avoid the problem of cascading request signalling in a peer-to-peer network, each network node reports to its neighbors the predicted traffic that is expected to be switched by the network node to its neighbors.

For example, node a reports to node B the predicted traffic per slice to be handed off from node a to node B. Node B reports the predicted traffic per slice to be switched from node B to node a, the predicted traffic per slice to be switched from node B to node C, and the predicted traffic per slice to be switched from node B to node D. Node C reports to node B the predicted traffic per slice to be switched from node C to node B, and node D reports to node B the predicted traffic per slice to be switched from node D to node B.

Fig. 5 is a diagram of an example embodiment of signals and operations among NG-RANs according to one illustrative aspect of the present disclosure. In various embodiments, the components depicted in fig. 5 may correspond to similar components described above in fig. 1 and 2. It should be understood that the described signals may have associated operations and that the described operations may have associated signals.

As shown in fig. 5, for example, NG-RAN node 1 may request reporting of predicted traffic from neighboring NG-RAN node 2, which is expected to cross the cell of NG-RAN node 2 and reach the cell of NG-RAN node 1. In this request, the NG-RAN node 1 may also include its own list of cells on which the NG-RAN node 1 wants to know the predicted incoming traffic. In various embodiments, these cells are target cells that predict incoming traffic. The NG-RAN node 1 may alternatively comprise a corresponding list of source cells for the traffic in the NG-RAN node 2. If the request sent by NG-RAN node 1 does not include any cell list, NG-RAN node 2 may determine the cell on which the predicted traffic will be sent. The NG-RAN node 1 may alternatively or additionally request information about the total traffic in the NG-RAN node 2. In various embodiments, the request by the NG-RAN node 1 may also include a list of slices on which it wishes to receive predicted traffic. The request in this case may be a request for predicted traffic per slice per cell. In various embodiments, a data collection request message (e.g., as introduced in 3gpp TS 38.423 version 18) may be used to request predicted traffic from a neighboring node.

The node receiving the request may acknowledge or reject such a request in the event that it cannot provide a prediction.

In various embodiments, at operation 501, NG-RAN node 1 sends a measurement configuration request message to NG-RAN node 2, and NG-RAN node 2 receives the measurement configuration request message. In various embodiments, the measurement configuration request message includes one or more of NG-RAN 1 measurement ID, cell list, slice list, node level, measurement configuration, and/or predicted time. In various embodiments, the measurement configuration request message may include a bitmap including the predicted traffic of the mth bit. In various embodiments, some of the information included in the measurement configuration request message may be optional.

At operation 502, NG-RAN node 2 sends a measurement configuration response message to NG-RAN node 1 and NG-RAN node 1 receives the measurement configuration response message. In various embodiments, the measurement configuration response message includes one or more of a NG-RAN 1 measurement ID, a NG-RAN 2 measurement ID, and/or a reporting characteristics bitmap of the failure. In various embodiments, some of the information included in the measurement configuration response message may be optional.

At operation 503, NG-RAN node 2 may determine a predicted traffic per slice and/or per cell at NG-RAN node 2 to NG-RAN node 1 for the UE to be handed over from NG-RAN node 2 to NG-RAN node 1 and/or for the UE (e.g., dual connectivity) where NG-RAN node 2 is or will become MN and NG-RAN node 1 is or will become SN.

At operation 504, NG-RAN node 2 sends a measurement report to NG-RAN node 1 and NG-RAN node 1 receives the measurement report. In various embodiments, the measurement report includes one or more of a predicted traffic arriving at the NG-RAN node 1 at the NG-RAN node 2, a predicted traffic per slice and per cell, a predicted traffic for a handed over UE, a predicted traffic for a UE in dual connectivity. In other examples, the predicted traffic arriving at NG-RAN node 1 at NG-RAN node 2 is reported for NG-RAN node 2, for the handed over UE, for the UE in dual connectivity, in whole per slice. The NG-RAN node 1 may then determine the predicted incoming traffic per slice per cell based on the traffic information already available in the NG-RAN node 1.

In various embodiments described in fig. 5, a node receiving a request may acknowledge or reject such a request if it cannot provide a prediction. The node receiving the request then determines all traffic that is incoming to the node and that is destined for the cell of the requesting node. In order to obtain the predicted traffic from all its neighbors to itself, the node may use different methods. In various embodiments, the node receiving the request may request predicted traffic from each of its neighbors into itself. The predicted flow may be measured per slice. In various embodiments, the node receiving the request may predict the incoming traffic itself by using the trajectories reported from its neighbors across its cells. In various embodiments, the node receiving the request may predict the incoming traffic itself by utilizing the predicted trajectories reported from its neighbors across its cells.

In various embodiments, a node receiving a request for predicted traffic may be triggered to begin measurement of the predicted traffic. In various embodiments, a node may maintain a prediction of traffic traversing its cell to each of its neighbors so that when a request for predicted traffic is received, the node may immediately respond to the request. The predicted traffic may be per-cell per-slice granularity. The predicted traffic may also be measured per UE.

The predicted traffic per cell may be one or more of a predicted throughput measure in the UL and/or DL direction, a predicted amount of data over a period of time.

In various embodiments, the predicted traffic may also be per-cell per-slice granularity.

A node requesting predicted traffic from one or more neighboring NG-RAN nodes to itself may eventually measure incoming traffic from a handover operation initiated by the neighboring node to the actual measurement of its cell. In various embodiments, this information may be used at a node to evaluate the accuracy or confidence of the predicted traffic provided by neighboring nodes.

In various embodiments, the measured traffic per cell may be one or more of throughput measurements in the UL and/or DL directions, data amounts over a period of time.

In various embodiments, the measured traffic may also be per-cell per-slice granularity.

A node may request predicted traffic per node granularity from its neighbors. In various embodiments, the request may include a set of cells and a set of slices or requests for node-level traffic. If the request relates to a set of cells and/or slices, the measurement report may include predicted traffic information per requested cell and/or slice. NG-RAN node 2 reports traffic to NG-RAN node 1 for UEs handed over from NG-RAN node 2 to NG-RAN node 1, and to NG-RAN node 1 for UEs served in the dual connectivity, respectively (NG-RAN node 2 is or becomes MN, NG-RAN node 1 is or becomes SN).

The operation of fig. 5 is merely illustrative, and variations thereof are contemplated as being within the scope of the present disclosure. In embodiments, the operations may include other operations not shown in fig. 5. In an embodiment, the operations may not include every operation shown in fig. 5. In an embodiment, operations may be implemented in a different order than that shown in fig. 5. Such and other embodiments are contemplated as being within the scope of the present disclosure. Those skilled in the art will appreciate that while various example components are described as performing various functions, other components may perform those functions described in fig. 5.

Fig. 6 is a diagram of an example embodiment of signals and operations among a UE, a gNB-CU-CP, and a gNB-CU-UP, according to one illustrative aspect of the disclosure. In various embodiments, the components depicted in fig. 6 may correspond to similar components described above in fig. 1 and 2. It should be understood that the described signals may have associated operations and that the described operations may have associated signals.

As shown in fig. 6, the gNB-CU-CP requests traffic or predicted traffic information related to one or more UE contexts from the gNB-CU-UP. The gNB-CU-UP determines the amount of measured traffic or predicted traffic and reports the requested information to the gNB-CU-CP. The slice list may be included in the request message and the measured traffic or predicted traffic may be reported per slice.

For example, at operation 601, the gNB-CU-CP sends a measurement configuration request message to the gNB-CU-UP, and the gNB-CU-UP receives the measurement configuration request message. In various embodiments, the measurement configuration request message includes one or more of a gNB-CU-CP measurement ID, a measurement configuration, a reporting period, and/or a predicted time. In various embodiments, the measurement configuration request message includes a bitmap including an nth bit for measured traffic and an mth bit for predicted traffic.

At operation 602, the gNB-CU-UP sends a measurement configuration response message to the gNB-CU-CP, and the gNB-CU-CP receives the measurement configuration response message. In various embodiments, the measurement configuration response message may include one or more of a gNB-CU-CP measurement ID, a gNB-CU-UP measurement ID, and/or a failed characteristic bitmap. In various embodiments, operations 601 and 602 may be measurement configurations.

At operation 603, the gNB-CU-CP sends a bearer context setup request message to the gNB-CU-UP, and the gNB-CU-UP receives the bearer context setup request message. In various embodiments, the bearer context setup request message may include one or more of an E1AP UE ID, a data collection ID, a gNB-CU-CP measurement ID, a gNB-CU-UP measurement ID.

At operation 604, a context is created in the CU-UP for the UE and traffic is started. In various embodiments, operations 603 and 604 may be measurement collection triggers.

At operations 605 and 606, the gNB-CU-UP sends a measurement report to the gNB-CU-CP, and the gNB-CU-CP receives the measurement report. In various embodiments, the measurement report may include one or more of a gNB-CU-CP measurement ID, a gNB-CU-UP measurement ID, a per-UE per-slice measurement, and/or a predicted traffic. In various embodiments, operations 605 and 606 may be measurement reports.

The operation of fig. 6 is merely illustrative, and variations thereof are contemplated as being within the scope of the present disclosure. In an embodiment, the operations may include other operations not shown in fig. 6. In an embodiment, the operations may not include every operation shown in fig. 6. In an embodiment, operations may be implemented in a different order than that shown in fig. 6. Such and other embodiments are contemplated as being within the scope of the present disclosure. Those skilled in the art will appreciate that while various example components are described as performing various functions, other components may perform those functions described in fig. 6.

Fig. 7 is a diagram of an example embodiment of signals and operations among NG-RANs according to another illustrative aspect of the disclosure. In various embodiments, the components depicted in fig. 7 may correspond to similar components described above in fig. 1 and 2. It should be understood that the described signals may have associated operations and that the described operations may have associated signals.

As shown in fig. 7, the NG-RAN node receives the predicted incoming traffic information per slice at the UE level granularity as part of the predicted UE trajectory information transmitted during handover preparation. This information may be included in the XnAP handoff request message according to an OAM configuration or according to a request per signaling.

At operation 701, NG-RAN node 2 determines a predicted UE trajectory and a corresponding predicted UE traffic per slice per predicted visited cell.

At operation 702, NG-RAN node 2 sends a handover request to NG-RAN node 1, and NG-RAN node 1 receives the handover request. In various embodiments, the handover request may include a predicted UE trajectory and a corresponding predicted UE traffic per slice per predicted visited cell.

The operation of fig. 7 is merely illustrative, and variations thereof are contemplated as being within the scope of the present disclosure. In embodiments, the operations may include other operations not shown in fig. 7. In an embodiment, the operations may not include every operation shown in fig. 7. In an embodiment, the operations may be implemented in a different order than that shown in fig. 7. Such and other embodiments are contemplated as being within the scope of the present disclosure. Those skilled in the art will appreciate that while various example components are described as performing various functions, other components may perform those functions described in fig. 7.

As described above, various message transmissions may be used in various embodiments. For example, in various embodiments, xnAP measurement reports may be sent. In various embodiments, the message is sent by the NG-RAN node to the NG-RAN node 1 to report the predicted traffic (e.g., NG-RAN node 2→ng-RAN node 1). The following table shows an example XnAP measurement report according to an embodiment.

The following table shows an example E1AP measurement report according to an embodiment. In various embodiments, the message is sent by the gNB-CU-UP to the gNB-CU-CP to report the results of the requested measurement (e.g., gNB-CU-UP→gNB-CU-CP).

Range boundaries	Interpretation of the drawings
		maxnoofUEReports	The maximum number of UEs contained in the message. The value is 512.
maxnoofSlicesInUE	The maximum number of slices supported by the UE. The value is 8.

The following table shows a table implementation including predicted traffic in the XnAP cell-based UE trajectory prediction IE (e.g., in the XnAP handover request message).

The following table shows predicted trajectory cell information.

Range boundaries	Interpretation of the drawings
		maxnoofSlicesInUE	The maximum number of slices supported by the UE. The value is 8.

Operations are described below from the perspective of the apparatus, and may include NG-RAN nodes, gNB-CU-CPs, or gNB-CU-UPs in various embodiments. From such a perspective, a method may include receiving, by a first apparatus, a first message including a request for predicted User Equipment (UE) traffic per cell for a second apparatus. The first device determines a predicted UE traffic per cell for the second device and sends a second message to the second device, the second message including a report of the predicted UE traffic per cell.

Referring now to fig. 8, a block diagram of example components of a UE or network device (e.g., RAN or core network) is shown. The apparatus includes an electronic memory 810, a processor 820, a network interface 840, and a memory 850. The various components may be communicatively coupled with each other. Processor 820 may be and include any type of processor, such as a single-core Central Processing Unit (CPU), a multi-core CPU, a microprocessor, a Digital Signal Processor (DSP), a system-on-a-chip (SoC), or any other type of processor. The memory 850 may be volatile type memory, such as RAM, or nonvolatile type memory, such as NAND flash memory. Memory 850 includes processor-readable instructions executable by processor 820 to cause the apparatus to perform various operations including those mentioned herein, such as those described in fig. 3-7.

Electronic storage 810 may be and include any type of electronic storage for storing data such as hard disk drives, solid state drives, optical disks, and/or other non-transitory computer readable media, as well as other types of electronic storage. The electronic memory 810 stores processor readable instructions for causing the apparatus or is configured to cause the apparatus to perform its operations and also stores data associated with such operations, such as storing data relating to the 5G NR standard, as well as other data. The network interface 840 may implement wireless networking technologies such as 5G NR and/or other wireless networking technologies.

The components shown in fig. 8 are merely examples, and those skilled in the art will appreciate that the apparatus includes other components not shown, and may include multiple components of any of the components shown. Such and other embodiments are contemplated as being within the scope of the present disclosure. For example, the transmitter and the receiver may be included as components for transmitting and receiving signals.

Other embodiments of the present disclosure include the following embodiments.

Example 1.1. An apparatus, comprising:

Means for receiving, by a first apparatus, a first message comprising a request for predicted User Equipment (UE) traffic per cell of a second apparatus;

Means for determining, by the first device, a predicted UE traffic per cell for the second device, and

The apparatus includes means for transmitting, by the first apparatus, a second message to the second apparatus, the second message including a report of predicted UE traffic per cell.

Example 1.2 the apparatus of example 1.1, wherein the first message is received from the second apparatus.

Example 1.3 the apparatus of example 1.1 or 1.2, wherein the second message includes a report of predicted UE traffic per cell per network slice.

Example 1.4 the apparatus of example 1.1 or 1.2, wherein the predicted UE traffic per cell is traffic incoming to the first apparatus and intended for the second apparatus.

Example 1.5 the apparatus of any one of examples 1.1 to 1.4, wherein the first message includes a request for predicted UE traffic for at least a first UE of the one or more UEs.

Example 1.6 the apparatus of any one of examples 1.1 to 1.5, wherein the first message comprises a request for predicted UE traffic for a specified period of time, and wherein the second message comprises an average amount of predicted UE traffic per cell averaged over the specified period of time.

Example 1.7 the apparatus of any one of examples 1.1 to 1.6, wherein the first message includes a request for predicted UE traffic for a particular time.

Example 1.8 the apparatus of any one of examples 1.1 to 1.7, wherein the first message comprises a request for predicted UE traffic for a cell list, and wherein the second message comprises predicted UE traffic for a cell indicated by the cell list.

Example 1.9 the apparatus of any one of examples 1.1 to 1.8, wherein the first message comprises a request for predicted UE traffic for a slice list, and wherein the second message comprises predicted UE traffic for a slice indicated by the slice list.

Embodiment 1.10 the apparatus of any one of examples 1.1-1.9 wherein predicting UE traffic comprises traffic throughput.

Example 1.11 the apparatus of any one of examples 1.1 to 1.10, further comprising:

Means for receiving, by the second apparatus, a second message from the first apparatus, the second message including a report of predicted UE traffic per cell, and

Means for performing load balancing between cells based on the received reports of predicted UE traffic per cell.

Example 1.12 the apparatus of example 1.11, further comprising:

Means for receiving, by the second apparatus, a second message from the first apparatus, the second message including a report of predicted UE traffic per cell per slice, and

Means for performing a slice reconfiguration or remapping action based on the received report of predicted UE traffic per cell.

Example 1.13 the apparatus of any one of examples 1.1 to 1.12, wherein the first message comprises a request for predicted UE traffic for at least a first UE of the one or more UEs, wherein the second message comprises predicted UE traffic for the first UE for a first cell of the second apparatus, and wherein the second apparatus estimates traffic demand of the first UE if the first UE enters the first cell of the second apparatus based on the predicted UE traffic for the first UE.

Example 1.14 the apparatus of any one of examples 1.1 to 1.13, wherein the first apparatus is a first network node controlling a first set of cells and the second apparatus is a second network node controlling a second set of cells, and wherein at least one cell of the first set of cells is a neighbor cell to at least one cell of the second set of cells.

Example 2.1 a method includes receiving, by a first apparatus, a first message including a request for predicted User Equipment (UE) traffic per cell for a second apparatus, determining, by the first apparatus, predicted UE traffic per cell for the second apparatus, and sending, by the first apparatus, a second message to the second apparatus, the second message including a report of the predicted UE traffic per cell.

Example 2.2 the method of example 2.1, wherein the first message is received from the second device.

Example 2.3 the method of example 2.1 or 2.2, wherein the second message includes a report of predicted UE traffic per cell per network slice.

Example 2.4 the method of example 2.1 or 2.2, wherein the predicted UE traffic per cell is traffic incoming to the first device and intended for the second device.

Example 2.5 the method of any of examples 2.1 to 2.4, wherein the first message includes a request for predicted UE traffic for at least a first UE of the one or more UEs.

Example 2.6 the method of any of examples 2.1 to 2.5, wherein the first message comprises a request for predicted UE traffic for a specified period of time, and wherein the second message comprises an average amount of predicted UE traffic per cell averaged over the specified period of time.

Example 2.7 the method of any of examples 2.1 to 2.6, wherein the first message includes a request for predicted UE traffic for a particular time.

Example 2.8 the method of any of examples 2.1 to 2.7, wherein the first message comprises a request for predicted UE traffic for a cell list, and wherein the second message comprises predicted UE traffic for a cell indicated by the cell list.

Example 2.9 the method of any of examples 2.1 to 2.8, wherein the first message comprises a request for predicted UE traffic for a slice list, and wherein the second message comprises predicted UE traffic for a slice indicated by the slice list.

Example 2.10 the method of any of examples 2.1 to 2.9, wherein predicting UE traffic comprises traffic throughput.

Example 2.11 the method of any of examples 2.1 to 2.10, further comprising receiving, by the second apparatus, a second message from the first apparatus, the second message comprising a report of predicted UE traffic per cell, and performing load balancing between cells based on the received report of predicted UE traffic per cell.

Example 2.12 the method of example 2.11, further comprising receiving, by the second apparatus, a second message from the first apparatus, the second message including a report of the predicted UE traffic per cell per slice, and performing a slice reconfiguration or remapping action based on the received report of the predicted UE traffic per cell.

Example 2.13 the method of any of examples 2.1 to 2.12, wherein the first message comprises a request for predicted UE traffic for at least a first UE of the one or more UEs, wherein the second message comprises predicted UE traffic for a first cell of the first UE for the second apparatus, and wherein the second apparatus estimates traffic demand of the first UE in case the first UE enters the first cell of the second apparatus based on the predicted UE traffic for the first UE.

Example 2.14 the method of any of examples 2.1 to 2.13, wherein the first device is a first network node controlling a first group of cells and the second device is a second network node controlling a second group of cells, and wherein at least one cell of the first group of cells is a neighboring cell of at least one cell of the second group of cells.

Example 2.15 an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to receive, by a first apparatus, a first message comprising a request for predicted User Equipment (UE) traffic per cell for a second apparatus, determine, by the first apparatus, the predicted UE traffic per cell for the second apparatus, and send, by the first apparatus, to the second apparatus, a second message comprising a report of the predicted UE traffic per cell.

Example 2.16 an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to perform at least the method according to any one of examples 2.1 to 2.14.

Example 2.17 a processor-readable medium storing instructions that, when executed by at least one processor of an apparatus, cause the apparatus to perform at least the method according to any one of examples 2.1 to 2.14.

The embodiments and aspects disclosed herein are examples of the present disclosure and may be embodied in various forms. For example, although certain embodiments herein are described as separate embodiments, each embodiment herein may be combined with one or more other embodiments herein. Specific structural and functional details disclosed herein are not to be interpreted as limiting, but as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present disclosure in virtually any appropriately detailed structure. Throughout the description of the drawings, like reference numbers may refer to similar or identical elements.

The phrases "in one aspect," "in an aspect," "in various aspects," "in some aspects," or "in other aspects" may each refer to one or more of the same or different aspects in accordance with the present disclosure. The phrase "plurality" may refer to two or more.

In various embodiments, the terms "first message" and "second message" and any subsequent messages may refer to any message sent or received in sequence, and are not necessarily limited to any particular message.

The phrases "in one embodiment," "in an embodiment," "in various embodiments," "in some embodiments," or "in other embodiments" may each refer to one or more of the same or different embodiments in accordance with the present disclosure. The phrase in the form "a or B" means "(a), (B) or (a and B)". The phrase in the form of "at least one of A, B or C" means "(A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C)".

Any of the methods, programs, algorithms, or code described herein may be converted to or expressed as a programming language or computer program. The terms "programming language" and "computer program" as used herein each include any language for specifying instructions to a computer, and include, but are not limited to, assembler, base, bulk files, BCPL, C, C++, delphi, fortran, java, javaScript, machine code, operating system command language, pascal, perl, PL1, python, scripting language, visual Basic, meta language that itself specifies a program, and all first, second, third, fourth, fifth, or higher generation computer languages, and derivatives thereof. Databases and other data schemas, as well as any other meta-languages, are included. There is no distinction between languages in which the compiling and interpretation methods are interpreted, compiled, or used simultaneously. There is no distinction between compiled and source versions of the program. Thus, when referring to a program, the programming language may exist in more than one state (e.g., source code, compiled, object code, or linked), and it refers to any and all of the states. Reference to a program may include actual instructions and/or intent of those instructions.

Although aspects of the present disclosure have been illustrated in the accompanying drawings, it is not intended that the disclosure be limited thereto, as it is intended that the disclosure be as broad in scope as the art will allow and that the specification be read likewise. Therefore, the above description should not be construed as limiting, but merely as exemplifications of certain aspects. Those skilled in the art will envision other modifications within the scope and spirit of the claims appended hereto.

Claims

1. A method for communication, comprising:

receiving, by a first device, a first message including a request for predicted user equipment (UE) traffic per cell for a second device;

determining, by the first device, a predicted UE traffic per cell of the second device;

The first device sends a second message to the second device, where the second message includes the report of the predicted UE traffic per cell.

The method of claim 1 , wherein the first message is received from the second device.

3. A method according to claim 1 or 2, wherein the second message includes a report of predicted UE traffic per cell per network slice.

4 . The method according to claim 1 , wherein the predicted UE traffic per cell is traffic incoming to the first device and destined for the second device.

5 . The method according to claim 1 , wherein the first message comprises a request for predicted UE traffic for at least a first UE among one or more UEs.

6. The method of claim 1 or 2, wherein the first message comprises a request for predicted UE traffic for a specified time period, and wherein the second message comprises an average amount of the predicted UE traffic per cell averaged over the specified time period.

7. The method according to claim 1 or 2, wherein the first message comprises a request for predicted UE traffic for a specific time.

8. The method according to claim 1 or 2, wherein the first message comprises a request for predicted UE traffic for a cell list, and wherein the second message comprises the predicted UE traffic for cells indicated by the cell list.

9. A method according to claim 1 or 2, wherein the first message includes a request for predicted UE traffic for a slice list, and wherein the second message includes the predicted UE traffic for the slice indicated by the slice list.

10. The method according to claim 1 or 2, wherein the predicted UE traffic comprises traffic throughput.