CDMA and Leap Seconds
Bruce Penrod
keeps time would be welcome. As most of you are aware, each basestation
in the system must maintain absolute synchronization to GPS time to the
10 us level in order to keep from interfering with the other
basestations. To do this, each has a GPS timing receiver with high
stability oscillator, either quartz or rubidium. This so as to be able
to maintain that level of sync even during hours of holdover after the
antenna has been shot off the tower.
UTC time is not used by the CDMA system for obvious reasons, e.g.
leapseconds. The GPS timescale is strictly monotonic. However, in
order to make the phones show the correct local time, embedded in the
sync channel message which all basestations broadcast continuously, is
the value of the UTC offset to GPS time and the local offset to UTC,
i.e. timezone. However, since these offset values do not affect the
operation of the mobile phone system, great care was not taken to
implement the changeovers rigorously.
Though until now there have been no leap second insertions since we
began shipping our CDMA based products, we have had over the years a
handful of customers report basestations transmitting leap second values
that were off by one second. In response, three years ago we created a
user enterable leap second mode for our CDMA products to allow
overriding the system transmitted value if necessary. This mode also
included the ability to set up the future leap second value prior to the
next insertion so as to be independent of the behavior of the
basestation. This has all been well documented in the product manuals
and a webpage dedicated to leap seconds has been maintained continuously
on our site to show the current and future values of the leap second so
that customers may easily determine how to configure their boxes.
When the IERS Bulletin C arrived in July, we updated our website and
notified via e-mail all CDMA product customers of the impending leap
second, and recommended that all users operate their NTP servers in the
user leap second mode. All NTP servers we shipped after July 1 were
preconfigured to user leap second mode with the current and future leap
seconds set appropriately.
We are pleased to announce that our GPS NTP servers and our CDMA NTP
servers configured in user leap mode performed the leap properly this
afternoon. We are aware that some of the cellular basestations set the
leap second a day early, and some PCS basestations have still not set
it. We regret that some customers apparently had not configured their
NTP servers to operate in user leap second mode, and apologize for any
problems this might have caused.
Unfortunately, judging from the other recent posts, it appears to me
that the long dearth of leap seconds may have resulted in a step
backwards in the proper handling of leap seconds. Many products that
had been debugged back when we were having regular leap second events
have been replaced by new ones that have no experience with them. I'm
not optimistic that we'll ever have a ho-hum leap second event with all
posting to say how smoothly everything went.
If we're lucky, we'll get rid of the pesky things before there's another
one...
Bruce Penrod
EndRun Technologies
Marc Brett
>
>If we're lucky, we'll get rid of the pesky things before there's another
>one...
>
>Bruce Penrod
>EndRun Technologies
Be careful what you wish for, and all that.
It's clear from early reports that the leap second event didn't go smoothly
everywhere. Eg. my Lidl weather station clock, synched to DCF77, didn't leap on
time and had to be manually kicked to listen for the new signal. My home PCs
(Windows 98SE/Dimension 4 and IRIX 6.5.22/ntpd-...@1.829) didn't leap at
midnight, and neither, apparently, did my ISP's server (ntp.demon.co.uk, synched
to tock.usno.navy.mil), though by morning they all seemed OK.
How has this muddled leap into the new year affected systems in the real world?
Has real money been lost? Lives? Has air traffic control had near misses?
GLONASS satellites gone south, as they did so mythically in 1997?
David L. Mills
Your candid explanation is much appreciated. On the other hand,
everybody else got it right and your unit didn't. There is an obvious
remedy here. If your unit implements Autokey, and it does implement just
about everything else, it could run in TAI and deliver the UTC offsets
in an extension field. I would be happy to collaborate on an RFC to that
effect.
Dave
Eric Jensen
First of all, there were quite a few glitches surrounding the
leap-second, many of them not related to CDMA or your products.
I apprectiate your explanation of the problem, but I have a different
point of view in a couple of areas. As an affected Endrun CDMA clock
user, I have the following comments.
My base station apparently started transmitting the new TAI-UTC offset
one day early. Or, perhap one could say it started transmitting the
new offset during the last day of the year, expecting that all users
of the signal understood it was only to be applied at the next UTC
midnight?
You have the manual setting available to override the transmitted
offset, which you referenced in your post and also in the support
bulletin. I actually came into the office to make the manual
adjustment six hours before midnight UTC, and discovered that my clock
had been off for 18 hours already. Your support bulletin said
specifically that the manual adjustment could be applied to the unit
anytime up to midnight of the day in question. Not so, it turns out.
Another problem with manual adjustments is that they require repeated
attention. My reference clock was off by a second for about 24 hours
using the glitchy automatic settings. Clocks that have been manually
configured could be off for days, weeks, or indefinetly if they are
installed and forgotten about. I don't think relying on manual
intervention is a good long-term solution.
If I understand your post, products of yours shipped after July 1,
2005 had the leap seconds values manually set. Does this mean that
all of those devices will miss the next leap second(s) permanently, if
not manually reconfigured each time?
Because the manual settings can be applied ahead of time and are
implemented by the clock at the correct time, I think there must be a
way to take the transmitted offset (early) and only apply it at the
correct time and day.
To summarize, my CDMA reference clock gave the wrong time for one day,
the product bulletin had incorrect advice, and the "solution" of
manual intervention before each leap event is not very practical. Net
result, my clock added to the instability on the 'net, and I am
embarrased and dismayed.
I look forward to a CDMA firmware revision that solves this problem
before the next leap-second.
- Eric
On Sat, 31 Dec 2005 23:31:25 -0800, Bruce Penrod
<bmpe...@comcast.net> wrote: