INTERNET-DRAFT                                                 G. Fodor
Document: draft-fodor-intserv-wireless-params-01.txt         F. Persson
Expires: July 2002                                          B. Williams
                                                           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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is an individual submission to the IETF.  Comments
   should be directed to the authors.


   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

   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

   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

   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-

   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

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

   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

   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

   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

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

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


8   IANA Considerations


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-

   [MIME]   N. Fred, J. Klensin and J. Postel, _Multipurpose Internet
   Mail Extensions (MIME): Registration Procedures_, RFC 2048, November

   [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-

   [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

   Fredrik Persson
   Ericsson Research
   Ericsson Radio Systems AB
   Torshamnsgatan 23
   SE-164 80 Stockholm, Sweden
   Phone: +46 8 585 30818

   Brian Williams
   Ericsson AsiaPacificLabs Australia
   37/360 Elizabeth St,
   Melbourne, Australia, 3000
   Phone: +61 3 9301 4675

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

   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

Fodor, Persson, Williams                                     [Page 15]