Internet DRAFT - draft-fodor-intserv-wireless-params
draft-fodor-intserv-wireless-params
INTERNET-DRAFT G. Fodor
Document: draft-fodor-intserv-wireless-params-01.txt F. Persson
Expires: July 2002 B. Williams
Ericsson
January 2002
Proposal on new service parameters (wireless hints) in the
controlled load integrated service
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
ABSTRACT
This report is the sequel of previous work [WI-INTSERV], where the
major issues related to establishing radio bearers suitable for
Integrated Services (IntServ) over wireless access networks in
general were identified and discussed.
Here we address the issue of providing appropriate QoS service over
wireless access networks for applications that request the CL
Service. More precisely, in this report we consider the necessary
parameters that help the wireless network to provide QoS in a
spectrum efficient manner for various applications. We believe that
focusing specifically on the CL service is a reasonable approach,
because we believe CL is the most reasonable service for
applications to request. Without strict quantitative service
requirements, it can be provided over a range of different types of
networks with different QoS mechanisms.
Fodor, Persson, Williams [Page 1]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
Our most important conclusion is that additional QoS parameters are
necessary in the CL service model in order for it to operate
efficiently over wireless accesses.
We consider UMTS networks and propose a set of parameters that make
spectrum efficient radio resource allocation in this specific case
possible. However, we believe that the proposed parameters are
general enough that they can be applicable to other wireless access
technologies (eg. CDMA-2000, bluetooth), also.
1 Table of Contents
1 Table of Contents 2
2 General Background 3
3 QoS enabled End-to-end scenarios with wireless access 4
4 UMTS service classes and parameters 6
5 Proposed IntServ QoS Parameters and Parameter Mapping 10
5.1 Media Description using MIME 10
5.2 Proposed Additional Parameters 11
5.2.1 SDU Format Information 11
5.2.2 Bit Error Ratio (BER) 12
5.2.3 Expected Delay Bound 12
5.2.4 Packet Loss Ratio (PLR) 12
5.2.5 Packet Handling Priority 12
6 Conclusions 13
7 Security Considerations 13
8 IANA Considerations 13
9 References 13
10 Author's Addresses 14
11 Full Copyright 14
Fodor, Persson, Williams [Page 2]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
2 General Background
Within the cellular community, there is an interest to develop
wireless access networks that provide various levels of QoS to
applications rather than just providing a circuit switched voice
service. A prime example of this initiative are the different
standard bodies (eg. 3GPP, 3GPP2) that propose (among other
technologies, such as EDGE) CDMA technology based networks (W-CDMA,
CDMA-2000) to provide access to the Internet. It is expected that
future wireless terminals allow users to run QoS enabled
applications to access services in the Internet and consequently
allow these applications to explicitly specify QoS requirements.
In the context of the _mobile Internet_, it is a requirement for
some type of terminals (eg. a laptop/handheld PC equipped with a
wireless modem) that the QoS enabled application programming
interface (API) is separated from the wireless resource management
part. That is, we expect that QoS enabled applications may use an
API, such as one based on IntServ to request QoS service
independently of the access network interface.
For instance, a conferencing application requesting the CL service
expects the same service behavior (for instance in terms of the
specified traffic and QoS parameters associated with the service) in
the cases when it uses a UMTS, CDMA-2000, or ethernet L2 network to
access the Internet.
Therefore, it is necessary to consider the mapping of the CL
Integrated Service (and its' parameters) over cellular access
networks. Intuitively, this type of mapping should be quite
feasible, because these types of accesses use per-flow resource
management techniques, in some aspects reminiscent of the IntServ
framework.
However, as discussed in detail in [WI-INTSERV] (work in progress),
wireless spectrum is a considerably scarcer resource than bandwidth
in wired accesses and IP backbone networks. Therefore, the traffic
and QoS parameters in e.g. W-CDMA networks are more extensive and
detailed than in the existing IntServ service specifications. For
instance, the CL service builds upon the notion of the lightly
loaded network in terms of expected QoS. While this is a useful
abstraction in a wired IP network, it makes spectrum efficient
wireless resource management rather difficult. Therefore, in this
document we argue that some additional parameters, (_wireless
hints_) would be a useful extension of the current CL IntServ
objects, because of two main reasons:
o Fine granularity QoS description helps the wireless resource
management entities allocate radio resources in a spectrum
efficient manner
o _wireless hints_ make it possible to optimize the radio bearer
service (in terms of radio packet delay/loss, bit errors, etc.)
to better meet end-user expectations.
Fodor, Persson, Williams [Page 3]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
We organize the rest of this report as follows. In Section 2 we
outline a rather general end-to-end scenario where applications
requests QoS services from the Internet over a W-CDMA (UMTS) access
network. In Section 3, we discuss the UMTS service classes and
their QoS parameters. In Section 4 we propose a set of QoS
parameters that should be included in the CL IntServ parameter list
and show how this extended set of parameters allow the spectrum
efficient resource allocation in the access. Section 5 concludes
this report.
3 QoS enabled End-to-end scenarios with wireless access
An end-to-end connection between two hosts may run across many
different QoS domains, and use many different layer 2 connections.
We shall here consider a network with a host which is IntServ
enabled that is requesting service across a cellular wireless access
network (WAN), as shown in the figure below.
+
+
+--++ Terminal /-----\
| | Equipment / \
| UE| | IP |
| | | Network |
+---+\ --------------------- | |- +----+
\ / \ | | \--| UE |
\/ WAN \ /\ / +----+
/\ /--\ /--\ GW \/ \---+-/ Remote
/ \ | | | +--+ /\ | Terminal
/ \| B | B | | |/ \ sss
/ | | | /| | \ sss
| /--\-/--\-/--\ / +--+ | sss
| | | ccc| |ccc |
| | B | ccc| B |ccc |
| | | ccc| |ccc |
| \--/-\--/-\--/ |
\ | | | /
\ | B | B | Radio /
\ | | | Access / Wireless
\ \--/ \--/ Network / Access
\ / Network
\ /
---------------------
ccc sss
B = base ccc = base station sss = application
Station ccc controller sss server
Figure 1 A simple diagram showing UE, WAN-GW, and IP Network chain
In this network architecture, the QoS enabled application is
executing in the terminal equipment (UE). In this draft, the
Fodor, Persson, Williams [Page 4]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
terminal equipment is considered to include the physical device
connecting to the WAN, as well as any additional equipment provided
with service through this connection (e.g. a mobile terminal and a
PC attached to it with a bluetooth connection).
The UE connects to the wider IP network through the Wireless Access
Network. The UE and the WAN GW are the two end points of the
wireless link. The UE supports the radio bearers for the layer 2
connection from the terminal equipment to the WAN GW over which the
terminal equipment traffic flows.
For UMTS, this layer 2 connection is not just a simple link between
the terminal equipment and the WAN GW. Rather, it is a collection
of one or more radio bearers, where each radio bearer has its own
QoS. In addition, a set of classifiers at the IP level identifies
the data packets that are directed to each individual radio bearer.
With UMTS, the terminal equipment has the responsibility for
identifying the radio bearers that it needs, and how it will use
them. The network and terminal equipment then negotiate the radio
bearers delivered (typically the network manages/controls the
allocation of the available radio resources across all the user
requests for radio bearers). At the successful completion of the
radio bearer negotiation, the network and the terminal equipment
will have negotiated a radio bearer with a specific set of
characteristics.
The mechanism for the terminal equipment and the network to
negotiate the establishment/modification/release of radio bearers
shall be referred to as Radio Management. Each type of wireless
access network (eg. W-CDMA, bluetooth)defines the mechanism for
Radio Management (ie. how to establish/modify/remove radio bearers).
The protocols defined also specify the set of QoS capabilities and
parameters that are available for the radio bearers.
Since the radio management function in the terminal equipment in
UMTS has the responsibility to manage the radio bearer requests,
this is the point where radio bearer requirements must be
identified.
The terminal equipment could examine the user traffic and derive
some assumptions about the service requirements from these
(considering well known port numbers), but this mechanism has many
drawbacks. Alternatively, the terminal equipment could use IP
service requirements requested by the application through a QoS API
to determine the radio bearer requirements.
It is believed that platforms supporting multiple interface types
will provide generic (non-interface specific) QoS APIs to
applications. Since an IntServ based API is expected to be widely
available to application developers on some of these platforms, it
is useful to ensure that spectrum efficient radio services can be
provided for applications requesting QoS through an IntServ API. To
Fodor, Persson, Williams [Page 5]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
enable this, a wireless access device would require sufficient
details about the application traffic and its' QoS requirements.
Although the UE has a single wireless interface, it actually
consists of multiple separate radio bearers. In both the upstream
(from the terminal equipment to the WAN) and the downstream (from
the WAN to the terminal equipment) directions, data packets will be
classified for transmission over a selected radio bearer. A traffic
classifier in the UE and the WAN GW has the capability and
flexibility to classify a set of flows, or even an individual IP
flow for each radio bearer. In order to achieve this, it can
examine a range of packet header information including (but not
necessarily limited to) source and destination IP addresses,
protocol, source and destination UDP/TCP port numbers, IPSec SPI,
DSCP, and IPv6 flow label.
The radio management function is responsible for the
establishment/modification/release of the radio bearers. The radio
management function may employ many different mechanisms to
determine what radio bearers are required such as classification of
flows, and configuration.
The radio management function discussed above is the key element for
providing optimal QoS, with spectrum efficient usage of radio
resources. In order to provide an optimal wireless service, the
radio management function must have a good understanding of the IP
service requirements, and how the radio bearers can be tailored to
meet these needs.
Where applications use an IntServ based API to request service, the
radio management function in the UE may utilise this information as
a convenient means to identify the IP service requirements. In
addition, by participating in the IntServ service, the UE can
interact with the IP service.
The IntServ service identifies session establishment/termination, as
well as the QoS requirements for the session. However, the wireless
network offers a much larger 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. Thus, it is important to examine what parameters
may be used within wireless networks. It is then necessary to
consider what information is important to provide to the radio
management function from an application that wishes to operate
efficiently over wireless networks. This information should allow
appropriate radio bearers to be selected, and to determine the
effects of these bearers on the IP service characteristics.
4 UMTS service classes and parameters
We have chosen UMTS as an example of a wireless network, since it
has a fine granularity of control to enhance spectrum efficiency and
operating conditions.
Fodor, Persson, Williams [Page 6]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
The QoS and traffic characteristics of the radio bearers in UMTS, as
specified in [3GPP-L3], are defined by several attributes describing
the traffic characteristics and QoS. Different profiles, or traffic
classes, incorporate different combinations and possible value
ranges of the attributes. There are four traffic classes specified:
Conversational, Streaming, Interactive and Background. When a
service is requested the radio management selects the one that best
corresponds to the requirements.
The two first classes are designed for real-time conversational and
streaming services, respectively. The fundamental characteristics
of the conversational class are low delay and delay variations, and
of the streaming class low delay variations. Low delay variations
are supposed to be achieved by reception buffers, and do not put
requirements on the transport. To achieve higher spectrum
efficiency and to be able to support mechanisms as Unequal Error
Protection (UEP) and Unequal Error Detection (UED), where different
parts of the payload are protected/detected differently [UEP], the
internal payload format can be specified. This is especially
important for codecs like the Adaptive Multi-Rate (AMR) codec [RTP-
AMR].
The two last classes are designed for non-real time services.
Interactive class is used when a request-response pattern (eg. WWW)
is requested, and background class when there are no requirements on
delay (eg. background file transfers). Within the interactive
class, radio bearers are differentiated by a relative priority. In
this way different levels of QoS can be provided for interactive
traffic.
The following list examines the attributes one by one. First there
are a number of descriptors:
o Traffic class is roughly defining the type of application that
the radio bearer is optimized for. It defines also the set of
attributes that can be used for that specific traffic class. It
can eg. be used for admission control (eg. real-time traffic
versus best effort traffic). By including the traffic class
itself as an attribute, UMTS can make assumptions about the
traffic source and optimize the transport for that traffic type.
o Maximum bit rate is defined as the maximum number of bits
delivered by UMTS and to UMTS at an end point of the network
(i.e. the WAN GW or the terminal equipment) within a period of
time, divided by the duration of the period. Its purpose is 1)
to limit the delivered bit rate to applications or external
networks with such limitations 2) to allow maximum wanted user
bit rate to be defined for applications able to operate with
different rates. Maximum bit rate could correspond to the peak
rate (p) in IntServ.
o Guaranteed bit rate is defined as the guaranteed number of bits
delivered by UMTS at an end point of the network (i.e. the WAN GW
or the terminal equipment) within a period of time (provided that
there is data to deliver), divided by the duration of the period.
Fodor, Persson, Williams [Page 7]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
Guaranteed bit rate may be used to facilitate admission control
based on available resources, and for resource allocation within
UMTS. The operator has to provide a service with the quality
requirements expressed by eg. delay and reliability attributes to
the incoming traffic up to the guaranteed bit rate. It is
possible that the operator offers a better service, but also that
the requirement on offered Guaranteed bit rate is violated
(temporarily) if the radio conditions are changed drastically
(eg. if a user moves into an area without any coverage).
Guaranteed bit rate can in some cases be considered as an average
rate, possibly corresponding to the token bucket rate (r) in
IntServ.
o Maximum SDU size or SDU format information defines the maximum
radio SDU size if variable sizes, or the exact payload formats
and sizes if these can be specified, respectively. The maximum
SDU size can eg. be used for policing. Besides that, the
spectral efficiency and delay can be optimized for transparent
transmission, if the exact sizes of the radio SDUs are known.
Transparent transmission is here referring to transmission
without adding any protocol information. Also, mechanisms like
UEP/UED require that the internal payload format is known (see
above). The bearer can thus be less expensive if the application
can specify the payload formats and packet sizes.
o Source statistic descriptor identifies if there is a
characteristic pattern (eg. if the application data has the
typical speech arrival traffic or not). By identifying the
characteristics of the source of submitted radio SDUs, the best
admission control algorithm can be applied.
There are also six attributes describing the provided QoS:
o Transfer delay indicates the maximum delay for the 95th
percentile of the distribution of delay for all delivered radio
SDUs (corresponds to IP packets at the IP side of the end point
of the network) during the lifetime of a radio bearer. Delay for
a radio SDU is defined as the time from a request to transfer a
radio SDU at one end point to its delivery at the other,
including re-transmission delay. It is used to specify the delay
tolerated by the application, which allows UTRAN to set transport
formats and ARQ parameters.
o Delivery order indicates whether the UMTS bearer shall provide
in-sequence radio SDU delivery or not. Whether out-of-sequence
radio SDUs are dropped or re-ordered depends on eg. the specified
SDU error ratio and Residual bit error ratio (see below). By not
having to provide in-sequence delivery the buffer sizes can be
minimized.
o Delivery of erroneous SDUs is used to decide whether error
detection is needed or not, and indicates whether radio SDUs
detected as erroneous shall be delivered or discarded.
o SDU error ratio indicates the fraction of radio SDUs lost or
detected as erroneous. SDU error ratio is defined only for
conformable traffic (i.e. traffic that keeps the agreed bit rate
Fodor, Persson, Williams [Page 8]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
and maximum SDU size). It is only specified if error detection
is used (see above).
o Residual bit error ratio indicates the undetected bit error ratio
in the delivered radio SDUs. If no error detection is requested,
Residual bit error ratio indicates the total bit error ratio in
the delivered radio SDUs.
o Traffic handling priority gives an internal priority handling for
the interactive class. It specifies the relative importance for
handling of all radio SDUs belonging to one specific interactive
bearer compared to the radio SDUs of other interactive bearers.
Even though no absolute guarantees are given for the interactive
class, not all non-real time services have the same QoS
requirements. To be able to provide the proper service behavior
under conditions of spectrum efficiency, there is still a need to
differentiate between interactive bearers. Traffic handling
priority can eg. be used for traffic scheduling and admission
control.
The attributes per traffic class are summarized in Table 3-1.
Traffic class Convers Streaming Interact Backgrnd
-------------------------------------------------------------------
Maximum bit rate X X X X
Guaranteed bit rate X X - -
Maximum SDU size X X X X
SDU format information X X - -
Source statistics descriptor X X - -
Transfer delay X X - -
Delivery order X X X X
Delivery of erroneous SDUs X X X X
SDU error ratio X X X X
Residual bit error ratio X X X X
Traffic handling priority - - X -
Table 3-1 The UMTS attributes defined for each radio bearer traffic
class.
As seen by the descriptions these attributes, some of them are
indeed general also to other wireless systems. Maximum (peak) bit
rate, Guaranteed bit rate, and SDU size are well-known traffic
descriptors. Source statistic descriptor is more UMTS specific, but
still provides quite general information. Almost all of the
wireless networks make use of basic wireless parameters like
Transfer delay, SDU error ratio and Residual bit error ratio.
Parameters similar to SDU format information, Delivery order,
Delivery of erroneous SDUs are found also in other wireless
networks. As indicated above, a gain in service quality and
spectrum efficiency is achieved when specifying the payload format,
the exact packet sizes, and whether erroneous packets should be
discarded or not. This information can be advantageous and utilized
also in other systems. Traffic handling priority is using similar
prioritization as eg. Diffserv.
Fodor, Persson, Williams [Page 9]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
5 Proposed IntServ QoS Parameters and Parameter Mapping
As discussed above, the Radio Management function requires detailed
information about the media stream and its required QoS in order to
optimize the QoS performance from the allocated radio resources.
Chapter 3 has examined the wireless parameters available with UMTS.
It is also necessary to consider how information can be provided by
the application to aid in setting these parameters. The controlled
load service is intended to support a broad class of applications
including _adaptive real-time_ applications. The controlled load
service is intentionally minimal, with no optional functions or
capabilities. However, it is proposed here that the need for
spectrum efficiency while optimizing performance with wireless
networks justifies extending the Controlled Load Service with
additional information.
The additional parameter information to be included must aid in
determining the appropriate setting of the wireless parameters.
Since the application may not know when a wireless link is involved
in the connection, the additional information must not depend on the
actual interface being used. Also, it must be straightforward for
the application to determine appropriate values for these
parameters. The important parameters for radio bearers have been
described above in section 3. This section will propose a set of
information aimed to allow the appropriate radio parameters to be
determined, while being simple for the application to set correctly
(that is to say, selection of the parameter value should be
straightforward for the application).
5.1 Media Description using MIME
Speech applications are typically an important application in
cellular networks. For instance, the AMR codec has been designed
with specific consideration given to spectrum usage, bit error rates
and performance for wireless networks. With the AMR codec, the
media stream contains data of different _classes_ with different
levels of sensitivity to errors (from class A data which is the most
sensitive to bit errors, to class C which is the least sensitive).
To provide optimal spectrum efficiency and performance, it may be
necessary to provide different service to the different class data
(unequal error protection).
In such a case it is also important to specify the format of the
media stream and the QoS associated with the different parts of the
stream. For instance, [RTP-AMR] (work in progress) proposes a
standard RTP payload format to carry AMR and AMR-WB coded speech
samples.
We believe that the description of many media types by means of a
few generic parameters is not realistic because of the large amount
of parameters that would be required to characterize the media and
Fodor, Persson, Williams [Page 10]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
the requested QoS. Also, on-going work [RTP-MIME], [RTP-AVC]
indicate that the majority of the important real time applications
will have RTP encoding names as MIME subtypes.
Therefore, we propose the use of the MIME type registration to
characterize media streams for which the CL integrated service is
requested.
Current on-going work [RTP-MIME] defines the procedure to register
RTP Payload Formats as audio, video or other MIME subtype names.
Furthermore, [RTP-MIME] registers all the RTP payload formats
defined in the RTP Profile for audio- and video conferences as MIME
subtypes. Some of these may also be used for transfer modes other
than RTP.
Using MIME as the media description format has the following
beneficial features:
o It provides a detailed description of the MIME registered media
types. Apart from the Registration Template shown in Section 2.8
of RFC 2048 [MIME], the MIME registration procedure allows to
specify additional parameters, including:
o Published Specification [RFC number]
o _Rate_ parameter: If the payload parameter does not have a
fixed RTP timestamp clock rate, then a _rate_ parameter is
required. A particular payload format may have additional
required parameters.
o Optional parameters, like those mentioned in [RTP-MIME]
(_channel_, _ptime_, or other payload format specific optional
parameters)
o It is flexible in the sense that it facilitates the description
of the relevant media types that are typically carried over the
RTP protocol. We expect that most real time applications will
use RTP, so the MIME description is expected to be a useful hint
on most of the relevant applications. For example, on-going work
within IETF [RTP-AMR] proposes MIME type registration and
associated RTP payload formats for AMR and AMR-WB speech encoded
signals. Standardizing the RTP payload formats and registering
the media type as MIME types provides exact information about all
possible SDU sizes that the wireless network will have to
transport. In addition, standard RTP payloads make unequal error
detection/protection mechanisms possible.
o The MIME type media description is easy to map to fields in the
SDP [SDP], which is commonly used to describe RTP sessions.
5.2 Proposed Additional Parameters
The following are qualitative hints rather than quantitative
parameters.
5.2.1 SDU Format Information
Fodor, Persson, Williams [Page 11]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
As mentioned above, unequal error protection (UEP) plays an
important role in spectrum efficient resource management. UEP
implies that different parts of an IP payload are associated with
different error protection mechanisms when transferring over the air
interface. In order to facilitate this mechanism, information about
the payload format is necessary at the radio level. For some (but
not all) MIME registered media types, parts of this piece of
information may be available. In general, however, the
specification of the SDU format as a service parameter allows any
application to take advantage of the UEP mechanism. Furthermore, in
some cases, the specification of the MIME type is not sufficient to
perform UEP.
The exact format of this parameter is for further study.
5.2.2 Bit Error Ratio (BER)
For real-time applications that use the UDP Lite transport protocol
[UDP-LITE], it can be advantageous to provide rough information
(hint) on the required (tolerated) bit error ratio over the wireless
link. The requested BER reflects trade-off between the quality
degradation that real time applications may suffer from bit errors
caused by the wireless link and the wireless spectrum that the
application actually consumes. A qualitative hint on the required
BER may be _low BER_, _medium BER_ and _high BER_, which, together
with the MIME media description allows the wireless network to
allocate the proper radio resources.
5.2.3 Expected Delay Bound
The expected delay bound is an important parameter that allows the
wireless network to configure the wireless bearer service. For
instance, the appropriate interleaving depth is directly affected by
the specified maximum delay requirement. Also, this parameter is
needed to determine the maximum number of retransmissions (if any)
in the wireless link.
5.2.4 Packet Loss Ratio (PLR)
The packet loss ratio affects the subjective quality of many real
time applications including coded speech and video. On the other
hand, the wireless network uses the target PLR value for admission
control and to set some parameters of the wireless network (eg. L2
buffer size).
5.2.5 Packet Handling Priority
For interactive packet services, the PHP parameter helps the
wireless network to provide QoS differentiation, especially in
congestion situations without the need of complex reservation or
scheduling mechanisms.
Fodor, Persson, Williams [Page 12]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
6 Conclusions
In this report we considered a basic QoS enabled end-to-end scenario
where an IntServ enabled host requests service across a UMTS access
network. We also considered the UMTS parameters that need to be
appropriately configured in order to provide QoS in a spectrum
efficient manner. Based on these considerations we proposed that a
small set of parameters that would help the wireless network to
configure its QoS and resource reservation parameters. This new set
consists of an accurate description of the media for which the
service is requested and some additional quantitative parameters on
bit error ratio, packet loss ratio, maximum transfer delay and
packet handling priority.
7 Security Considerations
TBD
8 IANA Considerations
TBD
9 References
[WI-INTSERV] G. Fodor, F. Persson, B. Williams, _Application of
Integrated Services on Wireless Accesses_, work in progress, <draft-
fodor-intserv-wireless-issues-01.txt>, January 2002
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C., Guerin, R., "Specification
of Guaranteed Quality of Service", RFC 2212, September 1997.
[RFC2997] Bernet, Y., Smith, A., Davie, B., "Specification of the
Null Service Type", RFC 2997, November 2000.
[RTP-MIME] S. Casner, P. Hoschka, _MIME Type Registration of RTP
Payload Formats_, work in progress, <draft-ietf-avt-rtp-mime-
06.txt>
[MIME] N. Fred, J. Klensin and J. Postel, _Multipurpose Internet
Mail Extensions (MIME): Registration Procedures_, RFC 2048, November
1996.
[RTP-AMR] RTP Payload Format and File Storage Format for AMR and
AMR-WB Audio work in progress, <draft-ietf-avt-rtp-amr-07.txt>,
April 2001.
[SDP] M. Handley and V. Jacobson, _SDP: Session Description
Protocol_, RFC 2327, April 1998.
Fodor, Persson, Williams [Page 13]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
[UDP-LITE] Lars-Ake Larzon, Mikael Degermark, Stephen Pink, _The
UDP Lite Protocol_, work in progress, <draft-larzon-udplite-04.txt>
[RTP-AVC] H. Schulzrinne, S. L. Casner, _RTP Profile for Audio and
Video Conferences with Minimal Control_, work in progress, <draft-
ietf-avt-profile-new-10.txt>
[3GPP-L3] 3G.PP, _Mobile Radio Interface Layer 3 Specification,
Core Network Protocols _ Stage 3_, 3G TS 24.008
[UEP] Q. Xie, S. Gupta, _Error Tolerant RTP Payload Format for
AMR_, work in progress, <draft-xie-avt-et-rtp-amr-02.txt>
10 Author's Addresses
Gabor Fodor
Ericsson Research
Ericsson Radio Systems AB
Torshamnsgatan 23
SE-164 80 Stockholm, Sweden
Phone: +46 8 404 3084
Email: Gabor.Fodor@era-t.ericsson.se
Fredrik Persson
Ericsson Research
Ericsson Radio Systems AB
Torshamnsgatan 23
SE-164 80 Stockholm, Sweden
Phone: +46 8 585 30818
Email: Fredrik.F.Persson@era.ericsson.se
Brian Williams
Ericsson AsiaPacificLabs Australia
37/360 Elizabeth St,
Melbourne, Australia, 3000
Phone: +61 3 9301 4675
Email: brian.williams@ericsson.com.au
11 Full Copyright
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
Fodor, Persson, Williams [Page 14]
INTERNET DRAFT New service parameters (wireless Expires July 2002
hints)in the CL integrated service
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Fodor, Persson, Williams [Page 15]
