Article 1963 of comp.dcom.telecom.tech: Newsgroups: comp.dcom.telecom.tech Path: mri-gw!psinntp!psinntp!psinntp!spunky.RedBrick.COM!wetware!sgiblab!pacbell.com!att-out!cbnewsh!kab From: kab@cbnewsh.cb.att.com (kenneth.a.becker) Subject: Re: Clocking? Organization: AT&T Distribution: na Date: Tue, 12 Apr 1994 04:47:31 GMT Message-ID: Summary: Here's some answers References: Lines: 115 kevin@kevind.army.mil (Kevin der Kinderen): > What exactly is Stratum 1 timing? Is this a clock signal that should > be present on my T1? We are > having problems with some muxes we recently purchased and are told > that we may need to provide > an external Stratum 1 timing. > > Why would I have to provide my own timing? Do both sites need exactly > the same clock or can one > site sync both sites? What are some examples of the proper equipment > that will provide Stratum 1 > timing? > > Thanks for any help, post here if appropriate or e-mail me. > > Kevin > mtimpn@baileys-emh2.army.mil > Sir: Well, as a real-life developer of Stratum 2 and Statum 3 systems, maybe I can answer some of your questions. First of all, let's consider just what you need timing for. The telephone network is considered to be "plesiochronos". What this means for T1 lines, say, is that they are all supposed to have an average frquency of 1.544 MHz, on the nose. If a T1 link is being clocked a little fast or a little slow, eventually that link is going to overrun or underrun the receive elastic store. This is defined as a "slip". A slip causes garbage on the line for at least one 125 usec period while things get realigned. Too many slips and the T1 link will get into red CGA (carrier group alarm), and the link will be lost. With this in mind, all digital CO gear has the ability to derive their system clocks from external timing references. These references may be T1 lines, E1 lines, or various types of sine and square waves. Now, when I say derive, you had better think "phase locked loop". Frequency locked loop might be a better term, since it's not the abolute phase that matters so much as the absolute frequency. Further, the widgets that "derive" the timing are not your average phase locked loop. For one thing, they have a state most PLL's don't dream of: holdover. If a backhoe takes out your favorite timing reference coming into your CO, you don't want the frequency of your local timing reference to take a hike. Doing so would, in some cases, put all the T1 links in your CO out of business. Instead, the PLL (or, more commonly, Synchronizer) has a mode where it attempts to hold the last known good frequency when its references are gone. Now, when you're in lock, the PLL's in your typical Stratum 3/4 are accurate to the network frequency to parts in 10e-12. If you lose lock, Stratum 3 clocks guarantees (at lease, they do if they follow Bellcore) no more than 255 slips per hour. Stratum 2 guarantees no more than 1 part in 10e-10 per day of frequency drift. Note that these are >>drift<< numbers. Bellcore's absolute accuracy (i.e., just how far are you allowed to get off frequency, for >>any<< reason) call for +-9 parts in 10e-6 for Stratum 3 and 1.6 parts in 10e-8 for Statum 2. I'm not too sure about the requirements, if any, for Stratum 4 (which is what your MUXs probably are), but they're much poorer than Stratum 3. There are additional specifications on MTIE (Maximum Time Interval Error), but we'll leave that for another day. In essence, this means that losing the references for a Stratum 3 node will get that node in trouble (i.e., T1 lines going into CGA) in no more than an hour or so. A Stratum 2 system might take a day or so before anybody really begins to noice. Stratum 4 drops dead right away. For Stratum 1... Note that I have not mentioned Stratum 1 as of yet. This is because Stratum 1 systems are >>really<< accurate. Statum 4 synchronizers use as an internal reference a junky $10 TTL oscillator. Stratum 3 usually uses mid-range ovenized quartz. Stratum 2 are either >>really<< good quartz or rubidum oscillators. Stratum 1 timing references (somehow, I can't bring myself to call these "synchronizers") typically consist of a triple of cesium/hydrogen maser oscillators. Triple so 2-out-of-3 voting can be done on the system when an oscillator goes down. With one of these systems, it's fairly immaterial what the external reference is, since you're not likely to get a slip in 10 years. The NBS in Boulder (or is it Ft. Collins?) runs Stratum 1 references. So do some of the BOC's. Most nations have a source of Stratum 1 somewhere. They cost serious money to buy, install, and maintain. In the US, most medium-to-large CO's keep a Stratum 2 synchronizer handy to time the entire office, which consists mainly of stratum 3 nodes. Note that Stratum 2 and Stratum 3 sync's are at least duplex in hardware and duplex in timing (each piece of a sync must be able to see at least two external references). There are nasty Bellcore requirements as to the failure modes and rates of such systems. The CO's themselves get diverse Stratum 2 references from other CO's. Another common method is to pick off timing from the GPSS system. The GPSS's main purpose is to provide location on the face of the Earth; however, in order to operate, it needs stable clocks. The GPSS gets its clocks from the National Bureau of Standards; a suitable (read, expensive!) receiver with the appropriate amount of filtering and hardware backup can be used to source timing for the CO's Stratum 2. Now, what do >>you<< need? Note that the local BOC is (or is supposed to be) timed to the network at large. If you have multiple (hopefully diverse) T1 links to the BOC, you may have all the timing you need. If you have a lot of internal connections that you care about, and the external world is less important, then Stratum 2 or 3 is the way to go. If you have a fair amount of money and some stringent requirements on timing, then think about that GPSS receiver and some hardware to time from it. I believe that SONET networks have other requirements as well; unfortunately, I don't know that much about them. Ken Becker kab@hotsc.att.com DACS II Hardware Development