IEEE Std 802.1AS-2020 pdf download
IEEE Std 802.1AS-2020 pdf download.IEEE Standard for Local and Metropolitan Area Networks-Timing and Synchronization for Time-Sensitive Applications.
NOTE I—A time-aware system can change the value of delayAsyrnmetry during operation (see 14.8.10, 14.16.8, and Annex G).
NOTE 2—A time-aware system PTP Port cannot measure the value of delayAsyrnmetry during live operation of the system (i.e., asyrnrnetryMeasurernentMode is FALSE; see 10.2.5.2); therefore, the value of delayAsymmetry must be defined separately using information from the supplier or additional testing before running the live system. The methods for measuring asymmetry are not specitied in this standard. These values can be added to the system configuration to improve the accuracy of time synchronization. The inaccuracy caused by asymmetry is half the value of the difference between tri and ti,., and these inaccuracies can either accumulate over successive hops or, if the successive asymmetries have different signs. cancel each other over the successive hops.
8.4 Messages
8.4.1 General
All communications occur via PTP messages and/or media-specific messages.
8.4.2 Message attributes
8.4.2.1 General
All messages used in this standard have the following attributes:
a) Message class
b) Message type
The message class attribute is defined in this clause. The message type attribute is defined in 3.18. Some messages have additional attributes; these are defined in the subclauses where the respective messages are defined.
8.4.2.2 Message class
There are two message classes, the event message class and the general message class. Event messages are timestamped on egress from a PTP Instance and ingress to a PTP Instance. General messages are not timestamped. Every message is either an event message or a general message.
8.4.3 Generation of event message timestamps
All event messages are tirnestamped on egress and ingress. The timestamp shall be the time, relative to the LocaiClock entity (see 10.1) at which the message timestamp point passes the reference plane marking the boundary between the PTP Instance and the network media.
The definition of the timestamp measurement plane (see 3.33), along with the corrections defined as follows, allows transmission delays to be measured in such a way (at such a low layer) that they appear fixed and symmetrical to gPTP even though the MAC client might otherwise observe substantial asymmetry and transmission variation. For example, the timestamp measurement plane is located below any retransmission and queuing performed by the MAC.
NOTE 1—If an implementation generates event message timestamps using a point other than the message timestamp point, then the generated tirnestamps should be appropriately corrected by the time interval (fixed or otherwise) between the actual time of detection and the time the message timestamp point passed the reference plane. Failure to make these corrections results in a time offset between PTP Instances.
NOTE 2—In general, the timestamps can be generated at a tirnestamp measurement plane that is removed from the reference plane. Furthermore, the timestamp measurement plane. and therefore the time othet of this plane from the reference plane. is likely to be difierent for inbound and outbound event messages. To meet the requirement of this clause, the generated timestamps should be corrected for these offsets. Figure 8-2 illustrates these offsets. Based on this model the appropriate corrections are as follows:
egressTimestamp = egressMeasuredTimestamp + egressLatency
ingressTimestamp = ingressMeasuredTimestarnp — ingressLatency
where the timestamps relative to the reference plane, egressTirnestamp and ingressTimestarnp, are computed from the timestamps relative to the timestamp measurement plane. egressMeasuredTimestamp and ingressMeasuredTimestarnp, respectively, using their respective latencies, egressLatency and ingressLatency. Failure to make these corrections results in a time offset between the slave and master clocks.
