ologies ITU-T G.781 Option SSM QL PTP clockClass Option I Option II QL-PRS QL-STU QL-PRC QL-ST2 QL-SSU-A QL-TNC QL-SSU-B QL-ST3E QL-ST3/QL-EEC2 QL-SEC/QL-EEC1 QL-SMC QL-PROV QL-DNU QL-DNU Source: ITU-T G.8265.1, Table 1 This example is given to show the flexibility in working with the standards to ensure that difficult network problems can be addressed simply with the tools available to you. Of course, this only demonstrates that the signal can pass from end to end and that the mapping of QL will be faithfully reproduced. But it does not mean that the frequency signal will meet the application requirements when it arrives at the desired location. There will be time error introduced at every step of the path, SO it is the responsibility of the timing engineer to ensure that the frequency quality metrics all meet the requirements. Note that sometimes you may run across the profile in some equipment known as Telecom 2008. This is a pre-standardized version of the telecom profiles based loosely on the default profiles, but which very closely resembles G.8265.1 (or G.8275.2). The authors frequently encounter it in use by mobile operators that are doing mostly frequency synchronization over packet, although it can work in the phase scenarios. See Annex A of IEEE 1588-2008 for details. 9.1.1 Packet-Based Phase Distribution It is now time to move on from distributing frequency based on packet transport to phase/time dis- tribution using the same techniques. In fact, a lot of the details have some commonality; if anything, the phase/time case is a superset of the frequency case, meaning that it is much the same, but harder. There are a limited number of options available to run accurate phase/time across a packet-based transport network, and just about all of them involve some flavor of PTP. There might be slightly different implementations of PTP; for example, a specific industry may mandate a profile that uses a purpose-built type of communication method. That requirement might be based on a situation unique to that ind