|
Delivery of Timing and Circuit Services using Packet-based Synchronization
Written by Nir Halachmi
Introduction As broadband Ethernet services are becoming a commodity, mobile network providers, business owners and service providers are examining ways to take advantage of these services for delivery of their packet based communications and legacy circuit services. This paper addresses the deployment of mobile backhaul as well as Ethernet and Legacy services to business and residential customers and the important role that the emerging use of packet-based synchronization methods play in the delivery of these services. Specifically, the paper discusses:
Clock Recovery Combinations for Co-located 2G, 3G and 4G Deployments Packet-based mobile backhaul meets the mobile providers’ business needs of increased bandwidth at a lower cost. The migration to packet-based mobile backhaul must take into consideration the requirement to transport circuits across the backhaul for 2G and 3G cell sites and the need for accurate and cost effective synchronization at all cell sites. Mobile Backhaul using Ethernet without synchronization services Figure 1 describes mobile backhaul deployment utilizing Ethernet Services offered by packet carriers where the backhaul providers do not provide any synchronization services to the user; synchronization needs to be independently transferred over the carrier network
Figure 1 The figure illustrates the interconnection of three sites; the Central Site C hosting 2G and 3G controllers and 4G gateways, a Large Cell Site L hosting collocated 2G, 3G and 4G base stations, and a Small Cell Site S hosting a 3G base station. Many more cell sites participate in typical deployment scenarios, ranging from pico-cells to mega-sized macro cells, all interconnected in a similar fashion. Mobile backhaul is provided in this case by two carriers; the Green (G) carrier and the Orange (O) carrier. Two carriers were chosen to enhance resiliency for large sites and ensure coverage reaching all smaller sites. The carriers install demarcation devices D1-20 at sites’ location to provision the acquired services. The various devices at the cell sites are connected through customer edge devices CE1-20 providing the services to the base stations and controllers. The user-network-interface is setup between the edge and demarcation devices, clearly indicating the ownership and responsibility boundaries between the carrier and the user. The edge devices provide Ethernet, circuit and synchronization services, utilizing the Ethernet (or MPLS) UNI provided by the carriers. The demarcation devices run end-to-end OAM enabling quick discovery and recovery from device, link and carrier failure events. Transitioning from TDM Backhaul to Packet Backhaul with PTP Figure 2 illustrates the 2G/3G central site deployment in more details.
Figure 2 Prior to the transition to packet based backhaul, the 2G/3G central sites were all connected to cell sites over TDM backhaul using traditional telecom carriers. The central site in our example used several STM-1s SDH UNIs for carrying backhaul traffic, where each cell site was connected with several E1 circuits to the 2G Base Station Controller (BSC) and to the 3G Radio Network Controller (RNC). Add-Drop-Multiplexers (ADMs) were used to aggregate the BSC’s E1 interfaces to STM-1s used at the UNI, and Inverse-ATM-Multiplexers (IMA) were used to convert 3G RNC ATM STM-1c traffic to E1 with STM-1 format for delivery to the cell sites. To minimize risk and to ensure smooth transition from TDM backhaul to packet backhaul, the mobile provider’s planning group decided that the configuration and settings of the central site will not be modified, and the adaptation to packet backhaul will be completely handled by the new deployed edge devices (CE1 to CE4). That is, the edge devices will be connected to the central site controllers through the (old) TDM UNI and convert the traffic to the new packet UNI. If anything goes wrong during the transition, the central site can simply revert back to the TDM backhaul until problems are isolated and solved. Each edge device provides two main functions; E1 CES (circuit emulation) Inter-Working-Function (IWF) that encapsulates the E1 traffic sent to a cell site in packet streams, and PTP Master function to deliver accurate frequency synchronization streams to each site. The edge devices are organized in active/backup pairs (CE1 and CE3, CE2 and CE4) protecting the service from link, device or carrier failures. The figure illustrates the E1 CES streams and PTP streams sent from the edge devices toward the cell sites. The PTP streams sent by CE1 and the CES traffic sent by CE4 are not shown to simplify the drawing. Two frequency clock sources, CLK-1 and CLK-2 are shown in the figure. CLK-1 is driving the 2G and 3G controllers while CLK-2 is driving the edge devices and the ADMs. When the TDM UNI is used, i.e. prior to the transition to the ETH UNI, CLK-2 is the TDM carrier clock supplied through the SDH UNI, which is not necessarily traceable to CLK-1. The edge devices’ PTP Master Synchronization stream carries CLK-2 to the cell sites. The BSC E1s clocks are driven by CLK-1. The difference between CLK-1 and CLK-2 is encoded in the RTP header of the CES packets to allow the cell sites’ edge device to recover CLK-1 through CES differential timing method. See appendix A for more details. Figure 2 illustrates only one deployment scenario out of many other possible ones. Planners in other scenarios may prefer separating the PTP Master function to dedicated equipment. Some deployments may rely on a single clock source to drive both the edge devices and mobile controllers (i.e. CLK-2 is locked to CLK-1). Using PTP to transfer master clock to slaves Figure 3 illustrates the cell sites 2/3G deployment at both the small cell site S and the large cell site L.
Figure 3 The large cell site (L) is composed of multiple base stations serving 2G, 3G and high speed 3.5G packet services. The edge devices provide Ethernet, E1 and clock services to the base stations. The PTP slaves at the edge devices recover the synchronized clock and provide a synchronized frequency interface to base stations. Each PTP slave is configured with the addresses of two PTP masters, as allowed by the ITU-T telecom profile, to ensure delivery of adequate clock synchronization at all times. For further redundancy, a backup synchronization interface is connected between the two edge-devices CE10 and CE11, used when connection to both masters fail. The CES IWF converts the E1 CES stream to E1 feeds. If the CES E1 clock and the PTP clock are not traceable to the same clock source, as in the scenario described in Figure 2, the IWF uses the timestamps encoded in the RTP header to recover the E1 clocks using differential clock recovery methods. Appendix A describes differential and adaptive clock recovery in more details. Cell site S represents a small installation designed with emphasis on low deployment cost. The single 3G Node-B is connected to an edge device that provides E1 CES and Ethernet services. The edge device uses the IWF CES adaptive clock recovery method to recover the E1 clocks. Adaptive clock recovery mechanism recovers the clock by examining the incoming packets arrival time, and doesn’t require any special master function? When required, the edge device can be upgraded to support synchronization delivery via PTP. No configuration changes will be required at the central site. 4G Deployment with PTP master or PTP Boundary Clocks There are many other possible deployment scenarios at the cell sites as well. In particular some newer 3.5G base stations are equipped with a built-in PTP slave. The Node-B PTP slave can either drive its synchronization directly from a PTP master located at the central site or lock to a locally available PTP boundary clock. This option is elaborated below presenting 4G deployment scenario. 4G technologies like WiMAX and LTE use Time Division Duplex (TDD) transmission methods that require tight phase synchronization between cells in the order of microseconds. Provision of Multicast-Broadcast-Multimedia-Services through a Single-Frequency-Network (MBSFN) and Coordinated Multipoint Transmission (aka Network MIMO) may require phase synchronization at a level of 1 microsecond or better. Delivery of phase synchronization at this level without on-path support (i.e. without support of the packet carrier) is challenging without a sophisticated slave algorithm. However the clear advantages of packet based backhaul are driving mobile providers to experiment and deploy 3.5G and 4G services with full or partial reliance on synchronization through PTP over the packet backhaul. The PTP master function is usually located at the central site. Figure 4 describes two possible deployment scenarios of 3.5 and 4G services at the cell site.
Figure 4 In these examples the base stations are equipped with built-in PTP slaves. Node-B slave recovers frequency while the eNode-B recovers both frequency and phase. In cell site A the edge devices provide Ethernet services only, and the PTP slaves communicate directly with the PTP master across the backhaul. In cell site B, GPS is used as primary source for time synchronization while PTP is used only as a backup timing source. The edge devices in cell site B support PTP boundary clock function, recovering clock from the remote PTP master and acts as master towards the base stations. The PTP slaves at the base stations communicate locally with either the master port of edge device CE11 or CE12 whoever is chosen as the Best-Master-Clock (BMC) as defined by the PTP protocol. The base stations are oblivious whether the clock source is GPS or the remote PTP master. The accuracy and stability of the recovered clock depends on multiple factors:
To ensure that the performance of the recovered clock meets the mobile backhaul requirements, slaves must implement state-of-the-art recovery algorithms with highly stable (and hence expensive) oscillators as local references. Thus an effort is made to minimize the forwarding delay variations introduced by the packet carrier. Advanced packet carriers offer multiple classes of forwarding services, which ensures that delay variations experienced by timing packets will be bounded. However since the accuracy required at the cell sites is in the order of one microsecond and the forwarding delay variations experienced even at the highest class of service is in the order of hundreds of microseconds or more, recovering the clock within the required performance at all times is challenging. Emerging transparent timing services The IEEE-1588-2008 standard defined a new type of clock called Transparent Clock (TC). Transparent clocks measure the residence time (forwarding delay) experience by each PTP message and add it to a correction field in the PTP header. A Transparent Clock that corrects the residence time of PTP messages on the fly is called one-step Transparent Clock. The IETF and MEF standard organizations are exploring ways to include such TC functions within packet carriers in general and MPLS carriers in particular and provide a new type of packet carrier technology enabling a new type of service – the transparent timing service.
Figure 5 The concept is illustrated in Figure 5 where the packet carrier offers transportation of timing packets across the carrier network, eliminating forwarding delay variations noise altogether. This technology promises to ensure compliance with strictest timing accuracy requirements at all times, and to significantly lower the cost of slave implementation at the cell sites. Once most noise sources are eliminated simpler recovery algorithms utilizing cost effective oscillators can be used. Transparency implies that multiple clocks can be transported across the packet carrier, as indicated by the green and purple clocks in Figure 5. To successfully deploy such technology, it has to be scalable, i.e. allow transporting of any number of clocks, and support any rate of timing packets. The PTP Transparent Clock (TC) is based on a simple idea - measure the forwarding delay of PTP messages while in transit, and add this information to the timing packets. Hence when the timing message is received at the slave, it can simply eliminate the forwarding delay variations by subtracting the forwarding delay information included in the message from the measured timing packet arrival time. PTP allows for two different types of TC implementations, either 1-step or 2-step. 1-step TC measures and updates the residence time within event messages (sync and delay-request) on-the-fly, while a two-step TC conveys the measured residence time of the event message (sync and delay-request) in an associated general message (follow-up and delay-response). Implementation of 1-step TC requires special hardware support, while a 2-step TC can be implemented on a larger set of hardware available today. Scalability requires that no state information is kept per packet (or clock) transported across the packet carrier, thus the measured delay variation information (residence time) should be included within each forwarded timing packet. That is, it will be advantageous to deploy such service using 1-step Transparent Clocks. Once timing transparent packet services are available, provisioning of a common synchronized clock shared by different elements (all cell sites of a mobile provider, all branches of a large organization, all femtocells deployed at residence sites, etc.) using PTP will become simple and cost effective; expensive oscillators and sophisticated recovery algorithms are not required. If additional clocks are required, i.e. for deployment of circuit emulation across the packet carrier, differential timing methods can be used for this purpose. Transparent timing services have the potential therefore to lower also the cost for circuit emulation deployments and allow deployments for services that require high clock accuracy such as SDH circuit emulation services. The Synchronized Metro-Access Network: The availability of a synchronized clock at the edges of metro access network allows provisioning of robust circuit services to the end user to address the connectivity needs of both mobile providers and business customers. Figure 6 illustrates a simplified metro access network providing business services. Two main services are provided; Ethernet connectivity and leased lines. Local sites (sites A and B) are interconnected directly, while remote sites are connected through gateways; the TDM leased lines are connected to the traditional telecom network, while the metro-access Ethernet pseudo-wires segments are connected through gateways to the core network, and routed to the remote sites.
Figure 6 Provisioning of mobile backhaul services is similar to the provisioning of business services, as illustrated in Figure 7. The main services required are leased lines for carrying 2G and 3G backhaul traffic between central sites and cell sites, and Ethernet connectivity from the cell sites to the Internet. 4G cells require Ethernet connectivity as well. In this case CES services are not needed.
Figure 7 The availability of a synchronized clock at the edges allows provisioning of leased lines by using of circuit emulation, and also enables providers to offer frequency and time synchronization services to cell sites.
Figure 8 Figure 8 illustrates the network elements at edges of the metro-access network providing business services. The User-Network-Interface (UNI) to the business sites is on the right and to the Network-Network-Interface (NNI) is on the left. The network is synchronized through Synchronous Ethernet. The demarcation devices provide Ethernet service (orange) and leased line services (green) using Circuit Emulation Service (CES). In this example E1 leased lines are provided to businesses, connecting Private Branch Exchanges (PBXs), Video Conferencing equipment and other equipment that require Constant Bit Rate (CBR) connectivity. The business customer can run bits at a rate of 2.048Mbps in any format across the leased line and expect these bits to appear on the other side of the line unmodified. The business customer equipment supports the traditional E1 leased line clock. In this figure three different businesses reside in business site A, each driving its own leased line with a different clock, symbolized by the purple, green and black clocks blocks. Utilizing a Synchronous Clock at the Edge The demarcation devices segment and send the leased line bit stream as CES packets to their destination demarcation device, and reassemble the leased line bit stream of the CES packets received from the remote device. The demarcation device must play out the reassembled E1 bit stream at the exact bit rate, i.e. using the same clock driving the leased line at the remote end, as if the leased line was connected through a direct E1 cable. For example, the demarcation device D3 at site B must clock out the E1 towards the customer’s equipment with a ‘purple’ clock. It cannot assume that the purple clock is driven by equipment at site B. It must recover the clock that was driving the E1 leased line at site A, as received by demarcation device D1. A common synchronous clock at all edges of the metro-access network enables the use of differential clock recovery method for recovery of the E1 clock at the remote site. Each CES packet is marked with a timestamp (at the RTP header) that encodes the difference between the E1 lease line clock (e.g. purple clock) and the synchronous clock (SyncE blue clock). The remote demarcation device decodes the difference between the clocks by analyzing the timestamps of received packets, and using SyncE clock, recovers the clock to drive the E1 at its end. See appendix A for more detailed explanations. Provisioning Leased Lines outside a Local Metro Access Network Leased lines which reach outside of the local metro-access network can be provisioned as well. In the example above, the leased lines are carried over CES segments connecting the business sites to a service provider leased line exchange. The demarcation devices are connected to the telecom exchange using high speed SDH interfaces, carrying E1s destined to multiple destination sites. Each set of leased line E1 is clocked by a different clock, as shown by the purple, green and block clock symbols within the telecom exchange. The demarcation device D10 must recover the clock of each leased line carried over CES to play out the E1 bit stream onto the SDH interface. The availability of the synchronous clock at the edges allows it to use differential recovery methods for this purpose here as well.
Figure 9 Figure 9 illustrates the network elements at the edge of the network providing mobile backhaul services. Using circuit emulation, multiple E1s are connected to 2G and 3G base stations at the cell sites and to the controllers in central office. The demarcation devices D1, D2 and D3 at the cell sites can either use the synchronous clock to time the E1s or if the controllers at the central site use a different independent clock to drive the backhaul, differential clock recovery methods can be used. The Timing UNI Beyond provisioning of Ethernet and E1 circuits for backhaul connectivity, a new User-Network-Interface is being discussed - the timing UNI. Work is in progress in the ITU-T and other standards organizations to define telecom profile for time distribution in carrier networks, which is the prerequisite for the provision of the timing UNI. ? The timing UNI provides synchronized frequency and time and has the potential to be highly beneficial for 4G LTE deployments which requires accurate frequency, phase and time at the cell site. The timing UNI can be a cost effective and reliable alternative to a locally installed GPS at the cell site. Provisioning the timing UNI requires that metro access networks bring both time and frequency to its edges. In Figure 9 above the IEEE-1588 Precision Time Protocol is used, along with SyncE to deliver frequency and time to the edges. To ensure time accuracy less than 1us, boundary clocks are used at each hop, up to the selected cell site edges. A timing UNI can be delivered to the cell site either using an IEEE-1588 feed over Ethernet interfaces, or using a dedicated physical synchronization interface. Conclusion Carriers are deploying frequency-synchronized packet networks, extending their reach to the edge using copper, fiber and wireless access technologies. Carriers and vendors alike are working to construct a solution that offers robust, performance compliant and cost effective clock synchronization for legacy circuit services as well as for mobile services across these multiple access technologies. The need of synchronized frequency and/or phase clock at the edge is the first order consideration in selecting the synchronization methods used in delivering circuit emulation and synchronization services to the end user. To reduce operation costs mobile providers and business owners are deploying circuit emulation and timing distribution solutions over Ethernet connectivity services offered by packet carriers. The use of PTP for distribution of synchronized clock to remote business or cell sites is becoming predominant. The use of differential timing methods for delivery of circuit emulation driven by independent clocks complements the solution. Whenever PTP clock distribution is not available or in deployments with emphasis on low cost, adaptive clock methods will used instead as part of the circuit emulation deployed solution. In large deployments, PTP on-path and Synchronous Ethernet availability at the edge cannot be relied upon across all sites as it requires all devices in path to support it in hardware. Therefore planning should take into consideration provisioning of circuit and synchronization services with and without the carrier support. The International Telecommunication Union (ITU-T), Internet Engineering Task Force (IETF) and Metro-Ethernet-Forum (MEF) are working to standardize phase and time delivery using a specially designed telecom profiles of the IEEE-1588 Precision Time Protocol (PTP). The use of PTP on-path support in the form of Boundary Clocks (BCs) and Transparent Clocks (TCs) for robust phase and time delivery is being examined both in the standards organizations as well as with early adapters’ deployments around the world. The emerging transparent timing services and the introduction of the timing UNI will further reduce the cost of deployments, improve performance and robustness of the clock and time available at remote locations, and allow deployment of new applications which require precise timing at all times. Appendix A: E1 leased line circuits are mostly plesiochronous; i.e. they are driven by a near-synchronous clock. Any equipment with E1 interface is required to clock the E1 circuit at a frequency within the range of 2048 kHz ± 102.4 Hz. The E1 receiver must be synchronized with the transmitter’s clock at all times; otherwise E1 data will be lost. The receiver can simply lock its local clock to the transmitter clock by tracking the incoming stream of E1 bits. When E1 is carried over packet network using circuit emulation service, locking the receiver clock becomes much harder task. This appendix provides a high level description of two methods for circuit emulation clock recovery; differential and adaptive clock recovery.
Figure 10 Figure 10 illustrates two E1 circuits connected between an E1 source and sink; the upper E1 is carried over a packet network while the E1 bits of the lower one are transmitted end to end on a physical wire. The two E1s are clocked by the same clock (the service clock). The Circuit Emulation Inter-Working Function Transmitter (CES IWF Tx) packetizes the E1 bits it receives from the E1 source and sends the packets to the receiver. The receiver (CES IWF Rx) extracts the bits from the received packets and plays them out on the E1 interface towards the E1 sink. The receiver must play out the E1 bits at the same rate as the service clock, i.e. it needs to steer its local clock such that its rate will be locked to the E1 source clock. To illustrate the accuracy expected from the CES IWF clock recovery mechanism, two wall clocks were added to the figure on the left, each driven by its respective recovered E1 clock. Assume that we reset both wall clocks to zero at the same time. The expectation is that the difference between the wall clocks will not exceed more than a few microseconds at all times.
Figure 11 Figure 11 illustrates the use of differential clock recovery for CES. Differential clock recovery is applicable whenever a common reference clock is available at both the transmitter and the receiver CES IWFs. The common reference clock is shown in blue in Figure 11. The transmitter maintains a timestamp driven by the reference clock, and reads the timestamp whenever it gathers enough E1 bits to fill the CES packet’s payload. The transmitter sets the timestamp in the Real-Time-Protocol (RTP) header of each CES packet. The RTP timestamp encodes the difference between the service clock and common reference clock. For example assume that the (purple) service clock and the (blue) common reference clocks are locked to each other, and that the RTP timestamp is driven directly (without a multiplier) by the common reference clock at 2048 kHz rate. Then if a packet contains 512 bits (two E1 frames) than the timestamp will advance in 512 steps each packet. If the service clock rate is slower than the common reference clock, then the timestamp will advance in two step sizes; 512 in most cases and once in a while the difference will jump to a 513 step. Similarly if the service clock is faster, occasionally the difference between subsequent RTP timestamps will be 511. The differential clock recovery function at the receiver side extracts the difference between the clocks as encoded in the RTP header of incoming packets and steers a local clock to drive the E1 interface accordingly. In addition the IWF samples the E1 bits with a timestamp driven by the common reference clock, repeating the RTP timestamping procedure at the transmitter; if both clocks are locked, the incoming RTP timestamps and the locally sampled timestamps should advance at the same rate. Other methods for implementing differential clock recovery are possible as well. Differential clock recovery is fast, robust and accurate as it is not affected by packet forwarding delays. The difference in clocks is encoded in the RTP header and the arrival time of each packet is of no importance to the recovery algorithm.
Figure 12 Figure 12 illustrates the use of adaptive clock recovery for CES. When common reference clock is not available at both ends, the CES receiver must use a different method to recover the service clock. Figure 12 illustrates the use of adaptive clock recovery. The main observation here is that the CES packet transmit rate is driven by the service clock, and hence it is possible to recover the clock by measuring the rate of incoming packets. If all CES packets were forwarded from transmitter to receiver without variation in their forwarding delay, adaptive clock recovery task would be fairly easy. Since even in managed networks the forwarding delay variations are in the order of hundreds of microseconds up to milliseconds, recovering the service clock with accuracy of single-digit-microseconds is challenging, and requires sophisticated noise filtering techniques and a stable local oscillator. Bibliography: [1] IEEE1588-2008, IEEE Standard for a Precision Clock Synchronization protocol for Networked Measurement and Control Systems, March 2008.
Set as favorite
Bookmark
Email This
Hits: 2118 Trackback(0)
Comments
(0)
You must be logged in to a comment. Please register if you do not have an account yet.
|
| Last Updated on Thursday, 20 October 2011 05:11 |
TrackBack URI for this entry
Subscribe to this comment's feed
