Overview of O-RAN Fronthaul Specifications

RAN Fronthaul Open

Special Articles on Standardization Trends toward Open and Intelligent Radio Access Networks

Overview of O-RAN Fronthaul

NTT DOCOMO Technical Journal

Specifications

Radio Access Network Development Department Anil Umesh Tatsuro Yajima

Toru Uchino† Suguru Okuyama

Standard specifications for fronthaul interfaces with a view to the next-generation

radio access network were released by the xRAN Forum in April 2018. Then,
with the integration of the xRAN Forum into the O-RAN Alliance in March 2019,
these specifications continued on as O-RAN fronthaul specifications. This article
describes the O-RAN fronthaul specifications that are expected to be the first
standard to enable interoperability between different vendors.

control section provides performance benefits through

1. Introduction
inter-cell and inter-frequency coordination while the
As architecture already adopted by operators centralized installation of equipment provides cost
in many countries for their Radio Access Network benefits through resource pooling and reduced in-
1 2
(RAN)* , Centralized RAN (C-RAN)* connects a stallation space [1].
baseband processing section in centralized base sta- On the other hand, the Common Public Radio
tion equipment to multiple units of radio equipment Interface (CPRI)*4 specifications that have come to
via fronthaul*3 (Figure 1). In C-RAN, a centralized be used in conventional C-RAN do not sufficiently

©2019 NTT DOCOMO, INC. *1 RAN: The network consisting of radio base stations and radio-
Copies of articles may be reproduced only for personal, noncommercial circuit control equipment situated between the core network
use, provided that the name NTT DOCOMO Technical Journal, the and mobile terminals.
name(s) of the author(s), the title and date of the article appear in *2 C-RAN: A radio access network having a configuration that
the copies. consolidates the baseband processing sections of base station
equipment and controls the radio sections of that equipment
† Currently Communication Device Development Department through optical fiber connections.
*3 Fronthaul: Circuit between the baseband processing section in
base station equipment and radio equipment using optical fi-
ber.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 46 ―
 Overview of O-RAN Fronthaul Specifications

Baseband processing unit

in base station equipment

Fronthaul

Radio equipment
NTT DOCOMO Technical Journal

Figure 1 C-RAN overview

prescribe specifications for fronthaul interfaces, and 7-2x that places in radio equipment some Layer 1*6
as a result, there are now many regions having orig- functions traditionally located in the baseband pro-
inal specifications prescribed by different vendors. cessing section. They also prescribe Control, User and
This state of affairs has made it difficult to achieve Synchronization Plane (C/U/S-Plane)*7 specifications
interoperability between baseband processing equip- that, while conforming to the eCPRI*8 framework,
ment and radio equipment from different vendors prescribe detailed signal formats and equipment
(hereinafter referred to as multivendor RAN ). It operation required for multivendor RAN not pre-
has also been pointed out from many quarters that scribed in eCPRI specifications, and Management
wider frequency bandwidths in the 5G era and Plane (M-Plane)*9 specifications as well. These O-
higher antenna counts due to Massive Multiple In- RAN fronthaul specifications support both New
5
put Multiple Output (Massive MIMO)* schemes Radio (NR) and LTE as Radio Access Technology
are increasing the required fronthaul transmission (RAT)*10. In this article, we first introduce Split
bandwidth and making it excessively large [2]. Option 7-2x and then describe C/U/S-Plane and
The Open RAN (O-RAN) fronthaul specifications M-Plane specifications.
were formulated against this background and are
expected to help make multivendor RAN a reality
2. Split Option 7-2x
in the 5G era.
Furthermore, in the face of this bandwidth prob- Split Option 7-2x is a specification for functional
lem, O-RAN fronthaul specifications include a new splitting between O-RAN Distributed Unit (O-DU)
provision for functional splitting called Split Option and O-RAN Radio Unit (O-RU) adopted by O-RAN

*4 CPRI: Internal interface specification for radio base stations. *7 C/U/S-Plane: The C-Plane and U-Plane are protocols for trans-
CPRI is also the industry association regulating the specifica- ferring control signals and user data, respectively. The S-Plane
tion. is protocol for achieving synchronization between multiple units
*5 Massive MIMO: Large-scale MIMO using a very large num- of equipment.
ber of antenna elements. Since antenna elements can be min- *8 eCPRI: Internal interface specification for radio base stations
iaturized in the case of high frequency bands, Massive MIMO prescribed by CPRI, an industry association.
is expected to be useful in 5G. *9 M-Plane: The management plane handling maintenance and
*6 Layer 1: The first layer (physical layer) in the OSI reference monitoring signals.
model. *10 RAT: A radio access technology such as NR, LTE, 3G, GSM,
and Wi-Fi.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 47 ―
 Overview of O-RAN Fronthaul Specifications

fronthaul specifications. An overview of Split Op- the case of digital BF and after analog-signal con-
tion 7-2x is shown in Figure 2. version in the case of analog BF.
In the downlink (DL) process flow, the user bit In the DL, Split Option 7-2x implements func-
sequence received from the Medium Access Con- tions up to resource element mapping in the O-
11
trol (MAC) layer* undergoes encoding and scram- DU and supports both an O-RU that implements
12
bling* , modulation and layer mapping, and pre- digital BF and later functions (Category A O-RU)
NTT DOCOMO Technical Journal

13 14
coding* and resource element mapping* result- and an O-RU that implements the above in com-
15
ing in an IQ sampling sequence* of an Orthogo- bination with precoding (Category B O-RU). Here,
16
nal Frequency Division Multiplexing (OFDM)* Category A O-RU, which is easy to deploy, is ex-
17
signal in the frequency domain* . This sequence pected to be the O-RU implementation of choice in
is then subjected to Inverse Fast Fourier Trans- 5G initial deployment. On the fronthaul an IQ sam-
18
form (IFFT)* processing, converted to an OFDM pling sequence of the OFDM signal in the frequency
19
signal in the time domain* , and finally converted domain for each MIMO spatial stream (Category
to an analog signal. In this flow, Beam Forming A O-RU) or each MIMO layer (Category B O-RU)
20
(BF)* is performed before IFFT processing in will be transmitted. There is no need to transmit

DL (e.g. PDSCH) UL (e.g. PUSCH)

gNB
Encoding Decoding

Scrambling Descrambling RRC/SDAP

CU
Modulation Demodulation PDCP

Layer mapping Equalization RLC

IDFT
Precoding Channel estimation
MAC O-DU
Resource element Resource element
mapping demapping
PHY-High

Precoding*2 Split Option 7-2x

(transmits/receives IQ
Digital BF Digital BF sampling sequences
of OFDM signal in
frequency domain)
IFFT FFT

PHY-Low & RF O-RU

Analog conversion Digital conversion

Analog BF Analog BF

*1: Broken lines indicate optional functions

*2: No precoding in O-DU if performed in O-RU

Figure 2 Split Option 7-2x adopted in O-RAN fronthaul specifications

*11 MAC layer: One of the sublayers of Layer 2 providing proto- and NR.
cols for allocating radio resources, mapping data, and control- *15 IQ sampling sequence: A sampling sequence consisting of in-
ling retransmission. phase and quadrature components of a complex digital signal.
*12 Scrambling: Masking of a data block to be transmitted using a *16 OFDM: A digital modulation method where information is di-
specific bit sequence determined by the user or cell identifier. vided into multiple orthogonal carrier waves and sent in par-
*13 Precoding: A process for improving the quality of signal recep- allel making for high spectral efficiency in transmission.
tion by multiplying the signal before transmission with weights *17 Frequency domain: In signal analysis, this domain is used to
according to the condition of the radio propagation channel. show the frequency makeup of a signal s components. A fre-
*14 Resource element mapping: The mapping of an IQ sampling quency-domain signal can be converted to a time-domain sig-
sequence to time/frequency resources in LTE, LTE-Advanced, nal by an inverse Fourier transform.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 48 ―
 Overview of O-RAN Fronthaul Specifications

on the fronthaul an IQ sampling sequence for a flow, BF is performed after FFT processing in the
frequency resource transmitting no signals on the case of digital BF and before digital-signal conver-
DL wireless interface. sion in the case of analog BF.
Next, in the UpLink (UL) process flow, the OFDM In the UL, Split Option 7-2x implements resource
signal in the time domain received at the O-RU and element mapping and higher functions in the O-DU
converted to a digital signal is subjected to FFT and digital BF and lower functions in the O-RU.
NTT DOCOMO Technical Journal

processing resulting in an IQ sampling sequence The fronthaul transmits an IQ sampling sequence

of the OFDM signal in the frequency domain. Then, of the OFDM signal in the frequency domain for
21
after resource element demapping* , the process each MIMO spatial stream. There is no need to
flow continues with equalizing processing, Inverse transmit on the fronthaul an IQ sampling sequence
22
Discrete Fourier Transform (IDFT)* processing, for a frequency resource transmitting no signals on
and channel estimation, and after demodulation, the UL wireless interface.
23
descrambling* , and decoding, the process sends As shown in Figure 3, tradeoffs exist in the way
24
a user bit sequence* to the MAC layer. In this that functional splitting is performed between the

DL (e.g. PDSCH) UL (e.g. PUSCH)

Small Complex Difficult Difficult
MAC More functions in
O-RU
L1
Encoding Decoding

Scrambling Descrambling

Modulation Demodulation

Layer mapping
Equalization
IDFT
Channel estimation
Precoding

Resource element Resource element

mapping demapping

Digital BF Digital BF

IFFT FFT

RF More functions in Large Simple Easy Easy

Analog conversion Digital conversion O-DU
Required fronthaul RU implementation Ease of Ease of
bandwidth requirements function multivendor
Analog BF Analog BF
(processing, memory) extendibility interoperability

Figure 3 Tradeoffs in O-DU and O-RU functional splitting

*18 IFFT: A method for efficiently computing the time signal se- antennas.
ries corresponding to input frequency components (discrete *21 Resource element demapping: A process for extracting an IQ
data). signal sequence from an IQ signal mapped to time/frequency
*19 Time domain: In signal analysis, this domain is used to show resources in LTE, LTE-Advanced, and NR.
the temporal makeup of a signal s components. A time-domain *22 IDFT: An inverse discrete Fourier transform used to convert
signal can be converted to a frequency-domain signal by a discrete data in the frequency domain to discrete data in the
Fourier transform. time domain.
*20 BF: A technique for increasing or decreasing the gain of an- *23 Descrambling: Unmasking of a received data block using a
tennas in a specific direction by controlling the amplitude and specific bit sequence determined by the user or cell identifier.
phase of multiple antennas to form a directional pattern of the

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 49 ―
 Overview of O-RAN Fronthaul Specifications

O-DU and O-RU. In general, the required fronthaul not just the O-DU but the O-RU too must be up-
bandwidth becomes smaller as more functions be- graded.
come entrusted to the O-RU. For example, com- Moreover, when performing resource element
pared to CPRI in which the O-RU handles only mapping/demapping on the O-DU side, data will be
the RF function section, placing IFFT/FFT pro- transmitted after user multiplexing thereby sim-
cessing in the O-RU can prevent an increase in plifying control signals on the fronthaul and mak-
NTT DOCOMO Technical Journal

the fronthaul required bandwidth caused by over- ing it easier to achieve multivendor RAN. Split
sampling applied to the OFDM signal in the time Option 7-2x was adopted taking these tradeoffs in-
domain. Similarly, placing DL precoding in the O- to consideration.
RU can prevent an increase in the required fron-
thaul bandwidth that occurs when the number of
3. Overview of Fronthaul Interfaces
MIMO spatial streams is greater than the number
of MIMO layers. 3.1 Protocol Stacks
Furthermore, when the O-RU handles all Layer The protocol stack*26 of each plane in O-RAN
1 functions, the required fronthaul bandwidth is fronthaul specifications are shown in Figure 4.
25
essentially comparable to the baseband* bit rate. In the C/U-Plane, the O-RAN fronthaul specifi-
On the other hand, in that case, the amount of pro- cations support a protocol stack that transmits sig-
cessing and memory required of dispersed O-RUs nals used by eCPRI or Radio over Ethernet (RoE)*27
increases. Additionally, when making function mod- directly over Ethernet and an optional protocol stack
ifications and extensions, it is often the case that that transmits the signals over User Datagram

NETCONF

eCPRI/RoE SSH

UDP
TCP
(optional)

IP
PTP SyncE IP
(optional)

Ethernet L2 +
Ethernet L2 Ethernet L2 + VLAN
VLAN

Ethernet L1 Ethernet L1 Ethernet L1

C/U-Plane S-Plane M-Plane

Figure 4 Protocol stack of each plane

*24 User bit sequence: The baseband bit sequence of user data. *26 Protocol stack: Protocol hierarchy.
*25 Baseband: The units or functional blocks that perform digital *27 RoE: Internal interface specifications of a radio base station
signal processing. prescribed by IEEE.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 50 ―
 Overview of O-RAN Fronthaul Specifications

Protocol (UDP)*28/IP. mainly concerned with the data model portion of

In the S-Plane, meanwhile, the O-RAN fronthaul NETCONF that is targeted by operations and treat-
specifications support a protocol stack that transmits ed as a matter of implementation.
29
signals used in Precision Time Protocol (PTP)* and
SyncE*30 over Ethernet. 3.2 C/U-Plane
Finally, in the M-Plane, the O-RAN fronthaul 1) U-Plane
NTT DOCOMO Technical Journal

specifications support a protocol stack that transmits The frame format for a U-Plane message is shown
signals used in NETwork CONFiguration protocol in Figure 5. The eCPRI header contains information
(NETCONF) over Ethernet/IP/Transmission Con- such as message type (ecpriMessage), eCPRI pay-
31 32
trol Protocol (TCP)* /Secure SHell (SSH)* . load*34 size (ecpriPayload), message source and des-
NETCONF, which was formulated as RFC6241 tination identifiers (ecpriPcid), and message sequence
33
in the Internet Engineering Task Force (IETF)* , number (ecpriSeqid). The O-RAN fronthaul speci-
is a general-purpose protocol for managing network fications prescribe an extended Antenna-Carrier
devices. The O-RAN fronthaul specifications are (eAxC) as message source and destination identifiers.

8 bits
Message type, ecpriVersion ecpriReserved ecpriConcat.
transmission source ecpriMessage
eCPRI
and destination ecpriPayload (16 bits)
ecpriPcid (16 bits) header
identifiers, sequence
number ecpriSeqid (16 bits)
dataDirection payloadVersion filterIndex
Time resource frameId
information, etc. subframeId slotId
slotId symbolId
sectionId
Frequency resource sectionId rb symInc startPrbu
information, etc. startPrbu
numPrbu
udCompHdr
reserved
udCompParam eCPRI
iSample (1st RE in the PRB)
payload
qSample (1st RE in the PRB)
IQ compression ･･･
information, IQ iSample (12st RE in the PRB)
compression qSample (12st RE in the PRB)
parameter, and IQ udCompParam
iSample (1st RE in the PRB)
sampling sequence
qSample (1st RE in the PRB)
･･･
iSample (12st RE in the PRB)
qSample (12st RE in the PRB)
･･･

Figure 5 U-Plane message frame format

*28 UDP: A protocol on the transport layer featuring light pro- complements IP by providing functions for confirming the
cessing by virtue of performing no delivery confirmation, other party in the connection and data arrival, performing flow
congestion control, etc. It is used in communications for which control, and detecting data duplication or loss to achieve high-
a loss of data during transmission does not present a major ly reliable communication.
problem. *32 SSH: A protocol for achieving secure remote login and provid-
*29 PTP: A protocol for achieving high-accuracy time synchroni- ing network services.
zation among equipment connected to a network. *33 IETF: A standardization organization that develops and pro-
*30 SyncE: A system for transmitting clock signals on the Ether- motes standards for Internet technology. The technology speci-
net. fications formulated here are published as Request For Com-
*31 TCP: A standard Internet upper-layer protocol above IP. It ment documents (RFCs).

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 51 ―
 Overview of O-RAN Fronthaul Specifications

As shown in Figure 6, this eAxC consists of an O-DU compression parameter (udCompParam) for each
port IDentifier (DU_Port_ID), Band Sector IDentifier PRB (12 IQ samples). For example, when applying
35
(BandSector_ID), Component Carrier (CC)* IDenti- block floating point*41 as the compression scheme,
fier (CC_ID), and O-RU port IDentifier (RU_Port_ID). the IQ compression parameter and IQ sample se-
A specific MIMO spatial stream or MIMO layer is quence represent an exponent and mantissa, re-
identified on the basis of RU_Port_ID. spectively, in floating point form.
NTT DOCOMO Technical Journal

The eCPRI payload of the U-Plane message can In addition, the frame format of the U-Plane mes-
be used to transmit an IQ sample (iSample/qSample) sage is used in common in both directions, that is,
sequence of the OFDM signal in the frequency for transmission from the O-DU to O-RU and trans-
domain applying IQ compression and IQ compres- mission from the O-RU to O-DU.
sion information (udCompHdr). This information is 2) C-Plane
transmitted together with time/frequency resource The frame format for a C-Plane message is
information that should be applied to the trans- shown in Figure 7. The eCPRI header in a C-Plane
mission and reception of the IQ sample sequence message is the same as that of the U-Plane mes-
on the radio interface. Details of this eCPRI pay- sage. Here, the C-Plane message source and desti-
load information are provided in O-RAN fronthaul nation identifiers have become ecpriRtcid in contrast
specifications but not in eCPRI. Here, time resource to ecpriPcid of the U-Plane message. In O-RAN fron-
information consists of identification information thaul specifications, however, these identifiers are
36 37 38
for radio frame* , subframe* , slot* , and OFDM prescribed as an extended Antenna-Carrier (eAxC)
39
symbol* while frequency resource information con- the same as in the U-Plane message.
40
sists of the Physical Resource Block (PRB)* start The eCPRI payload of the C-Plane message
position and number of PRBs (startPRBu, numPRBu). passed from the O-DU to O-RU consists of information
The IQ compression information consists of the specifying BF weights to be applied when trans-
applied compression scheme and the number of bits mitting and receiving IQ sample sequences included
in the IQ sample after compression. Specifically, in the U-Plane message on the radio interface. It
IQ compression is performed using a common IQ also consists of time resource information (the same

8 bits

DU_Port_ID BandSector_ID

CC_ID RU_Port_ID

Figure 6 Example of eAxC

*34 Payload: The part of the transmitted data that needs to be *38 Slot: A unit for scheduling data consisting of multiple OFDM
sent, excluding headers and other overhead. symbols.
*35 CC: Term referring to one of several carriers bundled to- *39 OFDM symbol: A unit of transmission data consisting of mul-
gether to achieve CA (see *44). tiple subcarriers. A Cyclic Prefix (CP) is inserted at the front
*36 Radio frame: The smallest unit used for signal processing (en- of each symbol.
coding, decoding). A single radio frame is composed of multi- *40 PRB: A unit for allocating radio resources consisting of one
ple slots (or subframes) along the time axis, and each slot is subframe and 12 subcarriers.
composed of multiple symbols along the time axis.
*37 Subframe: A unit of radio resources in the time domain, con-
sisting of multiple slots.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 52 ―
 Overview of O-RAN Fronthaul Specifications

8 bits
Message type, ecpriVersion ecpriReserved ecpriConcat.
transmission source ecpriMessage
eCPRI
and destination ecpriPayload (16 bits)
ecpriRtcid (16 bits) header
identifiers, sequence
number ecpriSeqid (16 bits)
dataDirection payloadVersion filterIndex
Time resource frameId
information, etc. subframeId slotId
NTT DOCOMO Technical Journal

slotId symbolId
IQ compression numberOfsections
control information, sectionType
udCompHdr
etc.
reserved eCPRI
sectionId
payload
sectionId rb symInc startPrbc
Frequency resource startPrbc
information, etc. numPrbc
reMask
reMask numSymbol
Beam identifier, ef beamId
beamId
etc.
･･･

Figure 7 C-Plane message frame format (beam identifier)

as the U-Plane message) and frequency resource in- timing of the radio interface and retransmission
formation (startPRBc, numPRBc) to which the above timing of the Hybrid Automatic Repeat reQuest
BF weights are to be applied. The O-RU uses this (HARQ)*42 technique. This form of delay manage-
information to generate a beam for transmitting and ment adopts the concept of a receive window and
receiving signals on the radio interface. A number transmit window based on the eCPRI framework.
of options have been prescribed as information for Delay management for transmission from the O-
specifying BF weights, but in O-RAN fronthaul spec- DU to O-RU is shown in Figure 8. On receiving
ifications, support for an interface using a beam identi- the IQ sample sequence of the OFDM signal in the
fier (beamId) as shown in Fig. 7 is mandated. In frequency domain from the fronthaul, the O-RU
addition, this option using a beam identifier can be must complete certain processing (IFFT, analog
applied to digital BF, analog BF, or a combination conversion, BF, etc.) in time for transmitting the sig-
of the two (hybrid BF). nal on the radio interface given specific time re-
3) Delay Management sources (radio frame, subframe, slot, OFDM symbol).
Split Option 7-2x, which inserts a functional split For this reason, the position of the O-RU receive
between O-DU and O-RU within the physical layer window is set before transmission timing on the
of the radio interface, includes delay management radio interface at an offset corresponding to this
given the need to transmit C/U-Plane messages on O-RU processing delay. The O-DU, meanwhile, must
the fronthaul in accordance with transmit/receive transmit a C/U-Plane message to the fronthaul so

*41 Block floating point: A method used when expressing data in *42 HARQ: A technique that compensates for errors in received
floating point form that calculates each data block with a com- signals through a combination of error-correcting codes and
mon exponent instead of calculating each data item with a retransmission.
separate exponent.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 53 ―
 Overview of O-RAN Fronthaul Specifications

Total gNB transmission processing delay

O-DU transmit window

O-DU

O-DU
processing
NTT DOCOMO Technical Journal

delay

C/U-Plane message

O-RU
processing
delay
O-RU
Sym Sym
#0 #1 ･･･
O-RU receive window
Radio interface

Fronthaul delay

Figure 8 Delay management (transmission from O-DU to O-RU)

that it is delivered within the O-RU receive window. from O-RU to O-DU. Additionally, though omitted
Accordingly, the position of the O-DU transmit win- in Fig. 8, the fronthaul specifications define sepa-
dow is set before transmission timing to the radio rate windows for the C-Plane and U-Plane.
interface at an offset corresponding to O-RU pro-
cessing delay and fronthaul delay. Here, fronthaul 3.3 S-Plane
delay includes variable elements such as fronthaul In a C-RAN configuration, highly accurate syn-
distance and switch processing delay. The size of chronization between O-DU and O-RUs is required
the O-RU receive window is set to a length that to achieve linking control that assumes inter-O-RU
can cover this fluctuation in fronthaul delay and synchronization for Time Division Duplex (TDD)*43,
size of the O-DU transmit window. The size of the Carrier Aggregation (CA)*44 using multiple O-RUs,
O-DU transmit window is set taking into account MIMO, and other processes. As an S-Plane, O-RAN
the processing time required for the O-DU to trans- fronthaul specifications support protocols such as
mit the C/U-Plane message to the fronthaul. PTP and SyncE to achieve high-accuracy synchroni-
Delay management using the same type of win- zation on the O-RU side by synchronizing with the
dows is also applied for transmission in the direction clock on the high-performance O-DU side.

*43 TDD: A bidirectional transmit/receive system. It achieves bi-

directional communication by allocating different time slots to
uplink and downlink transmissions that use the same frequency
band.
*44 CA: A technology that expands bandwidth and achieves high-
speed transmission by performing simultaneous transmission
and reception on multiple component carriers.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 54 ―
 Overview of O-RAN Fronthaul Specifications

3.4 M-Plane of a subordinate O-RU, which makes it un-

The M-Plane provides a variety of O-RU man- necessary for NMS to handle the monitor-
agement functions to set parameters on the O-RU ing/control of all O-RUs and helps reduce
side as required by the C/U-Plane and S-Plane de- the NMS processing load. Furthermore, in
scribed above, to manage O-RU software (SW), per- the event that the existing NMS does not
form fault management, etc. In this regard, O-RAN yet support NETCONF, this model has the
NTT DOCOMO Technical Journal

fronthaul specifications prescribe various parame- advantage of enabling network construction

ters as data models to achieve the above. This elim- without affecting the existing system since
inates dependence on each O-RU vendor s imple- O-DU supports NETCONF in this M-Plane.
mentation and makes multivendor RAN possible. (b) Hybrid model: In this configuration, an O-RU
The functions supported by the M-Plane are is managed by one or more NMSs in addi-
listed in Table 1. tion to O-DUs. An advantage of this model is
1) M-Plane Architecture that NMSs can monitor/control other net-
In the M-Plane, the O-DU and Network Man- work devices in addition to O-RUs enabling
45
agement System (NMS)* are specified as network uniform maintenance, monitoring, and con-
devices managing O-RUs. In NETCONF, moreover, trol of all equipment.
network devices managing O-RUs correspond to
NETCONF clients while O-RUs targeted for man- In either architectural model, management func-
agement correspond to NETCONF servers. tions can be limited for each NETCONF client man-
The following two models are supported as M- aging an O-RU making for flexible operation. For
Plane architecture (Figure 9). example, operations can be divided into a NETCONF
(a) Hierarchical model: In this configuration, an client performing SW management and a NETCONF
O-RU is managed by one or more O-DUs. client performing fault management.
These O-DUs terminate the monitoring/control

Table 1 Overview of M-Plane functions

Function name Description

“Start up”installation M-Plane startup procedure

SW management O-RU SW management

Configuration management O-RU parameter set/get

Performance management Management of O-RU measurement items

Fault management O-RU fault management

File management Send/receive data files to/from O-RU

*45 NMS: Generic name for a system or function performing man-

agement tasks in a network.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 55 ―
 Overview of O-RAN Fronthaul Specifications

NMS
NMS
NMS

1…N

O-DU
lls-CU O-DU
lls-CU
lls-CU lls-CU

1…N 1…N
NTT DOCOMO Technical Journal

1 1
1
O-RU O-RU

(a) Hierarchical model (b) Hybrid model

Figure 9 Architecture supporting M-Plane

2) M-Plane Functions nance personnel set Transport Layer address-

(a) Start up installation es beforehand, support is also provided for
Start up installation specifies the estab- a plug-and-play method of address resolu-
lishment of M-Plane connections between O- tion using a DHCP server, SLAAC, etc.
RU and NETCONF clients such as O-DU and (b) SW management
NMS. Establishing these connections on the An O-DU/NMS NETCONF client performs
M-Plane requires mutual exchange of Transport O-RU SW management via the M-Plane. In
46
Layer address* information. multivendor RAN, a NETCONF client of a
For this function, O-RAN fronthaul spec- certain vendor must manage the SW files of
ifications prescribe the following three options. an O-RU heavily dependent on another ven-
• Manual setting of Transport Layer ad- dor s implementation, so a mechanism of
dresses SW management that is independent of O-
• Allocation of Transport Layer addresses RU-implementation or vendor is important.
by a Dynamic Host Configuration Proto- The main SW management procedure is
47
col (DHCP)* server as follows:
• Allocation of Transport Layer addresses (1) SW inventory
by StateLess Address Auto-Configuration (2) SW download
48
(SLAAC)* (when supporting IPv6) (3) SW installation
(4) SW activation
In addition to the option of having mainte-

*46 Transport Layer address: Information such as an IP address

required for establishing a connection on the Transport Layer.
*47 DHCP: A protocol used for automatically allocating information
(e.g., IP addresses) to computers connected to networks.
*48 SLAAC: In IPv6, a protocol for automatically allocating infor-
mation (e.g., IPv6 addresses) to computers connected to net-
works.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 56 ―
 Overview of O-RAN Fronthaul Specifications

To begin with, the NETCONF client must Depending on the manifest file formats spec-
get hold of the O-RU SW package provided ified in O-RAN fronthaul specifications, it is
by the O-RU vendor. In addition to the SW sufficient for the NETCONF client to com-
files needed for actual O-RU operation, this pare only build-name/version and file-name/
package should include a manifest file indi- version information̶there is no need to
cating which SW files should be installed in compare actual SW files dependent on the
NTT DOCOMO Technical Journal

each O-RU. Such a manifest file is essential O-RU implementation. This enables SW man-
to achieving multivendor RAN. agement by NETCONF clients from differ-
The operation sequence is shown in ent vendors. Continuing on, the management
Figure 10. First, in the SW inventory step, process instructs that the required SW files
the NETCONF client gets information on be downloaded to the O-RU and that those
what types of files are currently stored on files be installed once the download completes.
the O-RU. This inventory information is com- Finally, once installation completes, the pro-
pared with build-name/version and file-name/ cess instructs that the SW files to be used
version information in the manifest file so that at the next boot be activated.
the NETCONF client can determine whether (c) Configuration management
a download to the O-RU is necessary, and if so, In this function, an O-DU/NMS NETCONF
which files should be designated for download. client sets O-RU parameters required on the

O-DU/NMS O-RU

SW inventory
(get O-RU SW information)

Compare with manifest file and

determine need for SW updates
on O-RU

SW download
(instruct SW download to O-RU)

SW installation
(instruct SW install on O-RU)

SW activation
(instruct SW activation on O-RU)

Figure 10 SW management

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 57 ―
 Overview of O-RAN Fronthaul Specifications

C/U-Plane and S-Plane and gets equipment • Locations affected by fault

status information via the M-Plane. This func- • Severity of fault
tion is achieved using standard messages spec- • New fault occurrence or a fault that has
ified in NETCONF. The setting of required already been resolved
parameters is specified in the form of YANG
modules and achieved in the following way. 3.5 Fronthaul Network Topologies
NTT DOCOMO Technical Journal

49
In NETCONF, establishing a session* Taking into account limitations on the number
is accompanied by an exchange of <hello> of physical lines between O-DU and O-RU, there may
messages. Each of these messages contains be cases when the fronthaul needs to take on net-
the NETCONF functions supported by that work topologies other than point-to-point (Figure 11 (a))
equipment and information on supported such as those using a Layer 2 switch*50. The C/U/S-
YANG modules. This enables the O-DU/NMS Plane and M-Plane described above supports such
NETCONF client to determine what YANG network topologies as shown by the following ex-
modules are supported by the O-RU. NETCONF amples (Fig. 11 (b)).
specifies <edit-config> and <get-config> as For example, case (1) in the figure depicts a to-
standard messages for setting parameters pology in which the number of fronthaul lines can
and getting parameter values, respectively. be different in each interval. This topology can be
Sending these messages to an O-RU makes used to increase the fronthaul transmission capac-
it possible to set various types of parame- ity without having to increase the capacity per port
ters and to get information on the parame- of the O-DU and O-RU by simply increasing the
ters stored on the O-RU and the status of number of ports each having the standard amount
that equipment. of capacity. In addition, this topology allows for only
(d) Fault management one line to be used between L2 switches, which can
An NETCONF client manages O-RU faults help keep line costs down.
via the M-Plane. In this function, the O-RU sends Next, case (2) in the figure depicts a topology
a notification to the O-DU/NMS NETCONF that gives redundancy to the fronthaul path be-
client using <notification> specified as a stand- tween O-DU and O-RU. If either of the paths shown
ard message in NETCONF. In the event of fails, this topology enables services to be continued
some sort of problem on the O-RU side such via equipment using the other path.
as an equipment fault, the O-RU notifies the Finally, case (3) in the figure depicts a topology
NETCONF client of the fault together with that enables many O-RUs to be simultaneously con-
the following detailed information. nected by using the switch as a hub even if the
• ID number of physical ports on the O-DU should be
• Location of fault occurrence limited.

*49 Session: A series of communications exchanged between a *50 Layer 2 switch: A network device that assesses the MAC ad-
client and server. dress included in a packet and relays that packet accordingly.

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 58 ―
 Overview of O-RAN Fronthaul Specifications

25 Gbps O-RU
25 Gbps
100 Gbps
25 Gbps 25 Gbps O-RU
O-DU L2 switch L2 switch
25 Gbps 25 Gbps
O-RU
25 Gbps
25 Gbps
O-RU Case (1) O-RU
NTT DOCOMO Technical Journal

O-RU
O-RU
O-DU
O-DU Path switching
O-RU L2 switch Path fails

Case (2) O-RU

O-RU
O-RU
Port

O-RU
O-DU
L2 switch
O-RU

Case (3) O-RU

(a) Point-to-Point (b) L2 switch

Figure 11 Examples of fronthaul topologies

achieving interoperability in a multivendor environ-

4. Conclusion
ment).
This article introduced Split Option 7-2x adopted
in O-RAN fronthaul specifications and described REFERENCES
[1] S. Abeta et al.: LTE-Advanced as Further Evolution of
the C/U/S-Plane and M-Plane prescribed in the
LTE for Smart Life, NTT DOCOMO Technical Jour-
same specifications. Going forward, the O-RAN Al- nal, Vol.17, No.2, pp.4‒9, Oct. 2015.
liance will continue to promote genuine multiven- https://www.nttdocomo.co.jp/english/binary/pdf/corporate/
dor RAN using O-RAN fronthaul specifications and technology/rd/technical_journal/bn/vol17_2/vol17_2_000en.
pdf#page=5
to make useful extensions to those specifications.
[2] A. Umesh et al.: 5G Radio Access Network Standardiza-
For its part, NTT DOCOMO will continue to sup-
tion Trends, NTT DOCOMO Technical Journal, Vol.19,
port the activities of the O-RAN Alliance such as No.3, pp.36‒47, Jan. 2018.
by drafting a multivendor RAN profile (compilation https://www.nttdocomo.co.jp/english/binary/pdf/corporate/

of fronthaul topologies, parameter settings, etc. for technology/rd/technical_journal/bn/vol19_3/vol19_3_005en.pdf

NTT DOCOMO Technical Journal Vol. 21 No. 1 (Jul. 2019)

― 59 ―