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, , 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, [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, , 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, [RTP-AVC] H. Schulzrinne, S. L. Casner, _RTP Profile for Audio and Video Conferences with Minimal Control_, work in progress, [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, 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]