Re: FW: Emergency Services and Service classes

30 Apr 2001


      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