One document matched: draft-jeong-nsis-3gpp-qosm-00.txt
IETF Next Steps in Signaling S. Jeong
Working Group HUFS
Internet-Draft S. Lee
Expires: November 18, 2005 J. Bang
BJ. Lee
Samsung AIT
May 17, 2005
3GPP QoS Model for Networks Using 3GPP QoS Classes
draft-jeong-nsis-3gpp-qosm-00.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 November 19, 2005.
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. In particular,
Jeong, et al. Expires November 18, 2005 [Page 1]
Internet-Draft 3GPP QoS Model May 2005
this draft tries to describe a QoS-NSLP QoS model (QOSM) based on
3GPP QoS classes and bearer service attributes.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. 3GPP QoS Classes and Bearer Service Attributes . . . . . . . . 4
3.1 Summary of 3GPP QoS Classes . . . . . . . . . . . . . . . 4
3.1.1 Mapping between the TS 23.107 and Y.1541 QoS
Classes . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 Mapping between the TS 23.107 and DiffServ QoS
Classes . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 QoS Attributes for 3GPP UMTS Bearer Services . . . . . . . 6
4. Additional QSPEC Parameters for 3GPP QOSM . . . . . . . . . . 9
4.1 Token Bucket Extension . . . . . . . . . . . . . . . . . . 9
4.2 Residual Bit Error Ratio . . . . . . . . . . . . . . . . . 10
4.3 Delivery of Erroneous SDU . . . . . . . . . . . . . . . . 10
4.4 Source Statistics Descriptor . . . . . . . . . . . . . . . 10
4.5 Signaling Indication . . . . . . . . . . . . . . . . . . . 11
5. Scenarios for End-to-End QoS Support . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1 Normative References . . . . . . . . . . . . . . . . . . . 14
9.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17
Jeong, et al. Expires November 18, 2005 [Page 2]
Internet-Draft 3GPP QoS Model May 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).
Figure 1 shows a network environment where there are multiple
different QOSMs [3]. One of the representative XG QOSMs shown in the
figure could be 3GPP QOSM.
+----------+ /-------\ /--------\ /--------\
| Laptop | | Home | | Cable | | Diffserv |
| Computer |-----| Network |-----| Network |-----| Network |----+
+----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | |
\-------/ \--------/ \--------/ |
|
+-----------------------------------------------+
|
| /--------\ +----------+
| | "X"G | | Handheld |
+---| Wireless |-----| Device |
| XG QOSM | +----------+
\--------/
Figure 1. An Example Configuration with Multiple Different QOSMs
Jeong, et al. Expires November 18, 2005 [Page 3]
Internet-Draft 3GPP QoS Model May 2005
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. In particular,
this draft tries to describe a QoS-NSLP QoS model (QOSM) based on
3GPP QoS classes and bearer service attributes. 3GPP TS 23.107 [5]
specifies four universal mobile telecommunications system (UMTS) QoS
classes (also called "traffic classes"), and the 3GPP-QOSM extensions
include additional QSPEC parameters which may be optional. The more
detailed description of the 3GPP QOSM will be provided in the later
version of this draft.
3. 3GPP QoS Classes and Bearer Service Attributes
3GPP TS 23.107 specifies four different QoS classes for UMTS, and
these QoS classes support a wide range of user applications. TS
23.107 also describes specific value ranges for each QoS class. 3GPP
TS 203.207 [6] specifies 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 most of generic QoS
parameters, and therefore this draft identifies additional QSPEC
parameters for the 3GPP QOSM.
3.1 Summary of 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
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
Jeong, et al. Expires November 18, 2005 [Page 4]
Internet-Draft 3GPP QoS Model May 2005
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 essential. The
following two subsections illustrate possible mappings between them.
Detailed mappings will be implementation specific.
3.1.1 Mapping between the TS 23.107 and Y.1541 QoS Classes
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 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 of the QoS Classes, 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 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.
3.1.2 Mapping between the TS 23.107 and DiffServ QoS Classes
Jeong, et al. Expires November 18, 2005 [Page 5]
Internet-Draft 3GPP QoS Model May 2005
DiffServ [9] proposes differentiation in the queuing 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, queuing 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 of the QoS Classes, 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 except reliability).
3.2 QoS Attributes for 3GPP UMTS Bearer Services
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) are described below [5].
(a) Traffic class: 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 itself as an attribute, UMTS can make
assumptions about the traffic source and optimize the transport
Jeong, et al. Expires November 18, 2005 [Page 6]
Internet-Draft 3GPP QoS Model May 2005
for that traffic type.
(b) Maximum bitrate (kbps): Maximum bitrate represents the maximum
number of bits delivered by UMTS within a period of time, divided
by the duration of the period. The traffic is conformant with
Maximum bitrate as long as it follows a token bucket algorithm
where token rate equals Maximum bitrate. The Maximum bitrate is
the upper limit a user or application can accept or provide. All
UMTS bearer service attributes may be fulfilled for traffic up to
the Maximum bitrate depending on the network conditions.
(c) Guaranteed bitrate (kbps): Guaranteed bitrate represents the
guaranteed number of bits delivered by UMTS within a period of
time, divided by the duration of the period. The traffic is
conformant with the guaranteed bitrate as long as it follows a
token bucket algorithm where token rate equals Guaranteed bitrate.
UMTS bearer service attributes, e.g., delay and reliability
attributes, are guaranteed for traffic up to the Guaranteed
bitrate. For the traffic exceeding the Guaranteed bitrate the
UMTS bearer service attributes are not guaranteed. This attribute
describes the bitrate the UMTS bearer service shall guarantee to
the user or application. Guaranteed bitrate may be used to
facilitate admission control based on available resources, and for
resource allocation within UMTS.
(d) Delivery order (y/n): Delivery order indicates whether the UMTS
bearer shall provide in-sequence service data unit (SDU) delivery
or not. The SDU may correspond to an IP packet. This attribute
is derived from the user protocol (i.e., packet data protocol
(PDP) type) and specifies if out-of-sequence SDUs are acceptable
or not. Whether out-of-sequence SDUs are dropped or re-ordered
depends on the specified reliability Delivery order should be set
to 'no' for PDP Type = 'IPv4' or 'IPv6'.
(e) Maximum SDU size (octets): Maximum SDU size represents the
maximum SDU size for which the network shall satisfy the
negotiated QoS. The maximum SDU size is used for admission
control and policing and/or optimizing transport. Handling by the
network of packets larger than Maximum SDU size is implementation
specific (e.g., they may be dropped or forwarded with decreased
QoS).
(f) SDU format information (bits): SDU format information represents
the list of possible exact sizes of SDUs. The radio access
network (RAN) needs SDU size information to be able to operate in
transparent radio link control (RLC) protocol mode, which is
beneficial to spectral efficiency and delay when RLC re-
transmission is not used. Thus, if the application can specify
Jeong, et al. Expires November 18, 2005 [Page 7]
Internet-Draft 3GPP QoS Model May 2005
SDU sizes, the bearer is less expensive.
(d) SDU error ratio: SDU error ratio indicates the fraction of SDUs
lost or detected as erroneous. SDU error ratio is defined only
for conforming traffic. By reserving resources, SDU error ratio
performance is independent of the loading conditions, whereas
without reserved resources, such as in Interactive and Background
classes, SDU error ratio is used as target value. This attribute
is used to configure the protocols, algorithms and error detection
schemes.
(h) Residual bit error ratio: Residual bit error ratio indicates the
undetected bit error ratio in the delivered SDUs. If no error
detection is requested, Residual bit error ratio indicates the bit
error ratio in the delivered SDUs. This attribute is used to
configure radio interface protocols, algorithms and error
detection coding.
(i) Delivery of erroneous SDUs (y/n/-): Delivery of erroneous SDUs
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.
(j) Transfer delay (ms): Transfer delay indicates maximum delay for
95th percentile of the distribution of delay for all delivered
SDUs during the lifetime of a bearer service. This attribute is
related to the delay tolerated by the application. In conjunction
with the SDU error ratio attribute, care needs to be taken in
deriving the value for the 95th percentile when an application
desires, for example, that 99.9% of all transmitted packets are
delivered within a certain time. This attribute allows RAN to set
transport formats and ARQ parameters.
(k) Traffic handling priority: Traffic handling priority specifies
the relative importance for handling of all SDUs belonging to the
UMTS bearer compared to the SDUs of other bearers. Within the
interactive class, there is a definite need to differentiate
between bearer qualities. This is handled by using the traffic
handling priority attribute, to allow UMTS to schedule traffic
accordingly. By definition, priority is an alternative to
absolute guarantees, and thus these two attribute types cannot be
used together for a single bearer.
Jeong, et al. Expires November 18, 2005 [Page 8]
Internet-Draft 3GPP QoS Model May 2005
(l) Allocation/Retention Priority: Allocation/Retention Priority
specifies the relative importance compared to other UMTS bearers
for allocation and retention of the UMTS bearer. Priority is used
for differentiating between bearers when performing allocation and
retention of a bearer. In situations where resources are scarce,
the relevant network elements can use the Allocation/Retention
Priority to prioritize bearers with a high Allocation/Retention
Priority over bearers with a low Allocation/Retention Priority
when performing admission control.
(m) Source statistics descriptor ('speech'/'unknown'): Source
statistics descriptor 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
statistical multiplex gain for use in admission control on the
relevant interfaces.
(n) Signaling Indication (Yes/No): Signaling Indication 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.
4. Additional QSPEC Parameters for 3GPP QOSM
Among the attributes described in Section 3, most of relevant
attributes for QSPEC have been specified in [3]. Additional
parameters which may need to be specified further include Guaranteed
bitrate, Source statistics descriptor, Delivery of erroneous SDUs,
Residual bit error ratio, and Signaling Indication. This section
briefly describes the format of these additional parameters which may
be optional in QSPEC. More detailed description and other possible
parameters will be provided in the later version of this draft.
4.1 Token Bucket Extension
The <Token Bucket Extension> parameter, "Guaranteed bitrate (Gbr)" is
represented by a floating point number in the single-precision IEEE
floating point format.
Jeong, et al. Expires November 18, 2005 [Page 9]
Internet-Draft 3GPP QoS Model May 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Guaranteed Bit Rate [Gbr] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sign bit MUST be zero (all values MUST be non-negative) and
Exponents less than 127 (i.e., 0) are prohibited. Exponents greater
than 162 (i.e., positive 35) are discouraged, except for specifying
the rate of infinity. Infinity is represented with an exponent of
all ones (255) and a sign bit and mantissa of all zeroes.
4.2 Residual Bit Error Ratio
Residual Bit Error Ratio (BER) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Residual Bit Error Ratio (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 Delivery of Erroneous SDU
Delivery of Erroneous SDU (DES) (2 bits) parameter is represented as
follows.
+------------+
| DES(2bits) |
+------------+
Three values of DES are listed below to indicate different meanings.
0 - 'No'
1 - 'Yes'
2 - '-'
4.4 Source Statistics Descriptor
Source statistics descriptor (SSD) parameter is represented as
follows. Different sources has a different value.
Jeong, et al. Expires November 18, 2005 [Page 10]
Internet-Draft 3GPP QoS Model May 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source statistics descriptor [SSD] (32 bit) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.5 Signaling Indication
Signaling Indication (SI) parameter is represented as follows.
+-----------+
| SI (1bit) |
+-----------+
Two values of SI are listed below to indicate different meanings.
0 - 'No'
1 - 'Yes'
5. Scenarios for End-to-End QoS Support
This section describes end-to-end scenarios that may occur from a UE
connected to a UTMS network. The Figure 2 shows a network
architecture [6] used to explain the scenario which illustrates how
end-to-end QoS is delivered in the network environment where 3GPP and
non-3GPP networks co-exist.
^ +-----+ +----+ +------+ +------+
IP | | | IP Bearer | | //------\\ | | | |
Bearer | | | Service | | | | | | | |
Layer | | |<----------| |-+---------+-| |-->| |
V |Local| | | | | |Remote| |Remote|
============|UE |===========|GGSN| | Backbone| |Access|===|Host |
Access ^ | | | | | IP | |Point | | |
Bearer | | | +----+ | | | Network | | | | |
Layer | | |<-|SGSN|-->| | | | | |<->| |
(eg. UMTS | | | +----+ | | \\------// | | | |
Bearer) V +-----+ +----+ +------+ +------+
^ ^
+............+
Scope of PDP Context
Jeong, et al. Expires November 18, 2005 [Page 11]
Internet-Draft 3GPP QoS Model May 2005
Figure 2. An End-to-End Network Architecture
It is assumed that the UE performs an IP bearer service (BS) manager
function which enables end-to-end QoS using IP-based signaling (e.g.,
NSIS signaling) towards the remote end. It is also assumed that the
GGSN supports DiffServ edge functions, and that the backbone IP
network is DiffServ enabled. The application layer (e.g., SIP/SDP)
between the end hosts identifies the QoS requirements. The QoS
requirements from application layer are mapped down to create an NSIS
session. The UE shall establish the PDP context suitable for support
of the NSIS session. The GGSN may use information regarding the PDP
context in order to select the appropriate DiffSer setting to apply.
It may be possible for the GGSN to support the mappting between TS
23.107 and Y.1541 QoS classes.
UE GGSN Remote AP Remote Host
| | | |
| Application Layer (eg. SIP/SDP) |
|<...............................................>|
| | | |
| NSIS Signalling |
|...........................+-------------------->|
Uplink Data | | | |
| | DiffServ |
|....................+------+-------------------->|
| | | |
| PDP Flow | | |
|------------------->| | |
| | | |
================================================================== | | | |
| Application Layer (eg. SIP/SDP) |
|<...............................................>|
| | | |
| NSIS Signalling |
|<..........................|<--------------------+
Downlink Data| | | |
| | DiffServ |
|<...................|<-----+---------------------+
| | | |
| PDP Flow | | |
|<-------------------+ | |
| | | |
Figure 3. An End-to-End Scenario
Jeong, et al. Expires November 18, 2005 [Page 12]
Internet-Draft 3GPP QoS Model May 2005
The control of the QoS over the UMTS access network (from the UE to
the GGSN) may be performed either from the terminal using the PDP
context signaling. Alternatively, subscription data accessed by the
SGSN may override the QoS requested via signaling from the UE. In
this scenario, the terminal supports signaling via the NSIS protocol
to control the QoS at the local and remote accesses.
The QoS for the wireless access is provided by the PDP context. The
UE may control the wireless QoS through signaling for the PDP
context. The characteristics for the PDP context can be derived from
the NSIS signaling information.
The end-to-end QoS is provided by a local mechanism in the UE, the
PDP context over the UMTS access network, DiffServ through the
backbone IP network, and DiffServ in the remote access network in the
scenario shown in Figures 2 and 3. The NSIS signaling may control
the QoS at both the local and remote accesses. This function may be
used to determine the characteristics for the PDP context, so the UE
may perform the interworking between the NSIS signaling and PDP
context. The UE may provide control of the DiffServ (although this
may be overwritten by the GGSN), and in effect, determine the
appropriate interworking between the PDP context and DiffServ.
An example scenario for end-to-end QoS signaling is described below.
- 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 UE.
- Upon receiving the Activation PDP Context Accept message, the QoS-
NSLP at the UE as a QoS NSIS Initiator (QNI) sends a QoS-NSLP
RESERVE message containing the Initiator QSPEC to the next hop in
the external IP network through the GGSN. The Initiator QSPEC
specifies parameters specific to the 3GPP QOSM and other generic
QSPEC parameters for the flow. The GGSN processes the NSIS
RESERVE message based on the PDP context and performs the
translation function for mapping between UMTS QoS classes and
DiffServ classes.
Jeong, et al. Expires November 18, 2005 [Page 13]
Internet-Draft 3GPP QoS Model May 2005
In the example above, the Create PDP Context Request message was
created before sending the NSIS message. However, it is also
possible to trigger the Create PDP Context Request message after
receiving the RESERVE message. Note that QoS mapping between the UMTS
and DiffServ QoS classes may occur at the UE and GGSN. The signaling
procedure for QoS interworking between Y.1541 and UMTS QoS Classes may
be similar to the procedure described above.
6. 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.
7. 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 [RFC2434]. [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 five new objects for the QSPEC Template, as
detailed in Section 4. Values are to be assigned for them from the
NTLP Object Type registry.
8. Acknowledgements
The authors thank Jerry Ash and Al Morton for very helpful comments
and discussion.
9. References
9.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-03
(work in progress), February 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.
Jeong, et al. Expires November 18, 2005 [Page 14]
Internet-Draft 3GPP QoS Model May 2005
[5] 3GPP TS 23.107 : Quality of Service (QoS) concept and architecture
(Release 6), V6.2.0, Dec. 2004.
[6] 3GPP TS 23.207 : End-to-end Quality of Service (QoS) concept and
architecture (Release 6), V6.4.0, Sept. 2004.
9.2 Informative References
[7] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[8] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[9] 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
Jong Ho Bang
Samsung Advanced Institute of Technology
Comm. and Network Lab.
San 14-1, Nongseo-ri, Giheung-eup
Jeong, et al. Expires November 18, 2005 [Page 15]
Internet-Draft 3GPP QoS Model May 2005
Yongin-si, Gyeonggi-do 449-712
KOREA
Phone: +82 31 280 9585
Email: jh0278.bang@samsung.com
Byoung-Joon 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 9626
Email: bj33.lee@samsung.com
Jeong, et al. Expires November 19, 2005 [Page 16]
Internet-Draft 3GPP QoS Model May 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 November 19, 2005 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 11:47:45 |