Emergency Services and Service classes

[Roy, Radhika R, ALCOO]

Hi, Tom:

Good that MLPP was discussed in the last Rap. meeting.

One suggestion comes to my mind that we can define "Priority" field in such
a way keeping options for all kinds of priority (civilian, interworking with
ISDN, etc.) levels and let people choose as it is needed.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor at nortelnetworks.com]
Sent: Wednesday, April 18, 2001 3:16 PM
To: Roy, Radhika R, ALCOO; ITU-SG16 at MAILBAG.INTEL.COM
Subject: RE: Emergency Services and Service classes



I just wanted to note that MLPP came up in the Launceston discussion.  The
point was made at that time that MLPP (the M stands for "Military") is a
separate issue, since what Gary and company are talking about is civilian
emergency services.

Beyond that, we are committed to working with other Study Groups on this
issue.

> -----Original Message-----
> From: Roy, Radhika R, ALCOO [ mailto:rrroy at ATT.COM <mailto:rrroy at ATT.COM>
]
> Sent: Wednesday, April 18, 2001 1:34 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Emergency Services and Service classes
>
>
> Hi, Tom and All:
>
> I have few comments on: 1. Priority Class, 2. Quality/QOS
> Class, and 3.
> Dependency between Priority and Quality
>
> 1. Priority Class of a Call
>
> Let us define priority classes for a call across all ITU SGs
> (not ONLY in
> SG16). If the SG16 is allowed to do define the priority class
> that will be
> followed by other SGs, we may then define this in this SG and will be
> sending liaison to other SGs (because the emergency services
> standard works
> span multiple SGs.
>
> In addition, there are other areas that we need to look into.
> For example,
> the present ISDN standard also defines MLPP where several
> kinds of priority
> are offered. (Recently, contributions have also been
> presented to define
> priority is SIP in accordance to the MLPP.)
>
> 2. Quality/QOS Class of a Call
>
> To define quality of a call is being undertaken in Q.F/16. It
> will take time
> to define QOS classes or anything like this in Q.F because
> the definitions
> of QOS provided in various cases (e.g., SG 13 [Q.4], BICC,
> TIPHON, IETF,
> etc) are problematic at the application layer because they
> are often tied to
> the network layer. Suggestions are also there whether best,
> high, medium, or
> best-effort will mean anything unless we call guaranteed,
> controlled, or
> best-effort.
>
> The point is that let us continue the discussion of quality
> in Q.F/16 so
> that we agree on this.
>
> By the way, in Q.F/16, we are considering the quality at the
> medium level as
> opposed the per call level. (At one point, we found that classes are
> becoming problematic. So, we have started to use a matrix
> where a user will
> define how each medium will be treated - a kind of preferences [e.g.,
> guaranteed, controlled, or best-effort] without defining
> explicit classes.)
>
> 3. Dependency between Priority and Quality
>
> I do not clearly whether there will be any dependency between
> the priority
> and quality of a call.
>
> Hope this helps.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Gary Thom [ mailto:gthom at delta-info.com
<mailto:gthom at delta-info.com> ]
> Sent: Wednesday, April 18, 2001 12:41 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Emergency Services and Service classes
>
>
> I would like to re-open the discussion started at the Nov 2000 Geneva
> meeting and continued at the March 2001 Launceston meeting relating to
> Emergency Services.
>
> In order to support Emergency Services, there are three
> services that are
> desired:
> 1)Priority Dial Tone - this is a line or endpoint dedicated
> to emergency
> calls.
> 2)Priority Call Setup - this allows an emegency call to be
> made from any
> endpoint.
> 3)Priority Call transit through packet network - this
> requires interworking
> existing ISUP high probability of completion call marking
> with H.323, H.323
> Annex M.2, h.246 Annex C, and H.248.
>
> An emergency call may be pre-emptive or may just improve the
> probability of
> call completion without pre-emption depending on national policy.
> Authentication issues also need to be worked out. Currently,
> in the US, this
> is handled like a calling card authentication.
>
> At the Geneva meeting, it was decided that this work was
> closely related to
> contribution D.4 from Cicso on reserving resources and also
> Annex N/H.323 on
> QOS. Also included were liaison statements from SG11 on QOS
> for BICC, and an
> ETSI TIPHON document on signaling end-to-end-qos.
>
> All of these items require a method of signaling the desired
> quality of
> service.
> One way of doing this that seems to be common to all
> requirements is to
> specify a Service Class parameter and to send this parameter
> in the various
> RAS and Call Signaling exchanges.
>
> 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
>         }
> }
>
> 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.
>
> The quality field is taken from the ETSI TIPHON QOS Class
> definitions, and
> relate to bitrate, codec type, and voice or video quality.
>
> High or emergency priority calls may not require best audio
> quality, medium
> may be sufficient (even prefered because of the lower bandwidth
> requirement), while normal priority calls may desire high or
> best audio
> quality.
>
>
> The Service Class parameter would then be added to the
> necessary RAS and
> Call Signalling messages. At a minimum this would include the
> ARQ and Setup
> messages, but might also be applied to others.
>
> It is necessary in the ARQ and Setup messages so that High
> Probability of
> Completion calls comming into the network from the PSTN can be given
> priority treatment.
>
> For priority dial tone, perhaps the Service Class should be
> included in the
> RRQ to indicate the desired priority, once authenticated by
> the Gatekeeper
> and confirmed in the RCF, this endpoint could then include
> that Service
> Class in subsequent ARQ and Setup messages. Is a token
> required from the
> Gatekeeper to indicate that the endpoint has been granted priority
> status????
>
> For priority call completion, an authentication authority and
> procedure
> needs to be defined. One approach is for the call to be made
> to an access
> number, the user is then queried for a PIN and the called
> endpoint number.
> After authentication, the call would be transfered to the
> called endpoint.
> The transfered call would be placed using the Service Class
> provided by the
> athentication authority. This would be the same procedure for
> any calling
> card call made on the packet network. The Service Class would
> be based on
> teh service level agreement between the card user and the
> provider. In the
> case of an emergency caller, the SLA would indicate Emergency
> Priority. How
> are calling card calls handled on packet networks now???? Is this
> consistent???
>
>
> I would appreciate any input that you could provide.
>
> Gary
>
>
>
>
>  --------------------------------------------
>  Name   : Gary A. Thom
>  Company: Delta Information Systems, Inc.
>  Address: 300 Welsh Rd., Bldg 3
>           Horsham, PA 19044 USA
>  Phone  : +1-215-657-5270 x123
>  Fax    : +1-215-657-5273
>  E-mail : gthom at delta-info.com
>  Website: www.delta-info.com
> --------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

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