Precise synch set to play big role in DOCSIS 3.0 deployments

As the technology, market and regulatory landscape continues to change for cable operators, they find themselves caught in a race against time with telco competitors. Assisting on the telco side: new optical networks combined with new copper modulation schemes–like 10 Mbps ADSL2+. For the cable side: the new DOCSIS 3.0 and its modular cable modem termination system (M-CMTS), with throughputs up to 160 Mbps.

Actually, time will help determine winners in more ways than one, with cable taking the current lead. New quad play services subscribers want (broadcast TV, IPTV, video-on-demand, voice-over-IP, and mobility) all have very precise timing requirements in the transmission or application layers. In the transport of PON (passive optical networks), DOCSIS, or wireless, if time-slots are misaligned across the cable with respect to a shared time reference, then modulators, switches, encoders, decoders, and other network elements can’t interpret data correctly. The result is likely to be loss of packets, service degradation, and unhappy subscribers.

So it’s not just a question of whose networks have more bandwidth–telco or cable–but also whose networks can better distribute a shared timing reference. What makes this harder is the on-demand quality of today’s services. Which services subscribers want now changes throughout the day, which means the right mix of various backend resources also changes–VOD QAMs versus data QAMs, for example. Functions that once shared the same backplane (and its internal timing signal) no longer will, so that operators can scale and configure functions independently. The result is that there will be a greater number of devices, all of which need access to the same external time reference–a number that will grow as fast or faster than the number of subscribers. That means that if timekeeping doesn’t scale as efficiently as the rest of the infrastructure, then that subscriber growth could also slow. So it really is a race against time.

Timing Is Everything Figure 1

Operators have eagerly awaited DOCSIS 3.0 precisely because it supports the higher bandwidths and greater flexibility the on-demand environment requires. But DOCSIS 3.0 is also a good example of the new synchronization challenges–and provides a good window into how best to master them.

The DOCSIS 3.0 specification is more than 1,500 pages long, but three features stand out:
Channel bonding: The bandwidth of multiple downstream data QAM channels can now be aggregated in support of the same service group–effectively providing up to 160 Mbps combined throughput–versus 10 Mbps for DOCSIS 1.1, and 30 Mbps for DOCSIS 2.0. Upstream channels may also be bonded.

Universal QAMs. The same QAM channel can serve as either a data channel or a VOD channel. This allows an operator to use the same resource for different services–say, for VOD during the evening and for data during the day. Capital costs are reduced because unused capacity can be tapped before additional equipment is purchased and also because the “general purpose” QAMs are less expensive than the “VOD-only” QAMs of earlier DOCSIS specs.

M-CMTS. A CMTS sends and receives traffic between the IP network (packets) and the cable plant (RF). It includes functions like MAC (media access control), downstream QAM modulation and RF conversion, and upstream QPSK/QAM demodulation. DOCSIS 1.1 and 2.0 bundled all these functions in one box. Modular CMTS specifies that the downstream QAM (and upstream receiver as well) can be separate from the CMTS “core”–on different shelves or in different racks. This allows the operator to scale up I/O capacity to serve more subscribers. In the M-CMTS model, an operator can add downstream capacity by simply adding a Universal EdgeQAM, whereas previously it would have had to purchase a CMTS line card. In the old integrated CMTS (I-CMTS), a line card was more expensive than adding an EdgeQAM, it was not interoperable, and it was bundled with upstream ports that often went unused.

What this means is that M-CMTS implementations–which for now decouple the downstream side only–must provide synchronization externally to EdgeQAMs and attached cable modems as well as to the M-CMTS core (integrated with upstream demodulation). Operators have always provided a timing reference to the QAMs and cable modems through the backplane of the I-CMTS. In an M-CMTS architecture, however, a common backplane does not exist since the QAMs now reside in several separate EdgeQAMs and in the M-CMTS core. Now, all EdgeQAMs and the M-CMTS core must be synchronized externally through the DOCSIS Timing Interface (DTI). As the number of QAMs increases, so will the number of connections that synch those QAMs with the headend’s DTI timing reference.

Timing Is Everything Figure 2

Why must all elements be synchronized? DOCSIS uses asynchronous time division multiple access (ATMDA) or synchronous code division multiple access (SCDMA) to share the same physical coax cable resource among hundreds of subscribers (Figure 1). Data and control signals move along a closed loop: downstream to subscribers and back again upstream to the headend. Each cable modem is given a time from the headend to transmit its data; hence, all cable modems must share a common time so they do not transmit at the wrong time.

In the M-CMTS, the DOCSIS Timing Interface ensures that the EdgeQAMs and M-CMTS core (with upstream demodulation) are aligned within five nanoseconds. This ensures that the timing sent to the cable modems from multiple EdgeQAMs is the same. The various cable modems lock to the timing information and align their transmissions to the M-CMTS core (and upstream) that are timed for the same DTI reference in the headend. DTI ensures that the M-CMTS is precisely synchronized, no changes to the cable modem are necessary, and the architecture can scale economically for new services.

A standalone single-shelf integrated CMTS (I-CMTS) DOCSIS 1.x, 2.x, or 3.x implementation supplies its own synchronization internally.

External synchronization in support of the M-CMTS introduces three additional key elements into the architecture: a timeserver, a client, and a protocol to synch the timeserver to the devices. That protocol is DTI, and every M-CMTS device includes a DTI client. As Figure 2 shows, DTI uses a point-to-point connection between a DTI server and each client. That connection consists of DTI frames containing time, frequency, position, status (e.g., “warming up”), and performance information (e.g., “phase noise”).

A DTI server must:

  • Deliver five-nanosecond precision reliably to the DTI client
  • Scale economically root server capacity, slave server capacity, and port density
  • Deliver synchronization to devices throughout the network–with GPS traceability
  • Support multiple devices (e.g., DTI for M-CMTS and NTP for IP networking).

The importance of reliability is self-evident. Unless devices stay in synch, the entire system will have to be resynchronized–forcing a system reset affecting all subscribers. Reliability is also an issue because there can only be one Root DTI server in a headend/hub. A DTI server could be a single point of failure. Most DTI servers address this by offering redundancy (without installing two servers) including redundant clock cards and power supplies.

Scalability is important because of the need for many individual point-to-point DTI connections. The more ports a DTI server has, the more devices it can support, allowing subscriber populations to grow. Because reliability is so important, operators may run two cables (preferably by different routes) between the DTI server and each client. If so, that reduces by half the number of clients that can attach to the server–and makes a large number of ports even more important.

Besides offering more ports, another way to scale a DTI deployment is if a DTI server can be operated as a Slave DTI server, a feature that allows a DTI server to synchronize to a Root DTI server, also increasing reliability and preventing downtime. A two-port DTI client can be connected to a root and a slave server (which is also synchronized to the root), so that if the root fails, the slave takes over. This configuration also allows operators to swap out a server or even reconfigure the timing architecture without taking down the whole system.

Scalability is achieved by adding more slave servers, each of which can potentially support the same number of clients as the root. It is important to note that there cannot be multiple roots in a single location. Since GPS only provides 100ns accuracy, it is not sufficient to meet the 5ns DOCSIS specifications. GPS is, however, appropriate for some architectures.

For example, GPS is a requirement for scaling synchronization across geographically dispersed sites. In GPS-based deployments, roots are synchronized to a common external parameter (time of day) or UTC (Coordinated Universal Time). Traceability to UTC means that timestamps in packets (like delay measurements and mapping) can be traceable within 100ns between different locations where both root servers reference GPS. GPS can also enable commercial services like T-1 circuit emulation by making DOCSIS synchronization traceable to a Stratum 1 source.

A DTI server can also contain other timing protocols to exploit the accuracy and reliability of the timing engine and the GPS connection. The obvious choice would be to support NTP (network time protocol) since it is the most popular way to synchronize computer clocks on enterprise networks and the Internet, and most systems have NTP clients built in. NTP and DTI timestamps can be used to establish the sequence events, which is helpful in applications like troubleshooting. And it also supports newer applications like VOD conditional access–like measuring time on movie rentals. NTP can also support a cable operator’s business systems, IT firewalls, internal e-mail, and other applications not directly involved in delivering content to cable subscribers.

DOCSIS 3.0 is good news for operators looking to quickly increase bandwidth, improve flexibility, enhance scalability and add new services. More good news: time is now on your side. The DOCSIS Timing Interface is designed to be self-configuring and simple to deploy. Properly architected, DOCSIS 3.0 M-CMTS synchronization is seamless, cost-efficient, and easy to do. That means one less roadblock in the race to offer “quad-play” services.

E-mail: Jeremy Bennington