Emergency Services and Service classes

Roy, Radhika R, ALCOO rrroy at ATT.COM
Thu Apr 19 09:26:08 EDT 2001


Hi, Ernst:

In SG16, we are focusing on the application layer on end-to-end basis,
independent of the underlying transport mechanisms. The call level
abstraction is NOT associated with the network layer. However, as I pointed
out (as you have also indicated for the packet layer), there may be
dependency between the call layer priority and the application layer QOS. We
hope that we will address this in Q.F/16. The same can also be abstracted
over the packet layer for implementation knowing the relationship between
the two right at the application layer at the time of call setup. (Please
note that an end-to-end call may include one or multiple networks [e.g., IP,
ATM]. Even in one network, there can be different network layer QOS schemes
[e.g., RSVP domain, DiffServ QOS domain].)

(With respect to MLPP, people from various countries discussed this in the
last IETF SIP meeting as well and some work is moving along that line.) The
point that I am trying to make is this: Let the priority field should be
flexible enough to meet different needs without limiting to only one kind of
priority scheme. For example, it may include QSIG CPI, civilian emergency
schemes, etc.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Horvath Ernst [mailto:ernst.horvath at SIEMENS.AT]
Sent: Thursday, April 19, 2001 3:36 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: AW: Emergency Services and Service classes


Roy,

as you say, call priority and QoS are different issues, but over a packet
network both come down to the same problem, expedited transport of packets
with minimal packet loss. So the mechanisms used in both cases may well be
the same.

The ISDN MLPP service is very complex and would be over-kill in a packet
network which should not run into the same blocking situations as a circuit
switched network. The complexity of MLPP was also the reason why ISO did not
adopt it for QSIG (QSIG has a simpler call priority service called CPI, call
priority interruption).

Regards,
Ernst Horvath
Siemens AG

> -----Ursprüngliche Nachricht-----
> Von: Roy, Radhika R, ALCOO [mailto:rrroy at ATT.COM]
> Gesendet am: Mittwoch, 18. April 2001 21:30
> An: ITU-SG16 at mailbag.cps.INTEL.COM
> Betreff: Re: Emergency Services and Service classes
>
> 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
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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



More information about the sg16-avd mailing list