Synchronization in microwave networks

Transcription

1 Synchronization in microwave networks Technology White Paper Network transformation, driven by IP services and Ethernet technologies, presents multiple challenges. Equally important to introducing a packet-transport solution in an SDH/SONET network is meeting TDM- or packet-based synchronization requirements. In mobile networks, 3G/LTE mobile technologies with multiple traffic types and synchronization requirements must find common ground for a cost-effective solution. Using a synchronization and timing-distribution strategy based on the interworking of IEEE 1588v2 and ITU-T Synchronous Ethernet, and ensuring synchronization continuity that leverages existing SDH/SONET networks, the Nokia 9500 MPR platform guarantees carrier-class transport while reducing the need for external synchronization sources. This paper explains the functionality and benefits of the synchronization technologies and describes how the Nokia 9500 MPR uses them in mobile backhaul networks. 1 Technology White Paper

2 Contents 1. Introduction 3 2. Today s synchronization challenges: setting the scene 3 3. Microwave use cases 5 4. Focus on synchronization distribution via IEEE 1588v Conclusion Acronyms Contacts References 18 2 Technology White Paper

3 1. Introduction Convergence toward a packet-transport network is widely discussed by mobile network operators who are aiming to seamlessly carry their existing TDM traffic while scaling to handle higher capacities and new IP services and technologies, such as the one needed by 4G/5G technologies. While targeting network transformation, most operators are focused on interoperability with the existing installed base. The usage of native IP/Ethernet base stations requires a new paradigm for timing distribution and synchronization. Industry-recognized ITU-T Synchronous Ethernet (SyncE) and IEEE 1588 Version 2 (1588v2) Precision Time Protocol (PTP) work synergistically, with a high degree of accuracy, to address synchronization in packet networks. Nokia Microwave Packet Radio platforms are designed to offer synchronization based on SyncE and 1588v2, complementing line-clock distribution to offer a flexible, high-performance solution that satisfies the most stringent synchronization requirements and is tailored for mobile applications. Multiple advantages result from this implementation design: SyncE is key for addressing native IP/Ethernet base stations to ensure their evolution to packet-transport backhaul networks. 1588v2 is delivered to obtain packet-based frequency synchronization as well as phase synchronization. Support of line-clock distribution ensures synchronization continuity, leveraging existing networks. The Nokia 9500 Microwave Packet Radio (MPR) provides a unique solution for mobile backhaul, enabling transformation to all-ip traffic and supporting a mix of synchronization solutions to meet current mobile-access generations as well as future generations such as Long Term Evolution (LTE) and 5G. 2. Today s synchronization challenges: setting the scene One of the challenges network operators face while approaching network convergence toward a packet-switched infrastructure is effective frequency and time distribution. The requirements for synchronization distribution vary because multiple services and applications coexist. In mobile backhaul networks, different technology generations Second Generation (2G): TDM, Third Generation (3G): ATM/Ethernet, Fourth Generation (4G): IP/Ethernet are delivered over the same transport network. 3 Technology White Paper

4 While offering similar end-user services, these mobile technologies have different synchronization requirements. For example, time accuracy (phase) is required in CDMA, UMTS, TDD, LTE TDD, and WiMAX, but it is not needed in GSM or UMTS FDD. A carrier-class backhaul network must be able to meet the synchronization requirements of all the services it supports, regardless of the technologies it uses to transport and deliver them. The Nokia 9500 MPR product family supports a full range of local and endto-end network synchronization solutions for a wide variety of applications. Regardless of the technology used as the synchronization source, synchronization at the far end of the network can be delivered using any of the ingress/egress options. Possible synchronization sources are: embedded radio link synchronization, Synchronous Ethernet, 1588v2, E1/T1 PDH line clock, STM-1 SDH/SONET OC-3, BITS (synch-in/synch-out ports). The first three in the list are the most interesting when looking at current and future Ethernet and packet networks; let s have a closer look at them. 2.1 Embedded radio link synchronization At the core of the 9500 Microwave Packet Radio technology is an inherent ability to transport a synchronization signal across the radio link. This is referred to as symbol rate and allows a pair of 9500 MPR devices to relay a network clock reference from one site over a microwave link to another site. This capability allows for an extremely reliable end-to-end synchronization distribution plan and interoperates with the other mechanisms described below. 2.2 Synchronous Ethernet ITU-T SyncE technology is designed to distribute a reference frequency on the physical layer of an IEEE network. Built using the foundation provided by SDH/SONET synchronization, SyncE delivers the same level of performance, allowing the seamless introduction of an element in an existing SDH/SONET network. SyncE and SDH/SONET must connect all nodes in a timing domain that relies on a physical-layer synchronization technology. 2.3 IEEE (1588v2) IEEE , also known as 1588v2 or PTPv2, is a protocol designed to distribute time and/or frequency across networks. Unlike SyncE, which is a physical-layer technology, IEEE1588v2 is a packet-layer technology, so it can work across a network that includes nodes that do not directly support the technology. This specific functionality makes it easier to introduce IEEE 1588v2 in existing networks. 4 Technology White Paper

5 Because IEEE 1588v2 is a packet-layer technology, it may be subject to performance impairments that are caused by packet queuing and scheduling delays due to congestion in the packet network. IEEE 1588v2 s On Path Support (OPS) mechanisms (transparent-clock and boundary-clock capability) compensate for these effects so that the protocol can provide the accuracy and precision required for even the most demanding telecommunications network applications. Another means of mitigating these possible effects and improving performance is to use IEEE 1588v2 together with SyncE and/or SDH/SONET. 3. Microwave use cases This section presents two synchronization-distribution use cases: mobile backhauling and vertical applications. Most of the technical discussion covers mobile backhauling, the most important application for microwave. A short use case addresses the emergence of a demand for microwave in strategic markets. 3.1 Mobile backhauling The most common scenario is characterized by the availability of a time source at the ingress of the microwave backhaul network, derived from the primary reference clock (PRC). Synchronization (frequency) is delivered to the cell-site SyncE, 1588v2, E1/T1 line clock, SDH line clock or sync-in/sync-out ports. If time of day (ToD) is required, such as for LTE TDD, IEEE 1588v2 is adequately serviced by the Nokia 9500 MPR, guaranteeing the support for the appropriate service level. Figure 1 shows the distribution flow of synchronization in a typical microwave network. Figure 1. Network clock distribution Sync distribution Service clock DCR Synchronous Ethernet SDH PRC Network clock phase 1588v2 for ToD 1588v2 for frequency Network clock frequency SyncE E1/T1 PDH STM-1/OC-3 BITS L1 sync L1 sync SyncE E1/T1 PDH STM-1/OC-3 BITS SyncE SDH Cell site Microwave tail Microwave hub Microwave handoff Aggregation network Service node with master clock 5 Technology White Paper

6 In case base stations require frequency synchronization only, at the handoff site the microwave equipment typically connects to a SyncE or SDH-synchronized network. A key advantage of the Nokia 9500 MPR is its capability of connecting to a full ITU-T G.803 [9] synchronized chain, carrying synchronization inbound from the radio channel to the microwave network tails and regenerating the SDH or SyncE signal toward the base stations. Configuration of the synchronization source to be delivered to cell sites is dictated by the site connectivity. Any of the available options can be made available regardless of the synchronization-source type. The emulated services all derive their synchronization information from the network clock, as shown in Figure 1. The service clock is therefore perfectly aligned with the network clock and provides maximum precision for recovery of the original stream at the egress of the backhaul network. Each E1/T1 circuit can recover the clock independently from the others, maintaining synchronicity with the native stream. If base stations require ToD sync and ToD synch distribution needs to be implemented via the backhauling network, then E1/T1/SDH line clock and SyncE are no longer sufficient and ToD synch distribution via 1588v2 is typically used. In this case the network elements building the backhauling network are often requested to provide some form of on-path support. Please refer to section 4 Focus on synchronization distribution via IEEE 1588v2 for more details. 3.2 Vertical applications Some vertical applications require clocking with stringent accuracy. One example is a rail operator that is looking to migrate its GSM Railway (GSM-R) network infrastructure from SDH to IP/Ethernet transport. To enable the rapid migration of these networks, SyncE and IEEE 1588v2 in some cases may be an easy, quick way to achieve frequency synchronization for the internal communications network, allowing the benefits of Ethernet transport without changing the TDM voice application. Traditionally supported on an SDH network, GSM-R is a secure platform for voice and data communications between railway operational staff. GSM-R base stations need to be fed with the synchronization of E1 circuits. The Nokia 9500 MPR is ideal for supporting the continuity of frequency distribution when moving from SDH to SyncE aggregation because the variation of ingress synchronization is handled using a pure configuration command. 6 Technology White Paper

7 4. Focus on synchronization distribution via IEEE 1588v2 Defined in IEEE Std (1588v2), PTP is a protocol that distributes frequency, phase and time over packet-based networks. The IEEE 1588v2 protocol is being used more and more for distribution of high-accuracy time v2 PTP basics PTP uses an exchange of four timestamps between a reference clock (master port) and the clock to be synchronized (slave port). A simplified illustration of this mechanism is shown in Figure 2. Figure 2. PTP messages and timestamp exchange Master t1 Sync (t1) Slave Data at slave t4 Optional follow up (t1) Delay_Req () t2 t3 t1, t2 t1, t2, t3 Delay_Resp (t4) t1, t2, t3, t4 The master sends a PTP Sync message containing a timestamp of when the Sync message is transmitted (t1) to the slave. In a two-step master clock, the t1 timestamp is sent in a Follow_Up 1 message. The slave records the time it receives the Sync message (t2). At some point after receiving the Sync message, the slave sends a Delay_Req message back to the master. The slave records the time of transmission of the Delay_Req message (t3) locally. The master records the time it receives the Delay_Req message (t4) and sends this timestamp back to the slave in a Delay_Resp message. 1 Note the Follow_Up message was defined to allow for implementations to generate a timestamp for the transmission of the Sync message but not have to try to insert that timestamp into the Sync message and update any frame checksums on the fly as it is in the process of transmission. While many recent implementations can perform the timestamping, update and checksum calculation on the fly, not all devices could perform this three-step process with the desired accuracy. By using the Follow_Up message to transmit the timestamp of the Sync message, the master port can still provide extremely accurate timestamps for the transmission of the Sync message to the slave port. Apart from the extra message required, there is no detriment to a master port using one-step clock versus two-step clock procedures. All PTP clocks that have slave port capability must accept timing information from both types of master port. There is no requirement to force a clock that is a one-step clock to use two-step clock procedures on its master ports. The nodes covered by this example all support one-step clock master port procedures. 7 Technology White Paper

8 After the four-timestamp exchange the slave can calculate the mean path delay and the clock offset from master using the following two equations: mean_path_delay = [(t4-t1) (t3-t2)] /2 offset_from_master = [(t2 t1) mean_path_delay] These calculations can occur on every message exchange or some initial packet selection can be performed so that only optimal message exchanges are used. The latter is useful if there is variable delay between the master and slave ports. If only frequency is necessary, then the slave may use one or both pairs of timestamps (t1, t2) and (t3, t4). The slave can monitor the change in the perceived delay master-to-slave (t2 - t1) or slave-to-master (t4 - t3) over time. If the delay (t2 t1) decreases over time, it means the t2 timestamps are not progressing quickly enough and the slave clock frequency needs to be increased. If time is necessary, then all four timestamps must be used. It is also important to note how the equation for offset uses the mean_path_delay. If the delays in the two directions are actually different, then the equation will introduce an error in the offset_from_master that is half of the difference of the two delays. The IEEE 1588v2 standard includes procedures to compensate for this asymmetry, if it is known, but if it is uncompensated it does introduce time error. 4.2 PTP deployment architectures It is important to understand that there are very different topologies recommended for using 1588v2 for frequency distribution and using 1588v2 for time distribution. Frequency distribution was developed for an architecture where there are mobile providers who have points of presence at the mobile telephony switching offices (MTSOs) and the cell site locations that depend on other parties for the connectivity between the MTSOs and the cell site locations. The mobile providers wanted a solution that could span the transport networks with minimal dependence on that network. This can be achieved by placing a 1588v2 grandmaster at the MTSO and a slave in the last transport equipment or directly in the base station and distributing the timestamped packets between the two, as shown in Figure 3. The transport network does introduce packet delay variation (PDV) to the 1588v2 messages, which makes it more difficult to track the frequency of the grandmaster s clock. However, the slaves have been designed to perform packet selection and noise filtering to allow for the recovery of a frequency within the required accuracies of the mobile base stations. This architecture and the performance requirements are covered by the ITU-T G.826x series of recommendations. 8 Technology White Paper

9 Figure v2 topology for frequency distribution Transport network with no 1588v2 support Slave clock Grandmaster clock For time distribution, it has been recognized that the architecture used above is extremely unlikely to be successful. The fundamental reason is that the performance requirement is much tighter and the network introduces not only PDV but also potentially asymmetric delay, which causes time error in the slave. The topology recommended for time distribution is what is sometimes referred to as full On-Path Support (OPS). Full OPS means that every network element between the grandmaster clock and the slave clock is either a 1588v2 boundary clock or a 1588v2 transparent clock, as shown in Figure 4. Boundary clocks and transparent clocks process the 1588v2 messages and remove the PDV noise that would be present in a non-1588v2 network element. By using network elements that have very tight constraints on the time error they introduced, the network can be built to guarantee time accuracy under all network traffic conditions. This architecture and the performance requirements are covered by the ITU-T G.827x series of recommendations. Figure v2 topology for time distribution Slave clock Boundary clocks or transparent clocks Grandmaster clock 4.3 PTP profiles The 1588v2 standard includes the concept of a PTP profile. A PTP profile allows standardization bodies or industry groups to adapt the 1588v2 standard to a particular application. A profile defines which aspects of the 1588v2 standard are included or excluded, along with configurable ranges and defaults necessary for the application. The 1588v2 standard itself includes a default profile that can be used for either time or frequency distribution. The default profile was defined principally for multicast operation. However, it can be used with the unicast sessions as described below. The default profile supports all 1588v2 clock types and includes the Best Master Clock Algorithm (BMCA) that automatically builds the synchronization distribution hierarchy among the PTP clocks. 9 Technology White Paper

10 In the telecommunications industry, the ITU-T is the body that develops these profiles. They have generated a profile for frequency distribution (G ) and a profile for time distribution (G ). The frequency profile permits only grandmaster and slave clocks and can be used to extend a traditional physical layer synchronization distribution (SDH/SONET, PDH, or SyncE) with a final leg of 1588v2 messages. The frequency source of the 1588v2 grandmaster could be a GPS receiver, a central office BITS or SASE device or it could use the frequency recovered from a SyncE or SDH/SONET interface. This is shown in Figure 5. Because a 1588v2 distribution system for frequency is noisier than a physical layer distribution system, it should only be used as the final segment to connect the end application into the synchronization network. If possible, it should not be used to connect two SyncE or SDH/SONET islands. Figure 5. Frequency distribution with 1588v2 in the final segment GNSS T1/E1 or SyncE Transport network with no 1588v2 support Mobile basestation Slave clock Grandmaster clock BITS/SASE SyncE or SDH/SONET distribution chain The important features defined in the G profile are: Only master clocks and slave clocks are allowed Unicast Message Negotiation using Signaling messages from the slave clocks toward the master clocks is used to establish communications PTP messages are encapsulated over User Datagram Protocol (UDP) over IPv4. PTP clock class values are based on a mapping of traditional quality levels from SSM/ESMC. 2 2 SSM stands for Synchronization Status Message and ESMC stands for Ethernet Synchronization Messaging Channel. These are two capabilities in SDH/SONET and SyncE respectively for the relaying of source clock quality information. 10 Technology White Paper

11 The slave clock uses an alternate BMCA to select the grandmaster clock from the available master clocks based on: Quality level Relative priority. The ITU-T has defined the first time distribution profile in G It uses an architecture of a Global Navigation Satellite System (GNSS)-based grandmaster clock distributing time through a chain of boundary and transparent clocks to a final slave device and end application. It includes the use of SyncE and 1588v2 at the same time for optimal performance. Physical layer SyncE is an excellent tool for the distribution of an accurate and stable frequency. This frequency can be used to advance time between offset adjustments made using the 1588v2 information. 4.4 Network limits A common concern around 1588v2 is whether it will work on or over a specific customer network. For time distribution using full OPS as shown in Figure 4, there are well-defined limits on the number of network elements allowed in the distribution chain (see below). However, for the frequency distribution using the architecture shown in Figure 3, it is a more difficult question to answer. There are so many different types of network elements and inter-node links that a simple limit on the number of network elements is not adequate. What has been specified is a limit to the noise that the network can introduce to the 1588v2 message flow between the grandmaster and slave clocks. This noise occurs as Packet Delay Variation (PDV). The following sections provide some description of this PDV and a new metric that has been defined for PDV as well as the recommended limit to PDV for 1588v2 deployments Packet Delay Variation (PDV) If the packet delay through the packet network is constant, then it is relatively easy to use a series of timestamp exchanges to remove the delay as an unknown and track the master clock frequency. However, in most network technologies, the packet delay will be different for each individual packet. This PDV makes it more difficult to track the master clock since observations have both the master information and PDV noise included. PDV is introduced when packets get placed in queues before they are forwarded. The time each packet sits in any one queue is influenced by multiple factors: Speed of the interface toward which the queue drains, for example 100 Mb/s versus 100 Gb/s Traffic load on the interface, for example 20% versus 100% of line capacity 11 Technology White Paper

12 Distribution of packet sizes and priorities in the traffic load toward the interface Underlying physical technology used, xpon, xdsl, Ethernet, or microwave. In addition, the load and packet distribution within the load will vary over time so the distribution of the PDV can shift rapidly, such as when a network event triggers congestion, or slowly, for example as end customers gradually come online over a period of several hours. Also there are pipeline effects that can occur in a chain of queuing devices, where the small timing packets can catch up to a large packet moving across the network. Once behind such a packet, the timing packet can remain stuck behind that packet on all subsequent transmit queues. QoS prioritization of packets helps reduce PDV significantly during congestion periods, but does not remove the PDV effects during lighter loading. This is due to the fact that a timing packet may be delivered to the egress queue for an interface while the interface is busy transmitting a packet. Pre-emption of packet transmissions is not used in today s networks. Even with all of the above, most of the time the network will still present a percentage of packets that get across the network with minimal queuing delays. These are often referred to as lucky or fastest packets. Since these lucky packets are never waiting in queues or have minimal wait times, their transit across the network is relatively consistent. By running a selection filter on all 1588v2 packets to find these lucky packets, a level of variation of network delay can be removed or reduced significantly. Then the slave clocks have a much easier time determining the frequency of the grandmaster. However, there will always be a limit to the amount of PDV that can be tolerated. The ITU has defined a metric to quantify the PDV, the limit of the PDV for a compliant network, and the required tolerance of a slave clock PDV metrics In order to know whether a particular timing-over-packet implementation will meet the performance targets in a given network deployment, it is desirable to both characterize the limits on the PDV that the implementation can tolerate and measure the network against these limits. In 2012, the ITU-T published three documents that address these requirements: G.8260 defines the Floor Packet Percentage (FPP) metric G defines a network limit for PDV in terms of FPP G.8263 defines the input tolerance expected of a 1588v2 frequency slave in terms of FPP 12 Technology White Paper

13 The FPP metric provides an indication of the guarantee that there are packets experiencing minimal delay across the network. The rationale behind this focus on fastest packets is that many networks do provide good consistency of these packets in most operating conditions and most slave clocks are capable of operating using only the information from these fastest packets. There are four parameters associated with the metric: W is the width of the windows used to monitor for the presence of fastest packets. Floor Delay is a value that is as close as possible to the absolute minimum transit delay across the network. Every actual delay measurement must be equal to or larger than this value. δ is the range above the floor to be analyzed for the presence of fastest packets. ρ is the percentage of all the packets received in a window whose delay must be within the range floor delay to floor delay + δ. Figure 6 illustrates how these parameters and the metric work. First the delays of all individual 1588v2 packets are plotted over the period of observation. Next the observation period is broken down into a series of consecutive windows of width W seconds. Then for each window a count is made of all the 1588v2 packets whose delays are within the range floor delay to floor delay + δ and this count is compared with all the 1588v2 packets received during the window to turn the count into a percentage. Finally the percentage of each window is checked against the threshold percentage ρ. For the FPP metric to be met, every window must have a percentage greater or equal to the threshold. If even one single window does not meet this threshold then the metric condition is not met. Figure 6. Floor packet counting for FPP (n, W, δ) Packet delay Floor delay + δ microseconds Floor delay across network Must contain at least ρ% of packets received during the window Time Window width W seconds Note: This metric is not perfect as it does not take into account slaves that use other aspects of the packet delay distribution (such as average delay), nor does it discuss the impact of reroutes, nor do the limits discuss how to apply these limits to the forward and backward message exchanges at the same time. However, it was agreed that this metric was a good start for the definitions of the network and slave limits. Expect to see timing test equipment vendors providing the tools to generate 1588v2 PDV profiles providing FPP-based distributions. 13 Technology White Paper

14 4.4.3 ITU-T budget for frequency The network limit on PDV for frequency distribution is defined in G using the FPP metrics defined above. In general, most carrier-grade networks with spans of up to ten nodes and which do not exceed 80% load on their internode links should meet the requirement. However, very low (sub-50 Mb/s) shaping or very long networks or last mile technologies such as xdsl or xpon may need to be studied to determine their acceptability. A general strategy for rolling out 1588v2 frequency distribution is to evaluate the specific grandmaster and slave pairing in a lab environment using a network emulator to introduce controlled PDV. Once the grandmaster and slave have passed the lab tests, then field trial locations should be identified. Ideally, the sites should include locations where the PDV of the network will likely be at its worst. These would be sites with the most intervening network elements between the grandmasters and the slaves and include segments of the network that have a high load. The slaves clocks should be deployed and monitored over several days to ensure that their frequency recovery engines can maintain lock with the grandmasters. During the initial field trails, it is beneficial to use external frequency test equipment at the slave locations to accurately monitor the frequency generated out of the slaves and ensure it stays within limits. As more sites are evaluated and confidence in the PDV environment increases, more deployments can be rolled out. In the deployed network, PTP frequency recovery slave states can be monitored to ensure the solution continues to work. There may be some locations in the network where the PDV will be too large, preventing the slaves to achieve or maintain lock. If it is possible to utilize an alternate network interface to obtain a frequency such as a leased T1 or E1 interface, then that could be used. A last resort would be the deployment of a GNSS receiver at the location to provide the frequency reference ITU-T budget for time The ITU-T has defined in recommendation G a topology for time distribution based on a full OPS environment. This means that every network element in the time distribution chain is a 1588v2 clock of some type. The original version defined an environment using boundary clocks, while the latest version foresees the usage of boundary clocks and transparent clocks. The ITU-T tackled the time distribution problem in a more traditional way when compared with the frequency distribution. The ITU-T first defined specific network element clock performance constraints and then defined a longest chain network permitted to ensure that the solution meets the endto-end budget. The portion of this budget allocated to transport equipment is in the range of 1 µs (G ). 14 Technology White Paper

15 The link asymmetries are an important aspect of this budget. The network topology not only has to have the network elements that meet the clock specifications but it also needs to have links that meet certain requirements. As explained above, the time offset calculation makes the assumptions that the master to-slave latency is the same as the slave to-master latency. When the latency is not equal, an error is introduced. Some analysis of network intersite connections may need to be performed to determine the budget for the link asymmetries. 4.5 Performance with 9500 MPR The performance of ToD synch distribution via 1588v2 over a chain of 9500 MPR links has been evaluated in a lab environment, exploring the different working conditions and assessing simultaneously the residual ToD errors experienced by a reference 1588v2 ToD slave. Full OPS was used on 9500 MPR network elements. Multiple impairments have been applied during the measurement campaign: Variable rates of user traffic up to overload conditions have been transmitted in parallel to 1588v2 frames Variable channel fading has been inserted to stimulate Adaptive Modulation changes from the minimum modulation format to the maximum applicable modulation format Presence/absence of radio link aggregation (radio LAG) Variable number of 9500 MPR links in the chain. Figure 7 represents one outcome of the tests on the residual ToD error after a chain of four 9500 MPR links; here total residual ToD errors are typically smaller than 250 ns. Figure 7. Residual ToD error after a chain of four 9500 MPR microwave links 500 Residual ToD error (ns) Time (s) Technology White Paper

16 5. Conclusion The trend of network transformation to packet-based network infrastructures has not eliminated the need for or importance of synchronization in networks. Instead, new challenges and requirements for tools and technology have emerged. The fundamental target remains the same: to provide efficient technology to enable operators to develop their networks according to their preferred pace and direction. Nokia Microwave Packet Radio platforms embody synchronization technologies in an integrated solution, allowing easy network transformation from TDM to the packet world and synchronization continuity as the network evolves. The support of standard clock-reference distribution methods and the use of market-recognized leading solutions such as SyncE and 1588v2 guarantee flexibility in network design and definition of the best strategy for operators moving toward all-ip backhauling. 6. Acronyms 9500 MPR Nokia 9500 Microwave Packet Radio 2G, 3G, 4G Second Generation, Third Generation, Fourth Generation ATM BITS BMCA BTS CDMA DCR E1 enodeb ESMC FDD FPP GNSS GPS GSM Asynchronous Transfer Mode Building Integrated Timing Supply Best Master Clock Algorithm base transceiver station Code Division Multiple Access differential clock recovery E-carrier system Evolved Node B Ethernet Synchronization Messaging Channel Frequency Division Duplex Floor Packet Percentage Global Navigation Satellite System Global Positioning System Global System for Mobile Communications 16 Technology White Paper

17 GSM-R IDU IEEE ITU-T LTE MPLS MTSO NTP ODU OPS PDH PDV PoE PRC GSM - Railway Indoor Unit Institute of Electrical and Electronics Engineers International Telecommunication Union Telecommunication Standardization Sector Long Term Evolution Multiprotocol Label Switching mobile telephony switching office Network Time Protocol outdoor unit On-Path Support Plesiochronous Digital Hierarchy Packet Delay Variation Power over Ethernet Primary Reference Clock PTP Precision Time Protocol (IEEE 1588v2) SASE SDH SONET SSM Stand Alone Synchronization Equipment Synchronous Digital Hierarchy Synchronous Optical Network Synchronouzation Status Message STM-1 Synchronous Transport Mode 1 SyncE T1 TDD TDM ToD UMTS Synchronous Ethernet T-carrier system Time Division Duplex Time Division Multiplexing Time of Day Universal Mobile Telecommunications System WiMAX Worldwide Interoperability for Microwave Access (IEEE ) 17 Technology White Paper

18 7. Contacts For more information about Nokia 9500 MPR solutions, please visit or contact your customer team representative. You can also contact Nokia Product Marketing or Product Management: Olivier Guéret Product Marketing - olivier.gueret@nokia.com James Ries Product Line Manager - ANSI, james.ries@nokia.com Andrea Sandri Product Line Manager - ETSI, andrea.sandri@nokia.com Roberto Valtolina Product Line Manager - ETSI, roberto.valtolina@nokia.com References 1. IEEE : IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 3: Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. 2. IEEE : IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. July 24, IEEE 1588v2: Clock Synchronization in Telecommunications via PTP (IEEE 1588). June ITU-T G.8261: Timing and synchronization aspects in packet networks. 5. ITU-T G.8262: Timing characteristics of synchronous ethernet equipment slave clock (EEC). 6. ITU-T G.8264: Distribution of timing information through packet networks. 7. Time and Frequency Distribution over Packet Switched Networks. Bell Labs Technical Journal, Volume 14, Issue 2. DOI: /bltj.20377, (pp. 131 to 153). August Technology White Paper

19 8. ITU-T G.707 (1996): Network node interface for the Synchronous Digital Hierarchy (SDH). 9. ITU-T G.803 (2000): Architecture of transport networks based on the Synchronous Digital Hierarchy (SDH). 10. ITU-T G.811 (1997): Timing characteristics of primary reference clocks. 11. ITU-T G.812 (1998): Timing requirements of slave clocks suitable for use as node clocks in synchronization networks. 12. ITU-T G.813 (1996): Timing characteristics of SDH equipment slave clocks (SEC). 13. ITU-T G.823 (2000): The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy. 14. ITU-T G.825 (2000): The control of jitter and wander within digital networks which are based on the synchronous digital hierarchy (SDH). 15. IEEE at (2009) Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications Amendment 3: Data Terminal Equipment (DTE) Power via the Media Dependent Interface (MDI) Enhancements 16. ITU-T G.8265: Architecture and requirements for packet-based frequency delivery 17. ITU-T G : Precision time protocol telecom profile for frequency synchronization 18. ITU-T G.8275 : Architecture and requirements for packet-based time and phase distribution 19. ITU-T G : Precision time protocol telecom profile for phase/time synchronization with full timing support from the network 20. Draft ITU-T G : Precision time protocol telecom profile for phase/ time synchronization with partial timing support from the network Nokia is a registered trademark of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. Nokia Oyj Karaportti 3 FI Espoo Finland Tel (0) Product code: PR EN Nokia 2016 nokia.com