Keeping track of the exact time¶
For DECT-based systems to allow for seamless roaming, it is necessary that the clocks of all antennas are synchronized.
PTPv2 is the protocol used to synchronize the clock between Green-GO STRIDE DECT antennas via the network.
PTPv2 Best Practices¶
- All switches that interconnect Green-GO STRIDE antennas need to have PTPv2 capability and have it enabled.
- Whenever possible, use the default PTPv2 settings.
- Be aware of other PTPv2 systems in your network. Connecting a high-priority clock into a running system can disrupt current DECT connections.
A Short Introduction into PTPv2 and Its Terms¶
PTPv2 (Precision Time Protocol Version 2) is an IEEE standard (1588-2008) that provides precise synchronization of clocks in a networked system. Below are key concepts and terms essential to understanding PTPv2.
Best Master Clock Algorithm¶
The Best Master Clock Algorithm (BMCA) is a mechanism used by PTPv2 to automatically select the most suitable clock as the Grandmaster in a network. This process is critical because only one Grandmaster clock should be active per domain to ensure seamless synchronization.
The selection considers several factors, including:
- Clock quality.
- Priority settings.
- Clock class and accuracy.
The BMCA operates dynamically, ensuring the most qualified clock becomes the Grandmaster if the current Grandmaster becomes unavailable or a better clock is introduced.
Synchronization¶
Synchronization in PTPv2 involves multiple message exchanges to ensure all devices in the network share the same notion of time. The key steps include:
- Sync Messages: Sent periodically by the Grandmaster clock to provide a time reference.
- Follow-Up Messages: Used to correct the sync message timing with precise information about when the sync message was sent.
- Delay Request/Response Messages: Exchanged to measure and compensate for the network delay between the Grandmaster and a device.
By continuously exchanging these messages, the clocks in the network align their time to the Grandmaster, achieving precise synchronization.
The Role of Switches Within PTPv2¶
Switches play a critical role in the implementation and efficiency of PTPv2 (Precision Time Protocol Version 2) within a network. They influence how time synchronization messages are propagated and handled, directly affecting the performance and stability of the system. Green-GO STRIDE supports networks using both Transparent Switches and Boundary Switches, each of which offers unique advantages.
Transparent Switches¶
Transparent Switches are designed to forward PTPv2 messages (such as Sync, Follow-Up, and Delay Request/Response) without altering the time synchronization process, but they add a vital enhancement:
They measure the time it takes for messages to traverse the switch and add this information (known as the residence time) to the PTPv2 messages. This ensures that downstream devices can account for the delay introduced by the switch, maintaining highly accurate time synchronization.
Key Features¶
- Minimal disruption: The switch does not participate as a clock in the PTPv2 hierarchy. It simply forwards PTPv2 messages with added timing information.
- Reduced complexity: Transparent switches do not need to run the Best Master Clock Algorithm (BMCA).
- High accuracy: By compensating for internal delays, they ensure that network-induced latency is minimized.
Best Practices¶
- Use Transparent Switches in networks where multiple Green-GO STRIDE antennas are connected and where simplicity is preferred.
- Ensure that the switch is fully PTPv2-compliant and capable of handling the traffic loads without bottlenecks.
Boundary Switches¶
Boundary Switches act as PTPv2-aware devices that terminate the timing domain on one side and initiate a new domain on the other side. In this role, the switch itself becomes a participant in the PTPv2 hierarchy, often functioning as a boundary clock within the network.
Key Features¶
- Domain separation: Each side of the boundary switch operates in its own timing domain, allowing for better isolation and control.
- Clock participation: The switch runs the BMCA to determine whether it should act as a Grandmaster clock, a Slave clock, or pass timing information downstream.
- Scalability: Ideal for large or complex networks, where clock distribution needs to be segmented or isolated to prevent timing conflicts.
Best Practices¶
- Use Boundary Switches in networks where multiple timing domains or mixed timing requirements exist.
- Ensure that the switches are properly configured to participate in the BMCA and that the correct clock priorities are set for your network's requirements.
STRIDE and Switch Support¶
Green-GO STRIDE supports both Transparent and Boundary Switch configurations, offering flexibility for different network topologies and timing needs. Whether you choose to deploy Transparent or Boundary Switches depends on the size, complexity, and specific timing requirements of your network.
Recommendations¶
- For smaller, simpler networks with a single timing domain, Transparent Switches provide a straightforward and efficient solution.
- For larger networks or scenarios involving multiple timing domains, Boundary Switches offer the necessary segmentation and control.
Regardless of the switch type, ensure that all network switches are PTPv2-capable and properly configured to handle PTPv2 traffic. Both Transparent and Boundary Switches must be carefully selected and tested to avoid potential disruptions in time synchronization.
PTPv2 Settings¶
Warning: Changing PTPv2 Settings is usually never necessary. It is even likely to make the system less stable if there is no FULL understanding of the result in behavior when changing any of the parameters.
We strongly advise to use the DEFAULT PTPv2 Settings and only adjust the settings with a deep understanding of their effect and only if a specific problem or challenge needs to be resolved.
In 99% of the cases, the default settings will be the best possible settings.
The available PTPv2 advanced settings, defined by the IEEE 1588-2008 standard, and their Green-GO defaults are described below.
PTPv2 Profile¶
The PTPv2 Profile defines how the protocol behaves in a specific use case. Green-GO STRIDE antennas use the AES67 profile, which is well-supported and commonly used in the industry. While Green-GO does not directly utilize AES67, this profile is compatible with STRIDE.
At present, only the AES67 profile is supported. Please let us know if you have a use case requiring alternative profiles.
PTPv2 Domain¶
Within a network, multiple domains, each with its own Grandmaster clock, can coexist. Different domains operate independently and do not synchronize with each other. It is essential to ensure that all Green-GO STRIDE antennas in a system are within the same domain to avoid degradation of the DECT RF space.
Multiple systems, whether Green-GO DECT, third-party DECT, or other time-sensitive network protocols, can share the same Grandmaster clock and domain, ensuring optimal performance.
PTPv2 Priority 2¶
The Priority 2 setting determines the relative importance of a clock when multiple potential Grandmasters exist in the network. Lower values indicate higher priority.
This setting works in conjunction with the BMCA and other attributes to select the most suitable Grandmaster clock for the domain.
PTPv2 Settings for STRIDE¶
The following PTPv2 settings are used by Green-GO STRIDE antennas. Not all properties are user-configurable, as some are defined by the profile.
Basic Configurable Properties¶
Property | Default Value | Allowed Values |
---|---|---|
Profile | AES67 | AES67 |
Domain | 0 | 0 to 255 |
Priority 2 | 128 | 0 to 255 |
Advanced (Non-Configurable) Properties¶
Property | Default Value | Possible Values |
---|---|---|
Priority 1 | 128 | 0-255 |
Announce Interval | 2 Seconds | 1 to 16 Seconds |
Sync Interval | 0.125 Seconds | 0.125 to 2 Seconds |
Delay Request Interval | 1 Second | 0.135 to 32 Seconds |
Announce Timeout Factor | 3 | 2 to 10 |
- Although Green-GO does NOT utilize AES67, using the PTPv2 AES67 profile is perfectly suitable for use with STRIDE and is well-known/available in our industry. At present, we only support the AES67 profile for STRIDE. Please let us know if you have a use case or requirement for other profiles or settings.