One document matched: draft-jeong-nsis-3gpp-qosm-01.txt
Differences from draft-jeong-nsis-3gpp-qosm-00.txt
IETF Next Steps in Signaling S. Jeong
Working Group HUFS
Internet-Draft S. Lee
Expires: January 19, 2006 Samsung AIT
G. Karagiannis
University of Twente
July 18, 2005
3GPP QoS Model for Networks Using 3GPP QoS Classes
draft-jeong-nsis-3gpp-qosm-01.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 January 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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. This draft discusses
how to achieve QoS interoperability between 3GPP based wireless
networks and IETF/ITU-T based wireline IP networks from the NSIS
Jeong, et al. Expires January 19, 2006 [Page 1]
Internet-Draft 3GPP QoS Model July 2005
point of view. In particular, this draft tries to describe a QoS-
NSLP QoS model based on 3GPP QoS classes and bearer service
attributes.
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 the TS 23.107 and Y.1541 QoS
Classes . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2 Mapping between the 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) . . . . . . . . . . . . . . . . . . . 11
5.7 Packet Loss Ratio (PLR) . . . . . . . . . . . . . . . . . 11
5.8 Traffic Handling Priority (THP) . . . . . . . . . . . . . 12
6. Interworking Scenarios for End-to-End QoS Support . . . . . . 12
6.1 UE-initiated NSIS signaling . . . . . . . . . . . . . . . 12
6.2 GGSN-initiated NSIS signaling . . . . . . . . . . . . . . 14
7. Future Issues . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 NSIS signaling within the IP based transport part of
UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2 NSIS signaling between UMTS and WiMAX via an IP-based
backbone . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3 NSIS signaling between UMTS and WLAN via an IP-based
backbone . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1 Normative References . . . . . . . . . . . . . . . . . . . 17
11.2 Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 20
Jeong, et al. Expires January 19, 2006 [Page 2]
Internet-Draft 3GPP QoS Model July 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 network comprised of multiple different QOSMs [3].
Jeong, et al. Expires January 19, 2006 [Page 3]
Internet-Draft 3GPP QoS Model July 2005
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 discusses how to achieve QoS interoperability between
3GPP-based wireless networks and non-3GPP based wireline IP networks
from the NSIS point of view. In particular, this draft tries to
describe a QoS-NSLP QOSM based on 3GPP QoS classes and bearer service
attributes. 3GPP TS 23.107 [5] specifies four different QoS classes
for UMTS, and these QoS classes support various user applications.
TS 23.107 also describes specific value ranges for each QoS class.
3GPP TS 23.207 [6] and TR 23.802 [7] specify the architecture and
procedures for achieving end-to-end QoS across networks with the 3GPP
QoS classes as a basis. QSPEC in [3] already addresses generic QoS
parameters, and therefore this draft identifies additional optional
QSPEC parameters for the 3GPP QOSM.
3. Summary of 3GPP QoS Classes and Attributes
3.1 3GPP QoS Classes
3GPP UMTS QoS classes were defined in [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
Jeong, et al. Expires January 19, 2006 [Page 4]
Internet-Draft 3GPP QoS Model July 2005
capable of providing reasonable QoS resolution.
As mentioned above, there are four different 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)
Jeong, et al. Expires January 19, 2006 [Page 5]
Internet-Draft 3GPP QoS Model July 2005
(e) Maximum SDU size (octets)
(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 QoS classes in TS 23.107 and other QoS classes. Detailed
mappings will be implementation specific.
4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ
4.1.1 Mapping between the 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 January 19, 2006 [Page 6]
Internet-Draft 3GPP QoS Model July 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 the 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 corresponds to
AF 4 which can support low jitter. The 3GPP Interactive class may
correspond to 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).
4.2 QoS Mapping between TS 23.107 and RMD-QOSM
Jeong, et al. Expires January 19, 2006 [Page 7]
Internet-Draft 3GPP QoS Model July 2005
In Section 8.4 of RFC 3726 [14] it is emphasized that in an UMTS like
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
Many of the 3GPP QoS attributes described in Section 2.2 are
Jeong, et al. Expires January 19, 2006 [Page 8]
Internet-Draft 3GPP QoS Model July 2005
specified in the QSPEC draft [3]. Additional optional QSPEC
parameters should be defined for appropriate radio resource
management in UMTS. This section briefly provides the description
and the format of these additional parameters. More detailed
description and other possible parameters will be provided in the
later version of this draft.
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.
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 2
+------------+
| DES(2bits) |
+------------+
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
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
Jeong, et al. Expires January 19, 2006 [Page 9]
Internet-Draft 3GPP QoS Model July 2005
statistical multiplex gain for use in admission control on the
relevant interfaces. Source statistics descriptor (SSD) parameter is
represented as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source statistics descriptor [SSD] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 is represented as follows.
0 1
+-----------+
| SI (1bit) |
+-----------+
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
Jeong, et al. Expires January 19, 2006 [Page 10]
Internet-Draft 3GPP QoS Model July 2005
in class A are corrupted, and some bits in class B and C are indeed
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 will be provided in an additional version of
this draft.
5.6 Transfer Delay (TD)
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)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Loss Ratio (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jeong, et al. Expires January 19, 2006 [Page 11]
Internet-Draft 3GPP QoS Model July 2005
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. The format
of this parameter will be provided in an additional version of this
draft.
6. Interworking Scenarios for End-to-End QoS Support
6.1 UE-initiated NSIS signaling
This section describes a 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 +-----+ +----+ +------+ +------+
^ ^
+............+
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.
Jeong, et al. Expires January 19, 2006 [Page 12]
Internet-Draft 3GPP QoS Model July 2005
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 |
|<-------------------+------+-------------------->|
Uplink | | | |
Data | | DiffServ (RMD) |
|....................+------+-------------------->|
| | | |
| PDP Flow | | |
|------------------->| | |
| | | |
===============================================================
| | | |
| Application Layer (e.g., SIP/SDP) |
|<...............................................>|
| | | |
| NSIS Signalling |
|<------------------------------------------------+
Downlink | | | |
Data | | DiffServ (RMD) |
|<...................|<-----+---------------------+
| | | |
| PDP Flow | | |
|<-------------------+ | |
| | | |
Figure 4. UE-initiated NSIS signaling
Jeong, et al. Expires January 19, 2006 [Page 13]
Internet-Draft 3GPP QoS Model July 2005
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.
UE GGSN (QNI) Remote AP Remote Host (QNR)
| | | |
| Application Layer (e.g., SIP/SDP) |
|<...............................................>|
| | | |
| NSIS Signalling |
| <------+-------------------->|
Uplink | | | |
Data | | DiffServ (RMD-QOSM) |
|....................+------+-------------------->|
| | | |
| PDP Flow | | |
|------------------->| | |
| | | |
===============================================================
| | | |
| Application Layer (e.g., SIP/SDP) |
|<...............................................>|
| | | |
| NSIS Signalling |
| <----------------------------+
Downlink | | | |
Data | | DiffServ (RMD-QOSM) |
|<...................|<-----+---------------------+
| | | |
| 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
Jeong, et al. Expires January 19, 2006 [Page 14]
Internet-Draft 3GPP QoS Model July 2005
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.
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. Future Issues
7.1 NSIS signaling within the IP based transport part of UMTS
As emphasized in [5], the RAN 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 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.
7.2 NSIS signaling between UMTS and WiMAX via an IP-based backbone
It is possible that 3GPP networks and WiMAX networks will interwork
via an IP-based backbone network in the future. In this situation,
QoS interwokring will be essential to provide seamless services to
Jeong, et al. Expires January 19, 2006 [Page 15]
Internet-Draft 3GPP QoS Model July 2005
users. Since 3GPP and WiMAX networks will use different QoS models,
QoS model aware signaling should be provided for optimal QoS
interworking. Specifically, for end-to-end QoS support, QoS
interworking between the 3GPP and backbone networks as well as QoS
interworking between the backbone and WiMAX networks should be
supported. NSIS signaling can be used for that purpose in such
heterogeneous network environments. How to provide such QoS
interworking using NSIS is for further study.
7.3 NSIS signaling between UMTS and WLAN via an IP-based backbone
The interworking between 3GPP networks and wireless LANs via an IP-
based backbone will occur in diverse places in the near future. In
this situation, QoS interwokring will be essential to provide
seamless services to users. Since 3GPP networks and wireless LANs
will use different QoS models, QoS model aware signaling should be
provided for optimal QoS interoperability. Specifically, for end-to-
end QoS support, QoS interworking between the 3GPP and backbone
networks as well as QoS interworking between the backbone network and
wireless LANs should be supported. NSIS signaling can be used for
that purpose in such heterogeneous network environments. How to
provide QoS interworking using NSIS is for further study.
8. Security Considerations
There are no new security considerations based on this draft at the
moment. Security considerations will be provided in the later
version of this draft, if any.
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
detailed 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, and Brian
Williams for helpful input/comments and discussion.
11. References
Jeong, et al. Expires January 19, 2006 [Page 16]
Internet-Draft 3GPP QoS Model July 2005
11.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., Karagiannis, G., and A. McDonald, "NSLP for Quality-
of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
progress), February 2005.
[3] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05
(work in progress), July 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.9.0, April 2004.
[7] 3GPP, "Architectural enhancements for end-to-end Quality of
Service (QoS)", 3GPP TR 23.802 1.0.0, June 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.
[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-03 (work in progress), July 2005.
Jeong, et al. Expires January 19, 2006 [Page 17]
Internet-Draft 3GPP QoS Model July 2005
11.2 Informative References
[14] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
April 2004.
[15] 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.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[17] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[18] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[19] 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
Jeong, et al. Expires January 19, 2006 [Page 18]
Internet-Draft 3GPP QoS Model July 2005
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE, Enschede
Netherlands
Email: g.karagiannis@ewi.utwente.nl
Jeong, et al. Expires January 19, 2006 [Page 19]
Internet-Draft 3GPP QoS Model July 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 January 19, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 11:46:51 |