idnits 2.17.1 draft-johansson-rmcat-scream-cc-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 2, 2015) is 3337 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-sarker-rmcat-cellular-eval-test-cases-00 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-newcwv-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMCAT WG I. Johansson 3 Internet-Draft Z. Sarker 4 Intended status: Informational Ericsson AB 5 Expires: September 3, 2015 March 2, 2015 7 Self-Clocked Rate Adaptation for Multimedia 8 draft-johansson-rmcat-scream-cc-05 10 Abstract 12 This memo describes a rate adaptation algorithm for conversational 13 video services. The solution conforms to the packet conservation 14 principle and uses a hybrid loss and delay based congestion control 15 algorithm. The algorithm is evaluated over both simulated Internet 16 bottleneck scenarios as well as in a LTE (Long Term Evolution) system 17 simulator and is shown to achieve both low latency and high video 18 throughput in these scenarios. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 3, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of SCReAM Algorithm . . . . . . . . . . . . . . . . 3 58 3.1. Congestion Control . . . . . . . . . . . . . . . . . . . 4 59 3.2. Transmission Scheduling . . . . . . . . . . . . . . . . . 5 60 3.3. Media Rate Control . . . . . . . . . . . . . . . . . . . 5 61 4. Detailed Description of SCReAM . . . . . . . . . . . . . . . 5 62 4.1. SCReAM Sender . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1.1. Constants and Parameter values . . . . . . . . . . . 7 64 4.1.2. Network congestion control . . . . . . . . . . . . . 11 65 4.1.2.1. Congestion window update . . . . . . . . . . . . 12 66 4.1.2.2. Transmission scheduling . . . . . . . . . . . . . 15 67 4.1.3. Video rate control . . . . . . . . . . . . . . . . . 16 68 4.2. SCReAM Receiver . . . . . . . . . . . . . . . . . . . . . 19 69 5. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 20 70 6. Additional features . . . . . . . . . . . . . . . . . . . . . 21 71 6.1. Packet pacing . . . . . . . . . . . . . . . . . . . . . . 21 72 6.2. Frame skipping . . . . . . . . . . . . . . . . . . . . . 21 73 6.3. Q-bit semantics (source quench) . . . . . . . . . . . . . 23 74 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24 76 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 10. Source code . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 80 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 81 14. Change history . . . . . . . . . . . . . . . . . . . . . . . 25 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 15.1. Normative References . . . . . . . . . . . . . . . . . . 26 84 15.2. Informative References . . . . . . . . . . . . . . . . . 26 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 87 1. Introduction 89 Congestion in the internet is a reality and applications that are 90 deployed in the internet must have congestion control schemes in 91 place not only for the robustness of the service that it provides but 92 also to ensure the function of the currently deployed internet. As 93 the interactive realtime communication imposes a great deal of 94 requirements on the transport, a robust, efficient rate adaptation 95 for all access types is considered as an important part of 96 interactive realtime communications as the transmission channel 97 bandwidth may vary over time. Wireless access such as LTE, which is 98 an integral part of the current internet, increases the importance of 99 rate adaptation as the channel bandwidth of a default LTE bearer 100 [QoS-3GPP] can change considerably in a very short time frame. Thus 101 a rate adaptation solution for interactive realtime media, such as 102 WebRTC, must be both quick and be able to operate over a large span 103 in available channel bandwidth. This memo describes a solution,named 104 SCReAM, that is based on the self-clocking principle of TCP and uses 105 techniques similar to what is used in a new delay based rate 106 adaptation algorithm, LEDBAT [RFC6817]. Because neither TCP nor 107 LEDBAT was designed for interactive realtime media, a few extra 108 features are needed to make the concept work well within this 109 context. This memo describes these extra features. 111 1.1. Wireless (LTE) access properties 113 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] introduces the 114 complications that can be observed in wireless environments. 115 Wireless access such as LTE can typically not guarantee a given 116 bandwidth, this is true especially for default bearers. The network 117 throughput may vary considerably for instance in cases where the 118 wireless terminal is moving around. 120 Unlike wireline bottlenecks with large statistical multiplexing it is 121 not possible to try to maintain a given bitrate when congestion is 122 detected with the hope that other flows will yield, this because 123 there are generally few other flows competing for the same 124 bottleneck. Each user gets its own variable throughput bottleneck, 125 where the throughput depends on factors like channel quality, network 126 load and historical throughput. The bottom line is, if the 127 throughput drops, the sender has no other option than to reduce the 128 bitrate. In addition, the grace time, i.e. allowed reaction time 129 from the time that the congestion is detected until a reaction in 130 terms of a rate reduction is effected, is generally very short, in 131 the order of one RTT (Round Trip Time). 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC2119 [RFC2119] 139 3. Overview of SCReAM Algorithm 141 The core SCReAM algorithm has similarities to concepts like self- 142 clocking used in TFWC [TFWC] and follows packet conservation 143 principles. The packet conservation principle is described as an 144 important key-factor behind the protection of networks from 145 congestion [FACK]. 147 The packet conservation principle is realized by including an 148 indication of the highest received sequence number in the feedback, 149 see Section 5, from the receiver back to the sender, the sender keeps 150 a list of transmitted packets and their respective sizes. This 151 information is then used to determine how many bytes can be 152 transmitted. A congestion window puts an upper limit on how many 153 bytes can be in flight, i.e. transmitted but not yet acknowledged. 154 The congestion window is determined in a way similar to LEDBAT 155 [RFC6817]. This ensures that the e2e latency is kept low. The basic 156 functionality is quite simple, there are however a few steps to take 157 to make the concept work with conversational media. These will be 158 briefly described in sections Section 3.1 to Section 3.3. 160 The rate adaptation solution constitutes three parts- congestion 161 control, transmission scheduling and media rate adaptation. All 162 these three parts reside at the sender side. The receiver side 163 algorithm is very simple in comparison as it only generates 164 acknowledgements to received RTP packets. 166 3.1. Congestion Control 168 The congestion control sets an upper limit on how much data can be in 169 the network (bytes in flight); this limit is called CWND (congestion 170 window) and is used in the transmission scheduling. 172 The SCReAM congestion control method, uses LEDBAT [RFC6817] to 173 measure the OWD (one way delay). The SCReAM sender calculates the 174 congestion window based on the feedback from SCReAM receiver. The 175 congestion window is allowed to increase if the OWD is below a 176 predefined target, otherwise the congestion window decreases. The 177 delay target is typically set to 50-100ms. This ensures that the OWD 178 is kept low on the average. The reaction to loss events is similar 179 to that of loss based TCP, i.e. an instant reduction of CWND. 181 LEDBAT is designed with file transfers as main use case which means 182 that the algorithm must be modified somewhat to work with rate- 183 limited sources such as video. The modifications are 185 o Congestion window validation techniques. These are similar in 186 action as the method described in [I-D.ietf-tcpm-newcwv]. 188 o Fast start for bitrate increase. It makes the video bitrate ramp- 189 up within 5 to 10 seconds. The behavior is similar to TCP 190 slowstart. The fast start is exited when congestion is detected. 191 The fast start state can be resumed if the congestion level is 192 low, this to enable a reasonably quick rate increase in case link 193 throughput increases. 195 o Adaptive delay target. This helps the congestion control to 196 compete with FTP traffic to some degree. 198 3.2. Transmission Scheduling 200 Transmission scheduling limits the output of data, given by the 201 relation between the number of bytes in flight and the congestion 202 window similar to TCP. Packet pacing is used to mitigate issues with 203 coalescing that may cause increased jitter and/or packet loss in the 204 media traffic. 206 3.3. Media Rate Control 208 The media rate control serves to adjust the media bitrate to ramp up 209 quickly enough to get a fair share of the system resources when link 210 throughput increases. 212 The reaction to reduced throughput must be prompt in order to avoid 213 getting too much data queued up in the RTP packet queues. The media 214 bitrate is decreased if the RTP queue size exceeds a threshold. 216 In cases where the sender frame queues increase rapidly such as the 217 case of a RAT (Radio Access Type) handover it may be necessary to 218 implement additional actions, such as discarding of encoded video 219 frames or frame skipping in order to ensure that the RTP queues are 220 drained quickly. Frame skipping means that the frame rate is 221 temporarily reduced. Discarding of old video frames is a more 222 efficient way to reduce media latency than frame skipping but it 223 comes with a requirement to repair codec state, frame skipping is 224 thus to prefer as a first remedy. Frame skipping is described as an 225 optional to implement feature in this specification. 227 4. Detailed Description of SCReAM 229 4.1. SCReAM Sender 231 This section describes the sender side algorithm in more detail. It 232 is split between the network congestion control and the video rate 233 adaptation. 235 Figure 1 shows the functional overview of a SCReAM sender. The RTP 236 application interaction with congestion control is described in 237 [I-D.ietf-rmcat-app-interaction]. Here we use a more decomposed 238 version of the implementation model in the sense that the RTP packets 239 may be queued up in the sender, the transmission of these RTP packets 240 is controlled by a transmission scheduler. A SCReAM sender 241 implements rate control and a queue for each media type or source, 242 where RTP packets containing encoded media frames are temporarily 243 stored for transmission, the figure shows the details for when two 244 video sources (a.k.a streams) are used. 246 ---------------------------- ----------------------------- 247 | Video encoder | | Video encoder | 248 ---------------------------- ----------------------------- 249 ^ | ^ ^ | ^ 250 (1)| (2)| (3)| (1)| (2)| (3)| 251 | RTP | | RTP | 252 | V | | V | 253 | ------------- | | ------------- | 254 ----------- | |-- ----------- | |-- 255 | Rate | (4) | Queue | | Rate | (4) | Queue | 256 | control |<----| | | control |<----| | 257 | | |RTP packets| | | |RTP packets| 258 ----------- | | ----------- | | 259 ------------- ------------- 260 | | 261 --------------- -------------- 262 (5)| |(5) 263 RTP RTP 264 | | 265 v v 266 -------------- ---------------- 267 | Network | (8) | Transmission | 268 | congestion |<-------->| scheduler | 269 | control | | | 270 -------------- ---------------- 271 ^ | 272 | (7) |(6) 273 ---------RTCP---------- RTP 274 | | 275 | v 276 ------------- 277 | UDP | 278 | socket | 279 ------------- 281 Figure 1: SCReAM sender functional view 283 Video frames are encoded and forwarded to the queue (2). The media 284 rate adaptation adapts to the size of the RTP queue and controls the 285 video bitrate (1). The RTP packets are picked from each queue based 286 on some defined priority order or simply in a round robin fashion 287 (5). A transmission scheduler takes care of the transmission of RTP 288 packets, to be written to the UDP socket (6). In the general case 289 all media must go through the transmission scheduler and is allowed 290 to be transmitted if the number of bytes in flight is less than the 291 congestion window. Audio frames can however be allowed to be 292 transmitted immediately as audio is typically low bitrate and thus 293 contributes little to congestion, this is something that is left as 294 an implementation choice. RTCP packets are received (7) and the 295 information about bytes in flight and congestion window is exchanged 296 between the network congestion control and the transmission scheduler 297 (8). 299 4.1.1. Constants and Parameter values 301 A set of constants are defined in Table 1, state variables are 302 defined in Table 2. And finally, local variables are described in 303 Table 3. 305 An init value [] indicates an empty array. 307 +-------------------------------+------------------------+----------+ 308 | Constant | Explanation | Value | 309 +-------------------------------+------------------------+----------+ 310 | OWD_TARGET_LO | Min OWD target | 0.1s | 311 | OWD_TARGET_HI | Max OWD target | 0.4s | 312 | MAX_BYTES_IN_FLIGHT_HEAD_ROOM | Headroom for | 1.1 | 313 | | limitation of CWND | | 314 | GAIN | Gain factor for | 1.0 | 315 | | congestion window | | 316 | | adjustment | | 317 | BETA | CWND scale factor due | 0.6 | 318 | | to loss event | | 319 | BETA_R | Target rate scale | 0.8 | 320 | | factor due to loss | | 321 | | event | | 322 | BYTES_IN_FLIGHT_SLACK | Additional slack [%] | 10% | 323 | | to the congestion | | 324 | | window | | 325 | RATE_ADJUST_INTERVAL | Interval between video | 0.1s | 326 | | bitrate adjustments | | 327 | FRAME_PERIOD | Video coder frame | | 328 | | period [s] | | 329 | TARGET_BITRATE_MIN | Min target_bitrate | | 330 | | [bps] | | 331 | TARGET_BITRATE_MAX | Max target_bitrate | | 332 | | [bps] | | 333 | RAMP_UP_TIME | Timespan [s] from | 10s | 334 | | lowest to highest | | 335 | | bitrate | | 336 | PRE_CONGESTION_GUARD | Guard factor against | 0.0..0.2 | 337 | | early congestion | | 338 | | onset. A higher value | | 339 | | gives less jitter | | 340 | | possibly at the | | 341 | | expense of a lower | | 342 | | video bitrate. | | 343 | TX_QUEUE_SIZE_FACTOR | Guard factor against | 0.0..2.0 | 344 | | RTP queue buildup | | 345 +-------------------------------+------------------------+----------+ 347 Table 1: Constants 349 +-------------------------+--------------------+--------------------+ 350 | Variable | Explanation | Init value | 351 +-------------------------+--------------------+--------------------+ 352 | owd_target | OWD target | OWD_TARGET_LO | 353 | owd_fraction_avg | EWMA filtered | 0.0 | 354 | | owd_fraction | | 355 | owd_fraction_hist | Vector of the last | [] | 356 | | 20 owd_fraction | | 357 | owd_trend | OWD trend, | 0.0 | 358 | | indicates | | 359 | | incipient | | 360 | | congestion | | 361 | owd_norm_hist | Vector of the last | [] | 362 | | 100 owd_norm | | 363 | mss | Maximum segment | 1000 | 364 | | size = Max RTP | | 365 | | packet size [byte] | | 366 | min_cwnd | Minimum congestion | 2*MSS | 367 | | window [byte] | | 368 | in_fast_start | True if in fast | true | 369 | | start state | | 370 | cwnd | Congestion window | min_cwnd | 371 | | [byte] | | 372 | cwnd_i | Congestion window | 1 | 373 | | inflection point | | 374 | bytes_newly_acked | The number of | 0 | 375 | | bytes that was | | 376 | | acknowledged with | | 377 | | the last received | | 378 | | acknowledgement | | 379 | | i.e. bytes | | 380 | | acknowledged since | | 381 | | the last CWND | | 382 | | update [byte]. | | 383 | | Reset after a CWND | | 384 | | update | | 385 | send_wnd | Upper limit of how | 0 | 386 | | many bytes that | | 387 | | can be transmitted | | 388 | | [byte]. Updated | | 389 | | when CWND is | | 390 | | updated and when | | 391 | | RTP packet is | | 392 | | transmitted | | 393 | t_pace | Approximate | 0.001 | 394 | | estimate of inter- | | 395 | | packet | | 396 | | transmission | | 397 | | interval [s], | | 398 | | updated when RTP | | 399 | | packet transmitted | | 400 | age_vec | A vector of the | [] | 401 | | last 20 RTP packet | | 402 | | queue delay | | 403 | | samples | | 404 | frame_skip_intensity | Indicates the | 0.0 | 405 | | intensity of the | | 406 | | frame skips | | 407 | since_last_frame_skip | Number of video | 0 | 408 | | frames since the | | 409 | | last skip | | 410 | consecutive_frame_skips | Number of | 0 | 411 | | consecutive frame | | 412 | | skips | | 413 | target_bitrate | Video target | TARGET_BITRATE_MIN | 414 | | bitrate [bps] | | 415 | target_bitrate_i | Video target | 1 | 416 | | bitrate inflection | | 417 | | point i.e. the | | 418 | | last known highest | | 419 | | target_bitrate | | 420 | | during fast start. | | 421 | | Used to limit | | 422 | | bitrate increase | | 423 | | close to the last | | 424 | | know congestion | | 425 | | point | | 426 | rate_transmit | Measured transmit | 0.0 | 427 | | bitrate [bps] | | 428 | rate_acked | Measured | 0.0 | 429 | | throughput based | | 430 | | on received | | 431 | | acknowledgements | | 432 | | [bps] | | 433 | s_rtt | Smoothed RTT [s], | 0.0 | 434 | | computed similar | | 435 | | to method depicted | | 436 | | in [RFC6298] | | 437 | rtp_queue_size | Size of RTP | 0 | 438 | | packets in queue | | 439 | | [bits] | | 440 | rtp_size | Size of the last | 0 | 441 | | transmitted RTP | | 442 | | packets [byte] | | 443 | frame_skip | Skip encoding of | false | 444 | | video frame if | | 445 | | true | | 446 +-------------------------+--------------------+--------------------+ 448 Table 2: State variables 450 +------------------+------------------------------------------------+ 451 | Variable | Explanation | 452 +------------------+------------------------------------------------+ 453 | owd | OWD = One way delay with base delay subtracted | 454 | | [s]. This is an estimate of the network | 455 | | queueing delay. | 456 | owd_fraction | OWD as a fraction of the OWD target | 457 | owd_norm | OWD normalized to OWD_TARGET_LO | 458 | owd_norm_mean | Average OWD norm over the last 100 samples | 459 | owd_norm_mean_sh | Average OWD norm over the last 20 samples | 460 | owd_norm_var | OWD norm variance over the last 100 samples | 461 | off_target | Relation between OWD and OWD target | 462 | scl_i | A general scalefactor that is applied to the | 463 | | CWND or target_bitrate increase | 464 | x_cwnd | Additional increase of CWND, used when | 465 | | send_wnd is computed | 466 | pace_bitrate | The allowed RTP packet transmission rate, used | 467 | | in the computation of t_pace [bps] | 468 | age_avg | Average RTP queue delay [s] | 469 | increment | Allowed target_bitrate increase | 470 | current_rate | Max of rate_transmit and rate_acked | 471 +------------------+------------------------------------------------+ 473 Table 3: Local temporary variables 475 4.1.2. Network congestion control 477 This section explains the network congestion control, it contains two 478 main functions 480 o Computation of congestion window at the sender: Gives an upper 481 limit to the number of bytes in flight i.e. how many bytes that 482 have been transmitted but not yet acknowledged. 484 o Transmission scheduling at the sender: RTP packets are transmitted 485 if allowed by the relation between the number of bytes in flight 486 and the congestion window. This is controlled by the send window. 488 Unlike TCP, SCReAM is not a byte oriented protocol, rather it is an 489 RTP packet oriented protocol. Thus it keeps a list of transmitted 490 RTP packets and their respective sending times (wall-clock time). 491 The feedback indicates the highest received RTP sequence number and a 492 timestamp (wall-clock time) when it was received. In addition, an 493 ACK list is included to make it possible to determine lost packets. 495 4.1.2.1. Congestion window update 497 The congestion window is computed from the one way (extra) delay 498 estimates (OWD) that are obtained from the send and received 499 timestamp of the RTP packets. LEDBAT [RFC6817] explains the details 500 of the computation of the OWD. An OWD sample is obtained for each 501 received acknowledgement. No smoothing of the OWD samples occur, 502 however some smoothing occurs anyway as the computation of the CWND 503 is in itself a low pass filter function. 505 SCReAM uses the terminology "Bytes in flight (bytes_in_flight)" which 506 is computed as the sum of the sizes of the RTP packets ranging from 507 the RTP packet most recently transmitted down to but not including 508 the acknowledged packet with the highest sequence number. As an 509 example: If RTP packet was sequence number SN with transmitted and 510 the last ACK indicated SN-5 as the highest received sequence number 511 then bytes in flight is computed as the sum of the size of RTP 512 packets with sequence number SN-4, SN-3, SN-2, SN-1 and SN. 514 CWND is updated differently depending on whether the congestion 515 control is in fast start or not and if a loss event is detected. A 516 Boolean variable in_fast_start indicates if the congestion is in fast 517 start state. 519 A loss event indicates one or more lost RTP packets within an RTT. 520 This is detected by means of inspection for holes in the sequence 521 number space in the acknowledgements with some margin for possible 522 packet reordering in the network. As an alternative, a timer for 523 loss detection similar to TCP RACK may be used. 525 Below is described the actions when an acknowledgement from the 526 receiver is received. 528 bytes_newly_acked is updated. 530 The OWD fraction and an average of it are computed as 532 owd_fraction = owd/owd_target 534 owd_fraction_avg = 0.9* owd_fraction_avg + 0.1* owd_fraction 536 The OWD fraction is sampled every 50ms and the last 20 samples are 537 stored in a vector (owd_fraction_hist). This vector is used in the 538 computation of an OWD trend that gives a value between 0.0 and 1.0 539 depending on how close to congestion it is. The OWD trend is 540 calculated as follows 542 Let R(owd_fraction_hist,K) be the autocorrelation function of 543 owd_fraction_hist at lag K. The 1st order prediction coefficient is 544 formulated as 546 a = R(owd_fraction_hist,1)/R(owd_fraction_hist,0) 548 The prediction coefficient a has positive values if OWD shows an 549 increasing trend, thus an indication of congestion is obtained before 550 the OWD target is reached. The prediction coefficient is further 551 multiplied with owd_fraction_avg to reduce sensitivity to increasing 552 OWD when OWD is very small. The OWD trend is thus computed as 554 owd_trend = max(0.0,min(1.0,a*owd_fraction_avg)) 556 The owd_trend is utilized in the media rate control and to determine 557 when to exit slow start. 559 An off target value is computed as 561 off_target = (owd_target - owd) / owd_target 563 A temporal variable is scl_i is computed as 565 scl_i = max(0.2, min(1.0, (abs(cwnd-cwnd_i)/cwnd_i*4)^2)) 567 scl_i is used to limit the CWND increase when close to the last known 568 max value, before congestion was last detected. 570 The congestion window update depends on whether a loss event has 571 occurred, and if the congestion control is if fast start or not. 573 ____________________________________________________________________ 575 On loss event: 577 If a loss event is detected then in_fast_start is set to false and 578 CWND is updated according to 580 cwnd_i = cwnd 582 cwnd = max(min_cwnd,cwnd*BETA) 584 otherwise the CWND update continues 585 ____________________________________________________________________ 587 in_fast_start = true: 589 in_fast_start is set to false and cwnd_i=cwnd if owd_trend >= 0.2 and 590 otherwise CWND is updated according to 592 cwnd = cwnd + bytes_newly_acked*scl_i 594 ____________________________________________________________________ 596 in_fast_start = false: 598 Values of off_target > 0.0 indicates that the congestion window can 599 be increased. This is done according to the equations below. 601 gain = GAIN*(1.0 + max(0.0, 1.0 - owd_trend/ 0.2)) 603 The equation above limits the gain when near congestion is detected 605 gain *= scl_i 607 This equation limits the gain when CWND is close to its last known 608 max value 610 cwnd += gain * off_target * bytes_newly_acked * mss / cwnd 612 Values of off_target <= 0.0 indicates congestion, CWND is then 613 updated according to the equation 615 cwnd += GAIN*off_target*bytes_newly_acked*mss/cwnd 617 The equations above are very similar to what is specified in 618 [RFC6817]. There are however a few differences. 620 o [RFC6817] specifies a constant GAIN, this specification however 621 limits the gain when CWND is increased dependent on near 622 congestion state and the relation to the last known max CWND 623 value. 625 o [RFC6817] specifies that the CWND increased is limited by an 626 additional function controlled by a constant ALLOWED_INCREASE. 627 This additional limitation is removed in this specification. 629 ____________________________________________________________________ 631 A number of final steps in the congestion window update procedure are 632 outlined below 633 ____________________________________________________________________ 635 Resume fast start: 637 Fast start can be resumed in order to speed up the bitrate increase 638 in case congestion abates. The condition to resume fast start 639 (in_fast_start = true) is that owd_trend is less than 0.2 for 1.0 640 seconds or more. 642 ____________________________________________________________________ 644 Competing flows compensation, adjustment of owd_target: 646 Competing flows compensation is needed to avoid that flows congestion 647 controlled by SCReAM are starved out by flows that are more 648 aggressive in their nature. The owd_target is adjusted according to 649 the owd_norm_mean_sh whenever owd_norm_var is below a given value. 650 The condition to update owd_target is fulfilled if owd_norm_var < 651 0.16 (indicating that the standard deviation is less than 0.4). 652 owd_target is then update as: 654 owd_target = min(OWD_TARGET_HI,max(OWD_TARGET_LO, owd_norm_mean_sh* 655 OWD_TARGET_LO*1.1)) 657 ____________________________________________________________________ 659 Final CWND adjustment step: 661 The congestion window is limited by the maximum number of bytes in 662 flight over the last 1.0 seconds according to 664 cwnd = min(cwnd, max_bytes_in_flight*MAX_BYTES_IN_FLIGHT_HEAD_ROOM) 666 This avoids possible over-estimation of the throughput after for 667 example, idle periods. 669 Finally cwnd is set to ensure that it is at least min_cwnd 671 cwnd = max(cwnd, MIN_CWND) 673 4.1.2.2. Transmission scheduling 675 The principle is to allow packet transmission of an RTP packet only 676 if the number of bytes in flight is less than the congestion window. 677 There are however two reasons why this strict rule will not work 678 optimally: 680 o Bitrate variations: The video frame size is always varying to a 681 larger or smaller extent, a strict rule as the one given above 682 will have the effect that the video bitrate have difficulties to 683 increase as the congestion window puts a too hard restriction on 684 the video frame size variation, this further can lead to 685 occasional queuing of RTP packets in the RTP packet queue that 686 will prevent bitrate increase because of the increased RTP queue 687 size. 689 o Reverse (feedback) path congestion: Especially in transport over 690 buffer-bloated networks, the one way delay in the reverse 691 direction may jump due to congestion. The effect of this is that 692 the acknowledgements are delayed with the result that the self- 693 clocking is temporarily halted, even though the forward path is 694 not congested. 696 Packets are transmitted at a pace given by the send window, computed 697 below 699 The send window is computed differently depending on OWD and its 700 relation to the OWD target. 702 o If owd > owd_target: 703 The send window is computed as 704 send_wnd = cwnd-bytes_in_flight 705 This enforces a strict rule that helps to prevent further queue 706 buildup. 708 o If owd <= owd_target: 709 A helper variable 710 x_cwnd=1.0+BYTES_IN_FLIGHT_SLACK*max(0.0, 711 min(1.0,1.0-owd_trend/0.5))/100.0 712 is computed. The send window is computed as 713 send_wnd = max(cwnd*x_cwnd, cwnd+mss)-bytes_in_flight 714 This gives a slack that reduces as congestion increases, 715 BYTES_IN_FLIGHT_SLACK is a maximum allowed slack in percent. A 716 large value increases the robustness to bitrate variations in the 717 source and congested feedback channel issues. The possible 718 drawback is increased delay or packet loss when forward path 719 congestion occur. 721 4.1.3. Video rate control 723 The video rate control is operated based on the size of the RTP 724 packet send queue and observed loss events. In addition, owd_trend 725 is also considered in the rate control, this to reduce the amount of 726 induced network jitter. 728 A variable target_bitrate is adjusted depending on the congestion 729 state. The target bitrate can vary between a minimum value 730 (target_bitrate_min) and a maximum value (target_bitrate_max). 732 For the overall bitrate adjustment, two network throughput estimates 733 are computed : 735 o rate_transmit: The measured transmit bitrate 737 o rate_acked: The ACKed bitrate, i.e. the volume of ACKed bits per 738 time unit. 740 Both estimates are updated every 200ms. 742 The current throughput current_rate is computed as the maximum value 743 of rate_transmit and rate_acked. The rationale behind the use of 744 rate_acked in addition to rate_transmit is that rate_transmit is 745 affected also by the amount of data that is available to transmit, 746 thus a lack of data to transmit can be seen as reduced throughput 747 that may itself cause an unnecessary rate reduction. To overcome 748 this shortcoming; rate_acked is used as well. This gives a more 749 stable throughput estimate. 751 The bitrate is updated at regular intervals, given by 752 RATE_ADJUST_INTERVAL and differently depending the fast start state 754 The rate change behavior depends on whether a loss event has 755 occurred, and if the congestion control is if fast start or not. 757 ____________________________________________________________________ 759 On loss event: 761 First of all the target_bitrate is updated if a new loss event was 762 indicated and the rate change procedure is exited. 764 target_bitrate_i = target_bitrate 766 target_bitrate = max(BETA_R* target_bitrate, TARGET_BITRATE_MIN) 768 If no loss event was indicated then the rate change procedure 769 continues. 771 ____________________________________________________________________ 773 in_fast_start = true: 775 An allowed increment is computed based on the congestion level and 776 the relation to target_bitrate_i 778 scl_i = (target_bitrate - target_bitrate_i)/ target_bitrate_i 780 increment = TARGET_BITRATE_MAX* RATE_ADJUST_INTERVAL/RAMP_UP_TIME* 781 (1.0- min(1.0, owd_trend/0.1)) 783 increment *= max(0.2, min(1.0, (scl_i*4)^2)) 785 target_bitrate += increment 787 target_bitrate is reduced further if congestion is detected. 789 target_bitrate *= (1.0- PRE_CONGESTION_GUARD*owd_trend) 791 target_bitrate = 792 min(TARGET_BITRATE_MAX,max(TARGET_BITRATE_MIN,target_bitrate)) 794 ____________________________________________________________________ 796 in_fast_start = false: 798 target_bitrate_i is updated to the current value of target_bitrate if 799 in_fast_start was true the last time the bitrate was updated. 801 A pre-congestion indicator is computed as 803 pre_congestion = min(1.0, max(0.0, owd_fraction_avg-0.3)/0.7) 805 pre_congestion += owd_trend 807 The target bitrate is computed as 809 target_bitrate=current_rate*(1.0- 810 PRE_CONGESTION_GUARD*pre_congestion)-TX_QUEUE_SIZE_FACTOR 811 *rtp_queue_size 813 target_bitrate = 814 min(TARGET_BITRATE_MAX,max(TARGET_BITRATE_MIN,target_bitrate)) 816 4.2. SCReAM Receiver 818 The SCReAM receiver is very simple in its implementation. The task 819 is to feedback acknowledgements of received packets. For that 820 purpose a set of state variables are needed, these are explained in 821 Table 4. 823 One set of state variables are maintained per stream. 825 +-----------------------------+-----------------------------+-------+ 826 | Variable | Explanation | Init | 827 | | | value | 828 +-----------------------------+-----------------------------+-------+ 829 | rx_timestamp | The wall clock timestamp | 0 | 830 | | when the latest RTP packet | | 831 | | was received | | 832 | highest_rtp_sequence_number | The highest received | 0 | 833 | | sequence number | | 834 | ack_vector | A 16 bit vector that | 0 | 835 | | indicates received RTP | | 836 | | packets with a sequence | | 837 | | number lower than | | 838 | | highest_rtp_sequence_number | | 839 | n_loss | An 8 bit counter for the | 0 | 840 | | number of lost RTP packets, | | 841 | | separate counters are | | 842 | | maintained for each SSRC | | 843 | n_ECN | An 8 bit counter for the | 0 | 844 | | number of ECN-CE marked RTP | | 845 | | packets, separate counters | | 846 | | are maintained for each | | 847 | | SSRC | | 848 | pending_feedback | Indicates that an RTP | false | 849 | | packet was received and | | 850 | | that an RTCP packet can be | | 851 | | generated when RTCP timing | | 852 | | rules permit | | 853 | last_transmit_t | Last time an RTCP packet | -1.0 | 854 | | was transmitted, this is | | 855 | | used to ensure that RTCP | | 856 | | feedback is generated | | 857 | | fairly for all streams. | | 858 +-----------------------------+-----------------------------+-------+ 860 Table 4: State variables 862 Upon reception of an RTP packet, the state variables in Table 4 863 should be updated and the RTCP processing function should be 864 notified. An RTCP packet is later generated based on the state 865 variables, how often this is done depends on the RTCP bandwidth. 867 5. Feedback Message 869 The feedback is over RTCP [RFC3550] and is based on [RFC4585]. It is 870 implemented as a transport layer feedback message (RTPFB), see 871 proposed example in Figure 2. The feedback control information part 872 (FCI) consists of the following elements. 874 o Highest received RTP sequence number : The highest received RTP 875 sequence number for the given SSRC 877 o n_lost : Ackumulated number of lost RTP packets for the given SSRC 879 o Timestamp: A timestamp value indicating when the last packet was 880 received which makes it possible to compute the one way (extra) 881 delay (OWD). 883 o n_ECN : Ackumulated number of ECN-CE marked RTP packets for the 884 given SSRC 886 o Source quench bit (Q): Makes it possible to request the sender to 887 reduce its congestion window. This is useful if WebRTC media is 888 received from many hosts and it becomes necessary to balance the 889 bitrates between the streams. 891 0 1 2 3 892 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 |V=2|P| FMT | PT | length | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | SSRC of packet sender | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | SSRC of media source | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Highest recv. seq. nr. (16b) | n_lost | n_ECN | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Timestamp (32bits) | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 |Q| Reserved for future use | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Figure 2: Transport layer feedback message 909 To make the feedback as frequent as possible, the feedback packets 910 are transmitted as reduced size RTCP according to [RFC5506]. 912 The timestamp clock time is recommended to be set to a fixed value 913 such as 1000Hz, defined in this specification. The n_lost and n_ECN 914 makes it possible to take necessary actions on the detection of lost 915 and ECN marked packets. 917 Section 4 describes the main algorithm details and how the feedback 918 is used. 920 6. Additional features 922 This section describes additional features. They are not required 923 for the basic functionality of SCReAM but can improve performance in 924 certain scenarios and topologies. 926 6.1. Packet pacing 928 Packet pacing is used in order to mitigate coalescing i.e. that 929 packets are transmitted in bursts. 931 Packet pacing is enforced when owd_fraction_avg is greater than 0.1. 932 The time interval between consecutive packet transmissions is then 933 enforced to equal or higher than t_pace where t_pace is given by the 934 equations below. 936 pace_bitrate = max (50000, cwnd* 8 / s_rtt) 938 t_pace = rtp_size * 8 / pace_bitrate 940 rtp_size is the size of the last transmitted RTP packet 942 6.2. Frame skipping 944 Frame skipping is a feature that makes it possible to reduce the size 945 of the RTP queue in the cases that e.g. the channel throughput drops 946 dramatically or even goes below the lowest possible video coder rate. 947 Frame skipping is optional to implement as it can sometimes be 948 difficult to realize e.g. due to lack of API function to support 949 this. 951 Frame skipping is controlled by a flag frame_skip which, if set to 1 952 dictates that the video coder should skip the next video frame. The 953 frame skipping intensity at the current time instant is computed 954 according to the steps below 956 The queuing delay is sampled every frame period and the last 20 957 samples are stored in a vector age_vec 958 An average queuing delay is computed as a weighted sum over the 959 samples in age_vec. age_avg at the current time instant is computed 960 as 962 age_avg(n) = SUM age_vec(n-k)*w(k) k = [0..20[ 964 w(n) are weight factors arranged to give the most recent samples a 965 higher weight. 967 The change in age_avg is computed as 969 age_d = age_avg(n) - age_avg(n-1) 971 The frame skipping intensity at the current time instant n is 972 computed as 974 o If age_d > 0 and age_avg > 2*FRAME_PERIOD: 975 frame_skip_intensity = min(1.0, (age_vec(n)-2*FRAME_PERIOD)/(4* 976 FRAME_PERIOD) 978 o Otherwise frame skip intensity is set to zero 980 The skip_frame flag is set depending on three variables 982 o frame_skip_intensity 984 o since_last_frame_skip, i.e the number of consecutive frames 985 without frame skipping 987 o consecutive_frame_skips, i.e the number of consecutive frame skips 989 The flag skip_frame is set to 1 if any of the conditions below is 990 met, otherwise it is set to 0. 992 o age_vec(n) > 0.2 && consecutive_frame_skips < 5 994 o frame_skip_intensity < 0.5 && since_last_frame_skip >= 1.0/ 995 frame_skip_intensity 997 o frame_skip_intensity >= 0.5 && consecutive_frame_skips < 998 (frame_skip_intensity -0.5)*10 1000 The arrangement makes sure that no more than 4 frames are skipped in 1001 sequence, the rationale is to ensure that the input to the video 1002 encoder does not change to much, something that may give poor 1003 prediction gain. 1005 6.3. Q-bit semantics (source quench) 1007 The Q bit in the feedback is set by a receiver to signal that the 1008 sender should reduce the bitrate. The sender will in response to 1009 this reduce the congestion window with the consequence that the video 1010 bitrate decreases. A typical use case for source quench is when a 1011 receiver receives streams from sources located at different hosts and 1012 they all share a common bottleneck, typically it is difficult to 1013 apply any rate distribution signaling between the sending hosts. The 1014 solution is then that the receiver sets the Q bit in the feedback to 1015 the sender that should reduce its rate, if the streams share a common 1016 bottleneck then the released bandwidth due to the reduction of the 1017 congestion window for the flow that had the Q bit set in the feedback 1018 will be grabbed by the other flows that did not have the Q bit set. 1019 This is ensured by the opportunistic behavior of SCReAM's congestion 1020 control. The source quench will have no or little effect if the 1021 flows do not share the same bottleneck. 1023 The reduction in congestion window is proportional to the amount of 1024 SCReAM RTCP feedback with the Q bit set, the below steps outline how 1025 the sender should react to RTCP feedback with the Q bit set. The 1026 reduction is done once per RTT. Let : 1028 o n = Number of received RTCP feedback messages in one RTT 1030 o n_q = Number of received RTCP feedback messages in one RTT, with Q 1031 bit set. 1033 The new congestion window is then expressed as: 1035 cwnd = max(MIN_CWND, cwnd*(1.0-0.5* n_q /n)) 1037 Note that CWND is adjusted at most once per RTT. Furthermore The 1038 CWND increase should be inhibited for one RTT if CWND has been 1039 decreased as a result of Q bits set in the feedback. 1041 The required intensity of the Q-bit set in the feedback in order to 1042 achieve a given rate distribution depends on many factors such as 1043 RTT, video source material etc. The receiver thus need to monitor 1044 the change in the received video bitrate on the different streams and 1045 adjust the intensity of the Q-bit accordingly. 1047 7. Discussion 1049 This section covers a few open discussion points 1051 o RTCP feedback overhead: SCReAM benefits from a relatively frequent 1052 feedback. Experiments have shown that a feedback rate roughly 1053 equal to the frame rate gives a stable self-clocking and 1054 robustness against loss of feedback. With a maximum bitrate of 1055 1500kbps the RTCP feedback overhead is in the range 10-15kbps with 1056 reduced size RTCP, including IP and UDP framing, in other words 1057 the RTCP overhead is quite modest and should not pose a problem in 1058 the general case. Other solutions may be required in highly 1059 asymmetrical link capacity cases. Worth notice is that SCReAM can 1060 work with as low feedback rates as once every 200ms, this however 1061 comes with a higher sensitivity to loss of feedback and also a 1062 potential reduction in throughput. 1064 o AVPF mode: The RTCP feedback is based on AVPF regular mode. The 1065 SCReAM feedback is transmitted as reduced size RTCP so save 1066 overhead, it is however required to transmit full compound RTCP at 1067 regular intervals, this interval can be controlled by trr-int 1068 depicted in [RFC4585]. 1070 o BETA, CWND scale factor due to loss: The BETA value is recommended 1071 to be higher than 0.5. The reason behind this is that congestion 1072 control for multimedia has to deal with a source that is rate 1073 limited. A file transfer has "unlimited" source bitrate in 1074 comparison. The outcome is that SCReAM must be a little more 1075 aggressive than a file transfer in order to not be out competed. 1077 8. Conclusion 1079 This memo describes a congestion control algorithm for RMCAT that it 1080 is particularly good at handling the quickly changing condition in 1081 wireless network such as LTE. The solution conforms to the packet 1082 conservation principle and leverages on novel congestion control 1083 algorithms and recent TCP research, together with media bitrate 1084 determined by sender queuing delay and given delay thresholds. The 1085 solution has shown potential to meet the goals of high link 1086 utilization and prompt reaction to congestion. The solution is 1087 realized with a new RFC4585 transport layer feedback message. 1089 9. Open issues 1091 A list of open issues. 1093 o Describe how clock drift compensation is done 1095 o Describe how FEC overhead is accounted for in target_bitrate 1096 computation 1098 o Investigate the impact of more sparse RTCP feedback, for instance 1099 once per RTT 1101 10. Source code 1103 Source code for SCReAM is available in two formats : 1105 o C++ code, that is apt for experimentation. The code maitained as 1106 Visual Studio project. This code can possibly be included in 1107 simulators such as NS3. Avaliable at 1108 https://github.com/EricssonResearch/scream 1110 o OpenWebRTC implementation : Work in progress, see 1111 http://www.openwebrtc.io/ for information about the OpenWebRTC 1112 project 1114 11. Acknowledgements 1116 We would like to thank the following persons for their comments, 1117 questions and support during the work that led to this memo: Markus 1118 Andersson, Bo Burman, Tomas Frankkila, Frederic Gabin, Laurits Hamm, 1119 Hans Hannu, Nikolas Hermanns, Stefan Haekansson, Erlendur Karlsson, 1120 Daniel Lindstroem, Mats Nordberg, Jonathan Samuelsson, Rickard 1121 Sjoeberg, Robert Swain, Magnus Westerlund, Stefan Aelund. 1123 12. IANA Considerations 1125 A new RFC4585 transport layer feedback message needs to be 1126 standardized. 1128 13. Security Considerations 1130 The feedback can be vulnerable to attacks similar to those that can 1131 affect TCP. It is therefore recommended that the RTCP feedback is at 1132 least integrity protected. 1134 14. Change history 1136 A list of changes: 1138 o -04 to -05 : ACK vector is replaced by a loss counter, PT is 1139 removed from feedback, references to source code added 1141 o -03 to -04 : Extensive changes due to review comments, code 1142 somewhat modified, frame skipping made optional 1144 o -02 to -03 : Added algorithm description with equations, removed 1145 pseudo code and simulation results 1147 o -01 to -02 : Updated GCC simulation results 1148 o -00 to -01 : Fixed a few bugs in example code 1150 15. References 1152 15.1. Normative References 1154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1155 Requirement Levels", BCP 14, RFC 2119, March 1997. 1157 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1158 Jacobson, "RTP: A Transport Protocol for Real-Time 1159 Applications", STD 64, RFC 3550, July 2003. 1161 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1162 "Extended RTP Profile for Real-time Transport Control 1163 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1164 2006. 1166 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1167 Real-Time Transport Control Protocol (RTCP): Opportunities 1168 and Consequences", RFC 5506, April 2009. 1170 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 1171 "Computing TCP's Retransmission Timer", RFC 6298, June 1172 2011. 1174 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 1175 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 1176 December 2012. 1178 15.2. Informative References 1180 [FACK] "Forward Acknowledgement: Refining TCP Congestion 1181 Control", 2006. 1183 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] 1184 Sarker, Z., "Evaluation Test Cases for Interactive Real- 1185 Time Media over Cellular Networks", 1186 . 1189 [I-D.ietf-rmcat-app-interaction] 1190 Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, "RTP 1191 Application Interaction with Congestion Control", draft- 1192 ietf-rmcat-app-interaction-01 (work in progress), October 1193 2014. 1195 [I-D.ietf-tcpm-newcwv] 1196 Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 1197 TCP to support Rate-Limited Traffic", draft-ietf-tcpm- 1198 newcwv-08 (work in progress), February 2015. 1200 [QoS-3GPP] 1201 TS 23.203, 3GPP., "Policy and charging control 1202 architecture", June 2011, . 1205 [TFWC] University College London, "Fairer TCP-Friendly Congestion 1206 Control Protocol for Multimedia Streaming", December 2007, 1207 . 1210 Authors' Addresses 1212 Ingemar Johansson 1213 Ericsson AB 1214 Laboratoriegraend 11 1215 Luleae 977 53 1216 Sweden 1218 Phone: +46 730783289 1219 Email: ingemar.s.johansson@ericsson.com 1221 Zaheduzzaman Sarker 1222 Ericsson AB 1223 Laboratoriegraend 11 1224 Luleae 977 53 1225 Sweden 1227 Phone: +46 761153743 1228 Email: zaheduzzaman.sarker@ericsson.com