Network Processor Offloading PTP Processing Load

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The computational power of processors running the PTP protocol stack in boundary clocks is limited, especially when unicast transport is used, restricting the number of slave clients that can be supported, and existing technologies do not efficiently manage the high processing load of time-critical PTP messages.

Innovation Solution

Moving higher-rate, lower-touch PTP packet processing functions from the PTP Protocol Engine to a network processor, reducing the general-purpose processor's burden and improving fan-out capabilities by offloading repetitive message generation and management tasks to a network processor unit.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If unicast transport is used for PTP messages to each slave client, then time synchronization precision is improved, but the computational load on the processor increases significantly

Engineering Contradiction:
Improvetime synchronization precisionVSAvoidcomputational load
Core Design Contradiction:
Measurement precisionVSPower

Solution Approach 1:

The patent segments PTP message processing into two distinct paths: unicast transport for time-critical event messages (Sync, Delay_Req, Follow_Up, Delay_Resp) to maintain precision, and multicast transport for non-time-critical general messages (Announce, management messages) to reduce computational load. This segmentation allows the system to apply different transport mechanisms based on message type requirements.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system dynamically selects transport mode based on message type characteristics. Time-critical messages automatically receive unicast treatment with precise timestamping, while general messages use multicast transport. This dynamic approach optimizes the balance between synchronization precision and processor utilization based on real-time message requirements.

Inventive Principle:
Principle #15Dynamics

2Reliability

If unicast transport is used for all PTP messages, then communication reliability is improved, but the number of supported slave clients is limited

Engineering Contradiction:
Improvecommunication reliabilityVSAvoidnumber of supported slave clients
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent divides PTP message traffic into two categories with different transport requirements: time-critical event messages that require unicast for reliability and precision, and general messages that can use multicast to support more clients. This segmentation enables the system to maintain high reliability for critical operations while scaling to support a larger number of slave clients through efficient multicast transport for non-critical messages.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system changes the transport parameter (unicast vs. multicast) based on message type parameters. Time-critical messages maintain unicast transport parameters for reliability, while general messages switch to multicast parameters to increase client capacity. This parameter-based approach allows flexible adaptation to different communication requirements.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If the PTP protocol stack is processed entirely by the general-purpose processor, then protocol flexibility is maintained, but processing speed decreases

Engineering Contradiction:
Improveprotocol flexibilityVSAvoidprocessing speed
Core Design Contradiction:
Adaptability or versatilityVSSpeed

Solution Approach 1:

The patent segments PTP protocol processing into two functional groups: time-critical event message processing that requires high-speed dedicated hardware paths, and general message processing that maintains processor-based flexibility. This segmentation allows critical time-path messages to be processed at line rate with precise timestamping while general messages continue to use the flexible but slower processor-based approach.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system introduces a message classification intermediary that directs different types of PTP messages through appropriate processing paths. Time-critical event messages are routed through high-speed hardware paths with dedicated timestamping, while general messages are handled by the general-purpose processor. This intermediary mechanism enables the system to achieve both high processing speed for critical messages and protocol flexibility for general messages.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP2817902B1Method and network node for processing a precision time protocol
Publication Date: 2019.04.10 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • EP2817902B1 patent drawingFigure 1
  • EP2817902B1 patent drawingFigure 2A
  • EP2817902B1 patent drawingFigure 2B

AI summary

In a data network node implementing the Precision Time Protocol, low-touch PTP packet processing functions are moved from a PTP processing unit into an efficient network processor. An example network node thus includes a time -transfer protocol processing unit that generates negotiation messages and management messages for a time-transfer protocol and forwards said negotiation and management messages to one or more clients. The network node also includes a separate network processor unit, which is adapted to: receive a configuration message from the time-transfer protocol processing unit, the configuration message comprising stream configuration data for a first type of repetitive time -transfer message; generate a plurality of time-transfer messages according to the first type of repetitive time -transfer message, using the stream configuration data; and forward said plurality of time-transfer messages to the one or more remote network nodes, via the one or more line ports.