 normal environmental conditions spe- cified for the equipment. This Recommendation includes noise generation, noise tolerance, noise transfer, and transi- ent response for APTS and PTS clocks. The APTS and PTS architectures are defined in G.8271.2, and the resulting synchronization deploy- ment assumes the use of the G.8275.2 PTP telecom profile. Physical sources of frequency (such as SyncE) are optional for PTS in this recommendation, and they are not used for APTS. This recommendation (in combination with G.8271.2) defines the requirements for both boundary and slave clocks in both the FTS and APTS architectures. So, it specifies these clock types: T-BC-A: Telecom Boundary Clock with assisted partial support T-BC-P: Telecom Boundary Clock with partial support T-TSC-A: Telecom Time Slave Clock with assisted partial support T-TSC-P: Telecom Time Slave Clock with partial support This recommendation includes the following main topics and appendix: Performance requirements for T-BC-A and T-TSC-A, which includes maximum absolute time error (max|TE|), constant time error (cTE), filtered dynamic time error (dTE), noise tolerance, noise transfer, transient response, and holdover Performance requirements for T-BC-P and T-TSC-P with a similar range of values to the assist clock case Appendix III, "Consideration on the use of synchronous equipment clock to maintain time hold- over for partial timing support networks" APTS is specifically designed for short-term holdover scenarios when the primary GNSS source is lost and a backup PTP source is temporarily unavailable. It is not appropriate to assume that the APTS will provide accurate long-term holdover or deliver accurate timing under double failure con- ditions (such as subsequent rearrangements in the unaware network). A new version of G.8273.4 was consented at the March 2020 plenary. Link to recommendation: https://handle.itu.int/11.1002/1000/14214 8.4.1 Telecom Profiles The most frequently consulted recommendations are those that cover the three main telecom pro- file