Verifying The Acr Configuration Of T1 Interfaces For Satop - Cisco ASR 900 Series Configuration Manual

Benefits of ACR for 8 T1/E1 Interface Module
Follow a similar procedure to configure to configure CEM ACR for E1 Interfaces for SAToP. Also, follow
Note
a similar procedure to configure CEM ACR for T1 and E1 Interfaces for CESoPSN. Use cem-group
circuit-id timeslots <1-24> | <1-31> command instead of cem-group circuit-id unframed command for
the configuration depending on T1 or E1 controller.
To remove the clock configuration in ACR, you must remove the recovery clock configuration in global
configuration mode, then remove the CEM circuit, and finally remove the clock source recovered configuration
under the controller.

Verifying the ACR Configuration of T1 Interfaces for SAToP

Important Notes
• When multiple ACR clocks are provisioned and if the core network or PSN traffic load primarily has
fixed packet rate and fixed size packets, the states of one or more ACR clocks might flap between
Acquiring and Acquired states and might not be stable in Acquired state.
This happens because of the "beating" phenomenon and is documented in ITU-T G.8261 - Timing and
synchronization aspects in packet networks.
This is an expected behavior.
• After an ACR clock is provisioned and starts recovering the clock, a waiting period of 15-20 minutes
is mandatory before measuring MTIE for the recovered clock.
This behavior is documented in ITU-T G.8261 Timing and synchronization aspects in packet networks
Appendix 2.
• When the input stream of CEM packets from the core network or PSN traffic is lost or has many errors,
the ACR clock enters the HOLDOVER state. In this state, the ACR clock fails to provide an output
clock on the E1/T1 controller. Hence, during the HOLDOVER state, MTIE measurement fails.
This is an expected behavior.
• When the clock output from the clock master or GPS reference flaps or fails, the difference in the
characteristics between the holdover clock at the source device and the original GPS clock may result
in the ACR algorithm failing to recover clock for a transient period. The MTIE measurement for the
ACR clock fails during this time. After this transient period, a fresh MTIE measurement is performed.
Similarly, when the GPS clock recovers, for the same difference in characteristics, ACR fails to recover
clock and MTIE fails for a transient period.
This is an expected behavior.
• When large-sized packets are received along with the CEM packets by the devices in the core network
or PSN traffic, CEM packets may incur delay with variance in delay. As ACR is susceptible to delay
and variance in delay, MTIE measurement may fail. This behavior is documented in ITU-T G.8261
section 10.
This is an expected behavior.
• For a provisioned ACR clock that is in Acquired state, if the ACR clock configuration under the
recovered-clock global configuration mode is removed and then reconfigured, the status of the ACR
clock may initially be ACQUIRED and not FREERUN and then move to Acquiring. This happens
because the ACR clock is not fully unprovisioned until the CEM circuit and the controller clock source
1-Port OC-192 or 8-Port Low Rate CEM Interface Module Configuration Guide, Cisco IOS XE Everest 16.7.x
(Cisco ASR 900 Series)
136
Clock Recovery System for SAToP