Your SlideShare is downloading. ×
Why should jitter be minimized in CPRI fronthaul?
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Why should jitter be minimized in CPRI fronthaul?


Published on

Download a PDF file: …

Download a PDF file:
You can also find and download more materials from

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. 1 NETMANIAS TECH-BLOG Please visit to view more posts Why should jitter be minimized in CPRI fronthaul ? July 4, 2014 | By Steve Shin ( and S.M. Shin ( 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. GPS Master Reference Clock BBU 1/fo 1/(fo +Δf) Master reference clock Recovered reference clock LTE Baseband fo CPRI CPRI CPRI Fronthaul Recovered Reference Clock Digital/ Analog ANTENNA Data (I/Q) Data (I/Q) Jitter + fo +Δf RRH Data (IP) RF I/Q bit stream Frequency Synchronization fo ≃ fo +Δf ▶Clock recovery through referencing to the CPRI I/Q bit stream received at RRH ▶Frequency synchronization between BBU and RRH? Jittered I/Q stream Jitter Unit Interval Received signal (with Jitter) Received signal (Ideal) t
  • 2. Netmanias Tech-Blog: Why should jitter be minimized in CPRI fronthaul ? 2 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. RRH clock frequency fo fo +Δf time Clock frequency deviation +2ppb -2ppb For example, assuming that the reference clock frequency of BBU is 30.72MHz, 2ppb of clock frequency accuracy represents 0.06144Hz.
  • 3. About NMC Consulting Group ( NMC Consulting Group is an advanced and professional network consulting company, specializing in IP network areas (e.g., FTTH, Metro Ethernet and IP/MPLS), service areas (e.g., IPTV, IMS and CDN), and wireless network areas (e.g., Mobile WiMAX, LTE and Wi-Fi) since 2002. Copyright © 2002-2014 NMC Consulting Group. All rights reserved. 3 Carrier WiFi Data Center Migration Wireline Network LTE Mobile Network Mobile WiMAX Carrier Ethernet FTTH Data Center Policy Control/PCRF IPTV/TPS Metro Ethernet MPLS IP Routing 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13 eMBMS/Mobile IPTV Services CDN/Mobile CDN Transparent Caching BSS/OSS Cable TPS Voice/Video Quality IMS LTE Backaul Netmanias Research and Consulting Scope Visit to view and download more technical documents. Future LTE IP/MPLS CarrierEthernet Networks Consulting POC Training Wi-Fi Infrastructure Services CDN Transparent Caching IMS Concept Design DRM eMBMS protocols Analyze trends, technologies and market Analysis Report Technical documents Blog One-Shot gallery We design the future We design the future We design the future