English

IEEE 1588v2

Updated on Apr 11, 2024 by
159

What Is IEEE 1588v2

IEEE 1588v2, also known as Precision Time Protocol Version 2 (PTPv2), is a precision clock synchronization protocol designed for networked measurement and control systems. It is an industry standard released by IEEE to achieve high-precision time and frequency synchronization between devices. In comparison to the Network Time Protocol (NTP), IEEE 1588v2 offers sub-microsecond-level time synchronization precision by leveraging hardware timestamping. This makes it well-suited for meeting the time synchronization requirements of wireless base stations. PTPv2 has distinct advantages over the traditional GPS high-precision time synchronization solution, particularly in terms of cost, maintenance, and security. As a result, it has become the most popular time synchronization protocol in the industry.

What Is Synchronization?

Synchronization involves maintaining a specific relationship in frequency or phase between two or more signals, ensuring that their frequency or phase difference stays within an acceptable range at a valid moment. This concept encompasses both frequency synchronization and time synchronization.

  • Frequency synchronization, also called clock synchronization, establishes a precise relationship between signals based on a consistent frequency or phase difference. It ensures that signals are transmitted or received at the same average rate at a valid moment. Consequently, all devices within a communication network operate at an identical rate, maintaining a fixed phase difference between signals.

  • Time synchronization, also known as phase synchronization, focuses on maintaining consistent phases between signals. This implies that the phase or time difference between signals is always zero or remains within a specified range. Typically, achieving time synchronization requires prior achievement of frequency synchronization between the involved devices.

Why IEEE 1588v2 Is Needed?

In IP radio access networks (RANs), maintaining synchronized frequencies among base stations is crucial for seamless handoffs during mobile transitions. Some wireless standards, particularly those using time division duplex (TDD) mechanisms like TD-SCDMA, CDMA2000, LTE-TDD, and 5G NR TDD, demand not only precise frequency synchronization but also stringent time synchronization. These standards require time precision between any two base stations to be less than 3 μs, or the time difference between each base station and the standard time source to be within ±1.5 μs.

Traditional time synchronization methods include satellite-based solutions, where satellite antennas capture GPS or BeiDou signals, and NTP time synchronization, using network-side NTP servers. However, these methods face challenges such as installation complexities, high costs, and security risks. To address these issues, a terrestrial transmission solution is needed. IEEE 1588v2, implementing Precision Time Protocol (PTP) packet transmission through optical fibers or cables, offers a secure alternative. Leveraging hardware timestamping, IEEE 1588v2 achieves sub-microsecond-level time precision, meeting the strict ±1.5 μs precision requirements of wireless base stations. This makes it the prevailing time synchronization protocol in the industry.

How Does IEEE 1588v2 Implement Synchronization?

Synchronization Clock

In a time synchronization network, each node is referred to as a clock, and IEEE 1588v2 defines three types of clocks: Ordinary Clock (OC), Boundary Clock (BC), and Transparent Clock (TC).

  • The Ordinary Clock (OC) utilizes a single physical interface for network communication. It can serve as a grandmaster clock, distributing time to downstream clocks, or act as a slave clock, synchronizing time with an upstream clock. Typically, the 1588 server is configured as an OC in grandmaster mode, overseeing the entire network's time synchronization. User terminals, like wireless base stations, are often configured as OC in slave mode.

  • The Boundary Clock (BC) is equipped with multiple physical interfaces for network communication. It employs one interface to synchronize time with an upstream clock and utilizes other interfaces to distribute time to downstream clocks.

  • The Transparent Clock (TC) has multiple physical interfaces for network communication. While processing and forwarding 1588v2 (PTP) packets through these interfaces, a TC does not synchronize its time with any clock. TCs come in two types: End-to-End (E2E) TCs and Peer-to-Peer (P2P) TCs.

When forwarding 1588v2 packets, an End-to-End Transparent Clock (E2E TC) corrects packet forwarding delay, allowing OCs or BCs at both ends to calculate link delay and time offset for synchronization. A Peer-to-Peer Transparent Clock (P2P TC) not only corrects forwarding delay but also addresses the delay of the link connected to each interface, aiding OCs or BCs in determining time offset for synchronization.

Example of the hierarchical topology of OC, BC, and TC

Example of the hierarchical topology of OC, BC, and TC

IEEE 1588v2 network synchronization involves two main processes: establishing the master/slave hierarchy on the control plane and implementing frequency/time synchronization on the service plane.

  • Establishing the master/slave hierarchy: Within each clock domain, every Ordinary Clock (OC) or Boundary Clock (BC) determines its reference source and interface status (master/slave) using the Best Master Clock (BMC) algorithm. This algorithm relies on clock source information found in Announce packets from each interface. The overall synchronization network then establishes the master/slave hierarchy and tracing path.

  • Implementing frequency/time synchronization: Once the master/slave hierarchy and tracing path are set, the master and slave clocks exchange various event packets such as Sync, Delay_Req, and Delay_Resp. Through this exchange, the slave clock calculates the time offset between itself and the master clock, making adjustments to synchronize its time with the master clock. This process achieves frequency/time synchronization.

Synchronization Mechanisms

IEEE 1588v2 introduces two time synchronization mechanisms: E2E (End-to-End) and P2P (Peer-to-Peer). In a 1588v2-enabled network, the master clock can establish a connection with the slave clock directly or through intermediate clocks. Both E2E and P2P mechanisms quantify the total link delay between the master and slave clocks, but they do so in different manners:

The E2E mechanism gauges the complete link delay encompassing all intermediate Transparent Clocks (TCs) between two Ordinary Clocks (OCs) or Boundary Clocks (BCs).

On the other hand, the P2P mechanism exclusively measures the hop-by-hop link delay between two directly linked OCs, BCs, or TCs, excluding any intermediate clocks along the path.

E2E Mechanism:

Within the E2E mechanism, the synchronization process involves the exchange of Sync, Delay_Req, and Delay_Resp packets between the master and slave clocks. This enables the slave clock to compute the time offset relative to the master clock and make necessary adjustments for synchronization. The master clock has the flexibility to transmit a Sync packet in either one-step or two-step mode. In the one-step mode, the Sync packet contains the sending timestamp, whereas in the two-step mode, the Sync packet records only the sending time, with the sending timestamp included in the Follow_Up packet.

P2P Mechanism:

Contrasting with the E2E mechanism, the P2P mechanism treats each clock as equal, without a clear distinction between master and slave clocks. Each clock engages in the exchange of P2P packets with its adjacent clock, facilitating the calculation of the link delay between them. Similar to the E2E mechanism, clocks can choose between one-step or two-step modes for packet transmission. In one-step mode, a Pdelay_Resp packet includes the sending timestamp, while in the two-step mode, the Pdelay_Resp packet lacks the sending timestamp, which is instead recorded in the subsequent Pdelay_Resp_Follow_Up packet.

You might be interested in

See profile for undefined.
FS Official
Load Balancing
See profile for undefined.
FS Official
Malware
See profile for undefined.
FS Official
Orthogonal Architecture