eCPRI Specification V2.0 (2019-05-10)
Interface Specification

Common Public Radio Interface:eCPRI Interface Specification

The eCPRI specification has been developed by Ericsson AB, Huawei Technologies Co. Ltd, NEC Corporation and Nokia (the “Parties”) and may
be updated from time to time. Further information about eCPRI, and the latest specification, may be found at http://www.cpri.info
BY USING THE eCPRI SPECIFICATION, YOU ACCEPT THE “Interface Specification Download Terms and Conditions” FOUND AT
http://www.cpri.info/spec.html
IN ORDER TO AVOID ANY DOUBT, BY DOWNLOADING AND/OR USING THE ECPRI SPECIFICATION NO EXPRESS OR IMPLIED
LICENSE AND/OR ANY OTHER RIGHTS WHATSOEVER ARE GRANTED FROM ANYBODY.
© 2019 Ericsson AB, Huawei Technologies Co. Ltd, NEC Corporation and Nokia.

2

eCPRI Specification V2.0 (2019-05-10)

1

Table of Contents

2

1.

Introduction................................................................................................................. 4

3
4
5
6
7

2.

System Description .................................................................................................... 6
2.1.
Definitions/Nomenclature ............................................................................. 6
2.2.
System Architecture ..................................................................................... 8
2.3.
Functional Description ................................................................................. 9
2.3.1. Functional Decomposition ............................................................... 10

8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

3.

Interface Specification.............................................................................................. 11
3.1.
Protocol Overview ....................................................................................... 11
3.1.1. Physical Layer ................................................................................. 13
3.2.
User Plane ................................................................................................... 13
3.2.1. User Plane over Ethernet ................................................................ 13
3.2.2. User Plane over IP .......................................................................... 14
3.2.3. eCPRI Message Format .................................................................. 14
3.2.3.1.
eCPRI Transmission Byte Order ............................... 15
3.2.3.2.
Common Header ...................................................... 15
3.2.3.3.
eCPRI Payload ......................................................... 16
3.2.3.4.
Mapping Examples ................................................... 16
3.2.4. Message Types ............................................................................... 17
3.2.4.1.
Message Type #0: IQ Data ....................................... 17
3.2.4.2.
Message Type #1: Bit Sequence .............................. 19
3.2.4.3.
Message Type #2: Real-Time Control Data .............. 21
3.2.4.4.
Message Type #3: Generic Data Transfer ................ 22
3.2.4.5.
Message Type #4: Remote Memory Access ............. 24
3.2.4.6.
Message Type #5: One-Way Delay Measurement .... 28
3.2.4.7.
Message Type #6: Remote Reset ............................. 34
3.2.4.8.
Message Type #7: Event Indication .......................... 36
3.2.4.9.
Message Type #8: IWF Start-Up ............................... 41
3.2.4.10.
Message Type #9: IWF Operation ............................ 43
3.2.4.11.
Message Type #10: IWF Mapping ............................ 51
3.2.4.12.
Message Type #11: IWF Delay Control .................... 56
3.2.4.13.
Message Type #12 - #63: Reserved ......................... 57
3.2.4.14.
Message Type #64 - #255: Vendor Specific.............. 57
3.3.
C&M Plane ................................................................................................... 57
3.4.
Synchronization Plane ................................................................................ 58
3.5.
QoS .............................................................................................................. 58
3.5.1. VLAN Tagging for Ethernet-switched fronthaul networks ................. 58
3.5.2. QoS for IP-routed fronthaul networks .............................................. 58

39
40
41
42
43

4.

Forward and Backward Compatibility ..................................................................... 59
4.1.
Fixing eCPRI Protocol Revision Position .................................................. 59
4.2.
Reserved Bits and Value Ranges within eCPRI ........................................ 59
4.3.
eCPRI specification release version .......................................................... 59
4.4.
Specification release version mapping to eCPRI protocol revision ........ 59

44

5.

Compliance ............................................................................................................... 61

45
46
47
48
49
50

6.

Annex A - Supplementary Specification Details (Informative) .............................. 62
6.1.
Functional Decomposition ......................................................................... 62
6.1.1. eCPRI Functional Decomposition .................................................... 62
6.1.2. Bit Rate Calculations / Estimations .................................................. 64
6.1.2.1.
Bit Rate Calculation Example.................................... 64
6.2.
Synchronization and Timing ...................................................................... 65

CPRI

3

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

6.3.

6.4.
6.5.

6.6.
6.7.
6.8.

eCPRI Specification V2.0 (2019-05-10)

6.2.1. Synchronization of eRE ................................................................... 65
6.2.2. Synchronization of eREC................................................................. 65
6.2.3. Synchronization of IWFs .................................................................. 65
Link Delay Management ............................................................................. 65
6.3.1. Reference Points for Delay Measurement ....................................... 66
6.3.2. Delay Management example ........................................................... 70
Network Connection Maintenance ............................................................. 72
Networking .................................................................................................. 73
6.5.1. Difference between eCPRI and CPRI .............................................. 73
6.5.2. eCPRI/CPRI networking with eCPRI/CPRI IWF type 0 .................... 74
6.5.3. eCPRI/CPRI networking with eCPRI/CPRI IWF type 1 and type 2... 75
Priority considerations ............................................................................... 76
Message Ordering Considerations ............................................................ 76
Security........................................................................................................ 77
6.8.1. eCPRI Network Security Protocol .................................................... 77
6.8.2. eCPRI Network Security Specification ............................................. 77
6.8.2.1.
User plane ................................................................ 77
6.8.2.2.
C&M plane ................................................................ 77
6.8.2.3.
Synchronization plane............................................... 77

20
21
22
23
24
25
26

7.

Annex B – eCPRI/CPRI Interworking with IWF type 0 (Informative) ...................... 78
7.1.
Concept ....................................................................................................... 80
7.2.
Bridging of User Plane................................................................................ 81
7.3.
Bridging/Routing of C&M Plane ................................................................. 82
7.4.
Bridging of Synchronization Plane ............................................................ 83
7.5.
Bridging of L1 inband protocol .................................................................. 83
7.6.
Start-up Sequence ...................................................................................... 84

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

8.

Annex C – eCPRI/CPRI Interworking with IWF type 1 and type 2 .......................... 85
8.1.
Concept ....................................................................................................... 85
8.2.
Definition of IWF type 1 and IWF type 2 CPRI ports ................................. 85
8.3.
Bridging of User Plane................................................................................ 86
8.4.
Bridging/Routing of CPRI Control Words.................................................. 86
8.5.
Bridging of Synchronization Plane ............................................................ 86
8.6.
Bridging/handling of CPRI sub-channels 0 and 2 ..................................... 87
8.7.
Start-up Sequence ...................................................................................... 87
8.7.1. eCPRI/CPRI IWF Start-up sequence overview ................................ 87
8.7.2. Start-up Delay Management ............................................................ 88
8.7.3. IWF CPRI port start-up sequence .................................................... 90
8.7.3.1.
General..................................................................... 90
8.7.3.2.
Layer 1 Start-up Timer .............................................. 90
8.7.3.3.
State Description ...................................................... 91
8.7.3.4.
Transition Description ............................................... 95
8.8.
Synchronization .......................................................................................... 97
8.9.
Delay Management ...................................................................................... 97
8.10.
Handling of eCPRI Remote Reset and CPRI Reset ................................. 100
8.11.
Link and Fault Management ..................................................................... 100
8.11.1. IWF CPRI transmitter fault recovery/actions for CPRI detectedfaults ............................................................................................. 102
8.11.2. IWF CPRI transmitter fault recovery/actions for Ethernet detectedfaults ............................................................................................. 102

50

9.

List of Abbreviations .............................................................................................. 104

51

10.

References .............................................................................................................. 107

52
53

11.

History ..................................................................................................................... 108

CPRI

4

eCPRI Specification V2.0 (2019-05-10)

1

1. Introduction

2
3
4
5
6

The Common Public Radio Interface (CPRI) is an industry cooperation aimed at defining publicly available
specifications for the key internal interface of radio base stations, such as eCPRI connecting the eCPRI
Radio Equipment Control (eREC) and the eCPRI Radio Equipment (eRE) via a so-called fronthaul transport
network. The parties cooperating to define the specification are Ericsson AB, Huawei Technologies Co. Ltd,NEC Corporation and Nokia.

78

Motivation for eCPRI:

9
10

Compared to CPRI [1], eCPRI makes it possible to decrease the data rate demands between eREC andeRE via a flexible functional decomposition while limiting the complexity of the eRE.

11
12

Scope of Specification:

13
14

The necessary items for transport, connectivity and control are included in the specification. This includes
User Plane data, Control and Management Plane transport mechanisms, and means for synchronization.

15
16
17

The eCPRI specification supports 5G and enables increased efficiency in order to meet the needs foreseenfor 5G Mobile Networks. In contrast to CPRI, the eCPRI specification supports more flexibility in thepositioning of the functional split inside the Physical Layer of the cellular base station.

18
19
20

The scope of the eCPRI specification is to enable efficient and flexible radio data transmission via a packet
based fronthaul transport network like IP or Ethernet. eCPRI defines a protocol layer which provides various- mainly User Plane data specific - services to the upper layers of the protocol stack.

21

The specification has the following scope (see Figure 1, Figure 1A and Figure 1B):

22
23
24

1.

The internal radio base station interface establishing a connection between “eCPRI Radio Equipment
Control” (eREC) and “eCPRI Radio Equipment” (eRE) via a packet based transport network is
specified.

25
26

2.

Three different information flows (eCPRI User Plane data, C&M Plane data, and Synchronization
Plane data) are transported over the interface.

27
28

3.

The specification defines a new eCPRI Layer above the Transport Network Layer. Existing standards
are used for the transport network layer, C&M and Synchronization.

29
eCPRI Radio Equipment Control (eREC)

eCPRI Radio Equipment (eRE)User Plane

Sync

C&M

User Plane

Sync

C&M

SAPU

SAPS

SAPCM

SAPU

SAPS

SAPCM

eCPRI
specificStandard
Protocols

Transport Network Layer

eCPRI
specific
Transport Network

Standard
Protocols

Transport Network Layer

30
31

Figure 1: System and Interface Definition

32
33

The eCPRI interface can also be used between two eRECs or between two eREs as well as with
Interworking Function(s) (IWF) located between the eCPRI transport network and one/several CPRI node(s).

34
35
36

In Figure 1A the Interworking Function is located between the eCPRI transport network and one/several
CPRI RE node(s). The SAPs shall be terminated at both eCPRI and CPRI ends and bridged to each othervia vendor specific functionality. For this configuration IWF type 0 is used.

CPRI

5

1
2
3

eCPRI Specification V2.0 (2019-05-10)

In Figure 1B the Interworking Functions are located between the respective CPRI nodes and the transport
network. The Interworking Functions bridge the CPRI link over the Fronthaul Transport Network. For thisconfiguration IWF type 1 and type 2 are used.

4
CPRI Radio Equipment Control (eREC)

eCPRI/CPRI Interworking Function type 0

CPRI Radio Equipment (RE)

IWF

User
Plane

Sync

C&M

SAPU

SAPS

SAPCM

eCPRI
specific

User Plane Sync
SAPU
eCPRI
specificStandard
Protocols
Transport
Network

Transport Network Layer

5
6
7

SAPS

C&M
SAPCM

Standard
Protocols

Transport Network Layer

User Plane Sync
SAPIQ

SAPS

User
Plane

Sync

C&M

SAPIQ

SAPS

SAPCM

C&M
SAPCM

Layer 2

Layer 2

Layer 1

Layer 1Figure 1A: System and Interface Definition with eCPRI/CPRI IWF type 0

8
CPRI Radio Equipment Control (REC)

CPRI Radio Equipment (RE)User Plane

Sync

C&M

User Plane

Sync

C&M

SAPIQ

SAPS

SAPCM

SAPIQ

SAPS

SAPCM

Layer 2
Layer 1

Layer 2

IWF
type 1

Transport Network

IWF
type 2

Layer 19
10
11

Figure 1B: System and Interface Definition with eCPRI/CPRI IWF type 1 and type 2

12

CPRI

6

eCPRI Specification V2.0 (2019-05-10)

1

2. System Description2
3
4This section describes the eCPRI related parts of the basic radio base station system architecture anddefines the mapping of the functions to the different nodes. Furthermore, the reference configurations andthe basic nomenclature used in the following sections are defined.

5
6

The following description is based on the Evolved UMTS Terrestrial Radio Access (E-UTRA) and 5G (NR).
However, the interface may also be used for other radio standards.

7

2.1. Definitions/Nomenclature

8This section provides the basic nomenclature that is used in the following sections.

910

eCPRI node:

11
12
13
14

The radio base station system is composed of two basic eCPRI nodes, the eCPRI Radio Equipment Control
and the eCPRI Radio Equipment (see Figure 1). The eCPRI Radio Equipment Control and the eCPRI Radio
Equipment are described in the following chapter. The radio base station system shall contain at least two
eCPRI nodes, at least one of each type: eREC and eRE.

15

eREC / eRE element:

16

A hardware or software component within an eCPRI node which alone does not constitute a full eCPRI node.

17

Protocol planes:

18

The following planes are outlined:

19
20

C&M Plane:

Control and Management data flow for the operation, administration andmaintenance of the nodes.

21

User Plane:

Three data flows covered by the User Plane:

2223a) Data flow to be transferred from the radio base station to the User
Equipment (UE) and vice versa.

24b) Real time control data related to a).

25c) Other eCPRI flows not covered by other protocol planes/flows.

26

Synchronization Plane:

Data flow for synchronization and timing information between nodes.

27

eCPRI Protocol Layer:

28

A Protocol Layer defined by this specification and providing specific services to the upper layers.

29Service Access Points:

30
31
32

For all protocol planes except Connection OAM, service access points are defined. These service accesspoints are denoted as SAPCM, SAPS and SAPU as illustrated in Figure 1. A service access point is defined ona per logical connection basis.

33

Logical connection:

34

A “logical connection” defines the interconnection between SAPs (e.g., SAPU) across peered eCPRI nodes.

35

Grandmaster Clock (GM):36
37

Reference clock of a Precision Time Protocol-based Transport network. The GM can be located in the
network as well as in the eREC or eRE.

38

Downlink:

39

Direction from eNB/gNB to UE.

40

Uplink:41

Direction from UE to eNB/gNB.

CPRI

7

eCPRI Specification V2.0 (2019-05-10)1Service:23

Method to access one or more functionalities via the eCPRI protocol. This method typically involves thetransmission/reception of eCPRI messages.

4

Figure 2 illustrates basic definitions related to service access points.

5
SAPS

Logical Connection for Synchronization (eRECóeRE)

SAPS

SAPCM

Logical Connection for C&M data (eRECóeRE)

SAPCM

SAPU

Logical Connection for User Plane data (eRECóeRE)SAPU

Transport Network

eREC

eRE

Link

SAPS
SAPCM
SAPU

6
7

Figure 2: Illustration of basic definitions

8

eCPRI/CPRI Interworking Function (IWF):

9
10

A function providing a bridge between eCPRI and CPRI nodes. The protocol for both eCPRI and CPRI shallbe terminated within the IWF and bridged to/from each other. Three types of IWF are defined:

11

Type 0:

12
13
14
15
16

Used in an “eREC  Fronthaul  IWF type 0  RE” configuration.
Type 1:
Used in an “REC  IWF type 1  Fronthaul  IWF type 2  RE” configuration, connected to an
REC.
Type 2:17

Used in an “REC  IWF type 1  Fronthaul  IWF type 2  RE” configuration, connected to an RE.

18

Interworking Function type 0 is described in sections 6.5.2 and 7, and types 1 and 2 in sections 6.5.3 and 8.

19

CPRI master port for IWF type 0:

20
21
22

The “CPRI master port for IWF type 0” is fully equivalent to “CPRI master port” described in section 2.1 of the
CPRI specification [1] and shall comply with all requirements for CPRI master ports stated in the CPRI
specification [1].

23

CPRI slave port for IWF type 1:

24
25
26
27
28

The “CPRI slave port for IWF type 1” is connected to and interacts with a “CPRI master port” and behaves asa “CPRI slave port” when IWF type 1 and 2 are configured as described in this eCPRI specification.
However, the configuration and function of the “CPRI slave port for IWF type 1” itself is not equivalent to a
“CPRI slave port” and may not behave as a “CPRI slave port” unless operating in conjunction with the IWF
type 2 and RE.

29

CPRI master port for IWF type 2:

30
31

The “CPRI master port for IWF type 2” is connected to and interacts with a “CPRI slave port” and behaves asa “CPRI master port” when IWF type 1 and 2 are configured as described in this eCPRI specification.

CPRI

8

eCPRI Specification V2.0 (2019-05-10)

12
3

However, the configuration and function of the “CPRI master port for IWF type 2” itself is not equivalent to a
“CPRI master port” and may not behave as a “CPRI master port” unless operating in conjunction IWF type 1
and REC.

42.2. System Architecture

5
6
7
8
9
10
11

Radio base stations should offer deployment flexibility to mobile network operators, i.e., in addition to an allin-one radio base station, more flexible radio base station system architectures involving remote radio
equipment shall be supported. This may be achieved by a decomposition of the radio base station into twobasic building blocks, the so-called eCPRI Radio Equipment Control (eREC) and the eCPRI Radio
Equipment (eRE). Both parts may be physically separated (i.e., the eRE may be close to the antenna,
whereas the eREC is generally located in a conveniently accessible site) and connected via a transport
network.

12
13
14
15

Typically, the eREC contains part of the PHY layer functions and higher layer functions of the air interface,whereas the eRE contains the other part of the PHY layer functions and the analog radio frequency
functions. The basic idea of the functional split between both parts is described in section 2.3.1. Several
examples of functional splits are described in informative Annex 6.1.

16
17
18

User Plane data (i.e. information flows between split PHY layer functions in eREC and eRE and their realtime control), control and management and synchronization signals are packetized, multiplexed andtransferred over the transport network (fronthaul network) which eREC(s) and eRE(s) are connected to.

19
20
21
22

eCPRI does not constrain the use of network-layer and data link-layer protocols to form the network, so any
type of network can be used for eCPRI provided eCPRI requirements (defined in [15]) are fulfilled. eCPRI
also uses existing de-facto/de-jure standard protocols as much as possible where available. The basic idea
is illustrated in Figure 1.

23
24
25
26

Figure 3 shows an example of a system architecture with local eCPRI. eCPRI is used as an internal interface
within the eREC and/or eRE (local eCPRI) when the eREC/eRE consists of multiple eREC/eRE elements. In
addition, eCPRI and CPRI can coexist in a system. Please note that eCPRI has no backward compatibility
with CPRI.

eREC
eREC
eREC
element element

REC

IWF
eREC

PTP
GM

type 1eREC
element

local network

Transport Network

eRE

eRE

IWF
type 0

IWF

local network

type 227
28
29

eCPRI link
Local eCPRI
CPRI link

RE

eRE
eRE
element element

RE

eRE
element

Figure 3: System Architecture example with local eCPRI and IWF types 0, 1 and 2

CPRI

9

eCPRI Specification V2.0 (2019-05-10)

1
2
3
4

The eCPRI/CPRI Interworking Functions type 0, 1 and 2 are also illustrated in Figure 3. IWF type 0 allows
connection of an RE as if it was an eRE (from the eREC viewpoint). Similarly, it provides REC functionality(from the RE viewpoint). IWF types 1 and 2 combined provide a logical connection between REC and RE
nodes.

5

2.3. Functional Description

6
7
8
9
10
11

This section provides a description of the functional content of an eNB/gNB. The CPRI concept of a radio
base station divided into two nodes, one called REC (Radio Equipment Control) and the other called RE(Radio Equipment) is still valid for eCPRI but with the small change of renaming the two nodes to eREC andto eRE. The functional split across these two nodes can be outlined more flexibly than in the CPRI
specification. The functional content of an eNB/gNB (eREC and eRE) is listed in Table 1, references tocorresponding 3GPP Technical Specifications are included in the table.

12

Table 1: Functional content of eNB/gNB
Functions and Protocol Stack of eNB/gNB
eREC + eRE

3GPP eNB Reference
TS 36.nnn [2]3GPP gNB Reference
TS 38.nnn [3]Radio Base Station Control & Management--

Backhaul transport--

RRC (Radio Resource Control)

331

331

PDCP (Packet Data Convergence Protocol)

323

323

RLC (Radio Link Control)

322

322

MAC (Medium Access Control)

321

321

PHY (Physical)

201(General description)

201(General description)

RF (Radio Functions)

104

104, 133

Measurements

214, 314

215

13
14

eREC

Fronthaul
NetworkeRE

eNB / gNB
15
16

Figure 4: Fronthaul Network definition

17
18

Regardless of which functional decomposition between eREC and eRE is selected for a specificimplementation, the “Fronthaul Network” is the interface between the two eCPRI nodes eREC and eRE.

19
20
21
22
23

The different functions listed in Table 1 can be located either in the eREC or in the eRE. When using eCPRI
for either existing or forthcoming radio standards such as the 3GPP 5G (NR) the functional decomposition
between eREC and eRE depends on vendor specific choices. Different implementations will be targeting
different objectives (radio performance, fronthaul performance adaptions, feature necessity circumstancesetc.) leading to a different functional decomposition between eREC and eRE.

24

CPRI

10

eCPRI Specification V2.0 (2019-05-10)1

2.3.1.

2
3
4

Figure 5 shows the protocol stack layers for a 3GPP 4G (LTE) or 5G (NR) radio base station. Five inter-layer
functional splits numbered A to E are depicted in the figure. One additional set of intra-PHY splits named“{I ;II ;I }” is also shown. For more details of the intra-PHY splits refer to section 6.1.1.
D

D

Functional Decomposition

U

Split A

Split B

RRC

PDCP

Split C

RLC

Split E

Split D

PHY

MAC

RF

Split {ID;IID;IU}

Data

eNB/gNB

eRE
5

eREC

6

Figure 5: Functional decomposition on RAN layer level

7
8
9
10
11
12
13

As shown in Figure 5 the eNB/gNB consists of only two units: the eREC and the eRE. For some of the splits
an implementation with only two nodes may not be realistic. For instance, Split A with a central RRC and a
distributed unit containing the rest of the protocol stack would not support a number of features (such as
those requiring cell-coordination) efficiently. eCPRI assumes that the eNB/gNB consists of eREC and eRE(s)only and thus the following text should be read with this in mind. The intra PHY Split is marked with a redline, this is just an example showing how the figure shall be interpreted, the blue and yellow colored areas ina eNB/gNB show what parts are located in eREC and eRE.

14

The CPRI specification [1] functional decomposition-split for E-UTRA corresponds to split E.

15
16
17

The advantages of the intra-PHY-split are: features such as Carrier Aggregation, Network MIMO, Downlink
CoMP, Uplink L1 Comp Joint Processing can be efficiently supported. Some of these features might ofcourse be supported by other splits as well.

18
19

Some disadvantages of the intra-PHY-split are: A fronthaul network with “higher” capacity and “lower” latency
is required compared to higher layer splits.

20
21

Table 2 shows how different splits will set different relative capacity- and latency-requirements on thefronthaul network.

22

Table 2: Fronthaul requirements vs. splits
Split

Fronthaul capacity
needs

Fronthaul latency
requirement

A

Low,
Scales with # MIMO layers

RelaxedB

Low,
Scales with # MIMO layers

RelaxedC

Low,
Scales with # MIMO layers

RelaxedD

Low,
Scales with # MIMO layers

Very Strict

E

Very High,
Scales with # antenna ports

Very Strict

See section 6.1.1

Very Strict{I ;II ;I }
D

D

U

CPRI

11

1

3. Interface Specification

2

3.1. Protocol Overview

3

The eCPRI interface includes the following information flows:

eCPRI Specification V2.0 (2019-05-10)

4

1. User Plane:

5
6
7
8

o

User Data:
User information (to be transmitted from/to the base station to/from the user equipment)with format depending on the underlying functional decomposition between the eREC andthe eRE.

910oReal-Time Control data:
Time-critical control and management information directly related to the User Data.

11
12

o

Other eCPRI services:
eCPRI services such as User Plane support, remote reset, etc.

13

2. C&M Plane:

14
15
16

o

17
18
19
20
21
22
23

Control and management information exchanged between the control and management
entities within the eREC and the eRE. This information flow is conveyed to the higher
protocol layers and is not considered time critical.

3. Synchronization Plane:oSynchronization data used for frame and time alignment.

eCPRI defines a protocol for the transfer of user plane information between eREC and eRE via a packet
based fronthaul transport network. For C&M and synchronization information flows, existing protocols andstandards are referenced as proposals. The interface supports Ethernet-switched or IP-routed fronthaul
networks. Figure 6 provides an overview on the basic protocol hierarchy for Ethernet/IP-based eCPRI
transport case.

CPRI

12

eCPRI Specification V2.0 (2019-05-10)

eCPRI Services
User
Data

other
eCPRI
services

Real-Time
Control

C&M

Synchronization

eCPRI protocol layer

e.g.
SNMP

PTP

UDP

UDP, TCP,
SCTP, etc.

UDP

SyncE

IP
IPsec

Ethernet MAC

VLAN (priority tag)

Connection
OAM

ICMP

MACsecEthernet
OAM

Ethernet PHY
1
2

Figure 6: eCPRI protocol stack over IP / Ethernet

3
4

For the example of IP/Ethernet based eCPRI transport protocol shown in Figure 6, the following needs to beconsidered:

5•

User Plane:

6o In case of eCPRI over Ethernet (refer to section 3.2.1) UDP/IP is not used for the User plane.

78o In case of eCPRI over IP (refer to section 3.2.2), Ethernet might not be used, even though Ethernet
is still a typical technology used to transfer IP packets.

9o Message types used by eCPRI are described in section 3.2.3 in detail.

10•o Please refer to Section 3.3 “C&M Plane” for more information.

11
12

C&M Plane:•

Synchronization Plane:

13
14
15

o UDP/IP and VLAN are optional, e.g. the ITU-T PTP telecom profile G.8275.1/Y.1369.1 [4] only
defines PTP transport over Ethernet. Insertion of VLAN tag is not allowed in this profile, IP and
VLAN are thus not possible.

1617

o Please refer to Section 3.4 “Synchronization Plane” and Annex 6.2 “Synchronization and Timing” formore information.

18•o Please refer to Annex 6.4 “Network Connection Maintenance” for more information.

19
20

Connection OAM:•

Please refer to section 3.1.1 for more information on “Ethernet PHY”.

CPRI

13

eCPRI Specification V2.0 (2019-05-10)

1•Please refer to section 3.5 “QoS” for more information on “VLAN (priority tag)”.

2•

IPsec and MACsec are optional. Please refer to informative Annex 6.8 “Security” for more information.

3

3.1.1.

4
5

The Physical Layer typically follows electrical and optical physical reference standards provided in IEEE
802.3 [5], [6] for the following eCPRI use cases:

6
7
8

1.
2.
3.

Physical Layer

eCPRI over electrical cable
eCPRI over electrical backplane
eCPRI over optical fiber

9
10

A high flexibility in the choice of connector and transceiver for the optical fiber use case can be achieved byadopting SFP+ [7], [8] and QSFP+ [9], [10].

11

However, usage of different form factors like CFP, CFP2/4 is not precluded by the eCPRI specification.

12
13

The following Table 3 lists typical examples of common Ethernet interface types for 10G, 25G, 40G and
100G Ethernet for the given use cases. Usage of other line rates / interface types is not precluded.

14

Table 3: Common Ethernet interface types for the given use cases
Use case

Standard / Interface Type

Optical

10GBASE-SR/LR/ER ([5], clause 52)

1

10G

10GBASE-LRM ([5], clause 68)

1

10G

25GBASE-SR, LR, ER ([5], clauses 112/114)

1

25G

40GBASE-SR4 LR4/ER4 ([5], clauses 86/87)

4

10G

100GBASE-SR10 ([5], clause 86)

10

10G

100GBASE-SR4/LR4/ER4 ([5], clauses 95/88)

4

25G

25GBASE-CR/CR-S ([5], clause 110)

1

25G

40GBASE-CR4 ([5], clause 85)

410G

100GBASE-CR10 ([5], clause 85)

10

10G

100GBASE-CR4 ([5], clause 92)

4

25G

10GBASE-KR ([5], clause 72)

1

10G

25GBASE-KR/KR-S ([5], clause 111)

1

25G

40GBASE-KR4 ([5], clause 84)

4

10G

100GBASE-KR4 ([5], clause 93)

4

25GElectrical

Backplane#LanesSignal Rate per Lane

15
16

3.2. User Plane

17

3.2.1.

18
19

In this option, eCPRI messages shall be transmitted in standard Ethernet frames 1 [5]. The Ethernet network
shall follow the definitions in [15].

20
21
22

The type field of the Ethernet frame shall contain the eCPRI Ethertype (AEFE16) [11]. The data field of the
Ethernet frame shall contain the eCPRI common header at the beginning, followed immediately by the
eCPRI payload. The eCPRI message shall be embedded in the Ethernet frame as a series of octets.

User Plane over Ethernet

1 Also, frames with a payload size larger than 1500 octets can be supported

CPRI

14

eCPRI Specification V2.0 (2019-05-10)

12
3

As the minimum size of the data field of an Ethernet frame is 46 octets, if necessary, the eCPRI data field ispadded with octets of zero to fill up this minimum size. This padding is not part of the eCPRI message and so
is not to be included in the eCPRI payload size field.

456

An eCPRI node involved in an eCPRI over Ethernet message exchange shall have at least one Ethernet
MAC address. All Ethernet MAC addresses within the Ethernet network shall be unique2. The assignment of
Ethernet MAC addresses to nodes/eCPRI services is out of scope of the eCPRI specification.

7
8
9The Ethernet MAC header shall provide enough information about the source and the destination of theeCPRI message to deliver the message successfully through the Ethernet network, with the required priority.
Further details of the format and definition of the Ethernet frame are out of scope of the eCPRI specification.

10

3.2.2.

11

In this option, eCPRI messages shall be transmitted in UDP/IP packets.

12
13
14
15

The data field of the UDP datagram contains the eCPRI common header at its beginning, followed
immediately by the eCPRI payload. The eCPRI message shall be embedded in the UDP datagram as aseries of octets. The UDP datagram shall encapsulate the eCPRI PDU precisely, i.e. without requiring
padding octets added to the eCPRI PDU.

16
17

An eCPRI node shall have at least one IP address. All IP addresses within the IP network shall be unique 3.
The assignment of IP addresses to nodes/eCPRI services is out of scope of the eCPRI specification.

18
19
20
21

The header fields of the UDP/IP datagram shall provide enough information about the source and thedestination of the eCPRI message to deliver the message successfully through the IP network, with therequired priority. Further details of the format and definition of the UDP/IP datagram, and how the IP network
is to be maintained are out of the scope of the eCPRI specification.

22

eCPRI does not specify any range of UDP port values to identify the various eCPRI streams.

23

3.2.3.

24
25

eCPRI messages shall have the format shown in Figure 7 and consist of a four byte eCPRI common header
followed by a variable length eCPRI payload.

User Plane over IP

eCPRI Message Format

2 Both locally unique and globally unique Ethernet MAC addresses are applicable.
3 There is no restriction on the IP version (IPv4 or IPv6) used in the IP-routed fronthaul network.

CPRI

15

eCPRI Specification V2.0 (2019-05-10)

Byte
0
1

eCPRI

2

Common Header

3
4

eCPRI Payload (First Byte)

4..65539

eCPRI Payload (Last Byte)

1

Bytes
transmitted
from top
to bottom

0

7

MSB

LSB

2

Figure 7: eCPRI message format

3
4

3.2.3.1.

eCPRI Transmission Byte Order56
7

When the range of a field is too large to fit in a single byte, multiple bytes are used to encode that field. For
eCPRI, the transmission byte order follows “network byte order” or “big endian”, i.e. the most significant byte
is sent first and the least significant byte is sent last (see [12]).

8
9

Example:The hexadecimal number 0xABCD1234 is sent as the byte sequence 0xAB, 0xCD, 0x12, 0x34.

103.2.3.2.

11

eCPRI Message Common Header shall have the format shown in Figure 8.

Common Header

Byte
eCPRI Protocol
Revision0
1

ReservedC
Bytes
transmitted
from top
to bottom

eCPRI Message Type

2eCPRI Payload Size
3

12
13

0

7

MSB

LSB

Figure 8: eCPRI Common Header format

CPRI

16

1

Where:

2

•

3
4
5

•

eCPRI Message Type:
o
o

•

9
10
11
12

eCPRI Protocol:
Revision indicates the protocol version. The eCPRI Protocol Revision is a positive integer value, seesection 4.4.

6
7
8

eCPRI Specification V2.0 (2019-05-10)

indicates the type of service conveyed by the message.
see Table 4

eCPRI Payload Size:
size in bytes of the payload part corresponding to the eCPRI message. It does not include any
padding bytes following the eCPRI message. The maximum supported payload size is 216-1 but theactual size may be further limited by the maximum payload size of the underlying transport network.

•

C:
o
o
o

13
14
15
16
17

eCPRI messages concatenation indicator.
“C=0” indicates that the eCPRI message is the last one inside the eCPRI PDU.
“C=1” indicates that another eCPRI message follows this one within the eCPRI PDU. In thiscase, 0 to 3 padding byte(s) shall be added to ensure that the following eCPRI message starts
at a 4-byte boundary. Padding byte(s) shall be ignored when received.

18

•

19

3.2.3.3.

20
21
22

The payload of eCPRI messages shall follow the format specified in the corresponding eCPRI Message
Type sub-section of section 3.2.4. An eCPRI message payload typically includes an eCPRI message header
and its associated eCPRI message user data.

23

3.2.3.4.

24
25

This section explains how eCPRI messages are mapped onto a transport network layer payload with
examples.

26
27

Figure 9 shows an example in which one eCPRI message is mapped onto a transport network layer payload(e.g. UDP/IP or Ethernet).

28
29

Figure 10 shows an example in which two eCPRI messages are concatenated and mapped onto a transport
network layer payload (e.g. UDP/IP or Ethernet).

Reserved bits shall be handled according to section 4.2.

eCPRI Payload

Mapping Examples

30
Byte

from/to SAPU

eCPRI
CommonHeadereCPRI Payload

C=0

eCPRI Payload SizeeCPRI Message
eCPRI PDU

Transport
Network Layer
HeaderTransport Network Layer Payload(Transport Network Layer = e.g. UDP/IP, Ethernet)

31

CPRI

Padding(optional)

17

1

eCPRI Specification V2.0 (2019-05-10)

Figure 9: An example of non-concatenated case2
from/to SAPU

eCPRI
CommonHeader #0

eCPRI Payload #0

C=1

eCPRI Payload Size #0

from/to SAPU

Padding
0-3Byte(s)Byte

eCPRI Message #0

eCPRI
CommonHeader #1

eCPRI Payload #1

C=0

eCPRI Payload Size #1

eCPRI Message #1
4-Byte boundaryeCPRI PDU

Transport
Network Layer
HeaderTransport Network Layer Payload(Transport Network Layer = e.g. UDP/IP, Ethernet)

Padding(optional)

3
4

Figure 10: An example of two concatenated eCPRI messages

5

3.2.4.

Message Types

6

The message types listed in Table 4 are supported by eCPRI. The usage of these types is optional.

7

Message types #8 - #11 are intended for IWF type 1 ↔ IWF type 2 communication.

8

Table 4: eCPRI Message Types
Message Type #NameSection0

IQ Data

3.2.4.1

1

Bit Sequence

3.2.4.2

2

Real-Time Control Data

3.2.4.3

3

Generic Data Transfer

3.2.4.4

4

Remote Memory Access

3.2.4.5

5

One-way Delay Measurement

3.2.4.6

6

Remote Reset

3.2.4.7

7

Event Indication

3.2.4.8

8

IWF Start-Up

3.2.4.9

9

IWF Operation

3.2.4.10

10

IWF Mapping

3.2.4.11

11

IWF Delay Control

3.2.4.12

12 - 63

Reserved

3.2.4.13

64 - 255

Vendor Specific3.2.4.14

910

3.2.4.1.

Message Type #0: IQ Data

11

3.2.4.1.1.

12
13This message type is used to transfer time domain or frequency domain IQ samples between PHY
processing elements split between eCPRI nodes (eREC and eRE).

Description/Usage

CPRI

18

1

3.2.4.1.2.

2

Figure 11 shows IQ Data Transfer message format.

eCPRI Specification V2.0 (2019-05-10)

Message format

Byte
0
PC_ID
1
2
SEQ_ID

Bytes
transmitted
from top
to bottom

3
IQ samples of User Data (first byte)

L bytes

43+L

3IQ samples of User Data (last byte)
0

7

MSB

LSB

4

Figure 11: IQ Data Transfer message format

5

Where:

6

•

o
o

7
8
9
10
11

o
•

•

An identifier of each message in a series of “IQ Data Transfer” messages.
For example, identifier of an OFDM symbol, a block of sub-carriers, etc.
How to allocate values to SEQ_ID is vendor specific.

IQ Samples of User Data:
o

16
17
18
19
20
21
22

An identifier of a series of “IQ Data Transfer” messages.
For example, identifier of a physical channel, a user, a layer, an antenna port, etc. which has acommon property for PHY processing.
How to allocate values to PC_ID is vendor specific.

SEQ_ID:
o
o
o

12
13
14
15

PC_ID:oo

A sequence of IQ sample pairs (I, Q) in frequency domain or time domain and associatedcontrol information if necessary.
Frequency domain IQ or time domain IQ depends on the selected functional split between
eCPRI nodes and is vendor specific.
The bit width of an IQ sample, the number of IQ sample pairs in a message, and the format of
IQ samples (e.g. fixed point, floating point, block floating point), etc. are vendor specific. The
actual format is known by the transmit/receive eCPRI nodes in advance.

23

3.2.4.1.3.

Message sequence diagram

24

Figure 12 shows an example of IQ Data Transfer Sequence. In this example:

25
26
27

•

A “Real-Time Control Information” message for PC_ID is transferred before a series of “IQ Data
Transfer” messages to inform the remote node how to process IQ samples in following “IQ Data
Transfer” messages.

CPRI

19

eCPRI Specification V2.0 (2019-05-10)

1
2•

An “IQ Data Transfer” message with PC_ID is transferred every OFDM symbol period. Each message
has a unique SEQ_ID.

3
4
5

•

In general, multiple transfer sequence may happen in parallel with different PC_IDs, e.g. for multiple
physical channels, users, layers, antenna ports, etc.

6

eCPRI
Node 1eCPRI
Node 2

RealTime
C

ontro
l

inform

ation
for P
C_ID=
M sy
a
mbol#
0 ( PC
_ID=a
, SEQ
_ID=0
IQ fo
)
r OFD
M sy
mbol#
1 (PC
_ID=a
, SEQ
_ID=1
)

IQ fo
r OFD

IQ fo
r OFD

TTI orsubframe

M sym
SEQ_ bol#N-1 (
PC_ID
ID=N
-1)
=a,

7
8

Figure 12: Message sequence diagram (example)

9

3.2.4.2.

Message Type #1: Bit Sequence10

3.2.4.2.1.

11
12This message type is used to transfer user data in form of bit sequence between PHY processing elements
split between eCPRI nodes (eREC and eRE).

13

3.2.4.2.2.

14

Figure 13 shows Bit Sequence Transfer message format.

Description/Usage

Message format

CPRI

20

eCPRI Specification V2.0 (2019-05-10)

Byte
0
PC_ID
1
2
Bytes
transmitted
from top
to bottom

SEQ_ID3
Bit Sequence of User Data (first byte)

L bytes

4

3+L

1
2
Where:

4

•

7

MSB

LSB

PC_ID:
o
o

5
6
7
8

o
•

•

An identifier of each message in a series of “Bit Sequence Transfer” messages.
For example, identifier of an OFDM symbol, a block of sub-carriers, etc.
How to allocate values to SEQ_ID is vendor specific.

Bit Sequence of User Data:
o
o

14
15
16
17
18

An identifier of a series of “Bit Sequence Transfer” messages.
For example, identifier of a physical channel, a user, a layer, an antenna port, etc. which has acommon property for PHY processing.
How to allocate values to PC_ID is vendor specific.

SEQ_ID:
o
o
o

10
11
12
13

0

Figure 13: Bit Sequence Transfer message format

3

9

Bit Sequence of User Data (last byte)oA Bit Sequence of User Data, e.g. channel coded data before modulation mapping.
The information carried by the Bit Sequence Transfer message depends on the selectedfunctional split between eCPRI nodes and is vendor specific.
The length of a Bit Sequence in a message is vendor specific and known by the transmit/receive
node in advance.

19

3.2.4.2.3.

Message sequence diagram

20

A message sequence example of the Bit Sequence Transfer is shown in Figure 14. In this example:

21
22
23

•

A “Real-Time Control Information” message for PC_ID=a is transferred prior to a series of “Bit
Sequence Transfer” messages to inform the remote node how to process the user data in bit sequence
format in the following “Bit Sequence Transfer” messages.

24
25

•

A “Bit Sequence Transfer” message with PC_ID is transferred every OFDM symbol period. Eachmessage has a unique SEQ_ID.

26
27
28

•

In general, multiple transfer sequences may happen in parallel with different PC_IDs, e.g. for multiple
physical channels, users, layers, antenna ports, etc.

CPRI

21

eCPRI
Node 1eCPRI Specification V2.0 (2019-05-10)

eCPRI
Node 2

RealTime
C
Bit S
e

ontro
l

Inform

ation
for P
ce fo
C_ID=
r OFD
a
M sy
m
SEQ_
b
o
l#
ID=0)
0 ( PC
_ID=a
Bit S
,
eq ue
nce f
or OF
DM
SEQ_ symbol#
ID=1)
1 (PC
_ID=a
,

Bit S
e

q uen

q uen

ce fo
r OFD
M
SEQ_ symbol#
ID=N
N-1
(PC_I
-1)
D=a,

TTI orsubframe

12Figure 14: Message sequence diagram (example)

3

3.2.4.3.

Message Type #2: Real-Time Control Data4

3.2.4.3.1.

5
6
7
8
9
10

This message type is used to transfer vendor specific real-time control messages between PHY processing
elements split between eCPRI nodes (eREC and eRE). This message type 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. However, this type of information
highly depends on the selected function split and the actual implementation of these functions. So only themessage type for Real-Time Control Data is defined, but not the data format.

11

3.2.4.3.2.

12

Figure 15 shows the Real-Time Control Data message format.

Description/Usage

Message format

Byte
0
RTC_ID
1
2
Bytes
transmitted
from top
to bottom

SEQ_ID
3
Real Time Control Data (first byte)

L bytes

4

3+L

13
14

Real Time Control Data (last byte)
0

7

MSB

LSB

Figure 15: Real-Time Control Data Message format

CPRI

22

1
2

Where:

3

•

8

o
•

14
15

o
•

An identifier of a series of “Real-Time Control Data” messages.
For example, identifier for message structures of specific control / configuration / status /measurement and request / response / indication types.
How to allocate values to RTC_ID is vendor specific.

SEQ_ID:
o
o

9
10
11
12
13

RTC_ID:
o
o

4
5
6
7

eCPRI Specification V2.0 (2019-05-10)

An identifier of each message in a series of “Real-Time Control Data” messages.
For example, identifier of message sequence, links between request and response messages,etc.
How to allocate values to SEQ_ID is vendor specific.

Real-Time Control Data:o

The format of this part of the payload is vendor specific.

16

3.2.4.3.3.

Message sequence diagram

17
18
19

Figure 16 shows an example of Real-Time Control Message passing sequence. In this example, Real-Time
Control Messages are transferred prior to and/or after the associated user data messages (in form of IQ Data
or Bit Sequence).

20

eCPRI
Node 1eCPRI
Node 2
RealTimassoc e Contro
iatedlwith Message
user
User
data
Data
(IQ, B
it Se
q uen
ce, e
tc.)

Use

Se
, Bit
a (IQ
r Dat

q uen

ce , e

tc.)

e
essag
rol M data
t
n
o
C
r
Time
h use
Real- iated wit
c
o
ass

21
22
23

Figure 16: Message Sequence diagram (example)

24

3.2.4.4.

Message Type #3: Generic Data Transfer

25

3.2.4.4.1.

26
27

This message type is used to transfer user plane data or related control between eCPRI nodes (eREC andeRE) providing extended data synchronization support for generic data transfers.

28

3.2.4.4.2.

29

Figure 17 shows the Generic Data Transfer message format.

Description/Usage

Message format

CPRI

23

eCPRI Specification V2.0 (2019-05-10)

Byte
0
1
PC_ID
2
3
4
Bytes
transmitted
from top
to bottom

5
SEQ_ID
6
7
Data transferred (first byte)
L bytes

8

7+L

1
2
Where:

4

•

o
•

o
•

An identifier of a series of “Generic Data Transfer” messages.
For example, identifier of a physical channel, a user, a layer, an antenna port, etc. or in case ofcontrol, an identifier for control / configuration / status / measurement or other indication.
How to allocate values to PC_ID is vendor specific.

SEQ_ID:
o
o

10
11
12
13
14
15

17
18
19
20
21
22
23
24
25
26

7

LSB

PC_ID:
o
o

5
6
7
8

16

0

MSB

Figure 17: Generic Data Transfer message format

3

9

Data transferred (last byte)

4-byte field of each message in a series of “Generic Data Transfer” messages.
For example, identifier of▪ message sequence▪ data time relation to frame, OFDM symbol, a block of sub-carriers or sub-carrier etc.
▪ identifier for completion of transfer phase
How to allocate values to SEQ_ID is vendor specific.

Data transferred:oooA sequence of▪ user data samples in frequency or time domain and associated control information if
necessary▪ control information
User or control data content depends on the selected functional split between eCPRI nodes andis vendor specific.
The sample size, the number of samples etc. in a message, and the format of samples (e.g.
fixed point, floating point, block floating point), etc. are vendor specific. The actual format is
known by the transmit/receive eCPRI nodes in advance.

CPRI

24

eCPRI Specification V2.0 (2019-05-10)

1

3.2.4.4.3.

2
3

Figure 18 shows an example of Data Transfer Sequence. In this example, the Message Type “Generic Data
Transfer” is used to transmit “User data”:

4
5
6

•

A “Real-Time Control Information” message for PC_ID is transferred before a series of “Generic Data
Transfer” messages to inform the remote node how to process Data samples in following “Generic
Data Transfer” messages.

7
8•

An “Generic Data Transfer” message with PC_ID is transferred e.g. every OFDM symbol period. Eachmessage has a unique SEQ_ID.
o

9
10
11

•

Message sequence diagram

SEQ_ID does not need to be continuous.

In general, multiple transfer sequence may happen in parallel with different PC_IDs, e.g. for multiple
physical channels, users, layers, antenna ports, etc.

12

eCPRI
Node 1eCPRI
Node 2

RealTimeC

ontro

l infor ma tion fo
r PC
for O
_ID=
FDM
a
s
y
m
bol#0
SEQ
_ID=
(
P
C_ID
0)
=a,
U se r
data
for O
FDM
SEQ symbol#1
_ID=
(PC_
5)
ID=a
,

U se rU se r

data

data

for O
FDM
SEQ symbol#N_ID=N-1) -1 (PC_I
D=a

TTI orsubframe,

13
14

Figure 18: Message sequence diagram (example)

15
16

3.2.4.5.

Message Type #4: Remote Memory Access17

3.2.4.5.1.

18
19

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

20
21
22

The service is conceived in a generic way to handle different kinds of write and read access that depend on
the hardware used in a specific implementation. It is up to the driver routines for an implementation to map awrite/read request to its hardware implementation.

23
24
25

A read or write request/response sequence is an atomic procedure, i.e. a requester needs to wait for the
response from the receiver before sending a new request to the same receiver. A write request without
response is also defined, this procedure is a one-message procedure.

26

3.2.4.5.2.

27

The “Remote Memory Access” message format is shown in Figure 19.

Description/Usage

Message format

CPRI

25

eCPRI Specification V2.0 (2019-05-10)

Byte
0Remote Memory Access ID

1

Read/Write

Req/Resp

2
Element ID
3
4

Address

Bytes
transmitted
from top
to bottom

9
10
Length = L
11Data (first byte)

L bytes

12

Data (last byte)

11+L

1
2
Where:

4

•

5
6

8

7
LSB

Figure 19: Remote Memory Access message format

3

7

0
MSB

Remote Memory Access ID:
The Remote Memory Access ID is used by the initiator of the request when the response is received
to distinguish between different accesses.

•

Read/Write & Request/Response:
The field consist of two parts, a read or write indication and a request or response indication.

CPRI

26

eCPRI Specification V2.0 (2019-05-10)

Read/Write

1
2

Req/Resp

0

7

MSB

LSB

Figure 20: R/W and Req/Resp

3

The Read/Write and Request/Response fields are coded according to Table 5 and Table 6.

4

Table 5: Read/Write coding

5

Value

Read/Write

0000b

Read

0001b

Write

0010b

Write_No_Resp

0011b
..
1111b

Reserved

Table 6: Request/Response coding
Value

Request/Response

0000b

Request0001b

Response0010b

Failure

0011b
..
1111b

Reserved

67
8
9The Response value 0010b (Failure) is used when the receiver of the request is unable to perform theread/write request due to invalid content in received parameters or other faults.
•

10
11
12

Depending on implementation the Element ID could be used for instance to point out a specificinstance of a generic hardware function.
•

13
14
15
16
17
18

Element ID:

Address:
The Address is a 48-bit value. Details such as whether the memory on the opposite node is organizedin one or more memory banks or whether an address offset is signaled over the interface etc. are
vendor specific. The Element ID could be used for identifying a specific memory hardware instance.

•

Length:For a request, the 2-byte Length field contains the number of bytes that are either to be written to orread from a specific address.

CPRI

27

1
2
3
4

eCPRI Specification V2.0 (2019-05-10)

For a response, the 2-byte Length field contains the actual number of bytes that were either written or
read. If for some reason it was not possible to either read or write the full length of data, this will be
detected via the difference in the length field.
•

5
6

Data:
The first Data-byte after the length-field is either the byte that will be written to the memory address
given in the write request or it is the byte read from the memory address given in the read request.

7

3.2.4.5.3.

Message sequence diagram

89
10

An eCPRI-node can at any time initiate a Remote Memory Access to another node. Depending on if it is arequest or a response and whether it is a read or write, different fields will be copied or set according toTable 7.

11

Table 7: Parameter handling
ActionID

Read/Write

Req/Resp

Element ID

Address

LengthData

ReadrequestSet

Set to Read

Set to Req

Set

Set

Set

No dataRead
response

CopiedCopiedSet to Resp

CopiedCopiedNumber ofread bytes

The read
data

Write
requestSet

Set to Write

Set to Req

Set

Set

Set

The data to
be written

Write
response

CopiedCopiedSet to Resp

CopiedCopiedNumber of
written bytes

No dataWrite No
response

Set

Set toWrite_No_Resp

Set to Req

Set

Set

Set

The data to
be written

Failureresponse

CopiedCopiedSet to Failure

CopiedCopiedVendorspecific

Vendorspecific

12

CPRI

28

eCPRI
Node 1eCPRI Specification V2.0 (2019-05-10)

Remote M
emory Acc
ess(
ID, Read,Req, Element ID, Ad
dress, Len
gth

eCPRI
Node 2)ess(
th, Data)
emory Acc
t ID, Leng
Remote M ead, Resp, ElemenID, Rngth, Data(
ory Accessent ID, Address, LemeMteRemo rite, Req, Elem
ID, W
Remote M
emoID, Writery Access(, Resp, Element ID,
Len

)

gth)

Remote M
ID, Writeemory Access(_No_Resp, Req, Element ID,
Remote M
Length)ID, Writeemory Access(_No_Resp, Req, Element ID,
Length)Remote M
em
ID, Write ory Access(_No_Resp, Req, Element ID,
Length)1
2

Figure 21: Message sequence diagram (example)

3

3.2.4.6.

Message Type #5: One-Way Delay Measurement4

3.2.4.6.1.

5
6
7
8
9
10

The Message Type “One-Way delay measurement” is used for estimating the one-way delay between two
eCPRI-ports in one direction. The sender of the message will sample the local time (t 1) and include acompensation value (tcv1) and send it to the receiver. The receiver will time stamp the message when it
arrives (t2) and send that together with an internal compensation value (t cv2) back to the sender. The one-way
delay measurement can be performed without or with a Follow_Up message (1-Step and 2-Step versions).
The decision of which version to use is vendor specific.

11

The One-Way delay value is calculated according to equation (1):12tD = (t2 – tCV2) – (t1 + tCV1)

13
14
15

With the two compensation values, it is possible for a specific implementation to set the reference points forthe measurements as suited for a specific implementation. The exact locations of the reference points arevendor specific.

16
17

Example: Time sampling according to Clause 90 in IEEE 802.3-2015 [5], in this case the time sampling is in
between MAC and PHY layers.

18
19

The service assumes that both nodes are time synchronized to a common time with an accuracy sufficientfor the eCPRI service.

20
21

The usage of eCPRI Message Type “One-Way delay measurement” regarding which node initiates atransmission, the frequency of measurements, response deadline, etc. is vendor specific.

Description/Usage

CPRI

(1)

29

eCPRI Specification V2.0 (2019-05-10)

One-Way Delay tD

SenderReceiver

tCV1

Clock

tCV2

Ethernet

t1
Optional timesampling points

Clock

Ethernet

t1; tCV1

MAC

tCV1
PHY

tCV2
Fronthaul
Network

MAC

t2

PHY

Optional timesampling points

t2; tCV2

tCV1

tD

tCV2

t
t1 (t1 + tCV1 )1
2(t2 – tCV2 ) t2

Figure 22: One-Way delay measurement of the delay Sender -> Receiver3

3.2.4.6.2.

Message format

4The “One-Way delay measurement” message format is shown in Figure 23.

CPRI

30

eCPRI Specification V2.0 (2019-05-10)

Byte
0Measurement ID

1

Action Type

2

TimeStamp

Bytes
transmitted
from top
to bottom

11
12Compensation Value

19
Dummy bytes (first byte)

L bytes20

Dummy bytes (last byte)

19+L

1
2
Where:

4

•

5
6
7

9

7

LSB

Figure 23: One-Way delay measurement message

3

8

0

MSB

Measurement ID:
The Measurement ID is a 1-byte value used by the sender of the request when the response isreceived to distinguish between different measurements, i.e. the receiver of the request shall copy the
ID from the request into the response message.

•

Action Type:The Action Type is a 1-byte value described in Table 8.

CPRI

31

1

Table 8: Action Type

2
3
4
5

eCPRI Specification V2.0 (2019-05-10)

Action Type

Description

0x00

Request

0x01

Request with Follow_Up

0x02

Response

0x03

Remote Request

0x04

Remote request with Follow_Up

0x05

Follow_Up

0x06 … 0xFF

Reserved

Values 0x00 and 0x01 are used when an eCPRI node initiates a one-way delay measurement in the
direction from its own node to another node. Values 0x03 and 0x04 are used when an eCPRI nodeneeds to know the one-way delay from another node to itself. See section 3.2.4.6.3 for usage.
•

TimeStamp:

6
7
8
9

When Action Type is set to 0x00 (Request) in the message this field will contain the time stamp t 1 andwhen Action Type is set to 0x02 (Response) the time stamp t2. When action type is set to 0x01
(Request with Follow_Up) the time stamp information fields shall be set to 0b in all bits, thecorresponding time information values are sent in the Follow_Up message.

10
11

When Action Type is set to 0x03 or 0x04 (Remote Request and Remote Request with Follow_Up) thetime stamp information fields shall be set to 0b in all bits.

12
13

When using the Follow_Up message (2-Step version) the Follow_Up message (Action Type set to0x05) the time information values t1 and tCV1 will be set to the TimeStamp field.

14

The time information values follow the format specified in IEEE 1588-2008 [13] Clause 5.3.3.

15
16

The value consists of 2 parts, one “seconds”-part and one “nanoseconds”-part. The first 6 bytes are
the seconds and the next 4 bytes are the nanoseconds.

CPRI

32

eCPRI Specification V2.0 (2019-05-10)

Byte
0Seconds (Most Significant Byte)

1
2
3
Bytes
transmited
from top
to bottom

45Seconds (Least Significant Byte)

6

Nanoseconds (Most Significant Byte)

78
Nanoseconds (Least Significant Byte)

9

1

0

7

MSB

LSB

2
3

Figure 24: TimeStamp•

Compensation value:

4
5
6
7
8
9

When Action Type is set to 0x00 (Request), 0x02 (Response) or 0x05 (Follow_Up) in the message,
this field will contain the “Compensation Value” which is the compensation time measured innanoseconds and multiplied by 216 and follows the format for the correctionField in the common
message header specified in IEEE 1588-2008 Clause 13.3 [13]. When Action Type is set to 0x03
(Remote Request) or 0x04 (Remote Request with Follow_Up) the time information fields TimeStampand Compensation Value are set to 0b in all bits.

10

A Compensation Value of 0 (zero) is a valid value.

11

Example: A Compensation Value of 183.5 ns is represented as 0000000000B78000 16.

12•

Dummy bytes:

13
14

The number of dummy bytes included in the eCPRI-payload will be defined by the eCPRI payload size
field in the eCPRI common header, see section 3.2.3.1

15
16

Due to network characteristics, a small message might take shorter time through the network than alarge one, with the dummy bytes the one-way delay estimation can be improved.

17
18

The insertion of dummy bytes is only needed when the Action Type set to 0x00 (Request) or to 0x01
(Request with Follow_Up).

19

3.2.4.6.3.

Message sequence diagram

20

The message sequence diagram shown in Figure 25 is divided in 2 parts:

21

Part I shows the sequence when Node 1 initiates a delay measurement in the direction Node 1 to Node 2.

22

Part II shows the sequence when Node 1 initiates a delay measurement in the direction Node 2 to Node 1.

23
24
25

An eCPRI-node can at any time initiate a one-way delay measurement by setting the Action Type to 0x00
(Request), 0x01 (Request with Follow_Up) 0x03 (Remote Request) or 0x04 (Remote Request with
Follow_Up). The Measurement ID received in the request shall be copied in the response.

26

Figure 26 shows the same sequences as Figure 25 but with the usage of the Follow_Up message.

CPRI

33

eCPRI Specification V2.0 (2019-05-10)

eCPRI
Node 1eCPRI
Node 2

t1
tCV1

One-Way

Delay Me
asurement(ID, Request, t1, t
CV )
1

I

tCV2
, t2, tCV2), Response
ID
t(
n
e
m
asure
Delay MeOne-Wayt2
tD = (t2 - tCV2) – (t1 + tCV1)

tD = (t2 - tCV2) – (t1 + tCV1)
One-WayIItCV2tD = (t2 - tCV2) – (t1 + tCV1)

Delay Me
asurement(ID, Remote Reque
st)

t1
)
t
uest, t1, CV1nt(ID, Req
e
m
re
su
a
Delay MeOne-WaytCV1

t2
One-Way

Delay Me
asurement(ID, Response, t2, t

CV2 )tD = (t2 - tCV2) – (t1 + tCV1)
1
2
3

Figure 25: Message sequence diagram without Follow_Up (example)

CPRI

34

eCPRI Specification V2.0 (2019-05-10)

eCPRI
Node 1eCPRI
Node 2

t1
tCV1

One-Way

One-Way

Delay Me
asuremen

Delay Me
asurement(ID, Requ
est w fu,
0

, 0)

tCV2
t(ID, Follo
w_Up, t ,
1 t

t2

CV1 )

I

tD = (t2 - tCV2) – (t1 + tCV1))
nse, t2, tCV2
ID, Respo
t(
n
e
m
re
asu
Delay MeOne-WaytD = (t2 - tCV2) – (t1 + tCV1)
One-WayIItCV2tD = (t2 - tCV2) – (t1 + tCV1)

Delay Me
asurement(ID, Remote Requ, Req
rement(IDlay Measu
e
D
y
a
-W
On e

t2

One-WaOne-Wayuest

est w fu)t1),
w fu, 0 0tCV1)_Up, t1, tCV1
ID, Follow
t(
n
e
m
re
easu
y Delay M

Delay Me
asurement(ID, Response, t2, t

CV2)

tD = (t2 - tCV2) – (t1 + tCV1)

1
2

Figure 26: Message sequence diagram with Follow_Up (Example)

3

3.2.4.7.

Message Type #6: Remote Reset4

3.2.4.7.1.

5
6
7This message type is used when one eCPRI node requests reset of another node. A “Remote Reset”
request sent by an eREC triggers a reset of an eRE. Upon reception of a valid “Remote Reset” request, theeRE should send a “Remote Reset” indication before performing the requested reset.

8
9
10
11
12

Resetting the IWF is recommended to be handled by higher layers to minimize the radio system impact,because all connecting functions including REs may be affected. However, applying Message Type #6“Remote Reset” to the IWF may be considered as an emergency reset for cases such as the IWF software
control not responding or misbehaving. Returning the “Remote reset response” (see Table 9) isrecommended but not mandatory.

13
14

An eREC can request the IWF type 0 to reset the connected REs by using this “Remote Reset” message. In
this case, each RE shall be identified by a vendor specific allocated Reset ID.

15

3.2.4.7.2.

16

Figure 27 shows the Remote reset message format.

Description/Usage

Message format

CPRI

35

eCPRI Specification V2.0 (2019-05-10)

Byte
0
Reset ID
1
2

Reset Code Op= Request/Response
Vendor Specific Payload (first byte)

L bytes3

Bytes
transmitted
from top
to bottom

2+L

Vendor Specific Payload (last byte)
0

7

MSB

LSB

1
2

Figure 27: Remote reset message format

3

Where:

4

•

o

5
6
7
8

Reset ID:o•

Depending on implementation the Reset ID could be used for instance to point out a specificinstance of a generic hardware function.
How to allocate values to Reset ID is vendor specific.

Reset Code Op:

9

The Reset Code Op is a 1-byte value described in Table 9.

10

Table 9: Reset Code Op
Reset Code Op

Description

0x00

Reserved

0x01

Remote reset request

0x02

Remote reset response

0x03…0xFF

Reserved

11
12
13
14
15

•

Vendor Specific Payload bytes:
Vendor Specific Payload bytes are used to carry optional vendor-specific information. The vendorspecific information can contain data items such as authentication parameters or any parameters to
select a specific reset behavior. This specification does not detail any concrete reset behavior.

16

CPRI

36

1

3.2.4.7.3.

eCPRI Specification V2.0 (2019-05-10)

Message sequence diagram

2

eCPRI
node 2eCPRI
node 1e C PR I

R e mo teReque Reset/stseote Reme
R
Ie C PRn se
R e sp ot/

Reset of the local
eCPRI node3
4

Figure 28: Message sequence diagram (example)

5

3.2.4.8.

Message Type #7: Event Indication

6

3.2.4.8.1.

78
9The Message Type “Event Indication” is used when either side of the protocol indicates to the other end thatan event has occurred. An event is either a raised or ceased fault or a notification. Transient faults shall be
indicated with a Notification.

10
11
12

Faults/Notifications sent on eCPRI level should be relevant to the eCPRI services. For instance, faults in theuser plane processing, power usage fault situations etc. The faults and notifications should be related to theuser data processing.

13
14

One Event Indication can either contain one or more faults, or one or more notifications. Faults andnotifications cannot be mixed in the same Event Indication message.

15
16

Other faults/notifications related to an eCPRI node such as temperature faults, power supervision, etc. would
normally be sent via the C&M plane.

17
18
19

An eCPRI node is modelled as consisting of N Elements, a fault or notification is connected to one Element.
The detailed mapping of a specific implementation of HW and SW to Elements and their associatedfaults/notification is vendor specific.

20
21

A fault/notification may be connected to the node itself. In that case a predefined Element ID number is used,
see Table 11.

22

The Event/Fault Indication message could be sent from an eCPRI node at any time.

23
24

For consistency check a synchronization request procedure is defined. This procedure will synchronize therequester with the current status of active faults. Transient faults will not be synchronized.

Description/Usage

CPRI

37

eCPRI Specification V2.0 (2019-05-10)

1

eCPRI Node
Element 1
element 2

eCPRI i/f
Event Indication

Element N

2
3

Figure 29: Model for event indications

4
5

3.2.4.8.2.

Message format

6

The Event Indication message format is shown in Figure 30.

CPRI

38

eCPRI Specification V2.0 (2019-05-10)

Byte
0Event ID

1

Event Type

2

Sequence Number

3

Number of Faults/Notif = N

4
Element ID #1
5
6

Raise/Cease #1

7

Fault/Notif #1 MSB

Fault/Notif #1 LSB

8
9Additional Information #1
10
Bytes
transmitted
from top
to bottom

11

12+8x(N-1)
Element ID #N
13+8x(N-1)
14+8x(N-1)

Raise/Cease #N

15+8x(N-1)

Fault/Notif #N MSB

Fault/Notif #N LSB

16+8x(N-1)
17+8x(N-1)
Additional Information #N
18+8x(N-1)
19+8x(N-1)

1
2

0

7

MSB

LSB

Figure 30: Event indication message

CPRI

39

1

Where:

2

•

3
4
5

eCPRI Specification V2.0 (2019-05-10)

Event ID:
A 1-byte value set by the transmitter of an Event Indication or a Synchronization Request to enable
identification of the acknowledge response.

•

Event Type:

6

Table 10: Event TypeEvent Type

Description

0x00

Fault(s) Indication

0x01

Fault(s) Indication Acknowledge

0x02

Notification(s) Indication

0x03

Synchronization Request

0x04

Synchronization Acknowledge

0x05

Synchronization End Indication

0x06…0xFF

Reserved

7
8

•

9
10
11
12
13
14
15
16

The Sequence Number is a 1-byte value that is incremented each time the transmitter sends the“Event Indication” with Event Type set to 0x00 (Fault(s) Indication). The receiver will use the sequencenumber to ensure that the correct status for a specific combination of {Element-ID; Fault-value} isused. Due to the nature of the packet based fronthaul network, packets might be delivered out of orderand a sequence number is needed to handle this scenario. When a fault indication is not
acknowledged the transmitter will re-transmit the fault, setting the sequence number to the same value
used in the initial transmission.
•

17
18

Sequence Number:

Number of Faults/Notifications:
Number of fault indications or notifications attached in the same message.

•

Element ID:

19

Table 11: Element ID
Element ID Number

Usage

0x0000 … 0xFFFE

Vendor specific usage

0xFFFF

20
21
22

•

A fault or notification applicable for
all Elements i.e. the node

Raise/cease:
First nibble in the same byte as the Fault/Notification Number.
Table 12: Raise/ceased
Raise/Cease

Description

0x0

Raise a fault

0x1

Cease a fault

0x2 … 0xF

Reserved

23

CPRI

40

1

•

2

eCPRI Specification V2.0 (2019-05-10)

Fault/Notification Numbers:
A 12-bit number indicating a fault or notification divided between 2 bytes.

3

Table 13: Fault/Notification numbers
Fault Indication and
Notification Numbers

Usage

0x000 … 0x3FF

eCPRI reserved Faults

0x400 ... 0x7FF

eCPRI reserved Notifications

0x800 ... 0xFFF

Vendor Specific Fault Indications andNotifications

eCPRI Faults and Notifications
0x000

General Userplane HW Fault

0x001

General Userplane SW Fault

0x002 ... 0x3FF
0x400

Unknown message type received

0x401

Userplane data buffer underflow

0x402

Userplane data buffer overflow

0x403

Userplane data arrived too early

0x404

Userplane data received too late

0x405 … 0x7FF
45•

eCPRI reserved

eCPRI reserved

Additional Information:
If available, additional information regarding the fault/notification for vendor specific usage.

6

3.2.4.8.3.

Message sequence diagram

7
8

An eCPRI node can at any time send an Event Indication to the peer node. Depending on what Event Type,different fields will be set or copied according to Table 14.

9

Table 14: Parameter handling
Event TypeEvent ID

Sequence
NumberNbr of Faults
or Notifications

Fault/Notification(s)Raise/Cease

Additional
Information

Fault Indication

Set

Increment>0

Fault(s)Raise or Cease

Vendor Specific

Fault
Indication
Acknowledge

CopiedCopied0

Not included

Not included

Not Included

Synchronization
RequestSet

Set to 00

Not included

Not included

Not Included

Synchronization
Acknowledge

CopiedSet to 00

Not included

Not included

Not Included

Synchronization
End Indication

CopiedSet to 00

Not included

Not included

Not Included

Notification

Set

Set to 0>0

Notifications

Set to 0x0

Vendor specific

10

CPRI

41

eCPRI Specification V2.0 (2019-05-10)

eCPRI
Node 1eCPRI
Node 2r, Fault, Seq_N
ation(ID, Fa
Event Indic
Event Indic
ation(ID, Fauult Ind(s))

lt_Ack, Seq_Nr)

Event Indic
ation(ID, Sync_Req)

Event Indic
ation(ID, Fau

lt_Ack, Seq_Nr)

q_Nr, Fault
D, Fault, Se
(I
n
io
at
ic
d
Event In
Event Indic
ation(ID, Fau

Ind(s))One synchronization
procedurenc_Ack)ation(ID, Sy
Event Indic
ult Ind(s)), Seq_Nr, Fa
lt
u
Fa
,
D
(I
ation
Event Indiclt_Ack, Seq_Nr)

nc_End)ation(ID, Sy
Event Indicotification
ation(ID, N
Event Indicon(s)), Notificati

1
2

Figure 31: Message sequence diagram (example)

3
4

The first part of the sequence above shows when Node 2 detects a fault condition which is signalled to Node
1 and Node 1 acknowledges the reception of the indication.

5
6
7
8
9
10

The middle part of the sequence diagram shows a Synchronization procedure. The procedure is started witha Synchronization-Request sent by Node 1, signals marked in grey might be sent due to number of faults ordue to the implementation. The request is acknowledged by Node 2, Node 2 then sends the current list ofraised faults to Node 1, the sequence is ended when Node 2 sends the Synchronization-End message. In
the Synchronization procedure the “Event ID” set by Node 1 in the request message will be used during thefull procedure.

11
12

The last part of the sequence shows when Node 2 sends a notification to Node 1, this notification is not
acknowledged by Node 1.

13

3.2.4.9.

14

3.2.4.9.1.

15
16This message type is used during the start-up sequence to transfer CPRI control words between CPRI
nodes (REC and RE). Typically, this message is used during line bit rate negotiation.

17
18

This message also instructs the IWFs when to start the CPRI frame structure relative to the IWFs local
clocks.

19
20

At start-up, IWF type 1 and type 2 will exchange eCPRI Type #8 messages. Please refer to section 8.7 fordetails on the usage of Message Type #8 during the start-up procedure.

Message Type #8: IWF Start-Up
Description/Usage

CPRI

42

1

3.2.4.9.2.

eCPRI Specification V2.0 (2019-05-10)

Message format
Byte
0

PC_ID
1
2

#Z

3

#X

4

5
Timestamp
6
7

8

F

9

S

r

Line Rate

L bytes

Data transferred (first byte)

Data transferred (last byte)

8+L
0

7

MSB

LSB

2
3

Figure 31A: IWF Start-Up message format

4

Where:

5

•

o
o
o

6
7
8
9

•

10
11

14
15
16
17
18
19

2-byte field identifier of a series of “IWF Start-Up” messages.
For example, identifier of destination CPRI node.
How to allocate values to PC_ID is vendor specific.

#Z:#Z is the hyperframe number (see [1]) of the corresponding CPRI basic frame.

•

12
13

PC_ID:#X:#X is the basic frame number within the hyperframe (see [1]) of the corresponding CPRI basic frame.

•Timestamp:
The Timestamp allows the IWF to establish the relation between the CPRI frame structure timing andits local clock. The Timestamp is a value in number of nanoseconds. Only values less than 109 shallbe used (see [13], section 5.3.3).
For the IWF type 1 to IWF type 2 direction the Timestamp specifies when the data contents in thismessage shall start to be transmitted on the IWF type 2 CPRI link. Transmission shall start, when thenanosecond part of IWF type 2 local clock equals this timestamp value.

CPRI

43

eCPRI Specification V2.0 (2019-05-10)

1
2
3
4

In the IWF type 2 to IWF type 1 direction this specifies when the CPRI data content was received at
IWF type 2.
From this Timestamp the IWFs shall learn when the CPRI hyperframe structure starts relative to the
local clocks in the IWFs. The CPRI 10ms frame delimitation is indicated by #Z=0 and #X=0.

5

See sections 8.7.2 and 8.9 for further details on delay management and Timestamp handling.

6

•

o
o
o

7
8
9
10

•

•

30
31

•

CPRI scrambling bit indicator of the CPRI link associated with the IWF generating the message.
“S=0” indicates that the CPRI scrambling is disabled.
“S=1” indicates that the CPRI scrambling is enabled.

Line Rate:
o
o

15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

CPRI FEC bit indicator of the CPRI link associated with the IWF generating the message.
“F=0” indicates that the CPRI FEC is disabled.
“F=1” indicates that the CPRI FEC is enabled.

S:
o
o
o

11
12
13
14

F:

Line rate of the CPRI link associated with the IWF generating the message:
CPRI line bit rate option 5-bits field (LLLLL):▪
00000: Reserved▪
00001: CPRI line bit rate option 1▪
00010: CPRI line bit rate option 2▪
00011: CPRI line bit rate option 3▪
00100: CPRI line bit rate option 4▪
00101: CPRI line bit rate option 5▪
00110: CPRI line bit rate option 6▪
00111: CPRI line bit rate option 7▪
01000: CPRI line bit rate option 7A▪
01001: CPRI line bit rate option 8▪
01010: CPRI line bit rate option 9▪
01011: CPRI line bit rate option 10▪
01100…11111: Reserved

Data transferred:
The Control Word bytes (TCW bits) of the basic frame #Z, #X.

32

3.2.4.10.

Message Type #9: IWF Operation

33

3.2.4.10.1. Description/Usage

34
35

This message type is used to transfer CPRI basic frames or part of CPRI basic frames between CPRI nodes(REC and RE) after CPRI start-up.

36

CPRI

44

1

eCPRI Specification V2.0 (2019-05-10)

3.2.4.10.2. Message format
Byte

0
PC_ID

1
2

#Z0

3

#X0
Chunk0 (first byte)

S0 bytes

...

S0+3

Chunk0 (last byte)

S Si+2x(1+k)

#Zk

k-1

i=0-k

Bytes
transmitted
from top
to bottom#Xk
Chunkk (first byte)

Sk bytes...

S Si+2x(1+k)+1

Chunkk (last byte)

k

i=0-k

2
3
Where:

5

•

•

14

•

2-byte field identifier of a series of “IWF Operation” messages.
For example, identifier of destination CPRI node.
How to allocate values to PC_ID is vendor specific.

#Zi:
o

10

12
13

PC_ID:
o
o
o

6
7
8

11

7

LSB

Figure 31B: IWF Operation message format

4

9

0

MSB

#Zi is the hyperframe number (see [1]) of the corresponding CPRI basic frame for chunk #i.

#Xi:o#Xi is the basic frame number within the hyperframe (see [1]) of the corresponding CPRI basic
frame for chunk #i.

The chunk format is defined as follows:

CPRI

45

eCPRI Specification V2.0 (2019-05-10)

Byte

0

CWMain CWExt DB

E

M

r

BFF

N

1

N+1 bytes1
N-byte Bitmask

Bytes
transmitted
from top
to bottom

Data transferred (first byte)...

Data transferred (last byte)
0

7

MSB

LSB

1

: These N+1 bytes are present if M=1.

1
2

Figure 31C: eCPRI Message Type #9 Chunk format

3
4

Where:

5

•

o
o

6
7
8
9
10
11

o
•

o
•

22

•

25

•

29
30

•

Error indicator, indicates if at least one error has been detected during the reception of the CPRI
basic frame bytes associated to the “Data transferred” bytes.

M:
o
o
o

26
27
28

CPRI IQ Data Block presence bit indicator.
“DB=0” indicates IQ Data Block bytes are not included in the “Data transferred” bytes.
“DB=1” indicates IQ Data Block bytes are included in the “Data transferred” bytes.

E:
o

23
24

Control Word Extension presence bit indicator.
“CWExt=0” indicates that the last T-TCW bits of the word with index W=0 are not included in the“Data transferred” bytes, except if explicitly stated by the sub-part mapping configuration (e.g.
by using eCPRI Message Type #10 or higher layer configuration).
“CWExt=1” indicates that the last T-TCW bits of the word with index W=0 are included in the“Data transferred” bytes.

DB:
o
o
o

19
20
21

CPRI Control Word presence bit indicator.
“CWMain=0” indicates that the first TCW bits of the CPRI Control Word are not included in the“Data transferred” bytes.
“CWMain=1” indicates that the first TCW bits of the CPRI Control Word are included in the“Data transferred” bytes.

CW Ext:
o
o

12
13
14
15
16
17
18

CW Main:N-byte bitmask flag
“M=0” indicates that there is no N-byte bitmask descriptor in this chunk.
“M=1” indicates that there is an N-byte bitmask descriptor in this chunk.

N:olength in bytes of the N-byte bitmask (N = 0, 1, 2, 4, 8).

CPRI

46

1

•

eCPRI Specification V2.0 (2019-05-10)

N-byte Bitmask:

2
3
4
5

N-byte parameter indicating which sub-part(s) of the previously negotiated CPRI IQ data area
configuration (e.g. via eCPRI Message Type #10) are included in the eCPRI message Datatransferred field.
The N-byte bitmask shall be interpreted as follows:67
8

If the ith bit of the N-byte bitmask is set to 1 then the ith sub-part of the previously negotiated CPRI IQ
data area configuration is included in the eCPRI message “Data transferred” field, otherwise this subpart is not included.

1 byte910

1stSub-part

...

...

...

...

...

...

8th
Sub-part

0

7

MSB

LSB

Figure 31D: 1-byte bitmask format

11
1st
Sub-part

...

...

...

N bytes

14

23
24
25
26
27
28
29
30
31
32
33
34

...

8th
Sub-part

...

...

...

...

...

...

8xNth
Sub-part

0

7

MSB

LSB

Figure 31E: N-byte bitmask format (N=2, 4, 8)
•

BFF:
o
o
o

15
16
17
18
19
20
21
22

...

...

...

12
13

...

o

•

Basic Frame Fragment index of a CPRI basic frame when split over several eCPRI chunks.
All fragments of a CPRI basic frame have the same #Z and #X.
The main purpose of basic frame fragmentation is to distribute large basic frames over multiple
eCPRI messages.
BFF shall be set to zero if fragmentation is not used. Otherwise BFF starts at zero for the firstfragment of a CPRI basic frame and is incremented by one for subsequent fragments of thesame CPRI basic frame.

Data transferred:oThe “Data transferred” field bytes correspond to the decoded CPRI basic frame content bytes.
▪
M=0:
Fields shall be created as specified in byte 0 of the chunk (“CW Main”, “CW Ext” and “DB”) in
combination the sub-part mapping provided by either:
 eCPRI Message Type #10: IWF Mapping messages (see section 3.2.4.11)
 Configured via C&M plane of IWFs
 Pre-configured Any other vendor-specific method▪ M=1:
Fields shall be created as specified in byte 0 of the chunk (“CW Main”, “CW Ext” and “DB”) in
combination the sub-part mapping provided by either:
 eCPRI Message Type #10: IWF Mapping messages (see section 3.2.4.11)

CPRI

47

eCPRI Specification V2.0 (2019-05-10)

1
2
3
4
5

 Configured via C&M plane of IWFs
 Pre-configured Any other vendor-specific method
Additionally, the sub-part must be set in the corresponding "N-byte bitmask" parameter;otherwise the sub-part shall not be included in "Data transferred".

6
7
8
9
10
11
12
13
14
15
16

 “N=0” indicates that there is no N-byte bitmask in this chunk meaning that the current
mapping is ignored and the “Data transferred” in the eCPRI message corresponds tothe concatenation of the decoded CPRI basic frame content bits indicated by fields“CWMain”, “CWExt” and “DB”.
 “N=1,2,4,8” indicates that there is an N-byte bitmask in this chunk.
 The N-byte bitmask shall be interpreted as follows: If the ith bit of the N-byte bitmask is set to 1 then the ith sub-part of the previously
negotiated CPRI IQ data configuration shall be included in the eCPRI message “Datatransferred” field otherwise this sub-part shall not be included.
The “Data transferred” fields in the eCPRI data are padded with bits of zero to fill up to the next
byte boundary.

17
18
19
20

o

The following examples assume:o
CPRI line bit rate option 2oIWFs have negotiated a simple mapping, where the first half of the IQ data block is divided in 4 equal
sub-parts of 30 bits and the second half (120 bits) is unused, as shown in Figure 31F:
W = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1 chip = 1/3.84MHz
B=0: A
B=1: B

Y=0

BYTE #Z.X.0

BitOffset=16

Y=1
BitOffset=46
B=14: G
B=15: H

21
22
23
24
25

BYTE #Z.X.1

B=7: H
B=8: A

control word

IQ
time

Data block

BitOffset=106

15 * 16 bits

BitOffset=76

Figure 31F: CPRI basic frame mapping configuration example
With the chunk parameters M=1, N=1 and a 1-byte bitmask = 0xC0, indicating that the first two sub-parts are
considered, the corresponding chunk, with CW Main=0 and CW EXT=0 and DB=1, will contain the first 60 bits of
the IQ data block and 4 padding bits, as shown in Figure 31G.

CPRI

48

eCPRI Specification V2.0 (2019-05-10)

Byte
0

CWMain CWExt DB=
=0
=0
1

E

M=1

r

00 b

1

2 bytes

1

1

23

0

0

0

0

0

0

1

1

0

0

0

16

31

24

39

32

47

46

45

44

43

42

41

Bytes
transmitted
from top
to bottom

40

8 bytes

1
2
3
4
5

55

48

63

56

71

1

1

1

0

0

0

64

0

0

0

0

75

74

73

72

0

7

MSB

LSB

Figure 31G: eCPRI chunk example M=1, N=1 and 1-byte bitmask = 0xC0With the chunk parameters M=1, N=1 and a 1-byte bitmask = 0x90, indicating that the first and the last subparts are considered, the corresponding chunk, with CW Main=0 and CW EXT=0 and DB=1, will contain the first
30 bits and the last 30 bits of the IQ data block and 4 padding bits, as shown in Figure 31H.
Byte
0

CWMain CWExt DB=
=0
=0
1

E

M=1

r

0

0

00 b

1

2 bytes
1

0

0

1

0

0

23

16

31

24

39

32

107

106

45

44

43

42

41

Bytes
transmitted
from top
to bottom

40

8 bytes
115

108

123

116

131

124

0

6
7
8
9
10

0

0

0

135

134

133

132

0

7

MSB

LSB

Figure 31H: eCPRI chunk example M=1, N=1 and 1-byte bitmask = 0x90
With the chunk parameter M=0, indicating that there is no N-byte bitmask, the corresponding chunk, withCW Main=0 and CW EXT=0 and DB=1, will contain all four sub-parts with a total size of 120 bits, as shown in
Figure 31I.

CPRI

49
Byte
0

CWMain CWExt DB=
=0
=0
1

E

eCPRI Specification V2.0 (2019-05-10)

M=0

r

00 b

23

16

31

24

39

32

47

46

45

44

43

42

41

40

55

48

63

56

71

64

79

78

77

76

75

74

73

72

Bytes
transmitted
from top
to bottom

15 bytes

87

80

95

88

103

96

111

1
2
3
4
5

110

109

108

107

106

105

104

119

112

127

120

135

128

0

7

MSB

LSB

Figure 31I: eCPRI chunk example M=0With the chunk parameters M=1, N=0, indicating that the whole IQ data block is considered, thecorresponding chunk, with CW Main=0 and CW EXT=0 and DB=1, will contain the complete IQ data block of size
240 bits, as shown in Figure 31J:

CPRI

50

eCPRI Specification V2.0 (2019-05-10)

Byte
0

CWMain CWExt DB=
=0
=0
1

E

M=1

r

00 b

0

23

16

31

24

39

32

47

46

45

44

43

42

41

40

55

48

63

56

71

64

79

78

77

76

75

74

73

72

87

80

95

88

103

96

111

110

109

108

107

106

105

104

119

112

127

120

135

128

Bytes
transmitted
from top
to bottom

30 bytes

1
2

0

7

MSB

LSB

Figure 31J: eCPRI chunk example M=1, N=0

3

CPRI

51

1

eCPRI Specification V2.0 (2019-05-10)

3.2.4.10.3. Message sequence diagram

IWF1

2
3

IWF 2

Figure 31K: Message #9 sequence4

3.2.4.11.

Message Type #10: IWF Mapping5

3.2.4.11.1. Description/Usage

6
7

This message type is used to negotiate the mapping configuration between two IWFs by defining sub-partlocations within the IQ data block area of a CPRI basic frame.

8

A sub-part may or may not correspond to one or more AxC containers.

9

Sub-parts may or may not have the same size.

10

Sub-parts may or may not be contiguous.

11
12
13

In an eCPRI/CPRI interworking scenario, the uplink and the downlink mapping configurations may bedifferent. The downlink mapping configuration request is initiated by IWF type 1, and the uplink mapping
configuration request is initiated by IWF type 2.

14

CPRI

52

1

eCPRI Specification V2.0 (2019-05-10)

3.2.4.11.2. Message format
Byte
0

PC_ID
1
2

Mapping_Config_ID

3

Action Type4

StartOffset1
Bytes
transmitted
from top
to bottom

4xL
bytes

Length 1

StartOffsetL

Length L
3+4xL
0

7

MSB

LSB

2
3

Figure 31L: IWF Mapping message format

4

Where:

5

•

o
o
o

6
7
8
9
10

•

17
18

•

2-byte field identifier of a series of “IWF Mapping” messages.
For example, identifier of destination CPRI node.
For the request message, how to allocate values to PC_ID is vendor specific. For the response
message, PC_ID is copied from the request.

Mapping_Config_ID:
o
o
o

11
12
13
14
15
16

PC_ID:

1-byte field identifier of a configuration request.
For a request message, how to allocate values to Mapping_Config_ID is vendor specific.
For a response message, Mapping_Config_ID is copied from the request. It enables the initiatorof the request to distinguish between different configuration requests, when it receives a
response.

Action Type:
This 1-byte field specifies the type of action associated to the message.
The Action Type field is coded according to Table 14A.

CPRI

53

1

eCPRI Specification V2.0 (2019-05-10)

Table 14A: Action Type
Value

Request/Response

00000000b

SetRxConfigRequest

00000001b

SetRxConfigResponseAccept

00000010b

SetRxConfigResponseReject

00000011b

SetRxConfigResponsePropose

00000100b
11111111b

Reserved

2
3
4
5

o

SetRxConfigRequest:
This Action Type is used by one IWF to specify the mapping configuration associated to the
PC_ID and Mapping_Config_ID in the eCPRI message to be used by the remote IWF.

6
7o

SetRxConfigResponseAccept/SetRxConfigResponseReject/SetRxConfigResponsePropose:
These Action Types are used by one IWF to respond to a SetRxConfigRequest.

8
9
10
11

If the requested mapping configuration associated to a SetRxConfigRequest with PC_ID and
Mapping_Config_ID parameters is accepted, the request message shall be acknowledged by a
SetRxConfigResponseAccept with the same PC_ID and Mapping_Config_ID parameters andno mapping configuration parameters.

12
13
14
15
16

If the requested mapping configuration associated to a SetRxConfigRequest with PC_ID and
Mapping_Config_ID parameters is rejected and the receiver does not want to propose analternative mapping configuration, the request message shall be acknowledged by a
SetRxConfigResponseReject with the same PC_ID and Mapping_Config_ID parameters and no
mapping configuration parameters.

17
18
19
20
21
22

If the requested mapping configuration associated to a SetRxConfigRequest with PC_ID and
Mapping_Config_ID parameters is rejected, and the receiver wants to propose a mapping
configuration, the request message shall be acknowledged by a SetRxConfigResponsePropose
with the same PC_ID and Mapping_Config_ID parameters and the proposed mapping
configuration parameters. The subsequent SetRxConfigRequest with the proposed mapping
shall be accepted by the receiver.

23
24

The mechanisms used to synchronize the IWFs when changing the configuration are out of thescope of the eCPRI specification and are vendor specific.

25•

StartOffseti/Lengthi:

26
27
28
29

These fields specify the location of a sub-part in a CPRI basic frame.
The value of StartOffseti corresponds to the first bit index of the ith sub-part in a CPRI basic frame.
The bit offset StartOffseti is given by the following equation:
StartOffseti = B + W x T

30
31
32
33
34

where B, W and T are defined by the CPRI specification [1] nomenclature as:o
T is the number of bits per word in a CPRI basic frame (The length T of the word depends on
the CPRI line bit rate).
o
W is the word index in the CPRI basic frame (W=0…15).
o
B is the bit index within a CPRI word (B=0…T-1).

CPRI

54

eCPRI Specification V2.0 (2019-05-10)

W = 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

1 chip = 1/3.84MHzBYTE #Z.X.0

B=0
B=1

BYTE #Z.X.(TCW/8-1)

Y=0

B=TCW-8
B=TCW-7

Y = TCW/8-1

BitOffset=TCW
BYTE #Z.X.TCW/8

B=TCW
B=TCW+1

B=(T-8)
B=(T-7)Y = (T/8-1)

B=(T-1)time

Data block

BYTE #Z.X.(T/8-1)

Y = TCW/8

IQ

BitOffset=T-1
BitOffset=16T-1

15 * T bits

1
2

Figure 31M: CPRI Basic bit offsets

3
4
5

The value of Lengthi corresponds to the number of bits of the ith sub-part of a CPRI basic frame. A
Lengthi equal to 0 indicates that the sub-part is defined as a Null sub-part, meaning that this sub-partis defined but it is not associated to any actual content.

6
7

As the sub-parts are in the IQ data block of a CPRI basic frame, the following inequalities shall beensured:8

TCW ≤ StartOffseti

9StartOffseti + Lengthi < 16 x T

10
11
12

Restricted by the maximum N-byte bitmask size of N=8, the number of sub-parts L is less than orequal to 64. Thus, the value of i shall be in the following range:
1 ≤ i ≤ L ≤ 64

13
14
15

The whole configuration shall be carried in only one message. In each message, i is always numberedfrom 1. If there are remaining sub-parts not covered in one message, i.e. the number of sub-parts isless than the length of bitmask in Message Type #9, they shall be interpreted as Null sub-parts.

16
17
18

If there are overlapping sub-parts, the corresponding bitmask entries in Message Type #9 shall not beenabled simultaneously in order to avoid that the subsequent sub-part would overwrite the previous
sub-part at the receiving end.

19
20
21

The negotiation process of the mapping configuration must be completed before the sub-parts can be usedin Message Type #9. During the mapping negotiation process, the bitmasks associated with the changed or
added sub-parts must not be enabled.

22

If there is no valid mapping configuration, only Message Type #9 with DB=1, M=1 and N=0 can be used.

23
24

Depending on whether the Action Type is a request or a response, different fields shall be copied or set
according to Table 14B.

CPRI

55

1

eCPRI Specification V2.0 (2019-05-10)

Table 14B: Parameter handling
PC_ID

Mapping_Config_ID

ConfigParameter(StartOffseti/Lengthi)

Set

Set

Set

SetRxConfigResponseAccept

CopiedCopiedNo data

SetRxConfigResponseReject

CopiedCopiedNo data

SetRxConfigResponsePropose

CopiedCopiedProposed configuration

Action Type
SetRxConfigRequest

2
3

3.2.4.11.3. Message sequence diagram

4

The message sequence diagram shown in Figure 31N is divided in three parts.

5
6

The first part of the sequence shows the case where the IWF type 1 initiates a mapping configuration and
IWF type 2 accepts the configuration.

7
8

The second part of the sequence shows the case where the IWF type 1 initiates a mapping configuration and
IWF type 2 rejects the configuration.

9
10
11
12

The last part of the sequence shows the case where the IWF type 1 initiates a mapping configuration and
IWF type 2 rejects the configuration but proposes another configuration instead. Then IWF type 1 initiates a
new mapping configuration with the one proposed by IWF type 2, and IWF type 2 accepts the new
configuration.

IWF1

IWF2

13
14

Figure 31N: Mapping configuration negotiation sequence examples

CPRI

56

eCPRI Specification V2.0 (2019-05-10)

1

3.2.4.12.

Message Type #11: IWF Delay Control

2

3.2.4.12.1. Description/Usage

34
5The Message Type “IWF Delay Control” is used to retrieve/report delay values from a remote device. A
typical use is to assist in the delay management of IWFs type 1 and type 2 in an eCPRI/CPRI interworking
scenario. The use of this message type is though not limited to this case.

6
7
8
9

In an eCPRI/CPRI IWF type 1 and type 2 scenario the IWF type 1 needs delay values from IWF type 2 to beable to calculate required operational parameters. By these calculated parameters and the “Timestamp” inthe “IWF Start-Up” messages the IWF type 1 can establish the CPRI frame timing. See section 8.7.2 andsection 8.9 for details on how and what IWF type 2 shall respond back to IWF type 1.

10

3.2.4.12.2. Message format

Byte
0
PC_ID
1
2

Delay Control ID

3

Action Type

4
Bytes
transmitted
from top
to bottom

5
Delay A

67
8
9
Delay B
10
11
0

7

MSB

LSB

11
12

Figure 31O: IWF Delay Control message format

13

Where:

14

•

o
o
o

15
16
17
18

•

19
20
21
22

PC_ID:
2-byte field identifier of a series of “IWF Delay Control” messages.
For example, identifier of destination CPRI node.
How to allocate values to PC_ID is vendor specific.

Delay Control ID:
The Delay Control ID is a 1-byte value used by the sender of the request when the response isreceived to distinguish between different Delay Control signals, i.e. the receiver of the request shallthus copy the ID from the request into the response message.

•

Action Type:

CPRI

57

1

eCPRI Specification V2.0 (2019-05-10)

The Action Type is a 1-byte value described in Table 14C.

2

Table 14C: Action Type
Action Type

Description

0x00

Request get delays

0x01

Response get delays

0x02 … 0xFF

Reserved

3
4
5
6
7
8

•

Delay A/Delay B:
When Action Type is set to 0x00 (“Request get delays”) or 0x01 (“Response get delays”) the “Delay A”
and “Delay B” fields are 4-byte values. The unit of the values is 1/16 ns. For example, a value of
15.5ns will be represented as 0x000000F8. For Action Type 0x00 (“Request get delays”) both “DelayA” and “Delay B” are set to zero.

9

3.2.4.12.3. Message sequence diagram

10
11

A message sequence diagram is shown in Figure 31P. It shows the sequence when IWF type 1 requests
delay values from IWF type 2.
IWF type 1

IWF type 2

1213Figure 31P Message sequence diagram for IWF Delay Control

14
15

3.2.4.13.

Message Type #12 - #63: Reserved

16

eCPRI Message Types from 12 to 63 are reserved for future eCPRI specifications.

17

3.2.4.14.

18
19
20

eCPRI Message Types from 64 to 255 are not defined in eCPRI. These are for vendor specific usage.
Vendor specific message types shall not be reserved (before any specific usage is defined) by any 3 rd parties(other than CPRI and vendors).

21

Vendor specific usage shall be guaranteed.

22

3.3. C&M Plane

23
24

Control and management information will be exchanged between eCPRI entities (eREC and eRE) on any
commonly used transport protocols. The C&M information will not be transmitted via the eCPRI specificMessage Type #64 - #255: Vendor Specific

CPRI

58

eCPRI Specification V2.0 (2019-05-10)

1
2

protocol. The details of this information flow are out of the scope of the eCPRI specification. This information
can use protocols (e.g. TCP) over the IP protocol but any other solution is not precluded.

3
4
5
6

The C&M information flow will be considered as non-time-critical and utilize a small part of the total
bandwidth between eCPRI entities. The majority of this information flow will be considered as backgroundtraffic, the rest are interactive traffic that is needed to keep control of the eCPRI node. See section 6.5.2 forconsiderations regarding priority for C&M data.

7

3.4. Synchronization Plane

8
9
10
11
12

The eCPRI nodes shall recover the synchronization and timing from a synchronization reference source, andthe air interface of the eRE shall meet the 3GPP synchronization and timing requirements. The
synchronization information will not be transmitted via the eCPRI specific protocol. The details of thisinformation flow are out of the scope of the eCPRI specification. This information flow can use existing
protocols (e.g. SyncE, PTP) but any other solution is not precluded.

13
14

The synchronization information flow will be considered as time-critical and will utilize a small part of the total
bandwidth between eCPRI nodes.

15

3.5. QoS

16
17
18
19

The quality of service (QoS) control for eCPRI is implemented by setting different priority for different traffic
flows depending of the needed quality of service. If the eCPRI fronthaul network is Ethernet-switched thepriority field (PCP field) in the VLAN-tag shall be used for QoS of eCPRI, see further details below. If theeCPRI fronthaul network is IP-routed the Differentiated Services (DiffServ) can be used.

20

3.5.1.

21
22
23
24

For an Ethernet network with Ethernet bridges a VLAN tag according to the IEEE 802.1Q-2014 [14] shallalways be added by the eRE or eREC and provided to the Ethernet network. The VLAN ID does not need to
be set if only the priority is used in the VLAN tag. In that case the VLAN ID (VID field) is set to zero (the null
VID). The priority is set in the PCP field of the VLAN tag.

25
26
27

Normally a C-tag with a priority in the PCP field is set by the eCPRI nodes (VID is optional), but other cases
may exist depending on the network type and what kind of customer service interface to the network is used.
For further details and options see [14].

2829

The use of the VLAN ID (VID field), including the null VID, is fully vendor specific and agreed with the
network provider.

30

How to use the priority field (PCP field) is vendor specific. See section 6.5.2.

31

3.5.2.

32
33
34

QoS for IP-routed fronthaul network can be done by DiffServ. The DiffServ uses the DSCP field in the
differentiated services field (DS field) in the IP header for classification purposes. How to use the DSCP fieldfor QoS in an IP-routed fronthaul network is fully vendor specific.

35

Other ways to implement QoS in an IP-routed fronthaul network are possible.

VLAN Tagging for Ethernet-switched fronthaul networks

QoS for IP-routed fronthaul networks

CPRI

59

eCPRI Specification V2.0 (2019-05-10)

1

4. Forward and Backward Compatibility

2

In order to allow for forward and backward compatibility of eCPRI, the following requirements are introduced.

3

4.1. Fixing eCPRI Protocol Revision Position

4
5

For forward and backward compatibility, the eCPRI Protocol Revision field in the common header shall be
fixed in all revisions. This is in order to find the eCPRI protocol revision correctly.

6

4.2. Reserved Bits and Value Ranges within eCPRI

7
8
9
10

Within the eCPRI message format some data parts are reserved for future use by the CPRI specificationgroup. These parts may be used in future releases of the eCPRI specification to enhance the capabilities or
to allow the introduction of new features in a backward compatible way. The reserved data parts are of two
different types:

11
12

1. Reserved bits in the eCPRI common header or reserved bits within a specific message payload.
2. Reserved value ranges in both eCPRI common header and within a specific message payload.

13
14

Reserved data parts of type 1: the transmitter shall send 0’s for the reserved bits, and the receiver shall notinterpret the reserved bits.

15
16
17

Reserved data parts of type 2: the transmitter is only allowed to use values that are defined by thisspecification or as defined within a vendor specific range. The receiver shall discard the message when
receiving a message with illegal values.

18

4.3. eCPRI specification release version

19
20

The eCPRI specification release version is indicated by two digits (version A.B). The following text defines
the digits:

21•

The first digit A is incremented to reflect significant changes (modification of the scope, new section…).

22
23

•

The second digit B is incremented for all changes of substance, i.e. technical enhancements,
corrections, updates etc.

24
25

4.4. Specification release version mapping to eCPRI protocol
revision26
27
28

The eCPRI common header field “eCPRI Protocol revision” indicates the protocol version number, which will
be denoted by 1, 2, 3, … The protocol revision number will be incremented only when a new specification
release version includes changes that lead to incompatibility with previous specification release versions.

29
30
31

The simple sequence and the well-defined rule for non-compatibility between different specification release
versions allows for a simple, efficient and fast start-up procedure. The following table provides the mapping
between specification release version and protocol revision number.

32

Table 15: Specification release version and protocol revision numbering
Specification
release version

Available eCPRI protocol Comment
revision values

1.0, 1.1, 1.2, 2.0

0001b

The interpretation of the eCPRI message shallfollow eCPRI specification versions up to 2.0.

0010b-1111b; 0000b

Reserved for future eCPRI protocol revisions.
Unallocated values can temporarily be used forvendor specific extensions until allocated.

CPRI

60

1

eCPRI Specification V2.0 (2019-05-10)

This table shall be updated when new specification release versions become available.

CPRI

61

1

5. Compliance2

An eCPRI compliant interface shall fulfill the following requirements:

eCPRI Specification V2.0 (2019-05-10)

3•An eCPRI compatible interface shall follow the normative parts of this specification.

4•

One or more eCPRI Message Types are used over the interface for eREC and eRE communication.

5•

eCPRI Message Types in use are implemented as per their defined requirements.

6

An eCPRI compliant IWF type 1/2 implementation shall in addition follow section 8 of this specification.

CPRI

62

eCPRI Specification V2.0 (2019-05-10)

2

6. Annex A - Supplementary Specification Details(Informative)3

6.1. Functional Decomposition

4

6.1.1.

5
6
7
8

The functional content of the PHY layer and a typical processing order is shown in Figure 32. Process stages
marked with grey text are optional, i.e. in a non-massive antenna configuration those stages are not present.
The eCPRI specification focuses on three different reference splits, two splits in downlink and one split in
uplink (Split I , II and I ). Any combination of the different downlink/uplink splits is possible.

910

Nevertheless, any other split within the PHY layer (and also any other inter/intra layer split) is not precluded
to be used with the eCPRI specification.

11
12

The major difference between Split I and II is that the data in Split I is bit oriented and the data in split II
and I is IQ oriented.

13
14
15
16
17

In Figure 32 only the data plane processing stages are shown, but in parallel to this, a user data real time
control flow also exists. Depending on where the split is, this real-time control data is e.g. modulation
scheme, Tx power, beamforming information etc. The bit rate of this real-time control flow differs between
different splits. As a rule of thumb the closer to the MAC layer the split is, the more real time control dataneeds to be sent between the two eCPRI nodes eREC and eRE.

18
19
20
21
22

It is possible to implement e.g. a PRACH preamble detection process in the eRE and handling of SRS in theeRE thus lowering the bit rate needs in the uplink direction, these options/possibilities are however notshown in Figure 32. Also, in the downlink direction the reference signals and synchronization signals could
be generated internally on the eRE with just an initial configuration by the eREC, this is not shown in the
figure either.

23
24
25
26
27
28
29
30

One of the major objectives of a new functional split between eREC and eRE compared to the classical
CPRI functional split is to lower the bit rates on the fronthaul interface. When looking at the different
processing stages performed in the PHY-layer (see Figure 32) in downlink direction, three processes will
mostly increase the bit rate. These three processes are modulation, the port-expansion being done in
combination with the beamforming process and the IFFT+cyclic-prefix-process (i.e. going from the frequency
domain to the time domain). By moving the split upwards in the figure the fronthaul bit rate will be loweredand vice versa. But conversely the bit rate for the user plane real-time control data will increase when moving
the split point towards the MAC layer and vice versa.

1

eCPRI Functional Decomposition

D

D

U

D

D

D

D

U

CPRI

63

eCPRI Specification V2.0 (2019-05-10)

RLC

RLC

MAC

MAC

CodingDecoding

Rate
Matching

Rate
Matching

Scrambling

Descrambling

ID

D

Demodulation

Modulation

PHY

iDFT *)IID

Layer
Mapping
Equalization
Diversity
Combiner

Precoding
TX Power

ChannelEstimation
Resource
Element
DemappingResource
Element
Mapping

IU

Port
Reduction

Beamforming
Port Expansion

iFFT

FFT

Cyclic Prefix
Insertion

Cyclic Prefix
RemovalRF

RFE*) Mandatory processing stage for 4G,
optional for 5G according to 3GPP
Technical Specification 38.300 section 5.1

1
2

Figure 32: PHY layer and eCPRI splits

CPRI

64

eCPRI Specification V2.0 (2019-05-10)

1

6.1.2.

Bit Rate Calculations / Estimations

2
3
4
5
6
7

When making the decision for what split to implement one major issue will be the bit rate capacity on the link
between the eREC and the eRE. When moving the split point from the MAC-PHY boundary towards the RF
layer the bit rate will increase for each step. This applies for the user data, the opposite is true for the control
data needed to process the data on the eRE, i.e. the bit rate for the control data will decrease when moving
the split towards the RF layer. However, the sum of the bit rates for the user data and the control data will not
remain the same.

8
9

It is assumed that the control algorithm for e.g. beamforming resides in the eREC and that control data forthese stages must be transmitted from eREC to eRE.

1011

When going to a split that is above the split E there are many factors that will have an impact on the final
needed bit rate of the link between eREC and eRE. The most relevant factors are:12•

Throughput (closely related to the available and used air bandwidth)13•

Number of MIMO-layers

14•

MU-MIMO support (y/n)

15•Code rate

16•

Modulation scheme

17•

Beamforming algorithm

18•

Number of antennas

19
20

When making a comparison of the needed bit rate between an eCPRI split and the classical CPRI split (splitE) one needs to set a specific use case.

21

Among the abovementioned factors, only the “Number of antennas” has an impact on the bit rate for split E.

22
23
24
25

There are on the other hand other factors that have an impact on the needed bit rate for a split E
implementation as well which are not mentioned in the bullet list above. These factors are mainly: sample
frequency for the IQ-data, used IQ-format (number of bits per IQ-sample) and the presence of IQ
compression algorithms or not.

26

6.1.2.1.

27

eCPRI has no limitation with respect to the factors mentioned in the previous section.

28

As an example, the following values are used for the forthcoming bit rates calculations:

29•

Throughput: 3/1.5 Gbps (downlink/uplink, end-user data rate, transport block from/to MAC)

30•

Air bandwidth: 100 MHz (5 * LTE20) -> 500 PRB

31•

Number of downlink MIMO-layers: 832•

Number of uplink MIMO-layers: 4 (with 2 diversity streams per uplink MIMO layer)

33•

MU-MIMO: No

34•

TTI length: 1 ms

35•

Digital beamforming where BF-coefficients calculation is performed in eREC.

36•

Rate matching assumptions: Code rate: ~0.80

37•Modulation scheme (Downlink & Uplink): 256 QAM

38•

Number of antennas: 64

39•

Sub-carrier spacing: 15 kHz

40•

IQ sampling frequency: 122.88 Msps (3.84*32)

41•

IQ-format: 30 bits per IQ-sample

42•

No IQ compression

Bit Rate Calculation Example

CPRI

65

1

eCPRI Specification V2.0 (2019-05-10)

Table 16: PHY layer splits bit rate estimations for the example use case above
Split D

eREC→
eRE

Split ID

Split IID

Split E

User Data[Gbps]

Control[Gbps]

User Data[Gbps]

Control[Gbps]

User Data[Gbps]

Control[Gbps]

User Data[Gbps]

3(assumption)

<< 1

<4

< 10

~ 20

< 10

236

~ 20

< 10

236

Split IU

eRE →
eREC

1.5
(assumption)

<< 1

~ 20

< 10

2
3

6.2. Synchronization and Timing

4
5
6

An eCPRI node shall recover the frequency and time/phase from its synchronization reference source (seeFigure 3). In an eCPRI installation all eCPRI nodes (eRECs and eREs) need to be time synchronized to acommon time reference, see sections 6.2.1 and 6.2.2 for more information.

7

Different solutions exist for synchronization of eREC and eRE.

86.2.1.

9
10
11
12
13
14
15

Depending on which 3GPP features a specific eCPRI installation supports, different timing accuracy
requirements are applicable for the eRE node. [15] defines four different timing synchronization requirement
categories each one targeting different timing accuracy requirements for different use cases. The different
categories will supply different timing accuracy at the edge of the fronthaul network, i.e. “almost” at the inputport on the eRE. With the knowledge of the expected supplied timing accuracy it will be possible toimplement an eRE that will fulfill the final timing accuracy requirement on the air interface according to the
3GPP requirements.

16
17

The eRE shall also fulfill requirements set by 3GPP on the transmission frequency accuracy and the phasenoise (implicit requirement).

18

6.2.2.

19
20
21
22
23
24
25
26

The timing accuracy requirement on the eREC is relaxed compared to the requirement set on the eRE (see6.2.1). Actually, the eREC does not need to have a high quality frequency available since it is the eRE thatwill generate the frequency for air transmission locally. Nevertheless, there will be a vendor specificrequirement set on the eREC regarding the eREC timing accuracy. Such a requirement is needed to be able
to send data at correct time to the eRE from the eREC thus to give the eRE time for its processing of thedata before being transmitted on the air interface and for buffer handling due to network latency variation.
The requirement value depends on vendor specific choices related to desired performance for the wirelessnetwork, expected delay variation in fronthaul network etc.

27

6.2.3.

28
29

The synchronization requirements for IWF type 0 are similar to (or may be tighter than) those of an eRE, see
Section 7.4.

30

The synchronization requirements for IWF types 1 and 2 are for further study.

31

6.3. Link Delay Management

32
33
34

The following section provides a description of the link delay management in eCPRI. Figure 33 shows anexample of an eREC and eRE connected via an eCPRI network. Both eREC and eRE clocks aresynchronized to a common grand master clock (in this example via PTP).

Synchronization of eRE

Synchronization of eREC

Synchronization of IWFs

CPRI

66

eCPRI Specification V2.0 (2019-05-10)

GM
3

eREC
1

1

...

3
2

2

...

...

3
1
2

DL/UL data patheREsynchronization path1
2

Figure 33: eCPRI topology example with synchronization via PTP

3

6.3.1.

Reference Points for Delay Measurement

4
5

The reference points for delay management are the input and the output points of the equipment, i.e. theconnectors of eREC and eRE as shown in Figure 34.

678Reference points R1 to R4 correspond to the output point (R1) and the input point (R4) of the eREC, and the
input point (R2), and the output point (R3) of an eRE. The antenna is shown as “Ra” forreference.

T1a (= T12 + T2a)
R1

eREC

Ra

T12

T2a

R2

R4

R3

T34

eRE
Ta3

Ta4 (= Ta3 + T34)
910

Figure 34: Definition of reference points for delay management

11

The definitions for the different delays are given in the remaining of this section.

12
13
14
15
16
17
18

Note: The eRE delay definitions refer to the delay between the transmission/reception of an IQ sample at theantenna Ra and the reception/transmission of data packets containing the corresponding information at thefronthaul interface R1/R4 (eREC) and R2/R3 (eRE). In case of time domain IQ functional split, theassignment is straight forward since an eCPRI message carries IQ samples. In case of frequency domainfunctional split, the information associated to an IQ sample is contained in a set of N packets, e. g. frequency
domain IQ data for one OFDM symbol + related control information or user data for one OFDM symbol +related control information.

CPRI

67

eCPRI Specification V2.0 (2019-05-10)

1Please note that N can vary per symbol/TTI according to the number of users/used resource blocks.

2
3
4

•

T12 is the transport network delay of a user data packet between eREC (R1) and eRE (R2) in DL
direction. T12 may not be constant for every data packet and shows a statistical variation, but its range
is limited by e.g. the profile of deployed transport network:
0 ≦ T12 min ≦ T12 ≦ T12 max

5
6

Where:

7o

T12 max is given as the maximum one-way end-to-end latency, see e.g. [15].

8
9
10

o

T12 min is 0 in general, but in case the minimum latency of some or all network elements are
known, it can be determined by the sum of all fiber delays and minimum forwarding delays ofthe network nodes along the DL data path.

11
12
13

•

T34 is the transport network delay of a user data packet between eRE (R3) and eREC (R4) in UL
direction. T34 may not be constant for every data packet and shows a statistical variation, but its range
is limited by e.g. the profile of deployed transport network:
0 ≦ T34 min ≦ T34 ≦ T34 max

14
15

Where:

16o

T34 max is given as the maximum one-way end-to-end latency, see e.g. [15].

17
18
19

o

T34 min is 0 in general, but in case the minimum latency of some or all network elements are
known, it can be determined by the sum of all fiber delays and minimum forwarding delays ofthe network nodes along the UL data path.

20
21
22
23

•

T1a is the timing difference between the transmission of a user data packet at the output point R1 ofthe eREC and the transmission of IQ samples at the antenna Ra of the eRE. The transmission of theearliest IQ sample which is generated from the transmitted user data is used as the reference timing at
the antenna Ra. T1a may not be constant but its range is limited by e.g. eREC design specification:
0 ≦ T1a min ≦ T1a ≦ T1a max

24
25

Where:

26
27
28

o

29
30
31
32

•

Both T1a min and T1a max are vendor specific values; in general, T1a min is related to the bestcase processing time of user data and T1a max is related to the worst case processing time andthe output buffer size.

T2a is the timing difference between the reception of a user data packet at the input point R2 of eRE
and the transmission of IQ samples at the antenna Ra. The transmission of the earliest IQ sample
which is generated from the received user data is used as the reference timing at the antenna Ra. T2a
may not be constant but its range is limited by e.g. eRE design specification:
0 ≦ T2a min ≦ T2a ≦ T2a max

33
34

Where:

35
36
37

o

Both T2a min and T2a max are vendor specific values; in general, T2a min is related to theworst case eRE processing time of user data and T2a max is related to the input buffer size andthe worst case eRE processing time.

38
39
40

o

If a user data packet arrives outside of this reception window (i.e. earlier than T2a max or later
than T2a min), the user data packet may not be used and consequently IQ samples related tothis user data packet may not be generated correctly.

41
42
43
44
45

•

Ta3 is the timing difference between the reception of IQ samples at the antenna Ra and thetransmission of a user data packet at the output point R3 of eRE. The reception timing of the earliest
IQ sample necessary to generate the user data packet is used as the reference timing at the antenna
Ra. Ta3 may not be constant but its range is limited by e.g. eRE design specification:
0 ≦ Ta3 min ≦ Ta3 ≦ Ta3 max

CPRI

68

1

Where:

2
3
4

o

5
6
7
8

•

eCPRI Specification V2.0 (2019-05-10)

Both Ta3 min and Ta3 max are vendor specific values; in general, Ta3 min is related to the bestcase eRE processing time of user data and Ta3 max is related to the worst case eRE
processing time and the output buffer size.

Ta4 is the timing difference between the reception of IQ samples at the antenna Ra of the eRE andthe reception of a user data packet at the input point R4 of the eREC. The reception timing of theearliest IQ sample necessary to generate the user data packet is used as the reference timing at theantenna Ra. Ta4 may not be constant but its range is limited by e.g. eRE design specification:
0 ≦ Ta4 min ≦ Ta4 ≦ Ta4 max

910

Where:

11
12
13

o

Both Ta4 min and Ta4 max are vendor specific values; in general, Ta4 min is related to the
input buffer size and the worst case eREC processing time. Ta4 max is related to the eREC
worst case processing time of user data.

14
15
16

o

If a user data packet arrives outside of this reception window (i.e. earlier than Ta4 min or later
than Ta4 max), the user data packet may not be used and (a part of) the UL user data may belost or degraded.

17
18
19
20

The DL timing relations are shown in Figure 35. eREC and eRE clocks are synchronized to a common GM
and it is assumed that both eREC and eRE know the timing relation between air frame start and their clocks.
The time point when the first IQ sample of a DL air frame has to be transmitted at the antenna is indicated by
the red line on the right.

21

By definition, the following equation has to be satisfied:22

T1a = T12 + T2a

23
24
25

This equation implies that fluctuation of transport network latency and the eREC transmission timing has tobe absorbed by the input buffer of eRE; moreover the minimum/maximum limits of these three variables are
not independent; i.e. the following conditions have to be met in order not to lose DL user data.

26

T1a min ≧ T12 max + T2a min

27

T1a max ≦ T12 min + T2a max

28“Tx window size at R1” ≦ “Rx window size at R2” - “max fluctuation of transport network latency”

29

Where:

30“Tx window size at R1” = T1a max - T1a min

31“Rx window size at R2” = T2a max - T2a min

32“Max fluctuation of transport network latency” = T12 max - T12 min

CPRI

69

eCPRI Specification V2.0 (2019-05-10)

Transmission Window
T1a max
eREC
R1

T1a min
#0

...

#n

...

#N-1

T12 minTransport
Network≧T12 max
T12 max≦T12 min

#0

...

#n

#0

...

#n

#n

...

...

#N-1

#N-1

R2
eRE
T2a max

Ratime

T2a min

Reception Window

IQ samples

The earliest IQ sample generated
from user data packet #0..#N-1

1
2

Figure 35: Timing relations in DL direction

3
4
5

The UL timing relations are shown in Figure 36. The time point when the first IQ sample of a UL air frame tobe received at the antenna is indicated by the red line on the left.

6

By definition, the following equation has to be satisfied:

7

Ta4 = Ta3 + T34

8
9

Therefore the minimum/maximum limits of these three variables are not independent; i.e. the following
conditions have to be met in order not to lose UL user data.

10

Ta4 min ≦ Ta3 min + T34 min

11

Ta4 max ≧ Ta3 max + T34 max

12“Rx window size at R4” ≧ “Tx window size at R3” + “max fluctuation of transport network latency”

13

Where:

14“Tx window size at R3” = Ta3 max – Ta3 min

15“Rx window size at R4” = Ta4 max – Ta4 min

16“Max fluctuation of transport network latency” = T34 max – T34 min

CPRI

70

eCPRI Specification V2.0 (2019-05-10)

The earliest IQ sample timing to
generate user data packet #0..#N-1

Ra

IQ samples
Transmission Window
Ta3 minTa3 max

eRE
R3

#0

...

...

#n

#N-1

≧T34 max

T34 min

T34 max≦T34 minTransport
Network

#0
R4

...

#n

#0

...

Ta4 min

#n

#n

...

...

#N-1

#N-1

Ta4 max

eREC
time

Reception Window

1
2

Figure 36: Timing relations in UL direction

3

6.3.2.

Delay Management example

4
5
6
7
8
9
10

Figure 37 shows a model of UL/DL eCPRI user data transmission between eCPRI nodes (eREC and eRE).
Both transmitter and receiver side of eCPRI nodes have buffer memories to absorb the fluctuation oftransport network delay as well as the variation of processing time in eCPRI nodes which depends on the
traffic and processing load. The goal of delay management is to avoid the overflow/underflow of buffer
memories and to decrease the overall delay, the necessary size of buffer memories, etc. at the same time.
Additionally, a sort of traffic shaping may be necessary at the transmitter side to avoid unnecessary traffic
congestion. Flow control with fast feedback loop is not considered in this example.

Internal
MemoryInput Buffer
MemoryTo MAC layer

Timing Management
UL PHY
Processing(upper part)

R2

R4

DL PHY
Processing(lower part)

RF
(Tx)

Internal
MemoryR3

UL PHY
Processing(lower part)C&M or user plane messages tomanage tx/rx timing

11
12

Ra

Timing Management

Output Buffer
MemoryInternal
MemoryR1
Transport Network(Fronthaul Network)

DL PHY
Processing(upper part)

Input Buffer
MemoryeRE
Output Buffer
MemoryFrom MAC layer

eREC

Figure 37: Delay management model example

CPRI

Internal
Memory

RF
(Rx)

71

1

eREC functions:

2
3
4



Measure the actual typical/maximum/minimum one-way delay between the eREC and the eRE (UL and
DL direction) in addition to the nominal maximum/minimum transport network delay and allocate theoptimum delay budget to the eREC, the eRE and the transport network.

5o

eCPRI service “one-way E2E delay measurement” is used.

6oMeasure the delay periodically if necessary.

7
8



eCPRI Specification V2.0 (2019-05-10)

Manage the transmission timing of UL/DL user plane messages in order to ensure that messages arriveat the eRE properly (i.e. within the reception windows at the eRE), considering:

9o

UL/DL frame timing at the antenna of the eRE (strictly defined by 3GPP specification)

10
11

o

Deadline of each user plane message (or a group of messages) for the eRE to start/complete
UL/DL processing to avoid buffer underflow.

12
13

o

The maximum size of the input buffer at the eRE as well as the remaining size to avoid buffer
overflow.

14
15

o

The actual delay of the transport network and processing time in the eRE based on reports fromthe eRE.

16
17



Declare the allowable reception window timing for each (or a group of) UL user plane message(s)relative to the air interface frame timing.

18
19

o

The end of the window (deadline) depends on the processing time in the eREC (vendor specific),
especially the HARQ related processing.

20oThe beginning of the window depends on the input buffer size in the eREC (vendor specific)

21
22



23

eRE functions:

24
25



Manage the transmission timing of UL user plane messages in order to ensure that messages arrive at
the eREC properly (i.e. within the reception windows at the eREC).

26
27



Declare the allowable reception window timing for each (or a group of) UL/DL user plane message(s)relative to the air interface frame timing.

Monitor the actual reception timing of (critical) user plane message and the input buffer status andrequest the eRE to adapt the transmission timing if necessary.

28oThe end of the window (deadline) depends on the processing time in the eRE (vendor specific).

29oThe beginning of the window depends on the input buffer size in the eRE (vendor specific).

30
31



Monitor the actual reception timing of (critical) user plane messages and the input buffer status andreport them to the eREC.

32o

At least, the occurrence of buffer overflow/underflow (late delivery) should be reported.

33
34

o

Reports may be transferred by C&M plane or eCPRI services (“Real-Time Control Data” or “Event
Indication”) depending on its time criticality.

35
36
37



38

Figure 38 shows an example of DL user data transmission timing between the eREC and the eRE.

39

In this example, we assume:40The eREC transmits user data each OFDM symbol interval (e.g. 67usec for LTE).

41

The eRE has an input buffer large enough to store full messages for 3 OFDM symbols.

42
43



Only worst cases (regarding min/max delay of transport network, maximum processing time in the eRE)
are considered.

44
45



The transmission timing of the first IQ sample of OFDM symbol #n at the eRE antenna Ra is used as
the reference timing. This timing is strictly defined by 3GPP specification, so fluctuation is not allowed.

Additionally, traffic shaping of UL user data may be necessary to avoid unnecessary transport network
congestion, especially in case the transport network bandwidth is shared by multiple synchronized TDD
eREs.

CPRI

72

eCPRI Specification V2.0 (2019-05-10)12The eREC transmits all user data packets which are necessary to generate OFDM symbol #n within thetransmission window [T1a max, T1a min] before its first IQ sample is transmitted from the eRE antenna.

34The eRE receives all user data packets which are necessary to generate OFDM symbol #n within thereception window [T2a max, T2a min] before its first IQ sample is transmitted from the eRE antenna.
T1a max
eREC

T1a minTransmission Window
for Symbol #n

R1

T12 minTransport
Networkmin delay (e.g. 0us)

T12 max
max delay (e.g. 100us)

...

R2

eRE

Deadline for
Symbol #n-1
Deadline for
Reception Window for Symbol #n-1
Symbol #n
Reception Window for Symbol #n
Input buffer ready
Reception Window for Symbol #n+1
for Symbol #n

PHY processing
time in eRE

Processing
symbol #n-3

Processing
symbol #n-2

Processing
symbol #n-1

Processing
symbol #n

Deadline for
Symbol #n+1
Processing
symbol #n+1

Worst caseprocessing timeRa

OFDM symbol#n-4

OFDM symbol#n-3

OFDM symbol
#n-2

time
T2a max

OFDM symbol#n-1
T2a min

5
6

OFDM symbol#n
The first IQ sample of
OFDM symbol#n

Figure 38: DL user data transmission timing example

7

6.4. Network Connection Maintenance

8
9

Network connection maintenance and network connection control is out of scope of the eCPRI specification.
There are a number of different methods and standards that can be used.

10
11
12
13
14
15
16
17

For the Ethernet parts of eCPRI (if applicable for the User plane data and for IP over Ethernet), the Ethernet
OAM can be used. Ethernet OAM is a common name for the IEEE 802.1Q [14] and ITU-T Recommendation
G.8013/Y.1731 [16]. The IEEE 802.1Q Ethernet CFM (Connectivity Fault Management) defines three
protocols, Continuity Check Protocol (CC), Link Trace (LT) and Loop-back (LB). ITU-T defines the samefunctions and tools in Y.1731 by the Ethernet continuity check (ETH-CC), Ethernet remote defect indication(ETH-RDI), Ethernet link trace (ETH-LT) and Ethernet loopback (ETH-LB), and also adds more OAM
functions like Ethernet alarm indication signal (ETH-AIS), Ethernet loss measurement (ETH-LM) or synthetic
loss measurement (ETH-SLM), and Ethernet delay measurement (ETH-DM).

18
19

For the IP parts of the eCPRI (e.g. the C&M flow), the Internet Control Message Protocol (ICMP) can beused. ICMP for IPv4 is defined in RFC 792 [17] and for IPv6 it is defined in RFC 4443 [18].

2021

An eCPRI node needs to have either a unique MAC address or a unique IP address. How to assign or getthese addresses is out of scope of the eCPRI specification.

22

CPRI

73

eCPRI Specification V2.0 (2019-05-10)

1

6.5. Networking

2

6.5.1.

3
4
5
6

This subsection describes the major differences between eCPRI and CPRI (e.g. CPRI v7.0). The main
audience of this section is anyone familiar with CPRI and who would like to understand the difference
between eCPRI and CPRI networking quickly. So it may not be of any use to new readers of eCPRI who are
not interested in CPRI.

7

Figure 39 shows an example network by CPRI. CPRI has the following characteristics:

8•

CPRI is a point-to-point interface by nature.

9•

There is a master-port and a slave-port connected directly by optical/electrical cable(s) (a hop).

10•

Networking functions are application layer functions and not supported by the CPRI interface itself.

11•

Supported topologies depend on REC/RE functions.

12•

Supported logical connections include:

Difference between eCPRI and CPRI

13o

Point-to-point (one REC – one RE).

14o

Point-to-multi-point (one REC – several REs).

15•

Redundancy, QoS, security, etc. are REC/RE functions (if required).

16
REC

Networking REC

SAP IQ, SAP CM, SAP S

SAP IQ, SAP CM, SAP S

Networking RE
SAP IQ, SAP CM, SAP S

Networking

CPRI

Master PortCPRI

Slave PortRE
SAP IQ, SAP CM, SAP S

Networking

CPRI

CPRI

Master Port

Slave PortCPRI

Master PortCPRI

Slave Port

LogicalConnection

17
18

Figure 39: Network by CPRI

19

Figure 40 shows an example network by eCPRI. eCPRI has the following characteristics:

20
21

•

An eCPRI network consists of eCPRI nodes (eRECs and eREs), transport network, as well as othernetwork elements not shown in Figure 40 (including GM/BC for timing, EMS/NMS for management).

22•

There is no longer a master port/slave port classification at physical level.

23oSAPS: master of PTP and Synchronous Ethernet is not a eREC in general.

24o

SAPCM: some of M-plane may be managed by EMS/NMS.

25•

The eCPRI layer is above the transport networking layer.

26•

The eCPRI layer does not care about the actual transport network layer topology.

27
28

•

The transport network may include some local network, e.g. local switch(es) provided by the eREC/eRE
vendors.

CPRI

74

1

•

eCPRI Specification V2.0 (2019-05-10)

Supported logical connections include:

2oPoint-to-point (one eREC – one eRE), same as CPRI.

3o

Point-to-multi-point (one eREC – several eREs), same as CPRI

45oMulti-point-to-multi-point (eRECs – eREs, eRECs – eRECs, eREs - eREs), new for eCPRI but notalways necessary.

6
7•

Redundancy, QoS, security, etc. are mainly transport network functions; eCPRI nodes need to
implement proper transport network layer protocols to support these capabilities if required.

8
eREC

eREC

eRE

eRE

SAPUP SAPCM, SAPSSAPUP SAPCM, SAPSSAPUP SAPCM, SAPSSAPUP SAPCM, SAPS

eCPRI

eCPRI

eCPRI

eCPRI

transport network (front-haul network)

LogicalConnection

9
10

Figure 40: Network by eCPRI

11

6.5.2.

eCPRI/CPRI networking with eCPRI/CPRI IWF type 0

12
13
14
15
16

This subsection describes a networking example of how CPRI REs can be connected to an eCPRI networkand eREC via eCPRI/CPRI Interworking Function (IWF) type 0. The eCPRI protocol is terminated by the
IWF. The IWF implements the master port of the CPRI interface. All information flows (User Plane, C&M
Plane and Synchronization and Timing) are bridged or routed at the higher layer over the eCPRI and CPRI
protocols. This is similar to the concept of the networking function of the CPRI Networking REC/RE.

17

Supported logical connections include:18oeREC and (networking) RE

19o

eREC and IWF, for the eREC to control and manage the IWF

20
21

o

IWF and (networking) RE, for the IWF to control and manage the (networking) RE as a proxy of the
eREC.

CPRI

75

eREC

eCPRI Specification V2.0 (2019-05-10)

Interworking function type 0

SAPU SAPCM SAPSSAPU SAPCM SAPS

eCPRI

SAPIQ SAPCM SAPSSAPIQ SAPCM SAPS

Networking

eCPRI

RE

Networking RE

SAPIQ SAPCM SAPSSAPIQ SAPCM SAPS

Networking

CPRI

CPRI
Slave Port

Master Port

CPRI

CPRI

Slave Port

Master Port

Transport network(fronthaul network)

Logicalconnection

1
2
3

Figure 41: Networking with eCPRI/CPRI Interworking Function type 04

6.5.3.

eCPRI/CPRI networking with eCPRI/CPRI IWF type 1 and type 2

5
6
7
8
9
10
11

This subsection describes a networking example of how a CPRI REC can be connected to a CPRI RE via an
eCPRI based transport network by using eCPRI/CPRI IWF type 1 and 2. The CPRI protocol is terminated by
the IWF, the IWF implements a “CPRI slave” and “CPRI master” port respectively, that are not fully compliant
with [1]. Further information regarding these special ports can be found in section 8. The CPRI information
flows (User Plane, C&M Plane and Synchronization Plane) are after transmitted over the eCPRI Network andsubsequently reconstructed by the IWF nodes. This tunneling, or pseudo wire concept is indicated in the
figure as an aggregation of the different SAPs.

12

The supported logical connection is:13o

REC and RE

14o

IWF type 1 and IWF type 2, to control and manage functionality between the IWFs

15
REC
SAPIQ SAPCM SAPS

Interworking function type 1
SAPIQ SAPCM SAPSSAPU SAPCM SAPSSAPU SAPCM SAPS

Networking

CPRI
Master Port

CPRI

RE

Interworking function type 2
SAPIQ SAPCM SAPSSAPIQ SAPCM SAPS

Networking

eCPRI

eCPRI

IWF Slave PortCPRI
IWF Master PortCPRI
Slave Port

Transport Network

16
17

Logicalconnections

Figure 42:

Networking with eCPRI/CPRI Interworking Function type 1 and type 2

18
19

Figure 43 shows a more detailed diagram of the functions typically implemented in IWF type 1 or type 2.

CPRI

76

eCPRI Specification V2.0 (2019-05-10)

IWF type 1 or type 2
IWF
C&M

1

Sync info

Management

Processing

Processing

User
Data

Control
Words

MUX

CPRI TDM
8B/10B or 64B/66B
8B/10B scrambler
64B/66B FEC, sync
64B/66B scrambler
PMD

PTP,
SCTP,
UDP/IP
UDP/IP
etc.
Ethernet MAC
Ethernet PHY

Media

Media

eCPRI
layer

eCPRI link

CPRI link

2

Figure 43: Protocol stack of Interworking Function type 1 or type 234
5

In the CPRI to eCPRI direction, IQ data and control word flows are extracted and combined with the CPRI
synchronization information (hyperframe boundary) to create eCPRI interworking messages to betransmitted over the fronthaul packet network.

6

6.6. Priority considerations

7
8
9

The User data and Real-Time Control data are the most time sensitive flows and normally require a highpriority. The traffic on the User Plane can in many cases be split into different kinds of traffic with different
need of QoS. In that case, it might be good, to have several priorities for the User Plane Data.

10
11
12
13
14

The C&M data flow is normally not time sensitive and can be set to a low priority. But it may be wise to have
two different priorities for C&M. One with lower priority than the User Plane Data that can be used for C&M
considered as background traffic, and one with higher priority than the User Plane Data for the interactive
traffic. The interactive traffic (including critical operation and emergency) needs to come through even if theamount of User Plane Data exceeds the available network bandwidth.

15
16
17
18

Note that for an Ethernet-switched fronthaul network there are only up to eight priorities available and in aprovider network other traffic might need at least one priority. So even if there are many traffic streams withdifferent QoS needs (e.g. for the User Plane Data) it will be good to keep down the total number of QoSlevels.

19

6.7. Message Ordering Considerations

20
21
22
23

The eCPRI transport network may not guarantee preservation of the eCPRI messages order (i.e. the order inwhich a sequence of eCPRI messages is transmitted by the source node may be different from the order inwhich the sequence is received at the destination node). Order preservation may not be guaranteed evenassuming the same priority, type of message, source node and destination node.

24
25

This is partially addressed by the inclusion of a sequence related ID field for some of the eCPRI Message
Types.

CPRI

77

eCPRI Specification V2.0 (2019-05-10)

1

6.8. Security

2
3
4

This section covers security considerations related to eCPRI traffic. If the transport network is not safe for aparticular flow then an eCPRI network end-to-end security system should be implemented in the eREC nodeand eRE node for that flow.

5

6.8.1.

6
7
8
9
10
11

eCPRI Network Security Protocol suites include IPsec in IP traffic and MACsec in Ethernet traffic， IPsec
and MACsec are designed to provide interoperable, high quality, cryptography-based security for IP and
Ethernet traffic. The set of security services offered includes access control, connectionless integrity, data
origin authentication, protection against replays (a form of partial sequence integrity), confidentiality(encryption), and limited traffic flow confidentiality. These services are provided at the IP or Ethernet layer,
offering protection for Ethernet or IP and/or upper layer protocols.

12

The details of IPsec and MACsec usage is vendor specific.

13

6.8.2.

14

Vendors can choose e.g. IPsec or MACsec to ensure security of transmission.

15

6.8.2.1.

16

User plane over IP:

17

•

18

User plane over Ethernet:

19

•

20

6.8.2.2.

21
22

TLS, IPsec or MACsec are optional solutions to provide transmission security and access control for eCPRI
C&M plane.

23

6.8.2.3.

24

There is no eCPRI recommendation for security aspects related to the synchronization plane.

eCPRI Network Security Protocol

eCPRI Network Security Specification

User plane

IPsec or MACsec are both optional solutions to provide transmission security.

MACsec is an optional solution to provide transmission security.

C&M plane

Synchronization plane

CPRI

78

eCPRI Specification V2.0 (2019-05-10)

2

7. Annex B – eCPRI/CPRI Interworking with IWF type 0(Informative)

3
4
5
6

The main purpose of IWF type 0 is allowing REs to be connected to an eREC via an eCPRI network andreused as eREs to support new services, e.g. 5G NR. In this informative section, a functionality to bridge
eCPRI and CPRI (eCPRI/CPRI Interworking Function, IWF) is described. There are different examples of
IWF type 0 use cases, such as:

1

7
8
9
10

o

IWF type 0 is a functionality, not necessarily in an independent node, i.e. it could be in
eRECs/eREs or transport network nodes (e.g. bridges/routers) as well as in independent nodes. If
it is within an eRECs/eREs, the concept is similar to networking CPRI REC/RE where networking
function is within the CPRI REC/RE.

11
12
13

o

IWF type 0 could be located at the cell-site close to CPRI REs, then the general packet-basedtransport network can be used (including the access link from the edge of the central network to thecell-site).

14
15
16

o

IWF type 0 could be located at the edge of the central network, e.g. at the central office, then the
new services by eREC could be added without changing the original CPRI access link and CPRI
REs.

CPRI

79

eCPRI Specification V2.0 (2019-05-10)

CPRI

RE

LTE

IP
Transport Network
IP
BackhaulREC[1] Current LTE system without eCPRI

Ethernet
fronthaul

CPRI

eREC
IP
Transport NetworkIPbackhaul

RE

LTE

eRE

NR

REC

[2] Possible 5G system with eCPRI v1.0

CPRI
Ethernet
fronthaul

eREC
IP
Transport Network
Ethernet
fronthaul

RE

LTE/NR

eRE

NR

IWF

[3] General 5G systems with eCPRI v2.0 (IWF type 0)
CPRI
I

RE

eRE

IP .eREC WF
Transport
Network

eREC
IP
Transport
Network

NR

Ethernet
fronhaul

I
W

F

RE

LTE/NReRE

NR

Ethernet
fronthaul

Ethernet
fronthaul

1
2

CPRI

LTE/NR[3.a 3.b] Implementation examples of 5G systems with eCPRI v2.0 (IWF type 0)
Figure 44: eCPRI/CPRI IWF type 0 possible migration scenarios

CPRI

80

1

7.1. Concept

2

The IWF type 0 acts as a proxy for the REC and eRE.

eCPRI Specification V2.0 (2019-05-10)

3
4
5

o

From the eREC viewpoint, “IWF type 0 and an RE connected via CPRI link” is considered as aneRE. Exceptions are C&M plane and Connection OAM. Independent Control & Management may
be necessary for each node and link.

6
7oFrom the RE viewpoint, “IWF type 0 connected to an eREC via eCPRI network” is considered as
an REC.

89o

The bridging of information flows between the eCPRI and the CPRI within the IWF type 0 is
implemented at the higher layers of the eCPRI and CPRI protocol stacks.

10
11

o

As the definitions of higher layer protocols are vendor specific, only guidelines of how eCPRI
information flows are mapped from/to CPRI information flows are provided.

12oThis concept is similar to the CPRI networking REs (e.g. daisy chained REs).
looks likean REC

Antennalooks likean eRE

eREC

IWF

eCPRI transport network

CPRI link

type 013
14

Figure 45: Concept of eCPRI/CPRI IWF type 0

15

Table 17 shows how information flows over eCPRI and CPRI can be mapped.

CPRI

RE

81

1

eCPRI Specification V2.0 (2019-05-10)

Table 17 An example of mapping between eCPRI and CPRI information flows
eCPRI
Section
3.2

SAP & Plane
User Plane

CPRI
Contents

SectionMessage Type #0:
IQ data

4.2.7.2

SAP & Plane
User Plane

Contents
AxC Container
IQ

Message Type #1:
Bit Sequence
3.2

User Plane (realtime control)

Message Type #2:
Real-Time Control
Data

4.2.7.9

User Plane

4.2.7.10

Vendor Specific
Data
Control AxC Data

3.3

C&M Plane(standard protocols)

4.2.7.7

C&M Plane

Slow C&M or Fast
C&M

3.4

Synchronization(standard protocols
like PTP and SyncE)

4.2.7.5

Synchronization
and Timing

Frame Timing

Message Type #5 ,6,
7:
One-way delay
Measurement

4.2.7.6

L1 inband
ProtocolProtocol Version

6.2
3.2

User Plane(other eCPRI
services)

Remote reset
Event indication
6.4

Connection
OAM

4.2.8

4.2.10Link
maintenance ofPhysical Layer

HFN, BFN

Start-up (HDLC
bit rate)
LOS, LOF, RAI,
SDI
Reset Req/Ack(standard protocols
like Ethernet OAM)

Pointer p27.2. Bridging of User Plane

3
4
5
6
7
8
9
10
11
12

Downlink IQ data in CPRI AxC containers is generated from eCPRI Message Type #0 (time-domain or
frequency-domain IQ Data) and/or eCPRI Message Type #1 (Bit Sequence). If data rate reduction oftransport network is not an essential requirement (this may be the case if the RE has neither many antenna
elements nor a wide radio bandwidth) and if the eREC can generate time-domain IQ, then time-domain IQ
Data is transferred by eCPRI Message Type #0, (function decomposition “E” in Figure 32). If data rate
reduction is required and/or the eREC does not generate time-domain IQ data, then eCPRI Message Type#0 (frequency-domain IQ, the function decomposition IID in Figure 32) or eCPRI Message Type #1 (Bit
Sequence, the function decomposition ID in Figure 32) are used. In this case, the IWF must include additional
functions (e.g. functions included between ID/IID and E). These additional functions are assumed as thesimple and open methods of data rate reduction.

13
14
15

Uplink IQ data in AxC containers are converted to eCPRI Message Type #0. Similar to the downlink case, IQ
data, time-domain IQ (function decomposition E) or frequency-domain IQ (function decomposition IU) can beused depending on the requirements.

16
17

eCPRI Message Type #2 is also used if associated information (real-time control) to IQ Data or Bit Sequenceis necessary.

18
19
20
21
22
23

If CPRI Vendor Specific Data and/or CPRI Control AxC Data are used, they are generated/converted from/toeCPRI Message Type #2 (real-time control data). The timing relation between CPRI AxC containers and
CPRI Vendor Specific Data/Control AxC Data can be maintained by the SEQ_ID in eCPRI Message Type#0, #1 and #2. In the CPRI specification [1], example use cases of Control AxC Data are shown such as:
GSM frequency hopping information, UMTS RTWP measurement report. Such information can be easily
carried by eCPRI Message Type #2 and associated with IQ Data by SEQ_ID.

24
25
26

Figure 46 shows two examples of protocol stacks in IWF type 0. The left part shows an example where timedomain IQ data is bridged across and the right part shows an example where frequency-domain IQ data isbridged across.

CPRI

82

eCPRI Specification V2.0 (2019-05-10)

Time-domain IQ
Unpack/PackeCPRI protocol
layer

User Data(Message
Type#0)Time-Domain
IQ Data

CPRI IQ mappingin AxC(s)UDP/IP
Ethernet MAC

CPRI PHY
Ethernet PHY

eCPRI Protocol StackeCPRI Protocol Stack

Real-Time
Control(Message
Type#2)

Freq-domain IQ
Pack/Unpack

CPRI Protocol Stack

Time-domain IQ
Pack/Unpack
User Data(Message
Type#0)Frequency-Domain IQ Data

Real-Time
Control(Message
Type#2)eCPRI protocol
layer

IFFT/FFT
CP add/remove
Time-Domain
IQ Data

CPRI IQ mappingin AxC(s)UDP/IP
Ethernet MAC

CPRI PHY
Ethernet PHY

CPRI Protocol Stack

Time-Domain IQ Data1
2
3

Figure 46: Example of User Plane Bridging in IWF type 0

7.3. Bridging/Routing of C&M Plane

56

In CPRI, two transport protocols are defined for C&M plane, namely slow C&M (HDLC based) and fast C&M(Ethernet based). However, any higher protocols over HDLC or Ethernet can be used.

78

In eCPRI, no protocols are defined for C&M plane as it is easy to use any existing standard protocols over
IP/Ethernet.

9
10
11
12
13

If there is no strong motivation to use different higher layer protocols over IP for eCPRI and CPRI, IP routing
is the functionality required for IWF C&M plane routing. C&M plane for the IWF itself (eREC-IWF) is
terminated at the IWF and C&M plane for the CPRI REs (eREC-RE) is routed to CPRI SAPCM. Additionally, a
C&M plane between the IWF and the CPRI RE may also be necessary. Figure 47 shows an example of the
protocol stacks in the IWF type 0 for this IP routing scenario.

Higher Layer
Protocols for
eCPRI C&M
(eREC-IWF)

Higher Layer
Protocols for
CPRI C&M(IWF-RE)
IP Routing

IP

IP
Fast/Slow C&M

Ethernet MAC

HDLC, Ethernet

Ethernet PHY

CPRI PHY

CPRI
ProtocolStack

General Protocol Stack for eCPRI

4

14
15

Figure 47: Example of C&M plane Routing in IWF type 0

CPRI

83

eCPRI Specification V2.0 (2019-05-10)

1

7.4. Bridging of Synchronization Plane2
3
4

All eCPRI nodes (eRECs, eREs and IWFs) are assumed to be time and frequency synchronized to one
master time clock (e.g. UTC), whereas CPRI does not assume all CPRI nodes are synchronized but slave
ports have to be synchronized to their master ports.

5
6
7
8

In the case where CPRI REs are connected to an eCPRI network via IWF, all nodes including CPRI REs
shall be time and frequency synchronized to one master time clock (e.g. UTC). This can be easily achieved
because all IWFs are time and frequency synchronized to one master clock and each CPRI RE (CPRI slaveport) is time and frequency synchronized to an IWF type 0 CPRI master port.

9
10
11
12

The one-way delay between the IWF and the RE (CPRI link) can be measured by CPRI standard method
and is constant. So, the overall delay between eCPRI interface points (R2 and R3) in the IWF and theantenna ports in the RE is equal to the internal delay T2a and Ta3 within the assumed eRE (IWF + CPRI link+ RE).

13
14

If the time relation between radio frames at the antenna ports of the eREs/REs and the master time clock(e.g. UTC) is pre-defined, the IWF can generate the radio frame timing (including HFN and BFN).
T2a = CPRI delay + IWF and RE internal delay (DL)T1a = T12 + T2a
T12

R1

eREC

T2a

R2

eCPRI transport network
R4

R3

T34

Ra

IWF
type 0CPRI linkRE

Ta3

Ta4 = Ta3 + T34

Ta3 = CPRI delay + IWF and RE internal delay (UL)

15
16

Figure 48: Definition of Reference Points for Delay Management of eCPRI/CPRI IWF type 0177.5. Bridging of L1 inband protocol

18
19

CPRI L1 inband protocol is classified into three categories. The mapping between eCPRI and CPRI is
explained per category.

20
21
22

•

Information necessary to establish CPRI link and C&M plane (start-up Sequence). This category is
terminated at link-by-link level. There is no direct relation with eCPRI network (similarly to Ethernet bit
rate negotiation):23

oProtocol version

24

oHDLC bit rate

25oPointer p (Ethernet bit rate)

26
27
28

•

Information necessary to monitor CPRI link status (alarms). The CPRI link status is monitored by themaster port of the IWF type 0 and reported to the eREC by C&M plane between eREC and the IWF type0 via eCPRI Message Type #7 “Event Indication”:

29

o

LOF

30

o

LOS

31

o

RAI

32

o

SDI

33
34
35
36
37

•

Information necessary for emergency control. If only the RE is out-of-control by CPRI C&M plane, resetof the RE is managed by the eREC via the eCPRI C&M plane between the eREC and the IWF type 0. If
the IWF itself is out-of-control, eCPRI Message Type #6 may be used to reset the IWF. In this case themaster port of the IWF type 0 shall reset the RE and hence stop transmission of the RF signal, e.g.
automatically generating CPRI reset bit (other methods are also possible):

CPRI

84

o

1

eCPRI Specification V2.0 (2019-05-10)

Reset

2

7.6. Start-up Sequence

3•

eCPRI connection between eREC and IWF type 0 is established via transport network.

4o

IWF is time- and frequency-synchronized to the master time clock (e.g. UTC).

5o

C&M plane between eREC and IWF type 0 is established.

6
7
8

o

eREC knows the one-way delay between eREC and IWF type 0 via transport network. In the casewhere several REs are controlled by one IWF type 0 the Tx/Rx time windows at the eREC could bemanaged per RE (not per IWF type 0).

9•

eREC configures the CPRI master port(s) in IWF type 0.

10
11

o

All necessary information for CPRI master port(s) is sent to IWF type 0 via the C&M plane between
the eREC and the IWF type 0.

12oCPRI master port in IWF type 0 is now ready to start “CPRI start-up sequence”.

13•

eREC requests IWF type 0 to start “CPRI start-up sequence”.

14
15

o

C&M plane between eREC and RE as well as between IWF type 0 and RE is established if “CPRI
start-up sequence” is successfully completed.

16oeREC or IWF type 0 may request to optimize the CPRI line bit rate.

17
18

o

One-way delay of CPRI link between IWF type 0 and RE is measured. This delay is considered asa part of internal delay T2a and Ta3 in the assumed eRE (IWF type 0 + CPRI link + RE).

19
20

o

eREC has now all necessary information of the assumed eRE configuration including the internaldelays T2a and Ta3.

21o

The assumed eRE (IWF type 0 + CPRI link + RE) is now ready to start operation.

22•

eREC requests IWF type 0 and RE to start operation.

CPRI

85

eCPRI Specification V2.0 (2019-05-10)

2

8. Annex C – eCPRI/CPRI Interworking with IWF type 1 andtype 23
4

Being able to re-use existing CPRI-based RAN equipment when migrating to an Ethernet-based fronthaulconfiguration is of great value.

5
6

These sections describe the use case when a CPRI link connected between a REC and RE is bridged overan eCPRI based fronthaul network by the usage of an Interworking Function (IWF).

7

8.1. Concept

8
9
10
11

In the IWF type 1 and 2 configuration suitable sub-parts will be extracted from the CPRI protocol by the nearend IWF, packed to eCPRI messages and transported over the network to the far end IWF, where the CPRI
stream is reconstructed and transmitted to the connected CPRI node, as defined in IWF specific eCPRI
Message Type sections 3.2.4.9 - 3.2.4.12.

12
13
14

Depending on the need for a bit rate reduction, this extraction, packing, signaling and reconstruction process
can be more or less complex. C&M of both IWF types shall be performed by a specific C&M entity and shallnot be performed via the CPRI link(s).

1looks like an REREClooks like an REC

CPRI link

IWF type 1

eCPRI transport network

IWF type 2 CPRI link

RE

15
16

Figure 49: Concept of eCPRI/CPRI bridge with IWFs type 1 and type 2

178.2. Definition of IWF type 1 and IWF type 2 CPRI ports

18This section specifies the IWF type 1 and 2 CPRI ports.

19
20
21

An IWF type 1 CPRI port shall implement all mandatory parts of the eCPRI specification related to the IWF
type 1 CPRI port and the appropriate sub-sections of the CPRI specification related to CPRI slave port as
per Table 18.

22
23
24

An IWF type 2 CPRI port shall implement all mandatory parts of the eCPRI specification related to the IWF
type 2 CPRI port and the appropriate sub-sections of the CPRI specification related to CPRI master port as
per Table 18.

25
26
27

In Table 18, the term “Applicable” means that the IWF type 1/2 CPRI port shall be fully compliant with thereferenced CPRI section, while the term “N/A” means that the referenced CPRI section is irrelevant for the
IWF CPRI port, which instead shall comply with the referenced eCPRI section.

CPRI

86

1

eCPRI Specification V2.0 (2019-05-10)

Table 18: IWF type 1 and type 2 CPRI protocol compliance
CPRI section
4.2.1 Line Bit Rate

Status

4.2.2 Physical Layer Modes

Applicable
Applicable

4.2.3 Electrical Interface

Applicable

4.2.4 Optical Interface

Applicable

4.2.5 Line Coding

Applicable

4.2.6 Bit Error Correction/Detection

Applicable

4.2.7 Frame Structure

Applicable
N/A

4.2.8 Synchronization and Timing
4.2.9 Link Delay Accuracy and Cable Delay
Calibration

eCPRI related section

8.3 Bridging of User Plane
7.4 Bridging of Synchronization Plane
8.8 Synchronization

N/A

8.7.2 Start-up Delay Management
8.9 Delay Management

Applicable

8.6 Bridging/handling of CPRI subchannels 0 and 2

4.3 Data Link Layer (Layer 2) Specificationfor Slow C&M Channel

Applicable

8.4 Bridging/Routing of CPRI Control
Words

4.4 Data Link Layer (Layer 2) Specification
for Fast C&M Channel

Applicable

8.4 Bridging/Routing of CPRI Control
Words

4.2.10 Link Maintenance of Physical Layer

4.5 Start-up Sequence

N/A

6.5 Scrambling

Applicable

6.7 64B/66B line coding

Applicable

6.9 Reed-Solomon Forward Error Correction

Applicable

8.7 Start-up Sequence2
3

8.3. Bridging of User Plane

4

The bridging of the user plane is performed via eCPRI specified message types described in section 3.2.4.

5

8.4. Bridging/Routing of CPRI Control Words

6
7
8

The bridging of the CPRI control words, as shown in Figure 43, is performed via eCPRI specified message
types described in section 3.2.4. Except subchannels 0 and 2 (see section 8.6) all CPRI control words are
expected to be tunneled, i.e. copied over and not interpreted by the IWFs.

9

8.5. Bridging of Synchronization Plane

10
11
12

In an eCPRI/CPRI interworking configuration with IWFs type 1 and type 2, the IWFs are assumed to be timeand frequency synchronized to one master time clock. The CPRI node REC needs to be time synchronized
to avoid bit slips on the IWF’s CPRI port.

13
14

The delay between R1 and R2 shall be kept constant. Likewise, the delay between R3 and R4 shall be kept
constant. For further details see section 8.8 and section 8.9.

CPRI

87

eCPRI Specification V2.0 (2019-05-10)

T12

T2a
R1

REC

CPRI link

R2

IWF

eCPRI transport network

type 1

IWF
type 2CPRI link

R4

RE
Ta3

R3
T34

1
2

Figure 50: Definitions of Reference Points for Delay Management of eCPRI/CPRI IWF type 1 and type 2

3

8.6. Bridging/handling of CPRI sub-channels 0 and 2

4
5
6

IWF type 1 or 2 must take special care of CPRI control word sub-channels 0 and 2 in the received eCPRI
messages. Table 19 below describes how each information element in these sub-channels shall be handled
in normal operation case. For details about error handling please refer to section 8.11.

7
89

When generating and transmitting eCPRI messages, all these information elements shall be tunneled fromCPRI to eCPRI messages except for the Sync byte which needs special handling according to the eCPRI
messages definitions.

10

Table 19: Sub-channel 0 and 2 handling in eCPRI to CPRI direction
Sub-channel

Information

Normal operation handling0

Sync byte

Based on IWF local counters

0

HFN

Based on IWF local counters

0

BFN-low and
BFN-high

Opt BFN. 1: Tunneled
Opt BFN. 2: Based on IWF local counters

2

VersionOpt Ver. 1: Tunneled
Opt Ver. 2: Based on IWF capabilities

2

Start-up

Tunneled

2

LOS, LOF

Tunneled, might be overwritten with local IWF
status, see section 8.11 (Fault Management)

2

RAI, SDI, Reset

Tunneled

2

p pointer

Tunneled

0 and 2

Reserved bits

Opt res. 1: Tunneled
Opt res. 2: Zeroed

11

Clarification of terms used in Table 19:

12

Tunneled: The information received in the eCPRI message is copied to the CPRI link.

13
14

Zeroed:15

8.7. Start-up Sequence

16

8.7.1.

17

Figure 51 shows a high-level flow chart for the IWF type 1/type 2 start-up sequence.

Used when no information is available and IWF needs to re-create it, in this case the bit or bits
are set to zero.

eCPRI/CPRI IWF Start-up sequence overview

CPRI

88

eCPRI Specification V2.0 (2019-05-10)

Master Clock

IWF
REC M

3

CPRI

S

type 1

IWF
FH NW

1

Frequency and time/phasesynchronization procedure

2

Measurement and estimation of
max/min delay between IWF nodes.
Configuration for network delay andnetwork delay assymetry

type 2 M

CPRI

S

RE

IWF CPRI Start-up

1
2

Figure 51: eCPRI/CPRI IWF Start-up sequence overview

3
4

Step 1:

5
6

The IWF nodes acquire frequency and time/phase synchronization via e.g. IEEE 1588v2 protocol. The startup sequence cannot continue until both nodes reach locked state.

7

Step 2:8910
11

To prepare for the CPRI data to be transmitted over the fronthaul packet network and get an estimate of thedelay variation, the IWF nodes measure the delay in both directions via the eCPRI one-way delay
measurement procedure defined in section 3.2.4.6. If applicable, necessary steps are taken to handle any
network delay asymmetries. These steps are described in more detail in section 8.7.2.

12

Step 3:13
14
15

The IWF nodes apply the IWF CPRI start-up procedure as specified in section 8.7.3, while the behavior of
the CPRI nodes (REC, RE) is assumed to fully comply with the CPRI start-up sequence specified in section
4.5 of [1].

16

8.7.2.

17

Figure 52 shows the steps taken during the IWF start-up sequence regarding delay management.

Start-up Delay Management

CPRI

89

T12network

REC M

CPRI

IWF

S

FH NW

type 1

T34network

eCPRI Specification V2.0 (2019-05-10)

TIWF2_DL
IWF
type 2

M

CPRI

S

RE

TIWF2_UL

One-Way Delay Measurement(ID, Request)

T12network calculated

One-Way Delay Measurement(ID, Response)
One-Way Delay Measurement(ID, Remote_Request)
One-Way Delay Measurement(ID, Request)
One-Way Delay Measurement(ID, Response)

T34network calculated

TIWF2_DL_min, TIWF2_UL_max
now known

IWF_Delay_Control(Get_Delays)

IWF_Delay_Control(T IWF2_DL_min, TIWF2_UL_max)

Calculate all relevant delay management
parameters according to 8.9

Repeatuntil line rate
negotiation is done

IWF_Start_Up(…, Timestamp,...)

IWF_Start_Up(…, Timestamp,...)

IWF_Operation(…,,...)

NormalOperation

IWF_Operation(…,,...)

1
2

Figure 52:

eCPRI/CPRI IWF type 1/type 2 delay management start-up sequence

3
4
5

•

IWF type 1 determines the network delays by using the eCPRI one-way delay measurement
procedure described in section 3.2.4.6. In general, several measurements are needed to properly
estimate T12network_max and T34network_max.

6
7
8

•

The IWF type 1 sends a Delay Control message (eCPRI Message Type #11, see section 3.2.4.12)
with “Request get delays”. IWF type 2 responds with a Delay Control message with “Response getdelays”. “Delay A” shall contain TIWF2_DL_min and “Delay B” shall contain TIWF2_UL_max.

9
10

•

IWF type 1 calculates all parameters needed for delay management, see section 8.9 on how to
calculate the parameters.

11
12

o

Based on the calculated parameters IWF type 1 knows how to set the Timestamp field in the
eCPRI Message Type #8 (IWF Start-Up).

13
14
15
16

o

IWF type 2 will set the Timestamp field in the eCPRI Message Type #8 (IWF Start-Up)
indicating the CPRI frame reception time. Based on the calculated parameters andTimestamp received from IWF type 2, IWF type 1 will compute the transmission time of the
CPRI frame towards the REC.

CPRI

90

eCPRI Specification V2.0 (2019-05-10)

1

8.7.3.

IWF CPRI port start-up sequence2
34This section defines the sequence of actions to be performed by IWF type 1 and type 2 CPRI ports to startup their relevant CPRI links (to/from REC and RE respectively), assuming that the latter fully comply with the
CPRI start-up sequence as specified in section 4.5 of [1].

5
6When both connected CPRI ports are in state F, the link is in normal operation.
After a reset, all CPRI ports shall enter state A.

7

8.7.3.1.

8

The start-up procedure accomplishes two main things:

General9•Layer 1 synchronization: byte alignment and hyperframe alignment.

10
11

•

Alignment of capabilities of the RE/REC CPRI ports and the IWF type 1/2 CPRI ports: line bit rate
and protocol.

12
13
14
15

Since there is no mandatory line bit rate, the CPRI master/slave port and IWF type 1/2 CPRI port shall,during the start-up procedure, try different configurations until a common configuration is detected. The
common configuration does not have to be optimal – it shall be considered as just a first contact where
capabilities can be exchanged for a proper configuration to be used in the following communication.

16
17

For all states, it is mandatory to always transmit information consistent with the protocol indicated in #Z.2.0 in
all control words in subchannel 1 and subchannels 3 to 15.

18
19
20
21

When changing the line bit rate of the transmitted CPRI, the interruption of transmission shall be less than
0.1s. When changing the line bit rate of the received CPRI, the interruption of reception shall be less than
0.1s. The time to reach HFNSYNC for the receiving unit shall be less than 0.2s, given the precondition thatthe far-end transmitter is on, they use the same line bit rate and no bit errors occur.

22
23
24
25
26

In the negotiation steps in state C the IWF type 1/2 CPRI port shall sample and evaluate the received
protocol version at least every 0.1 s. As the remote end IWF and CPRI node may be involved in theevaluation, it may not be possible to update the transmitted protocol version within 0.2 s after the evaluationas specified for the CPRI port in [1], section 4.5.1. In that case, Transition 13 of the CPRI start-up sequence
would be triggered (see section 8.7.3.4.7 of [1]) impacting the start-up time and associated timers.

27

8.7.3.2.

28

The start-up procedure may be endless due to:Layer 1 Start-up Timer

29•

Fault in one of the units.

30•

No common layer 1 configuration found.

31
32
33

The supervision may be done per state and per cause, but the start-up procedure also specifies a genericstart-up timer which shall be set upon entry of the start-up procedure and shall be cleared when state F isentered.

34

If the timer expires the start-up procedure shall be restarted.

35

The “layer 1 start-up timer” is activated in transitions 2 and 13.

36

The “layer 1 start-up timer” is cleared in transitions 3, 10 and 11.

37
38

If the “layer 1 start-up timer” expires, transition 16 shall take place and state B is entered, possibly modifying
the available set of line bit rates and protocols.

39

The “layer 1 start-up timer” expiration time is vendor specific.

40

Following Figure 53 shows the start-up state diagram for the IWF type 1/2 CPRI ports.

CPRI

91

eCPRI Specification V2.0 (2019-05-10)

11

IWF Shutdown or Reset
From any State
L1 LOS/LOF

Standby

10

9A« L1 start-up timer »expired1

L1
Synchronization

16

B

2

Reconfiguration

Protocol setup
3

13

Operation

C
Protocol mismatchF

1
2

Figure 53: Start-up states and transitions3

8.7.3.3.

State Description

4

8.7.3.3.1.

5
6

Prerequisites:
None

7
8
9
10

Description:
Waiting to be configured to start-up CPRI. No transmission or reception of CPRI. The operator may set up asuitable start-up configuration (line bit rate). The IWF type 1/2 CPRI ports may also have knowledge of aprevious successful configuration.

11

8.7.3.3.2.

12
13
14
15

Prerequisites:
The set of available line bit rate, protocol versions and C&M plane characteristics is known. This may be thecomplete set of the unit or a subset based on operator configuration or previous negotiation between theunits.

16
17
18
19

Description:
During this state, the line bit rate of the interface is determined and both CPRI master port (REC) and IWF
type 1 CPRI port as well as CPRI slave port (RE) and IWF type 2 CPRI port reach layer 1 synchronization up
to state HFNSYNC.

20
21
22
23

Interpreted control BYTES:For 8B/10B line coding protocol version 1 and 2; #Z.0.0, #Z.64.0
For 8B/10B line coding protocol version 2; #Z.0.2 … #Z.0.T/8-1
For 64B/66B line coding; #Z.0.8, #Z.64.0

24

IWF type 2 CPRI port actions:25
26

While in this state, upon reception of eCPRI start-up message from the remote end (i.e. IWF type 1), IWF
type 2 shall:State A – Standby

State B – L1 Synchronization and Rate Negotiation

CPRI

92

eCPRI Specification V2.0 (2019-05-10)

1
2
3
4

•

Opt Ver. 1: start transmitting CPRI on the line bit rate of the received eCPRI start-up message withthe protocol version in #Z.2.0, RS-FEC and scrambling mode set to the lower between the IWF
type 2 maximum capability and the received eCPRI start-up message setting and also start
attempting to receive CPRI at the same line bit rate.

5
6
7

•

Opt Ver. 2: start transmitting CPRI on the line bit rate of the received eCPRI start-up message withthe protocol version in #Z.2.0, RS-FEC and scrambling mode set according to the IWF type 2
configuration4 and also start attempting to receive CPRI at the same line bit rate.

8
9
10
11
12
13
14
15
16

IWF type 1 CPRI port actions:
The IWF type 1 CPRI port shall start attempting to receive CPRI at the highest available line bit rate directly
when entering the state. If the IWF type 1 CPRI port does not reach synchronization state HFNSYNC it shallselect another line bit rate for CPRI reception after T1’ from entering the state, given that another line bit rate
is available. T1’ is 3.9-4.1s. Each following T1’ interval, a new reception line bit rate shall be selected forreception, given that another line bit rate is available. The line bit rates shall be selected from the available
set in a round robin fashion, i.e. first highest, the second highest, …, the slowest, and then restarting fromthe highest line bit rate. An IWF type 1 CPRI port which supports both RS-FEC enabled/disabled modes
shall check both modes in parallel.

17
18
19
20

When entering this state, the IWF type 1 CPRI port shall turn off its CPRI transmitter. If this state wasentered with transition 10 the IWF type 1 CPRI port may optionally transmit for a maximum of 5 hyperframes
to indicate to far-end equipment (i.e. REC) the layer 1 link maintenance control BYTE #Z.130.0. When the
IWF type 1 CPRI port reaches synchronization state HFNSYNC, it shall

21
22
23

•

Opt Ver. 1: start forwarding the received CPRI basic frames by means of eCPRI start-up message#8 to the remote IWF (i.e. IWF type 2) with the protocol version in #Z.2.0, RS-FEC and scramblingmode set to the lower between the IWF type 1 maximum capability and the REC proposed setting.

24
25
26

•

Opt. Ver. 2: start forwarding the received CPRI basic frames by means of eCPRI start-up message#8 to the remote IWF (i.e. IWF type 2) with the protocol version in #Z.2.0, RS-FEC and scramblingmode set according to the IWF type 1 configuration4.

27
28
29

Upon reception of eCPRI start-up message from the remote end (i.e. IWF type 2) corresponding to the
expected line bit rate, it shall stop trying to select other line rates even if not in the HFNSYNC state and it
shall

30
31
32

•

Opt Ver. 1: start forwarding the CPRI basic frames received from the remote IWF (i.e. IWF type 2)
with the protocol version in #Z.2.0, RS-FEC and scrambling mode set to the lower between the
IWF type 1 maximum capability and the received eCPRI start-up message #8 setting.

33
34

•

Opt Ver. 2: start forwarding the CPRI basic frames received from the remote IWF (i.e. IWF type 2)
with the protocol version in #Z.2.0, RS-FEC, scrambling according to IWF configuration4.

35
36
37
38
39

Comments:
While in this state, no timer to detect hanging-up is provided by the start-up procedure. Such a hanging-up
will occur in case of HW fault or may also occur for configurations with an IWF type 2 CPRI port supporting
more than 4-line bit rates for auto-negotiation. Such a hanging-up shall be detected and managed by vendor
specific means. For more information see also Annex 6.8 in [1].

40
41

Figure 54 shows the line rate negotiation between two CPRI nodes in an eCPRI/CPRI type 1/ type 2interworking configuration.

4 How to set up the IWF configuration is out of the scope of this specification.

CPRI

93

REC M

CPRI

S

IWF

FH NW

type 1eCPRI Specification V2.0 (2019-05-10)

IWF
type 2M

CPRI

Master-port
RX: disabled
TX: disabled

Slave-port
RX: enabled
TX: disabled

S

RE

Slave-port
RX: enabled
TX: disabled

HFNSYNC

RX: enabled
TX: enabled~4 seconds

HFNSYNCHFNSYNC

RX: enabled
TX: enabled

HFNSYNC

RX: enabled
TX: enabled

HFNSYNC

CPRI Protocol Setup (CPRI start-up state C of REC)

1
2

Figure 54: Line bit rate negotiation sequence diagram

3
4

Assumptions in the sequence diagram (Figure 54):

5•

Both IWF type 1 and IWF type 2 support at least one common CPRI line rate option of REC and RE.

67•

REC in the example above supports at least CPRI line rate options N and (N+1), the RE only supports
the (N+1) option.

8
9•The line-rate auto-negotiation turn-around times are fulfilled (i.e. the T1 (0.9…1.1 seconds) and T1´(3.9…4.1 seconds) in the CPRI Specification).

10

8.7.3.3.3.

11
12
13

Prerequisites:
Layer 1 is synchronized, i.e., CPRI master port (REC) to IWF type 1 and IWF type 2 to CPRI slave port (RE)hyperframe structures are aligned.

14
15

Description:
During this state, a common protocol version of CPRI is determined.

16
17
18

Interpreted control BYTES:For 8B/10B line coding; #Z.0.0, #Z.64.0, #Z.2.0
For 64B/66B line coding; #Z.0.8, #Z.64.0, #Z.2.0

19

IWF type 2 CPRI master port actions:

State C – Protocol Setup

CPRI

94

eCPRI Specification V2.0 (2019-05-10)

1

When entering this state, the IWF type 2 CPRI master port shall:

2
3
4
5

•

Opt Ver. 1: set the protocol version in #Z.2.0 to the lower between the IWF type 2 maximum capability
and the received eCPRI start-up message #8 setting. If the currently received protocol version fromthe RE CPRI slave port is equal to the current protocol version sent by the IWF type 2 CPRI master
port, the protocol setup is achieved.

6•

Opt Ver. 2: set the protocol version in #Z.2.0 according to the IWF type 2 configuration.

7
8

The IWF type 2 CPRI master port shall decode the received protocol version by looking at #Z.2.0. When the
IWF type 2 CPRI master port receives a valid or an updated protocol version from the CPRI slave port,

9
10

•

If the currently received protocol version is equal to the current protocol version sent by the IWF type 2
CPRI master port, the protocol setup is achieved

11
12
13

•

If the currently received protocol version differs from the current protocol version sent by the IWF type
2 CPRI master port, it shall reselect the protocol version. The new protocol version shall be selectedaccording to the rule:

14
15

New IWF type 2 CPRI master port protocol version = highest available protocol version which is lessor equal to received CPRI slave port protocol version (received in #Z.2.0)

16Error case: If no such protocol exists:

17

New IWF type 2 CPRI master port protocol version = lowest available protocol version

18
19
20

Note that the reselection may choose the already transmitted protocol version. The new selected
protocol version shall be stated in #Z.2.0. If the currently received protocol version is equal to the newprotocol version sent by the IWF type 2 CPRI master port, the protocol setup is achieved.

21
22
23

While in this state, the IWF type 2 shall forward the received CPRI basic frames by means of eCPRI start-up
message #8 to the remote IWF (i.e. IWF type 1) with the protocol version in #Z.2.0 set to the lower between
the IWF type 2 maximum capability and the RE proposed setting.

24

IWF type 1 CPRI slave port actions:

25
26
27

While in this state, the IWF type 1 shall forward the received CPRI basic frames by means of eCPRI start-up
message #8 to the remote IWF (i.e. IWF type 2) with the protocol version in #Z.2.0 set to the lower between
the IWF type 1 maximum capability and the REC proposed setting.

28

While in this state,

29
30
31

•

Opt Ver. 1: the IWF type 1 shall forward the received eCPRI start-up message #8 setting to the REC
CPRI master port with the protocol version in #Z.2.0 set to the lower between the IWF type 1
maximum capability and the eCPRI start-up message #8 setting.

32
33

•

Opt Ver. 2: the IWF type 1 shall forward the received eCPRI start-up message #8 setting to the REC
CPRI master port with the protocol version in #Z.2.0 set to the IWF type 1 configuration.

34
35

The IWF type 1 CPRI slave port shall decode the received protocol version by looking at #Z.2.0. When the
IWF type 1 CPRI slave port receives a valid or an updated protocol version from the CPRI master port,

36
37

•

If the currently received protocol version is equal to the current protocol version sent by the IWF type 1
CPRI slave port, the protocol setup is achieved

38
39
40

•

If the currently received protocol version differs from the current protocol version sent by the IWF type
1 CPRI slave port, the IWF type 1 CPRI slave port shall reselect the protocol version. The new
proposed protocol version shall be selected according to the rule:41
42

New IWF type 1 CPRI slave port protocol version = highest available protocol version which is less orequal to received CPRI master port protocol version (received in #Z.2.0)

43Error case: If no such protocol exists:

44

New IWF type 1 CPRI slave port protocol version = lowest available protocol version

45
46
47

Note that the reselection may choose the already transmitted protocol version. The new selected
protocol version shall be stated in #Z.2.0. If the currently received protocol version is equal to the newprotocol version sent by the IWF type 1 CPRI slave port, the protocol setup is achieved.

48
49

Comments:
If the IWF type 2 CPRI master port does not receive a new protocol version before the layer 1 start-up timer

CPRI

95

eCPRI Specification V2.0 (2019-05-10)

1
2
3

expires, it can assume that there are no common protocol versions. Such a detection can be made faster but
then the application must take into account the case where the CPRI slave port enters the state later thanthe IWF type 2 CPRI master port.

4

8.7.3.3.4.

5
6

Prerequisites:
The protocol is agreed upon.

78

Description:
Normal operation.

9
10Interpreted control words:
All

11
12
13

IWF type 2 CPRI master port actions:
While in this state, the IWF type 2 CPRI master port shall check that #Z.2.0 is equal in both directions. If it is
not equal it shall enter state C.

14
15

While in this state, the IWF type 2 CPRI master port shall detect any change in the received protocol version
value #Z.2.0 from the remote IWF. If this protocol value changes it shall enter state C.

16
17
18

IWF type 1 CPRI slave port actions:
The IWF type 1 CPRI slave port shall check that #Z.2.0 is equal in both directions. If it is not equal it shallenter state C.

19

Comments:

20
21
22

•

In normal operation, the C&M plane has been established and all further setup of HW, functionality,
user plane links, IQ format, etc. is conducted using procedures outside the scope of the CPRI andeCPRI specifications. If the CPRI is subject to a failure state, B is entered.

23
24

•

IWF type 1 will stop sending Message Type #8 when IWF type 1 CPRI port get into operation state
F. The IWF type 1 will at this point start sending Message Type #9.

25
26

•

IWF type 2 will stop sending Message Type #8 when receiving Message Type #9 from the remote
IWF type 1. IWF type 2 will at this point start sending Message Type #9.

27
28

State F – Operation

While in this state the IWF type 1 and 2 ports shall manage the CPRI SAPs as specified in the following
sections:29•

8.3 Bridging of User Plane30•

8.4 Bridging/Routing of CPRI Control Words

31•

8.5 Bridging of Synchronization Plane32•

8.6 Bridging/handling of CPRI sub-channels 0 and 2

33

8.7.3.4.

34

8.7.3.4.1.

35
36
37

Trigger:
The trigger is out of the scope of the eCPRI specification. But it is required for the CPRI circuit initiation to becompleted.

38
39
40

A set of available line bit rates and protocol versions shall be available. This may be the equipment fullcapabilities, or a subset determined by the equipment configuration (manual) or knowledge from previous
successful configurations. Such a subset will shorten the time in state B and C.

41
42

Actions:None

438.7.3.4.2.

44

Trigger:

Transition Description
Transition 1

Transition 2

CPRI

96

eCPRI Specification V2.0 (2019-05-10)

1
2•

IWF type 1:

HFNSYNC synchronization state and eCPRI message #8 reception from remote end IWF
type 2.

3
4•

IWF type 2:

First time the synchronization state HFNSYNC is entered. Received CPRI line bit rate isequal to transmitted CPRI line bit rate.

5
6

Actions:
The “layer 1 start-up timer” is set.

7

8.7.3.4.3.

8
9

Trigger:Protocol is agreed on. First time transmitted #Z.2.0 is equal to received #Z.2.0.

1011

Actions:
The “layer 1 start-up timer” is cleared.

12

8.7.3.4.4.

13
14
15

Trigger:
Out of the scope of the eCPRI specification. The capability negotiation by the application proposes a new
CPRI protocol or line bit rate.

16
17

Actions:
The transition carries information about the agreed available set of line bit rates and protocol versions.

18

8.7.3.4.5.

19
20

Trigger:First time LOS or LOF has been found faulty as defined in [1], section 4.2.10.

21
22

Actions:
The “layer 1 start-up timer” is cleared.

23

8.7.3.4.6.

24
25

Trigger:
The IWF type 1 or 2 CPRI ports are initiated.

26
27

Actions:
The “layer 1 start-up timer” is cleared.

28

8.7.3.4.7.

29
30

Trigger:First time the received protocol version in #Z.2.0 is changed while in state F.

31
32

Actions:
The “layer 1 start-up timer” is set.

33

8.7.3.4.8.

34
35

Trigger:
When “layer 1 start-up timer” expires.

36
37

Actions:
None

Transition 3

Transition 9

Transition 10

Transition 11

Transition 13

Transition 16

38

CPRI

97

1

8.8. Synchronization

2

eCPRI/CPRI interworking synchronization assumptions:eCPRI Specification V2.0 (2019-05-10)

3
4•

The internal time clocks of IWF type 1 and IWF type 2 are frequency and phase/time synchronized
to a common reference.

5•

REC is (at least) frequency synchronized5 to the same reference as IWF type 1 and IWF type 2.

6•

RE is synchronized to the IWF type 2 CPRI master port.

78.9. Delay Management

8
9
10
11

In order to support eCPRI/CPRI interworking for CPRI REC and RE, it is necessary to ensure that the CPRI
delay management process can be used by REC and RE. This can be achieved by providing constant andsymmetrical6 DL and UL link delays between REC and RE, which can be measured by REC via T14
measurement and Toffset provided by RE.

12
13

Figure 55 shows the definition of the timing reference points for the eCPRI/CPRI interworking delay
management:

14
15

•

T12’/T34’ denotes the DL and UL CPRI link delays between REC and IWF type 1, assumed to beconstant and symmetric in DL and UL.

16
17

•

T12’’/T34’’ denotes the DL and UL CPRI link delays between IWF type 2 and RE, assumed to beconstant and symmetric in DL and UL.

18
19
20

•

T12network denotes the transport network delay of a user data packet between IWF type 1 and
IWF type 2. T12network may not be constant for every packet and may show a statistical variation
limited by the profile of the transport network:
0 ≤ T12network_min ≤ T12network ≤ T12network_max

21
22
23
24

•

T34network denotes the transport network delay of a user data packet between IWF type 2 andIWF type 1. T34network may not be constant for every packet and may show a statistical variation
limited by the profile of the transport network:
0 ≤ T34network_min ≤ T34network ≤ T34network_max

25
26
27
28
29

•

TIWF1_DL denotes the DL forwarding delay for user data in IWF type 1 between the reception of abasic frame at the CPRI port of IWF type 1 and the transmission of the corresponding user data
packet at the eCPRI port of IWF type 1. TIWF1_DL may not be constant for every packet and may
show a statistical variation:
0 ≤ TIWF1_DL_min ≤ TIWF1_DL ≤ TIWF1_DL_max

30
31
32
33
34
35
36

•

TIWF2_DL denotes the DL forwarding delay for user data in IWF type 2 between the reception of auser data packet at the eCPRI port of IWF type 2 and the transmission of the corresponding basic
frame at the CPRI port of IWF type 2. TIWF2_DL includes extra buffering of user data which is needed
for achieving a constant DL delay and symmetrical DL/UL delays. The worst case zero buffer
forwarding delay is denoted as TIWF2_DL_min, and the worst case zero buffer forwarding delay +maximum buffering delay is denoted as TIWF2_DL_max.

37
38
39
40

•

TIWF2_UL denotes the UL forwarding delay for user data in IWF type 2 between the reception of abasic frame at the CPRI port of IWF type 2 and the transmission of the corresponding user data
packet at the eCPRI port of IWF type 2. TIWF2_UL may not be constant for every packet and may
show a statistical variation:
0 ≤ TIWF2_UL_min ≤ TIWF2_UL ≤ TIWF2_UL_max

41

5 Frequency synchronized means that the average frequency difference is zero, which is equivalent to phase locked, i. e. the averagephase difference is arbitrary but constant.
6 in cases where time synchronization at the antenna ports is not needed (e. g. asynchronous UTRA FDD), a symmetrical DL and UL
delay is not essential

CPRI

98

eCPRI Specification V2.0 (2019-05-10)

1
2
3
4
5
6

•

TIWF1_UL denotes the UL forwarding delay for user data in IWF type 1 between the reception of auser data packet at the eCPRI port of IWF type 1 and the transmission of the corresponding basic
frame at the CPRI port of IWF type 1. TIWF1_UL includes extra buffering of user data which is needed
for achieving a constant UL delay and symmetrical DL/UL delays. The worst case zero buffer
forwarding delay is denoted as TIWF1_UL_min, and the worst case zero buffer forwarding delay +maximum buffering delay is denoted as TIWF1_UL_max.

7
8
9

•

T12 denotes the overall DL delay between transmission of a CPRI basic frame at the REC andreception of this basic frame at the RE. IWF type 1 and IWF type 2 shall ensure by additional
buffering of user data that T12 is constant and equal to T34.

10
11
12

•

T34 denotes the overall UL delay between transmission of a CPRI basic frame at the RE andreception of this basic frame at the REC. IWF type 1 and IWF type 2 shall ensure by additional
buffering of user data that T34 is constant and equal to T12.

13
14
15

•

Toffset denotes the CPRI frame offset between the input signal and the output signal at the input
point (R2), and the output point (R3) of an RE terminating a particular logical connection between
SAPIQ as specified by CPRI specification [1]. Toffset is constant, value is user specific.

16
17
18

•

T14 denotes the CPRI frame delay between REC DL and UL CPRI ports. IWF type 1 and IWF type2 shall ensure by additional buffering of user data that T14 is constant and equal to T12 + Toffset +
T34.
PRTC

T12

R1

T12'

REC

CPRI

TIWF1_DL

T12network

TIWF2_DL

IWF
type 1FH
NW

IWF CPRI
type 2
ToffsetTIWF1_UL

T34network

T14
T34'
R4

R2

T12''

T34

TIWF2_UL

RE

T34''
R3

19
20

Figure 55: Definition of reference points for eCPRI/CPRI interworking delay management

CPRI

99

eCPRI Specification V2.0 (2019-05-10)

T12

REC CPRI DL out
T12'

IWF type 1 CPRI DL in
TIWF1_ DL_max

IWF type 1 clock

IWF type 1 eCPRI DL out

TIWF1_ DL_min
T12network_max

TFRAME_IWF1_DL

T12network_min

CPRI frame boundary
IWF type 2 DL reception window

IWF type 2 eCPRI DL in
TIWF2_DL_max

IWF type 2 clock

buffering margin

TIWF2_DL_min

IWF type 2 CPRI DL out
TFRAME_IWF2_DL

T12''

RE CPRI DL in
T2a
RE CPRI UL out

Ta3

ToffsetT34''

IWF type 2 CPRI UL in
TIWF2_ UL_max

IWF type 2 clock

TIWF2_ UL_min

IWF type 2 eCPRI UL out

T34network_max

TFRAME_IWF2_UL

T34network_min
IWF type 1 UL reception window

IWF type 1 eCPRI UL in
TIWF1_UL_max

IWF type 1 clock

network delay asymmetry compensationbuffering margin

TIWF1_UL_min

IWF type 1 CPRI UL out
TFRAME_IWF1_UL

T34'

REC CPRI UL in
T34

1
2

Figure 56: eCPRI/CPRI interworking timing diagram

3
4

A detailed timing diagram for eCPRI/CPRI interworking is shown in Figure 56.

5

Where:

6
7•

TFRAME_IWF1_DL denotes the reception time of the DL CPRI frame boundary at IWF type 1 relative tothe internal timing reference.

8
9•

TFRAME_IWF2_DL denotes the transmission time of the DL CPRI frame boundary at IWF type 2 relative
to the internal timing reference.

10
11

•

TFRAME_IWF2_UL denotes the reception time of the UL CPRI frame boundary at IWF type 2 relative tothe internal timing reference.

12
13

•

TFRAME_IWF1_UL denotes the transmission time of the UL CPRI frame boundary at IWF type 2 relative
to the internal timing reference.

14
15

Please note that the internal time references of IWF type 1 and IWF type 2 are phase/time synchronized to acommon reference and thus synchronous (within a suitable synchronization accuracy), see section 8.8.

16

The goal of the IWF delay management is to achieve a constant and symmetrical delay:

17

TFRAME_IWF2_DL - TFRAME_IWF1_DL = TFRAME_IWF1_UL - TFRAME_IWF2_UL = constant,

18
19

by managing the delays TIWF2_DL and TIWF1_UL with extra buffers in IWF type 1 and IWF type 2, as well as
selecting for a suitable “constant” value, where:

20

TFRAME_IWF2_DL - TFRAME_IWF1_DL = TIWF1_DL + T12network + TIWF2_DL

21

TFRAME_IWF1_UL - TFRAME_IWF2_UL = TIWF2_UL + T34network + TIWF1_UL

22
23

To achieve constant and symmetric delay, the value for “constant” shall be selected to fulfill the following
relation:

24
25

TFRAME_IWF2_DL - TFRAME_IWF1_DL = TFRAME_IWF1_UL - TFRAME_IWF2_UL = constant ≥≥ max(TIWF1_DL_max + T12network_max + TIWF2_DL_min, TIWF2_UL_max + T34network_max + TIWF1_UL_min)

CPRI

100

eCPRI Specification V2.0 (2019-05-10)12

In case DL/UL delay symmetry is not needed the value for “constant” can be different in DL and UL and thefollowing relations apply:

3

TFRAME_IWF2_DL - TFRAME_IWF1_DL = constant_DL ≥ TIWF1_DL_max + T12network_max + TIWF2_DL_min

4

TFRAME_IWF1_UL - TFRAME_IWF2_UL = constant_UL ≥ TIWF2_UL_max + T34network_max + TIWF1_UL_min

5
6
7

Any user data packet with a DL delay lower than TFRAME_IWF2_DL - TFRAME_IWF1_DL has to be buffered in IWF
type 2 and any user data packet with an UL delay lower than TFRAME_IWF1_UL - TFRAME_IWF2_UL has to bebuffered in IWF type 1

89In order to avoid a buffer overflow in IWF type 1 or IWF type 2, the value for “constant” has to fulfill thefollowing additional relations:10

In case DL/UL delay symmetry is required:

11
12

TFRAME_IWF2_DL - TFRAME_IWF1_DL = TFRAME_IWF1_UL - TFRAME_IWF2_UL = constant ≤≤ min(TIWF1_DL_min + T12network_min + TIWF2_DL_max, TIWF2_UL_min + T34network_min + TIWF1_UL_max)

13

In case DL/UL delay symmetry is not needed:

14

TFRAME_IWF2_DL - TFRAME_IWF1_DL = constant_DL ≤ TIWF1_DL_min + T12network_min + TIWF2_DL_max

15

TFRAME_IWF1_UL - TFRAME_IWF2_UL = constant_UL ≤ TIWF2_UL_min + T34network_min + TIWF1_UL_max

16
17
18

T12network_max and T34network_max are either known from guaranteed network performance or have to
be measured by IWF type 1 and IWF type 2 (e. g. by using eCPRI one-way-delay measurement) before the
CPRI link start-up.

19
20
21

This delay management procedure requires IWF type 1 to know IWF type 2 delays. This can be achieved
using Message Type #11 Delay Control. IWF type 1 requests the IWF type 2 delays TIWF2_DL_min (Delay A)
and TIWF2_UL_max (Delay B) via Message Type #11 and calculates constant_DL/UL.

22
23

The timing configuration of the CPRI framer in IWF type 2 DL and IWF type 1 UL is carried out during startup by sending Message Type #8 (IWF Start-Up):

24
25
26
27

•

In DL IWF type 1 measures the reception time TZ.X_IWF1_DL of each DL CPRI basic frame Z.X relative
to its internal clock, adds constant_DL and sends it to IWF type 2 via the time stamp field of thecorresponding Message Type #8. This indicates the transmission time of CPRI basic frame Z.X at
IWF type 2 CPRI output port.

28
29
30
31

•

In UL IWF type 2 measures the reception time T Z.X_IWF2_UL of each UL CPRI basic frame Z.X relative
to its internal clock and sends it to IWF type 1 via the time stamp field of the corresponding Message
Type #8. IWF type 1 adds constant_UL to the time stamp, which indicates the transmission time of
CPRI basic frame Z.X at IWF type 1 CPRI output port.

32

Please note that TFRAME_IWF1_DL = T0.0_IWF1_DL and TFRAME_IWF2_UL = T0.0_IWF2_UL.

33
34

Once established, timing is kept by IWF type 1 and IWF type 2 after switching from start-up to operation(Message Type #9 IWF Operation).

35

8.10. Handling of eCPRI Remote Reset and CPRI Reset

36
37

The CPRI Reset bit sent in CPRI control word #Z.130.0 shall have no effect on and shall be tunneled by IWF
type 1 or IWF type 2.

38
39

How and when to reset the IWF nodes is vendor specific, it can be performed with the Remote Resetmessage specified in section 3.2.4.7.

40

8.11. Link and Fault Management

41
42
43
44

The CPRI link between a CPRI master (normally a REC) and CPRI slave (normally a RE) should behave asa normal CPRI link even if there are Inter Working Function nodes in between. Figure 57 shows a reference
model for link and fault management. Depending on the fault nature and location, special measures shouldbe put in place to ensure the CPRI links between the REC and RE behave as normal CPRI links.

CPRI

101

eCPRI Specification V2.0 (2019-05-10)

2
1
REC M

3

CPRI

S

IWF
type 1

FH NW

6

IWF
M
type 2

CPRI

5

1

S

RE

4

2

Figure 57: Reference model for link and fault management

3
4
5
6

During operation, line code errors detected at the CPRI receivers of the IWFs shall be indicated by an error
indication bit “E” in the eCPRI Message Type #9. This indicates that at least one “line code error” is detected
for a basic frame (or part of basic frame in some cases). This bit is transferred to the other IWF. What to dowith this error indicator in the other IWF is out of scope for this eCPRI specification.

7
8
9

Table 20 shows a summary of link faults and the actions that shall be performed. Faults and actions
corresponding to links 3 and 6 in Figure 57 are not listed in the table since they are covered by normal CPRI
link and fault management [1].

10

Table 20: Summary of link faults
Link

Fault
detectedbyFault detected via

Recovery action on/by same node as detected the fault

1

IWF type 1

Link Supervision(detected LOS/LOF)

Stop sending “link 1 related eCPRI packets” on link 2.
(Note: IWF type 2 will detect packet loss.)
Discard all received eCPRI packets related from link 5.
Set LOS/LOF on Link 6 according to [1].
Disable transmission on link 6 (the transmitting may continue
for up to maximum of 5 hyperframes to inform the L1 status).
Return to line-rate negotiation (transition 10 in 8.7.3.4.5)
See section 8.11.1 for details

2

IWF type 2

Received RAI

No action(L1 inband will be sent to the CPRI master over eCPRI)

Ethernet supervision

Disable CPRI link transmission on link 3.
Return to start-up.

Link down
Ethernet PCS link down or MAC
fault
Ethernet supervision
No received “link 3 related
eCPRI packets” or packets
received outside of the reception
window for longer than a vendor
specific timeout(timeout recommended to be
between 1-5 hyperframes)
Ethernet supervision
No reception or packets
received outside of the reception
window for “Link 3 related
eCPRI packets” but within avendor specific timeout.

4

IWF type 2

Link Supervision(detected LOS/LOF)

It is recommended to report this to the IWF type 2’s C&M.
Disable CPRI link transmission on link 3.
Return to start-up.
It is recommended to report this to the IWF type 2’s C&M.

IWF type 2 shall continue sending the CPRI data on link 3
with correct CPRI frame structure but replacing the missing
parts with zeros.
For exceptions and further details see section 8.11.2.

Stop sending “link 4 related eCPRI packets” on link 5(Note: IWF type 1 will detect packet loss.)
Set LOS/LOF on Link 3 according to [1].
See section 8.11.1 for further details

CPRI

102

IWF type 1

5

eCPRI Specification V2.0 (2019-05-10)

Received RAI

No action(L1 inband shall be sent to the CPRI master over eCPRI)

Ethernet supervision

Disable CPRI link transmission on link 6.
Return to start-up.

Link down
Ethernet PCS link down or MAC
fault
Ethernet supervision
No received “link 6 related
eCPRI packets” or packets
received outside of the reception
window for longer than a vendor
specific timeout(timeout recommended to be
between 1 and 5 hyperframe)
Ethernet supervision
No reception or packets
received outside of the reception
window for “Link 6 related
eCPRI packets” but within avendor specific timeout.

It is recommended to report this to the IWF type 1’s C&M.
Disable CPRI link transmission on link 6.
Return to start-up.
It is recommended to report this to the IWF type 1’s C&M.

IWF type 1 shall continue sending the CPRI data on link 6
with correct CPRI frame structure but replacing the missing
parts with zeros.
For exceptions and further details see section 8.11.2.

1
2
3

CPRI L1 reset does not need any special handling because it shall be transferred transparently between the
CPRI master and CPRI slave.

4
5
6

Depending on the functionality implemented by and the ambition level of the IWF-node vendor, KPIs
regarding the link quality could be accessed by an external management system. Details regarding this KPIreporting are out of scope of this specification.

7

8.11.1. IWF CPRI transmitter fault recovery/actions for CPRI detected faults

8

Only two bits shall be treated separately: LOF and LOS bit in the #Z.130.0.

910Normally the LOF and LOS bits are forwarded as is from the received eCPRI messages. Special handling isrequired when locally detecting LOS and LOF errors.

11
12

When the CPRI receiver detects LOF, the LOF bit shall be set in the CPRI transmitter. The locally-detected
LOF shall be OR-ed with the LOF bit reported in the received eCPRI message.

13
14

When the CPRI receiver detects LOS, the LOS bit shall be set in the CPRI transmitter. The locally-detected
LOS shall be OR-ed with the LOS bit reported in the received eCPRI message.

15
16

8.11.2. IWF CPRI transmitter fault recovery/actions for Ethernet detectedfaults17

Upon detection of Ethernet errors following actions shall be performed:

18

•

o

19
20

•
•

The generated value based on the local CPRI TX frame structure counter.

For HFN (#Z.64.0), the affected CPRI byte(s) shall be filled with:
o

21
22

For control word 0 (including the “sync byte”), the affected CPRI byte(s) shall be filled with:

The value based on the local HFN counter in the IWF.

For BFN (#Z.128.0 and #Z192.0), the affected CPRI byte(s) shall be filled with:23o

Opt BFN. 1: zeros.

24o

Opt BFN. 2: the value based on the local BFN counter in the IWF.

25•

For “protocol version” (#Z.2.0), the affected CPRI byte(s) shall be filled with:26o

Opt err prot. 1: zeros.

27oOpt err prot. 2: the same value as before the Ethernet error.

CPRI

103

1

•

eCPRI Specification V2.0 (2019-05-10)

For “start-up” (#Z.66.0), the affected CPRI byte(s) shall be filled with:2o

Opt err prot. 1: zeros.

3oOpt err prot. 2: the same value as before the Ethernet error.

4•

For LOF in #Z.130.0, the affected CPRI bit shall be filled with the locally-detected LOF.

5•

For LOS in #Z.130.0, the affected CPRI bit shall be filled with the locally-detected LOS.

6•For SDI, RAI, Reset in the in #Z.130.0, the affected CPRI bits shall be filled with zeros.

7•

For “pointer p” (#Z.194.0), the affected CPRI byte(s) shall be filled with:

8o

Opt err prot. 1: zeros.

9oOpt err prot. 2: the same value as before the Ethernet error.

10•

For all CPRI “reserved” control words/bits:o11

Opt err prot. 1: the affected CPRI byte(s) shall be filled with zeros.

12•

For all other CPRI sub channels, the affected CPRI byte(s) shall be filled with zeros.

13•

For IQ data block, the affected CPRI bits shall be filled with zeros.

CPRI

104

1

9. List of Abbreviations

2

3GPP

3rd Generation Partnership Project3

BC

Boundary Clock4

BFF

Basic Frame Fragment

5

C&M

Control and Management

6

CFM

Connectivity Fault Management

7

CoMP

Coordinated Multipoint

8

CCP

Continuity Check Protocol

9

CFP

C Form-factor Pluggable

10

CPRI

Common Public Radio Interface

11

DiffServ

Differentiated Services

12

DL

Downlink

13

DSCP

Differentiated Services Code Point

14

EMS

Element Management System

15

eNB

Evolved NodeB

16

eRE

eCPRI Radio Equipment

17

eREC

eCPRI Radio Equipment Control

18

ETH-CC

Ethernet Continuity Check

19

ETH-AIS

Ethernet Alarm Indication Signal

20

ETH-LT

Ethernet Link Trace

21

ETH-LB

Ethernet Loopback

22

ETH-RDI

Ethernet Remote Defect Indication

23

ETH-LM

Ethernet Loss Measurement

24

E-UTRA

Evolved Universal Terrestrial Radio Access

25

FFT

Fast Fourier Transform

26

GM

Grandmaster

27

gNB

5G base station name

28

GPS

Global Positioning System

29

HW

Hardware

30

ICMP

Internet Control Message Protocol

31

iDFT

inverse Discrete Fourier Transformation

32

IEEE

Institute of Electrical and Electronics Engineers

33

IFFT

Inverse Fast Fourier Transform

34

IP

Internet Protocol

35

IPsec

Internet Protocol Security

36

IQ

In-phase and Quadrature

37

IWF

eCPRI/CPRI Interworking Function

38

L1

Layer 1

39

LT

Link Trace

40

LLC

Logical Link Control

CPRI

eCPRI Specification V2.0 (2019-05-10)

105

1

LB

Loop-Back

2

LSB

Least Significant Bit

3

LTELong Term Evolution

4

MAC

Media Access Control

5

MACsecMedia Access Control Security

6

MIMO

Multiple Input, Multiple Output

7

MSB

Most Significant Bit

8

Msps

Mega sample per second

9

MU-MIMO

Multi-User MIMO

10

N/A

not applicable

11

NMS

Network Management System

12

NR

New Radio Access Technology (for 5G)

13

OAM

Operations, Administration and Maintenance

14

OFDM

Orthogonal Frequency-Division Multiplexing

15

PCP

Priority Code Point

16

PDCP

Packet Data Convergence Protocol

17

PDU

Protocol Data Unit

18

PHY

Physical Layer

19

PRACH

Physical Random Access Channel

20

PTP

Precision Time Protocol

21

QoS

Quality of Service

22

QSFP

Quad Small Form-factor Pluggable

23

RE

Radio Equipment

24

REC

Radio Equipment Control

25

Req

Request26

Resp

Response

27

RFRadio Frequency, Radio Functions

28

RLC

Radio Link Control

29

RRC

Radio Resource Control

30

Rx

Receive

31

SAP

Service Access Point

32

SCTP

Stream Control Transmission Protocol

33

SFP

Small Form-factor Pluggable

34

SNMP

Simple Network Management Protocol

35

SRS

Sounding Reference Signal

36

SW

Software37

t1

Timestamp 1

38

t2

Timestamp 2

39

TCP

Transmission Control Protocol

40

tcv1

Compensation Value 1

41

tcv2

Compensation Value 2

CPRI

eCPRI Specification V2.0 (2019-05-10)

106

1

tD

One-Way Delay

2

TLS

Transport Layer Security

3

TTI

Transmission Time Interval

4Tx

Transmit

5

UDP

User Datagram Protocol

6

UE

User Equipment

7

UL

Uplink8

UMTS

Universal Mobile Telecommunication System

9

VID

VLAN Identifier

10

VLAN

Virtual LAN

CPRI

eCPRI Specification V2.0 (2019-05-10)

107

eCPRI Specification V2.0 (2019-05-10)

1

10. References

2[1]

Common Public Radio Interface (CPRI) Interface Specification V7.0

3[2]

http://www.3gpp.org/ftp/Specs/archive/36_series/

4[3]

http://www.3gpp.org/ftp/Specs/archive/38_series/

5
6

[4]

ITU-T Rec. G.8275.1/Y.1369.1 (06/2016) Precision time protocol telecom profile for phase/time
synchronization with full timing support from the network

7[5]IEEE Std 802.3-2018 IEEE, New York, USA, 14th June 2018.

8

[6]

void

9

[7]

SFF-8083, SFP+ 1X 10 Gb/s Pluggable Transceiver Solution (SFP10), Rev 3.1, September 13, 2014

10

[8]

SFF-8402, SFP+ 1X 28 Gb/s Pluggable Transceiver Solution (SFP28), Rev 1.1 September 13, 2014

11

[9]

SFF-8635, QSFP+ 4X 10 Gb/s Pluggable Transceiver Solution (QSFP10), Rev 0.6 June 29, 2015

12

[10]

SFF-8665, QSFP+ 28 Gb/s 4X Pluggable Transceiver Solution (QSFP28), Rev 1.9 June 29, 2015

13

[11]

http://standards-oui.ieee.org/ethertype/eth.txt

14

[12]

ISO/IEC 10646:2014, Information technology - Universal Coded Character Set (UCS)

15

[13]

IEEE Std 1588™-2008 (Revision of IEEE Std 1588-2002), New York, USA, 24 July 2008

16

[14]

IEEE Std 802.1Q™-2014 (Revision of IEEE Std 802.1Q-2011), New York, USA, 3 November 2014

17

[15]

Requirements for the eCPRI Transport Network (www.cpri.info)

18
19

[16]

ITU-T Recommendation G.8013/Y.1731 - Operation, administration and maintenance (OAM) functions
and mechanisms for Ethernet-based networks, 08/2015

20

[17]

RFC 792 - INTERNET CONTROL MESSAGE PROTOCOL, September 1981

21
22

[18]

RFC 4443 - Internet Control Message Protocol (ICMPv6), for the Internet Protocol Version 6 (IPv6)
Specification, March 2006

23

[19]

void

CPRI

108

1

eCPRI Specification V2.0 (2019-05-10)

11. History
VersionDate

Description

V 1.0

2017-08-22

First eCPRI specification

V 1.1

2018-01-10

Editorial corrections

V 1.2

2018-06-25

Section 1:• “The eCPRI interface can also be used between two eREC units or
between two eRE units” added below figure 1
Section 2.3:
• Table 1: Reference to 38.133 added for RF functions in NR caseSection 3.1.1:• Table 3: 25GBase LR/ER added with reference [19]Section 3.2.4.7.1:• “shall” replaced by “should”:“Upon reception of a valid “Reset request”, the eRE should send a“Remote Reset” Indication before performing the requested reset.”
Section 6.1.1:• Figure 32 updated (legend added for iDFT UL processing block)• Footnote 4 removed
Section 6.1.2:• Reworked and new subsection 6.1.2.1 “Bit Rate Calculation Example”
introduced
Section 8:• New reference [19] added

CPRI

109

V2.0

2019-05-10

eCPRI Specification V2.0 (2019-05-10)• Editorial corrections• Introduction of eCPRI/CPRI Interworking function (IWF) resulting in thefollowing list of detailed modifications:o Section 1: System configurations with eCPRI/CPRI IWF type 0 and
IWF types 1 and 2 added (new Figures 2 and 3)
o Section 2.1: new definitions added:▪

eCPRI/CPRI Interworking Function (IWF)▪

CPRI master port for IWF type 0▪

CPRI slave port for IWF type 1▪

CPRI slave port for IWF type 2oSection 2.2: Figure 6 (System Architecture example with local eCPRI)
added together with associated description.

oSection 3.2.4: Table 4 updated to cover IWF related eCPRI Message
Types #8...#11. Explicit statement added, that eCPRI Message Types#8...#11 intended IWF type 1  IWF type 2 communicationoSection 3.2.4.7.1 (Remote Reset) updated to cover IWF impacto

New section 3.2.4.9 “Message Type #8: IWF Start-Up”oNew section 3.2.4.10 “Message Type #9: IWF Operation”oNew section 3.2.4.11 “Message Type #10: IWF Mapping”oNew section 3.2.4.12 “Message Type #11: IWF Delay Control”oSection 4.4, Table 15 updatedo

New section 6.2.3 “Synchronization of IWFs”o

New section 6.5.2 “eCPRI/CPRI networking with eCPRI/CPRI IWF
type 0”o

New section 6.5.3 “eCPRI/CPRI networking with eCPRI/CPRI IWF
type 1 and type 2”o

New Annex B (section 7) “eCPRI/CPRI Interworking with IWF type 0(Informative)”o

New Annex C (section 8) “eCPRI/CPRI Interworking with IWF type 1
and type 2 (Normative)”oSection 9: Abbreviations updatedoSection 10: References updatedoSection 11: History updated

1

CPRI