FW: Emergency Services and Service classes

[Folts, Harold]

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 at 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 at mailbag.intel.com