Before DOCSIS 3.0 and before modular CMTS architectures, a CMTS existed in one chassis. Life was much simpler for everyone. Inside the chassis existed a 10.24 MHz clock or oscillator. This was a master time keeper that kept every event in synchronization with every other event. Timing is very important in communications networks, especially when dealing with the microsecond timing calculations necessary for DOCSIS transport - remember the "tick" (6.25 usec). This article is going to address the DOCSIS Timing Interface Specification (DTI) and DTI time servers that have arisen due to the distributed architectures in M-CMTSs and DOCSIS 3.0 CMTSs. In these architectures, it is possible to have the CMTS core in say the headend, with the eQAM and upstream receivers in remote hubsites. Suddenly the single 10.24 MHz clock keeping the system in synchronization is no longer an option. Three separate, free running 10.24 MHz clocks would also not work because they would not be in phase and would not be running at the same frequency, causing the entire system to out of synchronization - there would packet collisions and lost data and VoIP packets all over the place. It would be chaos! So the smart folks at Cablelabs put together the DTI specification to resolve these issues. Here are some of the details. The following is taken from Figure 1-1 in the DOCSIS Timing Interface Specification located both on the Cablelabs website and in the Library.
This diagram illustrates several important details. First, there is a primary DTI server, called the Root Server. The DTI root server provides a 10.24 MHz clock source. Second, there is (actually it is strongly recommended) a DTI Slave Server. The DTI slave server is nothing more than a redundant 10.24 MHz clock that monitors the root server. In the event that the root server should fail, the slave server will automatically provide a 10.24 MHz reference clock to all sources. The current vendor of DTI servers has the provisions in their firmware to monitor root and slave, providing for minor and major alarms when there are problems with the servers. The DOCSIS DTI Specification also also defines the method by which the root and slave communicate with each other over the IP network, so be certain to provision all timing servers. Next, the DTI servers provide 10.24 MHz clock sources to the eQAM, the CMTS and the upstream receivers. As indicated at the beginning of this article and in this diagram, all three of these devices can be physically located in different buildings. Since it is not practical to run very long CAT5 cables between Headends and Hub sites, DTI time servers are installed in each location. Synchronization of time servers between the locations is recommended (though not required). The way that the time servers are synchronized is via the GPS (Global Positioning Satellite) antenna port on the time servers or network streams. The time servers synchronize themselves to the global time server signal originating from the GPS satellites, ensuring that every time server connected to a GPS is synchronized to within 100 nsec of every other time server in the network. If the GPS option is not used, it is recommended to use a network-based source such as PDH, SONET, or equivalent. In addition to being a highly accurate time source, the DTI server can also function as an NTP (Network Time Protocol) server for the cable modems and other devices in your network. This will provide IP devices with the time of day during the DHCP process. This is a function of the Symmetricom time servers, which at the time of this writing, is the only game in town for getting time servers. But their equipment works quite well and I have found both their technical support and RMA departments quite competent. To dive a little deeper into the implementation end of things, here are some considerations that one should consider when setting up DTI servers:
The DTI Server can support three modes of operation:
In M-CMTS, deployment where all the elements are located in the same area GPS traceability is not required. The DTI server should be connected to all devices. For distributed applications, the DTI Specification states (in items #2 and #3 above) that a GPS or network traceable source must be used if the network shows degradation as measured over a 35 second period of time. What types of degradation is the DOCSIS specification looking for? At the very minimum, the specification states a BER of <1e-8, but it further details requirements for synchronization jitter, timing, skew, etc. So it is important to understand that just good BER is not an indication that the system is meeting adequate timing. Other timing impairments could be present which will impact voice and video that will not impact data only applications. In summary, DOCSIS 3.0 with DTI servers has upgraded the timing in DOCSIS networks from a Tier 3, low end timing service to a much higher end, telco quality service. Using a DTI server in collocated M-CMTS architecture provides for a Tier 2 timing service with 5 nsec of timing resolution between the devices. Using multiple DTI servers between remotely distributed devices in an M-CMTS architecture traceable to network or GPS timing elements provides for a Tier 1 timing service with 100 nsec accuracy between each device. This is unprecedented timing accuracy in our continuously improving DOCSIS networks enabling evolving service offerings with enhanced quality of service and quality of experience.