Subject: [Ecrit] Final comments on ecrit-requirements-00

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 17 Oct 2005 16:43:30 +0900

I didn't realize I was so close to finishing, or I would have put this
together at the last stopover.  The page count was misleading ...

General remark:  It's probably time to get rid of the old requirement
numbers.  I think the ordering and number of requirements will be fairly
stable from now on, and the old numbering has been thoroughly messed up
in some sections.

I31 and I31b: I'd suggest I31 should come before I4, and I31b is in the
same group.

I39 doesn't make any sense in the general context of call setup.  Surely
it doesn't imply that a call already set up will suddenly be yanked off
to another PSAP based on more accurate data.  I'd suggest the relevant
aspect is covered by I42, and the rest is a matter of what is presented
to the call taker.

-------------

On the performance objectives: You've made a start, but we have to take
it a bit further.  An old teletraffic engineering trick is to assume
that probabilities along a path are additive.  This is a reasonable
assumption for low probabilities.  To show how it applies here:

You've declared a total latency to ring-tone objective with a set of
probabilities for given delays.  BTW you've assumed a normal
distribution of delay probabilities,likely not the true model, but that
means one of your objectives will be more binding than the others.
Let's take the 8-second delay probability (1% more than 8s) as a working
example.  We have to allocate that 1% to different components of the
total setup process.  Since we're concentrating on the mapping protocol
at the moment, one possible allocation is:

- probability of delay > 8s within the mapping operation: 0.1%
- probability of delay >8 s within all other segments of call setup: 0.9%

Note the implicit assumption that there is negligible probability that
neither segment takes as much as 8 seconds but the sum is > 8 seconds.
That isn't really the case, but the overall results will behave as if it
were at low probabilities.

That said, the appropriate allocation is a matter of economics.  We have
to model each subsystem and determine how cost varies with the allocated
probability.  That typically involves looking at the economics of
hypothetical reference connections.  Looks like a good exercise for a
student.

Meantime, as a starting point, an allocation of 0.1% probability that
the mapping process will take more than 8 seconds feels about right to
me.  That's what I'd suggest you add to your "latency to ringtone"
objective.

As for "latency to operator": the difference from "latency to ringtone"
is partly media propagation time, but mostly a matter of PSAP staffing
levels.  Neither relates to performance of the mapping operation, so I'd
suggest it is redundant in our context.

Tom Taylor

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 18 Oct 2005 07:38:33 -0700

Location updates will generally not change call signaling in real time,
although it may be possible to do so.  Here are a few scenario's which
may be defensible.

1. Call setup based on initial location / updated location is sent to
PSAP / PSAP transfers to more appropriate PSAP.
2. Call setup started per initial location / updated location is made
available to UA (or proxy) during call setup / UA (or proxy)
reinitializes SIP signaling based on alternate mapping result.

I don't know how feasible no. 2 is, since signaling usually happens a
lot quicker than location updates, but I think that the requirement
(I39), as it is presently worded, covers both cases.

Roger Marshall.

>-----Original Message-----
>From: Tom-PT Taylor [mailto:[email-masked]] 
>Sent: Tuesday, October 18, 2005 5:14 AM
>To: Roger Marshall
>Cc: ECRIT
>Subject: Re: [Ecrit] Final comments on ecrit-requirements-00
>
>Sorry, I still don't see how a location update can affect call 
>routing, unless you are saying the setup should wait several 
>seconds in case an update comes along.  Unless that is what 
>you mean, I39 is irrelevant to the routing process -- any 
>location update will come after setup has been launched.
>
>Roger Marshall wrote:
>...
>> 
>> 
>>>I39 doesn't make any sense in the general context of call setup.  
>>>Surely it doesn't imply that a call already set up will suddenly be 
>>>yanked off to another PSAP based on more accurate data.  I'd suggest 
>>>the relevant aspect is covered by I42, and the rest is a matter of 
>>>what is presented to the call taker.
>> 
>> 
>> I think you're right, that we should be clear as to what 
>implications 
>> are stated within the motivation. I39 itself is general (a 
>good thing).
>> How's an update can be used, either during call signaling or 
>> afterward, I'd rather not address with this requirement.
>> 
>> I39.  Location Updates: It SHOULD be possible to have updates of 
>> location.
>> 
>> Proposed new motivation text:
>> 
>> Motivation: Updated location information may have an impact on PSAP 
>> routing.  In some cases it may be possible to redirect that 
>call to a 
>> more appropriate PSAP (some device measurement techniques provide 
>> quick (i.e. early), but imprecise "first fix" location).
>> 
>> 
>...
>
>
>