EP4264999A1

EP4264999A1 - Mobility load balancing with rrc inactive awareness

Info

Publication number: EP4264999A1
Application number: EP21827705.1A
Authority: EP
Inventors: Luca LUNARDI; Angelo Centonza
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2020-12-18
Filing date: 2021-12-10
Publication date: 2023-10-25
Also published as: WO2022131995A1

Abstract

Systems and methods for Mobility Load Balancing (MLB) with Radio Resource Control (RRC) inactive awareness are provided. In some embodiments, a first Radio Access Node (RAN) node receives, from a second RAN node, information related to stored User Equipment (UE) contexts for inactive UEs that are hosted by the second RAN node and performs one or more actions based on the received information. In some embodiments, the second RAN node sends, to the first RAN node, information related to stored UE contexts for inactive UEs that are hosted by the second RAN node and performs one or more actions after sending the information to the first RAN node. In this way, the first RAN node takes more informed decisions for MLB actions.

Description

MOBILITY LOAD BALANCING WITH RRC INACTIVE AWARENESS

Related Applications

This application claims the benefit of provisional patent application serial number 63/127,664, filed December 18, 2020, the disclosure of which is hereby incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates to a Mobility Load Balancing (MLB) mechanism with the possibility to provide updated information related to stored User Equipment (UE) contexts for UEs in Radio Resource Control (RRC) Inactive state at a Radio Access Network (RAN) node providing resource updates.

Background

5G RAN Architecture

The current Fifth Generation (5G) Radio Access Network (RAN) architecture is depicted and described in section 6.1.1 ("Overall Architecture of NG-RAN") of Third Generation Partnership Project (3GPP) Technical Specification (TS) 38.401 V16.3.0. The 5G RAN is referred to as the Next Generation Radio Access Network (NG-RAN). Figure 1 illustrates the overall architecture of NG-RAN included in TS 38.401.

The NG-RAN architecture illustrated in Figure 1 can be further described as follows. The NG-RAN comprises a set of gNBs connected to the 5GC through respective NGs interfaces. A gNB can support Frequency Division Duplex (FDD) mode, Time Division Duplex (TDD) mode or dual mode operation. The gNBs can be interconnected through the Xn interface. A gNB may comprise a gNB Central Unit (gNB-CU) and one or more gNB Distributed Units (gNB-DUs). A gNB-CU and a gNB-DU are connected via Fl logical interface. One gNB-DU is connected to only one gNB-CU. For resiliency, a gNB- DU may be connected to multiple gNB-CUs by appropriate implementation. NG, Xn, and Fl are logical interfaces. The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, Fl), the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport and signaling transport. A gNB may also be connected to a Long Term Evolution (LTE) enhanced node B (eNB) via the X2 interface. Another architectural option is that where an LTE eNB connected to the Evolved Packet Core (EPC) network is connected over the X2 interface with a so called nr-gNB. The latter is a gNB not connected directly to a core network (CN) and connected via X2 to an eNB for the sole purpose of performing dual connectivity.

The architecture in Figure 1 may be expanded by spitting the gNB-CU into two entities. One gNB-CU User Plane part (gNB-CU-UP), which may serve the user plane and host the PDCP protocol, and one gNB-CU Control Plane part (gNB-CU-CP), which may serve the control plane and may host the Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) protocol. A gNB-DU may host the Radio Link Control (RLC), Medium Access Control (MAC), and Physical (PHY) protocols.

Mobility Load Balancing (MLB) in LTE

In mobile networks, the load of a radio access node is constantly measured so that when it gets above a pre-configure threshold, procedures can be triggered so that part of this load is transferred to either a neighbor cell of the same radio access technology (RAT) or another RAT or frequency.

The set of procedures to support this transfer is called MLB. Currently, the 3GPP specifies the following components for the MLB solution: (a) load reporting, (b) load balancing action based on handovers (HO)s, and (c) adapting HO/cell reselection (CR) configuration so that the load remains balanced.

For example, in LTE, the load reporting function is executed by exchanging cell specific load information between neighbor eNBs over the X2 (intra-LTE scenario) or SI (inter-RAT scenario) interfaces. In the case of intra-LTE load balancing, the source eNB may trigger a RESOURCE_STATUS_REQUEST message to potential target eNBs at any point in time, for example, when the load is above a pre-defined value i.e., Lte_load_threshold. Figure 2 illustrates the overloaded scenario triggering the MLB procedures.

Upon successful configuration of resource status reports from a target eNB to a source eNB, the target eNB can respond (periodically or not) with a RESOURCE_STATUS_UPDATE containing information about its load per cell. Figure 3 illustrates X2 load exchange procedures for MLB. The message exchange is highlighted in Figure 3. First, eNBl sends Resource Status Requests to eNB2 and to eNB3 (step 1). Next, eNB2 and eNB3 send Resource Status Updates to the eNBl (step 2). The Resource Status Updates (in step 2) may be periodic load reports in the intervals of 1 to 10 seconds.

An MLB algorithm running at a radio access node (for example, an eNB) may decide (a) which UEs will be handed over (a process called 'UE selection') and (b) to which neighbor cells (a process called 'cell selection') those UEs will be handed over. These decisions are typically taken based mainly on the load reports and potentially available radio measurements of source cell and neighbor cells reported by the UE candidates.

In other words, the UE may send measurement reports (Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), Signal-to- interference-plus-noise ratio (SINR), etc.) for a given neighbor cell (e.g., cell-2 in eNB- 2) and, upon the reception of these and having load information of such neighbor cell, the source may decide to handover the UE to the neighbor cell due to overload or not. In this case, a handover preparation is triggered towards a target node, e.g., eNB-2.

As part of Resource Status Reporting procedure, a first eNB sending load information to a second eNB can include an indication (such as Cell Reporting Indicator), to the second eNB node, that the ongoing transfer of load information has to be stopped. This may be used, e.g., as an indication that the load in the first eNB has become excessive.

Another procedure that may be executed is a Mobility Setting Change. The Mobility Setting Change procedure can be run before or after an MLB handover is performed. This procedure is aimed at negotiating between a source cell and a potential target cell a change on the Handover Trigger event, which is used to trigger the mobility event from one cell to another.

As an example, the Mobility Setting Change can be performed after the HO. Once the source eNB has selected the target eNB and which UE will be offloaded, the source eNB performs a Mobility Setting Change Procedure (for example, as specified by 3GPP TS 36.423). During this Mobile Setting Change procedure, new mobility settings are negotiated between the source eNB and the target eNB so that the UE handed over due to load balance will not be immediately handed over back to the source eNB. The Mobile Setting Change procedure can either be followed or preceded by ordinary HOs, depending on the vendor implementation. Figure 4 illustrates the MLB execution including the Mobility Parameter Change procedure. Specifically, as illustrated in Figure 4, the MLB execution has three steps: (1) load reporting (step 400), (2) load balancing action (step 402), and (3) amending mobility configuration (step 404).

In the load reporting step (step 400), when eNBl detects overload, eNBl sends Resource Status Request to eNB2. Then, eNB2 sends Resource Status Response (such as acknowledgment) and/or Resource Status Update.

In the load balancing action step (step 402), when eNBl finds cell or UE candidates for load balancing, eNBl performs a handover procedure with eNB2, which is caused by load balancing.

In the amending mobility configuration step (step 404), eNBl sends a Mobility Change Request to eNB2. In response, eNB2 may send "Mobility Change failure (allowed range)" and/or Mobility Change acknowledgment. Finally, eNBl and eNB2 respectively change their handover settings.

MLB in NG RAN

MLB in NR follows signaling principles that are in line with LTE. Similar signaling mechanisms are used in NG-RAN with the difference that the MLB metrics are reported over the split RAN interfaces. To this end, signaling support for Resource Status Reporting has been introduced over Xn, Fl and El, inter-node interfaces as well as enhanced over X2 for E-UTRAN New Radio - Dual Connectivity (EN-DC) scenario. In addition, the NG-RAN MLB functionality has been enhanced by means of new types of load metrics and with finer load granularity compared to LTE (where load information is expressed on a per-cell basis only). In particular, the NG-RAN MLB enhancements include the following:

• Load information on a per Synchronization Signal Block (SSB) coverage area granularity, such as o Radio Resource Status reporting per SSB area o Composite Available Capacity reporting per SSB Area

• Load information on a per network slice granularity, such as o Slice Available Capacity reporting per slice

• Hardware load indicator over El

• Transport Network Layer (TNL) capacity indication • Number of active UEs

• Number of RRC connections

As an example, one can consider the Xn interface specification in TS 38.423 V16.3.0, where Resource Status Reporting Indication procedure is specified in sections 8.4.10, 8.4.11 and 9.1.3.

Capacity Cells

One way to improve the capacity of networks is to deploy capacity cells which are typically placed in areas with high mobile traffic. By activating the capacity cell during high traffic around the capacity cell coverage, the cell that provides basic coverage can be offloaded which ideally would lead to gains, in terms of capacity and power. Energy efficiency is an important aspect in radio networks, one method for energy saving is to put capacity cells into sleep mode. The activation of a capacity cell may be triggered by a RAN node serving a "coverage cell", namely a cell deployed to provide the coverage layer for a given RAT. Deactivation of a capacity cell may be independently decided by the node serving the capacity cell. This process is typically a tradeoff between energy efficiency and capacity.

Existing UE Mobility History Information

In current specifications, it is possible to signal at every UE handover a "mobility history information". This information consists of a list of up to 16 cells which the UE visited while in RRC_CONNECTED mode. Namely, the list also represents the handovers the UE was subject to, together with the source and target cells of such handovers. The following excerpt from 3GPP TS 38.413 V16.3.0 describes that the existing UE history information comprises a list of up to 16 cells of various RAT types. For each cell change an HO cause is provided, as well as the time the UE stayed in the cell while in RRC-CONNECTED mode:

Start Excerpt from 3GPP TS 38.413 V16.3.0

9.3.1.95 UE History Information

This IE contains information about cells that a UE has been served by in active state prior to the target cell.

9.3.1.96 Last Visited Cell Information

This IE may contain cell specific information.

9.3.1.97 Last Visited NG-RAN Cell Information

This IE contains information about a cell. In case of NR cell, this IE contains information about a set of NR cells with the same NR ARFCN for reference point A, and the Global Cell ID IE identifies one of the NR cells in the set. The information is to be used for RRM purposes.

End Excerpt from 3GPP TS 38.413 V16.3.0

3GPP Re/- 17 Inter-System Load Balancing At RAN3#110-e meeting, it has been agreed to introduce a new mechanism for Inter System Status Request/Response/Update over NG: UL RAN CONFIGURATION TRANSFER and NG: DL RAN CONFIGURATION TRANSFER, via modification of the InterSystem Self Organizing Network (SON) Information IE ("Information Element"). For example, the following excerpt from R3-206185 (Qualcomm Inc.) discloses a proposal to modify Inter-System SON Information:

Start Excerpt from R3-206185

9.3.3.34 Inter-system SON Information

This IE identifies the nature of the configuration information transferred.

9.3.3.36 Inter-system SON Information Report

This IE contains the configuration information to be transferred.

9.3.3.x Inter-system SON Information Request This IE contains the request information to be transferred.

9.3.3.y Inter-system SON Information Reply This IE contains the reply information to be transferred.

9.3.3. a Inter-system Resource Status Request This IE contains the Inter-system resource status request information to be transferred.

9.3.3. b Inter-system Resource Status Reply

This IE contains the Inter-system load balancing reply information to be transferred.

9.3.3.C Inter-system Resource Status

This IE contains the results of requested measurements for Inter-system load balancing to be transferred.

9.3.3.d Event-Triggered Load Reporting

This IE contains request information for event-triggered inter-RAT or inter-system load reporting.

End Excerpt from R3-206185

Summary Systems and methods for mobility load balancing that take into consideration information related to User Equipments (UEs) that are in an inactive state are disclosed herein. In one embodiment, a method performed by a first Radio Access Node (RAN) node for balancing mobility load comprises receiving from a second RAN node information related to stored User Equipment (UE) contexts for inactive UEs that are hosted by the second RAN node and performing one or more actions based on the received information. Embodiments of the proposed solution enable more informed decisions taken by a RAN node for Mobility Load Balancing (MLB) actions.

In one embodiment, the one or more actions performed by the first RAN node comprise evaluating mobility load balancing actions based on the information related to stored UE contexts for inactive UEs. In one embodiment, the first RAN node receives from the second RAN node information related to stored UE contexts for inactive UEs that are hosted by the second RAN node via a direct interface between the first RAN node and the second RAN node.

In one embodiment, the first RAN node receives from the second RAN node information related to stored UE contexts for inactive UEs that are hosted by the second RAN node via one or more core network nodes.

In one embodiment, the method further comprises sending to the second RAN node a request to send information related to stored UE contexts for inactive UEs that are hosted by the second RAN node.

In one embodiment, the information related to stored UE contexts for inactive UEs is stored in one bit of a bitmap in the request.

In one embodiment, the method further comprises receiving from the second RAN node an acknowledgement of the request to send information related to stored UE contexts for inactive UEs that are hosted by the second RAN node.

In one embodiment, the method further comprises sending to the second RAN node proposed adjusted mobility settings deducted based on the information received from the second RAN node.

In one embodiment, the information related to stored UE contexts for inactive UEs comprises a maximum number of stored inactive UE contexts.

In one embodiment, the information related to stored UE contexts for inactive UEs comprises a percentage of stored UE contexts for inactive UEs compared to a number of UEs in Radio Resource Control (RRC) connected state.

In one embodiment, the information related to stored UE contexts for inactive UEs further comprises a percentage of stored UE contexts for inactive UEs compared to a maximum number of UEs in RRC connected state.

In one embodiment, the request to send information related to stored UE contexts for inactive UEs that are hosted by the second RAN node is included in a resource status request message sent from the first RAN node to the second RAN node.

In one embodiment, the information related to stored UE contexts for inactive UEs is stored in one bit of a bitmap in the resource status request message.

In one embodiment, the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node is included in a resource status update message sent from the second RAN node to the first RAN node. In one embodiment, the first RAN node and the second RAN node are respectively located in two different communication systems.

In one embodiment, the first RAN node forwards the request towards the second RAN node via at least one core network node.

In one embodiment, the inactive UEs are RRC inactive UEs.

In one embodiment, a method performed by the second RAN node comprises sending to the first RAN node information related to stored UE contexts for inactive UEs that are hosted by the second RAN node and performing one or more actions after sending the information to the first RAN node.

In one embodiment, the one or more actions performed by the first RAN node comprises receiving adjusted mobility settings from the first RAN node and applying adjusted mobility settings proposed by the first RAN node.

In one embodiment, the second RAN node sends to the first RAN node information related to stored UE contexts for inactive UEs that are hosted by the second RAN node via a direct interface between the first RAN node and the second RAN node.

In one embodiment, the second RAN node sends to the first RAN node information related to stored UE contexts for inactive UEs that are hosted by the second RAN node via one or more core network nodes.

In one embodiment, the method further comprises receiving from the first RAN node a request to send, to the first RAN node, the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node.

In one embodiment, the method further comprises sending to the first RAN node an acknowledgment of the request sent by the first RAN node.

In one embodiment, the method further comprises receiving from the first RAN node proposed adjusted mobility settings deducted based on the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node.

In one embodiment, the method further comprises sending to the first RAN node an acknowledgment of proposed adjusted mobility settings deducted based on the information received from the second RAN node.

In one embodiment, the information related to stored UE contexts for inactive UEs comprises a percentage of stored UE contexts for inactive UEs compared to a number of UEs in RRC connected state. In one embodiment, the information related to stored UE contexts for inactive UEs further comprises a percentage of stored UE contexts for inactive UEs compared to a maximum number of UEs in RRC connected state.

In one embodiment, the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node is included in a resource status update message sent from the second RAN node to the first RAN node.

In one embodiment, the first RAN node and the second RAN node are respectively located in two different communication systems.

In one embodiment, the second RAN node forwards the acknowledgment of the request to a second core network; the second core network relays the acknowledgment of the request to a first core network; and the first core network forwards the acknowledgment of the request to the first RAN node.

In one embodiment, the second RAN node forwards the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node to a second core network; the second core network relays the information to a first core network; and the first core network forwards the information to the first RAN node.

Corresponding embodiments of a first network node and a second network node are also disclosed.

A first RAN node is adapted to receive, from a second RAN node, information related to stored UE contexts for inactive UEs that are hosted by the second RAN node and perform one or more actions based on the received information.

A first RAN node comprises processing circuitry configured to cause the first RAN node to receive, from a second RAN node, information related to stored UE contexts for inactive UEs that are hosted by the second RAN node and perform one or more actions based on the received information. A second RAN node is adapted to send, to a first RAN node, information related to stored UE contexts for inactive UEs that are hosted by the second RAN node and perform one or more actions after sending the information to the first RAN node.

A second RAN node comprises processing circuitry configured to cause the second RAN node to send, to a first RAN node, information related to stored UE contexts for inactive UEs that are hosted by the second RAN node and perform one or more actions after sending the information to the first RAN node.

Certain embodiments may provide one or more of the following technical advantage(s). Embodiments of the proposed solution enable more informed decisions taken by a RAN node for MLB actions. In some embodiments, an improvement in latency is possible for UEs in RRC Inactive. This is due to the fact that UEs in RRC Inactive can have better probability to successfully complete the resume procedure instead of being subject to RRC Reject or fallback to RRC Setup procedures. In some embodiments, accessibility of UEs in RRC Inactive can be improved as a result of a better retention of UE Context at the RAN node.

Brief Description of the

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

Figure 1 illustrates the overall architecture of Next Generation Radio Access Network (NG-RAN) included in TS 38.401.

Figure 2 illustrates the overloaded scenario triggering the Mobility Loading Balancing (MLB) procedures.

Figure 3 illustrates the load exchange procedures for MLB.

Figure 4 illustrates the MLB execution including the Mobility Parameter Change procedure.

Figure 5 illustrates an example of intra-system MLB action between Evolved Universal Terrestrial Radio Access (E-UTRAN) cell and New Radio (NR) cell.

Figure 6 illustrates an example of inter-system MLB action between NR cell A and NR cell B.

Figure 7 illustrates one example of a cellular communications system in accordance with some embodiments of the present disclosure. Figure 8 illustrates a system including a first RAN node and a second RAN node in accordance with some embodiments of the present disclosure.

Figure 9 is a flow chart that illustrates one embodiment of a method of operation of the first RAN node.

Figure 10 a flow chart that illustrates one embodiment of a method of operation of the second RAN node.

Figure 11 illustrates one embodiment of a method of operation between the first RAN node and the second RAN node (in the same RAN system) that communicate directly.

Figure 12 illustrates one embodiment of a method of operation between the first RAN node (in RAN system 1) and the second RAN node (in RAN system 2) that indirectly communicate via two core networks for inter-system load balancing.

Figure 13 illustrates a schematic block diagram of the RAN node in accordance with some embodiments of the present disclosure.

Figure 14 illustrates a schematic block diagram of the RAN node in accordance with some embodiments of the present disclosure.

Figure 15 illustrates a schematic block diagram that illustrates a virtualized embodiment of the RAN node in accordance with some embodiments of the present disclosure.

Detailed Description

The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

Radio Node: As used herein, a "radio node" is either a radio access node or a wireless communication device.

Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a RAN of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

Communication Device: As used herein, a "communication device" is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehiclemounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network/system.

Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

There currently exist certain challenge(s). The problem with existing solution is that no knowledge or information exists at a neighbor node (in intra-system or intersystem) upon the number of User Equipments (UEs) in Radio Resource Control (RRC) Inactive state. The lack of the information may result in intra-system or inter-system Mobility Load Balancing (MLB) actions that will impact the capability of the target Radio Access Network (RAN) node receiving the users from a neighbor source node to resume at least a fraction of the UEs in RRC Inactive state.

The problem is present both in case of UEs attempting to resume in the same node hosting the UE Context as well as in case of UEs attempting to resume in another RAN node, in which case the attempt to retrieve the UE Context may fail due to an excess of UE context stored. The situation is shown in Figure 5 and Figure 6.

Figure 5 illustrates an example of intra-system MLB action (between Evolved Universal Terrestrial Radio Access (E-UTRAN) cell and New Radio (NR) cell) impacting the ability of UEs in RRC Inactive state to resume in a RAN node. Figure 6 illustrates an example of inter-system MLB action (between NR cell A and NR cell B) impacting the ability of UEs in RRC Inactive state to resume in a RAN node. In Figure 5 and Figure 6, the fraction of impacted Inactive UEs corresponds to the number of Inactive UEs that attempted to resume in a cell where, due to MLB handovers, a high number of RRC connections have been activated with a consequent high number of UE contexts to be stored. In this situation, a UE in RRC Inactive, which is trying to resume in such a cell, may be rejected because the maximum number of RRC connections or because the maximum number of stored UE contexts has been reached by the node hosting the resumed cell. The fraction of impacted Inactive UEs also relates to UEs in RRC Inactive, whose UE Context is stored in the RAN node, and the RAN node receives a request to retrieve the UE context from another RAN node where the Inactive UEs attempts to resume.

Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of the proposed solution extend the MLB mechanism with the possibility to provide updated information related to the stored UE contexts for UEs in RRC Inactive state at the RAN node providing resource updates.

Figure 7 illustrates one example of a cellular communications system 700 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 700 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC); however, embodiments of the present disclosure described herein are not limited thereto. In this example, the RAN includes base stations 702-1 and 702-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 704-1 and 704-2. The base stations 702-1 and 702-2 are generally referred to herein collectively as base stations 702 and individually as base station 702. Likewise, the (macro) cells 704-1 and 704-2 are generally referred to herein collectively as (macro) cells 704 and individually as (macro) cell 704. The RAN may also include a number of low power nodes 706-1 through 706-4 controlling corresponding small cells 708-1 through 708-4. The low power nodes 706-1 through 706-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 708-1 through 708-4 may alternatively be provided by the base stations 702. The low power nodes 706-1 through 706-4 are generally referred to herein collectively as low power nodes 706 and individually as low power node 706. Likewise, the small cells 708-1 through 708-4 are generally referred to herein collectively as small cells 708 and individually as small cell 708. The cellular communications system 700 also includes a core network 710, which in the 5G System (5GS) is referred to as the 5GC. The base stations 702 (and optionally the low power nodes 706) are connected to the core network 710.

The base stations 702 and the low power nodes 706 provide service to wireless communication devices 712-1 through 712-5 in the corresponding cells 704 and 708. The wireless communication devices 712-1 through 712-5 are generally referred to herein collectively as wireless communication devices 712 and individually as wireless communication device 712. In the following description, the wireless communication devices 712 are oftentimes UEs, but the present disclosure is not limited thereto.

For the proposed solution, embodiments of a method of operation of a RAN node and a corresponding a RAN node are disclosed. The RAN node (for example, the first RAN node and the second RAN node in Figure 8) may be the base station 702 (e.g., gNB, eNB, en-gNB, ng-eNB) or a network node that performs part of the functionality of the base station 702 (e.g., gNB-CU, gNB-CU-CP, eNB-CU, or eNB-CU-CP). In case two RAN nodes pertain to different RAN systems, embodiments are disclosed herein in which core network nodes are involved to transparently convey the inter-system signaling between the two RAN nodes.

Embodiments are disclosed herein for providing mobility load balancing based on information related to stored UE contexts of UEs in inactive state (e.g., RRC Inactive) at the RAN node providing resource status updates. In this regard, Figure 8 illustrates a system 800 including a first RAN node 802-1 and a second RAN node 802-2, each of which may be a base station 702 (e.g., gNB, eNB, en-gNB, ng-eNB) or a network node that performs part of the functionality of the base station 702 (e.g., gNB-CU, gNB-CU- CP, eNB-CU, or eNB-CU-CP). As described below in detail, the first RAN node 802-1 receives a resource status update(s) from the second RAN node 802-2, where the resource status update(s) includes information about stored UE contexts for UEs in an inactive state (e.g., RRC Inactive) hosted in the second RAN 802-2. The resource status update(s) may also include any or all of the information included in the existing resource update (see Introduction). The first RAN node 802-1 determines one or more MLB actions to be taken (e.g., by the first RAN node 802-1) based on the received resource status update(s) including the information about stored UE contexts for UEs in the inactive state hosted by the second RAN node 802-2. In some embodiments (e.g., when the first RAN node 802-1 and the second RAN node 802-2 are in the same RAN), the first RAN node 802-1 and the second RAN node 802-2 communicate directly (e.g., via X2). However, in some other embodiments (e.g., when the first RAN node 802-1 and the second RAN node 802-2 are in separate RANs), the first RAN node 802-1 and the second RAN node 802-2 communicative via one or more core network nodes 804.

Figure 9 is a flow chart that illustrates one embodiment of a method of operation of the first RAN node 802-1. Optional steps are represented by dashed boxes. As illustrated, the first RAN node 802-1 may send a request to the second RAN node 802-2 a request for a resource status update(s) (step 900). The request may include information indicating that the first RAN node 802-1 desires to receive a resource status update(s) from the second RAN node 802-1 that includes information related to stored UE contexts for UEs in inactive state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-1. The first RAN node 802-1 may receive an acknowledgment of the request from the second RAN node 802-2 (step 902).

The first RAN node 802-1 receives, from the second RAN node 802-2, a resource status update(s) that includes information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2 (step 904). Then, the first RAN node 802-1 may evaluate MLB actions based on the received resource status update(s) including the information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2 (step 906). In other words, in one embodiment, the first RAN node 802-1 determines one or more adjusted mobility settings based on the received resource status update(s) including the information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2. The first RAN node 802-1 may send, to the second RAN node 802-2, proposed adjusted mobility settings determined based on the information received from the second RAN node 802-2 in the resource status update(s) (step 908).

Thus, an exemplary embodiment at the first RAN node 802-1 may include:

• (Optional) The first RAN node 802-1 sends (in step 900) to the second RAN node 802-2 a request per cell to provide information to the first RAN node 802-1 concerning the stored UE context for RRC Inactive UEs hosted at the second RAN node 802-2. The information related to the stored UE context for UEs in inactive state (e.g., RRC Inactive) at the second RAN node 802-1 may include: o number of stored UE context for inactive (e.g., RRC Inactive) UEs, and/or o percentage of stored UE contexts for inactive (e.g., RRC Inactive) UEs compared to number of UEs in connected state (e.g., RRC Connected state), and/or o percentage of stored UE contexts for UEs in inactive (e.g., RRC Inactive) state compared to maximum number of UEs in connected (e.g., RRC Connected) state allowed in the cell.

• The first RAN node 802-1 receives from the second RAN node 802-2 (e.g., in the resource status update(s) of step 904) information per cell concerning the stored UE contexts for UEs in inactive (e.g., RRC Inactive) state at the second RAN node 802-2, as described above.

• The first RAN node 802-1 considers (e.g., in step 906) the received information related to the stored UE contexts for inactive UEs at the second RAN node 802-2 for decisions concerning load balancing (e.g., for mobility decisions to balance the load between the first RAN node 802-1 and the second RAN node 802-2).

• The first RAN node 802-1 may use the information received from the second RAN node 802-2 to judge the total number of RRC connections that the second RAN node 802-2 may be requested to serve and/or the total number of UE contexts the second RAN node 802-2 may need to store. Such evaluation may be performed, for example, on the basis of assumptions about the number of Inactive UEs that may resume at the second RAN node's cell for which the RRC Inactive information has been received. Such number of resumed UEs will constitute new RRC connections to be served by the second RAN node 802-2 and, for that, they will reduce the capacity of the second RAN node 802-2 to accept new UEs via MLB ("mobility load balancing").

Figure 10 is a flow chart that illustrates one embodiment of a method of operation of the second RAN node 802-2. Optional steps are represented by dashed boxes. As illustrated, the second RAN node 802-2 may receive from the first RAN node 802-1 a request for a resource status update(s) (step 1000). In one embodiment, the request indicates that the second RAN node 802-2 is to send resource status update(s) including information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) hosted in the second RAN node 802-2. The second RAN node 802-2 may send an acknowledgement of the request to the first RAN node 802-1 (step 1002).

The second RAN node 802-2 sends, to the first RAN node 802-1, a resource status update(s) that includes information related to stored UE contexts for UEs in inactive state (e.g., RRC Inactive) hosted in the second RAN node 802-2 (step 1004). The second RAN node 802-2 may receive from the first RAN node 802-1 proposed adjusted mobility settings deduced based on the information received from the second RAN node 802-1 (step 1006). The second RAN node 802-2 may apply the adjusted mobility settings proposed by the first RAN node 802-1 (step 1008). The second RAN node 802-2 may send to the first RAN node 802-1 an acknowledgment of the proposed adjusted mobility settings (step 1010).

Thus, an exemplary embodiment at the second RAN node 802-2 may include:

• (Optional) The second RAN node 802-2 receives (in step 1000) from the first RAN node 802-1 a request to provide information per cell to the first RAN node 802-1 concerning the stored UE contexts for inactive (e.g., RRC Inactive) UEs at the second RAN node 802-2, the information being described in the embodiments for the first RAN node 802-1.

• (Optional) E.g., in step 1002, the second RAN node 802-2 sends an indication to the first RAN node 802-1 indicating that the request to provide (e.g., periodic) updates to the first RAN node 802-1 including information related to stored UE contexts for Inactive UEs at the second RAN node 802-2 has been acknowledged. Alternatively, the second RAN node 802-2 sends to the first RAN node 802-1 an indication indicating that the request to provide (e.g., periodic) updates to the first RAN node 802-1 including information related to stored UE contexts for Inactive UEs at the second RAN node has been refused.

• The second RAN node 802-2 sends (e.g., in step 1004) to the first RAN node 802-1 (e.g., periodic) updates per cell comprising information concerning the stored UE contexts for inactive (e.g., RRC Inactive) UEs at the second RAN node 802-2. • (Optional) The second RAN node 802-2 receives from the first RAN node 802- 1 proposals for adjusted mobility settings e.g., using legacy Mobility Setting Change procedure) with characteristics described above (e.g., in step 1006).

Figure 11 illustrates one embodiment of a method of operation between the first RAN node 802-1 and the second RAN node 802-2 in the same system (RAN system 1), which communicate directly (e.g., via X2). Optional steps are represented by dashed lines. As illustrated in Figure 11, the first RAN node 802-1 may send a Resource Status Request to the second RAN node 802-2 (step 1100). The request may include information indicating that the first RAN node 802-1 desires to receive a resource status update(s) from the second RAN node 802-2 that includes information related to stored UE contexts for UEs in inactive state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2. The second RAN node 802-2 may send an acknowledgment of the request to the first RAN node 802-1 (step 1102).

The first RAN node 802-1 receives, from the second RAN node 802-2, a resource status update(s) that includes information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2 (step 1104). Then, the first RAN node 802-1 may evaluate MLB actions based on the received resource status update(s) including the information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2 (step 1106). In other words, in one embodiment, the first RAN node 802-1 determines one or more adjusted mobility settings based on the received resource status update(s) including the information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2. The first RAN node 802-1 may send, to the second RAN node 802-2, a mobility settings change request determined based on the information received from the second RAN node 802-2 in the resource status update(s) (step 1108). The second RAN node 802-2 may send an acknowledgement of the mobility settings change request to the first RAN node 802-1 (step 1110). The second RAN node 802-2 may apply mobile settings requested by the first RAN node 802-1 (1118).

Figure 12 illustrates one embodiment of a method of operation between the first RAN node 802-1 (in RAN system 1) and the second RAN node 802-2 (in RAN system 2) that indirectly communicate via two core networks (core network for RAN system 1 and core network for RAN system 2) for inter-system load balancing. Optional steps are represented by dashed lines.

As illustrated in Figure 12, the first RAN node 802-1 may send the inter-system load balancing request to the second RAN node 802-2 via, in this example, one or more core network nodes 804-1 for RAN system 1 and one or more core network nodes 804- 2 for RAN system 2 (steps 1200 to 1204) The second RAN node 802-2 may receive the inter-system load balancing request from the core network for RAN system 2 804-2 (step 1204). The inter-system load balancing response and the inter-system load balancing update may be generated by the second RAN node 802-2 and indirectly delivered to the first RAN node 802-1 via the core network node(s) for RAN system 2 804-2 and the core network node(s) 804-1 for RAN system 1 (steps 1206 to 1216).

After receiving the inter-system load balancing update(s), the first RAN node 802-1 may evaluate MLB actions based on the information related to stored UE contexts for UEs in inactivate state (e.g., RRC Inactive) that are hosted in (e.g., stored by) the second RAN node 802-2, as described above (step 1218).

Examples of Possible Implementations

An example implementation of at least some aspects of the embodiments described above is shown below as changes to 3GPP TS 38.423 (XnAP), where the changes are marked in underlined and bolded text.

Start of Example of Possible Implementation for TS 38.423 (XnAP)

9.1.3.18 RESOURCE STATUS REQUEST

This message is sent by NG-RAN nodei to NG-RAN node2 to initiate the requested measurement according to the parameters given in the message.

Direction: NG-RAN nodei NG-RAN node2.

9.1.3.21 RESOURCE STATUS UPDATE This message is sent by NG-RAN node2 to NG-RAN nodei to report the results of the requested measurements.

Direction: NG-RAN node2 -> NG-RAN nodei.

9.2.2.x1 NR RRC Inactive Contexts

The NR RRC Inactive Contexts IE indicates the overall status of stored UE Context for NR RRC Inactive users per cell.

9.2.2.x2 Max number of UE Contexts for RRC Inactive The Max number of UE Contexts for RRC Inactive IE indicates the maximum absolute number of UE Contexts stored for users in RRC INACTIVE mode. 9.2.2.x3 Available RRC Connection Capacity Value

The Available UE Contexts for RRC Inactive Capacity Value IE indicates the residual percentage of the stored UE Contexts for RRC Inactive, relative to the maximum number of RRC Inactive users supported by the cell.

End of Example of Possible Implementation for TS 38.423 (XnAP)

An example implementation of at least some aspects of the embodiments described above is shown below as changes to 3GPP TS 36.423 (X2AP), where the changes are shown in underlined and bolded text

Start of Example of Possible Implementation for TS 36.423 (X2AP)

9.1 .2.45 EN-DC RESOURCE STATUS REQUEST

This message is sent by the eNB to the en-gNB to initiate the requested measurement according to the parameters given in the message.

Direction: eNB en-gNB.

9.1.2.48 EN-DC RESOURCE STATUS UPDATE

This message is sent by the en-gNB to the eNB to report the results of the requested measurements.

Direction: en-

9.2.2.y1 NR RRC Inactive Contexts

9.2.2.V2 Max number of UE Contexts for RRC Inactive The Max number of UE Contexts for RRC Inactive IE indicates the maximum absolute number of UE Contexts stored for users in RRC INACTIVE mode.

9.2.2.y3 Available RRC Connection Capacity Value

End of Example of Possible Implementation for TS 36.423 (X2AP)

An example implementation of at least some aspects of the embodiments described above is shown below as changes to 3GPP TS 38.413 (NGAP), where the changes are shown in underlined and bolded text Over NGAP, an Inter-System Load Balancing Request can be realized using Inter-System SON Information IE to which a specific IE can be used to indicate the request to obtain updates on stored number of UE Context for RRC Inactive users.

Start of Example of Possible Implementation forTS 38.413 (NGAP)

9.3.3.C Inter-system Resource Status

9.3.3.x1 NR RRC Inactive Contexts

9.3.3.x2 _ Max number of UE Contexts for RRC Inactive

The Max number of UE Contexts for RRC Inactive IE indicates the maximum absolute number of UE Contexts stored for users in RRC INACTIVE mode.

9.3.3.x3 Available RRC Connection Capacity Value

End of Example of Possible Implementation forTS 38.413 (NGAP)

Additional Description

Figure 13 is a schematic block diagram of a radio access node 1300 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The radio access node 1300 may be, for example, a base station 702 or 706 or a network node that implements all or part of the functionality of the base station 702 or gNB described herein. As illustrated, the radio access node 1300 includes a control system 1302 that includes one or more processors 1304 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 1306, and a network interface 1308. The one or more processors 1304 are also referred to herein as processing circuitry. In addition, the radio access node 1300 may include one or more radio units 1310 that each includes one or more transmitters 1312 and one or more receivers 1314 coupled to one or more antennas 1316. The radio units 1310 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 1310 is external to the control system 1302 and connected to the control system 1302 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 1310 and potentially the antenna(s) 1316 are integrated together with the control system 1302. The one or more processors 1304 operate to provide one or more functions of the radio access node 1300 as described herein (e.g., one or more functions of the base station 702, gNB, gNB-CU, or gNB-DU described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1306 and executed by the one or more processors 1304.

Figure 15 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 1300 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.

As used herein, a "virtualized" radio access node is an implementation of the radio access node 1300 in which at least a portion of the functionality of the radio access node 1300 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 1300 may include the control system 1302 and/or the one or more radio units 1310, as described above. The control system 1302 may be connected to the radio unit(s) 1310 via, for example, an optical cable or the like. The radio access node 1300 includes one or more processing nodes 1500 coupled to or included as part of a network(s) 1502. If present, the control system 1302 or the radio unit(s) are connected to the processing node(s) 1500 via the network 1502. Each processing node 1500 includes one or more processors 1504 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1506, and a network interface 1508.

In this example, functions 1510 of the radio access node 1300 described herein (e.g., one or more functions of the base station 702, gNB, gNB-CU, or gNB-DU described herein) are implemented at the one or more processing nodes 1500 or distributed across the one or more processing nodes 1500 and the control system 1302 and/or the radio unit(s) 1310 in any desired manner. In some particular embodiments, some or all of the functions 1510 of the radio access node 1300 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1500. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 1500 and the control system 1302 is used in order to carry out at least some of the desired functions 1510. Notably, in some embodiments, the control system 1302 may not be included, in which case the radio unit(s) 1310 communicate directly with the processing node(s) 1500 via an appropriate network interface(s).

In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the radio access node 1300 or a node (e.g., a processing node 1500) implementing one or more of the functions 1510 of the radio access node 1300 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 14 is a schematic block diagram of the radio access node 1300 according to some other embodiments of the present disclosure. The radio access node 1300 includes one or more modules 1400, each of which is implemented in software. The module(s) 1400 provide the functionality of the radio access node 1300 described herein (e.g., one or more functions of the base station 702, gNB, gNB-CU, or gNB-DU described herein). This discussion is equally applicable to the processing node 1500 of Figure 15 where the modules 1400 may be implemented at one of the processing nodes 1500 or distributed across multiple processing nodes 1500 and/or distributed across the processing node(s) 1500 and the control system 1302.

Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations,

At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

• 3GPP Third Generation Partnership Project

• 5G Fifth Generation

• 5GC Fifth Generation Core

• 5GS Fifth Generation System

• AN Access Network

• AP Access Point

• ASIC Application Specific Integrated Circuit

• AUSF Authentication Server Function

• CN Core Network

• CP Control Plane

• CPU Central Processing Unit

• CR Cell Reselection

• DN Data Network

• DSP Digital Signal Processor

• eNB Enhanced or Evolved Node B

• EN-DC E-UTRAN New Radio - Dual Connectivity

• EPS Evolved Packet System

• E-UTRA Evolved Universal Terrestrial Radio Access FDD Frequency Division Duplex

FPGA Field Programmable Gate Array gNB New Radio Base Station gNB-DU New Radio Base Station Distributed Unit

HO Handover

HSS Home Subscriber Server loT Internet of Things

IP Internet Protocol

LTE Long Term Evolution

MAC Medium Access Control

MLB Mobility Load Balancing

MME Mobility Management Entity

MTC Machine Type Communication

NEF Network Exposure Function

NF Network Function

NG-RAN Next Generation Radio Access Network

NR New Radio

NRF Network Function Repository Function

NSSF Network Slice Selection Function

OTT Over-the-Top

PC Personal Computer

PCF Policy Control Function

PDCP Packet Data Convergence Protocol

P-GW Packet Data Network Gateway

QoS Quality of Service

RAM Random Access Memory

RAN Radio Access Network

RLC Radio Link Control

RNL Radio Network Layer

ROM Read Only Memory

RRC Radio Resource Control

RRH Remote Radio Head • RSRP Reference Signal Received Power

• RSRQ Reference Signal Received Quality

• RTT Round Trip Time

• SCEF Service Capability Exposure Function

• SINR Signal-to-interference-plus-noise ratio

• SMF Session Management Function

• SON Self Organizing Network

• SSB Synchronization Signal Block

• TDD Time Division Duplex

• TNL Transport Network Layer

• UDM Unified Data Management

• UE User Equipment

• UP User Plane

Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

1. A method performed by a first Radio Access Network, RAN, node (802-1) for mobility load balancing, the method comprising: receiving (904), from a second RAN node (802-2), information related to stored User Equipment, UE, contexts for inactive UEs that are hosted by the second RAN node (802-2); and performing one or more actions based on the received information.

2. The method of claim 1, wherein performing the one or more actions comprises evaluating (906) mobility load balancing actions based on the information related to stored UE contexts for inactive UEs.

3. The method of claim 1, wherein receiving (904), from the second RAN node (802-2), information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) comprises receiving the information from the second RAN node (802-2) via a direct interface between the first RAN node (802-1) and the second RAN node (802-2).

4. The method of claim 1, wherein receiving (904), from the second RAN node (802-2), information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) comprises receiving the information from the second RAN node (802-2) via one or more core network nodes (1204, 1206).

5. The method of claim 1 further comprising: sending (900), to the second RAN node (802-2), a request to send information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2).

6. The method of claim 5, wherein the information related to stored UE contexts for inactive UEs is stored in one bit of a bitmap in the request.

7. The method of claim 5 further comprising: receiving (902), from the second RAN node (802-2), an acknowledgement of the request to send information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2).

8. The method of any of claim 5 or 6, wherein the request to send information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) is included in a resource status request message (1106) sent from the first RAN node (802-1) to the second RAN node (802-2).

9. The method of claim 8, wherein the information related to stored UE contexts for inactive UEs is stored in one bit of a bitmap in the resource status request message.

10. The method of any of claims 2 to 9 further comprising: sending (908) to the second RAN node (802-2) proposed adjusted mobility settings deducted based on the information received from the second RAN node (802-2).

11. The method of any of claims 1 to 10, wherein the information related to stored UE contexts for inactive UEs comprises a number of stored inactive UE contexts.

12. The method of any of claims 1 to 10, wherein the information related to stored UE contexts for inactive UEs comprises a maximum number of stored inactive UE contexts.

13. The method of any of claims 1 to 12, wherein the information related to stored UE contexts for inactive UEs comprises a percentage of stored UE contexts for inactive UEs compared to a number of UEs in RRC connected state.

14. The method of any of claims 1 to 12, wherein the information related to stored UE contexts for inactive UEs further comprises a percentage of stored UE contexts for inactive UEs compared to a maximum number of UEs in RRC connected state allowed in a cell.

15. The method of any of claims 1 to 14, wherein the information related to stored UE contexts for inactive UEs that are hosted by second RAN node (802-2) is included in a resource status update message (1110) sent from the second RAN node (802-2) to the first RAN node (802-1).

16. The method of any of claims 1 to 15, wherein the first RAN node (802-1) and the second RAN node (802-2) are respectively located in two different communication systems.

17. The method of any of claims 1 to 16, wherein the first RAN node (802-1) forwards the request to a first core network (1204); the first core network (1204) relays the request to a second core network (1206); and the second core network (1206) forwards the request to the second RAN node (802-2).

18. The method of any of claims 1 to 17, wherein the inactive UEs are Radio Resource Control, RRC, Inactive UEs.

19. A method performed by a second Radio Access Network, RAN, node (802-2), the method comprising: sending (1004), to a first RAN node (802-1), information related to stored User Equipment, UE, contexts for inactive UEs that are hosted by the second RAN node (802- 2); and performing one or more actions after sending the information to the first RAN node (802-1).

20. The method of claim 19, wherein performing the one or more actions comprises receiving (1008) adjusted mobility settings proposed by the first RAN node (802-1) and applying (1010) the adjusted mobility settings.

21. The method of claim 19, wherein sending (1004) to the first RAN node (802-1) information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) comprises sending the information to the first RAN node (802-1) via a direct interface between the first RAN node (802-1) and the second RAN node (802- 2).

22. The method of claim 19, wherein sending (1004) to the first RAN node (802-1) information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) comprises sending the information to the first RAN node (802-1) via one or more core network nodes (1204).

23. The method of any of claims 19 to 22, further comprising: receiving (1000), from the first RAN node (802-1), a request to send, to the first RAN node (802-1), the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2).

24. The method of claim 23, further comprising: sending (1002), to the first RAN node (802-1), an acknowledgment of the request sent by the first RAN node (802-1).

25. The method of any of claims 19 to 24, further comprising: receiving (1006), from the first RAN node (802-1), proposed adjusted mobility settings deducted based on the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2).

26. The method of claim 25, further comprising: sending (1008), to the first RAN node (802-1), an acknowledgment of proposed adjusted mobility settings deducted based on the information received from the second RAN node (802-2).

27. The method of claim 19 to 26, wherein the information related to stored UE contexts for inactive UEs comprises the number of stored UE contexts for inactive UEs.

28. The method of claim 19 to 26, wherein the information related to stored UE contexts for inactive UEs comprises a percentage of stored UE contexts for inactive UEs compared to a number of UEs in RRC connected state.

29. The method of any of claims 19 to 26, wherein the information related to stored UE contexts for inactive UEs further comprises a percentage of stored UE contexts for inactive UEs compared to a maximum number of UEs in RRC connected state.

30. The method of any of claims 19 to 29, wherein the request to send information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) is included in a resource status request message (1106) sent from the first RAN node (802-1) to the second RAN node (802-2).

31. The method of any of claims 19 to 30, wherein the information related to stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) is included in a resource status update message (1110) sent from the second RAN node (802-2) to the first RAN node (802-1).

32. The method of any of claims 19 to 31, wherein the first RAN node (802-1) and the second RAN node (802-2) are respectively located in two different communication systems.

33. The method of any of claims 19 to 32, wherein the second RAN node (802-2) forwards the acknowledgment of the request to a second core network (1206); the second core network (1206) relays the acknowledgment of the request to a first core network (1204); and the first core network (1204) forwards the acknowledgment of the request to the first RAN node (802-1).

34. The method of any of claims 19 to 32, wherein the second RAN node (802-2) forwards the information on stored UE contexts for inactive UEs that are hosted by the second RAN node (802-2) to a second core network (1206); the second core network (1206) relays the information to a first core network (1204); and the first core network (1204) forwards the information to the first RAN node (802-1).

35. The method of any of claims 19 to 34, wherein the inactive UEs are Radio Resource Control, RRC, Inactive UEs.

36. A first Radio Access Network, RAN, node (802-1) adapted to: receive (904), from a second RAN node (802-2), information related to stored User Equipment, UE, contexts for inactive UEs that are hosted by the second RAN node (802-2); and perform one or more actions based on the received information.

37. The first RAN node (802-1) of claim 36 wherein the first RAN node (802-1) is further adapted to perform the method of any of claims 2 to 18.

38. A first Radio Access Network, RAN, node (802-1) comprising processing circuitry configured to cause the first RAN node (802-1) to: receive (904), from a second RAN node (802-2), information related to stored User Equipment, UE, contexts for inactive UEs that are hosted by the second RAN node (802-2); and perform one or more actions based on the received information.

39. The first RAN node (802-1) of claim 38 wherein the processing circuitry is further configured to cause the first RAN node (802-1) to cause the first RAN node (802-1) to perform the method of any of claims 2 to 18.

40. A second Radio Access Network, RAN, node (802-2) adapted to: send (1004), to a first RAN node (802-1), information related to stored User Equipment, UE, contexts for inactive UEs that are hosted by the second RAN node (802- 2); and perform one or more actions after sending the information to the first RAN node (802-1).

41. The second RAN node (802-2) of claim 40 wherein the second RAN node (802-2) is further adapted to perform the method of any of claims 20 to 35.

42. A second Radio Access Network, RAN, node (802-2) comprising processing circuitry configured to cause the second RAN node (802-2) to: send (1004), to a first RAN node (802-1), information related to stored User Equipment, UE, contexts for inactive UEs that are hosted by the second RAN node (802- 2); and perform one or more actions after sending the information to the first RAN node (802-1).

43. The second RAN node (802-2) of claim 42 wherein the processing is further configured to cause the second RAN node (802-2) to cause the second RAN node (802- 2) to perform the method of any of claims 20 to 35.