Synchronous Signals Over Asynch Networks

Wes Simpson

Many useful types of signals are synchronous, meaning that they use bit patterns that are transmitted using a built-in, fixed-frequency clock signal. Uncompressed digital video and audio signals are synchronous, as are important telecommunications signals used in SONET and SDH networks. Typically, these signals have very tight tolerances on their clock rates, and require a high level of stability in the time base of the delivered signal that is measured over both long (wander) and short (jitter) time scales.

Aside from the obvious multicamera video and multichannel audio transport applications, synchronous signals can be used to distribute complete ATSC or DVBT payloads to multiple broadcast antennas spread across a geographic area used in single frequency network configurations. Synchronous signals are also used for delivering voice and data services to mobile telephone base station antennas for 3G and 4G/LTE systems.

In both these applications, the traditional solution was to construct a costly SONET or SDH system that connected to every transmitter site. As packet networks have continued to drop in price, the economic incentives to create synchronous signal transport solutions that can work over asynchronous packet networks have become compelling.

For synchronous signals to be received correctly at their destination, the transport network must deliver the signals without causing clock distortions. Such distortions can be difficult to manage in a packet network, because the signal must be divided up into discrete blocks of data.

Delay variation (also called packet jitter) can affect the clock references contained in the transported packets, by making it more difficult for the receiver to reconstruct the accurate time base needed to generate an output. New transport standards can make this task easier.

TRANSPARENT SONET OVER PACKET
TSoP is a relatively new technology that is the subject of an IEFT draft. It allows complete SONET and SDH streams containing both payload and overhead to be transported over packet networks. This mechanism can be used to transport a wide variety of signals—essentially anything that can be placed inside a SONET transport stream. The list of compatible signals includes many types of voice and data protocols, and covers the entire range of compressed and uncompressed digital video formats. RTP (Real Time Protocol, RFC 3550) packet headers are used to provide timestamps. A system constraint that helps to improve clock recovery is the use of fixed-size packets for each installation; for example, 810 octet (byte) packets are used for STM-1/OC-3 signals, generating exactly 24,000 packets per second.

Fig. 1: Network using TSoP to provide video camera synchronization over a wide-area packet network This is a big technical advance over previous systems based on RFC 4842, which transported only virtual channels as individual packet streams. One drawback of RFC 4842 is that it discards the SONET line and section overhead, which are used to control the signals and report errors to downstream devices. This method also removes the precise timing information that is built into the overall SONET payload, forcing receivers to derive any needed clocking information from another source.

Synchronization in TSoP installations works by using a common clock signal that must be connected to devices at both ends of the packet network. This external reference allows both the packet stream generator and receiver to work from a common time base. With timestamps inserted into the packet headers at the generator, and suitably sized buffers in the receiver, clock behavior that complies with the SONET standards can be achieved.

There are several ways to provide a common clock to both ends of the circuit. One potential mechanism would be to use Synchronous Ethernet between the source and destination. Unfortunately, this method only works with distance-limited, Layer-2 networks that have the necessary hardware upgrades at every switch or router location to support this function.

Another method would be to loop time each end of the network to an external SONET link, but this only works when both ends of the system are connected to SONET networks, which isn’t practical for many video applications.

The best external clock is a Global Positioning System (GPS) receiver built into an Ethernet switch at each network termination that feeds signals to the packet stream generator or receiver. Fig. 1 shows this arrangement, with adapters used to convert video signals into packet streams shown at each end of a circuit. This arrangement shows cameras on both ends of the link connected to a common time base, allowing live switching between the streams. In addition, an external time server provides a common video sync function across the network.

Beyond providing excellent clock stability, the external reference also acts as an independent reference that prevents longterm drift from accumulating. In the event that the packet stream is interrupted, the external clock also allows re-synchronization much more quickly than what could be achieved with an in-band clock that required long settling periods over extended packet sequences. In addition, time-base correctors for video signals may not be needed.

Thanks to Pete Gilchriest of ARG ElectroDesign for his technical commentary.

Wes Simpson is an industry consultant and author of “Video Over IP, Second Edition,” from Focal Press. Your comments are welcome towes.simpson@gmail.com.

Wes Simpson

Wes Simpson is President of Telecom Product Consulting, an independent consulting firm that focuses on video and telecommunications products. He has 30 years experience in the design, development and marketing of products for telecommunication applications. He is a frequent speaker at industry events such as IBC, NAB and VidTrans and is author of the book Video Over IP and a frequent contributor to TV Tech. Wes is a founding member of the Video Services Forum.