Solution Brief
Spirent Attero-100G
5G Fronthaul Network Impairment Testing
Product highlights for
5G Fronthaul
• 25GbE and 10GbE
Fronthaul with SyncE pass-
thru.
• External clock inputs.
• eCPRI and RoE (IEEE
1914.3) traffic filtering.
• Extensive traffic filter with
customizable ranges.
• Create filters on captured
pcap file.
• 2 to 16 profile options
available.
• Full line-rate delay: 256ms
at 100GbE, 640ms at
40GbE, 1024ms at 25GbE,
2560ms at 10GbE.
• Packet jitter with 400ms
jitter range.
• 100GbE and 40GbE
optical interfaces also
available.
Spirent Attero-100G
www.spirent.com
What is Fronthaul?
To understand the concept of the “fronthaul”, it’s useful to first understand
what the “backhaul” is. “Backhaul” was a term originally coined by the trucking
industry, and referred to a truck carrying a load from a remote location back to
a central distribution centre. The term was then applied in all contexts to refer
to links connecting a remote site to a central site.
In mobile telecoms, “backhaul” is the link from the radio basestation back into
the core network i.e. hauling the data back from the basestation to the core.
These links are bi-directional so they also carry data from the core out to the
basestation.
Traditionally, a basestation sits in a cabinet and is connected by a co-axial cable
running up the tower to the antenna. This has issues with power loss of the
coaxial cablealong with potential interference and space issues.
So it was proposed to site the actual RF transceiver at the top of the tower
beside the antenna, and connect the transceiver via optical fibre to the
basestation below. This fibre connection between the basestation and the RF
transceiver became known as “fronthaul” as shown below:
Baseband Hotel and C-RAN Architecture
The protocol for the fronthaul interface was specified in the Common Public
Radio Interface (CPRI), produced by an industry consortium consisting of
Alcatel-Lucent, Ericsson, Huawei, NEC and Nokia. Since CPRI is carried over a
fibre connection, it was concluded that the fibre could be made considerably
longer than the height of a tower, freeing the mobile operator from having
to place the baseband unit (BBU) at the antenna location. This is particularly
attractive for dense urban locations where there might be several antennas
within a small area.
Spirent Attero-100G
5G Fronthaul Network Impairment Testing

Deployments consisting of several BBUs were co-located at a central site known as a “baseband hotel” and connected
to the Remote Radio Units (RRUs) using CPRI over dark fibre. This deployment style became known as Centralised Radio
Access Network (C-RAN).

C-RAN simplified the backhaul network because several BBUs could be co-located together and served by a common,
high-bandwidth connection. It also simplified synchronisation since all the BBUs could be served by the same time and
frequency reference, guaranteeing accurate synchronisation.

Provided the latency of the fibre connection to the RRUs was

known accurately, the BBUs could schedule transmission of
the radio frames such that at each antenna, the radio frames
would align with those from other antennas. Synchronisation
then becomes more of a latency management issue rather
than a distributed network synchronisation problem.

The downside of the C-RAN architecture was that the

fronthaul connections required dark fibre. This is costly to
install and prevents sharing of fibres. Furthermore, the CPRI
protocols limit the maximum distance between the BBU and
RRU to a few kilometres, which reduces the economies of
scale provided by the baseband hotel concept. Therefore,
the original C-RAN concept didn’t see much take-up for LTE
deployments.

eCPRI and 5G functional split

The dark fibre used by CPRI connections is not only expensive to install, it is also an inefficient use of fibre as it’s not fully
utilised by a CPRI connection. Some proposals were made to carry CPRI over Wavelength Division Multiplexing (WDM) to
enable sharing of fibres between closely sited RRUs. However, the next major step in the evolution of the fronthaul was to
consider whether the CPRI protocol could be transported across a shared network such as Ethernet.

The CPRI consortium recently published a new specification called eCPRI that defines how to carry radio signals over a
packet network. The underlying networks are not defined, but can include IP/UDP and/or Ethernet. The consortium does
not specify what the “e” stands for; it could be for Ethernet (but eCPRI also works over IP), Evolved (a term used to denote
4G over 3G) or, perhaps, Enhanced.

The IEEE are also in the process of creating an open standard

for the same thing, designated IEEE1914. This is split into
two parts: the radio over packet protocol (IEEE1914.3),
and the requirements on the underlying transport network
(IEEE1914.1). The main feature of both of these is that the
functions of the basestation are split into three parts – the
CU (Centralised Unit), the DU (Distributed Unit) and the
RRU, as shown opposite:

One reason for this is that carrying a radio signal across a

packet network is very inefficient, especially for 5G where
the data rates are particularly high. The RRU connection
may require a data rate of 25Gb/s or higher, therefore
the final link to each RRU is kept as short as possible by
deploying a small DU in the network close to the RRUs.
The “middlehaul” connection between CU and DU can be
lower bandwidth because carrying the intermediate data is
more efficient than the encoded radio signal.
A second reason is that some functions are very latency sensitive, limiting the length of the connection to a few kilometres
as with the original CPRI interface. If those functions are located in the DU, the less latency sensitive portions of the
basestation function can be located further back in the network. This last piece enables the transition from Centralised
RAN to Cloud RAN where the CUs can be located almost anywhere in the network, not just in a localised “baseband
hotel”.

Synchronization Methods in Fronthaul

Time and frequency distribution in the network are separated into two independent planes. Enhanced Synchronous
Ethernet (SyncE) is used at the physical layer to distribute the frequency and Precision Time Protocol (PTP) at the packet
layer to distribute the time and phase. These capabilities have long been present in the backhaul – and with the
movement towards the use of Ethernet in the fronthaul, are now being extended to cover that area as well.

Network Emulation and SyncE

As stated above, SyncE is utilised in the fronthaul, that is, the connection between the BBU and RRU or RRH. (The BBU is
simply the CU and DU, shown in the previous Functional Split diagram, combined into one functional block for simplicity.)
It’s vital that synchronisation is maintained between the
BBU and RRU/RRH. The network emulator used to impair
the network must operate at exactly the same line rate as
the fronthaul connection in order to emulate correctly. In
other words, it must be synchronised to the line rate and
must not break the synchronisation path between BBU and
RRU/RRH or sync/data will be lost.

Very few network emulators were designed with SyncE in

mind, and as such, will be unable to pass the SyncE clock
from one port to another, thus breaking the synchronisation
path. However, the Spirent Attero-100G was designed to
support both SyncE pass-thru and synchronisation to an
external reference clock.

As well as supporting SyncE pass-thru and/or external clock

references, the network emulator needs to support the
25GbE and 10GbE interfaces that fronthaul networks are carried over today. The diagram above shows how the Spirent
Attero-100G should be inserted into the fronthaul path. This is a simplistic diagram showing the emulator connected
between the BBU and the RRU/RRH. The reason for adding network emulation is that it’s important to test the fronthaul
network and the associated fronthaul network equipment in the presence of real network conditions, for example

1. What happens when network delay is increased?

2. What happens when packet loss is introduced and re-transmission occurs or data is lost?

3. What happens when packet jitter is added to the network?

3
Spirent Attero-100G
5G Fronthaul Network Impairment Testing

Network Emulation and eCPRI

As mentioned earlier, the eCPRI specification defines
how to carry radio signals over a packet network carrying
radio messages between the BBU and the RRU/RRH and
handling all of the Traffic and Control & Management.
eCPRI is a higher layer service and is depicted opposite
being carried over UDP and IP. It is also possible for it to be
carried directly over Ethernet.

The structure of the eCPRI User Plane messages common

Header format is shown below. Each message has a 4 byte
eCPRI common header (bytes 0 to 3) followed by a variable
length eCPRI payload.

C (the LSB in byte 0) is the eCPRI messages

concatenation indicator. A value of “1” indicates
that another eCPRI message follows this one
within the eCPRI PDU. A value of “0” indicates
that the eCPRI message is the last one inside the
ECPRI PDU.

Message Type #0: IQData used to transfer time

domain or frequency domain IQ sample between
PHY processing elements split between eCPRI
nodes.

Message Type #1: Bit Sequence used to transfer user data in the form of bit sequences between PHY processing
elements split between eCPRI nodes.

Message Type #2: Real-Time Control Data used to transfer vendor specific real-time control messages between PHY
processing elements eCPRI node (eREC and eRE). This message addresses the need to exchange various types of control
information associated with user data (in form of IQ samples, bit sequence, etc.) between eCPRI nodes in real-time for
control/configuration/measurement.

Message Type #3: Generic Data Transfer used to transfer user plane data or related control between eCPRI nodes (eREC
and eRE) providing extended data synchronisation support for generic data transfers.

Message Type #4: Remote Memory Access allows reading or writing from/to a specific memory address on the opposite
eCPRI node. The service is symmetric i.e. any side of the interface can initiate the service.

Message Type #5: One-way Delay Measurement is used to estimate the one-way delay between two eCPRI-ports in one
direction. The measurement can be performed with or without a Follow_Up message (1-step and 2-step versions). The
decision of which version to use is vendor specific.

Message Type #6: Remote Reset is used when one eCPRI node requests reset of another node. A remote reset request
by an eREC triggers a reset of an eRE.

Message Type #7: Event Indication is used when either side of the protocol indicates to the other end that an event has
occurred. An event is either a raised or ceased fault or a notification. Transient faults are indicated with a Notification.
4
In order to understand how eCPRI behaves in a real fronthaul network, and to be able to see the effect of network
impairments on specific eCPRI message types, the user must be able to filter on a particular eCPRI message type and
then add network impairments to the eCPRI message such as packet loss, delay and also jitter.

The screenshot below shows the eCPRI filter builder within the Spirent Attero-100G and the different eCPRI message
types which the user can filter on:

Network Emulation and Radio over Ethernet

A competing method for transferring CPRI data over the fronthaul network is Radio over Ethernet (RoE). This is defined
in IEEE1914.3. It enables transport of structure-aware mappers and structure-agnostic mappers for CPRI/OBSAI (Open
Base Station Architecture Initiative) and other data formats as well as native I and Q data over Ethernet. The IEEE 1914.3
standard supports:

• The encapsulation of digitized radio. In-phase Quadrature (IQ) payload, possible vendor specific flows and control data
channels/flows into an encapsulating Ethernet frame payload field.

• The header format for structure-aware and structure-agnostic encapsulation of existing digitized radio transport frames.
The structure-aware encapsulation has detailed knowledge of the encapsulated digitized radio transport format
content. The structure-agnostic encapsulation is only a container for the encapsulated digitized radio transport frames.

• A structure-aware mapper for CPRI frames and payloads to/from Ethernet encapsulated frames. The structure-agnostic
encapsulation is not restricted to CPRI.

5
Spirent Attero-100G
5G Fronthaul Network Impairment Testing

RoE (IEEE 1914.3) Common Header Format

The table below depicts the first header bytes in the RoE frame that is common to RoE control packets. The RoE subtype
values or Packet Types are described in more detail in the following RoE (IEEE 1914.3) Packet Types table.

where:
subType — Packet type
Control, structure agnostic, structure
aware, native time domain, native
frequency domain and slow C&M
packet types are defined

flowID — Flows allow SA/DA pairs to distinguish

connections

length — Payload size

orderingInfo — Sequence number or timestamp

Payload — The IQ data/control information

The Spirent Attero-100G can be used for RoE in a similar fashion to eCPRI (covered in the previous section). In order
to understand how RoE behaves in a real fronthaul network and to be able to see the effect of network impairments
on specific RoE message types, the user must be able to filter on a particular RoE message type and then add network
impairments such as delay, packet loss and jitter. For example, the Spirent Attero-100G can be used to stress the limit of
operation of RoE equipment by adding delay up to, and beyond, the 100µs limit.

6
The screenshot below shows the RoE filter builder within the Spirent Attero-100G network emulator and a drop-down
selection of the different RoE message types which you can filter on:

RoE (IEEE 1914.3) Packet Types

BINARY VALUE FUNCTION DESCRIPTION

0000 0000b RoE Control sub type RoE message that contains control or
management information.

0000 0001b Reserved 1 Reserved for future use by IEEE Std

1914.3.
Reserved subType values shall not be
transmitted.
RoE messages with Reserved
subTypes shall be ignored on receipt.

0000 0010b RoE Structure-agnostic Data payload packet with RoE

data sub type common frame header and structure-
agnostic payload.

0000 0011b RoE Structure-aware Data payload packet with RoE

CPRI data sub type common frame header and structure-
aware CPRI I/Q data.

0000 0100b RoE Slow C&M CPRI C&M payload packet with RoE
sub type common frame header and structure-
aware CPRI Slow C&M payload.

0000 0101b - Reserved2 Reserved for future use by IEEE Std

0000 1111b 1914.3.
Reserved subType values shall not be
transmitted.
RoE messages with Reserved
subTypes shall be ignored on receipt.

0001 0000b RoE Native time Time domain data payload packet
domain data sub type with RoE common frame header.

0001 0001b RoE Native frequency Frequency domain data payload

domain data sub type packet with RoE common frame
header.

0001 0010b RoE Native PRACH PRACH IQ data payload with common
data sub type frame header.

0001 0011b - Reserved3 Reserved for future use by IEEE Std

0111 1111b 1914.3.
Reserved subType values shall not be
transmitted.
RoE messages with Reserved
subTypes shall be ignored on receipt.

1000 0000b - Mapped subTypes Companies and/or organizations

1011 1111b owning an OUI or CID can use this
subType range for their own subTypes
and payload structures as defined in
subclause 5.3.4.

1100 0000b - Reserved4 Reserved for future use by IEEE Std

1111 1011b 1914.3.
Reserved subType values shall not be
transmitted.
RoE messages with Reserved
subTypes shall be ignored on receipt.

1111 1100b - Experimental Reserved for experimental types.

1111 1111b The nature and purpose of an
experimental subType cannot
be known in advance, thus the
structure after the common RoE
header is defined as opaque. Entities
implementing the subType can
interpret the message according to
their implementation.

7
Spirent Attero-100G
5G Fronthaul Network Impairment Testing

This discussion of fronthaul networking would not be complete without mentioning the 802.1CM standard that has been
published by the IEEE’s Time-Sensitive Networking (TSN) Task Group. It was developed through a collaborative effort
between the CPRI Cooperation and IEEE 802.1. IEEE Std 802.1CM specifies two TSN Profiles for Fronthaul – one for
eCPRI and one for CPRI.

Summary
The fibre connection between the basestation and the RF transceiver is known as “fronthaul”. The legacy protocol for the
fronthaul interface was specified in the Common Public Radio Interface (CPRI). There are two competing methods for
extending CPRI for use over Ethernets – eCPRI and Radio over Ethernet (RoE) as defined in IEEE 1914.3

SyncE (standardised by ITU-T G.8262) is utilised in the fronthaul to distribute frequency. As a result, any network emulator
that is used to impair the fronthaul network must support SyncE pass-thru or be able to lock to an external clock
reference. In addition, the network emulator needs to be able to support the 25GbE and 10GbE interfaces that fronthaul
networks are carried over today.

​ he Spirent Attero-100G was designed with SyncE in mind and supports both SyncE pass-thru and synchronisation to
T
external clock references, as well as the 25GbE and 10GbE interfaces that fronthaul requires. The Spirent Attero-100G can
also filter on, and impair, specific eCPRI and RoE message types thereby helping engineers understand how eCPRI and
RoE behave in a real fronthaul network.

Furthermore, time-sensitive fronthaul networks have a one-way latency requirement of about 100µs. New technologies,
such as eCPRI and RoE, are needed to enhance best effort Ethernet to make it deterministic and time bound. The Spirent
Attero-100G can be used to add delay to specific fronthaul packet types and stress the limit of operation of eCPRI and
RoE equipment and networks.

8
Spirent Attero-100G
5G Fronthaul Network Impairment Testing

About Spirent
Communications

Spirent Communications
(LSE: SPT) is a global leader
with deep expertise and
decades of experience
in testing, assurance,
analytics and security,
serving developers, service
providers, and enterprise
networks.

We help bring clarity to

increasingly complex
technological and business
challenges.

Spirent’s customers have

made a promise to their
customers to deliver superior
performance. Spirent assures
that those promises are
fulfilled.

For more information, visit:

www.spirent.com

Contact Us
Americas 1-800-SPIRENT
For more information, call your Spirent sales representative or
+1-800-774-7368 | sales@spirent.com
visit us on the web at www.spirent.com/ContactSpirent.
Europe and the Middle East
www.spirent.com +44 (0) 1293 767979 | emeainfo@spirent.com

© 2019 Spirent Communications, Inc. All of the company names and/or brand names Asia and the Pacific
and/or product names and/or logos referred to in this document, in particular the +86-10-8518-2539 | salesasia@spirent.com
name “Spirent” and its logo device, are either registered trademarks or trademarks
pending registration in accordance with relevant national laws. All rights reserved.
Specifications subject to change without notice. Rev A | 09/19