idnits 2.17.1 draft-westberg-realtime-cellular-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 7, 2001) is 8359 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '6' is defined on line 391, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 398, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 401, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 404, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 408, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-03) exists of draft-montenegro-pilc-ltn-02 ** Downref: Normative reference to an Informational draft: draft-montenegro-pilc-ltn (ref. '16') -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Lars Westberg, Ericsson 3 INTERNET-DRAFT Morgan Lindqvist, Ericsson 4 Expires: December 2001 Sweden 5 June 7, 2001 7 Realtime Traffic over Cellular Access Networks 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/lid-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is an individual submission to the IETF. Comments 31 should be directed to the authors. 33 Abstract 35 The draft discusses problems with transport of realtime traffic over 36 cellular access channels and their implications for protocol 37 enhancements. 39 Cellular Access Networks 41 1. Realtime services over cellular access channels - 42 background and motivation 44 Emerging realtime services in the Internet, such as VoIP (Voice over 45 IP), impose new requirements on cellular access networks. Support for 46 these new services in cellular access networks may be provided in a 47 number of ways, ranging from interworking (e.g., terminating the IP 48 protocols in the fixed network and using other optimized protocols 49 over the cellular link) to transferring the IP packets end-to-end 50 over the cellular links. Transferring the IP packets end-to-end 51 allows the use of standard applications in the cellular terminal and 52 is therefore an important alternative. 54 Most of the work so far has been focused on transmission of best 55 effort traffic over wireless and not on the time critical 56 applications. End-to-end VoIP applications are possible to use in the 57 new generation of cellular networks, but the efficiency of radio 58 spectrum usage must be improved for such applications. Combining 59 spectrum efficiency, high quality speech and short delay calls for 60 new solutions. 62 The usual way to transport the IP packets in a radio network is to 63 use retransmissions over the radio link in order to obtain similar 64 characteristics as in the fixed network. This, however, will cause 65 long delays for speech, which in turn entails poor conversational 66 quality. Instead we need to solve the problems arising in the radio 67 network by enhance some parts of the protocol suite. 69 The scenario we are considering is one where two mobile stations 70 (MSs) are connected to a common fixed network through cellular links. 72 Mobile Base Base Mobile 73 Station Station Station Station 75 ! ~ ~ ~ ~ ~ ~ ~ Y Y ~ ~ ~ ~ ~ ~ ~ ! 76 ! ! ! ! 77 !----! ! ! !----! 78 ! ! ! ! ! ! 79 ! MS ! ! ! ! MS ! 80 !----! !++++++++! !----! 82 Fixed Network 84 The mobile stations contain a Voice-Over-IP application and a full IP 85 stack. The application generates audio, video and application- 86 specific session signaling, e.g., SIP/H.323. The audio/video is 87 transported over RTP/UDP/IP, while the application-specific signaling 88 Cellular Access Networks 90 uses TCP and/or UDP. The cellular access is treated as a layer 2 (L2) 91 network with functionality for optimizing the performance on the 92 cellular link. 94 In this document, we summarize some of the requirements on the layers 95 that must be met in order to achieve good speech quality and spectrum 96 efficiency when transferring IP packets transparently over the 97 cellular access. It should be noted that due to the spectrum cost of 98 the transparent solution, alternative solutions such as interworking 99 also deserve to be considered. Such solutions, however, are not 100 discussed in this draft. 102 It should also be pointed out that some of the problems with realtime 103 packets over cellular access might only be solvable with "wireless 104 aware" terminals, meaning that not only the link layers, but also the 105 IP stack must be "wireless aware". However, all terminals and 106 applications will not be "wireless aware". Interworking between the 107 two classes of terminals/applications can be solved by gateways in 108 the fixed network. 110 2. Cellular access performance and system cost 112 The cellular radio access puts tough requirements on end-to-end 113 packet transmission. Packet transmission over the cellular access is 114 typically constrained by two factors: 116 - The high cost of cellular access links. Cellular bandwidth with 117 high quality imposes high system cost. 119 - The lossy link behavior. The radio network generates a high BER. 120 If retransmission over the radio link is not used, the BER may 121 be in the order of 10e-3. 123 2.1. System Cost - Selection of BER for the radio link 125 In wireless systems there is a close relationship between the BER and 126 the SNR (signal-to-noise ratio) of the radio channel. Furthermore, 127 the required SNR (corresponding to a selected BER requirement) can be 128 directly related to the system capacity, i.e. the number of users per 129 cell. Fewer users result in lower income, which in the end result in 130 higher system cost. 132 The cellular access network has wide area coverage and if the service 133 requires more spectrum, the whole network capacity will be affected 134 due to the mobility of the users. A poor spectrum usage for Voice 135 over IP will cause much more cost for hardware in base stations than 136 other more optimized services e.g. circuit switched voice. 138 Cellular Access Networks 140 Another important factor is the cost of the spectrum itself. The 141 spectrum is a limited resource and is licensed by the cellular 142 operator. The cost for licensed RF-spectrum is estimated to be 30% 143 [18] of the total operating cost and therefore represents a 144 significant cost for the cellular operator. 146 A typical circuit switched voice service requires a target BER of 147 10e-3. If the BER requirement is changed from 10e-3 to 10e-6, this 148 might result in a decreased spectrum efficiency of 25-50%, depending 149 on the type of cellular system and the underlying radio conditions. 150 This will increase system costs significantly. An efficient use of 151 the spectrum resource is crucial. 153 2.2. Lossy links - Design of link layer protocol based on radio 154 requirements 156 If the radio link characteristics are not considered in the link 157 layer design, the services will be more costly, or the performance in 158 terms of speech quality will be poor. The design of current protocols 159 is based on the transmission characteristics of fixed networks, so 160 these are not well suited to the radio requirements. A good trade-off 161 between the requirements of transmission (BER and packet loss) and 162 the design of the protocols is crucial. 164 The quality in a radio system (expressed for instance as the BER) 165 typically changes from one 20 ms radio frame to another due to fading 166 in the radio channel. For example, in a cellular system where the 167 target BER has been set to 10e-3, the BER might vary, roughly 168 speaking, from 10e-4 to 10e-2. However, the average BER will equal 169 the target BER. Thus, for the system capacity to remain unaffected, 170 the link layer protocols and speech coders must tolerate that the BER 171 exceeds the BER target for limited periods of time. 173 Another important aspect is the long round-trip time (RTT). Even if 174 we use channels without retransmission over the radio link, the 175 unidirectional delay might be important to consider for some link 176 layer functions, such as header compression. 178 Delay in cellular systems is caused by several reasons. Forward Error 179 Correction (FEC) and interleaving are used to increase the radio 180 channel performance. A typical cellular radio channel gives, without 181 any improvements, approximately 10% BER. With interleaving and FEC, 182 the radio channel can provide the proper channel performance (as 183 discussed above) for the service. But this introduces a fixed delay 184 for the channel. In some cellular systems, the algorithmic channel 185 RTT-delay is in the order of 80ms. 187 Other sources of delay are DSP-processing, node internal delay and 188 transmission. In all cellular system, the overall delay budget is 189 Cellular Access Networks 191 optimized to achieve optimal performance for service quality and 192 spectrum efficiency. 194 It is difficult to state a generally valid value for the RTT. Some 195 RTT figures (e.g. 200 ms) are mentioned in [16], but the delay might 196 be shorter for the case of radio channels optimized for real-time, 197 100-200 ms if the speech coding is excluded. One may compare the RTT 198 (Mobile->PSTN-GW->Mobile) for circuit switched speech, with the 199 "long-term objective value" which is stated to be less than 180 ms 200 for GSM-FR (GSM full-rate speech codec) in [17]. 202 3. Transport of realtime IP flows over cellular 204 We summarize the problems of transporting realtime packets over 205 cellular links and the implications of these problems for protocol 206 enhancements in wireless transmission. 208 3.1. Layer 2 enhancements for realtime traffic 210 To efficiently transfer audio and video streams over the radio 211 channels, these flows should be identified and de-multiplexed. 212 Identification of realtime flows could be carried out by heuristic 213 rules, as proposed in [12]. One of the problems is that the radio 214 channels still need to be adapted to the characteristics of the 215 compressed information. The BER assignment might be different for 216 audio and video. We might also differentiate the redundancy coding of 217 the compressed payload, something that requires a detailed knowledge 218 of the payload. 220 Therefore, for RTP flows that have dynamically assigned payload type 221 indicator (PTI) values [13], the identification of codec type is 222 important in order to allow simple layer 2 identification of the 223 compressed payload type. 225 Apart from the problems of transporting the payload, we also have to 226 perform optimization of the protocol headers [14] for real-time 227 traffic. One of the major problems here is that the compression 228 algorithm must work well in the radio environment with its link 229 delay, and also be resistant to bit errors. The current header 230 compression scheme [14] is sensitive to bit errors, as is shown in 231 [15]. 233 Cellular Access Networks 235 3.2. Transport of audio over cellular 237 3.2.1. Properties of speech codecs designed for cellular networks 239 A cellular access link is very lossy and expensive compared to fixed 240 lines. Furthermore telephony is a real-time service where 241 retransmissions should be avoided. Thus the speech decoder should 242 receive not only error-free speech frames but also frames with errors 243 [1]. If all erroneous speech frames are dropped, the frame error rate 244 (FER) will be high. With a high FER, it is not possible to produce 245 speech with an acceptable quality. In cellular telephony systems, 246 this problem is overcome by delivering all frames to the speech 247 decoder, regardless of bit errors. 249 The sensitivity to errors varies widely between different bits in a 250 frame of encoded speech. High error sensitivity means that an error 251 in that bit results in a severe degradation in speech quality. In 252 most cellular speech codecs for 2nd generation mobile systems (GSM, 253 TDMA or PDC), the bits are divided into three classes: 1a, 1b and 2. 254 Class 1a (the most sensitive bits) and 1b (medium sensitive bits) are 255 protected by convolutional coding. Class 1a bits are in addition 256 covered by a CRC. Class 2 bits (the least sensitive bits) are not 257 protected at all. This scheme results in a reduced FER, since a frame 258 is considered erroneous only if there are errors in the class 1a bits 259 (which on average amount to one third of the total number of bits). 260 On the other hand, the scheme also leaves undetected residual errors 261 in class 1b and class 2. However, it is better, from a speech quality 262 point of view, to allow some errors in these bits than to discard the 263 whole frame as soon as bit errors occur, and let the ECU (see 3.2.2 264 below) reconstruct the frame [2][3][4]. 266 3.2.2. Error Concealment Unit (ECU) 268 If the CRC for the class 1a bits is corrupt, there are severe errors 269 in the speech frame, which probably would give rise to annoying 270 distortions. The frame is therefore discarded, and instead the speech 271 decoder generates artificial speech that closely resembles that of 272 the previous frames. In this way the decoder attempts to mask the 273 distortion. The component carrying out this task is called the error 274 concealment unit (ECU). The ECU reconstructs the frame based on the 275 corrupt version of it that was received as well as the last good 276 frame. Using the bad frame itself increases the speech quality if the 277 number of damaged bits in the frame is not too high. 279 In most speech coders with a 20 ms frame size, the ECU is a state 280 machine with 6 states. When several consecutive lost/bad frames are 281 encountered, the ECU proceeds to the next state for each new frame 282 (until it reaches state 6). The amplitude of the generated speech is 283 Cellular Access Networks 285 gradually reduced in the states, and in state 6, the speech is 286 completely muted. 288 If the decoder receives a good frame when the ECU is in state 1-5, it 289 immediately switches back to normal decoding mode. If the ECU is in 290 state 6 when a good frame is received, the decoder awaits the next 291 frame. If this frame is also good, the decoder switches back to 292 normal decoding mode, otherwise it remains in state 6. This feature 293 is added to eliminate sound spikes when recovering from a long 294 sequence of lost/bad frames. It also mitigates the effects of 295 residual bit errors in the class 1a bits. 297 3.2.3. Adaptive buffer management 299 In order to minimize the end-to-end delay, an adaptive buffer manager 300 (ABM) is useful, another term is adaptive play-out buffer. The 301 function of the adaptive buffer manager is to change the buffer size 302 in order to allow as many packets as possible to reach the speech 303 decoder in time, while keeping the buffering delay to a minimum. 305 To achieve good performance, the ABM should treat the packets with 306 bit errors in the payload as normal packets, not as late packets. 307 Otherwise, the buffer size might be larger than necessary. 309 3.3. Transport of Video 311 The transport of compressed video, intended for conversational 312 services (i.e., videophone) over cellular links, entails some unique 313 requirements. One is that, delay must be kept under strict control. 314 Cellular links also have other error characteristics than fixed 315 networks, something that may cause problems. 317 One way to fulfil the requirements (real-time and limited delay) is 318 to allow bit errors in the payload in the same way as for speech. 319 Errors in the payload are of course not permissible for all type of 320 packets, and not even for all video streams. However, a number of 321 existing video compression standards (e.g. H.263 and MPEG4) have 322 error-resilient modes that facilitate resynchronization of the 323 decoder and improves performance on parts with errors in them. 325 3.3.1. Conversational video in a wireless environment 327 Wireless channels have high bit error rates. These high bit error 328 rates will result in requirements on retransmission, if all packets 329 delivered to the application must be error-free. This is not a good 330 solution for conversational applications, as was explained above. 332 Cellular Access Networks 334 There are, at least, two possible ways to implement a conversational 335 service over channels with high bit error rate. One is to use strong 336 forward error correction; another is to have an error-robust method 337 of video compression (usually called error-resilient source coding). 338 Many experiments (ITU, MPEG, ARIB, 3GPP) have shown that for a 339 wireless channel, error-resilient source coding [5] outperforms 340 methods using forward error correction codes. 342 4. Conclusions 344 Spectrum efficient transmission of audio and video packets is 345 extremely important in cellular access. Spectrum constitutes a 346 significant cost for the operator and must be considered in the 347 development of end-user services. To facilitate effective transport 348 of voice and video in a cellular system, some improvements of the IP 349 protocol suite are needed. Some of the changes are related to the 350 link layer and some to the behavior of RTP (real-time protocol). 352 The following improvements are identified: 354 - Simple identification of codec type in the link layer. The 355 knowledge of codec type enables enhancement of the performance 356 over the wireless link. 358 - BER-resistant header compression algorithm for RTP/UDP/IP. The 359 header compression algorithm also has to work well in an 360 environment with long round-trip delays. 362 - No dropped packets due to bit errors in the payload. The speech 363 decoder and the buffer manager perform better if they can access 364 all packets, also those that contain bit errors. 366 - Use of CRC for the most sensitive bits in the payload in order 367 to detect bit errors. This improves the performance of the 368 speech decoder. 370 Cellular Access Networks 372 5. References 374 [1] European digital cellular telecommunication system (Phase 2): 375 Radio transmission and reception (GSM 05.05), European 376 Telecommunications Standards Institute, October 1993. 378 [2] European digital cellular telecommunication system (Phase 2): 379 Channel coding (GSM 05.03), European Telecommunications 380 Standards Institute, October 1993. 382 [3] TIA/EIA/IS-641, Interim Standard, TDMA Cellular/PCS radio 383 interface - Enhanced Full-Rate Speech Codec, May 1996. 385 [4] Association of Radio Industry and Business, RCR STD-27F, 1997. 387 [5] Signal Processing, Image Communication, Special Issue on Error 388 Resilience, Volume 14, Nos. 6-8, May 1999, page 443-676, ISSN 389 0923-5965, Guest Editors: J.C Brailean, T. Sikora and T. Miki. 391 [6] Video coding for low bit rate communication, Recommendation 392 H.263 (02/98), International Telecommunication Union. 394 [7] Multiplexing protocol for low bit rate multimedia communication, 395 Recommendation H.223 (03/96) with later annexes (A,B,C 02/98), 396 International Telecommunication Union. 398 [8] Information Technology -- Very low bitrate audio-visual coding - 399 Part 2: Visual, ISO/IEC 14496-2 ("MPEG4"). 401 [9] Association of Radio Industry and Business, Test results of 402 video multimedia codec simulation, ICWG 16-4, July 17, 1998. 404 [10] Association of Radio Industry and Business, Report of ARIB IMT- 405 2000 Video Multimedia Codec Simulation Test, ICW-VMG35-, March 406 18, 1999. 408 [11] 3rd Generation Partnership Project (3GPP), TSG-SA Coding Working 409 Group, "QoS for Speech and Multimedia Codec Quantitative 410 performance evaluation of H.324 Annex C over 3G", TR 26.116 411 (working document). 413 [12] Heuristics for utilizing ISSL Mechanisms for A/V Streams over 414 Low Bandwidth Links in the absence of Announcement Protocols, 415 IETF, draft-putzolu-heuristic-00.txt (work in progress). 417 [13] RTP Profile for Audio and Video Conferences with Minimal 418 Control, IETF, ietf-avt-profile-new-05.txt (work in progress). 420 [14] Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, IETF, 421 RFC 2508. 423 Cellular Access Networks 425 [15] CRTP over cellular radio links, IETF, 426 draft-degermark-crtp-cellular-01.txt (work in progress). 428 [16] Long Thin Networks, IETF, draft-montenegro-pilc-ltn-02.txt 429 (work in progress). 431 [17] European digital cellular telecommunication system (phase 1): 432 Technical Performance Objectives, GSM 03.05, version 3.2.0. 434 [18] Wireless Voice-over-IP and Implications for Third-Generation 435 Network Design, Bell Labs Technical Journal, September 1998 437 6. Authors' addresses 439 Lars Westberg 440 Ericsson Research 441 E-mail: rtiow@era-t.ericsson.se 443 Morgan Lindquist 444 Ericsson Research 445 E-mail: morgan.lindqvist@era.ericsson.se 447 This Internet-Draft expires December 7, 2001.