Mobile

fronthaul
Testing reference guide
A best practices approach for validating
fronthaul networks
 About EXFO Table of contents
EXFO develops smarter network 1 Introduction.............................................................................................................................. 3
test, monitoring and analytics 1.1 Fiber characterization......................................................................................................... 6
solutions for the world’s leading 1.1.1 Connector inspection................................................................................................. 9
1.1.2 Inspecting and cleaning a connector.......................................................................10
communications service providers,
1.1.3 Fiber loss measurement..........................................................................................15
network equipment manufacturers 1.1.4 iOLM set‑up..............................................................................................................15
and webscale companies. Since 1.2 Fronthaul link validation...................................................................................................18
1985, we have worked side by side 1.2.1 Technical requirements............................................................................................19
with our clients in the lab, field, data 1.2.2 RRH validation test...................................................................................................20
1.2.2.1 How to start the CPRI test application....................................................20
center, boardroom and beyond to
1.2.2.2 CPRI interface rate configuration............................................................20
pioneer essential technology and 1.2.2.3 CPRI link‑up..............................................................................................21
methods for each phase of the 1.2.2.4 How to verify the CPRI state....................................................................21
1.2.2.5 CPRI protocol version..............................................................................23
network lifecycle. Our portfolio of
1.2.2.6 CPRI control and management (HDLC and Ethernet).............................23
test orchestration and real-time 3D 1.2.2.7 SFP/SFP+ information.............................................................................24
analytics solutions turn complex 1.2.2.8 Confirming that CPRI data has been received.........................................24
1.2.2.9 Verification when alarms or errors are present.......................................25
into simple and deliver business- 1.2.2.10 Extra—how to inject alarms and errors....................................................26
critical insights from the network, 1.2.3 C‑RAN architecture validation tests.........................................................................28
service and subscriber dimensions. 1.2.3.1 CPRI bit error rate validation test.............................................................28
1.2.3.2 CPRI BERT configuration.........................................................................28
Most importantly, we help our clients 1.2.3.3 CPRI bit error rate measurement.............................................................30
flourish in a rapidly transforming 1.2.3.4 Optional step—CPRI BERT configuration validation................................31
industry where “good enough” 1.2.3.5 CPRI latency measurement.....................................................................32

testing, monitoring and analytics just 1.3 Site commissioning using BBU emulation...................................................................35
1.3.1 Connection from the RRH to the FTB-1 Pro.............................................................35
aren’t good enough anymore—they
1.3.2 Starting the BBU emulation application...................................................................36
never were for us, anyway. 1.3.3 Setting up the BBU emulation application to initiate the test..................................36
1.3.4 Creating reports in BBU emulation ..........................................................................37
For more information, visit 1.3.5 Additional/optional BBU emulation features...........................................................38
www.EXFO.com and follow us 1.3.5.1 BBU emulation results and log.................................................................38
1.3.5.2 Antenna carrier and Rx-Tx frequency.......................................................38
on the EXFO Blog at 1.3.5.3 Bandwidth, VSWR and Tx power..............................................................39
www.EXFO.com/corporate/blog. 1.3.5.4 OCNS, PCI, RET and RET Tilt....................................................................39

1.4 RF spectrum analysis over CPRI ...................................................................................40

1.4.1 Connecting to the digital uplink...............................................................................40
1.4.2 Starting the OpticalRF™ application.........................................................................41
1.4.3 Setting up the OpticalRF™ application to view the RF spectrum over CPRI.............41
1.4.4 Validating the CPRI RF spectrum.............................................................................42
1.4.5 Additional/optional RF spectrum configurations ....................................................43

2 Test documentation..........................................................................................................45
3 PMD/CD dispersion...........................................................................................................47
3.1 Best practices.....................................................................................................................47
3.2 Doing the test......................................................................................................................47

4 Field test process automation and analytics...................................................48

4.1 Key benefits of the TestFlow solution...........................................................................48
4.2 Solution architecture.........................................................................................................49
4.3 Project tracking and compliance analysis...................................................................50

5 Network quality monitoring systems (NQMS) ...............................................51

5.1 Key tools for dark fiber providers involved in FTTA...................................................51
5.2 Equipment—remote test unit (RTU)...............................................................................51
5.3 Motivations for monitoring fiber in the fronthaul.......................................................52

6 Appendix A—list of acronyms.....................................................................................53

2 Mobile fronthaul: Testing reference guide

1 Introduction
The mobile industry is undergoing a major transformation that is being driven by the exponential growth of traffic (mobile
broadband and video), new services (e.g., the Internet of Things and private mobile radio) and new requirements (lower latency
and ubiquitous coverage). The traditional radio access architecture is migrating to a distributed architecture (centralized radio
access network [C‑RAN]), with the replacement of copper radio frequency (RF) cables by optical fibers (fiber‑to‑the‑antenna, or
FTTA). This transformation requires a split of the radio elements (remote radio head [RRH] or remote radio unit [RRU]) and the
broadband unit functions (baseband unit [BBU] or digital unit [DU]), and deployment of two competing digital RF communication
protocols: Common Public Radio Interface (CPRI) and Open Base Station Architecture Initiative (OBSAI). These elements are
typically referred to as fronthaul technology.

IP/MPLS
network
Central office /
data center
(BBU hotel)

D-RoF
ul
kha
RRH B ac
RRH
Optical D-RoF
RRH
distribution
network RI
RRH
l : CP way)
RRH au a
RRH ro nth 5 km
F to 1
(up

Figure 1. A typical fronthaul network

This document will start with a review of the best practices applicable when the RRH and BBU are collocated, which represents
the foundation for the next step: C‑RAN. In a C‑RAN environment, the BBUs are pooled at a central site, usually in a central office
or data center—also commonly referred to as the BBU hotel. Next, the document will review best testing practices applicable
during C‑RAN deployment.

Prior to discussing the fronthaul, it is important to take a closer look at the RAN architecture without any fronthaul implications,
as follows:
– The mobile core is connected to the base station through an IP network that is referred to as the backhaul
– The base station (BTS or Node B/eNodeB) itself is made up of the following four components:
– The BBU, which is the intelligence of the RAN (eNodeB or eNB)
– Radio management
– RF amplifiers
– Antennas
– Antennas are connected to the cell‑site cabinet through copper cables, which have the following disadvantages:
– Are very expensive
– Are subject to passive interference modulation (PIM)

Mobile fronthaul: Testing reference guide 3

 Antennas

Copper/coaxial
cables

Cell-site cabinet C
MS re
SGS
N
S co
RF amp. Radio
C S/P
RF amp. Radio Baseband Backhaul
unit
RF amp. Radio

Cell-site MPLS
router (CSR)

Figure 2. Typical architecture for 2G/3G cellular deployments

To reduce costs and replace copper cables, the radio/RF component is displaced to the top of the cell tower or rooftop. This new
element, the remote radio head (RRH), is connected to the BBU through optical fibers. This connection between the RRH and
BBU is referred to as the fronthaul, and uses the CPRI transport protocol. The fronthaul supports all radio access technologies
(RATs), including 2G, 3G, 4G LTE and LTE A; it will soon support 5G as well.

RRHs
Radio RF Amp. Ant.
RadioRFRF
Radio Amp.
amp. Ant.
Ant.

Optical fiber
cables

E
MM
GW
Cell-site cabinet E HeN
B
MM
ed re
GW olv co
HeN
B
Ev cket
Baseband pa
unit Backhaul

Cell-site MPLS
router (CSR) S11
Fronthaul

Figure 3. Typical architecture for 4G/LTE cellular deployments

With fronthaul architecture, the mobile communications industry is going through a major transformation in radio access.
As such, the deployment, maintenance and assurance of fronthaul requires a new test methodology combining optical fiber
and transmission testing, as well as service assurance.

Fiberization of antenna sites is the first and most significant step for:
– The deployment of new RATs (e.g., LTE‑A coordinated multipoint [CoMP])
– Increased RAN efficiency (C‑RAN)
– Preparation of the 5G era (with RAN virtualization and mobile edge computing, or [MEC])

4 Mobile fronthaul: Testing reference guide

 MEC Mobile edge computing
• Distributed content
FTTA is the foundation of RAN modernization. Testing FTTA at
• RAN-aware content optimization
the rollout phase will ensure the readiness of the antenna sites • Active device location tracking
to support:
– The next evolution to C‑RAN
– The increase of bit rates (larger carrier bands) Virtual Virtualization of BBU functions
• BBU function slicing
RAN
FTTA is the first critical step towards the adoption of new RAN • Enable service-specific RAN

architectures such as C‑RAN (and vRAN, its virtualized flavor),

and the addition of service‑specific processing at the RAN level
for services such as Video on Demand (VoD) and local content
C-RAN Centralization of the BBUs in BBU hotels
delivery network (CDN) functions (MEC). • Group BBUs in pools to optimize utilization
• Facilitate inter-BBU communication (X2)
Given the importance of FTTA as the foundation for next‑generation
wireless architectures, a high level of vigilance is required during
its deployment phase. If the execution of the FTTA rollout is
performed without quality measures in place, the cell site will
FTTA Fiber to the antenna
• Copper replaced by fiber
require retesting, and may need a rebuild to ensure efficient • Split between BBU and RRH
centralization of BBUs. • CPRI transport between BBU and RRH

RRH RRH

Top Top
junction junction
box box

Bottom Bottom
junction junction
box box

15 km

Figure 4. FTTA deployment with collocated BBU Figure 5. C-RAN architecture: FTTA deployment
and RRH at the cell-tower location using a CPRI transport system

Mobile fronthaul: Testing reference guide 5

 Best practices—testing during the construction phase
Installation of the optical physical layer during the construction stage is one of the most important steps towards an
easy‑to‑maintain system. However, many customers have been observed using a no‑test approach early on in the deployment
phase. During a mobile fronthaul installation, there can be as many as four connection points, and this is where many issues will
first be seen, as confirmed by professionals with fiber experience. Another key element is the type of fiber used. For example,
some installations have bend‑resistant fibers (ITU‑T G.657), whereas others use standard fibers (ITU‑T G.652), which is sensitive
to macrobending. Fiber mismatch is also a very common issue, in which the connector is not well seated into the small
form‑factor pluggable (SFP), the wrong SFP is used, or the SFP data rate is incorrect. In addition, because optical fibers with
different wavelengths are used for wavelength‑division multiplexing (WDM) systems (mainly in C‑RAN deployment), it is very
important to ensure that the right wavelength from the customer is connected into the right port on the WDM muxes and
demuxes. Old dark fiber is rented and prone to impairments, such as chromatic dispersion (CD) or polarization mode dispersion
(PMD). As a result, if the work is not done properly, the turn‑up team that is called on‑site may have to send for another climbing
crew in order to change the SFP, which is expensive, ranging from $1,000 to $1,500 per day, depending on the region.

This document describes all the steps needed to improve the key performance indicator, which is do it right the first time!

1.1 Fiber characterization

The purpose of any fiber‑optic network is to perform high‑speed, error‑free data transmission. Adequate testing during
each phase of the network deployment guarantees that products meet specifications, in addition to minimizing costly and
time‑consuming troubleshooting efforts such as locating dirty/damaged connectors, questionable splices and other faulty
components before they disrupt service.

One of the most important factors in ensuring proper transmission is controlling the power loss in the network against the link
loss budget specifications from the network design requirements. This is done by establishing a total end‑to‑end loss budget
with sufficient margin while keeping back reflection to a minimum. The following section will take a closer look at parameters
that are capable of greatly affecting network performance.

One of the first tasks that needs to be performed during the design phase of a fiber‑optic network is an evaluation of the
acceptable budget loss in order to create a product that will meet application requirements.

What causes loss in the fiber? Loss includes both intrinsic attenuation and extrinsic discontinuities in a fiber‑optic cable, such
as connectors and splices. Link loss is wavelength dependent, measured in decibels per kilometer or dB/km, and used in
calculations for determining the overall loss budget.

The following key parameters are usually considered in order to adequately characterize budget loss:
–– Transmitter: launch power, temperature and aging
–– Fiber connections: connectors and splices
–– Cable: fiber loss and temperature effects
–– Receiver: detector sensitivity
–– Others: safety margin and repairs

When one of these variables fails to meet specifications, the performance of the network could be greatly affected—or worse,
the degradation could lead to network failure.

6 Mobile fronthaul: Testing reference guide

The illustration on the right (Figure 6) shows an example of the typical
total loss budget calculation.
Remote radio unit
Important specifications for consideration: Antenna Fiber jumper

– Connector loss, typically around 0.2 dB per connector pair.

– Fiber loss, which is equal to attenuation multiplied by distance.
The maximum distance is limited by the loss budget at the
worse‑case attenuation wavelength (1310 nm with approximately Coax jumper Junction box
0.33 dB/km attenuation). The maximum length in an RRH
application will be hundreds of meters for a large deployment.
Fiber cable
The budget loss calculation should be one of the first verifications
Base
performed prior to any deployment. If, for example, a system is designed junction
with the elements present in the figure below, the launch power of the box

transmitter at 1550 nm is 0 dBm, and the detector sensitivity is at

–10 dBm, the accepted budget loss of 10 dB will compromise system Baseband unit
performance. However, tighter design tolerances can be set in order
to prevent long‑term evolution of the network. For example, the typical
budget loss in a collocated BBU‑RRH will be between 1.5 dB and 3 dB, Figure 6. Typical RRH installation
depending on the number of connectors or splices present. Still, in a
passive C‑RAN installation, the budget will be affected by the different
elements, leaving less margin. In the example below, the budget loss
could vary from 8.8 dB up to 14.7 dB if at the maximum of each tolerance.

BB
U
BB
U
BB
U

l
RRH
te
ho
U
B
B
km
15

s
or
dB ct
dB

.4 nne
0. inim <3

<1 o
2 UX

< 2c
<
M
dB

dB m
6 u
r
be
fi
M

M
D
W
C

nm )
15 10 B
m
at 13 d

)
50 n
dB /k < er
m at .5
.2 dB B ib

dB
3 UX

/k m <4
(0 .3 d F
dB
< M

.7
E

14
dB D
<

ne 8 d s

<
on . or
c B
/c <2 ct

ss
)
(0
dB < e

lo
to
5 B n
2

0. d n

er
e 2 co

ow
1. 4

lp
um

ta
im

To
in

<
g
M

ra

dB
ve
(a

8
8.

Figure 7. Budget-loss variation in a passive C-RAN installation

Mobile fronthaul: Testing reference guide 7

 Therefore, the total loss measured during network deployment should not exceed the
total loss budget allowed by the system design, and should have enough margin to
Maintenance
compensate for any loss fluctuation that could occur during the lifecycle of the system.

Once the design of the system has been completed, the lifecycle of a network Commissioning
and optimization
generally consists of three main phases, as shown in the diagram to the
right. This section focuses primarily on fiber characterization during the
construction phase. Construction

The bottom of the pyramid represents the construction deployment stage,

which involves most of the work required to prepare the dwelling‑connected
fiber up to the fiber expansion units. In some cases, the installation contractor will
be responsible for this stage.

Installation of the optical physical layer during the construction stage is one of the most important steps for an easy‑to‑maintain
system and a high return on investment. Sufficient testing during construction will locate problematic splices, dirty or damaged
connectors, and other faulty components before they can cause service disruption—all of which minimizes costly and
time‑consuming troubleshooting efforts during the commissioning phase. It is therefore essential to implement best practices
for optical testing during this phase in order to ensure a successful yet easy‑to‑maintain RRH in the future.

Proper connector care and fiber‑optic cable handling are important pieces of the puzzle, and ensure a less problem‑prone
network. Another important aspect is end‑to‑end fiber documentation. These documents are critical to ensuring a shorter
response time to resolve customer complaints or service interruptions caused by network‑related issues.

Testing during the construction phase is a key step to:

– Qualify each fiber section of the system and document it for future reference
– Ensure that transmission system requirements (standards) are met
– Avoid delays and costly repairs once the system has been turned up

Construction
Test type Out‑of‑service test

– To qualify each optical element (e.g., fiber and connector) of the system
– To ensure the installation meets transmission system requirements
Why test?
– To avoid delays and costly repairs during system turn‑up
– To future‑proof the network

– Connector and ferrule cleanliness

– Optical loss or insertion loss (IL) of each element
– Total end‑to‑end loss as compared to the optical loss budget
Test parameters
– Fiber mapping
– Optical return loss (ORL) measurement, especially for RF/analog video
– In C‑RAN: CD and PMD for long fiber (>10 km)

– OTDR or intelligent Optical Link Mapper (iOLM)

Test gear – Fiber inspection probe
– CD and PMD

– Connector inspection
– Testing at different wavelengths (1310 nm and 1550 nm) for IL and ORL
– LinkView or OTDR trace documentation using 1310/1550 (reporting)
Testing considerations
– Data storage
– Testing the total link or segments
– Applicable work/labor

8 Mobile fronthaul: Testing reference guide

1.1.1 Connector inspection
All connectors on the link must be inspected using the inspection tools indicated in the section below. Inspection results
are held to International Electrotechnical Commission (IEC) standards for acceptance criteria selected in the user interface.
Most fiber connectors present in the RRH application will be LC/ultra‑polished connector (UPC), and will require use of the
IEC SM SF UPC ORL ≥ 45 dB (61300-3-35, 1.0) configuration.

To inspect the APC connector on the iOLM port, the IEC SM SF APC (61300-3-35, 1.0) configuration is required.

Choosing the right fiber inspection tips

Part number FIPT-400-LC-SQ FIPT-400-LC-APC FIPT-400-FC-SC FIPT-400-SC-APC

LC/UPC tip for LC/APC tip for FC‑SC/UPC tip for SC/APC tip for
Description bulkhead adapter bulkhead adapter bulkhead adapter bulkhead adapter

Part number FIPT-400-U12M FIPT-400-U12MA FIPT-400-U25M FIPT-400-U25MA

Universal patchcord tip for Universal patchcord tip for Universal patchcord tip for Universal patchcord tip for
Description 1.25 mm LC ferrules 1.25 mm LC APC ferrules 2.5 mm SC ferrules 2.5 mm SC APC ferrules

Part number FIPT-400-LC-A6 FIPT-400-MF-MPO FIPT-400-MF-MPO-APC FIPT-400-MF-MPO-X

MPO/UPC Universal MPO/APC Universal MPO/UPC Universal

Patchcord and Bulkhead Patchcord and Bulkhead Patchcord and Bulkhead
LC angled tip for bulkhead 12 fibers row connector. 12 fibers row connector. 16 fibers row connector.
Description adapter (60 degrees) Compatible with single and Compatible with single and Compatible with single and
dual row connectors, dual row connectors, dual row connectors,
up to 24 fibers up to 24 fibers up to 32 fibers

Mobile fronthaul: Testing reference guide 9

 1.1.2 Inspecting and cleaning a connector
As detailed in the previous section, connectors are key A B
elements that interconnect the different components of a
network; failure to inspect and clean them as needed can
lead to network failure.

Where and what to inspect and clean

– Active equipment (BBU and RRH)
– CPRI panel
– Junction box Figure 8. a) Scratch in the core region; b) Chipping on the cladding

– Test jumper
– Cable connectors
– MUX/DEMUX (add/drop), if not spliced

When to inspect and clean the connectors

The very first step to fiber testing is inspection of connectors at all testing phases (construction, optimization and maintenance).
Connectors should be cleaned only if inspection reveals they are dirty.

What to look for during connector inspection

During inspection of a connector ferrule, two types of problems may be encountered: a damaged endface or a dirty endface.

Physical damage to connector endfaces is generally permanent and in most cases will require connector replacement, except
in cases where the damage is not detrimental to the endface. When determining whether or not the damage is detrimental, a
good rule of thumb is to discard or replace any connectors with scratches near or across the fiber core (Figure 8.a), because
these scratches can generate high loss and affect connector performance. For physical damage, including chipped cladding
(Figure 8.b), worn connectors, and/or excessive epoxy residue on the cladding, the connector must be replaced.

10 Mobile fronthaul: Testing reference guide

In an ideal environment (i.e., free of contaminants), connector endfaces would remain clean and never require in‑depth
maintenance. However, this is rarely the case due to the high amount of fiber‑optic connector contaminants present in most
situations. For example, a 1 μm dust particle on a singlemode (SM) core is capable of blocking up to 1% (0.05 dB loss) of light
and, accordingly, a 9 μm dust particle would block a significantly higher percentage of light. Another factor that should be
taken into consideration is the effect of high‑power components on the connector endface. Some modern telecommunications
components can produce signals with power levels up to 30 dBm (1 W); this can have catastrophic results when paired with
a dirty or damaged connector endface (e.g., fiber fuse).

Dust, isopropyl alcohol, oil from hands, mineral oils, index‑matching gel, epoxy Clean
resin, oil‑based black ink and gypsum are among the contaminants that can
affect a connector endface. Some of these contaminants are single soil
particles, whereas others are complex soil combinations.

Note that each contaminant shows up differently and, regardless of the Dust Liquid contamination

appearance of these contaminants, the most critical areas for inspection are the
core and cladding because contamination in these regions can greatly impact
signal quality. Figure 9 illustrates the endfaces of different connectors that have
been inspected with a video inspection probe.

A best practice to avoid connector endface damage or contamination is to Dry residue Oil from hand

always keep a protective cap on unused connectors. As such, it is also important

to store unused protective caps in a sealed container to prevent contamination.

When inserting the protective cap on a ferrule, do not push it all the way in,
because small dirt particles can accumulate at the bottom of the cap and
contaminate the connector endface upon contact. Note that outgassing from Figure 9. Clean connector endface vs. different
contaminant types
the manufacturing process of the dust cap can leave a residue of the mold
release agent or materials in the cap; the role of these protective devices is
merely preventive—their presence does not guarantee cleanliness. In addition,
test jumpers and connectors received in sealed bags from the supplier may
not have been clean at the time of packaging, in which case they will be dirty
upon removal. Fortunately, soiled connectors can be cleaned effectively using
the appropriate cleaning tools and procedures.

Note: To ensure cleanliness, inspection should be performed on all brand‑new, factory‑delivered jumpers and cables.

Mobile fronthaul: Testing reference guide 11

 Most common connector issues

Dust/dirt residue Before mating

If connectors are not cleaned properly,

residues will be transferred and can lead to
permanent damage during mating.

After mating

Patch panel

Wet residue
– Most often caused by an incorrect cleaning technique
After drying
– Fibers must be carefully dried after a wet cleaning

Oily residue
– Most often caused by touching with fingers; technicians must
avoid touching the fiber ends
– An oily residue may act as a matching gel
– May or may not affect IL and return loss (RL) in the short term
– May trap dust and increase IL and RL over time

Circular residue
– Most often caused by an incorrect cleaning technique
– Occurs when fiber is mated while still wet
– Typically happens in the contact area Patch panel

– Contamination will migrate from male to female fiber ends

Adhesive region defects

– May occur during the manufacturing process or from
mishandling
– Epoxy residue and chips may occur in this region
– Normal if size does not exceed standards

Dirty/damaged connector
– Most often results from poor handling or cleaning
– Defects appear small, but may still fail inspection criteria

Scratches
– May appear as light or dark defects
– May be difficult to see with the naked eye
– Critical when in the core area of SM fibers

12 Mobile fronthaul: Testing reference guide

Step-by-step inspection instructions
1. Connect the probe to the connector being inspected, and then select the corresponding IEC standard.
2. Set the probe magnification to high.*
3. Locate, center and adjust the focus.*
4. Start the analysis using the Capture button.
5. View the pass or fail result.
6. Clean or replace the connector, depending on the result.
7. Save the analysis report.

* During inspections performed using the FIP‑430B/FIP‑435B Wireless Fiber Inspection Probe, steps 2 and 3 are automated.

1
7

(If required)

Figure 10. Step-by-step inspection instructions

Tools needed for cleaning

Appropriate cleaning methods and accessories must be used on any connector that fails acceptance criteria for endface
inspection. Failure to use proper cleaning accessories and techniques may result in connector damage and/or network failures.

Dry cleaning
The first recommended step is to use a mechanical cleaner. If, after two dry cleaning attempts, there is still soil on the connector,
proceed to hybrid cleaning.

Single-fiber mechanical cleaner Multifiber mechanical cleaner Patchcord mechanical cleaner

(male/female) [MTP/MPO] (male/female) (female only)

Mobile fronthaul: Testing reference guide 13

 Dry cleaning method
Insert the jumper, and then push the outer shell to begin cleaning. A clicking
sound will indicate that cleaning is complete. Some mechanical cleaners are
compatible with male and female jumpers, in addition to multifiber push‑on
(MPO) and other connectors.

Hybrid cleaning
Hybrid cleaning is a combination of the wet and dry cleaning methods, and involves use of a solvent. The first step involves
cleaning the connector endface with a solvent and then drying off any remaining residue using either a wipe or swab. If, following
the hybrid cleaning procedure, the connector still fails to meet the acceptance criteria, it should be replaced.

Cleaning pen Cleaning swabs Lint-free wipes

Used to dispense optical grade Used to clean the inside of female Used in dry cleaning procedures and
solvent to clean optical connectors connectors and adaptors also used to dry out any solvent

Cleaning connectors using the hybrid method

BEGIN
1. Wet a corner of the wipe with solvent.
2. Using a smooth, linear motion, trace the endface Quantity scratches
of the jumper over the wet area two times. and defects

3. Using a smooth, linear motion, trace the endface

of the jumper over the dry area three times.
Meets No
acceptance
criteria?

Fail due to No
Yes Fail due to detects
scratches?

Yes Clean fiber endfaces

Quantity scratches
and defects

No Decrease Yes
defects?

DUT DUT
passes fails

END

Figure 11. Flowchart demonstrating the inspection procedure

recommended by the IEC-61300-3-35 standard
(http://webstore.iec.ch/webstore/webstore.nsf/artnum/034902 )

14 Mobile fronthaul: Testing reference guide

1.1.3 Fiber loss measurement
For these characteristics, an OTDR‑based measurement method is recommended, and is described in IEC 61280‑4‑2.
Although alternative methods of performing end‑to‑end loss measurement do exist (e.g., handheld power meters and light
sources), only an OTDR‑based method will provide full characterization and mapping of each element (connector, splice and
fiber section) present on the link. OTDRs can also be used to find faults that could be present on the link.

Detailed analysis of these OTDR traces allows for accurate measurement of total link attenuation and total link ORL; it also
provides a full breakdown of component losses along the link, including fiber section attenuation, splice losses, connector
insertion and return loss. In addition, excessive mismatches between fibers in different cable sections along the route can
be identified along with any problems, such as bends on the fiber. Normally, for commissioning or acceptance of a dark fiber
section, OTDR (or more recently, iOLM) testing is carried out at a minimum of two wavelengths. These wavelengths should be
representative of the wavelengths at which the fiber is to operate.

For WDM systems used mainly in C‑RAN deployments, which use optical filters (different wavelengths), it is very important to
ensure that the right wavelength (specified by the customer) is connected to the right port on the WDM muxes and demuxes.
To effectively test the circuit and ensure that both the transmitter (Tx) and receiver (Rx) are patched correctly, it is necessary
to use an iOLM with WDM wavelengths. The iOLM can be used to measure the fiber loss at the specific WDM wavelength
through the network cable to the drop site (cell site), provided that the MUX and DEMUX are optically designed. Furthermore,
the fiber can then be looped with an additional launch fiber onto the return fiber connected to the BBU. This means that both
the Tx and Rx links can be tested in one measurement.

OTDR-based solutions
The iOLM performs several consecutive OTDR‑like measurements at different wavelengths, in addition to measurements at
different power and pulse widths to ensure that there is no compromise on range or resolution, thus providing greater accuracy.
All of these traces are compared, analyzed and integrated for a complete, extremely accurate and repeatable link mapping.
The iOLM application is the best method capable of providing full assurance and consistency of the test results.

It is recommended that a launch and receive fiber be used to fully characterize the front and end connector. This method
produces a true and accurate end‑to‑end characterization.

1.1.4 iOLM set-up

Launch, loop and receive fiber calibration

Launch fiber Loop fiber Receive fiber

FTB-1 Pro with iOLM

Figure 12. Automatic measurement of launch and receive fibers

Mobile fronthaul: Testing reference guide 15

 Loop fiber

20 m loop

Technician 2

Tx Rx
56 m

Technician 1

Figure 13. FTTA testing with the FTB-1 Pro platform and iOLM application

Specialized testing techniques

As shown in the figure below, specialized software (such as iLOOP for the iOLM) will separate the two fibers in the original
measurement to generate a clear pass/fail status for each fiber. This enables the user to test the upload and download fibers
at the same time, as shown below.

Original measurement

FIBER 1 LOOP FIBER 2

Pos. –0.1580 0.0000 0.0562 0.0763 0.1325 0.2876 km
LAUNCH RECEIVE
A B

Len. 0.1580 0.0562 0.0201 0.0562 0.1551 km

iLoop Automatically separates

the two fibers for individual results
Split

FIBER 1 LOOP LOOP FIBER 2

Pos. –0.1580 0.0000 0.0562 0.0763 0.1325 0.2876 km
LAUNCH RECEIVE
A B

Len. 0.1580 0.0562 0.0201 0.0562 0.1551 km

Figure 14. iLoop application splits the iOLM results into two individual links—one for each fiber

16 Mobile fronthaul: Testing reference guide

 Figure 15. iOLM graphical display

Type of fault Diagnostic Solving the issue

The connector or bulkhead is damaged,

Bad connector Inspect and clean as needed.
dirty or not well connected

Inspect the fiber in this area for excessive bending.

Macrobend Excessive fiber bend Use of a visual fault locator (VFL) could help identify the
exact location of the macrobend.

Inspect the splice at this location, and resplice if needed.

Bad splice Excessive loss of a non‑reflective fault Use of a VFL could help identify the exact location of a
bad splice.

Table 1. iOLM diagnostic examples

The link composition is described below.

The detailed iOLM analysis of the total span or fiber link allows for accurate measurement in a single, simple linear view.

Measurements also generate pass/fail analysis according to the provider’s criteria:

– Total span distance
– Section and distance attenuation
– Total link loss (attenuation)
– ORL: the ratio of the forward optical power to the reflected optical power
– Splice loss: loss of optical power at a (fusion) splice point
– Connector loss: the loss of light at a mated pair of connectors
– Connector reflection: the percent of power reflected back from a mated pair of connectors
– Excessive mismatches between fibers in different cable sections

Mobile fronthaul: Testing reference guide 17

 Element diagnostics are associated with specific link element issues. Each failed link element will have associated diagnostics
to assist with troubleshooting. Some elements (such as macrobends) will have associated diagnostics, even in the case of a
pass status.

Connector loss, macrobends and splice loss that fall out of the design specifications will give clear failure analysis with
diagnostics and pointers to help resolve the problem.

Once the test has been completed, the result sections can be referenced for information about any potential fault present on
the fiber.

1.2 Fronthaul link validation

The fronthaul represents the portion of the network from the BBU to the RRHs at the cell‑site location. As previously discussed,
there are two types of fronthaul architectures:
– Distributed radio access network (D‑RAN) architecture, which is the collocation of the BBU and RRH
– Centralized radio access network (C‑RAN) architecture, which is the centralization of the BBUs in a common location
such as a central office (CO) or data center, with the RRH located in a remote site many miles/kilometers away

RRH RRH

Top Top
junction junction
box box

Bottom Bottom
junction junction
box box

15 km

Figure 16. D-RAN fronthaul architecture Figure 17. C-RAN fronthaul architecture

In both architectures, the RRH validation test is necessary. However, for C‑RAN architecture, additional tests are recommended.
C‑RAN includes a CPRI transport system. At the optical level, the system can be a coarse wavelength‑division multiplexing
(CWDM) or dense wavelength‑division multiplexing (DWDM), while at the protocol layer, it is based on an optical transport
network (OTN) CPRI transport system. As such, two important validation tests are recommended. One test validates the signal
integrity of the transport system by measuring the bit error rate (BER). The other test involves measuring latency through the
system and fiber span. Minimizing latency in the transport system and long‑distance fiber span is critical in order to ensure
proper cellular network operation. The following section describes the recommended test steps for complete fronthaul link
validation in detail.

18 Mobile fronthaul: Testing reference guide

1.2.1 Technical requirements
Supported on the FTB-1 Pro test platform, the NetBlazer modules shown in figures 18, 19, 20 and 21 all have the framed CPRI
test capability. The supported CPRI rates range from 1.2 Gbit/s to 9.8 Gbit/s.

Connection to the CPRI optical interface requires use of an SFP optical module. EXFO has qualified a multirate SFP+ (SFP‑8600)
that is capable of covering all currently supported NetBlazer CPRI rates (e.g., 1.2G, 2.4G, 3.1G, 4.9G, 6.1G and 9.8G).

The figures to the right show the SFP port interface used on various NetBlazer V2 Series modules. These ports are used to
communicate with a BBU or RRH using the CPRI protocol test application.

SFP port 1 or port 2 (module A and B)

CPRI: All rates from 1.2 Gbit/s to 9.8 Gbit/s
SFP port 1 or port 2
CPRI: All rates from 1.2 Gbit/s to 9.8 Gbit/s

Figure 18. CPRI interfaces on the FTB‑870 V2/FTB‑880 V2 modules Figure 19. CPRI interfaces on the FTB‑720G V2/FTB-730G V2 modules

SFP port 1 or port 2 SFP port 1 or port 2

CPRI: All rates from 1.2 Gbit/s to 9.8 Gbit/s CPRI: All rates from 1.2 Gbit/s to 9.8 Gbit/s

Figure 20. CPRI interfaces on the FTB‑870Q/FTB-880Q quad modules Figure 21. CPRI interfaces on the FTB-890NGE 100G module

Mobile fronthaul: Testing reference guide 19

 1.2.2 RRH validation test
The RRH validation test can be performed for D‑RAN and C‑RAN architectures. From the BBU location, this test validates that
the RRH is powered up correctly, the SFP optical module and fibers are connected properly, and the RRH is fully operational at
the interface rate being tested without any CPRI errors or alarms.

1.2.2.1 How to start the CPRI test application

The following steps must be completed on the EXFO NetBlazer tester.
1. Select the Wireless tab at the 3
bottom of the screen. Depending
on the number of activated test 2
applications, this step may not be
required.

2. Select the CPRI/OBSAI BERT option.

3. Select the Test Configurator tab.

Figure 22. Starting the CPRI Test Application

1.2.2.2 CPRI interface rate configuration

There are currently six CPRI interface rates, which range from 1.2G to 9.8G, supported on the NetBlazer. The user must know
the CPRI interface rate at which the RRH validation test will be performed. Perform the steps described below to configure
the desired CPRI interface rate and emulation mode. Before proceeding with the test, please ensure that the NetBlazer unit is
properly connected to the uplink and downlink fibers of the RRH.
1. Select the Modify Structure button.
1
2. Select the Framed L2 option
for framed CPRI layer 2
(default setting).

3. Select the CPRI interface rate at

which the test is to be performed 3 2
(1.2 Gbit/s to 9.8 Gbit/s).

4. Select the Base Station option

under Emulation Mode. 4
5
5. Select OK to finish.

Figure 23. Configuring the CPRI Interface Rate

20 Mobile fronthaul: Testing reference guide

1.2.2.3 CPRI link-up
Once the correct CPRI interface rate has been configured, the CPRI Link‑Up status should be displayed with a green arrow.

1. Verify that the CPRI link is

operational. This is depicted by
a green up arrow indicating that
communication with the RRH is
operational. If the CPRI link is down,
it will be displayed with a red down
arrow. In some cases, a CPRI link
down is due to the fact that the CPRI
configured rate does not match the 1
configured rate of the RRH under
test. EXFO recommends trying
different CPRI rates to see if a link
up can be achieved.

Also, the following sections describe

other possible troubleshooting
measures that can be taken when
the CPRI link is down.

Figure 24. CPRI link-up status

1.2.2.4 How to verify the CPRI state

The CPRI protocol standard defines states that are used by the RRH and BBU to establish and set up communication.
The following steps ensure that the CPRI state is operational.

1. Select the CPRI configuration box.

Figure 25. Navigating to the CPRI configuration

Mobile fronthaul: Testing reference guide 21

 1. Verify the CPRI state.

Figure 26. Reading CPRI States

States A to E are intermediate states

during which a negotiation between
the BBU and RRH occurs to establish a
proper CPRI communication link. The
State F (active link) or State G (passive
link) must be reached in order to start
the test. If State F or G is not achieved,
the CPRI link is not operational.

Figure 27. State of CPRI link

22 Mobile fronthaul: Testing reference guide

1.2.2.5 CPRI protocol version
The term protocol version as defined in the CPRI protocol standard is used to indicate whether or not line scrambling is enabled.
Protocol version 1 signifies unscrambled; protocol version 2 signifies scrambled. Scrambling is only possible on the higher
CPRI interface rates starting at 4.9 Gbit/s. (In digital communication, the scrambling function is used for proper direct‑current
[DC] balancing on the transmission line. This ensures that the same number of 1s and 0s are present in the data stream over
time, thereby minimizing signal drifts and bit errors.)

1. Keep the Protocol field set to Auto to

enable the NetBlazer to self‑adjust
to the protocol capabilities of
the RRH. The Auto setting is the 2
recommended setting. However, 1
during a troubleshooting or
lab‑testing phase, the protocol
can be set manually.

2. Verify the negotiated protocol with

the RRH. The negotiated protocol
indicates the capabilities negotiated
with the RRH.

Note: If the protocol capabilities of

the RRH do not match the NetBlazer’s
capabilities (when set to a specific
protocol), the Negotiated box will
appear in red.

Figure 28. Changing the protocol version

1.2.2.6 CPRI control and management (HDLC and Ethernet)

CPRI provides two control and management (C&M) communication channel types: slow bit rate with high‑level data link control
(HDLC) (legacy) and fast bit rate with Ethernet.

1. Keep the C&M Channel field set

to Auto to enable the NetBlazer to
self‑adjust to the capabilities of
the RRH. The Auto setting is the
recommended setting. However,
during a troubleshooting or lab 2
testing phase, the C&M channel type 1
and rate can be set manually.

2. Verify the negotiated C&M type and

bit rate with the RRH. Note: The
blue arrow in the box is pointing to
the C&M type that was negotiated
with the RRH. If the C&M type
and/or bit‑rate capabilities of the
RRH do not match the NetBlazer’s
capabilities (when set to a specific
C&M type and/or bit rate), the
Negotiated box will appear in red.

Figure 29. Changing C&M type and bit rates

Mobile fronthaul: Testing reference guide 23

 1.2.2.7 SFP/SFP+ information
This step is not related to CPRI testing; however, it contains valuable information about the optical SFP module inserted into
the NetBlazer.

1. If information regarding the SFP

inserted in the NetBlazer is required,
click the SFP/SFP+ tab.

Figure 30. SFP/SFP+ information

1.2.2.8 Confirming that CPRI data has been received

Once the CPRI link is operational (start‑up sequence in State F or State G), the test can be launched. The test will report the
statistics in terms of transmitted and received CPRI hyperframes and codewords. In addition, the negotiated protocol version
and C&M type/bit rate will be displayed.

1. Make sure that the NetBlazer is

either in State F or State G.

2. Press the Start button to start 1

the test. The results page will 2
automatically display. Note that
because the CPRI test application is
always generating and monitoring
CPRI frames, starting the test
will only start the statistical
counters, and CPRI error and alarm
monitoring.

Figure 31. CPRI statistics results display

24 Mobile fronthaul: Testing reference guide

1. Verify that the quantity of
transmitted and received 2
hyperframes and codewords are
increasing.

2. The test is complete once the 1

NetBlazer reports a Pass and No
Alarm result.

Figure 32. Reading CPRI frame statistics

1.2.2.9 Verification when alarms or errors are present

If alarms or errors occur during the test, the alarm or error type can be verified by navigating to the Alarms/Errors tab.

1. Select the Alarm/Errors tab to view 1

the reporting page.

2. A yellow status will appear to the left

of an item that was previously in an 4
2
error or alarm state. In this example,
the interface was previously in a
loss of signal (LOS) state that lasted 3
for 11 seconds. 5

3. A red status will appear for an item

that is currently in an error or alarm
state. In this example, the CPRI
link is reporting a remote alarm
indication (RAI) that has been
ongoing for nine seconds.

4. Time near each item is cumulative.

Box no. 4 in the CPRI alarms section
shows that the CPRI link was down
for 20 seconds (9 seconds for LOS
and 11 seconds for RAI). Figure 33. Alarms/errors reporting page

5. Click the Reset button to clear the

alarms/errors statistics counters.

Mobile fronthaul: Testing reference guide 25

 1.2.2.10 Extra—how to inject alarms and errors
The NetBlazer provides capabilities for injecting alarms and errors into the CPRI protocol. These alarms and errors are sent to
the RRH, mainly for troubleshooting and lab purposes.

1. From the Alarms/Errors tab in the

Results section, select the arrow.

2. Select the layer to be tested

(interface or CPRI).

Figure 34. Selecting the interface or CPRI for alarm/error injections

1. Select the type (Alarms or Errors) to

be tested. Note: For interface only,
the LOS alarms selection is available.

2. Select Inject. Note: The RRH will

receive a continuous LOS alarm, and
should then return an R‑LOS alarm.

Figure 35. Selecting the alarm or error to inject

26 Mobile fronthaul: Testing reference guide

1. For the interface, Code Violation and
K30.7 can be independently injected
to simulate defects.

Figure 36. Available error defects

1. CPRI Alarms can be injected by the

NetBlazer to the RRH.

Figure 37. CPRI injectable alarm type

Mobile fronthaul: Testing reference guide 27

 1.2.3 C-RAN architecture validation tests
1.2.3.1 CPRI bit error rate validation test

RRH

Top
junction
box

FTB-700G V2 Series FTB-700G V2 Series

CPRI transport system

(CWDM/DWDM/OTN)

15 km

Figure 38. CPRI BER validation through the CPRI transport system

As with any digital transport system, it is critical to ensure the lowest possible bit error rate (BER), because doing so guarantees
optimal performance and improved user experience. The BER test (BERT) is best performed using two EXFO NetBlazer testers.
Each testing direction can be tested independently, and if any errors are observed, the faulty direction can easily be isolated
and investigated further. The pass criterion for a CPRI BERT is a BER that is better than 1.0E‑12. However, the transport system
should ideally carry the signal error‑free.

1.2.3.2 CPRI BERT configuration

The CPRI interface rate at which BER testing is to be performed must be provided by the CPRI transport system vendor. EXFO’s
recommendation is to perform the BERT at the fastest CPRI interface rate supported by the CPRI transport system to ensure
that the CPRI link operates correctly up to the fastest supported rate.

The CPRI interface rate configuration

must be completed on each EXFO 1
NetBlazer tester as follows:

1. Select Modify Structure.

2. Select Framed L2.

3. Select the CPRI interface rate at 3 2

which the test is to be performed.

4. Select Base Station for the tester

located at the BBU/base‑station
location. 4
5
5. Select Remote Radio Head for the
tester located near the RRH location.

6. Click OK.

Figure 39. Configuring the CPRI interface rate

28 Mobile fronthaul: Testing reference guide

The CPRI BERT configuration must be
performed on each EXFO NetBlazer
tester.

1. Select the BERT box to enter the

BERT configuration window.

Figure 40. CPRI BERT window

The CPRI BERT configuration must be

performed on each EXFO NetBlazer
tester.
2
1. Uncheck the No Pattern Analysis
1
(Live) box to enable BERT. 5

2. Select the pseudo‑random bit

sequence (PRBS) for the Tx and for 3 4
Rx paths. The recommended pattern
is the default PRBS31 setting, which
is the most stringent pattern. The
Tx pattern of one tester must match
the Rx pattern of the other tester,
and vice versa.

3. In the Pass/Fail Verdict field, select

Bit Error Rate from the drop‑down
list (for a rate), or select Bit Error
Count (for a count).

4. In the BER Threshold field, set the

threshold to 1.0E 12 or a specific bit
error count threshold. Figure 41. CPRI BERT configuration

Note: The CPRI specification

requires that the BER be better than
1.0E‑12. Ideally, no bit errors should
be present in the system. Setting the
bit error count to 0 for the Pass/Fail
Verdict implies that no bit errors are
accepted during this test.

5. Select Start on each EXFO tester.

Note that the Results page will
display automatically.

Mobile fronthaul: Testing reference guide 29

 If the CPRI BERT is to be performed for
a specific time duration, the following 1
steps must be completed. The CPRI 2
BERT duration configuration must be
completed on each EXFO NetBlazer
tester.

1. Click the Timer tab.

2. Check the Duration option and enter

a user‑defined time period, or select
a time period from the predefined
times in the drop‑down list.

Figure 42. CPRI BER test duration configuration

1.2.3.3 CPRI bit error rate measurement

BERTs are executed to ensure that a network under load can deliver the specified throughput with a bit error rate below a
predetermined threshold for the testing period. For proper execution of a BERT, the test duration must be in the 12‑ to 24‑hour
range. This duration may vary from one operator to another. The duration must be long enough to ensure that the optical and
network components reach stability and remain in that mode for a substantial amount of time. This ensures long‑term link stability
and performance. A BERT can also be performed for a few minutes in order to gain a quick sense of short‑term link stability.

When the CPRI BERT is running on

each EXFO tester, test results will be 2
available on each unit. The test results
appearing on the tester at the BBU
location provide BER measurement
for the RRH‑to‑BBU link direction.
The test results appearing on the
tester at the RRH location provide BER
measurement for the BBU‑to‑RRH link
direction.

1. Verify the Bit Error Rate and

Count fields.

2. Verify that the Status is Pass.

1
A Pass with the No Alarm status 1
indicates that no bit errors were
observed. A Pass with the Alarms
status indicates that the bit error
rate or count is below the specified
threshold.
Figure 43. CPRI BERT results

30 Mobile fronthaul: Testing reference guide

1. Once the test has been completed,
a PASS status displayed in green is 1
a confirmation that the CPRI BERT
was completed successfully.

2. Select Yes or No to generate a test

report. Note: The generated test
report can be used for validation of
successful CPRI BERT completion.

3. If other CPRI interface rates need 2

to be validated, select Setup and
return to the CPRI Interface Rate
Configuration section.
3

Figure 44. CPRI BERT report generation

1.2.3.4 Optional step—CPRI BERT configuration validation

Some service providers may want further validation that the CPRI BERT is operating correctly. Bit error injection will ensure
that the CPRI BERT is configured properly. If this type of validation is required, the following steps can be performed prior to
launching a long‑term BERT.

With the CPRI BERT running on one of

the EXFO testers, perform the following
steps from the Results window:

1. Set the Bit Error injection type to

Manual.

2. Set the Amount of bit errors for

injection to 50.

3. Select Inject to inject 50 bit errors,

and then verify whether the errors
1
have been detected on the remote
EXFO tester. 2

Figure 45. CPRI BERT error injection

Mobile fronthaul: Testing reference guide 31

 1. Verify on the EXFO NetBlazer remote
tester that the test status changed 1
to FAIL.

2. Verify that the bit error count is 50.

3. Select Reset to clear the alarms.

3
If desired, repeat the previous steps
on the EXFO tester that just measured
the bit errors in order to validate the
opposite testing direction (remote 2
tester to local tester).

Figure 46. CPRI BERT error injection detection remote tester

1.2.3.5 CPRI latency measurement

RRH

FTB-700G V2 Series

CPRI transport system

(CWDM/DWDM/OTN)

15 km

Figure 47. CPRI round-trip delay measurement

The round‑trip delay (RTD) measurement from the BBU site location to and from the RRH can be performed with the EXFO
NetBlazer tester. The following steps outline the procedure for performing RTD measurements through a CPRI transport system.

32 Mobile fronthaul: Testing reference guide

On the EXFO tester at the BBU site
location, in the CPRI test application 1
Test Configurator window, perform the
following steps:

1. Select Modify Structure. 6

2. Select Framed L2.

3 2

3. Select the CPRI interface rate at

which the test is to be performed.
4
4. Select Base Station under the CPRI
Emulation Mode. 5

5. Select OK.

6. Select the Start button.

Figure 48. Configuring the CPRI interface rate

If the CPRI transport system and

the RRH are operating correctly,
the previous configuration steps
(1 to 5) should allow a CPRI link‑up
to be achieved, as shown in the
adjacent image.

Figure 49. RTD Measurement: CPRI link-up with RRH

Mobile fronthaul: Testing reference guide 33

 Once the CPRI Link‑Up is obtained
with the RRH, RTD can be measured. 4
Follow the steps as detailed in the
adjacent image.

1. Select the Functions button. 3 5

2. Select the measurement unit

(µs or ns).
2
3. If the internal processing time of the
RRH is known, enter the Toffset (ns)
value.

The RRH manufacturer may provide

the Toffset value. This will make it
possible to obtain a separate cable
delay measurement that includes the
fiber delay and transport system delay 1
without the RRH processing delay.

4. The total RTD measurement is

displayed in the Round Trip Delay
results table. The Delay T14 value is Figure 50. CPRI RTD measurement configuration
the total RTD.

5. Select the Stop button.

6. Select Yes or No to generate a

test report that includes the RTD
measurement.

Note: In a fronthaul link, the total RTD should be no more than 3 msec, including the processing time at the BBU. Using the BBU
technology available in 2015, the internal BBU processing time is typically around 2.75 msec. Excluding the BBU, this leaves
around 250 μs (3 msec minus 2.75 msec) of RTD budget for the CPRI transport system, the fiber link and the RRH processing
time. Accordingly, EXFO recommends that RTD (Delay T14) measurements be below 250 μs, and also recommends that further
information be obtained from the network equipment (BBU/RRH) manufacturer regarding the maximum tolerable RTD on the
fronthaul link in order to ensure reliable communication between the BBU and the RRH.

34 Mobile fronthaul: Testing reference guide

1.3 Site commissioning using BBU emulation
EXFO’s BBU emulation test application allows mobile cell technicians and contractors to ensure that cell sites are installed
correctly the first time prior to the site being handed over to the mobile network operator (MNO) for integration. The system
is designed for simple one‑click operation, with clear pass/fail results that make it possible to isolate problems quickly and
generate a complete test report, creating a birth certificate for the cell site.

The BBU emulation test can be performed for D‑RAN and C‑RAN architectures. The test is performed by connecting the fibers
from the RRH to the FTB‑1 Pro, directly at the BBU location. The test provides full emulation of the CPRI C&M and IQ data,
where valuable information, like local SFP, remote SFP, antenna RET status and tilt, received signal strength indication (RSSI),
and voltage standing wave ratio (VSWR) measurements, are identified and reported. The BBU emulation test generates LTE
transmission, which is used to perform PIM testing and isolate problems associated with RF interference.

The following steps must be completed on EXFO’s FTB‑1 Pro test platform with the BBU emulation application.

1.3.1 Connection from the RRH to the FTB-1 Pro

Beta sector Gamma sector

Remote radio head

Antenna
Fiber jumper
External Alpha sector
RET unit

Coax jumper Junction box

Fiber cable

Optical transceiver
Base
junction box

Up to 15 km away
Optical
transceiver

Figure 51. RRH to FTB-1 Pro connection

Test Config Description

ALU-LTE Basic Basic emulation test (RRH inventory and SFP information)

ALU-LTE Link Validation Link validation with RRH

ALU-LTE Turnup NoRET Full turn‑up of the cell site without RET support (inventory, SFP, VSWR and RSSI)

ALU-LTE Turnup Full turn‑up of the cell site (inventory, SFP, ALD, AISG bus scan, RET, VSWR and RSSI)

SelfTest BBU emulation application self‑test (loopback needed)

SFP Test Fiber and SFP validation (loopback needed)

Table 2. BBU emulation tests

Mobile fronthaul: Testing reference guide 35

 1.3.2 Starting the BBU emulation application
1. From the FTB‑1 Pro platform
toolbox, select BBU emulation.

Figure 52. FTB-1 Pro platform toolbox

1.3.3 Setting up the BBU emulation application to initiate the test

1. Select the Port1 or Port2 option.

2. Select the CPRI rate from the list 1

(Rate 2 to Rate 7). 3
2
3. Verify that the CPRI link is
operational. This is depicted
by the link status changing to
Active. If the link status stays at
LossOfSignal, the CPRI rate or
the connection to the RRH needs
to be re‑verified. (Do not proceed
without an active link.)

4. Select the Emulate menu.

Figure 53. BBU emulation main interface

36 Mobile fronthaul: Testing reference guide

1. Select the desired Test Config
option (Refer to table 2
in section 1.3.1).
1 2 3
2. Run the test.

3. The test will stop after sending

10,000 radio frame counts; by
enabling monitor mode, the test
will run continuously.

Figure 54. BBU emulation emulate tab

1.3.4 Creating reports in BBU emulation

1. Verify that the test has generated a
PASS or FAIL notification.

2. Select the Add/Report button.

2 1
3. Enter the desired test name and
select OK. 3

4. Repeat steps 1, 2 and 3 for all

sectors and until all technologies of
the cell tower have been covered.

5. Select the Report tab and blue

positioning bars will appear. Tap on
one of the blue positioning bars and
the Report window will be inserted
at that location.

Figure 55. BBU emulation add to report

Mobile fronthaul: Testing reference guide 37

 1. The Report name, site and notes
field can be updated by selecting the
Edit button. 3

2. Right-clicking on one of the tests gives

many options, like Rename and Delete.

3. Once the report is ready, select the 1

2
Export PDF button to generate a PDF
version of the report.

Figure 56. BBU emulation Emulate and Report tabs

1.3.5 Additional/optional BBU emulation features

1.3.5.1 BBU emulation results and log

Figure 57. BBU emulation results, results/log and log view

1.3.5.2 Antenna carrier and Rx-Tx frequency

1. EXFO’s BBU‑Emulation application
provides the ability to automatically
or manually configure the number
of AxCs.

2. The RRH’s upper and lower Tx/

1
Rx operating frequency limits are
automatically determined by EXFO’s
BBU emulation test application. The
user can modify and set the desired Tx 2
and Rx operating frequency within the
RRH’s operating frequency range.

Figure 58. BBU emulation Tx frequency

38 Mobile fronthaul: Testing reference guide

1.3.5.3 Bandwidth, VSWR and Tx power
When VSWR readings are required,
make sure the Tx power is at least
80% of the maximum power of the
RRH. VSWR readings are available
in Antenna Measurements under the
Results section.

1. Select the current signal bandwidth

(BW): 5 MHz, 10 MHz or 20 MHz.

2. The RRH’s upper and lower Tx power

2
limits are automatically determined
by EXFO’s BBU emulation test 1
application. The user can modify
and set the desired Tx power used
for the test.

Figure 59. BBU emulation Tx power

1.3.5.4 OCNS, PCI, RET and RET Tilt

1. Orthogonal channel noise simulator

(OCNS) simulates user load on
the downlink: Off, Idle, 50% and
100%. The number of users on a
radio system loads up the available
resource blocks and affects how the
mobile system performs. In order
to simulate real-world loading, OCNS
is applied to the last phase of the
emulate tests.

2. Set the physical cell identification

(PCI) that will be transmitted by
the RRH. 1
2
3. Select the RET that is attached to
the RRH that is under test. 3
4
4. RET Tilt sets the tilt (in 0.1 degree
increments) of the selected
antenna RET.
Figure 60. BBU emulation RET

Mobile fronthaul: Testing reference guide 39

 1.4 RF spectrum analysis over CPRI
EXFO’s OpticalRF™ enables field technicians to troubleshoot cell sites by accessing the RF signal at the BBU location. The system
is designed to provide the most powerful real‑time, high‑resolution RF spectrum analysis over CPRI to quickly identify external
RF interference.

CPRI RF spectrum validation can be performed for D‑RAN and C‑RAN architectures. The FTB‑1 Pro is connected from the BBU
location to the digital uplink, where the CPRI protocol carries the RF signal in a digital format (IQ data). Once the link becomes
active, the RF spectrum over CPRI analysis will identify the RF signal quality.
The following steps must be completed on EXFO’s FTB‑1 Pro test platform with the OpticalRF™ application.

1.4.1 Connecting to the digital uplink

The uplink is the signal that the tower receives from RRH
Downlink
cellphones, and needs to be verified because of its low Uplink Remote Radio Head (RRH) or
power and high susceptibility to RF interference. Remote Radio Unit
Antenna Fiber Jumper

Coax Jumper Junction Box

CPRI Link

Fiber Cable

Base
Junction Box

Base Station or
Baseband Unit or
eNobeB
Base Station

Figure 61. CPRI cell tower

1. Connect the fiber from the RRH to the A port of TAP

the splitter (TAP).
From
FromRRH
RRH
A

2. Connect the TAP’s B port to the BBU.

ToBBU
To BBU
B

3. From the FTB‑1 Pro, connect the uplink (A) of the To FTB-1
AB port to the SFP+ Rx port 1 or port 2. The SFP
AB

on the FTB‑1 Pro must be the same wavelength as

the SFP on the BBU and RRH. Also, the SFP must A side for Uplink Signal
B side for Downlink Signal
support the link speed.
Note: Both are transmit signals

Tx
From Tap AB Port SFP+ P1
Rx

FTB-1 Pro

Figure 62. FTB-700G V2 Series and splitter (TAP) connections

40 Mobile fronthaul: Testing reference guide

1.4.2 Starting the OpticalRF™ application
1. Select the OpticalRF™ application from the
FTB‑1 Pro toolbox.

Figure 63. FTB-1 Pro platform toolbox

1.4.3 Setting up the OpticalRF™ application to view the RF spectrum over CPRI
1. Select the Port1 or Port2 option under Source.
1
2. Select Auto from the drop‑down menu to
2
automatically discover the correct CPRI rate
option.

Figure 64. OpticalRF™ main interface

3. Verify that the CPRI link is operational by seeing

whether the Link status changed to Active. If the 4
link status remains LossOfSignal, the CPRI 3
rate or the connections to the uplink need to be
reverified. Do not proceed without an active link.
5
6
4. Select the Mapping option. The RRH
manufacturer and Channel Bandwidth
(Channel BW) are required.

5. Select the proper Antenna Carrier (AxC).

6. Set the Center frequency.

Figure 65. OpticalRF™ Graph tab

Mobile fronthaul: Testing reference guide 41

 7.a. Auto scaling (recommended)

1. Select the Amplitude Menu. 2

2. Select the Full Scale button to switch it on.

The RF spectrum will auto‑adjust the trace
to get a full view.

7.b. Manual scaling

3
3. The reference level moves traces along the 4
power axis (Y‑axis.) Change the reference
level to center the trace.

4. The scale changes the number of dB per

division in Y‑axis.
1

Figure 66. OpticalRF™ Amplitude tab

1.4.4 Validating the CPRI RF spectrum

After completing the steps above, the RF signal will be displayed on the FTB‑1 Pro using a real‑time, high‑resolution spectrum
over CPRI, making it easy to quickly identify issues such as external RF interference and passive interference modulation (PIM).
A quick look at the spectrum gives a general idea of whether the RF signal is good or if there is major interference affecting it.

OpticalRF™ enables multiple antenna carriers (AxC) to be displayed at the same time. This facilitates the ability to identify
internal from external interference by visualizing diversity imbalances.

1. The port/file that is already selected is

highlighted in blue.
1
2. Select the Overlay button
3
3. Select the second trace to be overlaid.
2

Figure 67. OpticalRF™ System tab

42 Mobile fronthaul: Testing reference guide

1.4.5 Additional/optional RF spectrum configurations
Sometimes there will be a small spike in the RF spectrum, making it difficult to determine whether it is RF interference or normal
mobile traffic. This situation requires more troubleshooting; OpticalRF™ has all the functions required to verify this uncertainty.
Crosshair

1. Select the Graph menu.

4
2. Select the Crosshair button to switch it on.

3. Move the crosshair across the graph.

4. Get the power (dB) and frequency (MHz) 3

readings. 2

Figure 70. OpticalRF™ Crosshair

Zoom

1. Select the Graph menu.

2. Select the Enable Zoom button to switch it on.

B
3
3. Click and drag from bottom to top on the
desired zoom location.

UnZoom
2
4. Select the UnZoom button. A 4

Figure 68. OpticalRF™ Zoom and UnZoom

Recording

1. Select the red button in the top right‑hand corner.

Type a filename and press OK.
1 2 3

Replaying

2. Change the source to File1 or File2. Select the

green loop in the top right‑hand corner to play
back a file and then select a filename to open.

Snapshots

3. Select the orange camera in the top right‑hand

corner to save a snapshot of the current RF
spectrum.

Figure 69. OpticalRF™ Record, Replay and Snapshot

Mobile fronthaul: Testing reference guide 43

 Minimum/Maximum/Average hold

1. Select the Traces menu. 2

2. Select the Trace button and a list of options 3

will open. 4

3. Select the type of trace.

4. Select the Enabled button to switch it on.

Figure 71. OpticalRF™ Traces tab

Displaying multiple graphs

1. Select the Graph menu.

2. Select the New button. 3

2
3. Select the type of graph from the box and
click OK.

4. Tap on any of the blue positioning bars and the

new graph will be inserted.

Figure 72. OpticalRF™ New graph

4 4

Figure 73. OpticalRF™ Select View

44 Mobile fronthaul: Testing reference guide

2 Test documentation
Although network test documentation helps with the planning and expansion of network capacity (bandwidth and routing), this
need is generally considered only when a problem occurs. When the network is down, productivity is normally lost and customers
may not be supported, all of which could lead to high revenue loss. When a problem occurs and network documentation is
readily available, the team in charge of resolving the issue will be able to quickly obtain an understanding of the network and
minimize the time required to fix the problem—resulting in lower costs for you and/or your customer. Good documentation is
not only helpful when a problem occurs, but also aids the internal and external transfer of knowledge.

Another important consideration is that many networks are built by contractors or subcontractors who, in most cases, must
submit test reports for job completion and payment. Therefore, it is mandatory to save the test results of work performed in
the field.

All native files from the FIP, iOLM and CPRI tests can be submitted via EXFO Connect. A report must be sent containing all the
files, in PDF format, generated by the test units. From the unit, generate a report after each FIP, iOLM and CPRI test.

For examples of test reports, refer to the figures below.

Figure 74. FIP test report Figure 75. iOLM test report

Mobile fronthaul: Testing reference guide 45

 Figure 76. CPRI test report

Sometimes, measurements taken in the field will not require extra post‑processing, but in other cases extra processing will be
required to perform proper analysis, establish accurate diagnoses, and ultimately document the network properly (test report
or birth certificate), as per customer requirements or the network owner’s standard. As indicated in the table below, the three
logical steps of data post‑processing generally consist of editing, analyzing and documenting the test results.

1. Edit 2. Analyze 3. Document

Adjust the cable and fiber parameters Perform OTDR or iOLM bidirectional analysis Report customization
(e.g., job information)

Add/remove OTDR/iOLM events Detect duplicated measurements Various report types

Adjust detection thresholds Easily identify the results that fail network Combined reports such as:
requirements – Fiber characterization
– iOLM with connector inspection results

Perform manual measurements on OTDR files

Set pass/fail thresholds

Table 3. Data post-processing actions

46 Mobile fronthaul: Testing reference guide

3 PMD/CD dispersion
Polarization mode dispersion (PMD) and chromatic dispersion (CD) are two effects that can lead to bit errors, which cannot
be overlooked during the commissioning or troubleshooting phase of any network path.

PMD is caused primarily by fiber defects, imperfections and external stresses. These external stresses may be natural
(e.g., earthquakes and storms), or artificial (e.g., digging and vehicle‑induced vibration). As such, PMD can vary quite rapidly
and is not wavelength dependent. When testing for PMD, a safety margin is often required. PMD cannot be compensated for
in the optical domain. Some advanced technologies, such as those used in 100 Gbit/s coherent transmission, partly help to
mask the impact of PMD.

CD is caused by normal light dispersion in a medium such as glass, where some wavelengths travel faster than others.
CD is a given value for a given fiber; as such, it can be easily compensated for once identified.

3.1 Best practices

There are several methods for testing PMD and CD; however, single‑ended solutions are the most cost‑effective in a dark fiber
implementation in short‑haul and metro networks:
– Single‑ended: Based on OTDR‑like technology, these solutions offer the benefit of much faster and simpler characterization
procedures because a single technician can carry out two measurements (PMD and CD) without waiting for a second
technician to move from one site to another. These methods are ideal; they are the recommended test approaches for
CWDM‑based and metro networks, because they are typically less than 150 km and do not contain amplifiers.

The single‑ended approach can have the two testing capabilities (CD and PMD) within the same unit, tested at the same time,
and without the need to reconfigure or to disconnect test equipment. In the process, these units also measure fiber length,
which can serve the following purposes:
– Validate the fiber length found by the iOLM
– Automatic calculation of CD and PMD co‑efficient, which is the amount of dispersion per kilometer, and often an
indication of fiber quality and type

3.2 Doing the test

Performing the test is extremely simple using the FTB‑5700
Single‑Ended Dispersion Analyzer, which integrates both CD and
PMD testing capabilities within the same unit.

Data rate CD tolerance PMD tolerance 1

2.5 Gbit/s 18 468 ps/nm 37.5 ps
10 Gbit/s 1193 ps/nm 9.3 ps

1
Assuming an outage probability of 0.001%.

Mobile fronthaul: Testing reference guide 47

 4 Field test process automation and analytics
Many field issues require testing verification during construction in order to prevent costly deployment delays and future service
outages. However, this involves highly manual and error‑prone management tasks, and is further complicated by the many levels
of contractors/subcontractors involved. Building a solid process is one thing, but ensuring that a varied and ever‑changing set of
contractor companies and technicians are following it correctly is another. In addition, the task of analyzing and interpreting reams
of test results that are full of ID and file naming data entry errors is something else entirely. EXFO’s TestFlow field test process
automation and analytics application is fully capable of addressing the process compliance and analytics requirements essential
to successful fronthaul deployments. Through this combined approach, contractors and their technicians are able to benefit
from higher efficiency and better job quality with minimal training required; service providers are able to gain control of their fiber
deployments, maximize return on investment through on‑schedule project delivery, and proactively prevent future service issues.

TestFlow integrates the fully automated fiber inspection probe, the single‑touch automated iOLM OTDR and the CPRI link
validation test functionality to enable complete validation of new or upgraded fiber-based mobile architectures.

4.1 Key benefits of the TestFlow solution

–– Digitizes and automates field construction and testing to ensure that work performed by the technicians is labeled and
tracked 100% of the time without the need for post‑processing, bookkeeping or unnecessary processing of manually
collected results
–– Standardizes all tasks and tests to provide workforce conformity to quality construction and testing processes
–– Centralizes and analyzes all field test results into a unified set of dashboards for fast, easy verification and tracking
focused on job performance, status, efficiency and quality

ON-SITE FIELD TESTING POST-TESTING ANALYSIS

CONTRACTOR FIELD SERVICE
TECHNICIAN MANAGER PROVIDER
Drive Test Test Results Test Results Package Manual Analyze
Time Setup Testing Admin Handoff Results Handoff Results Answers

Manual
Process

TIME SAVINGS TIME SAVINGS

(job efficiency) (compliance validation)
Upload Test Results

From the frontline and manager or supervisor perspectives, field test process automation and analytics assure compliance with
network standards and maximize technician efficiency. However, for network engineers and designers, and operations and marketing
executives at MSOs, cable companies, MNOs and telcos, it is the foundation for the following progressive, escalating benefits:
–– Reduced network construction time and costs
–– Faster, high-quality, on-schedule network deployments
–– Accelerated time-to-revenue for new services
–– Decreased troubleshooting and sustained service revenue
–– Reduced subscriber churn and enhanced corporate brand

48 Mobile fronthaul: Testing reference guide

4.2 Solution architecture Web-based user interface

5 Compliance analysis and analytics

DESIGN JOB EFFICIENCY TECHNICIAN
QUALITY PROGRESS PROGRESS

Customer operations
support system (OSS)
6
TROUBLE-TICKETING
Open APIs 1
FIELD SERVICE MANAGEMENT Database
WORKFLOW MANAGEMENT

TestFlow jobs 2 4 Test results

3 Data sources
Contractor X Contractor Y Service
provider

FIP-400B wireless
FTB-1 Pro fiber inspection probe

1 Make Sure that Your Entire Workforce Is on the Same Page Moreover, EXFO Link can capture any result in the form of pictures,
files or PDFs; it also interacts with the user to verify results based on
The process starts with the conversion of a static methods and procedure
defined thresholds.
(M&P) document into a digitized and automated task sequence. Once
defined, the TestFlow template is pushed directly to the assigned
technicians from the TestFlow server to their units. TestFlow templates 3 Capture All the Results in a Central Repository
can be shared with different technician groups, contractors and Once the user has verified the results and confirmed job completion using
subcontractors, depending on the job types that need to be performed. the summary report, the test results and all pictures, files and PDFs will be
The information can also be shared via the EXFO Link app to provide uploaded to the central server repository for further analysis and closeout.
step‑by‑step instructions to the contractor.
If a template is updated, it can be pushed out again the next time the 4 Analyze Results and Close Out Without the Hassle
relevant test sets connect back to the server; technicians don’t need to
manage template versions. This ensures a standardized and repeatable Test results are stored in a centralized database and can be analyzed
approach for everyone in the workforce. using the TestFlow software to identify performance, efficiency, status
and quality issues. Each stakeholder can access relevant pieces of
information based on individual user privileges. The information is made
2 Address the Challenge of Controlling and Guiding Work in the Field readily available in the form of preconfigured analytics dashboards with
As the user progresses through the test sequence, each fiber inspection, contextual filtering, drilldown to detailed reports, and even individual
intelligent Optical Link Mapper (iOLM) fiber characterization and CPRI per‑test results for detailed troubleshooting.
link validation test will be properly documented and organized. Whenever These analytics dashboards provide a comprehensive review of all work
internet connectivity is available, it will be possible to upload and performed in the field via a single screen and without the need for any
centralize test results to the TestFlow database directly from the test manual intervention.
set; this prevents any test results with file naming errors, or time wasted
in transferring the information via USB device and e‑mail. To provide
accurate geolocation tagging of test results, technicians must run the
5 Integrate TestFlow server with back-office systems using
open APIs
EXFO Link app on their smartphones, then use its GPS and location
acquisition capability. This will transmit the information to the TestFlow Cross‑functional collaboration is made possible through the use of open
application running on the EXFO FTB‑1 Pro test platform. If needed, the application programming interfaces (APIs) supporting integration into
technician can also upload third‑party test results using the EXFO Link service provider OSS for field service and workflow management as
app (e.g., from RF spectrum analyzers for FTTA and distributed antenna well as trouble‑ticketing. These APIs remove the barriers to workflow
system [DAS] deployments), along with key metadata such as job ID and optimization across multiple processes and drive operational efficiencies
pass/fail indication, directly from a smartphone to the TestFlow server. throughout the organization.

Mobile fronthaul: Testing reference guide 49

 Figure 77. Example of test results tracked within the TestFlow application on the FTB-1 Pro test platform.

4.3 Project tracking and compliance analysis

TestFlow analytics offer a highly flexible way of reporting on data collected in the field and relevant derived metrics. The example
in the image below illustrates specific regional, market and location views of project status and shows how each project is
performing. In addition, it provides all the tests—iOLM in this example—performed in accordance with established practices
and thresholds, thus guaranteeing first‑time‑right deployments.

Figure 78. Example dashboard showing project status and progress

50 Mobile fronthaul: Testing reference guide

5 Network quality monitoring systems (NQMS)
5.1 Key tools for dark fiber providers involved in FTTA
Challenge: Dark fiber providers typically have no access to BBU/RRH equipment; they are responsible for the fiber (including
the infrastructure), but not for the equipment. However, they want to be aware of issues and respond to their customers with
reliable data about the past and present condition of the fiber. The particular challenge is to understand whether the fibers
are affected up to a demarcation point close to or at the RRH equipment optical ports, typically the endface of the fiber links.

Solution: The solution involves installing a fixed, permanent OTDR, optical switching and any passive test access device on
all new installations for remote testing and fiber surveillance. Dark fiber providers can therefore propose link monitoring as
an option to fiber leasing in order to enforce and improve their service level agreements (SLAs), thus increasing the value of
their service offering. It is common practice to take OTDR snapshots of the fiber from day one and understanding when and
how the fiber condition changes up to a demarcation location. The demarking device can be as simple as the end of the fiber
shown clearly on an OTDR trace, or consist of more sophisticated reflective filters that are capable of acting as a demarcation
device and of blocking or attenuating the OTDR signal to ensure that it doesn’t affect RRH transmit/receive functions.

5.2 Equipment—remote test unit (RTU)

Application: remote OTDR testing and monitoring of cloud/centralized/distributed RANs
– OTDR‑based; single‑ended means no need for an end‑of‑line active device.
In some cases, a passive OTDR rejection filter is needed to isolate the receive fiber (Rx)
– Active, in‑service fiber testing, proactive monitoring or reactive troubleshooting
– OTDR models adapted to FTTA and centralized RAN for 100 m to 40 km+ ranges
– Equipment is to be placed in central or temperature‑controlled macrocell sites
– Scalable in ports; single OTDR shared among a large number of test ports is the best value
– Down three seconds per port (round‑robin 16 ports in less than one minute for up to 15 dB attenuation)

Figure 79. Scalable from eight to 96 ports in 2U size rack Figure 80. Configuration with 24 ports based on 12-f MPO and test access module kit
(TAMK) that houses 24 WDMs, all occupying a 3U space

Mobile fronthaul: Testing reference guide 51

 Refer to the figure below to see how it all works together.

Figure 81. Fiber pair cases operated by a dark fiber provider

5.3 Motivations for monitoring fiber in the fronthaul

With value‑added services running on fixed and mobile networks, as well as 5G looming on the horizon, dark fiber providers
are under increasing pressure to ensure that access networks are stable and reliable. In addition, it will be important to have
the right tools in place to provide essential data needed to validate the quality of the fiber at all times.

Top line: Bottom line:

– Offer higher‑value dark fiber services – Reduce the cost of maintenance and troubleshooting
– Mobile operators to improve the quality of service (QoS) in any access‑type network
of 4G LTE – Achieve faster times in understanding, isolating and
– Fiber providers to gather and present historical data to locating fiber‑related issues
their prospective carriers – Centralize operations at the network operations center
– Improve customer service (being aware of issues – Spend less time and money on managing tenants
before answering the call) – Avoid penalties
– Improve customer loyalty – Faster mean time to repair
– Maintain quality over time (e.g., change management
and repair verification)

52 Mobile fronthaul: Testing reference guide

6 Appendix A—list of acronyms
API application programming interface MPLS multiprotocol label switching
BBU baseband unit MPO multifiber push‑on
BER bit error rate OBSAI Open Base Station Architecture Initiative
BERT bit error rate test/testing OCNS orthogonal channel noise simulation
BTS* base transceiver station OTN optical transport network
C&M control and management ORL optical return loss
CD chromatic dispersion PCI physical cell identification
CDN content delivery network PIM passive interference modulation
CO central office PMD polarization mode dispersion
CoMP coordinated multipoint PRBS pseudo‑random bit sequence
CPRI Common Public Radio Interface RAI remote alarm indication
C‑RAN centralized radio access network RAT radio access technology
CSR cell‑site router RF radio frequency
CWDM coarse wavelength‑division multiplexing RL return loss
DAS distributed antenna system RRH remote radio head
DC direct current RSSI received signal strength indication
D‑RAN distributed radio access network RTD round‑trip delay
DU digital unit RTU remote test unit
DWDM dense wavelength‑division multiplexing Rx remote receive fiber
FTTA fiber‑to‑the‑antenna SFP small form‑factor pluggable
HDLC high‑level data link control SLA service‑level agreement
IEC International Electrotechnical Commission SM singlemode
IL insertion loss Tx transmitter
iOLM intelligent Optical Link Mapper QoS quality of service
LOS loss of signal UPC ultra‑polished connector
M&P methods and procedure VoD video on demand
MEC mobile edge computing VSWR voltage standing wave ratio
MNO mobile network operator WDM wavelength‑division multiplexing

*Or NodeB/eNodeB

Mobile fronthaul: Testing reference guide 53

54 Mobile fronthaul: Testing reference guide
Mobile fronthaul: Testing reference guide 55
 Sales and customer service
EXFO Headquarters
400 Godin Avenue
Quebec City, Quebec G1M 2K2 CANADA
T: +1 800 663-3936 (U.S. and Canada)

EXFO America Inc.

3400 Waterview Parkway, Suite 100
Richardson, TX 75080 USA
T: +1 800 663-3936 (U.S. and Canada)

EXFO Europe Ltd.

Winchester House
School Lane, Chandlers Ford, SO53 4DG UK
T: +800 22 55 39 36 (+800 CALL EXFO; from most European countries)
Sales: +44 2380 246 810

EXFO Asia Pacific PTE Ltd.

62 Ubi Road 1, #09-01/02
Oxley Biz Hub 2, SINGAPORE 408 734
T: +65 6333 8241
SAP1069622
17/09
20170339V5
© 2017 EXFO Inc. All rights reserved.