5G Fronthaul Handbook

Application Note

5G Fronthaul Handbook

https://www.viavisolutions.com/en-us

3 5G Fronthaul Handbook2 5G Fronthaul Handbook

A guide to understanding the impact of 5G on transport networks and key test considerations for ensuring reliable performance and high quality of service

Fronthaul Evolution: The Beginning

5G technology is touted as an innovation platform that will enhance our connected world. To deliver on this promise, 5G will demand the network supporting it to be as flexible as the services running on it. The following high-level 5G uses cases are well understood and documented by the wireless industry:

y Enhanced Mobile Broadband (eMBB) providing greater data-bandwidth services with peak data rates of 10 Gbps and beyond. This data rate will enable new use cases such as augmented reality/virtual reality or ultra-high density (UltraHD) applications.

y Ultra-Reliable Low Latency Communications (URLLC) providing ultra-reliable capabilities with availabilities in the range of 99.9999%, and extremely low latency features in millisecond range. Vehicle-to-vehicle communication over 5G networks is one prominent use case for this category.

y Massive Machine Type Communication (mMTC) supporting extremely large numbers of devices in the range of hundreds of thousands per square kilometer. Essential for this application class are battery lives up to ten years.

Medium

Low

eMBB

mMTC

URLLC

High Importance

Ultra-ReliableLow Latency

Communications

EnhancedMobileBroadband

Massive MachineType Communications

Peak Data Rate

Connection density Latency

Network Energy Efficiency

Area TrafficCapacity

SpectrumEfficiency

Mobility

User ExperiencedData Rate

Figure 1. Importance of key capabilities in different usage scenarios (from ITU IMT Vision)

Table of Contents

Table of ContentsFronthaul Evolution: The Beginning ..................................................................................3

Network Evolution: The Key Drivers .................................................................................4

Centralized vs. Distributed BBU functions .....................................................................5

eCPRI ...............................................................................................................................................10

Testing the Transport Network for 5G .............................................................................13

y Fronthaul and Midhaul Network Test .......................................................................13

y Synchronization Test ........................................................................................................13

y FTN Test .................................................................................................................................15

y 5G Fronthaul RU Connectivity and Delay Test .....................................................16

y GPS Test (GPS signal/satellite coverage test) ........................................................18

y PTP Test (PTP timing error test) ..................................................................................18

y Ethernet Test .......................................................................................................................19

y Virtual Network Performance Test .............................................................................20

Conclusion ....................................................................................................................................21

4 5G Fronthaul Handbook 5 5G Fronthaul Handbook

The big challenge is how to support these use cases on the same network. Much of the trade buzz to date has been centered on 5G-NR (new radio), virtualized core, and mm-Wave spectrum. Receiving far less attention, but equally important as the new radio interface, is the evolution of the transport network connecting 5G nodes that enable the key 5G use cases –simultaneously. In the 2019 Heavy Reading survey Operator Strategies for 5G Transport, Heavy Reading reported, “the industry has recognized that this transport infrastructure must be put in place before 5G applications can be rolled out in volume”.

Network Evolution: The Key Drivers

We have come a long way from the days of T1 and E1 circuits. Before 4G, wireless industry backhaul transport requirements were relatively simple and were defined by cell site capacity requirements (number of voice users, low throughput applications) and certain performance metrics (latency, jitter, availability). T1/E1 circuits met the need at the time yet, beginning with 4G, the bar was raised. Large data throughput (100’s Mbps) demand, introduction of multiple input, multiple output (MIMO) technology, better coverage, energy efficiency, and radio coordination technologies imposed new and stringent requirements on the radio access network (RAN) infrastructure.

In addition, as radios became more robust and mean-time-to-replace (MTTR) improved, vendors began offering remote radio solutions. Radios were moved close to the antenna to avoid the significant losses caused by long coaxial cables and connectors. This strategy not only helped with improved RF footprint, it also reduced the cooling cost at the radio equipment enclosure located at or near the base of the tower. However, to support remote radio units and remote radio heads (RRU/RRH), new digital interfaces were introduced. These connected the digital equipment also, called baseband units, (BBU) to the RRUs through a physical fiber link. Today the most widely used technology is based on the common public radio interface (CPRI) protocol. This introduced a new link in the RAN infrastructure called fronthaul, in contrast to the backhaul that connects the BBUs with the core mobile network.

Fronthaul(Antenna to Central Office) Backhaul

BBU

BBU

Data CenterInternet/Core NetworkCentral Office

Distributed Unit

Remote Radio Head

(RRH)

Figure 2. Evolution of RAN

Centralized vs. Distributed BBU functions

Centralization enables resource pooling which optimizes resource utilization. Furthermore, the architecture provides some key functions for advanced LTE technology. The ability to coordinate multiple radios from one location is a key enabler for implementing features such as coordinated multipoint (CoMP), which helps increase user bandwidth by aggregating traffic sourced from multiple cells at the user terminal. All these advantages come with a massive disadvantage for emerging 5G services: inefficient bandwidth. CPRI’s stringent delay requirement is well-suited for centralization. However, it creates challenges in terms of bandwidth and node flexibility. CPRI provides a dedicated transport protocol specifically designed to transport radio waveforms between the RRU and BBU. CPRI frames expand with increased radio channel bandwidth and the number of antenna elements. CPRI is not very efficient in statistical multiplexing and cannot scale to the demands of 5G, especially for massive MIMO and larger bandwidth increments. The required bandwidth and antennas in a 5G scenario would push the CPRI bandwidth requirements above 100 Gbps (Table 1).

Antenna 10 MHz 20 MHz 100 MHz1 0.49 Gbps 0.98 Gbps 4.9 Gbps2 0.98 Gbps 1.96 Gbps 9.8 Gbps4 1.96 Gbps 3.92 Gbps 19.6 Gbps64 31.36 Gbps 62.72 Gbps 313.6 Gbps

These bandwidth allocations would be extremely expensive for larger 5G network rollouts. Standard bodies including 3GPP, IEEE, ITU-T and others have been working to:

1. Study different split options (as shown in figure 3) of the BBU functions and its implications

2. Identify optimal requirements for different applications and services (throughput, latency, jitter, etc.)

3. Identify potential challenges and solutions for dividing the different BBU functions to meet the application and network demands

4. Provide guidance for flexible fronthaul splits

To develop an alternative solution necessitates an analysis of the key functional elements between a BBU and an RRU. As per 3GPP BBU can be divided into eight main functional splits as shown in figure 3. In the case of 4G, RRUs retain the RF functions, while the other main functions are placed in the BBU. This functional distribution allows operators to centralize most of the functions at one location and have a basic lower cost radio at each end point (option 8).

Table 1. CPRI Bandwidth as a function of bandwidth and antenna ports

Table of Contents Table of Contents


BBU RRU

Option4

Option5

Option6

Option7

Option8

CPRI

Option2

Option3

Option1

HighMAC

LowMAC

HighPHY

LowPHY

LowPHY

RF

RRC PDCP HighRLC

LowRLC

HighRLC

LowRLC

HighMAC

LowMAC

HighPHYRRC PDCP

DO

WN

LIN

KU

PLIN

K

Network Layer

Data LinkLayer

PhysicalLayer

Figure 3. Functional split options

Beyond the key disadvantage of bandwidth inefficiency, CPRI also has a very limited delay budget. In practice, this means that the distance between BBUs and RRUs will be very limited. The distance is determined by the delay budget and the type of transport technology deployed in the fronthaul. Dark fiber is the simplest one allowing for maximum distance. Transport equipment that contains some processing elements reduces the delay budget, sometimes substantially, as with Optical Transport Networking (OTN). As it is often the case, operators must look at the individual use case and conduct a trade-off analysis to determine the best transport technology. Key inputs in the analysis include the availability of fiber and equipment rooms, as well as the number and locations of radio end-points. Following are the high-level requirements for the fronthaul that vendors and service providers are driving:

a. Reduce bit rate (capacity usage) on the front haul, especially separating fronthaul usage from antenna port capacity as in the case of CPRI.

b. Manage stringent latency requirements for uRLLC type application.

c. Optimize timing and jitter requirements for coordination features such as CoMP and carrier aggregation.

d. Reduce overhead cost and deployment cost because fiber is an expensive resource to deploy.

To deliver on these requirements, next-generation RAN has evolved such that the functions performed by the BBU are split into three parts:

1. Central Unit (CU)

2. Distributed Unit (DU)

3. Remote Radio Unit (RRU).

However, 3GPP considers a split base station architecture consisting of CU and DU only. The new BBU architecture not only helps with the above-mentioned challenges, it also takes advantage of RAN virtualization allowing certain BBU functions to be located at the different physical locations, depending on the application type and the service provider network topology.

The two new interfaces created between the Core and the CU and the CU and DU generally are referred to as the high layer split point (NGFI-II) and the low layer split point (NGFI-I) respectively. From an application standpoint, for fixed wireless type applications a higher layer split (HLS) option is recommended (Figure 4). This option places the real-time functions inside the radio unit and can also be considered as a distributed unit (DU)/radio unit (RU) functional element. This placement significantly reduces the bandwidth at the HLS interface. 3GPP recommends option 2 for HLS. This interface is also known as the F1 interface (equivalent to NGFI-II). Beyond significant reduction of the bandwidth, the delay budget is in the range of several milliseconds, much higher than CPRI (fronthaul) interfaces. This budget allows the CU to be located tens of miles away from the DU/RU element. This segment of the network is called midhaul as it sits between the fronthaul and the backhaul.

Option4

Option5

Option6

Option7

Option8

Option2

Option3

Option1

HighMAC

LowMAC

HighPHY

LowPHY

LowPHY

RF

RRC PDCP HighRLC

LowRLC

HighRLC

LowRLC

HighMAC

LowMAC

HighPHYRRC PDCP

DO

WN

LIN

KU

PLIN

K

CU DU/RU

F1

Figure 4. Higher layer split (HLS) option



Scheduling of available resources takes place in the MAC (Media Access Control) layer. The MAC scheduler must execute a certain set of actions every Transmission Time Interval (TTI) which requires very low latency and execution jitter. The MAC instructs the radio link control (RLC) about the size of packets it will receive thereby assuring a specific quality of service (QoS) for each radio bearer. Per an NGMN study, moving the MAC layer to the CU can potentially limit the performance of coordination functions. The Hybrid ARQ (HARQ) process and other timing critical functions are part of lower MAC, therefore the split options from 1 to 5 as shown in the above figure have relaxed latency requirements on the fronthaul link, where splits 6 to 8 have very strict fronthaul latency requirements.

Massive mobile broadband services that are expected to take advantage of advanced mobility applications that require coordination of multiple radios will require a lower layer functional split option that leaves most of the functional elements (Figure 5) in a centralized location coordinating the radios. Options 6 and 7 of the standards are currently being considered for this use. Remember this functional split creating a front haul interface equivalent to NGFI-I will reduce the downlink and uplink fronthaul bitrates but will have significantly stringent latency requirements. This means the distance between the DU and RU will be limited. For this same use case, the CPRI organization published the first eCPRI specification in 2017.

CU/DU RU

Option4

Option5

Option6

Option7

Option8

eCPRI

Option2

Option3

Option1

HighMAC

LowMAC

HighPHY

LowPHY

LowPHY

RF

RRC PDCP HighRLC

LowRLC

HighRLC

LowRLC

HighMAC

LowMAC

HighPHYRRC PDCP

DO

WN

LIN

KU

PLIN

K

Figure 5. Lower layer split option

As reported in the Next Generation 5G Wireless Networks: A Comprehensive Survey, IEEE Communications Survey Tutorials, (vol. 18, no. 3, pp. 1617–1655, 2016) fronthaul bitrates for uplink (UL) and downlink (DL) for each functional split for a 20 MHz LTE carrier using two DL antennas and 64 Quadrature Amplitude Modulation (QAM), results are shown in figure 6. The figure shows a full load of the entire carrier, which will always be in use for split option 8 and 7-1, but for splits 1 to 7-2 this is just the highest possible peak on the fronthaul link, as the bitrate will vary with the user load.

80

20

40

60

80

100

120

140

160

180

7.1 7.2 7.3 6 5 4 3 2 1

Functional Split Options

DL UL

Figure 6. Fronthaul bitrates, as per 3GPP UL/DL for each functional split

eCPRI

eCPRI technology is based on a functional split in the LTE Physical Layer (PHY) component. The eCPRI specification recommends that split option IU be used for uplink, and either IID or ID be deployed for downlink, which maps to the 7.x split with respect to 3GPP as shown in figure 7. eCPRI connects the eCPRI Radio Equipment Control (eREC) and the eCPRI Radio Equipment (eRE) via fronthaul transport network. The goal of eCPRI compared to CPRI, is to decrease the data rate demands between the eREC and the eRE via a functional decomposition while limiting the complexity of the eRE. In addition, eCPRI is designed to enable efficient and flexible radio data transmission over a packet based fronthaul transport network like IP or Ethernet.



Coding

Ratematching

Scrambling

Modulation

Layermapping

Pre-coding

RE mapping

IFFT/CPaddition

D/A

Analog BF

De-coding

Ratede-matching

De-scrambling

De-modulation

Channelestimation/Equalization

& IDFT

REde-mapping

Digital BF Digital BF

FFT/CPremoval

A/D

Analog BF

Option6

Option7-3 (DL)

Option7-2

Option7-2a

Option7-1

Option8

MAC

ID (eCPRI)

IID (eCPRI) IU (eCPRI)

E (CPRI) E (CPRI)

MAC

PHY PHY

RF RF

Figure 7. Functional split in PHY

For eCPRI, three planes are necessary for interaction between the eREC and the eRE: 1) user plane, 2) sync plane, and 3) control and management (C&M) plane. The eCPRI standard defines the user plane and refers to other standards for the definition of the other planes. For example, an operator is free to choose precision timing protocol (PTP) or global positioning system (GPS) for synchronization.

eCPRI also mentions packet-based technologies for the transport of the user plane. Both Ethernet (layer 2) and Ethernet/IP/UDP (layer 2/3/4) are possible. For the physical layer, eCPRI refers to Ethernet rates 10 Gbps to 100 Gbps. The point of this discussion is not to rehash eCPRI, but to identify the difference between CPRI and eCPRI. And further, where CPRI becomes a limited interface, eCPRI opens it up for 5G by reducing the throughput on the fronthaul and it uses a frame format that supports an Ethernet or Ethernet/IP/UDP frame transmission. The frame includes an eCPRI header that follows layer 2 or layer 2/3/4 header and is followed by the eCPRI payload.

Synchronization plane is carried independently over any ethernet layer and is not restricted to specific protocol. Global positioning system (GPS), precision time protocol (PTP), synchronous Ethernet, or something similar can be used for timing and synchronization.

Using Ethernet for transport is very practical because it is backwards compatible, allowing for commodity equipment, enabling greater convergence of access networks, and enabling statistical multiplexing which will help lower the aggregate bit-rate requirements. Use of standard IP/Ethernet network switching/routing will also make functional virtualization and overall network orchestration relatively easy.

The above options rely on a single-split configuration. There are also good reasons to have a double-split-option (Figure 8). For example, URLLC applications require extremely fast network responses. Vehicle to network (V2N) applications need response times in the range of a few milliseconds from vehicle to vehicle. That does not leave much budget for the cellular network if the two vehicles communicate over two RUs. This use case is a good example of cases that would benefit from a double-split design that separates the DU and CU. While the time critical functions in DU can be placed closely to the RU, and thereby help meet the low latency requirement, the non-time-critical functions can be placed farther away in a central location.

Option4

Option5

Option6

Option7

Option8

Option2

Option3

Option1

HighMAC

LowMAC

HighPHY

LowPHY

LowPHY

RF

RRC PDCP HighRLC

LowRLC

HighRLC

LowRLC

HighMAC

LowMAC

HighPHYRRC PDCP

DO

WN

LIN

KU

PLIN

K

CU RUDU

F1 eCPRI

Figure 8. Double split option

To summarize, splitting the BBU function is essential for 5G services because CPRI is not scalable for eMBB and massive MIMO, and it does not offer the flexibility required for MMTC and uRLLC applications. Moving some of the BBU functions to reduce the fronthaul bitrate (CPRI bit rate is proportional to the number of antenna to user throughput) can impact the latency requirements for coordination features and real-time applications including uRLLC. By using NFV (network function virtualization) and flexible split options for different application types, a more optimal midhaul and fronthaul (also known as x-haul) can be implemented. This new x-haul architecture allows for scalable, packet-based transport technologies but the downside is operators now have to address timing and synchronization issues. However, those can be addressed using standards-based timing and synchronization technologies such as GPS, PTP, synchronous Ethernet, or something similar. The bottom line is that 5G front haul and midhaul networks will vary based on the applications offered, network topology, medium availability (fiber, microwave, etc.), and service provider business case. There is no one size fits all.



EPC/NGC

FHFH

DU

MH

DU

DU

DU

gNB

BH

BH

BH Aggregation Network

DU

FH

FH

FH

CU/DU CU/DU

CU

MidhaulBackhaul

C-RAN

4G RAN

5G RAN

5G RAN

Regional MTSO/MEC

Fronthaul DU-RU

• CPRI/eCPRI/ORAN• Range <20kM• Latency micro seconds

Midhaul CU-DU

• F1 Interface• Range <80kM• Latency low milliseconds

Backhaul CU-Packet Core

• S1 Interface• Range <200kM• Latency tens of milliseconds• N1, N2, and N3 for 5G

Figure 9. X-haul evolution

Testing the Transport Network for 5G

Fronthaul and Midhaul Network Test

Whether service providers are deploying a new technology or launching a greenfield network, all components, connections, and the overall network integration needs to be tested. After ensuring all physical layer tests are completed (fiber inspection and certification), it is important to run higher layer tests along with timing and sync to ensure the best return on investment. Failure to test can cause network launch delays, poor 5G system performance, and excessive, unplanned capital expenditure. Ultimately, neglecting to test can negatively affect the customer experience, cause end-user churn, and hurt the topline.

Service level agreements (SLAs) for midhaul networks will be very similar to backhaul, which means testing requirements will be similar:

A. Bandwidth measurement/committed information rate

B. Delay and jitter

C. Packet or Frame Loss

D. RFC 2544 and Y.1564 Test

SLAs for fronthaul networks will grow more stringent as higher capacity and ultra-low latency and reliability services are deployed. We will see the network evolve from dark fiber to a wider WDM expansion which means WDM testing will be needed. Some service providers are in the process of deploying NG-PON already as a future investment. We anticipate more frequent use of Time Sensitive Networking (TSN) for real-time communication with hard, non-negotiable time boundaries for end-to-end transmission latencies, where devices in the network need to have a common time reference and therefore, need to synchronize their clocks. This means in addition to the tests listed above, timing and synchronization tests will also be required.

Synchronization Test

As discussed earlier, timing and synchronization play a vital role in the performance of a wireless network. In 5G networks, those requirements are magnified due to phase and timing demands brought by time division duplex (TDD) and coordinated radio techniques. Previous mobile networks primarily required frequency synchronization to align signals. Unfortunately, frequency sync alone will not be enough with 5G.

Synchronization requirements are derived from several bodies, including the 3rd Generation Partnership Project (3GPP). 3GPP technical specifications 36.104/38.104 represent two key documents that describe base station radio transmission and reception requirements. More specifically, section 6.5 (Transmit signal quality) lists several requirements that are essential for synchronization network design including time alignment error (TAE). TAE is defined as the largest timing difference between any two signals belonging to different antennas or transmitter groups. The requirements are categorized depending on the wireless use case (Table 2). These use cases are assigned unique categories from A+ to A, B, and C. The use cases at the bottom of the table are being developed at this time and have not been assigned a category.

3GPP Feature RANLTE NR

MIMO or TX-diversity transmission Category A+ Category A+Intra-band contiguous carrier aggregation Category A BS Type 1: Category B

BS Type 2: Category AIntra-band non-contiguous carrier aggregation Category B Category CInter-band carrier aggregation Category B Category CTDD Category C Category CDual Connectivity Category C Category CCOMP Not specified in 3GPP Not ready in 3GPPSupplementary Uplink Not applicable for LTE Not ready in 3GPPIn-band Spectrum Sharing Not ready in 3GPP Not ready in 3GPPPositioning Not specified in 3GPP Not ready in 3GPPMBSFN Not specified in 3GPP Not ready in 3GPP

Table 2. Timing Accuracy categories (eCPRI Transport Requirements)



Category A+ demands the most stringent synchronization requirements (Table 3) while category C’s requirement is in line with current LTE backhaul networks. The requirements are identified in terms of relative and absolute Time Error (TE). The relative TE specifies the time error between any two RU (or eRE). Absolute TE is the time error against a reference Primary Reference Time Clock (PRTC). In most cases the absolute TE requirements are in addition to the one for respective relative TE requirements (categories A+, A, and B).

Category Time ErrorA+ (relative) 20-32 nsA (relative) 60-70 nsB (relative) 100-200 nsC (absolute) 1100 ns

Figure 10. shows synchronization network components and test applications with T-BERD/MTS-5800 used for validating connectivity to PRTC/T-GM (Primary reference and grand master clock) and measuring time error within the network.

Table 3: Time error requirements

FTN FTN

Fronthaul

10/25GE 10/25GET-BC

T-GM

T-BC

O-DU

T-GM

O-DU

FTNT-BC

T-TSC

O-RU

T-TSC

O-RU

5800/TEM

PRTC

PRTC

5GRU

5GRU

5GCU + DU

4GRRU 4G

RRUFTN

RoE

Fronthaul Bridged Network

CPRI

eCPRI

eCPRIFTN

FTNRoE

FTN eCPRI

CPRI

Figure 10. Synchronization test applications using T-BERD/MTS 5800

Figure 11. FTN Network architecture

FTN Test

A fronthaul transport network node (FTN) is introduced to manage the ethernet access ring that can deliver a converged fronthaul supporting legacy CPRI and 5G eCPRI as shown in Figure 11.

This resolves some topology challenges, but it is important to make sure that FTN networks do not create excessive delays and meet the delay and synchronization budgets for the access network. The following table highlights key eCPRI transport requirements.

Cos Name Example Use One-way Maximum Packet delay

One-Way Packet Loss Ratio

High User Plane 100 µs 10-7

Medium User Plane (slow), C&M Plane (fast)

1 ms 10-7

Low C&M Plane 100 ms 10-6

Today multiple NEMs in the lab are using VIAVI T-BERD/MTS-5800-100G to validate FTN performance. T-BERD/MTS-5800-100G can perform eCPRI tests and measure throughput, delay, and packet jitter. By using a T-BERD/MTS-5800 engineers can configure eCPRI message types according to eCPRI specification, measure bandwidth for each message type, and measure round trip delay (RTD) with sub 5 ns accuracy. By performing FTN tests, engineers can validate the delay and synchronization requirements for the FTN and can ensure it is within the designed network specifications. In the future this test can also be used in the field to validate the fronthaul network performance.

Table 4: Split E and splits ID, IID, IU requirements


https://www.viavisolutions.com/en-us/products/t-berd-mts-5800-handheld-network-tester


Backhaul

Backhaul F1

Midhaul

Fronthaul

WDMFiber

eCPRI

CU/vCU

DU/vDU

RUFTN FTN

Figure 12. 5G fronthaul transport test use case

The VIAVI T-BERD/MTS can perform the following tests for 5G fronthaul networks:

Backhaul

Backhaul F1

Midhaul

Fronthaul

WDMFiber

eCPRI

CU/vCU

DU/vDU

RUFTN FTN

Figure 13. 5G fronthaul RU connectivity and delay test

y Generate and analyze eCPRI signals (10/25GE)

y Verify proper QoS for eCPRI message types (Measure bandwidth/delay/jitter for each message type)

y Generate/filter eCPRI subheaders

y One Way Delay Measurement

y RTD measurement < 5 ns accuracy

y C&M, SNMP/UDP/TCP test

y Test PTP/SyncE/GPS for synchronization

y Emulate PTP Slave/master

y Measure Time Error, Wander, PDV, MTIE/TDEV

y GPS Signal Strengths, Trails

y Test Ethernet OAM (Loopback, LoC, Trace)

5G Fronthaul RU Connectivity and Delay Test

y Verify connectivity to an RU

y Measure One Way Delay against an RU

y Verify PTP connectivity, and measure PTP Time Error

y Same tests can be done against a DU

GPS Test (GPS signal/satellite coverage test)

It is important to check GPS signal stability and suitability for the GPS antenna location at the time of installation, and periodically after installation as conditions around the site may have changed. VIAVI T-BERD/MTS-5800 tests GPS signals using an integrated GPS receiver and provides the following results:

y Number of visible satellites

y Signal strengths

y CNO map spectrogram plots line of sight to satellites as they move around the orbit over time

T-BERD/MTS-5800

RRH

RIU

Figure 14. GPS Test using VIAVI T-BERD/MTS-5800



T-BERD/MTS-5800

PTP/SyncE

RRH DU CU

Figure 15. PTP Check using VIAVI T-BERD/MTS-5800

PTP Test (PTP timing error test)

As discussed earlier, reliable wireless service depends upon reliable synchronization. For PTP, the PTP slave (RIU) must be able to connect to its assigned PTP grand-master and comply to PTP frequency profile network limits such as floor packet percentile. Additionally, PTP time/phase profile, must conform to the time error network limits. Using a VIAVI T-BERD/MTS-5800, which works as a PTP slave, an engineer can check connectivity to the PTP grand-master and check whether timing error is within requirements by using a step-by-step guide.

Ethernet Test

As discussed, earlier midhaul, i.e. the link between the distributed unit and the centralized unit, have similar SLAs as compared to backhaul. Therefore, requirements for validating the performance of the midhaul will be very similar to validating the performance of the backhaul network. Verifying the correct configuration and high-quality transport of data-plane and control-plane is extremely important. By implementing RFC 2544 and Y.1564 test methodologies to validate end-to-end configuration at either the Ethernet or IP level can ensure the key performance objectives such as committed burst size (CBS), committed information rate (CIR), latency, packet jitter, and frame loss are met.

Tests can be performed using solutions supporting RFC 2544 and Y.1564 test methodologies. Testing can be done in a single-ended or dual-ended test topology. The latter requires two test units but can ensure proper characterization of network in both directions and can detect potential asymmetries between the two directions. One-way delay measurement can identify asymmetries caused by network equipment, components or fiber lengths. With the help of VIAVI T-BERD/MTS-5800-100G service providers can perform the following tests:

y Throughput/one-way and loopback latency/frame loss/jitter

y RFC2544 testing

y RY.1564 testing

Figure 16. T-BERD/MTS-5800 used for RFC2544 Testing

Virtual Network Performance Test

With network function virtualization (NFV), the network is moving away from a hardware-centric, proprietary network infrastructure toward an open, standards-based, software model that is revolutionizing the way networks will be designed, implemented and operated. In the 5G realm, we expect to see a larger deployment and integration of commercial off-the-shelf (COTS) servers and orchestration of virtual functions, this type of network will also demand test and measurement solutions which are more software based rather than physical proprietary hardware products, especially for higher layer testing. Using a VIAVI NITRO vNet Fusion solution, service providers can combine software-based test agents with standards-based (RFC7594) data collection methodologies to quickly and efficiently test wireless backhaul and midhaul.


https://www.viavisolutions.com/en-us/products/fusion

© 2021 VIAVI Solutions Inc.Product specifications and descriptions in this document are subject to change without notice. 5gfronthaul-an-xpf-nse-ae30190975 901 0221

Contact Us +1 844 GO VIAVI (+1 844 468 4284)

To reach the VIAVI office nearest you, visit viavisolutions.com/contact

viavisolutions.com

Real Time Data Collector

External Data Analytics External Controller (e.g. SDN)

• Test / PM Results• KPIs

Test and PM Controller• Test / PM setup and control

Netconf/YANGStreaming DB I/F

Netconf/YANGData Exchange API

LMAP

RFC

759

4co

mpl

iant

arc

hite

ctur

e

Configuration and Setupof Test and PM

L2/L3 Y.1564L3 TWAMP Light PML3 TWAMP PM

Control I/F

Data Reporting

vAgent vAgent

vCPEServer

UnmanagedTWAMP

reflector

VIAVI TestervCPE

Figure 17. Fusion Test Architecture

When a new backhaul/midhaul service is introduced, engineers can quickly add virtual probes run layer 2-4 tests and measure network performance and throughput and evaluates overall network quality.

Conclusion

As service providers continue the quest to offer new 5G services that require different levels of quality, they are bound to evolve from a CPRI-based fronthaul approach to a more packet based-split architecture. This architecture can meet their needs because it offers greater flexibility, but it also requires a different testing approach. Validating latency, timing and sync and network availability at a scale calls for test solutions that are efficient and simple. With the fully-integrated VIAVI portfolio of cloud-enabled instruments and systems, software automation, and services for network testing, performance optimization, and service assurance, operators and their partners gain confidence for smooth network and service roll-outs, sustainable network quality, and an excellent customer experience.

http://www.viavisolutions.com/contacts

http://viavisolutions.com



5G Fronthaul Handbook

Documents

Transcript of 5G Fronthaul Handbook