Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
CHANNELS     HFR    |  Mobile Fronthaul Solution  |  Carrier Ethernet Solution  | Resources        
CHANNELS     ZARAM    |  XGSPON 10G SFP+ ONT  |  Use cases  | Evolution of FTTH Access Network    

 

Why should jitter be minimized in CPRI fronthaul? - frequency accuracy
July 04, 2014 | By Steve Shin (tech@netmanias.com) and S.M. Shin (smshin@hfrnet.com)
Online viewer:
Comments (1)
10

In this post, we will talk about “jitter” introduced in the fronthaul network of LTE C-RAN.
 

As shown in the figure on the right, jitter refers to the skew or variation in time or phase of a digital signal exchanged between communication systems. This jitter can eventually cause errors during the data and clock recovery process at RRH.
 
Then, why should we be worried about jitter in LTE C-RAN?
 
In LTE C-RAN (Centralized/Cloud RAN), BBU and RRH are placed tens of kms away from each other, and connected through a fronthaul network that carries CPRI traffic.
 
A remotely separated RRH should be synchronized with a BBU in the clock frequency. In most cases, a BBU can generate a master reference clock using its GPS receiver while a RRH, with no built-in or external GPS receiver, can't (Just for your reference, a RRH unit is usually about a few thousand dollars, and a GPS unit is about a few hundred dollars. So, a RRH with an extra GPS would result in extra costs).
 
Thus, in LTE C-RAN, a RRH must obtain a reference clock by recovering a timing clock from CPRI I/Q bit streams transmitted by BBU. Then it creates and distributes all sub-system clocks to be used in the RRH system.
 

 

In a fronthaul network composed of Dark fiber only, jitter rarely occurs between BBU and RRH, because this type of optic fiber seldom causes any jitter.
 
On the contrary, in a fronthaul network containing active equipment like “Active WDM” or “PON”, jitter can be generated and introduced into the fronthaul network during signal processing such as mapping/muxing (i.e., mapping/demaping/multiplexing in OTN). CPRI I/Q bit streams with such jitter can cause errors in the clock and data recovery process at RRH, consequently leading to degraded system performance of RRH.
 
Degraded frequency accuracy of the reference clock recovered in RRH can affect the performance of all relevant components that use the reference clock, subsequently.
 
For example, an inaccurate reference clock may cause errors in converting LTE digital signals (I/Q sample data) into LTE analog signals at DAC (Digital Analog Converter), and also lead to inaccurate frequency of carrier signals used for radio transmission of LTE analog signals. Eventually, jitter in the fronthaul network can cause significant impacts on the quality of LTE radio signals transmitted through RRH antennas.

Because of this risk, when building a fronthaul network for C-RAN, thorough verification is required to ensure jitter introduced by active equipment is kept within the tolerance range.
 
Low deviation between BBU and RRH clocks: How low is low enough? This can be a tricky question.
 
As seen above, jitter introduced in a fronthaul network can degrade the accuracy of a recovered clock, which then accordingly causes degradation of LTE signal quality at RRH. So, strict accuracy requirements for RRH clocks are needed for performance management.
 
For this, the CPRI standard specifies the maximum allowed impact of a fronthaul jitter on the frequency accuracy of the clock recovered at RRH (in comparison with a master reference clock of BBU). 

 

 

The above graph depicts a frequency variation (fo+Δf) of a reference clock recovered at RRH, fluctuating around the original frequency of the master reference clock (fo). It shows there is a deviation in the clock frequency between BBU and RRH due to the clock frequency variation at RRH.
 
R-18, one of the CPRI technical requirements (CPRI Specification_v_6/2013-08-30), defines the clock frequency accuracy of RRH as '±0.002ppm'.
 
This requirement states that the maximum impact of jitter from the CPRI fronthaul on the frequency accuracy of RRH should be less than '±0.002ppm', '±2ppb' or ‘two billionth of the reference clock frequency (Hz)’.
  
Other than jitter, there are many factors that may affect the clock frequency accuracy. The R-18 requirement concerns only jitter, among all other factors, and defines the contribution of jitter to the total frequency accuracy budget allowed at an LTE radio base station.

Note: ‘ppm’/’ppb’(parts per million/billion) unit is used to express a very small parameter/value using “one millionth or one billionth” like 'percentage'. For example, assuming that the reference clock frequency of BBU is 30.72MHz, 2ppb of clock frequency accuracy represents 0.06144Hz.
 

 

hadrien 2018-01-29 20:47:49

Hello,

 

very interesting article!  Do you expect the same kinds of issues with eCPRI?

 

Best regards,

Hadrien

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (819)
4.5G (1) 5G (88) AI (6) AR (1) ARP (3) AT&T (1) Akamai (1) Authentication (5) Big Data (2) Blockchain (3) C-RAN/Fronthaul (17) CDN (4) CPRI (4) Carrier Ethernet (3) China (1) China Mobile (2) Cisco (1) Cloud (5) CoMP (6) Connected Car (4) DHCP (5) Edge Computing (1) Ericsson (2) FTTH (6) GSLB (1) GiGAtopia (2) Gigabit Internet (19) Google (7) Google Global Cache (3) HLS (5) HSDPA (2) HTTP Adaptive Streaming (5) Handover (1) Huawei (1) IEEE 802.1 (1) IP Routing (7) IPTV (21) IoST (3) IoT (55) KT (42) Korea (19) Korea ICT Market (1) Korea ICT Service (13) Korea ICT Vendor (1) LG U+ (18) LSC (1) LTE (78) LTE-A (16) LTE-B (1) LTE-H (2) LTE-M (3) LTE-U (4) LoRa (7) MEC (3) MPLS (2) MPTCP (3) MWC 2015 (8) NB-IoT (6) Netflix (2) Network Protocol (21) Network Slicing (4) New Radio (9) Nokia (1) OSPF (2) OTT (3) PCRF (1) Platform (2) QoS (3) RCS (4) Roaming (1) SD-WAN (17) SDN/NFV (71) SIM (1) SK Broadband (2) SK Telecom (34) Samsung (5) Security (16) Self-Driving (1) Small Cell (2) Spectrum Sharing (2) Switching (6) TAU (2) UHD (5) VR (2) Video Streaming (12) VoLTE (8) VoWiFi (2) Wi-Fi (31) YouTube (6) blockchain (1) eICIC (1) eMBMS (1) iBeacon (1) security (1) telecoin (1) uCPE (2)
Password confirmation
Please enter your registered comment password.
Password