ustry or because the messages must be carried by a transport method that is already widely deployed. The Power Profile is one good example. See details of the Power Profile and other profiles in Chapter 7. For the following section, the focus is on the telecom profiles, but the principles apply to other cases and profiles trying to achieve accurate phase/time synchronization. PTP for Phase/Time Figure 9-10 illustrates the architecture for the carriage of phase/time over packet. The approach is for frequency, phase, and time to be taken from a time source (PRTC) and used by a grandmaster to send time information across a packet network. These signals are then recovered on the slave clock and used to synchronize the slave node and any associated application hosted there (represented here as a radio in a cell tower). SyncE SyncE Packet Packet network network PTP & (optional) Slave clock with end Optional boundary SyncE from T-GM application or transparent clock Grandmaster Figure 9-10 Phase/Time Synchronization over Packet Using PTP with Optional SyncE As you can see, the concept is simple, but there is a lot of detail involved in making it work well. The following sections of this chapter go through the major factors that contribute to a successful deployment. Many of the topics have been quickly covered in previous chapters, but this chapter will tie that background to specific choices when faced with a real implementation. The choice for a network timing engineer is very clear. If possible, a packet timing network should use the following approaches to distribute time: Utilize a full timing-aware network with timing awareness in every node (and the transport) and using the Layer 2 ITU-T G.8275.1 telecom profile. Distribute the timing infrastructure as much as possible. It is not recommended to deploy a couple of PRTC+T-GM in the center of the network and then attempt to run timing out to the furthest reach of the network over many hops. Use T-BC or Telecom Transparent Clocks (T-TCs) with G.8275.1 support embedded