Ken,

Many thanks for your comments. I think that they are very important to be inclusive of the many considerations for emergency communications including 911/999/211 calls as well MLPP (preemption).

I am also sending this to the SG16 experts list as there has been quite a bit of discussion to Gary's Email there.

Hal

-----Original Message----- From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] Sent: Thursday, April 26, 2001 5:20 AM To: Folts, Harold Cc: Gary Thom (E-mail) Subject: Re: FW: Emergency Services and Service classes

Hello,

My apologies for the tardiness of this response. In looking at Gary's original message, I thought I might chime in and introduce some food for thought.

in Gary's message, he suggested the following:

...

I would like to propose the following Service Class parameter.

ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } }

I was thinking that it may be better to add another value in the 'priority' field in order to distinguish 'authorized' emergency calls like GETS, versus generic emergency calls like 911 that would be used by the general public and not require special PIN numbers, or other additional measures to denote authentication and authorization.

so, perhaps one might have something like:

...

priority                CHOICE
{
        authorized-emergency,
        emergency,
        high,
        normal,
        low
}

also, would it be of value to have a separate field that distinguishes "classification" of priority? For instance, the above would be the generic type used for global/national PSTN. But there is also the MLPP (from ANSII?) that has 5 levels of priority, but is not used in the PSTN, but rather private voice nets like Autovon.

My feeling is that having a separate field that differentiates normal PSTN versus private-MLPP may be helpful and less confusing than having a single "priority" field that covers all defined values of priority.

However, if you think this may be too cumbersome, then maybe we should look into adding 5 additional values that relate directly to MLPP, thus having a field of 10 values in the above.

For the following...

...

The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call.

I was wondering if it might be better to start off by saying that the values in the priority field denote a "distinction" of the types of calls that can be made. The reason I state this is that there may be cases where traffic engineering separates the routes that calls make, but does not place any additional resources per type. This line of thinking would reflect the cases where preemption is not used, but rather higher probability is.

After stating the point on distinction, then one could talk about the allocation of resource with respect to preemption and quality, on which you talk about next.

...

quality         CHOICE  ;per TIPHON definition
{
        best,
        high,
        medium,
        bestEffort
}

for the above, you may want to inc;ude a value called "BelowBestEffort". I have a paper that makes an arguement for doing this at times, and I have recently come across others that are trying to promote this. In addition, it may correlate nicely to the above priority of "low". It may also correlate to the drop precedence field in IP packets (for diff-serv) when a flow/call exceeds the traffic rate originally negotiated for it.

regards,

-ken

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com