Subject: Re: Washington Issue 7 - Time Local or UTC

From: Al Varney <[email-masked]>
Date: Fri, 19 Nov 1999 16:16:52 -0600

At 14:19 11/19/1999 -0600, Tom-PT Taylor wrote:

> I'm a bit worried about the demands of billing systems which require event
> timestamps.  These demands can be pretty stringent in the PSTN, to support
> time-of-day tarriffing.  Will we have the same considerations here?

   While I'm reluctant to quote Telcordia (nee Bellcore) documents on an
IETF mailing list, they do provide at least one "PSTNish" perspective on
these issues.

   Accounting records (call detail records) specified in GR-1100 have
time stamps and duration values in tenths-of-seconds.

   The "PSTN switch" requirements are in GR-508, including requirements
for duration accuracy and precision.  In general, the requirements are
for no more than 400 ms error (variation) in any measure of Duration.
Clock drift can affect duration measurements by less than 50 ms / hour.
That's about 24 min/year drift rate.

   I'm assuming the "time/date stamp" for records will be generated at
the MGC or some higher-level system, and the MG is only used for duration
measurements.  If the higher-level system is considered part of the AMA
Data Network, then it must follow GR-1343 requirement (clock drift rate
of about 25 ms / hour).

   So reporting times in tenths-of-seconds (rounded from internal 50 ms
times) should be enough for accounting/recording.  I haven't looked at
the requirements for things like Event Logs and other test-access needs.
The recording unit (an MGC or Signaling Gateway, etc.) might have to
time-stamp these at the milli-second level, but I don't see a need to
have messages from OTHER units carry a time-stamp of that precision.

   I think the 2 fractional parts of a second (hundredths of a second)
that Nancy last proposed are enough.  At most, we could make it 3 parts
(milli-seconds) and indicate event detection mechanisms of lower precision
should just append one or two zeroes as needed.

> I suppose instead of worrying I should check to see if synchronization has
> to be any better than 100 ms.

   If you mean synchronization of Clocks [rather than precision of duration
measurements], I'm not aware of a requirement that a "switch" have a clock
closely synchronized with clocks of other switches, and I hope any duration
measurement can be determined from events observed in a single MG.  If not,
an MGC may have to estimate the "differential" between it's own clock and
that of each MG from which it receives reports.

   FYI, Telcordia's SR-3336 provides a perspective on the use of GPS where
accurate times and timing are required in a telecom network.  (Note:
I receive no compensation for mentioning Telcordia's publications.  :)

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 19 Nov 1999 14:36:36 -0800

Can I ask a really dumb question? People aren't
seriously thinking of using an untrusted MG's idea
of a UTC or any other clock for a *billing* timer
are they? For example, when I install a nice shiny
the MikeMG at home running MEGACO, my service
provider's not going to get upset that the MikeMG
has this software "flaw" that always happens to
have the effect of zeroing the billing timer?

If the only reason for timestamps are billing or
other DOA things like that, we should not
introduce them into the spec at all.  If all we
need is sequencing, we should just use
monotonically incrementing counters.

                  Mike