A pragmatic industrial road map for shifting the
existing fronthaul from CPRI to 5G compatible
eCPRI
Chaitanya Sharad Shinde
Research Engineer, CDOT
Abstract—In this fast approaching era of 5G deployments,
MNOs have started implementing Centralized radio access net-
works (C-RAN) so that it can fulfil the prodigious requirements
of future 5G services in terms of network latency, service
availability, capacity, and network coordination. The fronthaul
interface will now have to adapt to various functional splits and
cannot be constrained to one split option. Thus evolved Common
Public Radio Interface (eCPRI) has been introduced for the
communication between the evolved Radio Equipment Controller
(eREC) and evolved Radio Equipment (eRE). This article aims
to deliver a basic understanding of eCPRI specification: its
concept, design and synchronisation. The author plans to give the
industrial world a realistic glimpse of the amendments required
in the already deployed CPRI fronthaul so as to make it 5G
compatible eCPRI, and research challenges in the next-generation
5G mobile network.
Index terms - CRAN, 5G, eCPRI, Fronthaul (FH), Functional
splits.
I. I NTRODUCTION AND M OTIVATION
Mobile Network Operators(MNOs) have unanimously con-
ferred that the C-RAN architecture, for the 5G deployment
in its various use cases, would embrace the concepts of
cloud computing and processing of radio signals. Effective
load balancing and joint processing of different base stations
enhances the network’s effective capacity [1,2]. A CRAN
deployment trial from China Mobile has showcased 53 and 30
percent OPEX and CAPEX savings respectively [3]. The split
between REC and RE depends on which all radio processing
functions will be implemented in DU or RRH (RE) and which
all functions will be processed by cloud or centralised REC.
According to the current development, literature defines the
following functional splits [4,5]:
(1) Split option 8 aka PHY-RF split which has been used on a
vast scale for LTE deployments and uses CPRI as front-haul
interface
(2) Split Option 7 aka intra-PHY split, where some of the radio
control operations are performed at RE, after its reception from
REC.
(3) Split Option 6 aka the MAC-PHY split where the whole
RF and PHY processing operations will be implemented at the
RRH or DU.
(4) Split Option 2, aka PDCP-RLC split, where all the
functions after PDCP i.e RLC, MAC, PHY and RF are
implemented in DU and PDCP in CU.
The lower layer PHY splits, i.e split options 7.x, support
the advanced radio coordination techniques such as Joint
297Downloaded on June 30,2022 at 12:39:10 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR.
Transmission and Coordinated Multipoint. A challenging pre-
requisite that comes with such CRAN deployments is that REC
and RE needs to be connected with a high speed, low latency
Fronthaul adhering to critical synchronization requirements. A
great deal of processing that was supposed to occur at base
station is now offloaded, posing stringent management and
synchronization constraints for the fronthaul transport. CPRI,
a serial line interface transmitting Constant Bit Rate (CBR)
data over a dedicated channel, was introduced to cater the FH
specifications specifically for split option 8. With 5G moving
to different market oriented use cases, different Intra PHY
splits have to be deployed for each one of them. This limits
the use of CPRI for different functional splits. Furthermore,
CPRI being a CBR option regardless of actual mobile payload,
optimum bandwidth utilization would not be always catered
and will result in resource wastage. As a result of the above
constraints, eCPRI was introduced which is flexible with
lower layer split options 7.x. Owing to the implementation of
other benefits such as traffic aggregation, point to multi-point
architecture, statistical multiplexing gain and low quantization
resolution, Ethernet based packet transport layer is considered.
Due to the packet based fronthaul, data rates are dependent on
the actual resource block (RB) utilization at any given time
[6].
The article proceeds with the following agenda : section II
gives a brief about the constraints of CPRI FH in 5G deploy-
ment. Section III will give an overview about the features and
highlights of eCPRI specification. Section IV briefly explains
the transmission process of User Plane messages among
eCPRI nodes, through the FH. Section V gives interesting
insights and guidelines to MNOs for making split option 8
deployments compatible with eCPRI. Section VI deals with
important research initiatives to be undertaken for the real time
deployment of 5G based CRAN.
II. CPRI TO E CPRI : R EASONS
Fig 1 shows different functional splits that will be imple-
mented in different 5G Use Case deployment scenarios. The
decision of split to be implemented, mainly depends on the bit
rate required for the fronthaul. As we move towards the MAC-
PHY aka split option 6 (split D), the bit rate for user data will
decrease but the reverse happens for control data required for
synchronization and management of fronthaul. Rest assured,
the sum of bit rates does not remain same and hence only
 certain split options are considered owing to the trade off as
shown in Fig 1.
For illustrating the reduction in bit rate, let us consider split
Fig. 1. 5G Processing chain illustrating MAC-PHY split (option D); PHY-RF
split (option E) and intra PHY-split options 7.1, 7.2 (IID or IU ) and 7.3 (ID )
option IU which corresponds to the split IID [7]. The bit rate
required in this case will now depend only on the fraction of
RBs used (η), and is expressed as
RIU = Nsc . 0.9 . Ts−1 . η . 2 . Nbits . Nant (1)
Ts - Symbol duration time, Nbits - Quantisation bits, Nant -
number of antennas for reception, Nsc - Number of orthogonal
sub-carriers. Whereas the split option E if implemented will
give the following bit rate,
RE = fs . 2 . Nbits . Nant (2)
where, fs is sampling frequency. The factor 2, in both of
the above equations, is due to the complex samples being
transmitted. [8] works out on the traffic profiles for these 2
splits and demonstrates a bit rate reduction by approximately
1.7 times in the case of IU . [9] shows a tabular representation
of user data bit rate along the eREC-eRE, according to which
ID and IU will have the best bit rate optimizations among the
intra PHY splits. It also claims that a massive bit rate of 236
Gbps will be required to implement 100 MHz air bandwidth
with Split 8(E), in 5G deployments, without compression tech-
niques. The problem that tags along with CPRI as fronthaul
is that only Split E can be implemented. This will require
atleast 10 25GigE links for the transfer of 3Gbps MAC data.
Additionally, considering the 5G numerology and slot lengths,
it has to be noted that the slot length varies from 1ms to
0.0625ms as opposed to the fixed slot of 1 ms in LTE. Now,
for synchronizations and management of these slot lengths
the PHY layer timing units have to be in powers of half a ns.
Such strenuous high accuracy requirements cannot be fulfilled
by CPRI, owing to its own transport layer. Furthermore, CPRI
being a CBR option, accuracy failures will rise resulting to
high BER.
Although CPRI was deemed to be the main FH interface
standard, as compared to its counterpart: OBSAI interface,
its adaptation to the vast 5G use cases is questioned. For
high accuracy timings, advanced networking architectures and
OAM features of the current packet based networks, such as
Ethernet/IP need to be utilized. Also, bandwidth utilization in
CPRI is not dependent on the mobile payload and hence will
lead to resource wastage in idle state.
Owing to these constraints, eCPRI was introduced showcas-
ing the following key features[9]: 1/10th of the BW utilization,
packet based network with required BW scaling according
to the user-plane traffic data, flexibility of implementation of
functional splits, using predominant Ethernet/IP as transport
network etc.
III. OVERVIEW OF E CPRI S PECIFICATION
A. Highlights
As the functional splits vary according to the deployment
case, the eREC will be performing the MAC and all the PHY
functions above the split whereas the eRE will be performing
all the lower PHY and RF functions. Co-operative techniques
among nearing cell sites, such as CoMP and Joint Trans-
mission, can still be implemented as the signal processing
functions will be located in eREC protocol stack [10]. Some
of the main design highlights and requirements of eCPRI are
:
• A Precision Time Protocol based reference clock, Grand
Master, is a must at both eREC and eRE. There is
no master slave configuration among the nodes, but a
master PTP is required. All the eRECs and the eREs
should always be synchronized to a common GM. Further
implications and applications will be unveiled in later
sections.
• eCPRI, at its core, is a multi-point network as opposed
to point-to-point interface of CPRI. It can also be used
as an internal interface for local networks consisting
of multiple nodes. eCPRI, even though not backward
compatible to CPRI, can coexist with CPRI in a system.
This shouldn’t come as a surprise as eCPRI also follows
the same radio standards as followed by CPRI i.e 3GPP
and E-UTRA. Fig 2 showcases the system architecture of
eCPRI. The IWF allows the eCPRI nodes to collate with
CPRI networks so that they can coexist.
Fig. 2. eCPRI System architecture : PTP GM, eREC, eRE, IWFs, RE, REC

298Downloaded on June 30,2022 at 12:39:10 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR.
 B. Protocol planes
The interface specification defines 3 protocol planes be-
tween eREC and eRE: User Plane Data, Control and Man-
agement Plane, Synchronization Plane. Each of these protocol
planes will establish a logical connection among the system
access point (SAP) of any 2 nodes. Thus, interconnection
between SAPS , SAPCM and SAPU will define a logical link.
All protocol planes are multiplexed into a single packet based
transport PHY layer.
• User Plane Data : This protocol carries the user data,
real time control information for the user data and other
eCPRI related support services depending on the func-
tional split implemented. eCPRI specification defines a
protocol only for this flow
• C & M : C & M is a non-time critical data flow that is
required by the control and management entities within
the eCPRI nodes. This information flow is conveyed to
the higher protocol layers without any modification from
eCPRI protocol. Existing protocols are used, such as TCP
over IP, as majority of this data flow is considered as
background traffic.
• Synchronization : This protocol plane carries informa-
tion required for frame and time alignment so that nodes
can recover timings from reference source and the air
interface meets the synchronization timings of 3GPP
radio standard. Existing protocols such as PTP and SyncE
are applied for this time critical flow, which also uses a
small part of the total bandwidth.
C. Interworking Functions
Interworking functions(IWFs) act as a functional interface
used for coalition of eCPRI protocol with CPRI implemented
radio nodes. Implementation of these, make the CPRI nodes
available on eCPRI fronthaul network. These functions ter-
minate the protocols for both, CPRI and eCPRI, and acts as
bridge between them.
• Interworking Function 0 :The CPRI master port is
implemented in IWF type 0 so that it can bridge with
RE. The eREC will treat the entire configuration of IWF
0 and RE as eRE even when RE is using CPRI as its FH.
The IWF 0 is accommodated in the network as follows :
eREC ↔ eCP RI ↔ F H ↔ IW F 0 ↔ RE
• Interworking Function 1 : CPRI slave is implemented
in IWF 1 corresponding to the master REC. However, this
behaves as a CPRI slave as long as RE is in conjunction
with IWF 2 and is online on the network. IWF 1 and
IWF 2 cannot perform exclusively of each other, because
the following configuration:
REC ↔ IW F 1 ↔ eCP RI ↔ F H ↔ IW F 2 ↔ RE
ensures that REC and IWF1 behaves as eREC only in
presence of eRE virtually visualised by IWF2 and RE
combination.
• Interworking Function 2 : CPRI master is implemented
in IWF 2 corresponding to the slave RE. However,
this behaves as a CPRI master as long as REC is in
conjunction with IWF 2 and is online on the network.
IV. U SER P LANE M ESSAGES
A. Message Format
User plane messages, transmitted when Ethernet is the
chosen transport layer, will be transmitted in standard Ethernet
frames of size 1500 octets through the AEFE16 eCPRI type
[11]. The minimum size of the Ethernet packet is 46 octets
and hence eCPRI payload data is padded with zeros, if it
does not fill up the minimum size. The data field of the
Ethernet PDU starts with an eCPRI common header of 4
bytes, Fig. 3, which is followed by the eCPRI payload. The
Fig. 3. An example of mapping of two continuous eCPRI packets to the
transport layer
common header describes the eCPRI protocol version, which
all service the payload conveys, length of the payload and the
concatenation indicator. The concatenation indicator(C) bit is
asserted when another eCPRI message follows the one which
is being transmitted now. Basically, when the eCPRI PDU
exceeds the maximum transport layer packet size, it is split
into multiple packets. While concatenating, padding bytes are
added in place of common header so that the data starts at a
4 byte boundary. The transmission byte order is big endian.
After the eCPRI packet is formed, it is sent to the transport
layer where TNL layer header and padding bytes are added.
B. Types of messages
1 byte in the common header is used to define 256 message
types to be used in eCPRI. Out of these, types 12 to 63 is
reserved for further modifications whereas 64 to 255 are used
for vendor specific data. Types 0 to 11 can be broadly classified
in to 3 different categories as follows,
1) Related to user data: Type 0 : IQ Data, 1 : Bit
Sequence, 2 : Real-Time Control Data (RTCD) and 3 :
Generic Data Transfer come under this category. Now each
of these messages uses PC ID and SEQ ID where PC ID
values are allocated by the vendor to distinguish the series of
messages according to physical channel or an user or a layer
or an antenna port. In practical scenarios, multiple transfer
sequences are paralleled with different PC IDs. SEQ ID is
used as an identifier of each message in a series of messages
with same PC ID. Its allocation is also vendor specific and is
differentiated on basis of OFDM symbol identifier or block of
sub-carriers, etc. Even the User data format is vendor specific
which is known by the nodes in advance.
Difference between the interpretation of Type 0 and type 1

299Downloaded on June 30,2022 at 12:39:10 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR.
 user data is dependent on the functional split. Furthermore
in type 0, user data can be transmitted as frequency domain
IQ data as well as time domain IQ data depending on the
implemented functional split. Type 2 messages are vendor
specific messages which are used for the user data associated
with real time control information flow. As this data also
depends on the implementation of functional split, its message
format is defined but the interpretation of the message by
the node is vendor specific. RTC ID is the identifier of these
RTCD messages based on configuration, status, measurement
request/response/indication; whose allocation also depends on
vendor. The decision of transmission of these message prior
to or after the user data solely depends on the vendor. RTCD
informs the remote node on the processing of the associated
incoming/received user data.
The generic data transfer message gives the flexibility to
transfer user plane data or control data at enhanced data
synchronization. Also PC ID and SEQ ID, which is of 2 bytes
each in types 1 and 2, is 4 bytes each in this message transfer.
This message type plays an important role in our suggested
transition from CPRI to eCPRI interface.
2) Control, Support and Timing: This includes message
types 4 to 7. Message type 4 is Remote Memory Access
which allows a symmetric initiation of reading/writing on the
memory address of the link connected opposite to the initiating
eCPRI node. This message, by default, is an atomic procedure
unless specified otherwise. Even the write request has to be
acknowledged, and the requester cannot send another request
to the same receiver until the previous one is acknowledged.
Requests can be broadly classified as Read, Write and Write
without response. Request/response/failure is encoded into a 4
bit field. 2 byte Length field depicts the actual read or written
bytes which may be different from the requested length due
to contingency reasons. Failure response will have the length
of the associated data stating the reason of failure. This data
encoding into bit format will be vendor specific. Also, failure
response will be asserted even when the request was Write
without response.
Message type 5 is used for estimating one way delay mea-
surement between two eCPRI ports. This is done by including
a time stamp in the message while transmitting. The time
stamp is the sampled time while the sender sends the message.
The decision of selecting a timing instant out of the optional
timing instants, shown in Fig 4, depends on the vendor. The
receiver while receiving, will sample the local time, note its
timestamp and send the message back to transmitter. Provision
of requesting delay measurement from the other eCPRI node
to itself is also provided, using remote request. To increase
the estimation of delay, dummy bytes are included. As shorter
messages takes less time through the network as compared to
a longer one, the delay estimation is improved. The number of
the dummy bytes that will be appended is defined in the eCPRI
common header. An important concept of compensation value
(cv) is also used in this estimation procedure.
cv time of transmitter can be imagined as the internal
processing time starting from generation of timestamp to the
300Downloaded on June 30,2022 at 12:39:10 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR.
Fig. 4. Representation of one way delay measurement
actual transmission of message on the network. In the same
way, at the receiving end cv time is the internal processing
time starting from the reception of the message to the time
stamping of it. To estimate the one way delay measurement
on FH; start of transmission happens at (t1 + tcv1 ) and ends at
(t2 − tcv2 ). Thus delay measurement estimation can be stated
as :
tD = (t2 − tcv2 ) − (t1 + tcv1 ) (3)
where tcv1 is the cv at transmitting side and tcv2 is the cv
at receiving side. One important point this transfer assumes
is that the participating nodes need to be synchronized, with
sufficient accuracy, to a common time.
Message type 6, Remote Reset, may be used in succession
of type 7 (Event Indication) or in an emergency. This can be
used to reset the IWFs also but should be restricted only to
emergencies as the radio system impact due to connecting
functions of RE will also be affected. A total reset as well
as resetting a generic hardware function instance can be
implemented by defining Reset ID in the message format
accordingly. Each remote reset request should be returned
with a proper response, as defined by vendor, for minimizing
and controlling its impact on other hardware dependants.
Vendor can also append specific data for the authentication
of the parameters pertaining to the execution of the reset.
Message type 7 is used when a node connected to either side
of the FH wants to indicate about an event to the other one.
Event can be a fault or a notification of ongoing fault, but
should be related to eCPRI. A type 7 message can have either
multiple faults or notifications, but not both. C&M faults
will be sent on C&M plane. To model faults according to
hardware and software elements, specific implementation of
this elements to element ID is done by vendor. Certain faults
which are related to all the elements i.e the entire node, is
given a separate reserved Element ID.
A type 7 message can be a Fault indicator, fault
acknowledgement, notification indicator, Synchronization re-
quest(Sync Req), Synchronization Acknowledge(Sync Ack)
or a Synchronization End(Sync End) indication. When
multiple faults, for the same element, are sent over a period
of time; sequence number field in the message format is
incremented. This helps the receiving node to map the
faults sequentially when the indications are received out of
order due to the packet based network. A fault indication
is retransmitted with the same sequence number when fault
acknowledgement is not received. Indications are provided
by transmitter only when a fault is encountered or ceased.
 Functionality of requesting the status of all active faults from
the faulty node is also provided. In that case Sync Req is
transmitted to the faulty node, to which it acknowledges
using Sync Ack. Sync Ack just acknowledges that a request
message is received. After Sync Ack, the faulty node starts
transmitting fault indicator messages of all the active faults
in its elements. In the end, when all indicator messages
have been acknowledged, the faulty node sends a Sync End
message to indicate the end of the synchronization procedure.
3) CPRI-eCPRI collation messages for IWFs: IWF Start-
Up messages (Type 8) are used for setting up the configuration
of IWFs 1&2 to which REC and RE are connected. This is
done by transmitting the Control word bytes (TCW ) of each
CPRI basic frame. Along with TCW ; information pertaining
to forward error correction (FEC), scrambling and bit rate of
implemented CPRI line is also transferred. The IWFs extract
timestamps from these messages for synchronizing their local
clocks with the start of the hyperframe structure of CPRI.
After setting up the IWFs; negotiation for deciding the map-
ping configuration of CPRI data to eCPRI specified data
format takes place, through Type 10 messages (IWF Mapping).
The mapping configuration divides the CPRI basic frame’s IQ
data into sub parts. Each mapping configuration is recognised
by the node through an unique mapping ID whose assignment
will be vendor specific. Negotiation for settling up on a
mapping configuration takes place in the following stages
: Request, Accept/Reject/Propose, Request (only in case of
Propose). Proposing a mapping configuration after rejection
is not mandatory. Request message sends mapping ID, along
with the mapping locations of each sub part, to the other node.
Initiation of Request for uplink mapping configuration is done
by IWF type 2 whereas for downlink, IWF type 1 initiates. The
mapping configurations for UL and DL can be different. The
request message is acknowledged by sending an Accept/Reject
message. In the above response messages, proposal of a new
mapping configuration for the sub parts is not included. If the
receiver proposes a new sub parts’ mapping configuration, as
an acknowledgement, the initiator again sends a request with
the proposed mapping parameters; compelling the receiver to
accept it.
After the start up and negotiation process, starts the actual data
transmission via IWF operation messages (Type 9). The header
of this message is defined to indicate the hyper frame number,
basic frame number,fragment index, presence of control word
bytes, Data block, errors etc. Fragment Index depicts if the
CPRI basic frame has been split into several eCPRI type 9
messages or not. All fragments will be pointing towards the
same basic frame number in the hyper frame. This index starts
with zero for the first fragment and will eventually increase
per eCPRI message fragment. The data block is transmitted
using the mapping configuration which was set up by message
type 10. Each sub part is considered as a chunk of data to be
transmitted as a data block.
For delay management and to procure proper CPRI frame tim-
ing with respect to the local clock, IWFs use the Timestamps in
301Downloaded on June 30,2022 at 12:39:10 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR.
type 8 messages along with the type 11 messages (IWF Delay
Control). This message type is used to calculate delay values
from a remote device to itself. The initiator requests for delay
values from a certain node, to which the receiver reports the
1 th
delay values in the order of 16 of a ns. A request message
for this type has to be acknowledged with the delay values.
V. FH R ESTRUCTURING TO E CPRI IN CPRI DEPLOYMENT
SCENARIOS
A. Considerations beyond Protocol stack
The LTE-A architecture has been deployed with CPRI fron-
thaul for leveraging the advantages of CRAN implementation.
We have dealt with the protocol layer mapping concepts
of the interworking function. But the deployment types of
IWF varies according to the characteristics of the transport
network. In a certain transport network of a mobile network
operator, REs might not have multiple antenna elements or
less elements and will be operating on a lesser bandwidth.
Such network need not address the issue of data reduction
on FH and thus these ones can transfer data using Type 0
messages with time domain IQ data, provided the eREC also
generates time domain IQ data. If the transport network wants
to address data rate reduction or the eREC doesn’t generate
time domain IQ samples, then the interworking functions will
have to support additional functions. In that case, the fronthaul
will be transporting Type 0 frequency domain IQ data (split
IID ) or type 1 bit sequence (split ID ). The type 2 messages
will bridge the CPRI real time control data for the user plane.
Fig 5 shows deployment possibilities of all the three function
split options. The first shows that the eREC can handle time
domain IQ data (split E) and hence IWF has to deal only with
the mapping of CPRI data to eCPRI format. The second and
third shows the deployment of IWF for split IID and split ID
respectively. In these cases, IWF will have to deal with extra
PHY layer functionalities along with the data mapping.
Taking the OPEX in to consideration : eREC, which by
Fig. 5. User plane Bridging using different Protocol stacks of IWF type 0
for different functional splits
default wont be following split option 8, won’t have the
protocol functions required for the generation of time domain
IQ data. Thus making the eREC capable to decipher and
generate time domain IQ and then transmit on FH with a
high bandwidth requirement won’t be economical. Instead
implementing the IWF with the added the functional protocols
and then transmitting it on FH with data reduction, will surely
bring down the CAPEX of the mobile network operators.
 B. Deployment possibilities
The purpose of implementing IWFs is to cut the cost
required to deploy new Radio heads. The existing REs should
be able to connect to an eREC via eCPRI network. IWFs need
not be protocol specific and can have functions from PHY
stack, for data reduction. So the use cases for deployment
have these possible migration scenarios:
1. IWF as a functionality is deployed as a separate independent
node. Its protocol stack can be placed anywhere among
eRE/eREC or in the transport network between the RE and
eREC.
2. IWF protocol stack can be placed on an eRE which will be
daisy chained to another RE. The data arriving from the RE to
the IWF, through CPRI link, will be combined with the data
to be transmitted by the eRE to the eREC. The control and
downlink data from the eREC to the RE will also be following
the same path. The constraints faced by this deployment will
be the end to end latency and more processing of control data
at the eRE. Also, the headers at each transaction layer will
have an impact on the ratio of data transmitted to useful data.
3. A pooled IWF protocol stack as an independent node placed
between the eREC and multiple REs. The joint processing
of multiple REs and reduction of the extra packet headers
will drastically reduce the cost of the link. The end to end
latency from the eREC to eRE will come down because : the
processing of multiple REs can be treated as different antenna
carrier elements of a same base station, from the point of view
of eREC. The disintegration of the DL data will be handled by
the IWF in much more simpler way owing to the packetization
of data into a single/multiple continuous PDU.
VI. F UTURE R ESEARCH AND C HALLENGES
The above work articulated an overview of the backdrop
of eCPRI on the grounds of the constraints faced by CPRI
FH. A brief discussion about the specifications of eCPRI
enlightened the packet formation and transfer of user plane
data. Real life deployment scenarios for the MNOs, to deploy
and implement eCPRI FH, using the existing CPRI FH gives
a market oriented approach by taking into consideration athe
capital and operational expenditures.
eCPRI is still in its formulation stages and has been recently
creating a buzz for itself. Also, implementation of CPRI in
mobile networks caused cost inefficiency as its hardware was
not compatible with the existing MAC and PHY protocols.
Thus eCPRI was developed to address flexible deployment
according to the existing architecture, cost-effectiveness and
easy integration compatibility with the packet based optical
networks.
The formulation of Ethernet as Time sensitive network needs
the mechanisms for implementing strict delay requirements.
These requirements impose a limit of 20 km on maximum
fibre distance between RRH and BBU, when there are no
bridges in the network path. Addition of bridges in the network
path leads to delay insertion, and hence reduces the overall
spread distance. Even though the implementation of IHON
and IEEE TSN standardized mechanisms adds extra spread to
302Downloaded on June 30,2022 at 12:39:10 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: INDIAN INSTITUTE OF TECHNOLOGY KHARAGPUR.
this transmission distance, there is still more scope for further
research[13].
Advancements in DSP and FPGA implementations for the
support of ultra low latency requirements of 5G in both
PTP and PTMP architectures for eCPRI has to be studied.
These will require high-speed transceivers of range 200Gbps
to even 1Tbps to guarantee ultra-low queuing delay values[14].
Technologies to develop such transceivers are a prerequisite
for implementation of FH eCPRI transport on legacy 40 MHz
and 100 MHz LTE channel networks.
There is a vast scope of research in the areas of load adaptive
flexible quantization resolution using LAFQB strategies for the
implementation of elastic eCPRI based fronthaul. Although the
flexibility of the FH capacity is enhanced and the FH band-
width is saved, the queuing model for LAQFB by adopting
low QR is worth researching[15].
R EFERENCES
[1] A. Checko, H. L. Christiansen, Y. Yan, L. Scolari, G. Kardaras, M.
S. Berger, and L. Dittmann, “Cloud RAN for mobile networks—a
technology overview,” IEEE Commun. Surv. Tutorials, vol. 17, no. 1,
pp. 405–426, 2015.
[2] A. Checko, A. P. Avramova, M. S. Berger, and H. L. Christiansen,
“Evaluating C-RAN fronthaul functional splits in terms of network level
energy and cost savings,” J. Commun. Netw., vol. 18, no. 2, pp. 162–172,
2016.
[3] “C-RAN: the road towards green RAN,” China Mobile White Paper, v2,
2011
[4] 3GPP, “Study on new radio access technology: Radio access architecture
and interfaces,” NTT DOCOMO, INC., Draft Tech. Rep. 38.801 (version
0.3.0), Aug. 2016.
[5] Small Cell Forum, “Small cell virtualization functional splits and use
cases,” SCF 159.07.02, Jan. 2016.
[6] J. Kani, S. Kuwano, and J. Terada, “Options for future mobile backhaul
and fronthaul,” Opt. Fiber Technol., vol. 26, pp. 42–49, 2015.
[7] U. Dötsch, M. Doll, H. P. Mayer, F. Schaich, J. Segel, and P. Sehier,
“Quantitative analysis of split base station processing and determination
of advantageous architectures for LTE,” Bell Labs Tech. J., vol. 18, pp.
105–128, May 2013.
[8] Pérez, Gabriel Otero, José Alberto Hernández, and David Larrabeiti.
”Fronthaul network modeling and dimensioning meeting ultra-low latency
requirements for 5G.” IEEE/OSA Journal of Optical Communications and
Networking 10.6 (2018): 573-581.
[9] Gigalight.com. (2019). eCPRI Specification V2.0. [online] Available at:
https://www.gigalight.com/downloads/standards/ecpri-specification.pdf
[Accessed 23 Feb. 2020].
[10] De la Oliva, Antonio, Jose Alberto Hernandez, David Larrabeiti, and
Arturo Azcorra. ”An overview of the CPRI specification and its applica-
tion to C-RAN-based LTE scenarios.” IEEE Communications Magazine
54, no. 2 (2016): 152-159.
[11] Standards-oui.ieee.org. (2020). [online] Available at: http://standards-
oui.ieee.org/ethertype/eth.txt.
[12] Civerchia, F., Kondepue, L., Giannone, F., Doddikrinda, S., Castoldi,
P. and Valcarenghi, L., 2018, July. Encapsulation techniques and traffic
characterisation of an Ethernet-based 5G fronthaul. In 2018 20th Interna-
tional Conference on Transparent Optical Networks (ICTON) (pp. 1-5).
IEEE.
[13] Bjφmstad, S., David Chen, and Raimena Veisllari. ”Handling delay in
5G ethernet mobile fronthaul networks.” In 2018 European conference
on networks and communications (EuCNC), pp. 1-9. IEEE, 2018.
[14] Zeng, Huaiyu, Xiang Liu, Sharief Megeed, Andy Shen, and Frank
Effenberger. ”Digital signal processing for high-speed fiber-wireless con-
vergence.” Journal of Optical Communications and Networking 11, no. 1
(2019): A11-A19.
[15] Li, Longsheng, Meihua Bi, Haiyun Xin, Yunhao Zhang, Yan Fu,
Xin Miao, Ahmed Mohanmmed Mikaeil, and Weisheng Hu. ”Enabling
Flexible Link Capacity for eCPRI-Based Fronthaul With Load-Adaptive
Quantization Resolution.” IEEE Access 7 (2019): 102174-102185.