Automatic ecpri RX packet position prediction
By tagging eCPRI packets with unique indexes for automatic positioning in the receiver buffer, the solution addresses the latency and resource issues in eCPRI packet handling, enhancing network performance and reducing processing delays.
Patent Information
- Application Number
- PCT/CN2024/076580
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-02-07
- Publication Date
- 2025-08-14
AI Technical Summary
The complexity of searching and reordering eCPRI packets in the RU due to out-of-order reception and transmission delays significantly impacts network capacity and latency, requiring additional hardware resources and increasing processing time.
Implementing a mechanism for automatic eCPRI RX packet position prediction by tagging packets with unique indexes, allowing the receiver to store them in a buffer based on these indexes, eliminating the need for searching and reordering operations.
Reduces processing latency and resource consumption by predicting packet positions, enabling faster data handling and supporting more UEs, layers, or cells with reduced hardware requirements.
Smart Images

Figure CN2024076580_14082025_PF_FP_ABST
Abstract
Description
AUTOMATIC ECPRI RX PACKET POSITION PREDICTIONTECHNICAL FIELD
[0001] Various example embodiments described herein generally relate to communication technologies, and more particularly, to devices, methods, apparatuses and computer readable mediums supporting automatic position prediction of enhanced Common Public Radio Interface (eCPRI) received (RX) packets.BACKGROUND
[0002] Certain abbreviations that may be found in the description and / or in the figures are herewith defined as follows: CP Control Plane CU Centralized Unit DU Distributed Unit eCPRI enhanced Common Public Radio Interface OFDM Orthogonal Frequency Division Multiplexing ORAN Open Radio Access Network PRB Physical Resource Block RE Resource Element RFOE Radio Frequency over Ethernet hardware accelerator RU Radio Unit UE User Equipment UP User Plane
[0003] Open Radio Access Network (Open-RAN, or ORAN) is an evolution of the Next Generation Radio Access Network (NG-RAN) architecture with a goal to enable mobile network operators to use equipment from multiple vendors and still ensure interoperability. In the Open-RAN environment, the NG-RAN is disaggregated into three main building blocks: a centralized unit (CU) , a distributed unit (DU) and a radio unit (RU) . An enhanced Common Public Radio Interface (eCPRI) protocol has been defined for the fronthaul communication between the RU and the DU.SUMMARY
[0004] A brief summary of exemplary embodiments is provided below to provide basic understanding of some aspects of various embodiments. It should be noted that this summary is not intended to identify key features of essential elements or define scopes of the embodiments, and its sole purpose is to introduce some concepts in a simplified form as a preamble for a more detailed description provided below.
[0005] In a first aspect, an example embodiment of a receiver device is provided. The receiver device may comprise at least one processor and at least one memory. The at least one memory stores instructions that, when executed by the at least one processor, cause the receiver device at least to receive enhanced common public radio interface (eCPRI) packets tagged with packet indexes from a transmitter device, determine addresses in a buffer based on the packet indexes, and store the eCPRI packets into blocks of the buffer corresponding to the determined addresses.
[0006] In a second aspect, an example embodiment of a transmitter device is provided. The transmitter device may comprise at least one processor and at least one memory. The at least one memory stores instructions that, when executed by the at least one processor, cause the transmitter device at least to split a data stream into multiple fragments, calculate packet indexes for the multiple fragments, the packet indexes indicating an order of the multiple fragments in the data stream, transmit a message indicating a range of the packet indexes to a receiver device, package the multiple fragments and the corresponding packet indexes into multiple enhanced common public radio interface (eCPRI) packets, respectively, and transmit the eCPRI packets to the receiver device.
[0007] Example embodiments of methods, apparatuses and computer readable mediums are also provided. Such example embodiments generally correspond to the above example embodiments of the receiver device and the transmitter device, and a repetitive description thereof is omitted here for convenience.
[0008] Other features and advantages of the example embodiments of the present disclosure will also be apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of example embodiments of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Some example embodiments will now be described, by way of non-limiting examples, with reference to the accompanying drawings.
[0010] Fig. 1 is a schematic diagram illustrating a mobile network architecture in which example embodiments of the present disclosure can be implemented.
[0011] Fig. 2 is a message flow chart illustrating a process according to an example embodiment of the present disclosure.
[0012] Fig. 3A is a schematic diagram illustrating data structure of an enhanced Common Public Radio Interface (eCPRI) packet.
[0013] Fig. 3B is a schematic diagram illustrating an eCPRI sequence identifier field in an eCPRI transport header of the eCPRI packet.
[0014] Fig. 4A is a schematic diagram illustrating buffer blocks mapping to eCPRI packet indexes.
[0015] Fig. 4B is a schematic diagram illustrating buffer blocks mapping to eCPRI packet indexes.
[0016] Fig. 5 is a message flow chart illustrating a process according to an example embodiment of the present disclosure.
[0017] Fig. 6 is a schematic block diagram illustrating an apparatus according to an example embodiment of the present disclosure.
[0018] Fig. 7 is a schematic block diagram illustrating an apparatus according to an example embodiment of the present disclosure.
[0019] Fig. 8 is a schematic block diagram illustrating devices in a communication system according to an example embodiment of the present disclosure.
[0020] Throughout the drawings, same or similar reference numbers indicate same or similar elements. A repetitive description on the same elements would be omitted.DETAILED DESCRIPTION
[0021] Herein below, some example embodiments are described in detail with reference to the accompanying drawings. The following description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well known circuits, techniques and components are shown in block diagram form to avoid obscuring the described concepts and features.
[0022] Fig. 1 illustrates a schematic diagram of a mobile network architecture in which example embodiments of the present disclosure can be implemented. As shown in Fig. 1, a mobile, or cellular / wireless network 100 may comprise two domains: Core Network (CN) 110 and Radio Access Network (RAN) 120. The CN 110 may include numerous network functions (NFs) (not shown) to provide various functionalities. For instance, it can provide access controls to ensure that users are authenticated for the services they are using, route telephone calls over the public switched telephone network, enable operators to charge for calls and data use, and connect users to a data network e.g. the internet. It can also control the network by making handovers happen as a user moves from a cell coverage provided by a RAN base station to another cell coverage provided by the same or a different base station. In an example embodiment, the CN 110 may be deployed on cloud, e.g. a public cloud, a private cloud or a hybrid cloud.
[0023] The RAN 120 may include a plurality of base stations connected to the CN 110 and to each other. Each base station may provide one or more cell coverages to deliver network services to user equipment (UEs) (not shown) camping in the cell. The base station may have a split architecture. For instance, in the Open-RAN environment, the base station may be split into a centralized unit (CU) 122, a distributed unit (DU) 124 and a radio unit (RU) 126, as shown in Fig. 1. One CU 122 may be connected to one or more DUs 124, and one DU 124 may be connected to one or more RUs 126. Fig. 1 shows one CU 122, two DUs 124a, 124b, and four RUs 126a, 126b, 126c, 126d as an example. The link between the CN 110 and the CU 122 is referred to as backhaul, the link between the CU 122 and the DU 124 is referred to as midhaul, and the link between the DU 124 and the RU 126 is referred to as fronthaul.
[0024] The RU 126, also known as remote radio head (RRH) or remote radio unit (RRU) , may function to transmit, receive, amplify and digitize radio frequency signals, and it may be located near or integrated into an antenna module that is positioned on a tower or on top of a building. The DU 124 and the CU 122 are computation parts of the base station, sending the digitalized radio signal into the network. The DU 124 may be physically located at the cell site, e.g. near the RU 126, whereas the CU 122 may be located closer to the CN 110.
[0025] In 5G New Radio (NR) , the enhanced Common Public Radio Interface (eCPRI) is adopted for the fronthaul communication between the RU 126 and the DU 124. Unlike Common Public Radio Interface (CPRI) used in 4G / Long Term Evolution (LTE) that utilizes a time division multiplexing (TDM) serial interface, eCPRI is a packet technique utilizing an Ethernet / Internet Protocol (IP) . The eCPRI packet is encapsulated in an Ethernet frame data field and used to transmit both User Plane (U-Plane, or UP) and Control Plane (C-Plane, or CP) messages, which allows the fronthaul traffic to switch between physical nodes. Compared with CPRI, eCPRI can provide lower latency, increased bandwidth efficiency, scalability and flexibility.
[0026] According to the ethernet frame format defined in the IEEE 802.3 standard, the eCPRI packet has a typical maximum transfer unit (MTU) size of 1500 bytes. Due to the limitation of eCPRI MTU size, in some cases U-Plane transmission is split into multiple fragments and transmitted by multiple eCPRI packets. For instance, in case the lower layer split (LLS) point for the fronthaul is between the media access control (MAC) layer and the physical (PHY) layer (known as split Option 6) or between the scrambling function and the modulation function within the PHY layer (known as split Option 7-2e or 7-3) , the DU 124 splits encoded bit streams per UE into fragments and transmits the fragments to the RU 126. On the RU side, the received sequence of fragments may be disordered randomly. The RU 126 would search and reorder the fragments in order to reassemble the bit streams for subsequent processing. The complexity of searching and reordering algorithms will significantly impact the network capacity and cost.
[0027] For instance, Radio Frequency over Ethernet hardware accelerator (RFOE) may be implemented in the DU 124 and the RU 126 to transmit and receive ethernet frames / eCPRI packets. For downlink transmissions, the RFOE transmitter (TX) module deployed in the DU 124 splits the encoded bit streams per UE into multiple fragments and encapsulates each fragment in an eCPRI packet / ethernet frame transmitted to the RU 126. The RFOE TX module can transmit the eCPRI packets / ethernet frames in multiple channels. On the receiving side, the RFOE receiver (RX) module deployed in the RU 126 parses the ethernet frames, filters out ethernet headers, and outputs the eCPRI packets into a buffer according to the packet receiving order. The buffer is usually a cyclic buffer. When an eCPRI packet is stored in the last block of the cyclic buffer, next eCPRI packet would be stored to the first block. Hence the RX module cannot predict a storage position for an eCPRI packet before the eCPRI packet is received.
[0028] Besides this issue, the eCPRI packets are received and stored out of order due to for example transmission delay and the fact that multiple eCPRI packets are transmitted in parallel via multiple channels. Consequently, when the eCPRI packets arrives at the RU 126, the RU 126 needs to search and reorder the packets in order to reassemble the bit streams before processing them. For an example scenario of NR 100 MHz bandwidth 4 layer transmission, there are ceil (273 PRB*12 RE*4 Layer / 1500 MTU size) *13 symbol = 117 eCPRI packets per 500 μs (i.e., 1 slot) to be searched. The searching task should select and reorder the eCPRI packets belonging to a slot, and handle all exceptions like packet loss and packet transmission delay, which consume much time and significantly impacts the real time performance of the RU 126. The next processing step cannot start before the searching task is finished. The RU 126 may allocate extra dedicated hardware resources e.g. Digital Signal Processor (DSP) , ARM processor and shared memory (SMEM) resources for the searching task, but it still causes one extra symbol delay. The drawback would be more obvious in case the RU 126 serves more cells / UEs or operates a larger bandwidth.
[0029] In addition, the buffer for storing the received eCPRI packets is usually allocated on the shared memory (SMEM) (also known as on-chip memory) because the SMEM has low latency. If the buffer is on a device memory (also known as on-board memory) e.g. a double data rate (DDR) memory, frequent accessing to the buffer would impact the system performance dramatically because the DDR memory has relatively high latency.
[0030] Example embodiments of the present disclosure provide a mechanism for automatic eCPRI RX packet position prediction. The eCPRI packets may be tagged with a unique index which is calculated by the transmitter. When the packets arrive at the receiver side, the receiver may store the packets into specific buffer blocks according to the unique index. In an example embodiment, the receiving buffer may be a cyclic buffer, and the storage mechanism may be realized by constructing the mapping relation between the buffer blocks and the unique index. For example, the unique index may be used to index the blocks in the receiving buffer. When a received eCPRI packet has a unique index that does not exceed the size of the receiving buffer (i.e., the number of blocks included in the receiving buffer) , the packet may be stored in a buffer block corresponding to the unique index. When a received eCPRI packet has a unique index that exceeds the size of the receiving buffer, the receiver may calculate a remainder given by the unique index modulo the size of the receiving buffer first and then store the packet into a buffer block indexed by the remainder. The unique index is a finite number, when it reaches to the maximal number it will be reset to the initial value. It would be appreciated that other mapping mechanisms are also applicable in the example embodiments. Since the eCPRI packets are stored in a predetermined order in the buffer, the searching and reordering operations may be eliminated, and the DSP, ARM and SMEM resources used for the searching and reordering operations may be saved. It can reduce one slot processing delay of the eCPRI packets and improve capability of the receiver. For instance, with the saved resources, the receiver can support more UEs, layers, cells or additional processing. In addition, the receiver does not need to access the buffer frequently and fragmentarily for searching and reordering the packets, cache miss penalty relating to the packets may be avoided. The receiving buffer may be deployed in a DDR memory that has lower cost than the SMEM, because the receiver does not need to access it frequently and thus the DDR access delay would be acceptable. In an example embodiment, the transmitter may calculate the packet indexes and transmit the calculated packet indexes to the receiver before the eCPRI packets are actually transmitted to the receiver. The receiver can predict the buffer block addresses for storing the eCPRI packets and configure next processing of the eCPRI packets with the buffer block addresses before the eCPRI packets are actually received. It can futher reduce the processing latency of the eCPRI packets.
[0031] Fig. 2 is a message flow chart illustrating a process 200 according to an example embodiment of the present disclosure. The process 200 may be performed at a receiver (RX) 202 which receives eCPRI packets and a transmitter (TX) 204 which transmits eCPRI packets. In an example embodiment, the receiver 202 may be implemented as a radio unit (RU) , and the transmitter 204 may be implemented as a distributed unit (DU) . The DU 204 can split downlink (DL) bit streams into eCPRI packets and transmit the DL eCPRI packets over ethernet frames to the RU 202. In another example embodiment, the receiver 202 may be implemented as the DU, and the transmitter 204 may be implemented as the RU. The RU 204 can split uplink (UL) bit streams into eCPRI packets and transmit the UL eCPRI packets over ethernet frames to the DU 202.
[0032] Referring to Fig. 2, at 210, the transmitter 204 may split data / bit streams per UE into multiple fragments. For instance, the transmitter 204 may receive from a higher layer U-Plane messages to be transmitted to the receiver 202, and the U-Plane messages, when including overhead, may exceed maximum transfer unit (MTU) requirements set by the network. Then the transmitter 204 may split the U-Plane messages into pieces such that the fragments with overheads fit to the MTU requirements. In an example, considering the standard IEEE 802.3 Ethernet frame payload size of 1500 bytes and the transport overhead of 8 bytes, the split fragments may have a maximum size of 1492 bytes. In another example, the fragments may have a larger size for e.g. Jumbo frames.
[0033] As discussed above, the split fragments will be carried by eCPRI packets and transmitted to the receiver 202 via ethernet frames. At 212, the transmitter 204 may calculate a unique index, also referred to as packet index hereinafter, for each fragment / eCPRI packet. The packet index may indicate the order of the fragments in the data / bit stream, and the transmitter 204 may increment / accumulate the packet index for all UEs. The packet index may have a predetermined length e.g. 8 bits or 16 bits. When the packet index reaches the maximum value, it wraps and restarts from the initial value. In an example, the transmitter 204 may calculate the packet index before splitting the data streams into fragments. For instance, the transmitter 204 may calculate the packet index by dividing the MTU size into the data length. In another example, the transmitter 204 may calculate the packet index in parallel with or after splitting the data streams into fragments. For instance, the transmitter 204 may calculate the packet index by counting the number of the split fragments.
[0034] In an example embodiment, the transmitter 204 may optionally send an indication of the range of the calculated packet indexes to the receiver 202 at 214. The indicated packet index range may include a packet index start value and length per UE. Optionally, the indication may further contain frame, subframe, slot and symbol information of each packet implicitly or explicitly. The transmitter 204 may transmit the indication via a C-Plane message to the receiver 202.
[0035] In response to the indication received at 214, the receiver 202 may predict at 216 a range of buffer addresses to be used for storing the eCPRI packets, based on the received packet index range. The receiver 202 may map the packet indexes to the block addresses in the buffer according to a mapping relationship between the packet indexes and the buffer block address, which will be discussed in detail below. Hence the receiver 202 can determine the buffer blocks to be used for storing the eCPRI packets before actually receiving the eCPRI packets. In an example embodiment, the receiver 202 may further make preparation for subsequent processing of the eCPRI packets, though it has not yet received them. For instance, the receiver 202 may configure direct memory access (DMA) of the predicted buffer block addresses and configure next processing operations with the predicted buffer block addresses. Then after a predetermined time period, the receiver 202 may read the eCPRI packets from the predicted buffer block addresses and perform the configured processing operations. It can reduce processing delay of the eCPRI packets.
[0036] At 218, the transmitter 204 may package the split fragments and the corresponding packet indexes into eCPRI packets. Fig. 3A shows a data structure of the eCPRI packet defined in the ORAN technical specification. As shown in Fig. 3A, the eCPRI packet may contain a transport header, an application header and a payload section. The transport header may include information of eCPRI protocol version, message type, payload size, message identifier, etc. The application header may include time domain information for the eCPRI packet, e.g. frame, subframe, slot and symbol identifiers, and UE information relating to the eCPRI packet, e.g. Radio Network Temporary Identifier (RNTI) . In an example embodiment, if the transmitter 204 has transmitted the time domain information and the UE information of the eCPRI packet to the receiver 202 at 214, the application header may be omitted. The transmitter 204 may encapsulate the packet index in the transport header or the application header, and place the fragment in the payload section.
[0037] In an example embodiment, the transmitter 204 may reuse an eCPRI sequence identifier field ecpriSeqid in the eCPRI transport header to carry the packet index. Fig. 3B shows the ecpriSeqid field defined in the ORAN technical specification. The ecpriSeqid field may include 16 bits (2 bytes / octets) . The first octet is the Sequence ID (SeqID) , and the second octet is the Subsequence ID consisting of 7 bits and a single bit field, called E-bit. In an example embodiment, if the packet index has a length less than or equal to 8 bits, the Sequence ID field may be used to indicate the packet index. If the packet index has a length larger than 8 bits, both the two octets of the ecpriSeqid field may be used to indicate the packet index. The transmitter 204 may guarantee that the packet index length is less than or equal to 16 bits. In another example embodiment, the packet index may have a length larger than 16 bits and it may be carried by another field or a new field defined in the eCPRI transport header or application header.
[0038] Referring back to Fig. 2, at 220, the transmitter 204 may transmit the eCPRI packets via ethernet frames to the receiver 202. Each ethernet frame may include an ethernet header and a payload including one eCPRI packet. The transmitter 204 may transmit the eCPRI packets in an order different from the packet indexes. For instance, the transmitter 204 may simultaneously transmit multiple packets via multiple channels to the receiver 202. As mentioned above, the receiver 202 may receive the eCPRI packets / ethernet frames out of order.
[0039] When the receiver 202 receives the eCPRI packets at 220, it may determine addresses in a receiving buffer based on the packet indexes at 222, and store the eCPRI packets into blocks of the receiving buffer corresponding to the determined addresses at 224, so that the eCPRI packets are stored in an order identical to the order of the fragments in the data stream. A mapping relationship between the packet indexes and the buffer block addresses may be pre-defined / pre-configured at the receiver 202. Fig. 4A shows an example mapping relationship between the packet indexes and the buffer block addresses. In the example shown, the receiving buffer has 256 blocks with an address from 0 to 255, and the packet index is an 8-bit sequence ID (SeqID) with a value from 0 to 255. The packet indexes may be one-to-one mapped to the buffer blocks. For example, the eCPRI packet indexed with SeqID 0 is stored into the buffer block 0, the eCPRI packet indexed with SeqID 1 is stored into the buffer block 1, and so on. If the receiver 202 does not receive one or more eCPRI packets, the corresponding buffer block (s) may be reserved. In the example shown in Fig. 4A, the buffer blocks 2 and 254 are reserved for the lost packets indexed with SeqID 2 and SeqID 254, respectively.
[0040] Fig. 4B shows another example mapping relationship between the packet indexes and the buffer block addresses. In the example, the receiving buffer has 1024 blocks with an address from 0 to 1023, and the packet index is a 16-bit sequence ID (SeqID) with a value from 0 to 65535. The packet indexes may be mapped to the buffer blocks as follows: Buffer block address = mod (SeqID, buffer size) (formula 1)
[0041] where mod () is the modulo function which returns a remainder of dividing SeqID by the buffer size, and the buffer size is the number of blocks included in the buffer. In the example, the eCPRI packets indexed with SeqID 0-1023 are stored into the buffer blocks 0-1023 respectively, the eCPRI packets indexed with SeqID 1024-2047 are stored into the buffer blocks 0-1023 respectively, and so on. If the receiver 202 does not receive an eCPRI packet, the corresponding buffer block will be reserved. In the example shown in Fig. 4B, the buffer block 2 is reserved for the lost packet indexed with SeqID 2, the buffer block 3 is reserved for the lost packet indexed with SeqID 1027, and the buffer block 1022 is reserved for the lost packets indexed with SeqID 1022 and SeqID 2046.
[0042] In an example embodiment, the receiving buffer may have a configurable size. For example, the receiver 202 may configure the buffer size (i.e. the number of blocks in the buffer) for receiving the eCPRI packets when the receiver 202 is powered on. In another example, the transmitter 204 may send a C-Plane message containing buffer configuration to the receiver 202 to configure the buffer size. In either approach, the buffer should be configured with a sufficient size to ensure that an eCPRI packet stored in the buffer would not be overwritten by a new packet before it is read out for subsequent processing. In an example embodiment, the receiving buffer may be configured with a size 2n where n is an integer.
[0043] In an example embodiment, the receiver 202 may maintain a new data indicator (NDI) for each buffer block in order to identify missing packets for trouble shooting. The NDI may include e.g. 2 bits with a value 00, 01, 10 or 11. When a packet is stored into the buffer block, the receiver 202 may increment the NDI from the initial value 00 to 01; when a new packet is stored into the same buffer block, the NDI may be incremented from 01 to 10, and so on. Then the receiver 202 can determine whether a new packet is received and written into a buffer block by comparing the current NDI value with the previous NDI value. If the NDI value does not change, the receiver 202 can determine that the packet mapped to the buffer block is lost.
[0044] With continuous reference to Fig. 2, the receiver 202 may read the eCPRI packets from the buffer blocks at 226, and reassemble the data stream from the eCPRI packets at 228 for subsequent processing. Since the eCPRI packets are stored in the buffer in the order of the packet indexes, the receiver 202 may sequentially read the eCPRI packets from the buffer blocks corresponding to the packet indexes, extract fragments encapsulated in the packets, and concatenate the fragments to reassemble the data stream. When reading the packets from the buffer, the receiver 202 can determine whether a packet is lost in a buffer block based on the NDI associated with the buffer block as discussed above, and take proper actions if a packet is lost. For instance, the receiver 202 may inform a higher layer that a certain packet is lost to initiate re-transmission of the lost packet. When the receiver 202 successfully reassembles the data stream from the eCPRI packets, it may perform subsequent processing on the data stream, e.g. modulation, layer mapping and pre-coding.
[0045] In the process 200, though the eCPRI packets may be received out of order at the receiver 202, they are stored in the buffer in the order of the packet indexes. Then the receiver 202 can sequentially read the packets from the buffer and reassemble the data stream from the packets, without performing packet searching and reordering operations. It can reduce DSP, ARM and SMEM resources otherwise used for the searching and reordering operations and simplify software programs executed at the receiver 202. The receiver 202 can use the saved resources to support more UEs, layers, cells or additional processing and to improve capability and performance. Since the packet searching and reordering operations are omitted, one slot processing delay of the eCPRI packets is eliminated, and the receiver 202 can process the received eCPRI packets in a faster way.
[0046] In an example embodiment, the receiver 202 may allocate the receiving buffer in a DDR memory which has higher latency but lower cost than a SMEM memory. Since the packet searching and reordering operations are omitted in the process 200, the receiver 202 does not need to access the buffer frequently and fragmentarily, cache miss penalty does not exist, and the DDR access delay would be acceptable.
[0047] In the process 200, the transmitter 204 can specify destination position of a packet by assigning a unique index to the packet. The transmitter 204 can inform the receiver 202 of the packet index range per UE by a C-Plane message before it actually transmits the packets. Hence the receiver 202 can predict position of the packets in the buffer and prepare for subsequent processing of the packets, without waiting until the packets are successfully received. It can further reduce the processing latency of the eCPRI packets.
[0048] Fig. 5 is a message flow chart illustrating a process 300 according to an example embodiment of the present disclosure. The process 300 may be performed at the receiver 202 and the transmitter 204.
[0049] Referring to Fig. 5, the receiver 202 may send a capability report indicating whether the receiver 202 supports eCPRI packet position prediction to the transmitter 204 at 310. If the receiver 202 supports the eCPRI packet position prediction, the capability report may further indicate the supported packet index range and buffer size of the receiver 202. In another example embodiment, if the capability report indicates the receiver 202 supports the eCPRI packet position prediction, the transmitter may configure the supported packet index range and buffer size to the receiver 202.
[0050] At 312, the receiver 202 may set a configuration flag for the buffer that is used to store the received eCPRI packets. The configuration flag may include one bit indicating whether the buffer is configured to support the packet position prediction mode or the legacy packet receiving mode. If the buffer is configured to the legacy packet receiving mode, the receiver 202 can store the eCPRI packets in the buffer in the receiving order. If the buffer is configured to support the packet position prediction, the receiving 202 can, when receiving an eCPRI packet, determine a buffer address based on the packet index and store the eCPRI packet in the determined buffer address, as discussed above with respect to the process 200. In an example embodiment, if the receiver 202 has multiple buffers for storing the eCPRI packets, the receiver 202 may set the configuration flag per buffer.
[0051] Then the transmitter 204 and the receiver 202 may perform the eCPRI packet transmitting and receiving based on the capability of the receiver 202 at 314. If the capability report indicates the receiver 202 supports the eCPRI packet position prediction, the transmitter 204 and the receiver 202 can perform the process 200 discussed above at 314 to transmit and receive the eCPRI packets. If the receiver 202 does not support the eCPRI packet position prediction, the transmitter 204 and the receiver 202 can transmit and receive the eCPRI packets in the legacy mode. Therefore, the transmitter 204 and the receiver 202 are compatible with the ORAN eCPRI protocol.
[0052] Fig. 6 is a block diagram illustrating an apparatus 400 in accordance with an example embodiment of the present disclosure. The apparatus 400 may be implemented to comprise or to form at least a part of the receiver 202 discussed above to perform at least a part of operations related to the receiver 202. Since the operations related to the receiver 202 have been discussed above with reference to Figs. 1-5, the blocks of the apparatus 400 will be described briefly here and details thereof may refer to the above description.
[0053] As shown in Fig. 6, the apparatus 400 may include a first means 410 for receiving eCPRI packets from the transmitter 204, a second means 412 for determining buffer addresses to store the received eCPRI packets, and a third means 414 for storing the eCPRI packets into buffer blocks corresponding to the determined addresses. The eCPRI packets received from the transmitter 204 each may be tagged with a unique packet index, and the second means 412 may determine the buffer address for storing the eCPRI packets based on the packet index. For example, the second means 412 may determine the buffer address based on a packet index to buffer address mapping relationship.
[0054] In an example embodiment, the apparatus 400 may optionally include a fourth means 416 for sending a capability report indicating the receiver 202 supports eCPRI packet position prediction to the transmitter 204. In an example embodiment, the capability report may further indicate the supported packet index range and buffer size of the receiver 202. After receiving the capability report, the transmitter 204 may assign a unique packet index for each eCPRI packet and send the eCPRI packet to the receiver 202. As discussed above, the packet index is used to specify a destination position in the receiving buffer for the eCPRI packet. If the transmitter 204 does not receive the capability report or it receives a capability report indicating that the receiver 202 does not support eCPRI packet position prediction, the transmitter 204 may transmit eCPRI packets in a legacy manner to the receiver 202.
[0055] In an example embodiment, the apparatus 400 may optionally include a fifth means 418 for setting a configuration flag for the receiving buffer. The configuration flag is set to indicate that the buffer is configured to store the eCPRI packets in buffer blocks corresponding to the packet indexes.
[0056] In an example embodiment, the apparatus 400 may optionally include a sixth means 420 for receiving a message indicating a packet index range from the transmitter 204, and a seventh means 422 for predicting a buffer block address range based on the received packet index range. The sixth means 420 may receive the packet index range via a C-Plane message before the first means 410 actually receives the eCPRI packets. The seventh means 422 can predict the buffer block addresses for storing the eCPRI packets without waiting until the eCPRI packets are actually received.
[0057] In an example embodiment, the apparatus 400 may further include an eighth means 424 for updating new data indicators associated the buffer blocks. The new data indicator may include two or more bits with a value that can be circularly incremented. When the eCPRI packet is written into the buffer block, the eighth means 424 may update the new data indicator associated with the buffer block by incrementing its value. Hence the new data indicator can be use to identify whether the cCPRI packet is successfully received and stored in the buffer block.
[0058] The apparatus 400 may further include a ninth means 426 for reading the eCPRI packets from the buffer blocks in an order of the block addresses corresponding to the packet indexes, and a tenth means 428 for reassembling a data stream from the eCPRI packets.
[0059] Fig. 7 is a block diagram illustrating an apparatus 500 in accordance with an example embodiment of the present disclosure. The apparatus 500 may be implemented to comprise or to form at least a part of the transmitter 204 discussed above to perform at least a part of operations related to the transmitter 204. Since the operations related to the transmitter 204 have been discussed above with reference to Figs. 1-5, the blocks of the apparatus 500 will be described briefly here and details thereof may refer to the above description.
[0060] As shown in Fig. 7, the apparatus 500 may include a first means 510 for splitting a data stream into multiple fragments, a second means 512 for calculating packet indexes for the multiple fragments, and a third means 514 for transmitting a message indicating a range of the packet indexes to the receiver 202. The calculated packet indexes may indicate an order of the multiple fragments in the data stream. The apparatus 500 may further include a fourth means 516 for packaging the multiple fragments and the corresponding packet indexes into multiple eCPRI packets, and a fifth means 518 for transmitting the eCPRI packets to the receiver 202.
[0061] In an example embodiment, the apparatus 500 may further include a sixth means 520 for receiving a capability report from the receiver 202. The capability report may indicate the receiver 202 supports eCPRI packet position prediction, and optionally it may further indicate a packet index range supported by the receiver 202. In
[0062] Fig. 8 is a schematic block diagram illustrating devices in a communication system 600 according to an example embodiment of the present disclosure. As shown in Fig. 10, the communication system 600 may include a distributed unit (DU) 610 and a radio unit (RU) 620. Fig. 8 shows one RU 620 as an example, but the DU 610 may connect to a plurality of RUs 620.
[0063] The DU 610 may comprise one or more processors 611, one or more memories 612 and one or more network interfaces 614 interconnected through one or more buses 615. The one or more buses 615 may be address, data, or control buses, and may include any interconnection mechanism such as series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. The one or more network interfaces 614 may provide wired or wireless communication links through which the DU 610 may communicate with other network devices, entities, elements or functions. For example, the DU 610 may communicate with a centralized unit (CU) (not shown) via a midhaul link and with the RU 620 via a fronthaul link 602. The one or more memories 612 may include instructions 613 which, when executed by the one or more processors 611, may cause the DU 610 to perform operations and procedures relating to the receiver 202 and the transmitter 204 as described above.
[0064] The RU 620 may comprise one or more processors 621, one or more memories 622 and one or more network interfaces 624 interconnected through one or more buses 625. The one or more buses 625 may be address, data, or control buses, and may include any interconnection mechanism such as series of lines on a motherboard or integrated circuit, fiber, optics or other optical communication equipment, and the like. The one or more network interfaces 624 may provide wired or wireless communication links through which the RU 620 may communicate with other devices, entities, elements or functions. For example, the RU 620 may communicate with the DU 610 via the fronthaul link 602 and with a plurality of mobile devices (not shown) via radio links. The one or more memories 622 may include instructions 623 which, when executed by the one or more processors 621, may cause the RU 620 to perform operations and procedures relating to the receiver 202 and the transmitter 204 as described above.
[0065] The one or more processors 611, 621 discussed above may be of any appropriate type that is suitable for the local technical network, and may include one or more of general purpose processors, special purpose processor, microprocessors, a digital signal processor (DSP) , one or more processors in a processor based multi-core processor architecture, as well as dedicated processors such as those developed based on Field Programmable Gate Array (FPGA) and Application Specific Integrated Circuit (ASIC) . The one or more processors 611, 621 may be configured to control other elements of the DU 610 and the RU 620 and operate in cooperation with them to implement the procedures discussed above.
[0066] The one or more memories 612, 622 may include at least one storage medium in various forms, such as a transitory memory and / or a non-transitory memory. The transitory memory may include, but not limited to, for example, a random access memory (RAM) or a cache. The non-transitory memory may include, but not limited to, for example, a read only memory (ROM) , a hard disk, a flash memory, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) . Further, the one or more memories 612, 622 may include but not limited to an electric, a magnetic, an optical, an electromagnetic, an infrared, or a semiconductor system, apparatus, or device or any combination of the above.
[0067] It would be understood that blocks in the drawings may be implemented in various manners, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more blocks may be implemented using software and / or firmware, for example, machine-executable instructions stored in the storage medium. In addition to or instead of machine-executable instructions, parts or all of the blocks in the drawings may be implemented, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field- Programmable Gate Arrays (FPGAs) , Application-Specific Integrated Circuits (ASICs) , Application-Specific Standard Products (ASSPs) , System-on-Chip systems (SOCs) , Complex Programmable Logic Devices (CPLDs) , etc.
[0068] Some exemplary embodiments further provide program instructions which, when executed by one or more processors, may cause a device or apparatus to perform the procedures described above. The program instructions for carrying out procedures of the exemplary embodiments may be written in any combination of one or more programming languages. The program instructions may be provided to one or more processors or controllers of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program instructions, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program instructions may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
[0069] Some exemplary embodiments further provide a computer program product or a computer readable medium having the program instructions stored therein. The computer readable medium may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0070] As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.
[0071] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.
[0072] Although the subject matter has been described in a language that is specific to structural features and / or method actions, it is to be understood the subject matter defined in the appended claims is not limited to the specific features or actions described above. On the contrary, the above-described specific features and actions are disclosed as an example of implementing the claims
Claims
1.A receiver device, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the receiver device at least to perform:receiving enhanced common public radio interface (eCPRI) packets from a transmitter device, the eCPRI packets being tagged with packet indexes;determining addresses in a buffer based on the packet indexes; andstoring the eCPRI packets into blocks of the buffer corresponding to the determined addresses.2.The receiver device of claim 1, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the receiver device at least to perform:reading the eCPRI packets from the blocks of the buffer in an order of the addresses corresponding to the packet indexes; andreassembling a data stream from the eCPRI packets.3.The receiver device of claim 1, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the receiver device at least to perform:setting a configuration flag for the buffer indicating that the buffer is configured to store the eCPRI packets in buffer addresses corresponding to the packet indexes.4.The receiver device of claim 1, wherein the buffer includes a configurable number of blocks.5.The receiver device of claim 1, wherein the buffer is deployed in a double data rate memory.6.The receiver device of claim 1, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the receiver device at least to perform:reporting capability of supporting eCPRI packet position prediction and supported packet index range to the transmitter device, before receiving the eCPRI packets.7.The receiver device of claim 1, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the receiver device at least to perform:receiving, from the transmitter device, a message indicating a range of the packet indexes, before receiving the eCPRI packets togged with the packet indexes; andpredicting a range of the buffer addresses to be used based on the received packet index range.8.The receiver device of claim 1, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the receiver device at least to perform:updating new data indicators for the buffer blocks in response to the eCPRI packets being stored into the buffer blocks.9.The receiver device of claim 1, wherein the receiver device is a radio unit or a distributed unit.10.A transmitter device, comprising:at least one processor; andat least one memory storing instructions that, when executed by the at least one processor, cause the transmitter device at least to perform:splitting a data stream into multiple fragments;calculating packet indexes for the multiple fragments, the packet indexes indicating an order of the multiple fragments in the data stream;transmitting, to a receiver device, a message indicating a range of the packet indexes;packaging the multiple fragments and the corresponding packet indexes into multiple enhanced common public radio interface (eCPRI) packets, respectively; andtransmitting the eCPRI packets to the receiver device.11.The transmitter device of claim 10, wherein the at least one memory further stores instructions that, when executed by the at least one processor, cause the transmitter device at least to perform:receiving, from the receiver device, a capability report indicating the receiver device supporting eCPRI packet position prediction and a packet index range supported by the receiver device, the message indicating the range of the packet indexes being transmitted in response to the capability report.12.The transmitter device of claim 10, wherein the transmitter device is a distributed unit or a radio unit.13.A method comprising:receiving enhanced common public radio interface (eCPRI) packets from a transmitter device, the eCPRI packets being tagged with packet indexes;determining addresses in a buffer based on the packet indexes; andstoring the eCPRI packets into blocks of the buffer corresponding to the determined addresses.14.The method of claim 13, further comprising:reading the eCPRI packets from the blocks of the buffer in an order of the addresses corresponding to the packet indexes; andreassembling a data stream from the eCPRI packets.15.The method of claim 13, further comprising:setting a configuration flag for the buffer indicating that the buffer is configured to store the eCPRI packets in buffer addresses corresponding to the packet indexes.16.The method of claim 13, wherein the buffer includes a configurable number of blocks.17.The method of claim 13, wherein the buffer is deployed in a double data rate memory.18.The method of claim 13, further comprising:reporting capability of supporting eCPRI packet position prediction and supported packet index range to the transmitter device, before receiving the eCPRI packets.19.The method of claim 13, further comprising:receiving, from the transmitter device, a message indicating a range of the packet indexes, before receiving the eCPRI packets togged with the packet indexes; andpredicting a range of the buffer addresses to be used based on the received packet index range.20.The method of claim 13, further comprising:updating new data indicators for the buffer blocks in response to the eCPRI packets being stored into the buffer blocks.21.A method, comprising:splitting a data stream into multiple fragments;calculating packet indexes for the multiple fragments, the packet indexes indicating an order of the multiple fragments in the data stream;transmitting, to a receiver device, a message indicating a range of the packet indexes;packaging the multiple fragments and the corresponding packet indexes into multiple enhanced common public radio interface (eCPRI) packets, respectively; andtransmitting the eCPRI packets to the receiver device.22.The method of claim 21, further comprising:receiving, from the receiver device, a capability report indicating the receiver device supporting eCPRI packet position prediction and a packet index range supported by the receiver device, the message indicating the range of the packet indexes being transmitted in response to the capability report.23.An apparatus comprising:means for receiving enhanced common public radio interface (eCPRI) packets from a transmitter device, the eCPRI packets being tagged with packet indexes;means for determining addresses in a buffer based on the packet indexes; andmeans for storing the eCPRI packets into blocks of the buffer corresponding to the determined addresses.24.An apparatus comprising:means for splitting a data stream into multiple fragments;means for calculating packet indexes for the multiple fragments, the packet indexes indicating an order of the multiple fragments in the data stream;means for transmitting, to a receiver device, a message indicating a range of the packet indexes;means for packaging the multiple fragments and the corresponding packet indexes into multiple enhanced common public radio interface (eCPRI) packets, respectively; andmeans for transmitting the eCPRI packets to the receiver device.25.A computer readable medium comprising instructions stored thereon for performing at least the following:receiving enhanced common public radio interface (eCPRI) packets from a transmitter device, the eCPRI packets being tagged with packet indexes;determining addresses in a buffer based on the packet indexes; andstoring the eCPRI packets into blocks of the buffer corresponding to the determined addresses.26.A computer readable medium comprising instructions stored thereon for performing at least the following:splitting a data stream into multiple fragments;calculating packet indexes for the multiple fragments, the packet indexes indicating an order of the multiple fragments in the data stream;transmitting, to a receiver device, a message indicating a range of the packet indexes;packaging the multiple fragments and the corresponding packet indexes into multiple enhanced common public radio interface (eCPRI) packets, respectively; andtransmitting the eCPRI packets to the receiver device.
Citation Information
Patent Citations
System and method for transmitting CPRI interface on grouping equipment
CN106941448A
Network data transmission method and system
CN115766706A
CPRI / eCPRI Data Transmission Method in Cloud Radio Access Network
US20200113016A1