 in every network element, with a certified performance level (certainly for noise generation) from G.8273.2 (for T-BC or T-TSC) and/or G.8273.3 (for T-TC). Combine PTP phase/time with SyncE or, if possible, enhanced SyncE (G.8262.1) to carry fre- quency in what is called hybrid mode. Use a PTP-aware transport system, which aims to reduce asymmetry as far as possible and con- trols any generation of PDV. Avoid (unless necessary) the use of G.8275.2 telecom profile over unaware nodes. If its use cannot be prevented, then its use must be very limited in scope because there is no control over how well even a single unaware hop will treat the timing signal as it passes through. The best approach in these circumstances is to run G.8275.1 as far as possible and then use profile inter- working to convert it to G.8275.2 at the last hop (see Chapter 11 on profile interworking). Design a timing solution around budgeting time error, not as a networking exercise. There is much more on budgeting in the section "Budgeting End-to-End Time Error" later in the chapter. The engineer needs to know how accurate the phase and frequency must be when needed at the application, and then figure out how to get time delivered to it within that time error budget. For details of each of these factors, see the following three sections. Chapter 11 will further expand on this chapter with a specific focus on the 4G and (especially) 5G radio applications. To avoid re- petition, the details of some aspects are more thoroughly covered in Chapter 11. Even if mobile syn- chronization is not your problem, there are lessons to be learned from an industry that needs micro- second-level timing accuracy across the whole country, even on remote mountaintops. 9.1.1 Full On-Path Timing Support Versus Partial Timing Support "Chapter 8. ITU-T Timing Recommendations", deals with the ITU-T recommendations that cover the network topology and requirements, detailing the form and topology of network suitable for a PTP deployment. One case is a network that is full