Patent Application
20250168843
The present application claims priority to Indian Provisional Patent Application No. 202321078359 filed on Nov. 17, 2023, the entirety of which is incorporated by reference herein.
The present disclosure is related to 4G and/or 5G wireless networks, and relates more particularly to optimized method and apparatus to detect and correct resource allocation mismatch in different radio access network (RAN) nodes, e.g., Open Radio Access Network (O-RAN) nodes.
In the following sections, overview of Next Generation Radio Access Network (NG-RAN) architecture and 5G New Radio (NR) stacks will be discussed. 5G NR (New Radio) user and control plane functions with monolithic gNB (gNodeB) are shown in
In addition, as shown in
For the control plane (shown in
NG-Radio Access Network (NG-RAN) architecture from 3GPP TS 38.401 is shown in
Open Radio Access Network (O-RAN) is based on disaggregated components which are connected through open and standardized interfaces based on 3GPP NG-RAN. An overview of O-RAN with disaggregated RAN CU (Centralized Unit), DU (Distributed Unit), and RU (Radio Unit), near-real-time Radio Intelligent Controller (Near-RT RIC) and non-real-time RIC (Non-RT RIC) is illustrated in
As shown in
A cell site can comprise multiple sectors, and each sector can support multiple cells. For example, one site could comprise three sectors and each sector could support eight cells (with eight cells in each sector on different frequency bands). One CU-CP (CU-Control Plane) could support multiple DUs and thus multiple cells. For example, a CU-CP could support 1,000 cells and around 100,000 User Equipments (UEs). Each UE could support multiple Data Radio Bearers (DRB) and there could be multiple instances of CU-UP (CU-User Plane) to serve these DRBs. For example, each UE could support 4 DRBs, and 400,000 DRBs (corresponding to 100,000 UEs) may be served by five CU-UP instances (and one CU-CP instance).
The DU could be located in a private data center, or it could be located at a cell-site. The CU could also be in a private data center or even hosted on a public cloud system. The DU and CU, which are typically located at different physical locations, could be tens of kilometers apart. The CU communicates with a 5G core system, which could also be hosted in the same public cloud system (or could be hosted by a different cloud provider). A RU (Radio Unit) (shown as O-RU 803 in
The E2 nodes (CU and DU) are connected to the near-real-time RIC 132 using the E2 interface. The E2 interface is used to send data (e.g., user and/or cell KPMs) from the RAN, and deploy control actions and policies to the RAN at near-real-time RIC 132. The applications or services at the near-real-time RIC 132 that deploys the control actions and policies to the RAN are called xApps. During the E2 setup procedures, the E2 node advertises the metrics it can expose, and an xApp in the near-RT RIC can send a subscription message specifying key performance metrics which are of interest. The near-real-time RIC 132 is connected to the non-real-time RIC 133 (which is shown as part of Service Management and Orchestration (SMO) Framework 805 in
The E2 interface specifications facilitate the following:
The E2 interface functions are grouped into the following categories: i) Near-RT RIC services; and ii) Near-RT RIC support functions.
Near-RT RIC services: Near-RT RIC can use the following RIC services provided by an E2 node:
Near-RT RIC support functions include: i) Interface Management (E2 Setup, E2 Reset, E2 Node Configuration Update, E2 Removal, Reporting of General Error Situations); and ii) Near-RT RIC Service Update, i.e., an E2-Node-initiated procedure to inform Near-RT RIC of changes to the list of supported Near-RT RIC services and mapping of services to functions.
In this section, O-RAN specified E2 service models will be discussed. A given RAN Function offers a set of services to be exposed over the E2 (REPORT, INSERT, CONTROL and/or POLICY) using E2AP. These services are offered using following service models:
In this section, PDU sessions, DRBs, and quality of service (QOS) flows will be discussed. In 5G networks, PDU connectivity service is a service that provides exchange of PDUs between a UE and a data network identified by a Data Network Name (DNN). The PDU Connectivity service is supported via PDU sessions that are established upon request from the UE. The DNN defines the interface to a specific external data network. One or more QoS flows can be supported in a PDU session. All the packets belonging to a specific QoS flow have the same 5QI (5G QoS Identifier). A PDU session consists of the following: Data Radio Bearer which is between UE and CU in RAN; and an NG-U GTP tunnel which is between CU and UPF (User Plane Function) in the core network.
The following should be noted for 3GPP 5G network architecture, which is illustrated in
In this section, UE context management will be briefly discussed. Among the possible functional splits for 5G NR and/or O-RAN, in Split 2 deployment mode, gNB comprises CU-CP and one or more CU-UPs and DUs (see, e.g., the gNB architecture in
Because UE context exists in all RAN nodes until the call is released, in an ideal scenario, when the call is released, UE context is deleted in all the nodes. However, at times the UE context deletion may not occur at all the nodes for various reasons, e.g., software bugs, memory exhaustion, link failures, packet loss on external or internal links, synchronization issues between active and standby nodes, etc. Due to such issues, there is a high possibility that stale UE context may remain in some nodes. Over a period of time, the number of stale UEs in the node can grow to the extent that all resources are exhausted, and thereby cause critical service outages. Occurrence of similar mismatch is possible for other resources such as PDU session, DRB, and/or QoS Flow, which can negatively impact service if RAN nodes are not able to allocate any of the above mentioned resources.
Accordingly, there is a need for an improved system and method for RAN resource (e.g., UE context) mismatch management in 5G networks.
Accordingly, what is desired is an improved system and method for RAN resource UE context) mismatch management in 5G networks.
According to a first example embodiment of the system and method according to the present disclosure, an RIC-based technique is utilized to detect and clean up stale RAN resources.
According to a first variant of the first example system and method, Non-RT RIC can periodically poll the RAN nodes (e.g., CU-CP, CU-UP and DU of gNB) via a management interface (e.g., as implemented by network management system (NMS)) to get the information about the allocated UE contexts. In response to the allocated UE context request, along with other information, RAN nodes can include the application protocol identity (AP ID) for respective protocol interfaces between the respective RAN nodes. Using the AP ID as well as other information received for different interfaces from CU-CP, CU-UP and DU, the Non-RT RIC can correlate the received information to determine whether all nodes are in sync or not. After stale UE contexts are identified, Non-RT RIC can send a trigger to respective Network function(s) to perform the necessary clean-up. The clean-up command should include gNB ID, NF ID and a list of AP IDs for the node (e.g., CU-UP or CU-CP) to identify and delete the stale user context(s).
According to a second variant of the first example system and method, telemetry data are used as tracing information to detect whether any of the RAN nodes has stale UE context(s). RAN nodes report tracing data to the RIC (e.g., Near-RT RIC). Apart from standard 3GPP trace events, internal events such as UE context allocation and UE context release can be traced by RAN nodes. 3GPP trace events and internal trace events from CU-CP, CU-UP and DU nodes can be monitored by the RIC (e.g., Near-RT RIC) to determine whether all nodes in the gNB have cleaned up the UE context or not. After stale UE contexts are identified, Near-RT RIC can send a trigger to respective network function(s) to perform the necessary clean-up.
According to a third variant of the first example system and method, a stale UE context can be detected based on performance measurement (PM) counters the RIC (e.g., Non-RT RIC) receives from RAN nodes. Because i) the number of UEs (connected) at CU-CP should be equal to the number of UEs across all DUs served by CU-CP, and ii) the number of UEs (connected or inactive) at CU-CP should be equal to the number of UEs across all CU-UPs served by CU-CP, if any discrepancy is found between the number of connected UEs reported by different nodes and the discrepancy continues to be present for multiple PM counter collection intervals, it can be treated as a stale UE condition.
According to a fourth variant of the first example system and method, standard 3GPP events and internal events (e.g., UE context allocation and UE context release) from different E2 nodes (CU-CP, CU-UP and/or DU) can be monitored by Near-RT RIC to detect stale context in real time. Near-RT RIC and E2 nodes can utilize report services to obtain information regarding i) specific events such as Initial UL RRC Message, Incoming Xn/NG HO Request, UE Context Release Request, and Bearer Context Release Request, etc., and/or ii) UE Context Management and Bearer Context Management call process types. Based on the information received from the E2 nodes, corrective action can be triggered immediately or additional steps taken to clear the stale UE contexts.
According to a second example embodiment of the method, a procedure to detect and clean up stale resources based on Resource Status Reporting is implemented. By adding new, additional IEs to existing Resource Status Reporting messages, the CU-CP can request status reports for user and/or bearer session contexts periodically from CU-UP and DU, and an audit can be performed based on some configured thresholds, e.g., when the number of connected UEs in a given cell is greater than 75%. Using this information from other nodes (CU-UP and DU), CU-CP can ensure that all nodes are in sync. In case some stale contexts are found, a clean-up of stale contexts can be performed.
According to a third example embodiment of the method, the DU sends the UE CONTEXT RELEASE REQUEST to the CU-CP to release the UE-associated logical F1-connection. The UE CONTEXT RELEASE REQUEST also includes a cause. In response, the CU-CP initiates the UE CONTEXT RELEASE by sending UE CONTEXT RELEASE COMMAND to the DU. The DU subsequently sends UE CONTEXT RELEASE COMPLETE message to gNB-CU-CP to report the completion of the UE context release.
In the present disclosure, system and/or network components (e.g., RIC (including Non-RT RIC and Near-RT RIC), gNB-CU (including gNB-CU-CP and gNB-CU-UP), gNB-DU, etc.) can be implemented as i) software executed on processor(s) and/or servers, and/or ii) dedicated hardware modules comprising processor(s) executing software, to implement the respective functionalities of the system and/or network components.
For this application, the following terms and definitions shall apply:
The term “network” as used herein includes both networks and internetworks of all kinds, including the Internet, and is not limited to any particular type of network or inter-network.
The terms “first” and “second” are used to distinguish one element, set, data, object or thing from another, and are not used to designate relative position or arrangement in time.
The terms “coupled”, “coupled to”, “coupled with”, “connected”, “connected to”, and “connected with” as used herein each mean a relationship between or among two or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, and/or means, constituting any one or more of (a) a connection, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, (b) a communications relationship, whether direct or through one or more other devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means, and/or (c) a functional relationship in which the operation of any one or more devices, apparatus, files, programs, applications, media, components, networks, systems, subsystems, or means depends, in whole or in part, on the operation of any one or more others thereof.
The above-described and other features and advantages of the present disclosure will be appreciated and understood by those skilled in the art from the following detailed description, drawings, and appended claims.
Method 1—RIC-Based Method (e.g., Using rApp/xApp) to Handle Stale RAN Resources:
According to a first example embodiment of the system and method according to the present disclosure, an RIC-based technique is utilized to detect and clean up stale RAN resources. Described below are several sub-variants of Method 1.
Method 1A-Polling-based method: In a first sub-variant (Method 1A), a polling-based method is implemented to detect and clean up the resources. Although the example Method 1A is explained for UE context resources, the example Method 1A is equally applicable to other RAN resources such as PDU session, DRB, etc. Various Steps of Method 1A are explained below.
Step 1 (Data Collection): Non-RT RIC (e.g., 901 as shown in
Additionally, Non-RT RIC can periodically poll the CU-CP and DU via the management interface (e.g., NMS 902) to get the information about the allocated UE contexts using the Cell Global identifier (CGI) and Cell Radio-Network Temporary Identifier (CRNTI) tuple. The CGI uniquely identifies the cell in the PLMN, and the CRNTI locally identifies the UE in the cell. The (CGI, CRNTI) tuple acts as a unique identifier for the UE context maintained at the CU-CP and DU, respectively.
Data collection can be optimized further by reporting UE contexts whose age is greater than a configurable threshold. When the Non-RT RIC polls for the UE context information, it can specify the minimum age of the UE context to be reported, e.g., the Non-RT RIC can specify only UE context aged more than 5 minutes to be reported. This helps in reducing both bandwidth (BW) and processing cost.
Step 2 (Data Analysis): Using the AP ID as well as other information (e.g., as discussed above) received for different interfaces from CU-CP, CU-UP and DU, the Non-RT RIC can correlate the received information to determine whether all nodes are in sync or not.
As shown in Table 1 and
To identify a UE uniquely in CU-CP and CU-UP, gNB-CU-CP UE E1AP ID and gNB-CU-UP UE E1AP ID shall be matched across CU-CP and CU-UP. Similarly, gNB-CU UE F1AP ID and gNB-DU UE F1AP ID shall be matched to identify UE across CU-CP and DU. This 3-way comparison across CU-CP, one or more CU-Ups, and DUs in a gNB can be used to detect whether any stale UE context is present in the system. Table 2 below illustrates examples of how stale UE contexts can be detected in a gNB based on APID:
In an example embodiment, to identify a UE uniquely in CU-CP and DU, the (CGI, CRNTI) tuple shall be matched across CU-CP and DU. This 2-way comparison across CU-CP and one or more DUs in a gNB can be used to detect whether any stale UE context is present in the respective node. An example of using such comparison is shown in Table 3 below:
An example of detecting stale UEs in the scenario of inter-DU conditional handover (CHO) is shown in Table 4 below:
In an alternative example, we can also determine stale UE contexts across gNBs connected via Xn interface in the scenario of CHO.
For a UE which has transitioned to RRC Inactive state, the UE is allocated IRNTI, and the CRNTI is released. The UE context is maintained in CU-CP and CU-UP, while the UE context in DU is cleared when the UE has transitioned to RRC Inactive. When the 3-way comparison (e.g., as described above) based on AP ID is applied to identify stale UEs, the UE contexts for UEs which have transitioned to RRC Inactive state are not found in DU, but this does not necessarily mean there are stale UEs in the CU-CP. If the UE context available in CU-CP is associated with IRNTI but not with CRNTI, then it is not a stale UE. If the UE context available in CU-CP is associated with CRNTI and UE context in DU is not found, then it is a stale UE in CU-CP. Alternatively, if the UE context based on AP ID is found in CU-CP and CU-UP but not found in DU, then it can be deduced that the UE is an RRC-Inactive UE. If i) the Non-RT RIC determines the UE is RRC-Inactive, and ii) UE context is found in CU-CP but not in CU-UP, then there is a stale UE in CU-CP. If i) the Non-RT RIC determines the UE is RRC-Inactive, and ii) UE context is found in CU-UP but not in CU-CP, then there is stale UE in CU-UP.
Step 3 (Clean-up action): After stale UE contexts are identified in Step 2, Non-RT RIC can send a trigger to respective Network function(s) to perform the necessary clean-up. The clean-up command should include gNB ID, NF ID and a list of AP IDs for the node (e.g., CU-UP or CU-CP) to identify and delete the stale user context(s). For example, if a stale context is detected in CU-UP, a clean-up command will be sent CU-UP. Similarly, if a stale context is found in CU-CP, a clean-up trigger will be sent to CU-CP. Further optimizations, such as evaluating the status of a stale UE for multiple intervals before initiating the clean-up, are also possible to avoid any false detection, and such optimizations can be implemented in the rApp. it should be noted that Step 2 and Step 3 can be designed differently for detection of stale context of users in RRC-connected mode and RRC-inactive mode.
The above-described Method 1A can also be applied to the following scenario: Non-Standalone (NSA) deployments to find the stale UE contexts across eNB and gNB. When stale UEs are detected across eNB and gNB, clean-up action mentioned above can be triggered on the impacted node to remove the stale UE contexts.
Although Method 1A has been explained for UE context resource, this method can also be used to audit the resource allocation at different levels, e.g., PDU session, DRB, QOS Flow, etc., in the RAN nodes. In addition, although Method 1A has been described as using polling, asynchronous reporting of UE context information to Non-RT RIC at pre-configured interval can also be supported.
Method 1B (Telemetry Data-tracing data): In modern day telecom deployments, telemetry data play an essential role in monitoring the health and performance of the network. RIC-based rApps and xApps rely heavily on the telemetry data from RAN nodes. Performance counters, trace events, and logging are some of the important data requirements of rApps and xApps, and these are being monitored continuously by RIC applications to optimize the network. In the context of stale UE detection, tracing data sent from RAN nodes can be leveraged to detect whether any of the RAN nodes has stale UE context(s). Using trace information not only helps in easily detecting the stale UE contexts, but it will also provide enrichment data in terms of the call flow sequence that potentially caused the stale context in the system. This enrichment data can be further analyzed using artificial intelligence (AI) and/or machine learning (ML) to identify some pattern and automatically detect the source of the issue. Whether the issue is i) caused in a specific scenario, ii) caused in a specific UE model, or iii) due to a specific sequence of events can be easily determined. By employing such techniques, identifying the cause of the problem is greatly simplified in a sub-variant (referred to a Method 1B) of the first example method.
Step 1 (Data Collection); RAN nodes report tracing data to the RIC (e.g., Near-RT RIC). Apart from standard 3GPP trace events, internal events such as UE context allocation and UE context release can be traced by RAN nodes.
Step 2 (Data Analysis): 3GPP trace events and internal trace events from CU-CP, CU-UP and DU nodes can be monitored by the RIC (e.g., Near-RT RIC) to determine whether all nodes in the gNB have cleaned up the UE context or not (i.e., UE context still exists). If any of the nodes did not clean up the UE context, RIC can further monitor the signalling and/or user plane activity of the user. If no activity is observed for a predefined time, such UEs can be marked (categorized) as stale UE context. RIC can further retrieve the UE context information for stale UE context as described in Step 1 and Step 2 of Method 1A to ensure that it is really the case of a stale UE, in which case a clean-up is subsequently triggered.
Step 3 (Clean-up Action): The clean-up action is the same as that described for Method 1A.
Method 1C (Telemetry Data-PM Counters): In this subvariant (Method 1C) of the first example method, the trigger for detecting a stale UE context can be performance measurement (PM) counters. The RIC (e.g., Non-RT RIC) can detect a stale UE based on performance counters it receives from RAN (i.e., E2) nodes. The number of UEs (connected) at CU-CP should be equal to the number of UEs across all DUs served by CU-CP. Similarly, the number of UEs (connected or inactive) at CU-CP should be equal to the number of UEs across all CU-UPs served by CU-CP. This information can be further analyzed at the cell level to obtain the precise information about stale UE context. If any discrepancy is found between the number of connected UEs reported by different nodes and the discrepancy continues to be present for multiple PM counter collection intervals, it can be treated as a stale UE condition. Once a stale UE condition is detected, Method 1A or Method 1B can be used for data collection, analysis and stale UE clean up.
Typically, PM counters are implemented at the cell level identified by CGI. However, PM counter at the cell level may be implemented at CU-CP or DU, depending on the pegging condition associated with the functionality and usage of the counter. To detect the stale UE problem, a counter for the number of RRC-connected users can be pegged at the cell level in both DU and CU, respectively. Whenever the UE context is created in CU-CP and DU, respectively, the counter is incremented, and when the UE context is cleared at the respective node, the counter shall be decremented. At a given point of time, if the number of RRC-connected users at the cell level in CU-CP is equal to the number of RRC-connected users at the cell level in DU, there is no stale UE. However, if there is a mismatch in the number of RRC-connected users at the cell level, then there is a stale UE in either CU-CP or DU. An example is shown in Table 6 below:
Method 1D (Near-RT RIC stale UE detection); In another sub-variant of Method 1 (referred to as Method 1D), in addition to standard 3GPP events, internal events such as UE context allocation and UE context release from different E2 nodes (CU-CP, CU-UP and/or DU) can be monitored by Near-RT RIC, which can determine stale context in real time. Near-RT RIC and E2 nodes can utilize report services, either with report style 1 or 2. With report style 1, Near-RT RIC can request E2 node to report specific events such as Initial UL RRC Message, Incoming Xn/NG HO Request, UE Context Release Request, and Bearer Context Release Request, etc. Similarly, for report style 2, UE Context Management and Bearer Context Management call process types can be configured. Based on the information received from E2 nodes, corrective action can be triggered immediately or additional steps described in Method 1A or 1B can be taken to clear the stale UE contexts.
In the context of Method 1D,
Method 2 (gNB-level native stale resource detection and clean-up): In a second example method (Method 2), a procedure to detect and clean up stale resources based on Resource Status Reporting is explained for UE Context resource. It should be noted that Method 2 can be applied to other RAN resources such as PDU session, DRB, etc.
As shown in
Resource Status Reporting procedure is an existing procedure used on F1-C and E1 interface to report the load measurements to gNB-CU-CP. As part of this procedure, both DU and CU-UP can report the load status of the user and bearer contexts to CU-CP. Additional IEs described below in sections discussing F1-C and E1AP can be added to existing messages to share the required information across different nodes of gNB. CU-CP can request status report for user and/or bearer session contexts periodically from CU-UP and DU. An audit can be performed based on some configured thresholds, e.g., when the number of connected UEs in a given cell is greater than 75% of maximum number of connected UEs supported by the cell or CU-CP, which threshold can be implementation dependent. Using UE context related information reported in Resource Status Reporting procedure from other nodes (CU-UP and DU), CU-CP can ensure that all nodes are in sync. In case some stale contexts are found, clean-up will be performed.
The following sequence of steps illustrate an example for implementing an audit:
Although the above example has been described for auditing UE contexts, similar audits can be performed when a discrepancy is detected at the DRB or the PDU session level, by configuring RESOURCE STATUS REQUEST with appropriate measurement objects. Various example scenarios will be discussed below.
Example 1: In case a bearer context is allocated in CU-UP but a corresponding user context is not found in CU-CP and DU, then CU-CP can send E1 Reset (partial) message containing one or more gNB-CU-CP UE E1AP ID IE and gNB-CU-UP UE E1AP ID IE to explicitly identify the UE association(s) to be reset.
Example 2: In case a user context is allocated in DU but a user context is not found in CU-CP and CU-UP, then CU-CP can send F1 Reset (partial) message containing one or more gNB-DU UE F1AP ID and gNB-CU UE F1AP ID IE to explicitly identify the UE association(s) to be reset.
Example 3: If a user context is found in CU-CP but DU and CU-UP don't have the corresponding user context, then CU-CP can locally perform a UE context release.
Example 4: In case a PDU-level mismatch is detected on E1 interface, CU-CP can configure the RESOURCE STATUS REQUEST and perform the clean-up of the stale PDU session by including “PDU Session Resource To Remove List” in a BEARER CONTEXT MODIFICATION REQUEST message. Similarly, DRBs corresponding to the stale PDU on the DU can be cleared by including “DRB to Be Released List” in a UE CONTEXT MODIFICATION REQUEST message towards DU, if required.
Example 5 for non-standalone (NSA) mode deployment: In case a DRB-level mismatch is detected on F1-C interface, CU-CP can configure the REPORT STATUS REQUEST and perform the clean-up of the stale DRB by including “DRB to Be Released List” in a UE CONTEXT MODIFICATION REQUEST message sent towards DU. Similarly, “DRB To Remove List” can be included in a BEARER CONTEXT MODIFICATION REQUEST message sent to CU-UP to release the corresponding DRB on CU-UP, if required.
Example 6 for standalone (SA) mode deployment: Similar to above example 4, to clean up a DRB-level mismatch, CU-CP can include “DRB To Remove List” in a “PDU Session Resource To Modify List” IE of a BEARER CONTEXT MODIFICATION REQUEST message sent towards CU-UP. The clean-up procedure for DU-level DRB mismatch will remain the same as in example 5.
The above-described technique for stale-resource detection and clean-up can be applied to 4G legacy RAN and other combinations of MR-DC deployments.
In addition, resource status reporting procedure can also be enhanced such that CU-UP and DU can also request for the user session status report to perform the audit.
In this section, details of RESOURCE STATUS REQUEST sent to gNB-DU will be discussed, including new elements proposed to be added according to the present disclosure. As discussed above, RESOURCE STATUS REQUEST message is sent by gNB-CU (e.g., gNB-CU-CP) to gNB-DU to initiate the requested measurement according to the parameters given in the message. The overall structure of RESOURCE STATUS REQUEST message is shown in Table 7 below. In the “Report Characteristics” IE, a seventh bit is added to enable report of connected UE periodic report (among other changes). Changes proposed to the RESOURCE STATUS REQUEST message sent by gNB-CU-CP are highlighted in bold and underlined below:
Seventh Bit =
Number of
Connected UEs
Eighth Bit =
Connected UE
Report Periodic
Ninth Bit =
Number of DRBs
>> Connection Time
O
INTEGER
Select connected
(
1 . . . 7200
UEs whose age
in secs
)
or
is greater than or
(
1 . . . 120
equal to
in mins
)
specified
connection time.
This is
configured only
when Connected
UE Report
Periodic
measurement
object is
configured
RESOURCE STATUS UPDATE message is sent by gNB-DU to gNB-CU (e.g., gNB-CU-CP) to report the results of the requested measurement. The overall structure of the RESOURCE STATUS UPDATE message sent by gNB-DU is shown in Table 8 below. Changes proposed to the RESOURCE STATUS UPDATE message are highlighted in bold and underlined below, which changes include adding, e.g., “Number of Connected UE” IE and “Number of DRB” IE, among others.
>> Number of
O
INTEGER
Number of
—
Connected UE
(
0 . . . 16384,
connected UEs
. . .
)
in a cell
>> Number of
O
INTEGER
Number of
—
DRB
(
0 . . . 65535,
DRBs in a
>>Connected UE
0 . . . 1
. . .
)
cell
YES
ignore
List
>>>Connect UE
1 . . .
—
Item
<maxnoofConnectedUE>
>>>> gNB
-
DU UE
M
9.3.1.5
—
F1AP ID
>>>> gNB
-
CU UE
M
9.3.1.4
—
F1AP ID
>>>> C
-
RNTI
O
9.3.1.32
>>>> CHOICE
O
YES
reject
System
>>>>> E
-
UTRAN
>>>>>> DRB List
0 . . . 1
YES
reject
>>>>>>> DRB
1 . . .
EACH
reject
Item
<maxnoofDRBs>
>>>>>>>> DRB ID
M
9.3.1.8
—
>>>>> NG
-
RAN
>>>>>> DRB List
0 . . . 1
YES
reject
>>>>>>> DRB
1 . . .
EACH
reject
Item
<maxnoofDRBs>
>>>>>>>> DRB ID
M
9.3.1.8
—
>>>>>>>>
S
-
O
9.3.1.38
NSSAI
>>>>>>>> Flows
1 . . .
—
Mapped to DRB
<maxnoofQoSFlows>
Item
>>>>>>>>> QoS
M
9.3.1.63
—
Flow Identifier
The above-listed range parameters are explained below:
In the previous section, the RESOURCE STATUS UPDATE is triggered by the DU in response to a preceding initiation of Resource Status Reporting procedure triggered by CU-CP (using RESOURCE STATUS REQUEST). The DU sends the status report periodically as indicated by the Reporting Periodicity in the RESOURCE STATUS REQUEST. In the event the CU-CP is locked or shut down, the UE context may be cleared by the CU-CP and DU. When the CU-CP is unlocked or rebooted, the DU can send the RESOURCE STATUS UPDATE unsolicited to the CU-CP after the F1 setup procedure is completed.
In this section, details of RESOURCE STATUS REQUEST sent by gNB-CU-CP to gNB-CU-UP will be discussed, including new elements proposed to be added according to the present disclosure. As discussed above, RESOURCE STATUS REQUEST message is sent by gNB-CU-CP to gNB-CU-UP to initiate the requested measurement according to the parameters given in the message. The overall structure of RESOURCE STATUS REQUEST message is shown in Table 9 below. In the “Report Characteristics” IE, a third bit is added to enable report Number of Bearer Contexts (among other changes). Changes proposed to the RESOURCE STATUS REQUEST message sent by gNB-CU-CP to gNB-CU-UP are highlighted in bold and underlined below:
RESOURCE STATUS UPDATE message is sent by gNB-CU-UP to gNB-CU-CP to report the results of the requested measurement. The overall structure of the RESOURCE STATUS UPDATE message sent by gNB-CU-UP is shown in Table 10 below. Changes proposed to the RESOURCE STATUS UPDATE message are highlighted in bold and underlined below, which changes include adding, e.g., “Number of Bearer Contexts” IE, among others.
Number of Bearer
O
INTEGER
YES
ignore
Contexts
(
1 . . . 4294967295,
Bearer Context List
0 . . . 1
. . .
)
YES
ignore
> Bearer Context
1 . . .
—
Item
<maxnoofBearerContexts>
>> gNB
-
CU
-
CP UE
M
9.3.1.5
—
E1AP ID
>> gNB
-
CU
-
CP UE
M
9.3.1.4
—
E1AP ID
>> CHOICE
O
YES
reject
System
>>> E
-
UTRAN
>>>> DRB ID
M
9.3.1.16
>>> NG
-
RAN
>>>> PDU Session
M
9.3.1.21
ID
>>>> S
-
NSSAI
M
9.3.1.9
—
—
>>>> DRB List
O
1 . . .
>>>>> DRB ID
M
<maxnoofDRBs>
9.3.1.16
>>>>> QoS Flow
1
—
—
List
>>>>>>QoS Flow
1 . . .
—
—
Item
<maxnoofQoSFlows>
>>>>>>>QoS Flow
M
9.3.1.24
—
—
Identifier
The above-listed range parameters are explained below:
It should be noted that CU-UP can also include plmn Id and slice Id in the Resource Status Update message sent towards CU-CP.
In the previous section, the RESOURCE STATUS UPDATE is triggered by the CU-UP in response to a preceding initiation of Resource Status Reporting procedure triggered by CU-CP (using RESOURCE STATUS REQUEST). The CU-UP sends the status report periodically as indicated by the Reporting Periodicity in the RESOURCE STATUS REQUEST. In the event the CU-CP is locked or shut down, the UE context may be cleared by the CU-CP and CU-UP. When the CU-CP is unlocked or rebooted, the CU-UP can send the RESOURCE STATUS UPDATE unsolicited to the CU-CP after the F1 setup procedure is completed.
Method 3 (node-level native autonomous clean-up): In another example embodiment of the method according to the present disclosure, the DU 903c sends the UE CONTEXT RELEASE REQUEST 1801 to the CU-CP 903a (as shown in
In the above-described procedure, there is no retry mechanism if the CU-CP does not initiate the UE Context Release Command in response to receiving the UE Context Release Request from the DU. The DU can start a timer upon sending the UE Context Release Request. If the UE Context Release is initiated by the CU-CP, i.e., the UE Context Release Command is sent, the DU stops the timer upon receiving the UE Context Release Command from the CU-CP. However, if the timer expires and the UE Context Release Command is not received at the DU, the DU initiates another UE Context Release Request and increments the retry count. The DU initiates the retry (i.e., sends the UE Context Release Request) for a configured (specified) number of times (counts). In the event the configured retry count is reached and the CU-CP fails to initiate the UE Context Release, the DU autonomously cleans up the UE context.
As shown in
In the above-described procedure, there is no retry mechanism if the CU-CP 903a does not initiate the Bearer Context Release procedure (by sending the Bearer Context Release Command 2002) in response to receiving the Bearer Context Release Request 2001 from the CU-UP 903b. In an example embodiment, the CU-UP 903b can start a timer upon sending the Bearer Context Release Request 2001. If the Bearer Context Release procedure is initiated by the CU-CP 903a, i.e., the Bearer Context Release Command 2002 is sent, the CU-UP 903b stops the timer upon receiving the Bearer Context Release Command 2002 from the CU-CP 903a. However, if the timer expires and the Bearer Context Release Command 2002 is not received, the CU-UP 903b initiates another Bearer Context Release Request 2001 and increments the retry count. The CU-UP 903b initiates the retry (i.e., sends the Bearer Context Release Request) for a configured (specified) number of times (counts). In the event the configured retry count is reached and the CU-CP 903a fails to initiate the Bearer Context Release procedure, the CU-UP 903b autonomously cleans up the bearer context.
While the present disclosure has been described with reference to one or more exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the present disclosure. For example, although the example methods have been described in the context of 5G cellular networks, the example methods are equally applicable for 4G, 6G and other similar wireless networks. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the disclosure without departing from the scope thereof. Therefore, it is intended that the present disclosure not be limited to the particular embodiment(s) disclosed as the best mode contemplated, but that the disclosure will include all embodiments falling within the scope of the appended claims.
For the sake of completeness, a list of abbreviations used in the present specification is provided below:
| Number | Date | Country | Kind |
|---|---|---|---|
| 202321078359 | Nov 2023 | IN | national |
