Internet DRAFT - draft-jeong-nsis-3gpp-qosm
draft-jeong-nsis-3gpp-qosm
IETF Next Steps in Signaling S. Jeong
Working Group HUFS
Internet-Draft S. Lee
Expires: April 27, 2006 Samsung AIT
G. Karagiannis
University of Twente
G. Lieshout
Samsung Electronics Research
Institute
October 24, 2005
3GPP QoS Model for Networks Using 3GPP QoS Classes
draft-jeong-nsis-3gpp-qosm-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft describes an NSIS QoS Model (QOSM) based on 3GPP QoS
classes and bearer service attributes. Specifically, this draft
Jeong, et al. Expires April 27, 2006 [Page 1]
Internet-Draft 3GPP QoS Model October 2005
describes additional optional parameters for QSPEC which carries 3GPP
QOSM specific information and how the QSPEC information should be
processed in QNEs.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Summary of 3GPP QoS Classes and Attributes . . . . . . . . . . 4
3.1 3GPP QoS Classes . . . . . . . . . . . . . . . . . . . . . 4
3.2 3GPP QoS Attributes . . . . . . . . . . . . . . . . . . . 5
4. QoS Mappings between TS 23.107 and Other QoS Models . . . . . 6
4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ . . . . 6
4.1.1 Mapping between TS 23.107 and Y.1541 QoS Classes . . . 6
4.1.2 Mapping between TS 23.107 and DiffServ QoS Classes . . 7
4.2 QoS Mapping between TS 23.107 and RMD-QOSM . . . . . . . . 7
5. Additional Optional QSPEC Parameters for 3GPP QOSM . . . . . . 8
5.1 3GPP QoS Classes . . . . . . . . . . . . . . . . . . . . . 9
5.2 Delivery of Erroneous SDU (DES) . . . . . . . . . . . . . 9
5.3 Source Statistics Descriptor (SSD) . . . . . . . . . . . . 9
5.4 Signaling Indication (SI) . . . . . . . . . . . . . . . . 10
5.5 SDU Format Information (SFI) . . . . . . . . . . . . . . . 10
5.6 Transfer Delay (TD) . . . . . . . . . . . . . . . . . . . 12
5.7 Packet Loss Ratio (PLR) . . . . . . . . . . . . . . . . . 12
5.8 Traffic Handling Priority (THP) . . . . . . . . . . . . . 13
6. Interoperation with 3GPP UMTS . . . . . . . . . . . . . . . . 13
6.1 UE-initiated NSIS signaling . . . . . . . . . . . . . . . 13
6.2 GGSN-initiated NSIS signaling . . . . . . . . . . . . . . 15
7. NSIS Signaling within the IP-based Transport Part of
UMTS/GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. Change History . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1 Normative References . . . . . . . . . . . . . . . . . . . 18
12.2 Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Jeong, et al. Expires April 27, 2006 [Page 2]
Internet-Draft 3GPP QoS Model October 2005
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
2. Introduction
The NSIS working group is standardizing a signaling protocol suite
with QoS signaling as the first use case. The overall signaling
protocol suite is decomposed into a generic lower layer with separate
upper layers for signaling applications. The upper layer protocol,
called NSIS Signaling Layer Protocol (NSLP), has an end-to-end scope
and contains application specific functionality. QoS-NSLP [2] which
is an NSLP for QoS signaling defines message types and control
information generic to all QoS models (QOSMs). A QOSM is a defined
mechanism for achieving QoS as a whole. The specification of a QOSM
includes a description of its QSPEC parameter information and how
that information should be treated or interpreted in the network.
The QSPEC contains a set of parameters and values describing the
requested resources [3]. The QSPEC object also contains control
information and the QoS parameters defined by the QOSM. A QOSM
provides a specific set of parameters to be carried in the QSPEC. At
each QoS NSIS Entity (QNE), its contents are interpreted by the
resource management function (RMF) for policy control and traffic
control (including admission control and configuration of the packet
classifier and scheduler).
+----------+ /-------\ /--------\ /--------\
| Laptop | | Home | | Cable | | Diffserv |
| Computer |-----| Network |-----| Network |-----| Network |----+
| (QNE) | | No QOSM | |DQOS QOSM | | RMD QOSM | |
+----------+ \-------/ \--------/ \--------/ |
|
+-----------------------------------------------+
|
| /--------\ +----------+
| | "X"G | | Handheld |
+---| Wireless |-----| Device |
| XG QOSM | | (QNE) |
| (e.g., | +----------+
|3GPP QOSM)|
\--------/
Figure 1. An Example Configuration with Multiple Different QOSMs
Figure 1 shows a hybrid network comprised of multiple different QOSMs
Jeong, et al. Expires April 27, 2006 [Page 3]
Internet-Draft 3GPP QoS Model October 2005
[3]. One of the representative XG QOSMs shown in the figure could be
3GPP QOSM. QoS interworking between 3GPP wireless and non-3GPP
wireline networks will be essential if future IP-based next
generation networks are to provide assured-quality end-to-end IP
flows.
In general, in 3GPP UMTS, the wireless physical resource (e.g.,
frequency spectrum, transmission power or time slots) can be
considered to be a significantly scarcer resource than the bandwidth
in IP backbone networks [8, 9]. The transmission is therefore
optimized in order to utilize the resources as efficiently as
possible. Furthermore, in UMTS, different radio bearer services can
be provided, that could result in different QoS characteristics,
service behaviors, and service costs. The key element for providing
optimal QoS with spectrum efficient usage of radio resources is the
radio management function. The optimal QoS support can only be
provided if the radio management function understands via the 3GPP
QOSM, the IP service requirements, and how the radio bearers can be
tailored to meet these needs. Therefore, the 3GPP QOSM should be
able to signal the user QoS requirements for a session, and as well a
set of parameters to control the characteristics of the radio bearers
in order to optimize the offered services while maximizing the
efficient use of the scarce radio resources. It is, therefore,
important to identify what parameters the radio management function
should get from an application that wishes to operate efficiently
over wireless networks. These parameters allow appropriate radio
bearers to be selected, and to determine the effects of these bearers
on the IP service characteristics.
This draft describes an NSIS QoS Model (QOSM) based on 3GPP QoS
classes and bearer service attributes. Specifically, this draft
describes additional optional parameters for QSPEC which carries 3GPP
QOSM specific information, how the QSPEC information should be
processed in QNEs, which and how other NSIS QoS models, e.g., RMD-
QOSM [13] and Y.1541-QOSM [4], can be applied and interoperate with
the 3GPP PDP context signaling.
3. Summary of 3GPP QoS Classes and Attributes
This section summarizes 3GPP QoS classes and bearer service
attributes which are used to describe the 3GPP QOSM.
3.1 3GPP QoS Classes
3GPP UMTS QoS classes were defined in TS 23.107[5] by taking the
restrictions and limitations of the air interface into account. The
QoS mechanisms provided in the cellular network have to be robust and
capable of providing reasonable QoS resolution.
Jeong, et al. Expires April 27, 2006 [Page 4]
Internet-Draft 3GPP QoS Model October 2005
There are four different UMTS QoS classes, i.e., Conversational
class, Streaming class, Interactive class, and Background class. The
main distinguishing factor between these QoS classes is how delay
sensitive the traffic is. For example, Conversational class is meant
for traffic which is very delay sensitive while Background class is
the most delay insensitive traffic class.
Conversational and Streaming classes are mainly intended to be used
to carry real-time traffic flows. The main divider between them is
how delay sensitive the traffic is. Conversational real-time
services, like video telephony, are the most delay sensitive
applications and those data streams should be carried in
Conversational class.
Interactive and Background classes are mainly meant to be used by
traditional Internet applications like WWW, E-mail, Telnet, FTP, and
News. Due to looser delay requirements, compared to Conversational
and Streaming classes, both provide better error rate by means of
channel coding and retransmission. The main difference between
Interactive and Background classes is that Interactive class is
mainly used by interactive applications, e.g., interactive e-mail or
interactive web browsing, while Background class is meant for
background traffic, e.g., background download of e-mail or background
file downloading. Traffic in the Interactive class has higher
priority in scheduling than Background class traffic, so background
applications use transmission resources only when interactive
applications do not need them. This is very important in wireless
environment where the bandwidth is scarce compared to fixed networks.
To achieve QoS interoperability for end-to-end QoS, the mappings
between 3GPP QoS classes (defined in TS 23.107) and non-3GPP QoS
Classes such as Y.1541 and DiffServ classes will be important.
3.2 3GPP QoS Attributes
UMTS bearer service attributes describe the service provided by the
UMTS network to the user of the UMTS bearer service. A set of QoS
attributes (QoS profile) defined in TS 23.107 are listed below [5].
(a) Traffic class
(b) Maximum bitrate (kbps)
(c) Guaranteed bitrate (kbps)
(d) Delivery order (y/n)
(e) Maximum SDU size (octets)
Jeong, et al. Expires April 27, 2006 [Page 5]
Internet-Draft 3GPP QoS Model October 2005
(f) SDU format information (bits)
(g) SDU error ratio
(h) Residual bit error ratio
(i) Delivery of erroneous SDUs (y/n)
(j) Transfer delay (ms)
(k) Traffic handling priority
(l) Allocation/Retention Priority
(m) Source statistics descriptor ('speech'/'unknown')
(n) Signaling Indication (Yes/No)
4. QoS Mappings between TS 23.107 and Other QoS Models
The following two subsections illustrate possible mappings between
3GPP UMTS QoS classes in TS 23.107 and other QoS classes. These
mappings will be useful for interoperation between 3GPP networks and
non-3GPP networks. More detailed mappings will be implementation
specific.
4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ
4.1.1 Mapping between TS 23.107 and Y.1541 QoS Classes
ITU-T Recommendation Y.1541 proposes six QoS classes defined
according to the desired QoS performance objectives [4]. These QoS
classes support a wide range of user applications. The QoS classes
group performance objectives for one-way IP packet delay (IPTD), IP
packet delay variation (IPDV), IP packet loss ratio (IPLR), and IP
packet error ratio (IPER). Classes 0 and 1 support interactive real-
time applications, and Classes 2, 3, and 4, support non-interactive
applications. Class 5 has all the QoS parameters unspecified. These
classes serve as a basis for agreements between end-users and service
providers, and between service providers. They support a wide range
of traffic applications including point-to-point telephony, data
transfer, multimedia conferencing, and others. The limited number of
classes supports the requirement for feasible implementation,
particularly with respect to scale in global networks.
Based on the definitions above, the 3GPP Conversational and Streaming
classes may correspond to Y.1541 classes 0 and 1, respectively. The
two classes of Y.1541 and TS 23.107 are intended to support real-time
Jeong, et al. Expires April 27, 2006 [Page 6]
Internet-Draft 3GPP QoS Model October 2005
services. The Conversational class and Y.1541 class 0 have a more
stringent latency requirement than the Streaming class and Y.1541
class 1. In both specifications, jitter is intended to be limited.
In addition, the 3GPP Interactive class may correspond to Y.1541
classes 2, 3, and 4, and one of the relevant applications is
interactive data. More detailed mappings can be found in [10].
4.1.2 Mapping between TS 23.107 and DiffServ QoS Classes
DiffServ [9] proposes differentiation in the queueing and forwarding
treatment received by packets at the routers in the network domain,
on the basis of DiffServ Code Points (DSCPs) included in their
headers at the ingress of the network domain. IETF has standardized
two groups of behavior aggregates, namely expedited forwarding or EF
(one class) and assured forwarding or AF (four classes each
containing three drop-precedence levels). The actual policies used
for marking, queueing and forwarding of packets at routers in
DiffServ domain is an implementation-specific issue.
EF per-hop behavior (PHB) group has been defined with the intention
of providing leased-line like service using DiffServ. This is
achieved by regulating the total rate of all the flows registered
with the EF PHB class to be less than the service rate allocated to
the EF PHB class at that node. Strict policing is enforced on the
flows, and any non-conforming packets are dropped at the ingress
itself. The AF PHB group has provision for classifying packets into
different precedence levels. Three such levels have been specified
and each level is associated with a drop precedence. Thus, each AF
class has three DSCPs reserved, one for each level. AF PHB group
defines a relationship between these three precedence levels. If
congestion occurs at a particular forwarding node, a packet with the
lowest drop precedence must have the lowest probability of being
dropped. Likewise, a packet with the highest drop precedence has the
highest probability of dropping.
Based on the definitions above, it appears that the 3GPP
Conversational class corresponds to EF PHB class which can support
low latency and jitter, and the 3GPP Streaming class may also
correspond to EF. The 3GPP Interactive class may correspond to AF4
or AF 3 (which can support low latency (but not as low as in
conversational class)), and the Background class may correspond to
AF2, AF1, or BE PHB class (which does not impose any special QoS
requirement). Please note that there may be different reasonable
mappings.
4.2 QoS Mapping between TS 23.107 and RMD-QOSM
In Section 8.4 of RFC 3726 [14] it is emphasized that in an UMTS like
Jeong, et al. Expires April 27, 2006 [Page 7]
Internet-Draft 3GPP QoS Model October 2005
scenario, (see Figure 2) the NSIS QoS protocol can be applied between
a base station and the gateway (GW). Furthermore, in this scenario
the NSIS QoS protocol can also be applied either between two GWs, or
between two edge routers (ERs). In these situations, the RMD-QOS
model [13] can be used to satisfy the requirements imposed by the
characteristics of such topologies. In these cases the mapping
between the attributes specified in [5] depends on bandwidth and
provisioning of resources among the different DiffServ classes which
the operators control to satisfy their cost and performance
requirements.
An example of mapping the TS 23.107 and RMD-QOSM DiffServ QoS Classes
could be similar to the mapping explained in Section 3.1.2.
An example of mapping the TS 23.107 and RMD-QOSM bandwidth parameters
is:
RMD QOSM <Bandwidth> = TS 23.107 <Maximum bitrate>
|--|
|GW|
|--| |--|
|MH|--- .
|--| / |-------| .
/--|base | |--| .
|station|-|ER|...
|-------| |--| . |--| back- |--| |---| |----|
..|ER|.......|ER|..|BGW|.."Internet"..|host|
-- |-------| |--| . |--| bone |--| |---| |----|
|--| \ |base |-|ER|... .
|MH| \ |station| |--| .
|--|--- |-------| . MH = mobile host
|--| ER = edge router
<----> |GW| GW = gateway
Wireless link |--| BGW = border gateway
... = interior nodes
<------------------->
Wired part of wireless network
<---------------------------------------->
Wireless Network
Figure 2. QoS Architecture of Wired Part of UMTS
5. Additional Optional QSPEC Parameters for 3GPP QOSM
Some of the 3GPP QoS attributes described in Section 2.2 are
specified in the QSPEC draft [3]. Additional optional QSPEC
Jeong, et al. Expires April 27, 2006 [Page 8]
Internet-Draft 3GPP QoS Model October 2005
parameters should be defined for appropriate radio resource
management in UMTS. This section provides the description and the
format of these additional optional parameters. More detailed
description will be provided in the later version of this draft.
[Editorial note: The number of the additional QSPEC parameters given
in this version is not fixed. Future versions of the draft may
include more QSPEC parameters.]
5.1 3GPP QoS Classes
Traffic class represents the type of application (i.e.,
'conversational', 'streaming', 'interactive', or 'background') for
which the UMTS bearer service is optimized. By including the traffic
class as an attribute, UMTS can make assumptions about the traffic
source and optimize the transport for that traffic type. This
parameter can be defined in a way similar to the <Y.1541 QoS Class>
parameter in [3] except for the number of classes, i.e., 4 in this
draft.
5.2 Delivery of Erroneous SDU (DES)
Delivery of erroneous SDUs (DES) indicates whether SDUs detected as
erroneous shall be delivered or discarded. 'yes' implies that error
detection is employed and that erroneous SDUs are delivered together
with an error indication, 'no' implies that error detection is
employed and that erroneous SDUs are discarded, and '-' implies that
SDUs are delivered without considering error detection. This
attribute is used to decide whether error detection is needed and
whether frames with detected errors shall be forwarded or not.
The DES (2 bits) parameter is represented as follows.
0 1
+-+-+
|DES|
+-+-+
Three values of DES are listed below to indicate different meanings.
0 - 'No'
1 - 'Yes'
2 - '-'
5.3 Source Statistics Descriptor (SSD)
Source statistics descriptor (SSD) specifies characteristics of the
Jeong, et al. Expires April 27, 2006 [Page 9]
Internet-Draft 3GPP QoS Model October 2005
source of submitted SDUs. Conversational speech has a well-known
statistical behaviour. By being informed that the SDUs for a UMTS
bearer are generated by a speech source, RAN, the serving GPRS
support node (SGSN) and the gateway GPRS support node (GGSN) and also
the user equipment (UE) may, based on experience, calculate a
statistical multiplex gain for use in admission control on the
relevant interfaces. The format of SSD parameter will be provided in
the later version of this draft.
5.4 Signaling Indication (SI)
Signaling Indication (SI) indicates the signaling nature of the
submitted SDUs. This attribute is additional to the other QoS
attributes and does not over-ride them. This attribute is only
defined for the interactive traffic class. If signaling indication
is set to 'Yes', the UE should set the traffic handling priority to
'1'. Signaling traffic can have different characteristics to other
interactive traffic, e.g., higher priority, lower delay, and so on.
This attribute permits enhancing the RAN operation accordingly. The
SI parameter (1 bit) is represented as follows.
0
+--+
|SI|
+--+
Two values of SI are listed below to indicate different meanings.
0 - 'No'
1 - 'Yes'
5.5 SDU Format Information (SFI)
The SDU format information represents the list of possible exact
sizes of SDUs. UMTS uses the Adaptive Multi-Rate (AMR) [11] or the
AMR Wideband (AMR-WB) [12] as speech transcoders. As emphasized in
[15], the speech bits encoded in each AMR or AMR-WB frame have
different perceptual sensitivity to bit errors. By applying this
property a better voice quality can be achieved using Unequal Error
Protection (UEP) and Unequal Error Detection (UED) mechanisms. These
mechanisms focus on the protection and detection of corrupted bits
only to the perceptually most sensitive bits in an AMR or AMR-WB
frame. In AMR and AMR-WB, these most sensitive bits are denoted as
class A bits. Two other classes are also used, i.e., B and C,
wherein the bits belonging into these classes are less sensitive to
errors. In this case, a frame is declared correct even when no bits
in class A are corrupted, and some bits in class B and C are indeed
Jeong, et al. Expires April 27, 2006 [Page 10]
Internet-Draft 3GPP QoS Model October 2005
corrupted. If the bits in class A are corrupted then the frame is
anyway declared corrupted.
The UEP and UED mechanisms could therefore be significant in
achieving spectrum efficient resource management. In order to be
able to use these mechanisms, information about the payload format
(class A, B and C sensitivity bits) is necessary at the radio level.
The specification of the SDU format as a service parameter allows any
application to take advantage of the UEP and UED mechanism. The
format of this parameter can be specified as follows. Two types of
AMR codecs should be supported. The first one is the typical AMR
codec, where the SDU format is described in Section 4 of [14].
The second type of codec is the the AMR-WB (AMR- Wideband) codec.
The SDU format is described in Section 4 of [15]. The format of this
parameter should be a QSPEC Control Information container. Its
format should be:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT | FT |Q| MI | MR | CRC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AT (AMR type): 2 bits integer used to soecify the used AMR type and
its values are:
0: (default) typical AMR codec as specified in [14]
1: AMR-WB (AMR- Wideband) codec as specified in [15].
2: reserved for future use
3: reserved for future use
Frame Type (FT): 4 bits
Q (Frame Quality Indicator): 1 bit
MIndication (Mode Indication: MI): 4 bits
If AT = 0 then only the 3 Most Signifficant Bits are used
If AT = 1 then the 4 bits are used
MRequest (Mode Request: MR): 4 bits
If AT = 0 then only the 3 Most Signifficant Bits are used.
If AT = 1 then the 4 bits are used
CRC (Codec CRC): 8 bits
Note that the Frame Type and the Frame Quality Indicator represent
the AMR header. The Mode Indication, Mode Request and Codec CRC
parameters represent the AMR Auxiliary information. The Class A
Jeong, et al. Expires April 27, 2006 [Page 11]
Internet-Draft 3GPP QoS Model October 2005
bits, Class B bits and Class C bits represent the AMR Core frame.
Using the AMR header and AMR Auxiliary information the destination
can deduce how many bits should be used for Class A, how many for
Class B and how many for class C in the AMR Core frame.
5.6 Transfer Delay (TD)
[Editorial note: This parameter may have the same semantic behavior
as its associated QSPEC parameter (i.e., QSPEC Path Latency
Parameter) described in the QSPEC template draft. A future version
of this daft may use the associated QSPEC template parameter instead
of the currently specified one.]
Transfer delay (ms) indicates maximum delay for 95th percentile of
the distribution of delay for all delivered SDUs during the lifetime
of a bearer service. This parameter allows the radio management
function to efficiently configure the radio bearer service. For
example, by knowing the Delay requirement, the appropriate
interleaving depth can be estimated. This parameter could also be
used to determine the maximum number of retransmissions (if any) in
the wireless link.
The transfer delay (ms) is represented as a 32-bit integer as shown
below.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transfer delay (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7 Packet Loss Ratio (PLR)
[Editorial note: This parameter may have the same semantic behavior
as its associated QSPEC parameter (i.e., QSPEC Path BER Parameter)
described in the QSPEC template draft. A future version of this daft
may use the associated QSPEC template parameter instead of the
currently specifeid one.]
The packet loss ratio can significantly affect the subjective quality
of real time applications. This parameter can be used by the radio
management function for admission control and to set some parameters
of the radio part, such as L2 buffer size.
The Packet Loss Ratio is represented as a 32-bit integer as shown
below.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Jeong, et al. Expires April 27, 2006 [Page 12]
Internet-Draft 3GPP QoS Model October 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Loss Ratio (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.8 Traffic Handling Priority (THP)
Traffic handling priority specifies the relative importance for
handling of all SDUs belonging to the UMTS bearer compared to the
SDUs of other bearers. In many interactive packet services the
packet handling priority can be used to provide certain levels of QoS
differentiation, in particular in congestion situations. According
to Section 6.5.1 of [5] the Traffic handling priority class can get
the values 1, 2 and 3. Therefore the format of this parameter is:
0 1
+-+-+
|THP|
+-+-+
Note that the length of this parameter is 2 bits integer.
6. Interoperation with 3GPP UMTS
This section describes two possible interoperation scenrios for NSIS
QoS signaling which is initiated by QNEs in UMTS.
6.1 UE-initiated NSIS signaling
This section describes an interoperation scenario for end-to-end NSIS
signaling that is initiated from a UE connected to a UTMS network.
Figure 3 shows an end-to-end network architecture [6, 7] used to
explain how end-to-end QoS signaling is achieved using NSIS in the
situation where 3GPP and non-3GPP networks are interconnected.
^ +-----+ +----+ +------+ +------+
IP | | | IP Bearer | | //------\\ | | | |
Bearer | | | Service | | | | | | | |
Layer | | |<----------| |-+---------+-| |-->| |
V |Local| | | | | |Remote| |Remote|
============|UE |===========|GGSN| | Backbone| |Access|===|Host |
Access ^ | | | | | IP | |Point | | |
Bearer | | | +----+ | | | Network | | | | |
Layer | | |<-|SGSN|-->| | | | | |<->| |
(e.g. UMTS| | | +----+ | | \\------// | | | |
Bearer) V +-----+ +----+ +------+ +------+
^ ^
+............+
Jeong, et al. Expires April 27, 2006 [Page 13]
Internet-Draft 3GPP QoS Model October 2005
Scope of PDP Context
Figure 3. An End-to-End Network Architecture
Figure 4 shows signaling flows in the scenario. The UE acts as a QNI
and initiates NSIS signaling towards the remote end. The IP backbone
network is DiffServ-enabled, and the GGSN supports DiffServ. The
application layer (e.g., SIP/SDP) between the end hosts identifies
the QoS requirements. The QoS requirements from the application
layer are mapped down to create an NSIS session. The QoS for the
wireless access is provided by the PDP context. The wireless QoS can
be controlled through signaling for the PDP context. The UE
populates the initiator QSPEC and establishes the PDP context
suitable for supporting the NSIS session based on the QSPEC
information.
To activate the PDP context, the UE sends an Activate (Secondary) PDP
Context message to the SGSN with the UMTS QoS parameters, and the
SGSN sends the corresponding Create PDP Context message to the GGSN.
The GGSN authorizes the PDP context activation request according to
the local operator's IP bearer resource based policy, the local
operator's admission control function and the GPRS roaming agreements
and sends a Create PDP Context Response message back to the SGSN.
The radio access bearer (RAB) setup is done by the RAB assignment
procedure, and the SGSN sends an Activate (Secondary) PDP Context
Accept message to the UE.
Upon receiving the Activate PDP Context Accept message, the QoS-NSLP
at the UE (QNI) sends a QoS-NSLP RESERVE (in case of sender-initiated
approach) message which contains the Initiator QSPEC to the next hop
in the external IP network through the GGSN. The Initiator QSPEC
specifies optional parameters specific to 3GPP QoS model as well as
generic QSPEC parameters for the application flow.
UE (QNI) GGSN (QNF) Remote AP Remote Host (QNR)
| | | |
| Application Layer (e.g., SIP/SDP) |
|<...............................................>|
| | | |
| NSIS Signalling |
|<-------------------+------+-------------------->|
| | | |
| PDP Flow | | |
|------------------->| | |
| | | |
Figure 4. UE-initiated NSIS signaling
Jeong, et al. Expires April 27, 2006 [Page 14]
Internet-Draft 3GPP QoS Model October 2005
Please note that the NSIS signaling and the PDP signaling could also
be used in an interleaved way.
In the example above, only RMD-QOSM is assumed to be used in the
external network. The signaling procedure for QoS interworking in
the situation where the external network is based on Y.1541-QOSM will
be similar except for QoS mapping.
6.2 GGSN-initiated NSIS signaling
This section describes a scenario for NSIS signaling that is
initiated from the GGSN. That is, the GGSN acts as a QNI in this
scenario.
UE GGSN (QNI) Remote AP Remote Host (QNR)
| | | |
| Application Layer (e.g., SIP/SDP) |
|<...............................................>|
| | | |
| NSIS Signalling |
| <------+-------------------->|
| | | |
| PDP Flow | | |
|------------------->| | |
| | | |
Figure 5. GGSN-initiated NSIS signaling
Figure 5 shows signaling flows in the scenario. The GGSN acts as a
QNI and initiates NSIS signaling towards the remote end. The IP
backbone network is DiffServ enabled, and the GGSN supports DiffServ.
The application layer (e.g., SIP/SDP) between the end hosts
identifies the QoS requirements. The wireless QoS can be controlled
through signaling for the PDP context. Therefore, the QoS
requirements from the application layer are mapped down to the PDP
context at the UE.
To activate the PDP context, the UE sends an Activate (Secondary) PDP
Context message to the SGSN with the UMTS QoS parameters, and the
SGSN sends the corresponding Create PDP Context message to the GGSN.
The GGSN authorizes the PDP context activation request according to
the local operator's IP bearer resource based policy, the local
operator's admission control function and the GPRS roaming agreements
and sends a Create PDP Context Response message back to the SGSN.
The radio access bearer (RAB) setup is done by the RAB assignment
procedure, and the SGSN sends an Activate (Secondary) PDP Context
Accept message to the UE.
Jeong, et al. Expires April 27, 2006 [Page 15]
Internet-Draft 3GPP QoS Model October 2005
The GGSN populates the initiator QSPEC based on the PDP context to
create an NSIS session. The QoS-NSLP at the GGSN (QNI) sends a QoS-
NSLP RESERVE (in case of sender-initiated approach) message which
contains the Initiator QSPEC to the next hop in the external IP
network. The Initiator QSPEC specifies optional parameters specific
to 3GPP QoS model as well as generic QSPEC parameters for the
application flow. Note that QoS mapping between the 3GPP and
DiffServ QoS classes/parameters should be performed at the GGSN.
In the example above, only RMD-QOSM is assumed to be used in the
external network. The signaling procedure for QoS interworking in
the situation where the external network is based on Y.1541-QOSM will
be similar except for QoS mapping.
7. NSIS Signaling within the IP-based Transport Part of UMTS/GPRS
As emphasized in [5], the RAN/BSS Access bearer services and Core
network bearer services for packet traffic shall provide different
bearer services for variety of QoS. The operator is responsible for
choosing which QoS capabilities in Frame Relay layer, in IP layer or
in ATM layer are used. Regarding the IP based RAN/BSS Access bearer
services and Core network bearer services it is recommended that the
Differentiated Services defined by IETF shall be used. The NSIS RMD-
QOSM [13] satisfies this recommendation and therefore, it can be
considered as a feasible solution on satisfying the QoS requirements
imposed by the RAN Access bearer services and Core network bearer
services on the IP based transport part of UMTS/GPRS. The QoS
support in the IP based transport of UMTS/GPRS can be achieved by
combining either the UE (MS) initiated or the network initiated
Activate/Modify/Deactivate PDP context procedures, specified in [16]
with the NSIS RMD-QOSM procedures specified in [13]. This is
depicted in Figure 6, where either a UE (MS), or a SGSN or a GGSN can
start the PDP context procedures on requesting, modifying or deleting
a PDP context, in terms of QoS. The NSIS RMD-QOSM procedures can be
applied on the IP based transport network(s), see also Figure 2,
used between:
* Node B (Base Station) and RNC (or BSC)
* between RNC's (or BSC's)
* between SGSN and GGSN
A possible way of achieving the QoS mapping between the PDP context
procedures and the NSIS RMD-QOSM is described in Section 4.2.
UE Node B RNC SGSN GGSN
(MS) (Base Station) (BSC)
Jeong, et al. Expires April 27, 2006 [Page 16]
Internet-Draft 3GPP QoS Model October 2005
| | | | |
| | | | |
|Activate/Modify/Deactivate PDP context procedure| |
|<------------------------------------------------------------->|
| | | |NSIS RMD-QOSM |
| | | |<------------>|
|Activate/Modify/Deactivate PDP context procedure| |
|<------------------------------------------------------------->|
| | | | |
| | | | |
| | | | |
| | NSIS RMD-QOSM | | |
| |<------------->| | |
|Activate/Modify/Deactivate PDP context procedure| |
|<------------------------------------------------------------->|
| | | | |
Figure 6. NSIS Signaling within the IP-based Transport Part of
UMTS (and GPRS)
8. Security Considerations
There are no new security considerations based on this draft.
9. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
QSPEC template, in accordance with BCP 26 RFC 2434 [16]. [2] requires
IANA to create a new registry for QoS Model Identifiers. The QoS
Model Identifier (QOSM ID) is a 32-bit value carried in a QSPEC
object. The allocation policy for new QOSM IDs is TBD. This
document also defines new objects for the QSPEC Template, as etailed
in Section 5. Values are to be assigned for them from the NTLP
Object Type registry.
10. Acknowledgements
The authors thank Jongho Bang, Byoung-Joon Lee, Cornelia Kappler,
Jerry Ash, Al Morton, Gabor Fodor, Fredrik Persson, Brian Williams,
and Attila Bader for helpful comments and discussion.
11. Change History
11.1. Changes since -01
1. Updated abstract, introduction, and additional optional QSPEC
parameters
Jeong, et al. Expires April 27, 2006 [Page 17]
Internet-Draft 3GPP QoS Model October 2005
2. Created a new section "NSIS Signaling within the IP-based
Transport Part of UMTS/GPRS"
3. Updated figures regarding interoperation with UMTS
11.2. Changes since -00
1. Reduced the text for overview
2. Added QoS mapping between 3GPP TS 23.107 and RMD-QOSM
3. Updated additional optional QSPEC parameters
4. Updated interworking Scenarios for End-to-End QoS Support
5. Added Future Issues
12. References
12.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bosch, S., "NSLP for Quality-of-Service signalling",
draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005.
[3] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06
(work in progress), October 2005.
[4] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using
Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in
progress), May 2005.
[5] 3GPP, "Quality of Service (QoS) concept and architecture", 3GPP
TS 23.107 3.9.0, September 2002.
[6] 3GPP, "End-to-end Quality of Service (QoS) concept and
architecture", 3GPP TS 23.207 5.10.0, October 2005.
[7] 3GPP, "Architectural enhancements for end-to-end Quality of
Service (QoS)", 3GPP TR 23.802 7.0.0, October 2005.
[8] Fodor, G., Persson, F., and B. Williams, "Application of
Integrated Services on Wireless Accesses",
draft-fodor-intserv-wireless-issues-01 (work in progress),
January 2002.
Jeong, et al. Expires April 27, 2006 [Page 18]
Internet-Draft 3GPP QoS Model October 2005
[9] Fodor, G., Persson, F., and B. Williams, "Proposal on new
service parameters (wireless hints) in the controlled load
integrated service", draft-fodor-intserv-wireless-params-01
(work in progress), January 2002.
[10] Bain, G. and N. Seitz, "Mapping between ITU-T (Y.1541/Y.1221)
and 3GPP (TS 23-107) QoS Classes and Traffic Descriptions",
February 2004.
[11] 3GPP, "AMR speech Codec; Transcoding Functions", 3GPP TS 26.090
3.1.0, December 1999.
[12] 3GPP, "Speech codec speech processing functions; Adaptive
Multi-Rate - Wideband (AMR-WB) speech codec; Transcoding
functions", 3GPP TS 26.190 5.1.0, January 2002.
[13] Bader, A., "RMD-QOSM - The Resource Management in Diffserv QOS
Model", draft-ietf-nsis-rmd-04 (work in progress),
October 2005.
[14] 3GPP, "Mandatory speech codec speech processing functions;
Adaptive Multi-Rate (AMR) speech codec frame structure", 3GPP
TS 26.101 3.3.0, March 2002.
[15] 3GPP, "Speech codec speech processing functions; Adaptive
Multi-Rate - Wideband (AMR-WB) speech codec; Frame structure",
3GPP TS 26.201 5.0.0, April 2001.
[16] 3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2", 3GPP TS 23.060 3.16.0, January 2004.
12.2 Informative References
[17] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[18] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-
Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
[19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[20] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
Jeong, et al. Expires April 27, 2006 [Page 19]
Internet-Draft 3GPP QoS Model October 2005
[21] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[22] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
Authors' Addresses
Seong-Ho Jeong
Hankuk University of FS
89 Wangsan Mohyun
Yongin-si, Gyeonggi-do 449-791
KOREA
Phone: +82 31 330 4642
Email: shjeong@hufs.ac.kr
Sung-Hyuck Lee
Samsung Advanced Institute of Technology
Comm. and Network Lab.
San 14-1, Nongseo-ri, Giheung-eup
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
Email: starsu.lee@samsung.com
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE, Enschede
Netherlands
Email: g.karagiannis@ewi.utwente.nl
Gert-Jan van Lieshout
Samsung Electronics Research Institute
Geert Grote straat 8a
7411GS, Deventer
Netherlands
Phone: +31(0)570615651
Email: gert.vanlieshout@samsung.com
Jeong, et al. Expires April 27, 2006 [Page 20]
Internet-Draft 3GPP QoS Model October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jeong, et al. Expires April 27, 2006 [Page 21]
