Optimization in data exchange over d2 interface

Abstract

A messaging structure is provided that uses in O-RAN (Open Radio Access Network) architecture using the D2 interface for exchanging user data associated with User Equipment (UE) and Physical Uplink Control Channel (PUCCH) information across O-RAN Distributed Units (O-DUs) that can be exchanged over GTP / IP / UDP or over IP / UDP / Ethernet without generating excessive processing in the receiver DU by avoiding multiple memory copy in the system, and optimization of consumption of received Uplink Control Information (UCI) for a Secondary Cell (SCell).

Description

0017040WGU / 4688OPTIMIZATION IN DATA EXHANGE OVER D2 INTERFACEBACKGROUND1. Field of the Disclosure

[0001] The present disclosure is related to a proposed messaging structure used in 0-RAN (Open Radio Access Network) architecture. More particularly, the present disclosure is related to using the D2 interface for exchanging user data and Physical Uplink Control Channel (PUCCH) information across 0-RAN Distributed Units (O-DUs).2. Description of Related Art

[0002] O-RAN (Open Radio Access Network) is an open and intelligent radio access network architecture that seeks to improve performance and efficiency of wireless networks while simultaneously reducing complexity and cost. An 0-RAN Distributed Unit (O-DU) is a component of O-RAN architecture.

[0003] User data and Physical Uplink Control Channel (PUCCH) information are time sensitive. D2 is a new interface defined between DUs to support inter DU Carrier Aggregation (CA).Currently, there is no structure defined for user data and PUCCH information to be exchanged over the D2 interface.

[0004] Typically, each DU forms the Transport Block (TB) for user data in different modules and PUCCH information in other modules. TB formation can be done per User Equipment (UE) while PUCCH information can be done per cell. As different modules handles / forms thesemessages hence it requires proper message architecture so that messages can be forwarded without excessive processing in a receiver DU to the intended module.

[0005] The size of the Protocol Data Unit (PDU) that can be sent over General Packet Radio Service Tunnelling Protocol (GTP) is a maximum of 1500 or 9000 bytes. Additionally, a size of 1 TB could be 130000 bytes. As such, segmentation / reassembly is required to handle TB size data. Without proper chaining of these messages, it can lead to multiple segmentation and reassembly between transmitter and received. This could also lead to a multiple memory copy in the system that will degrade system performance.

[0006] Additionally, D2-U is part of the interface between DUs supporting user data exchange between DUs. TB size may be such that multiple Radio Link Control (RLC) packets need to be assembled to form one TB. Because of this relatively large size, multiple D2-U packets must be transmitted for one TB. This in turn requires multiple levels of segmentation and reassembly in the transmitter and at the receiver. This process leads to latency issues in D2-U packets causing negative performance issues.

[0007] Accordingly, there is a need for communication structure that overcomes, alleviates, and / or mitigates one or more of the aforementioned and other deleterious effects of prior art O- RAN systems for exchanging data and PUCCH information across various DUs.SUMMARY

[0008] Accordingly, what is needed is a system and method that allows for the exchange of user data and Physical Uplink Control Channel (PUCCH) information across O-DUs that does not generate excessive processing for the system.

[0009] It is further desired to provide a system and method that facilitates exchanging user data and PUCCH information across O-DUs without generating excessive processing in the receiver DU.

[0010] It is still further desired to provide a system and method that facilitates exchanging user data and PUCCH information across O-DUs that avoids multiple memory copy in the system, which degrades system performance.

[0011] It is yet further desired to provide a system and method that utilizes the D2 interface to transmit user data and PUCCH information between DUs.

[0012] The D2 interface will be used for exchanging user data as well as PUCCH information across O-DUs. This interface will bring in the latency over data transfer and PUCCH handling. Data and PUCCH information are exchanged over the over General packet radio service Tunnelling Protocol / Internet Protocol / User Datagram Protocol (GTP / IP / UDP) interface or over Internet Protocol / User Datagram Protocol / Ethemet (IP / UDP / Ethernet). DownLink (DL) data to be transmitted to a secondary DU, will be provided from a primary DU. The primary DU will form the TB as per the size given by the secondary DU. The TB size can be larger than the D2-U packet size, hence multiple D2-U packets will be needed to carry the data to secondary DU. The system is optimized to avoid multiple memory copy for segmentation or reassembly of D2-U packets or RLC packets to form the complete TB that needs to be transmitted at the Secondary0017040WGU / 4688Cell (SCell). Optimized message structure is used so that processing time in the DU can be reduced.

[0013] A structure for message chaining is provided for data exchange. The maximum PDU size over the D2 interface that can be used is 130000 bytes. As the IP packet size is a maximum of 1500 or 9000 bytes (if jumbo frame is used), segmentation of a single TB data will be required. Chaining of this data is proposed so that memory copy can be avoided in the system. Accordingly, data chaining for data PDUs over the D2 interface can reduce the segmentation / reassembly for each TB.

[0014] Likewise, large data packets can be transmitted in multiple D2-U packets of smaller size (9000 or smaller for jumbo and 1500 or less for non-jumbo). One D2-U packet may contain multiple RLC PDUs. Each RLC PDU has a Medium Access Control (MAC) header prepend before transmission over SCell. A MAC header may be added with each RLC PDU at the primary DU. The Chain of pointers having a MAC header + RLC PDU can be given to Data Plane Development Kit (DPDK) Application Programming Interface (API). DPDK APIs, while forming the ethemet packets can do the memcpy() as per the D2-U packet size. This will avoid memcpyO in application protocol to form the D2U packet. At the receiver side, once D2-U packets are received, reassembly can be done without any delay. If any Medium Access Control Control Element (MAC CE) related to SCell must be added, the secondary DU can attach to the received TB and send it across.

[0015] Accordingly, the present disclosure captures an improvement in message structures to avoid high processing in the receiver. Based on initial information itself, the sending module canforward the message to a destination module and therefore the number of hops can be reduced within the DU.

[0016] Furthermore, message chaining for relatively large sized PDU will be employed for segmented data. This means that rather than having to make a memory copy in the application, the data can just be transferred to the receiving DU thereby avoiding increasing the system processing load. In particular, memory copy of RLC / MAC PDUs for forming a TB and then transmission over D2 interface can be avoided. RLC / MAC PDUs received from CU can instead be directly passed to DPDK send.

[0017] Additionally, consumption of received Uplink Control Information (UCI) for a SCell is also optimized. This is advantageous because it reduces the latency in marking the transmitted Radio Link Control / Medium Access Control Protocol Data Unit (RLC / MAC PDU) received in the transmitter.

[0018] In one configuration, data for multiple UEs and SCells can be combined in a single message. This will result in the loading on the D2 interface being reduced. This will also help lower processing requirements in the DUs supporting the D2 interface.

[0019] PUCCH optimization can be accomplished using the OTA Slot, current slot and the like. K2 selection can be done using this information. Also, if possible, the Primary Cell (PCell) can combine the PUCCH resource allocation for the same UE, if multiple cells are requesting or if some PUCCH information is scheduled such as periodic CSI or HARQ.

[0020] PUCCH handling in the primary DU can bring in optimization for PUCCH handling in inter DU CA.

[0021] For this application the following terms and definitions shall apply:

[0022] The term “data” as used herein means any indicia, signals, marks, symbols, domains, symbol sets, representations, and any other physical form or forms representing information, whether permanent or temporary, whether visible, audible, acoustic, electric, magnetic, electromagnetic or otherwise manifested. The term “data” as used to represent predetermined information in one physical form shall be deemed to encompass any and all representations of the same predetermined information in a different physical form or forms.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] As used herein, the phrases "at least one", "one or more", "or" and "and / or" are open- ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions "at least one of A, B and C", "at least one of A, B, or C" ,"one or more of A, B, and C", "one or more of A, B, or C" ,"A, B, and / or C" and "A, B, or C" means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.

[0027] As used herein, the term “D2 Interface” refers to the interface between the DUs for supporting inter DU CA or any other functionality across DUs.

[0028] As used herein, the term “D2-U” indicates D2 Interface - User Datagram Protocol (UDP).

[0029] As used herein, the term “SCell Status Update Request” is the message over D2 interface to update the SCell status as active / inactive in secondary DU.

[0030] As used herein, the term “SCell Status Update Response” is the message over D2 interface to bring the response from secondary DU to primary DU after reception of SCell status Update Request mentioned in above.

[0031] As used herein, the term “SCell Status Update Required” is the message over D2 interface from secondary DU to primary DU if SCell status must be modified. It could be due to RLF or loading, or any other scenario that happened at secondary DU over the SCell for a particular UE.

[0032] As used herein, the term “SCell Status Update Confirm” is the message over D2 interface to update the confirm the secondary DU about handling of SCell Status Update Required as mentioned in above.

[0033] As used herein, the term “DL Buffer Indication” is the message sent from primary DU to secondary DU for informing about the available DL buffer that can be transmitted over SCell in secondary DU.

[0034] As used herein, the term “DL Data Request” is the message sent from secondary DU to primary DU for requesting the DL data for different LCTD for transmission.

[0035] As used herein, the term “DL Data Indication” is the message sent from primary DU to secondary DU for providing the DL data to be transmitted over SCell. Data could be MAC SDU or MAC PDU. It can also bring the Physical Uplink Control Channel (PUCCH) resources.

[0036] As used herein, the term “PUCCH Resource Request” is the message used by secondary DU to request PUCCH resources from primary DU.

[0037] As used herein, the term “PUCCH Resource Indication” is the message sent by primary DU to secondary DU for informing the allocated PUCCH resources.

[0038] As used herein, the term “UCI Indication” is the message sent by primary DU to secondary DU for sharing the received PUCCH information (CQI, RI etc.)

[0039] As used herein, the term “memcpyQ” is a function used in the C programming language to copy blocks of memory from one place to another. Its prototype is defined in the string.

[0040] In one configuration, a method of communicating between Distributed Units (DUs) in an Open Access Radio Network (0-RAN) is provided comprising the steps of: connecting a plurality of DUs via a D2 interface and wherein a transport mechanism for the D2 interface0017040WGU / 4688 includes: Stream Control Transmission Protocol (SCTP), open-source Remote Procedure Call (gRPC), or GPRS Tunnelling Protocol (GTP).

[0041] 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.DESCRIPTION OF THE DRAWINGS

[0042] FIG. l is a data flow diagram between a primary DU and a secondary DU for exchanging the user plane message over D2 interface.

[0043] FIG. 2 is a table showing the content of Status update APIs between primary and secondary DUs to activation or deactivation of the SCells for a UE according to FIG. 1.

[0044] FIG. 3 is a table showing buffer indication message content from the primary DU to the secondary DU according to FIG. 2.

[0045] FIG. 4 is a table showing the procedure for getting PUCCH resources allocated from the primary DU.

[0046] FIG. 5 is a table showing a message structure for a data request sent by secondary DU to primary DU.

[0047] FIG. 6 is a table showing the structure of the primary DU to send DL data to the secondary DU.

[0048] FIG. 7 is a table showing structure for conveying received PUCCH information to a secondary DU.

[0049] FIG. 8 is a table showing the PUCCH resources allocated by the primary DU.

[0050] FIG. 9 is a table illustrating the D2-U packet to be exchanged for data between primary and secondary DUs.

[0051] FIG. 10 is a block diagram illustrating the chaining of buffer in a transmitter.DETAILED DESCRIPTION

[0052] As discussed in U.S. 2024 / 0297767, a message sequence between a primary DU and a secondary DU may be as follows:@startuml autonumberBox "primary DU"Participant "primary-DU UE Entity" as pUEParticipant "primary-DU cell Entity" as pcellParticipant "primary-DU transmitted" as pTParticipant " secondary -DU transmitted" as pREnd boxBox "secondary DU"Participant " secondary -DU UE Entity" as sUEParticipant " secondary -DU cell Entity" as scellParticipant "primary-DU transmitted" as sTParticipant " secondary -DU transmitted" as sREnd box pcell->scell: SCell Status Update Request (Activate) scell->pcell: SCell Status Update Response(Success) scell->pcell: SCell Status Update Required(RLF) pcell->scell: SCell Status Update Confirm (Success) pcell->scell: SCell Status Update Request( Activate) scell->pcell: SCell Status Update Response( Success) pcell->scell: DL Buffer Indication sUE->pUE: DL Data Request scell->pcell: PUCCH Resource RequestpUE->sUE: DL Data Indication pcell->scell: PUCCH Resource Indication pcell->scell:UCI Indication@enduml

[0053] FIG. 1 further illustrates data flow between a primary DU and a secondary DU.

[0054] Step 1. The SCell Status Update Request (Activate) is transmitted from the primary -DU cell entity to the secondary -DU cell entity.

[0055] Step 2. The SCell Status Update Response (Success) is transmitted from the secondary- DU cell entity to the primary -DU cell entity.

[0056] Step 3. The SCell Status Update Required (RLF) is transmitted from the secondary -DU cell entity to the primary-DU cell entity.

[0057] Step 4. The SCell Status Update Confirm (Success) is transmitted from the primary-DU cell entity to the secondary -DU cell entity.

[0058] Step 5. The SCell Status Update Request (Activate) is transmitted from the primary-DU cell entity to the secondary -DU cell entity.

[0059] Step 6. The SCell Status Update Response (Success) is transmitted from the secondary- DU cell entity to the primary-DU cell entity.

[0060] Step 7. The DL Buffer Indication is transmitted from the primary-DU cell entity to the secondary -DU cell entity.

[0061] Step 8. The DL Data Request is transmitted from the secondary-DU UE entity to the primary-DU UE entity.

[0062] Step 9. The PUCCH Resource Request is transmitted from the secondary-DU cell entity to the primary-DU cell entity.

[0063] Step 10. The DL Data Indication is transmitted from the primary-DU UE entity to the secondary-DU UE entity.

[0064] Step 11. The PUCCH Resource Indication is transmitted from the primary-DU cell entity to the secondary-DU cell entity.

[0065] Step 12. The UCI Indication is transmitted from the primary-DU cell entity to the secondary-DU cell entity.

[0066] Referring to FIG. 2, this figure illustrates the Status update APIs between primary and secondary DUs to activation or deactivation of the SCells for a UE. If Radio Link Failure (REF) is detected by the secondary DU, Status update required / confirm will be used. These procedures are mainly needed by the scheduler in the DU and are therefore looped with SCells. The receiving entity can just check the SCell ID and post it to the scheduler without needing to check the rest of the message.

[0067] FIG. 3 illustrates a buffer indication from the primary DU to the secondary DU. This information is also needed by the scheduler for UE scheduling and is therefore looped with cell IDs. Using this information, the scheduler in the secondary DU will run its scheduling algorithm to schedule UE in a Transmission Time Interval (TTI). Based on the scheduled slot, it can request data from the primary DU.

[0068] FIG. 4 shows the procedure for getting PUCCH resources allocated from the primary DU. Once UE is scheduled for transmitting the data over a slot, the secondary DU will request0017040WGU / 4688 the PUCCH request from the secondary DU. Additionally, in the case where retransmission is necessary, this message can be used.

[0069] FIG. 5 shows the message structure for a data request from the primary DU being captured. Once UE is scheduled for transmitting the data over a slot, the secondary DU will send this message to the primary DU. As this must be handled by the UE level entity to send the data, looping with UE list is utilized. The Hybrid Automatic Repeat Request Process Identifier (HARQ PID) sent can be used by the primary DU to handle the HARQ feedback once received from UE.

[0070] FIG. 6 shows the structure of the primary DU to send data to the secondary DU. Optionally PUCCH resources can be included in this. A number of PDUs mention the number of RLC / MAC PDUs in this TB, as there could be multiple RLC / MAC PDUs in a single TB. The Sequence Number (SN) could be a RLC / MAC SN or any other SN decided by the primary DU for chaining of the data at secondary DU..

[0071] FIG. 7 shows the structure for conveying received PUCCH information to the secondary DU. It should be noted that the received HARQ feedback as well as the Channel Quality Indicator (CQI) report can be transmitted in this message.

[0072] FIG. 8 shows the PUCCH resources allocated by the primary DU. As this information must be handled at each cell level, looping is accomplished from the Cell ID.

[0073] There are various messages and structures that can be transmitted between the primary DU and the secondary DU to exchange data over the D2 interface. Messages used for this purpose are illustrated in FIG. 2 and can include:0017040WGU / 4688• SCell Status Update Request• SCell Status Update Response• SCell Status Update Required• SCell Status Update Confirm• DL Buffer Indication• PUCCH Resource Request• DL Data Request• DL Data Indication• UCI Indication• PUCCH Resource Indication

[0074] These messages will be exchanged over the GPRS Tunnelling Protocol (GTP) or any other protocol that is fast enough to meet the transport requirements of the D2 interface.

[0075] Once the SCell is activated, the SCell Status Update Request / Response procedure can be used to inform the status to SCells (Steps 1 and 2, FIG. 1). Once the SCell is active, data exchange can be accomplished by the procedures previously outlined above. If the Secondary DU observes any issue with the SCell and decides to deactivate the same, it will inform the Primary DU by exchanging procedures including SCell Status Update Required and SCell Status Update Confirm (Steps 3 and 4, FIG. 1). The action / cause is to exchange SCell status messages so that the other side is aware of the activity. As shown in FIG. 2, multiple SCells status can be changed between a pair of O-DUs by a single primitive. This reduces message exchange over the D2 interface and therefore the loading on each DU is reduced.

[0076] The PCell will be responsible for data sharing and PUCCH resource allocation for the SCells. The PCell informs the SCell about the data that must be transmitted over the SCell using a primitive Downlink (DL) Buffer Indication (Step 6, FIG. 1). It contains data for each Logical Channel Identifier (LCId) for each UE for each SCell. As this information is needed at the celllevel in the secondary DU, the structure of FIG. 3 is maintained. The received module in the secondary DU, on reception of this message will inform the scheduler. The Scheduler will add the UEs / LCIds for considering the same for scheduling. As there is no processing done in the receiver module for this, loading in the receiver module will be minimal with this handling. Also, the buffer status for multiple UEs in multiple SCells between pair of O-DUs can be shared in a single primitive.

[0077] Once the UE is scheduled by the scheduler in the secondary DU for DL data for each LCId for each UE, the secondary DU will send a request to the Primary DU using message DL DATA Request (Step 8, FIG. 1). Data will be provided by the Radio Link Controller / Medium Access Control (RLC / MAC) module in primary DU for a UE. As such, FIG. 5 has the UE listed first. The receiver in the Primary DU will post the data request to each UE specific MAC to get the data based on the Cell Radio Network Temporary Identifier (CRNTI) received. As there is no processing in this instance, loading on the receiver is advantageously low.

[0078] Each UE specific module will process the message and according to the length listed, will fill multiple RLC / MAC PDUs to be sent in DL DATA INDICATION for transmission (Step 10, FIG. 1). HARQ PID will be transmitted to the scheduler, so that the scheduler can use it while receiving the HARQ feedback. As DL DATA INDICATION will contain multiple RLC / MAC PDUs (FIG. 6) to exhaust the size mentioned, several PDUs will indicate the same. The SN can be set as RLC / any other SN, which can be used by the receiver in the secondary DU to chain the messages that are part of one DL DATA INDICATION. Instead of forming the complete TB, RLC / MAC PDUs are added separately the size of which could be less than 1500 bytes or 9000 bytes in case of Jumbo frame enabled. This leads to no segmentation required at the User Datagram Protocol (UDP) layer. At the transmitter, when data is given to the Data Plane0017040WGU / 4688Development Kit (DPDK) transmitter, it can include the pointers to the RLC / MAC PDUs. At the receiving side, the DPDK receiver will receive the primitive. Based on the message type and the CRNTI, it will post the message to the UE level MAC entity. The MAC will collate all the RLC / MAC PDUs using the sequence number mentioned. It will form the MAC header for each RLC PDU in a separate structure and both these data pointers and MAC header structure can be passed to the LI for transmission. This will advantageously avoid memory copy at the transmitter and receiver. Optionally, the primary DU can also include PUCCH resources in the DL Data indication message.

[0079] The PUCCH Resource request / Indication is used between the primary DU and the secondary DU for obtaining the PUCCH resource allocation for transmitting the data (Steps 9 and 11, FIG. 1). This procedure can also be used for receiving the aperiodic Channel State Information CSI reports. The structures disclosed in FIGS. 4 and 8 are used for this purpose.

[0080] Once the Secondary DU transmits / retransmits the data, it can request PUCCH resources using PUCCH Resource request to the primary DU (Step 9, FIG. 1). It will use the Over-The- Air (OTA) slot where the DL data is scheduled for transmission. The System Frame Number (SFN) and slot indicate the current SFN / slot running in the secondary DU. The HARQ PID will be stored by the primary DU, and it can use the same for handling the HARQ feedback once received from the UE. Based on the OTA slot, the primary DU will decide the K value for PUCCH reception. It will also calculate the total Downlink Assignment Indicator (tDAI) and counter Downlink Assignment Indicator (cDAI) and the same is informed back to the secondary DU. As PUCCH information is needed by the Cell level entity, the structure in FIGS. 4 and 8 starts with SCell IDs. The primary DU, optionally, can choose the K2 value so that it can be combined with CQI / HARQ feedback for other cells for the same UE. This can be done forPUCCH resource optimization. The primary DU can also exchange the PUCCH resource config for a particular UE with the secondary DU in the SCell addition message. The primary DU can allocate the PUCCH resources at the same time / frequency domain for periodic CSI reporting.

[0081] DL Data indication or PUCCH indication can bring in information for multiple cells (Steps 10 and 11, FTG. 1). For supporting this, the primary DU can run a timer. It could be based on the TTI duration. Data received for all the UEs during this time can be packed in a single message and sent across.

[0082] FIG. 9 shows the structure that carries the DL data indication from a primary DU to a secondary DU. This is the format for D2-U packets. The total size of this PDU could be, for example, 8500 bytes. If Jumbo frame is supported, max Ethernet packet size could be 9000 bytes. The D2-U packet is size is defined based on that. The remaining bytes are left for the header, etc. Each field in FIG. 9 is defined below.

[0083] D2-U PDU Length indicates the length of total D2-U PDU.

[0084] Curr SFN / Slot indicates the Single Frequency Network (SFN) and slot where data is sent.

[0085] Over The Air (OTA) slot indicates where data will be transmitted to the User Equipment (UE).

[0086] A single D2-U packet may contain data from multiple UEs, therefore UE count indicates the same.

[0087] Cell Radio Network Temporary Identifier (CRNTI) is used to identify each UE for which data is encoded.0017040WGU / 4688

[0088] UE PDU Length indicates the length of data for a single UE.

[0089] As a single UE can be connected to multiple SCells, SCell count and SCell ID is used to identify each one of them.

[0090] Total PDU Length indicates the total TB length for the SCell.

[0091] Data length indicates the size of the following data field.

[0092] FIG. 10 indicates the chaining of buffer in transmitter. MAC 1, MAC 2 etc. are MAC PDUs indicating the RLC PDU + MAC header that must be assembled to form a single TB. Each MAC PDU has a pointer that points to the next MAC PDU that must be added after the previous one. Once application forms the chain of PDUs that must be sent in a single TB, it sends the same to DPDK API or any other API, which will form D2-U packets by copying the MAC PDUs into D2-U PDU and sends it to the secondary DU.

[0093] In FIG. 10, multiple MAC PDUs (MAC Header + RLC PDU) can be assembled into a single data field that must be transmitted over the D2 interface in D2-U PDU. To avoid memcpyO, the application forms the chain of PDUs containing RLC PDU and MAC header as per the TB size provided by secondary DU. This chain of buffers will be given to DPDK APIs to assemble up to the size of D2-U packet while copying over ethernet. This will avoid assembling of multiple RLC PDUs and MAC header to form a TB and then segmentation at UDP to match up to D2-U packet size at the transmitter side.

[0094] There are several benefits the new system offers compared to existing systems including:• Message structures for data and PUCCH are defined that can be proposed in the standards.0017040WGU / 4688• Memory copy in L2 can be avoided while exchanging data between the primary and the secondary DUs.• Multiple segmentation and reassembly can be avoided while exchanging data between the primary and the secondary DUs.• Latency in PUCCH handling can be reduced.

[0095] 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 made and equivalents can be substituted for elements thereof without departing from the scope of the present disclosure. 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.

Claims

0017040WGU / 4688CLAIMSWhat is claimed is:

1. A method of communicating between Distributed Units (DUs) in an Open Access Radio Network (O-RAN) comprising the steps of: connecting a plurality of DUs to each other via a D2 interface; wherein a transport mechanism for the D2 interface is selected from the group consisting of: Stream Control Transmission Protocol (SCTP), open-source Remote Procedure Call (gRPC), General Packet Radio Service Tunnelling Protocol (GTP), Internet Protocol (IP), User Datagram Protocol (UDP), Ethernet and combinations thereof.

2. The method of claim 1, wherein the plurality of DUs comprise a first DU and a second DU, the first DU connected to the second DU via the D2 interface, the method further comprising the steps of: the first DU transmitting Downlink (DL) data using message DL Data Indication to the second DU; wherein data from multiple User Equipment (UE) scheduled on multiple Secondary Cells (SCells) is transmitted in a single primitive.

3. The method of claim 2, further comprising the steps of the first DU appending a Medium Access Control (MAC) header and sending a MAC Protocol Data Unit (PDU) as per a requested Transport Block (TB) size to the second DU.

4. The method of claim 3, further comprising the steps of the first DU forming a single TB from a chain of buffers including the MAC header and MAC PDUs; and transmitting the single TB via the D2 interface.

5. The method of claim 3, wherein the MAC PDUs comprise a Radio Link Control (RLC) header and a RLC Service Data Unit (SDU), where the RLC SDU includes a data pointer received from a Central Unit (CU) avoiding memory copy at an application level.

6. The method of claim 2, further comprising the step of: the first DU reports a status of a SCell to the second DU via SCell Status Update Request / Response / Required / confirm messages, and a status change includes activation or deactivation of a SCell.

7. The method of claim 6, further comprising the step of: sharing statuses of multiple User Equipment (UE) in a single API between the first and second DUs.

8. The method of claim 7, further comprising the step of: the second DU directly posting the single API based on SCell ID to a cell level entity for processing.

9. The method of claim 2, wherein the first DU comprises a secondary DU and the secondDU comprises a primary DU, the method further comprising the steps of: the first DU reporting a SCell Status Update Required (RLF) or Channel Quality Indicator (CQI) miss or other failure to an SCell to the second DU.

10. The method of claim 2, wherein the first DU comprises a secondary DU and the second DU comprises a primary DU, the method further comprising the steps of: the second DU shares an available DL Buffer using a DL Buffer Indication message adapted to transmit cumulative information for multiple UEs, multiple cells and multiple Logical Channel Identifier (LCIds) to the first DU; wherein Uplink Buffer Status Report (UL BSR) information is provided to the first DU.

11. The method of claim 2, wherein the first DU comprises a secondary DU and the second DU comprises a primary DU, the method further comprising the steps of: the first DU transmits a DL Data Request message to the second DU; and the first DU requests data for multiple UE scheduled on multiple SCells in a single message.

12. The method of claim 2, wherein the first DU comprises a secondary DU and the second DU comprises a primary DU, the method further comprising the steps of: the first DU requests Physical Uplink Control Channel (PUCCH) resources from the second DU using a PUCCH Resource Request message including PUCCH resources for multiple cells in a single API; the second DU uses a current slot / System Frame Number (SFN) and an Over The Air0017040WGU / 4688(OTA) slot to determine a K2 value for reception of faster Hybrid Automatic RepeatRequest (HARQ) feedback; and the first DU indicates the HARQ Process Identifier (PID) to the second DU.

13. The method of claim 2, wherein the first DU comprises a secondary DU and the second DU comprises a primary DU, the method further comprising the steps of: the second DU transmits DL data using a DL Data Indication message to the first DU; wherein, based on a User Equipment Identifier (UE ID) in the DL Data Indication message the first DU posts received data to respective Medium Access Control (MAC) entities without parsing the DL Data Indication message; the second DU encodes PUCCH resources and additional data transmitted from a UE level entity to a scheduler; and the second DU uses Radio Link Control Sequence Number (RLC SN) as Sequence Number (SN), which is used by a Medium Access Control (MAC) entity for chaining data in a sequence.

14. The method of claim 2, further comprising the step of: the first DU copying data while forming ethemet packets up to a packet size of 8500 bytes where a Maximum Transmission Unit (MTU) size is set to 9000 bytes to avoid segmentation.

15. The method of claim 2, further comprising the step of: the second DU, upon receiving the DL Data Indication, forms a Transport Block (TB)according to a total Protocol Data Unit (PDU) length provided in a D2-U packet; transmitting the TB via a SCell.

Images