Emergency Services and Service classes

[Mike Buckley]

Gary, Radhika, Tom,

Sorry to be a little slow in joining to this interesting thread - I have been out of email contact over the last couple of days.

I think we all agree there are two distinct issues here:

1. The Quality of the media stream (this is what we usually refer to when we talk of QoS)

2.  The Grade of Service - that is the probability that the call will connect successfully.  This is a concept well understood in the circuit switched world but which now needs reinterpreting for IP telephony.

I think Gary's comments are correct in that the issue of emergency services is primarily a grade of service issue rather than an issue of the quality of the media stream.

As Radhika points out I hope Q.F will qive some guidance on the classification system  to be adopted for media stream QoS.  The TIPHON categories are a good starting point for speech.  So far though TIPHON has not addressed Multimedia and is only just beginning to look at this.  Work is also underway in this area in SG12 and SG13 (the latter group from a network perspective).  Another important group interested in multimedia classification is 3GPP.  So we need to co-ordinate the work of Q.F wilth all these groups which will take a little time.  The idea of maybe referring to media classes by number to start with until we can define what these numbers mean is probably a good starting point.  Radhika and I were planning to propose  a new work item on multimedia classification Q.class at the next Sg16 meeting.

The GoS issue is really one of priority in resource reservation  within the transport network. Once the resource is committed then  the QoS class chosen not the GoS class will determine network performance.   Gary's idea of signalling the priority of the call between the User and Service Provider seems a good approach.  Within the service provider's domain this request will need to translated to an indication of priority associated with a request for resource reservation to the transport domain at the time of media stream establishment.  In a multi domain environment which is very much part of the terms of reference for the work in Q.F) this will involve signalling between service domains and transport domains and possibly between transport domains, and we will need to ensure mechanisms for SD to SD as well as SD to TD.  TD to TD is very much the role of the IETF so co-ordination will also be needed here.  Again I was planning to start work on defining these signalling require!
ments in Q.F.

Finally, I agree work has got off to a slow start on Q.F since Geneva.  Lack of time to discuss QoS at the last two WG2 meetings has not helped, also my inability to attend the Launceston meeting and the lack of contributions in this area.  We will be holding a Q.F session in Brazil though and I hope then to start work on two or three new work items.  Hopefully we can make some progress on these and Annex N.   All contributions would be very welcome.

Mike





-----Original Message-----
From:   Roy, Radhika R, ALCOO [SMTP:rrroy at ATT.COM]
Sent:   Wednesday, April 18, 2001 6: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]
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