Open RAN Blog - Migrating from CPRI to eCPRI

Joseph Chu

09 November 2020

Since the mobile industry developed the digital interface between the baseband unit and radio unit, big brands such as Ericsson, Nokia, NEC and Huawei have formed the CPRI.info organization and set the CPRI standard that currently 90% of the radio units in the field are using. The CPRI standard is built on Time Division Multiplexing (TDM) technology, which defines layer 1 and 2 protocols to transport user plane and Control and Management (C&M) information. The frame structure is fixed for users and C&M information in different CPRI rate, giving a constant transmission bandwidth even though there is no data transmitting. 

Source: CPRI.info

Figure 1. CPRI frame structure

 

Despite other payloads such as the Ethernet packet being carried by the CPRI logical channel, the channel bandwidth has to be pre-defined and cannot be adjusted with the real-time traffic loading. This network architecture makes the bandwidth and delays in the CPRI interface predictable and precise. 

 

Customized with the components like optical module and transport network equipment, the CPRI protocol main application is for radio unit connection which covers from the application layer to the physical layer, while different RAN vendor still has their own implementation requirements. 

 

When the industry moves forward and 5G emerges from the market, a more cost-efficient and multi-purpose fronthaul interference is required to support different RAN architectures such as centralized RAN and Cloud RAN. To address the demands, CPRI.info announced a new packet-based interface standard, eCPRI, to provide more flexible, efficient and reliable fronthaul networks in 2017. 

 

The eCPRI protocol specification only defines the layer 2 function that carries the user defined payload data such as IQ stream, however, both C&M and synchronization are out of the eCPRI protocol scope. Instead of using TDM in CPRI, the typical transport use of eCPRI is the Ethernet protocol which is packet-based. Below shows the eCPRI packet message type. 

Message Type # Name
0 IQ Data
1 Bit Sequence
2 Real-Time Control Data
3 Generic Data Transfer
4 Remote Memory Access
5 One-Way Delay Measurement
6 Remote Reset
7 Event Indication
8-63 Reserved
64-255 Vendor Specific

Table 1: eCPRI Message Types

 

To transport eCPRI protocol in an Ethernet network, eCPRI packet will be encapsulated in an Ethernet packet and can be transported with other traffic such as IP data. 

Figure 2: Typical Ethernet packet with eCPRI payload

 

eCPRI leverages the highspeed Ethernet available in the market such as 10Gbps, 25Gbps, 40Gbps, 100Gbps and above. Most importantly, it is much easier for eCPRI to ride on the metro Ethernet transport network commonly used to connect different datacenter and cloud infrastructure, making it suitable for cloud-based RAN deployment. 

 

eCPRI also has its own challenges. To enjoy the advantages of packet-based networks, some challenges have to be tackled first. One of the challenges in the packet network is synchronization. Unlike CPRI, radio unit adopting eCPRI cannot use the TDM frame as the packet is sent in a synchronized mode. It is suggested to use existing protocols namely SyncE and PTP (IEEE 1588v2) to provide the synchronization function for DU and RU. 

 

Another challenge is the delay and jitter requirement specified in 3GPP for the fronthaul interface, stating one-way delay being kept to less than 100 microseconds (µs). However, the delay time of each packet is difficult to control due to the standard efficiency of packet sending by Ethernet networks. In order to meet the 3GPP’s requirement, applying time sensitive network (TSN) technology defined by IEEE 802.1Q standards to provide deterministic messaging on standard Ethernet can be used to ensure the delay is sufficiently managed. 

 

Although eCPRI is facing new challenges for the fronthaul transport networks, there is no doubt that eCPRI is a more future-oriented interface with BBU compared to CPRI. It can efficiently open up the RAN architecture in 5G evolution and network modernization.

About Joseph Chu

Joseph Chu has worked in telecommunications for over 18 years and with a wide range of experiences, including product management, technical support, solution design, and project management. Joseph is currently the product and solution manager at Comba Telecom, mainly responsible for supporting the OpenRAN business of the Comba International.

More Articles