Procedure optimization by supporting interface between dus for 6g and beyond technologies

Abstract

A method for optimizing radio access network (RAN) operation is provided where the RAN has at least a first distributed unit (DU), a second DU, and a centralized unit (CU), the method including: communicatively connecting the first DU to the CU via an Fl interface; and communicatively connecting the second DU to the first DU via a first DU-to-DU interface. The method can include exchanging, between the first and second DUs via the first DU-to-DU interface, at least one of downlink and uplink data at radio link control level. The method can include exchanging, between the first and second DUs via the first DU-to-DU interface, information regarding at least one of loading of the first DU and loading of the second DU to optimize a handover procedure between the first and second DUs.

Description

Procedure Optimization By Supporting Interface between DUs For 6G And Beyond TechnologiesBACKGROUND1. Field of the Disclosure

[0001] The disclosure is directed to the field of Radio Access Network (RAN), and relates more particularly to an interface between distributed units (DUs) in the RAN.2. Description of Related Art

[0002] In 5G technology, there is no interface supported between DUs, so information has to be routed via a centralized unit (CU). For the purposes of present disclosure, DU is intended to encompass gNB-DUs, O-RAN DUs (O-DUs) and RAN nodes supporting Open Systems Interconnection model (OSI model) Layer 2 (L2) functionality. Many procedures, e.g., intra-CU, inter-DU handover, mobility, cell change procedure, and load balancing, cannot be optimized due to absence of interface between DUs. Fl interface between CU and DU has a large latency (e.g., 1.5 ms to 10 ms). Xn interface, which is supported at CU level, also exhibits a similar level of latency.

[0003] In the case of an intra-CU, inter-DU handover according to the current standards, once a measurement report is received from a UE, the CU obtains the current configuration from a source DU by triggering a UE Context Modification procedure (a Fl procedure). Then, the CU triggers a Handover request towards a target DU by sending a UE Context Setup Request message (Fl procedure). In response, the target DU configures the UE and sends a Cell Group Configuration message to the CU. Subsequently, the CU sends a radio resource control (RRC) Reconfiguration message to the UE by triggering a Fl message towards the source DU. Once CU triggers the RRC reconfiguration towards the UE, data transmission is stopped in downlink (DL) direction, and data transmission is resumed once the UE has successfully latched onto the target DU with the PDCP sequence number that was sent by the source DU. Data loss over the midhaul (between CU and DU) during the handover procedure needs to be taken care of by PDCPre-transmission. In addition, as messages are exchanged over the Fl interface, latency of the handover procedure becomes high.

[0004] In the conventional implementation, load balancing is supported between a CU and a DU. There are Fl procedures defined for sharing the loading condition between a CU and a DU, i.e., based on the loading condition, the CU can opt for a handover or a UE release. However, these Fl procedures are optional in 3 GPP standards, and hence not supported by many of the equipments (e.g., DUs). If the target DU does not support these Fl procedures, then the CU will not be aware of the load condition of the target DU, and the CU can trigger a handover of the UE to the target DU which is loaded, thereby resulting in sub-optimal performance of the network.

[0005] In the context of industrial deployments, there are 2 conventional solutions available; i) either each DU is connected to the CU, or ii) CU / DUs are supporting an integrated access and backhaul (IAB) stack. Most of the CU / DUs do not support the IAB stack. If each DU has connection with CU, this leads to two drawbacks: i) higher transport cost between DUs; and ii) multiple intra-CU, inter-DU handovers if UEs are moving. FIG. 1 is a block diagram illustrating an example conventional connection among a Core network, CU and multiple DUs for industrial area deployment without integrated access and backhaul (IAB). FIG. 1 shows CU 1001 connected to Core network 1002 and multiple DUs 1003a - 1003f via midhaul (MH) connections 101a - lOlf, respectively.

[0006] In Lower Layer Triggered Mobility (LTM) procedures, a CU configures (based on measurement reports) LTM cells to a UE by sending an RRC reconfiguration message. These cells are supported in different DUs connected to the same CU. For configuration of LTM cells to a UE and a source DU, the CU collects the information from DUs hosting the cells by sending UE Context Setup Request messages. These LTM cells are configured to a source DU by using a UE Context Modification procedure. Once LTM cells are added in the UE and the source DU, handover to a target LTM cell can be triggered by the source DU by using a MAC CE towards the UE. Cells can be synchronized before triggering the handover, thereby reducing the connection break duration.

[0007] In the conventional implementation of scheduling algorithm optimization, each DUapplies its own algorithm for PRB allocation, without being aware of neighboring DUs’ PRB allocation scheme. Given this lack of awareness, if the deployed DUs are from different vendors, there is a possibility that the DUs allocate the same PRBs for different UEs at the same time, even when the system is not highly loaded. This scenario can result in interference.

[0008] In addition to the above-noted issues, there is no cell change procedure defined in the current technical specifications. Therefore, in case of inter-DU movement of a UE, a handover procedure always needs to be triggered.

[0009] Accordingly, there is a need for a system and a method for optimizing various DU-involving procedures to improve, e.g., latency, mobility, load balancing, scheduler optimization and interference management.SUMMARY

[0010] Accordingly, it is desired to provide a system and method for optimizing various DU- involving procedures to improve, e g., latency, mobility, load balancing, scheduler optimization and interference management.

[0011] According to an example embodiment, an interface between DUs is provided to optimize various DU-involving procedures, which interface between DUs can support much lower latency (500 ps or lower), so exchanging information over an inter-DU interface can provide significant latency improvement in multiple procedures.

[0012] According to an example embodiment, the transport mechanism for the interface between the DUs can be based on Stream Control Transmission Protocol (SCTP), Remote Procedure Call (gRPC), General Packet Radio Service Tunnelling Protocol (GTP), and the like.

[0013] According to an example embodiment, intra-CU, inter-DU handover can be optimized by deploying an interface between DUs. In contrast to the conventional technique in which a handover decision is implemented by CU based on message exchanges with a target DU, message exchanges for the handover can be done between a source DU and the target DU in accordance with the example embodiment, thereby reducing the handover procedure latency.

[0014] According to an example embodiment, data exchange after a handover completion can be done at the DU level (assuming there is no change in encryption keys and algorithm), which facilitates reduction in data retransmission.

[0015] The interface across DUs can also help in interference cancellation by allocating orthogonal PRBs in case where PRB loading is not high on the DUs. Information on PRB allocation by any DU can be shared over the inter-DU interface, so PRB allocations across various DUs can be coordinated and each DU can avoid allocation of the PRBs already allocated by nearby DUs.

[0016] According to an example embodiment, for network optimization in UE mobility scenarios, neighboring cell information can be stored at a DU which is interfacing with a second DU, whereby each DU can be aware of loading condition of its peer DU. This embodiment enables a source DU to guide the CU to avoid a UE handover to a loaded cell.

[0017] According to an example embodiment, for a cell-less architecture, a DU-to-DU interface provides significant improvement in realizing faster network mobility for different types of devices, e.g., unmanned aerial vehicle (UAV), urban air mobility (UAM), and the like.

[0018] According to an example embodiment, a PCell change procedure can be implemented using a DU-to-DU interface for optimizing the network usage. If DUs are connected with each other and used for carrier aggregation (CA) across the DUs, a loaded primary DU can trigger a cell change to a secondary DU.

[0019] According to an example embodiment, if a PCell DU experiences loading which results in slow scheduling of UEs, data for some of the UEs (along with PUCCH resources for the UEs) can be transferred to an Scell DU using the DU-to-DU interface, thereby reducing the loading condition on the PCell DU.

[0020] According to an example embodiment, a DU-to-DU interface is utilized to support various techniques, e.g., carrier aggregation (CA), CoMP, and dynamic spectrum sharing (DSS) in 6G technology. The DU-to-DU interface provides a significant improvement in achieving higher throughput with lower latency by enabling efficient coordination across DUs.

[0021] According to an example embodiment, loading condition of each neighboring DU can be exchanged over a DU-to-DU interface, and a handover decision made by a source DU and / or CU can take into consideration the available loading information, i.e., a handover to a highly loaded DU cell can be avoided to improve the network performance.

[0022] According to an example embodiment, in the context of industrial deployment of the RAN network, the need to connect each DU directly to the CU is obviated. The DU-to-DU interface enables data exchange between the CU and a DU that is not directly connected to the CU, thereby reducing data transport cost.

[0023] According to an example embodiment, a DU-to-DU interface is utilized to optimize the LTM procedure.BRIEF DESCRIPTION OF THE DRAWINGS

[0024] FIG. l is a block diagram illustrating an example conventional connections among a Core network, CU and multiple DUs for industrial area deployment.

[0025] FIG. 2 is a signal flow diagram showing an example embodiment of the disclosure in which a DU-to-DU interface is utilized to optimize an intra-CU, inter-DU handover procedure.

[0026] FIG. 3 is a block diagram illustrating an example embodiment of the disclosure in which connections are provided among a Core network, CU and multiple DUs for industrial area deployment, including DU-to-DU connections.

[0027] FIG. 4 is a signal flow diagram showing an example embodiment of the disclosure in which a cell change procedure is implemented using a DU-to-DU interface.

[0028] FIG. 5 is a signal flow diagram showing an example embodiment of the disclosure in which network load balancing is optimized by using a DU-to-DU interface.DETAILED DESCRIPTION

[0029] According to an example embodiment of the disclosure as illustrated in FIG. 2, an intra-CU, inter-DU handover procedure is optimized by implementing a DU-to-DU interface. FIG. 2 is a signal flow diagram showing example interactions among CU 1001, source DU 2003a, a target DU 2003b, and a UE 2004. After the CU 1001 receives a measurement report (as shown by the process arrow 201), the CU 1001 sends a UE Context Modification Request (as shown by the process arrow 202) to the source DU 2003a. Subsequently, the source DU 2003a will send a UE Handover Request (as shown by the process arrow 203) to the target DU 2003b over the DU-to- DU interface to set up the UE context in the target DU 2003b. In response, the target DU 2003b will send (as shown by the process arrow 204) a UE Handover Response with a cell group configuration to the source DU 2003a over the DU-to-DU interface. The UE Handover Request will be treated similarly to a UE Context Setup Request at the target DU 2003b (i.e., admission control and resource allocation will be performed). The source DU 203a then sends (as shown by the process arrow 205) a UE Context Modification Response to the CU 1001 with information regarding a target cell (e.g., the cell group configuration and PDCP sequence number). In response, the CU 1001 forms a Handover Command and sends it in an RRC Reconfiguration Request (as shown by the process arrow 206) to the source DU 2003 a. In turn, the source DU 2003a forwards (as shown by the process arrow 207) the RRC Reconfiguration Request to the UE 2004.

[0030] The remaining steps shown in FIG. 2 include: i) Handover (HO) Random Access Channel (RACH) procedure (as shown by the process arrow 208) initiated by the UE 2004 towards the target DU 2003b; ii) UE Handover Complete message (which is optional) sent (as shown by the process arrow 209) by the target DU 2003b to the source DU 2003a; iii) UE Handover Complete Acknowledgement message (which is optional) sent (as shown by the process arrow 210) by the source DU 2003a to the target DU 2003b; iv) RRC Reconfiguration Complete message sent (as shown by the process arrow 211) by the UE 2004 to the target DU 2003b; and v) RRC Reconfiguration Complete message forwarded (as shown by the process arrow 212) by the target DU 2003b to the CU 1001.

[0031] FIG. 3 is a block diagram illustrating an example embodiment of the disclosure in which connections are provided among the Core network 1002, CU 1001 and multiple DUs 1003a - 1003f for industrial area deployment, including DU-to-DU connections (interfaces) 301a - 301 d. By using the DU-to-DU interfaces 301a - 30 Id, the CU 1001 need not be directly connected toevery DU. In the example configuration shown in FIG. 3, only DUs 1003a and 1003f are directly connected to the CU 1001 (via midhaul (MH) connections 101a and 10 If, respectively), and the remaining DUs 1003b, 1003c, 1003d, and 1003e are connected to neighboring DUs via the respective DU-to-DU interfaces 301a, 301b, 301c and 301d (i.e., all the DUs are connected to the CU 1001 by “daisy chaining”). Because DUs 1003b, 1003c, 1003d, and 1003e are located nearer to each other in comparison to the CU 1001, transport link requirement between the DUs will be lower.

[0032] In the downlink (DL) direction, the CU 1001 can receive data from the Core network 1002 and send the data to any of the connected DUs 1003a - 1003f. For the DUs 1003b, 1003c, 1003d and 1003e which are connected to the CU 1001 via at least one other DU (i.e., at least one DU-to-DU interface), the number of hops will increase, but any latency impact can be optimized by efficient connections between the DUs. The daisy chaining od the DUs illustrated in FIG. 3 can be achieved using, e.g., Data Plane Development Kit (DPDK), and logical interface for this purpose is not needed. If UE devices are moving in this deployment environment, the network mobility of the UE devices can be optimized by implementing the intra-CU, inter-DU handover procedure described above.

[0033] Under the current technical specifications, there is no cell change procedure that is defined. According to an example embodiment illustrated in connection with FIG. 4, a cell change procedure is implemented using a DU-to-DU interface, thereby achieving faster network mobility for UEs. Once neighboring cell configuration is completed (or detected) by CU 1001 (as shown by 401), the CU 1001 sends (as shown by 402) a UE Context Modification Request containing the neighboring cell configuration to the source DU 2003a. The source DU 2003a can store the neighboring cell data, and the source DU 2003a sends (as shown by 403) a UE Context Modification Response to the CU 1001. Subsequently, the source DU 2003a receives (as shown by 404) lower layer (e.g., LI) measurements for a cell hosted by the source DU 2001a and a neighboring cell hosted by the target DU 2003b. Based on the LI measurements, if Layer2 in the source DU 2003a detects the neighboring cell hosted in the target DU 2003b is better, the source DU 2003a can trigger a new MAC control element (CE) called Cell Change. As shown by the process arrow 405, the source DU 2003a sends a Cell Change Request to the target DU 2003b, and the target DU 2003b responds by sending (as shown by the process arrow 406) a Cell0016908WGU / 4688Change Response (which contains a dedicated random access channel (RACH) configuration) to the source DU 2003 a.

[0034] Continuing with the signal flow diagram of FIG. 4, the source DU 2003a sends (as shown by 407) a Cell Change Notification message to the CU 1001. The DU 2003a then sends (as shown by 408) a MAC_CE_CELL_CHANGE_REQUEST message to the UE 2004. In response, the UE 2004 latches onto the target cell (of the target DU 2003b) and completes the RACH procedure (as shown by 409). As shown at 410, the source DU 2003 a continues to send UL data to the CU 1001 and DL data to the UE 2004. Next, as shown by the process arrow 411, the target DU 2003b sends a Cell Change Complete message to the source DU 2003a. In turn, the source DU 2003a sends (as shown by the process arrow 412) a Cell Change Success message to the CU 1001. In addition, the source DU 2003a transfers (as shown by the process arrow 413) the DL data to the target DU 2003b. Next, as shown by the process arrow 414, the CU 1001 sends a UE Context Release message to the source DU 2003a.

[0035] In the example embodiment illustrated in the signal flow diagram of FIG. 4, data radio bearer (DRB) and / or signaling radio bearer (SRB) configuration in the cell change procedure shall remain the same across the DUs. As the source DU 2003a and the target DU 2003b are assumed to be connected to the same CU 1001 in the example illustrated in FIG. 4, DRB and / or SRB information is already available with the CU 1001 . GTP tunnel information can be shared by the target DU 2003b to the source DU 2003a, which GTP tunnel information will be sent to the CU 1001 in the Cell Change Notification message. In case the DUs are already involved in inter-DU carrier aggregation (CA) procedure, the PCell DU can use the same procedure for moving PCell from one DU to another, thereby facilitating control of the loading in the PCell DU. This implementation will need modification in the 3GPP technical specifications.

[0036] According to an example embodiment, load balancing among DUs can be optimized by implementing the DU-to-DU interface, e.g., based on the loading condition of the target DU, the source DU can reject a proposed handover triggered by the CU. Alternatively, a cell change procedure can be triggered based on the loading conditions of the DUs. If the DUs are connected for CA for a UE, based on the loading condition of the PCell DU, PUCCH can be completely moved to the SCell DU. In another example use case involving the DU-to-DU interface for loadbalancing, when CA is supported across the DUs, if cells from other DUs are used for CA, it can be determined based on the loading conditions whether data can be completely moved to the SCell DU.

[0037] FIG. 5 is a signal flow diagram showing an example embodiment of the disclosure in which network load balancing is optimized by using a DU-to-DU interface. Initially, as shown by 501, the neighboring cell configuration is completed (or detected) by CU 1001. Next, the source DU 2003a sends (as shown by the process arrow 502) its loading information to the target DU 2003b, and the target DU sends (as shown by the process arrow 503) its loading information to the source DU 2003 a. The CU 1001 then sends (as shown by the process arrow 504) a UE Context Modification Request containing the neighboring cell configuration to the source DU 2003a. The source DU 2003a determines, based on the loading information received from the target DU 2003b, that the target DU 2003b is loaded (as shown by 505), and the source DU 2003a sends (as shown by 506) a UE Context Modification Failure message to the CU 1001, thereby rejecting the handover to the target DU 2003b.

[0038] According to an example embodiment, scheduling algorithm can be optimized by implementing the DU-to-DU interface. DUs can exchange information regarding the existing active UEs and the associated 5QI information, based on which exchanged information the PCell DU can choose to offload user data to the Scell DU for transfer in CA condition. User data offloading can be controlled by a timer to implement a single instance pumping for transmission in multiple TTI, and the Scell DU can continue scheduling the UE as per the Scell DU’s own algorithm.

[0039] According to an example embodiment, scheduling algorithm can be defined in the Scell DU, such that if high amount of user data is received for a CA user with high 5QI, then for the next few TTIs, the CA user will be prioritized for scheduling. Based on the requirements of other existing users on the Scell DU, the Scell DU can decide statically the TTIs in which the CA user will be scheduled. PUCCH allocation for Scell resources can be allocated statically in these scenarios to reduce the transport latency.

[0040] 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 can be madeand equivalents can 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 and 6G cellular networks, the example methods are equally applicable for other wireless networks. In addition, many modifications can 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.

[0041] For the sake of completeness of disclosure, the following lists of acronyms and definitions are provided:ACRONYMS:3 GPP: Third generation partnership project4G: Forth Generation Cellular Wireless System5G: Fifth Generation Cellular Wireless SystemCU: Central UnitDU: Distributed UnitDL: DownlinkUL: Uplink eNB: Enhance Node B gNB: Next Generation Node BGPRS: General Packet Radio ServiceGTP: GPRS Tunneling Protocol gNB-DU: next generation Node B Distributed UnitRAN : Radio Acces s N etworkL2: Layer 2LTM: Lower Layer Triggered MobilityCA: Carrier AggregationSUL: Supplementary UplinkSDL: Supplementary DownlinkPCell: Primary CellSCell: Secondary CellO-DU: Open RAN Distributed UnitCoMP: Coordinated Multi-PointPRE: Physical Resource BlockUE: User EquipmentRLC: Radio Link ControlSCTP: Stream Control Transmission ProtocolMAC : Medium Access ControlMAC CE: MAC Control Element gRPC: Remote Procedure CallTTI: Transmission Time IntervalQoS : Quality of Service5QI: 5G QoS IdentifierPUCCH: Physical Uplink Control ChannelPDCP: Packet Data Convergence Protocol

Claims

What is claimed is:

1. A method for optimizing radio access network (RAN) operation, wherein the RAN has at least a first distributed unit (DU), a second DU, and a centralized unit (CU), the method comprising: communicatively connecting the first DU to the CU via an F 1 interface; and communicatively connecting the second DU to the first DU via a first DU-to-DU interface.

2. The method according to claim 1, further comprising: exchanging, between the first and second DUs via the first DU-to-DU interface, a UE mobility information to optimize a handover procedure between the first and second DUs.

3. The method according to claim 1, further comprising: exchanging, between the first and second DUs via the first DU-to-DU interface, at least one of downlink and uplink data at radio link control level.

4. The method according to claim 1, further comprising: exchanging, between the second DU and the CU via the first DU and the first DU-to-DU interface, at least one of downlink and uplink data at radio link control level.

5. The method according to claim 1, further comprising: exchanging, between the first and second DUs via the first DU-to-DU interface, information regarding at least one of loading of the first DU and loading of the second DU to optimize a handover procedure between the first and second DUs.

6. The method according to claim 1, further comprising: receiving, by the first DU, Layer 1 measurements for a cell hosted by the first DU and Layer 1 measurements for a neighboring cell hosted by the second DU; and triggering, by the first DU, a cell change procedure based on the Layer 1 measurements for the cell hosted by the first DU and the Layer 1 measurements for a neighboring cell hosted bythe second DU.

7. The method according to claim 1, further comprising at least one of: i) exchanging, between the first and second DUs via the first DU-to-DU interface, information regarding at least one of physical resource block (PRB) allocations by the first DU and PRB allocations the second DU; ii) exchanging, between the first and second DUs via the first DU-to-DU interface, data and signaling messages for carrier aggregation involving the first and second DUs; iii) exchanging, between the first and second DUs via the first DU-to-DU interface, data and signaling messages for Coordinated Multi-Point transmission involving the first and second DUs; and iv) in the case the first DU is serving as a primary cell DU and is loaded, and the second DU is serving as a secondary cell DU, offloading by the first DU to the second DU via the first DU-to-DU interface, at least one of downlink and uplink data.

8. A radio access network (RAN) system, comprising: a first distributed unit (DU); a second DU; a centralized unit (CU) communicatively connected to the first DU via an Fl interface; and a first DU-to-DU interface communicatively connecting the second DU to the first DU.

9. The system according to claim 8, wherein: the first DU-to-DU interface is configured to enable exchange of a UE mobility information between the first and second DUs to optimize a handover procedure between the first and second DUs.

10. The system according to claim 8, wherein: the first DU-to-DU interface is configured to enable exchange of at least one of downlink and uplink data at radio link control level between the first and second DUs.11 . The system according to claim 8, wherein: the first DU-to-DU interface is configured to enable exchange of at least one of downlink and uplink data at radio link control level between the second DU and the CU via the first DU and the first DU-to-DU interface.

12. The system according to claim 8, wherein: the first DU-to-DU interface is configured to enable exchange, between the first and second DUs, of information regarding at least one of loading of the first DU and loading of the second DU to optimize a handover procedure between the first and second DUs.

13. The system according to claim 8, wherein: the first DU is configured to: i) receive Layer 1 measurements for a cell hosted by the first DU and Layer 1 measurements for a neighboring cell hosted by the second DU; and ii) trigger a cell change procedure based on the Layer 1 measurements for the cell hosted by the first DU and the Layer 1 measurements for a neighboring cell hosted by the second DU.

14. The system according to claim 8, wherein at least one of: i) the first DU-to-DU interface is configured to enable exchange, between the first and second DUs, of information regarding at least one of physical resource block (PRB) allocations by the first DU and PRB allocations the second DU; ii) the first DU-to-DU interface is configured to enable exchange, between the first and second DUs, of data and signaling messages for carrier aggregation involving the first and second DUs; iii) the first DU-to-DU interface is configured to enable exchange, between the first and second DUs, of data and signaling messages for Coordinated Multi-Point transmission involving the first and second DUs; and iv) in the case the first DU is serving as a primary cell DU and is loaded, and the second DU is serving as a secondary cell DU, the first DU-to-DU interface is configured to enable offloading by the first DU to the second DU at least one of downlink and uplink data.

Images