AW: Emergency Services and Service classes

19 Apr 2001

      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@ATT.COM]
Gesendet am: Mittwoch, 18. April 2001 21:30
An: ITU-SG16@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@nortelnetworks.com]
Sent: Wednesday, April 18, 2001 3:16 PM
To: Roy, Radhika R, ALCOO; ITU-SG16@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@ATT.COM
mailto:rrroy@ATT.COM
]
...
Sent: Wednesday, April 18, 2001 1:34 PM
To: ITU-SG16@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

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.)

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.)

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@delta-info.com
mailto:gthom@delta-info.com ]
...
Sent: Wednesday, April 18, 2001 12:41 PM
To: ITU-SG16@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@delta-info.com
 Website: www.delta-info.com

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

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

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

Horvath Ernst

tags (0)

participants (1)