|
Synchronization in packet-based mobile backhaul networks Abstract Mobile backhaul networks are evolving from circuit switched to packet switched technologies to meet exploding demand for bandwidth in both core and access networks. A prerequisite in the evolution to packet-based backhaul in mobile backhaul networks is the ability to deliver carrier grade synchronization over the packet network to remote wireless base stations and access platforms. Synchronization in legacy mobile backhaul networks SDH/SONET network synchronization hierarchy Network synchronization in legacy telecom systems is based on clock hierarchy, with the highest accuracy clock at the top, as illustrated below:
Figure 2‑1: SDH/SONET network synchronization hierarchy At the top of the hierarchy is the Primary Reference Clock (PRC) or Primary Reference Source (PRS) with clock accuracy of 1 part in 1011 [1]. PRC/PRS can be generated from a cesium (atomic) clock or from cesium clock-controlled radio signals, such as Global Positioning System. At the second level of hierarchy is Synchronization Supply Unit (SSU) [2] or Building Integrated Timing Supply (BITS). SSU/BITS includes holdover, a feature that allows it to generate a clock with higher accuracy than its intrinsic free running accuracy for a short period after it loses synchronization with PRC/PRS. The third level is the SDH Equipment Clock (SEC) [3] or SONET Minimum Clock (SMC). SEC/SMC also features holdover, but its holdover and free-run accuracy performance is lower than what is required for SSU/BITS. The second and lower levels of hierarchy will have clock accuracy equal to PRC/PRS, so long as their path to the PRC/PRS is not broken. While PRC/PRS and SSU/BITS are usually implemented as standalone products with timing-only functionality (no data transmission), SEC/SMC are almost exclusively implemented as a part of networking product, such as an SDH/SONET add-drop multiplexer.
Time and frequency synchronization in Mobile Networks Synchronization is crucial for Mobile wireless networks because the radio used in these networks operate in very strict bands that need separation to avoid channel interference which reduces the call quality and network capacity. Poor synchronization has also negative impact for the handover between Base Stations. Mobile handsets derive the accurate frequency that they transmit and receive from the Base Stations. If the transmission frequencies are not very closely matched between adjacent cell sites, then “clicks” can occur when the call is being handed over (switches) between Base Stations. In the worst case, the call would drop because the mobile handset would not be able to immediately lock onto and acquire the new signal. It is clear that the need for synchronization has always been inherent in Radio Access Networks. Radio networks fall into two categories:
The modulated carrier frequency of the BS shall be accurate to within the accuracy range given in Table 6.0 observed over a period of one timeslot.
Table 6.0: Frequency error minimum requirement When time synchronization is required, it also has strict requirements. For example the radio interface requirement for WCDMA (UMTS) TDD base stations is a frequency accuracy of ±50ppb; for the TDD mode there is the additional requirement for the phase alignment of neighbouring base stations to be within 2.5ms. In the case of CDMA2000 the time synchronization requirement is that for all base stations, the pilot time alignment error should be less than 3ms and shall be less than 10ms. The table below provides a reference for today’s wireless technologies and their synchronization requirements.
Synchronization in TDM based mobile backhaul networks Conventionally GSM, WCDMA (UMTS) FDD base stations (CDMA2000 uses GPS receivers because of the need for time synchronization) that are connected via TDM networks can be synchronized via TDM timing (PDH or SDH). Following a master-slave architecture, the timing (frequency synchronization) is distributed over the TDM links from an accurate primary reference clock to slave clocks. With the replacement of TDM links with Packet Switched Networks (PSNs) such as Ethernet, IP or MPLS, this simple method of providing a frequency reference is lost, and frequency information must be made available in some other way. The solutions are discussed in the following section. Footnotes:
Synchronization solutions for packet based mobile backhaul networks As previous sections of this paper show, synchronization is a crucial factor in mobile backhaul, and probably the most challenging capability to be supported over packet-switched networks. In a TDM network, clock is transported natively over the network, but with a packet-based transport network that is asynchronous in nature, it is a necessity to develop mechanisms to transport the clock in a very accurate and reliable manner with minimum bandwidth consumption. These mechanisms need to overcome packet-based network issues, such as varying delay, jitter and packet loss. In January 2009 Metro Ethernet Forum published the MEF 22 (Mobile Backhaul Implementation Agreement – phase 1)[8] which provides guidelines for implementing mobile backhaul network that is based on Carrier Ethernet. The synchronization requirements specified in MEF 22 are derived from the ITU-T Recommendation G.8261 [9], which studies timing and synchronization over packet based networks and also examines the requirements for different mobile technologies. As G.8261 states there are two basic categories of synchronization solutions for packet-based mobile backhaul networks:
Packet-based solutions Packet-based methods use a master-slave mechanism where a master distributes timing to the slaves via packets that carry timestamps. The master has access to an accurate reference, such as GPS.
The main packet protocols currently defined are network time protocol (NTP) and precision time protocol (PTP).
NTP Network Time Protocol, (NTP), is one of the oldest Ethernet protocols still in use. It was originally designed by Dave Mills of the University of Delaware about 25 years ago. NTP v3 is defined in RFC 1305 [10] and NTP v4 [11] (backwards compatible with NTP v3) is an Internet-Draft which includes fundamental improvements, one of them being to extend the potential accuracy to the tens of microseconds. The latest version of NTP, Version 4 (NTP v4) can usually maintain time to within 10-20 milliseconds over the public Internet and can achieve accuracies of microseconds or better in local area networks, under ideal conditions. The issue is that its accuracy can degrade substantially if networks becomes congested. NTP is quite simple in operation; the NTP client polls the NTP server at regular intervals and the server responds with a time stamp. The problem with using NTP for precise timing applications is that there is no allowance to account for network delays other than through multiple poll time averaging techniques and buffering. So NTP, even in the latest implementation does not meet the higher precision requirements for 3G/4G wireless backhaul.
IEEE 1588 (PTP) Precision Time Protocol, (PTP), popularly known as IEEE standard 1588 [13], is the latest revolution in IP timing technology. Originally designed to provide precise timing for critical industrial automation applications it is now providing the highest level of accurate frequency and time to wireless backhaul networks. Currently standardized in 2008 as Version 2 (IEEE-1588v2) [13] (supersedes IEEE 1588-2002 [12]) , PTP overcomes the Ethernet NTP latency and jitter issues, providing an unprecedented accuracy in the nanosecond range. Network delays and latency are greatly reduced by measuring the roundtrip delay between the master and slave clock (client), using a technique where the slave and master communicate with short messages to each other in order to measure and cancel out delay and latency inaccuracies.
PTP network components The following figure shows a possible PTP synchronization network topology.
Figure 4-2: PTP synchronization topology
Grandmaster Clock This is the primary reference source within a PTP sub-domain. The Grandmaster clock has a high-precision time source, which can be a GPS reference or an Atomic clock.
Boundary Clock Boundary Clock (BC) is specified by both Version 1 and Version 2 of IEEE standard 1588. A boundary clock sits in place of standard network switches or routers. IEEE 1588 boundary clocks are an effective way to reduce packet jitter. A boundary clock runs the PTP protocol and is synchronized to the master clock. The boundary clock in turn acts as a master clock to all slaves within the same network. So the boundary clock acts as an interface between separate PTP domains intercepting and processing all PTP messages (BC does not pass Sync, Follow_Up, Delay_Req, or Delay_Resp messages) and passing all other network traffic. Cascading of BCs introduces the cascade effect because BC distributes timing based on the its local clock and so each clock depends on the quality of all preceding clocks. The BMC algorithm (see below at PTP operation) is used by the boundary clock to select the best clock any port can see. The chosen port is set as a slave and all other ports of the boundary clock are asserted as masters to their domain. The following figure shows a network topology with Boundary Clocks:
Figure 4-3: Boundary Clocks Transparent Clocks Transparent clocks added to version 2 of the standard as an improved method of forming cascaded topologies where each clock does not depend on the quality of the preceding clocks. Rather than acting as a multi-port ordinary clock as boundary clocks do, transparent clocks update a newly introduced time-interval field within PTP event messages. This 64-bit time-interval correction field allows for switch delay compensation to a potential accuracy of less than a picosecond. There are two types of transparent clocks, end-to-end and peer-to-peer. End-to-end Transparent Clock forwards PTP event messages, but modify the messages for the residence time for the message to traverse the Transparent Clock. The residence times are accumulated in the correction field of the PTP event message or the associated follow-up message.
Figure 4-4: End-to-end transparent clocks Peer-to-peer Transparent Clock, measure the local link delays using the peer delay mechanism, in addition to the residence time. The computation of link delay (peer delay mechanism) is based on an exchange of Pdelay_Req, Pdelay_Resp, and possibly Pdelay_Resp_Follow_Up messages with the link peer.
Figure 4-5: Peer-to-peer transparent clocks Peer-to-peer and end-to-end TCs cannot be mixed on the same communication path. Peer-to-peer transparent clocks can allow for faster reconfiguration after network topology changes. Concluding, transparent clock is a PTP enhanced switch which modifies the precise timestamps within the PTP messages to account for receive and transmit delays within the individual switch itself, thus leading to improved sync between the slave and master clocks.
PTP operation PTP operation is based upon the transfer of short messages to determine system properties and to convey time information. A delay measurement method is used to determine path delay, which is then used for the adjustment of local clocks. IEEE 1588 uses a specific algorithm, the Best Master Clock (BMC) algorithm, in order to determine which clock is of the highest quality within the network and to create a master/slave hierarchy. The BMC node (grandmaster clock) then synchronizes all other nodes (slave clocks) in the network. The BMC algorithm is then run continuously to quickly adjust for changes in network configuration. So, if the BMC node is removed from the network or is determined by the BMC algorithm to no longer have the highest quality clock, the algorithm determines the new BMC node. After the creation of the master/slave hierarchy, synchronization is achieved by a series of messages between master and slaves. There are five message types - Sync, Delay Request, Follow Up, and Delay Response - which are used by the protocol. The sequence of message transactions which takes place to synchronize a pair of clocks is shown in the following figure.
Figure 4-3: IEEE 1588 operation The PTP operation has two phases. In the first phase the slave correct his time difference with the offset measurement and at the end of it the slave clock is synchronized in frequency with the Master clock. In this phase the master sends a SYNC message to the slave cyclically at defined intervals. This “Sync” message contains the current time of the master clock. However, since the reading out of the clock, the delays of the communication stack and the transmission of the data via the Ethernet hardware require an undefined time, the time information in the “Sync” message is not precise when it leaves the master. Therefore the actual transmission time of the message is measured as close as possible to the physical interface (ideally directly at the Ethernet port by hardware – see ANNEX A: Hardware assisted time stamping) and this information is sent to the slave by a second message, the “Follow-up” message. Upon reception of the “Follow-up” message, the slave calculates the correction value (offset Δt). The slave clock is then corrected by this offset. So both clocks are now synchronized in frequency. The second phase of the synchronization process determines the network delay time between slave and master. For this, the slave sends a "Delay Request" packet to the master and determines the exact transmission time of the message. The master creates a time stamp when it receives the packet and sends the reception time back to the slave in a "Delay Response" packet. From the local transmission and reception time stamp of the master, the slave determines the delay time between the slave and the master. The delay measurement is made at greater intervals than an offset measurement. The IEEE1588 standard makes several assumptions about the network being used (for example multicast support) but the key assumptions that affect clock accuracy are: 1. The transmission delays are almost constant over time (or at least change slowly) Assumptions above are not necessarily true in a general network. This is due to the fact that the scope of IEEE1588 is for local networks, and the standard was originally targeted at command and control networks used for data acquisition. Within these networks it is possible to control these parameters to desired levels. Boundary clocks, transparent clocks and hardware assisted time stamping try to fulfill the above assumptions. Ultimately, the accuracy depends on many elements:
Hardware implementation (packets time-stamped by hardware very close to the PHY) or software implementation (packets time-stamped in software interrupt routines) of the time stamping mechanism CoS used for the IEEE1588 messages. These must run in the best CoS that the network can offer. Furthermore, the SLS must ensure very low delay and delay variation.
Synchronous Ethernet solution Synchronous Ethernet is mentioned in MEF 22 [8] as a possible scenario for timing distribution in a mobile network. Packet technologies were initially designed to work in asynchronous mode where the oscillators in the equipment are free running. The primary idea behind Synchronous Ethernet is that the input reference clock is not free-running with an accuracy of ±100 ppm, but rather locked and traceable to a primary reference clock. ITU-T Recommendations G.8261, G.8262, and G.8264 define the distribution of timing over synchronous Ethernet physical interfaces. ITU-T Recommendation G.8261 [9] was the first ITU-T Recommendation which introduces the Synchronous Ethernet as part of the synchronization methods in packet networks. It extends the scope of the G.803 [16] reference synchronization chain to Synchronous Ethernet equipment and defines the architectural aspects of Synchronous Ethernet. ITU-T Recommendation G.8262 [14] specifies the clocks for Synchronous Ethernet equipment in a compatible way with SONET/SDH clocks as defined in G.812 [2] and G.813 [3]. It defines requirements for clock accuracy, noise transfer, holdover performance, noise tolerance, and noise generation. It defines two options for clocks for Synchronous Ethernet - these clocks are called Synchronous Ethernet equipment slave clocks (EECs). The first option, referred to as EEC-Option 1, applies to Synchronous Ethernet equipment designed to interwork with networks optimized for the 2048 kb/s hierarchy. The second option, referred to as EEC-Option 2, applies to Synchronous Ethernet equipment designed to interwork with networks optimized for the 1544 kb/s hierarchy. ITU-T Recommendation G.8264 [15] defines the use of synchronization status messages which contain an indication contain an indication of the quality level of the clock that is driving the synchronization chain, and is used to control, maintain, and restore the synchronization chains of Synchronous Ethernet equipment. Unlike packet-based synchronization solutions, this technology operates on the physical layer, effectively taking many of the SDH synchronization mechanisms over into the packet world. The figure below presents a diagram of network elements connected via an Ethernet interface and forming a synchronization network and timing chain.
Figure 4-4: Synchronous Ethernet timing distribution Passing synchronization is relatively simple – take the recovered clock from the node receiving synchronization, and with this clock, feed all nodes that are transmitting synchronization (Figure 4-4). The recovered signal needs to be cleaned with a PLL to remove jitter generated from the clock recovery circuit before being fed to the transmitting device. However, the PLL used in Synchronous Ethernet must provide additional functions beyond jitter cleaning (e.g. frequency accuracy, pull-in, hold-in and pull-out ranges) in order to fulfill the requirements of ITU-T G.8262. It is generally proposed that physical layer timing transport is required to guarantee frequency distribution to the extent necessary for encapsulated signals to meet network performance requirements. Although it is acknowledged that other methods such as IEEE 1588-2008 PTP may be used for this purpose, because it is impervious to the effects of traffic load, physical layer Synchronous Ethernet provides the best technical option for guaranteed frequency accuracy and stability. The downside is that it requires to be supported at every hop along the chain of nodes between the switching office and the cell site. Also this method can only be used to distribute frequency synchronization. Some other aspects of the Synchronous Ethernet that need to be considered are:
For the mobile backhaul requirements where the Ethernet network interfaces with the traditional TDM networks, Synchronous Ethernet can provide the necessary clocking input required for TDM links at the endpoints, as well as for new-generation Ethernet-based base stations. The following figure shows a typical example of Synchronous Ethernet application in a mobile backhaul network:
Figure 4-5: Example of Synchronous Ethernet in mobile backhaul
Mixed solutions It is also possible in some cases to combine Synchronous Ethernet and IEEE 1588 solutions. The figure below shows such a case.
Figure 4-6: IEEE 1588 and Synchronous Ethernet case 1 Above case is used when phase alignment is required (e.g. WiMAX 802.16e) or when not all MEN nodes support Synchronous Ethernet. Another case of combining IEEE 1588 and Synchronous Ethernet could be when the mobile backhaul network is implemented from two or more MEN operators. The figure below shows this case.
Figure 4-7: IEEE 1588 and Synchronous Ethernet case 2 At this case operator B doesn’t support Synchronous Ethernet while operator A does. So the operator’s A node which is connected with the network of operator B implements IEEE 1588 slave clock and the recovered clock is used as the reference clock for Operator’s A network. This clock is used as the reference clock for the Synchronous Ethernet implementation of MEN A.
Conclusion With the mobile backhaul network rapidly transitioning to IP/MPLS with Ethernet as the transport medium of choice, there is an increasing need for SONET/SDH-like frequency synchronization capability in the inherently asynchronous Ethernet network. Synchronous Ethernet is an ITU-T standardized PHY-level way of transmitting frequency synchronization across Ethernet packet networks that fulfills that need. A very high level of performance is achievable with Synchronous Ethernet not subject to the normal packet delay variation and traffic load conditions that can occur in packet based networks. But as mentioned before, Synchronous Ethernet does not provide time synchronization and requires a major investment in new infrastructure, so it may not be viable for all budgets. Consensus has formed among Tier 1 mobile operators and equipment manufacturers that frequency delivery as specified in ITU-T Recommendations for Synchronous Ethernet is the preferred solution for frequency and IEEE 1588v2 Precision Time Protocol (PTP) is the preferred solution for delivering both phase and time. So, a combinationof both technologies may be the answer to the question which technology to use. Footnotes: References [1] International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), 1997. ITU-T. G.811 : Timing characteristics of primary reference clocks. Available at: http://www.itu.int/rec/T-REC-G.811/en [2] International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), 2004. ITU-T. G.812 : Timing requirements of slave clocks suitable for use as node clocks in synchronization networks. [3] International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), 2003. ITU-T. G.813 : Timing characteristics of SDH equipment slave clocks (SEC). [4] ETSI TS 145 010 V8.4.0 (2009-06) Technical Specification Digital cellular telecommunications system (Phase 2+); [5] ETSI TS 125 104 V8.7.0 (2009-07) Technical Specification Universal Mobile Telecommunications System (UMTS); Base Station (BS) radio transmission and reception (FDD) (3GPP TS 25.104 version 8.7.0 Release 8) [6] ETSI TS 125 105 V8.4.0 (2009-07) Technical Specification Universal Mobile Telecommunications System (UMTS); Base Station (BS) radio transmission and reception (TDD) (3GPP TS 25.105 version 8.4.0 Release 8) [7] 3GPP2 C.S0002-E Version 1.0 Date: May 11, 2009 Physical Layer Standard for cdma2000 Spread Spectrum Systems Revision E [8] MEF Technical Specification MEF 22, “Mobile Backhaul Implementation Agreement Phase 1” [9] International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), 2008. ITU-T. G.8261 : Timing and synchronization aspects in packet networks [10] RFC 1305 – 1992, “Network Time Protocol (Version 3) – Specification, Implementation, and Analysis” [11] draft-ietf-ntp-ntpv4-proto-11 – 2008,”Network Time Protocol Version 4 Protocol And Algorithms Specification” [12] IEEE Std. 1588 - 2002 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. Superseded by 1588-2008 [13] IEEE Std. 1588 – 2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems, Published Date: Jul 24, 2008. [14] International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), 2007. ITU-T. G.8262 : Timing characteristics of synchronous ethernet equipment slave clock (EEC) [15] International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), 2007. ITU-T. G.8264 : Distribution of timing information through packet networks [16] International Telecommunication Union, Telecommunication Standardization Sector (ITU-T), 2000. ITU-T. G.803 : Architecture of transport networks based on the synchronous digital hierarchy (SDH) [17] IEEE Std. 802.16-2009 IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems [18] ETSI TS 136 104 V8.6.0 (2009-07) Technical Specification LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio transmission and reception (3GPP TS 36.104 version 8.6.0 Release 8)
ANNEX A: Hardware assisted time stamping IEEE 1588 uses hardware assisted time stamping in order to achieve sub microsecond synchronization accuracy. A Time Stamping Unit placed between the Ethernet Media Access Control (MAC) and the Ethernet PHY transceiver sniffs both inbound and outbound traffic and issues a time stamp when the leading bits of an IEEE 1588 PTP packet are identified, precisely marking the arrival or departure of PTP time packets. An example of a possible architecture is given below:
About the Author Antonis Karvelas is working for INTRACOM TELECOM, the largest multinational provider of telecommunications products, solutions and services of Greece. He is the company’s primary contact person for the Metro Ethernet Forum. He has over 10 years of experience in system design, protocol design and an intimate knowledge of L2 and L3 networks and technologies. He can be reached at This e-mail address is being protected from spambots. You need JavaScript enabled to view it , or +30-210-667-4753
Set as favorite
Bookmark
Email This
Hits: 13483 Trackback(0)
Comments
(4)
G.8264 specifies only two SSM codes (EEC1 ,EEC2) however other SSM values mentioned by G.781 (including DNU) are not included in G.781. My questions are:
Votes: +0
1. what is the reason for missing SSM values? 2. how can we achive SDH/SONET and Ethernet timing domains interworking with missing SSM? Thanks Ronen report abuse
vote down
vote up
You must be logged in to a comment. Please register if you do not have an account yet.
|
| Last Updated on Monday, 21 September 2009 20:24 |
Concerning the frequency synchronization the requirements are very strict. For example 3G UMTS systems required a tolerance of as little as 50 parts per billion in long term frequency accuracy. The official specification from 3GPP, TS25.104 Release 8 [5] mentions:
TrackBack URI for this entry
Subscribe to this comment's feed
