Abstract-We propose a QoS control architecture for mobile multimedia streaming in which RTP monitoring agents report. QoS information to media servers.
Rate and Robustness Control with RTP Monitoring Agent for Mobile Multimedia Streaming T. Yoshimura, T. Ohya, T. Kawahara, and M. Etoh Multimedia Laboratories, NTT DoCoMo, Inc. 3-5, Hikarinooka, Yokosuka, Kanagawa, 239-8536, Japan rate control
Abstract-We propose a QoS control architecture for mobile multimedia streaming in which RTP monitoring agents report QoS information to media servers. The RTP monitoring agents lie midway between wired networks and radio links, monitor RTP packets sent from media servers to mobile terminals, and report quality information to media servers so that the servers can realize network-adaptive QoS control. By analyzing the information sent from the agents, the servers can distinguish quality degradation caused by network congestion from that caused by radio link errors, and can improve service quality by controlling the transmission rate and robustness against packet loss. Simulation results show our implemented QoS control schemes that use the feedbacks from the agent and control transmission rate and robustness provide better video quality than a simple rate control mechanism.
packet loss & jitter calculation
network RTP media stream RTCP receiver reports
streaming server
streaming client
Fig. 1. Example of rate control using RTCP feedback information. incorrect rate control
wired core network
packet loss due to radio link errors
radio link
RTP media stream
I. INTRODUCTION Multimedia streaming service is becoming popular over the Internet, but current mobile packet networks provide only simple data services such as i-mode and WAP (Wireless Access Protocol). These current services mainly focus on e-mail, web browsing, and data transactions. To meet the demand towards streaming service, mobile packet networks are also expected to support IP-based streaming in addition to data services. While several techniques must be extended to introduce mobile multimedia streaming applications, QoS control is one of the keys in well supporting streaming media. Unless end-to-end QoS is guaranteed, senders of IP traffic must continually adapt their transmission rates to the network congestion condition. While TCP’s congestion controls are widely known, continuous media applications such as voice over IP (VoIP), video conferencing, and multimedia streaming generally use UDP and Real-time Transport Protocol (RTP)[1] as their transport protocol. Neither protocol, however, has any inherent congestion control mechanism. A number of papers have considered how to control the transmission rate of non-TCP flows. TCP-friendly rate control (TFRC)[2] and other equation-based congestion controls[3][4] calculate their maximum transmission rate using a TCP throughput formula. To calculate the transmission rate, these mechanisms require feedback from the receiver to obtain packet loss rates and round trip time (RTT) information. Some rate control mechanisms utilize the RTP Control Protocol (RTCP)[1] to obtain feedback information from receivers[5][6]. RTCP is used along with RTP to provide quality information on the corresponding RTP media stream as well as some user-specific information. As shown in Fig. 1, the receiver of an RTP media stream sends back RTCP receiver reports, which include packet loss and jitter information, so that the sender can identify network congestion condition and control its transmission rate accordingly.
streaming server
RTCP receiver reports packet loss indication
base station
streaming client
Fig. 2. Incorrect rate control due to radio link errors. When it comes to mobile packet networks, the intrinsic characteristics of radio links cause several new problems. Since radio links are subject to frequent packet losses and/or large latency variation (i.e., jitter) because of their error-prone environment, senders cannot distinguish congestion from error in the radio links. An incorrect assessment of network condition is likely to result in inappropriate congestion control. All of the rate control mechanisms mentioned above assume that packet loss, delay, and jitter are caused by network congestion. In mobile networks, however, packet loss and jitter may also be caused by radio link errors. Since radio links have much higher bit error rates, packets are frequently discarded due to the presence of bit errors. In addition to the higher bit error rate, cellular links cause large transmission delays, sometimes more than 100 milliseconds. When conventional rate control mechanisms are applied to mobile networks, a sender cannot identify the network congestion condition correctly, and this leads to inappropriate rate control. A typical symptom is that a sender reduces its transmission rate even if the network is not congested (Fig. 2). For this reason, distinguishing radio link condition from network congestion is the most important for mobile multimedia streaming. As long as a sender correctly estimates both network and radio link conditions, it can do an appropriate QoS control based on the estimated conditions. To enable senders to realize appropriate QoS control, we introduce a new type of proxy named “RTP monitoring agent”, which lies at the wired/wireless intersection, provides information about the network condition to senders, and enables the senders to correct determine the congestion state. Simulation results show that
0-7803-7400-2/02/$17.00 © 2002 IEEE
2513
rate control
wired core network
split RTP connection intermediate node
this approach to RTP streaming, however, requires frequent feedbacks as similar to TCP. Furthermore, the sender does not take any rate control when both network congestion and wireless errors occur at the same time.
radio link
RTP media stream RTCP receiver reports streaming server
III. QOS CONTROL WITH RTP MONITORING AGENT base station
A.
streaming client
Fig. 3. Split-connection approach. the sender can correctly control its media quality by utilizing the information sent from the RTP monitoring agent and can improve overall media quality.
All of the proposed architectures described above have one or more drawbacks for mobile multimedia streaming. We consider the following QoS control policies are essential and suitable for mobile multimedia streaming. •
A QoS control architecture has to adapt to both network congestion and radio link errors. That is, the conventional rate control methods that react only to network congestion are inadequate because of their ignorance of radio link error condition.
•
Functionality of network nodes is to be kept moderately light; intelligent functionality such as transcoding is not expected here because of its high computational burden. Let us leave the intelligence to an application layer and make network nodes simply provide hint information for applications to enable the above QoS control.
•
Media servers at the application layer, in contrast, are supposed to have specific information on media contents, and thus to have intelligent media delivery methods based on the content information. Given the additional hint information from the network, they can perform any QoS control needed including rate and robustness control by utilizing the content information.
II. PREVIOUS APPROACH OBSERVED IN WIRELESS TCP We can observe a similar problem mentioned above in TCP. Several techniques have been proposed to counter it[7]. First, let us discuss an application of four techniques, local retransmission, splitconnection, and Explicit Loss Notification (ELN), to RTP multimedia streaming. Local retransmission over error-prone radio links is an efficient way to minimize packet losses caused by radio link errors. Retransmission can be performed at either the link layer or the TCP layer[8]. Packets that are dropped due to radio link errors are retransmitted, and final packet losses are caused only by network congestion. However, retransmission leads to large delay and jitter. These may trigger incorrect rate control if the rate control mechanism takes delay or jitter into account. A media server is likely to consider the network is being congested when the feedbacks from the client indicate an increase in delay and jitter, and to reduce its transmission rate although the delay and jitter are actually caused by packet retransmissions over radio links. The split TCP connection proposed in [9] is another way to solve the above problem. RTP connections can also be split at the boundary between the wired networks and radio links (Fig. 3). The intermediate node sends back RTCP receiver reports to the sender instead of the receiver. The sender controls its transmission rate using the RTCP receiver reports sent from the intermediate node. Since the RTCP receiver reports from the intermediate node include only congestion information, not radio link condition, the senders can correctly control their transmission rate. However, the senders remain ignorant of the radio link condition and the final media quality at the receiver. Therefore, the sender cannot perform any QoS control against the packet losses caused by radio link errors. To ensure media quality against the packet losses caused by radio link errors, transcoding at the intermediate node is another way. In this approach, the intermediate node transcodes media data into data that are more robust against packet losses and transmits them over the error-prone radio link. Increasing the frame rate of I-pictures (MPEG video) is an example of transcoding. Although this approach can deal with the packet losses caused by radio link errors, transcoding incurs more processing overhead and leads to additional delay. Furthermore, transcoding is not always applicable in terms of security and copyright protection. ELN[10] has been proposed, which explicitly notifies packet losses due to wireless link errors in a reserved bit of TCP ACK header. It also provides a hint for distinguishing radio link errors from the effect of network congestion. If a TCP sender receives an ACK packet whose ELN flag is set, it does not reduce its transmission rate, but simply retransmits the lost packets. To adapt
Basic Architecture
Based on the above policies, we developed a new type of proxy, named “RTP monitoring agent”. It works as the intermediate node in the split connection approach mentioned above, but it does not actually split an RTP connection. That is, it returns feedback reports corresponding to RTCP receiver reports, but clients also return RTCP receiver reports to the media servers. Fig. 4 shows the network architecture with RTP monitoring agent. Note that the shaping point, which adjusts the outgoing rate of all packet traffic to the rate of the radio link, is located just prior to the RTP monitoring agent. This limits the occurrence of network congestion on the path between the media server and the RTP monitoring agent, and eliminates it on the radio link. The reports from the RTP monitoring agent indicate the network congestion condition, while those from the receiver cover network congestion and radio link conditions. Therefore, the server can determine the radio link condition by comparing these two reports. In this way, the server is informed of both network congestion condition and radio link condition. B.
RTP Monitoring Agent
RTP monitoring agent is a network agent located at the boundary between the wired core network and the wireless link. RTP monitoring agent broker that manages all of the agents provides APIs to media servers for the monitoring service and directs the agent on the streaming path to start monitoring and sending feedbacks. Therefore, only the media servers who know the service can utilize the monitoring service via API handshake when initiating a streaming session. The other media servers simply start a session without any feedbacks from the agent, which avoids server’s malfunction because of unexpected feedbacks. During the streaming session, the RTP monitoring agent collects statistics about packet loss, jitter, etc. for each RTP media flow and
2514
rate & robustness control
shaping point wired core network
network information feedback RTP monitoring radio link agent
media server
radio link shaping point
RTP media stream feedback reports streaming server RTCP receiver reports
base station
background traffic generator
streaming client
RTP monitoring agent
media client
background traffic
Fig. 5. Network configuration used in computer simulations.
Fig.4. Proposed QoS control architecture with RTP monitoring agent. sends feedback reports to the corresponding media server. To do this, the RTP monitoring agent has to identify each flow by analyzing IP addresses and UDP port numbers. Note that the agent keeps session contexts in a soft-state way, i.e., it releases a session context if there are no packets of the session to be transmitted for a certain time. Although someone may point out computational burden, supposed heavy, at the RTP monitoring agents, one agent will not carry many flows because it is located just before the radio links. In addition, collecting statistics for creating the RTCP receiver reports is rather a light process compared with header compression[11], which is expected to be implemented in IMT2000 radio access networks[12]. The supposed overhead to the network is therefore moderately low and acceptable when considering the expected benefits. Since the feedback reports sent from the agent indicate only the wired core network condition, the media server can determine the correct congestion status and do appropriate rate control. Unlike the split-connection approach, the RTP monitoring agent does not interrupt any media streams, which means the streaming session can be continued even in case of agent’s malfunction. C. Rate and Robustness Control at Media Server Media servers have to separate the feedback reports sent from the RTP monitoring agent from those sent from the media receiver. The pair of SSRC identifier and CNAME (canonical name) included in RTCP receiver reports can be used for this purpose. Any of the conventional rate control methods can be applied to the reports from the RTP monitoring agent. Servers can control their transmission rates upon analyzing the RTP monitoring agent reports because these include only network congestion information. On the other hand, rate control does not work if the packet loss is caused by radio link errors. The media server, therefore, needs to estimate the radio link condition from the two reports. The packet loss rate on the radio link, Pradio, can be calculated by the following equation: pradio = ( pclient − pagent ) /(1 − pagent ) ,
RTP media flow
(1)
where Pclient is the packet loss rate observed by the streaming client, and Pagent is the one observed by the RTP monitoring agent. In the case of radio link errors, servers have to make their media streams more robust against packet losses. Robustness can be controlled by several ways. One example is changing the frequency of transmitting forward error correction (FEC) packets. Increasing the frequency of FEC packet transmission increases robustness against packet loss. Changing the media encoding parameters is another way to control robustness. For example, robustness increases with the intra-refresh rate of video encoding. Examples of the robustness control are described in the next section.
IV. SIMULATION We did computer simulations on the network environment depicted in Fig. 5. The rate of the radio link was 384 kbit/s while the core network had enough bandwidth. An RTP media stream was transmitted from the media server to the client; at the same time, background traffic was also generated following a Poisson process and sent to the client. RTCP receiver reports were transmitted every 5 sec. from the client and the RTP monitoring agent. A.
Loss-Jitter Distribution
First, we examined packet loss rate and delay jitter reported from the client and the RTP monitoring agent while changing the rate of the background traffic and the packet loss rate due to radio link errors. Fig. 6 shows a typical jitter and packet loss distribution reported in the RTCP receiver reports sent from the client. The diamond plots were obtained with the media stream and the background traffic rates of 80 kbit/s and 320 kbit/s, respectively. The packet loss rate due to radio link errors was 0%. This is the case of good radio links but bad network congestion. The triangle plots, on the other hand, were obtained with the media stream and background traffic rates of 80 kbit/s and 200 kbit/s, respectively; the packet loss rate due to radio link errors was 5%. This is the case of bad radio link condition but good (insignificant) network congestion. Since these plots largely overlap, the media server cannot distinguish network congestion from bad radio link condition if only the RTCP receiver reports from the client are available. Fig. 7 shows a typical jitter and packet loss distribution plotted from the RTCP receiver reports sent from the RTP monitoring agent. The diamond and triangle plots indicate the same conditions as described in Fig. 5. The diamond plots show higher packet loss rate than the triangle plots because the information from the RTP monitoring agent indicates only the congestion state, not the radio link condition. The diamond and triangle plots are well separated, which means that the media server can easily determine the network congestion state. Fig. 8 shows the jitter and packet loss distribution calculated by subtracting the values obtained by RTP monitoring agent from those obtained by the client. The diamond and triangle plots are shown under the same condition as used in Fig. 5. In contrast to Fig. 5, the packet loss rates of the triangle plots are higher than those of the diamond plots. This is because these subtracted values indicate the radio link condition. Therefore, the media server can easily find the radio link condition by comparing the information sent from the client and RTP monitoring agent. B.
Rate and Robustness Control for MPEG-4 Video Streaming
We implemented rate control and robustness control mechanisms for MPEG-4 video streaming using the RTCP receiver reports sent from both the client and RTP monitoring agent. Both rate control
2515
Table 1. PSNR in error-free environment.
0.16 0.14
content I-picture 128 kbit/s 96 kbit/s 64 kbit/s
0.12 Loss
0.10
Background 320k, Error 0%
0.08 0.06
Background 200k, Error 5%
0.04
0.005
0.010
0.015
0.020
0.025
0.030
Jitter (sec.)
Fig. 6. Typical packet loss rate and jitter distribution at the client (media rate = 80 kbit/s). 0.16 0.14 0.12 Loss
An alternative way is changing the frequency of FEC packet transmission to make the overall packet loss rate of the RTP media stream less than a set target rate (1.0% in the following simulations). We used the FEC packet defined in RFC2733[13]. When the FEC packet is generated from N media packets, the FEC packet can recover one lost packet as long as the other N-1 media packets are correctly transmitted. To make the overall packet loss rate less than 1.0%, we chose N to meet the following equation:
Background 320k, Error 0%
0.10 0.08
Background 200k, Error 5%
0.06 0.04 0.02 0.00 0.000
0.010
0.020
0.030
Jitter (sec.)
Fig. 7. Packet loss rate and jitter distribution at RTP monitoring agent.
1
1− ¦ i =0
0.16
0.12
Loss
0.1 Background 320k, Error 0%
0.06 Background 200k, Error 5%
0.04 0.02 0 -0.02 -0.01
-0.005
0
0.005
0.01
Jitter (sec.)
Fig. 8. Packet loss rate and jitter distribution calculated by subtracting the values obtained by RTP monitoring agent from those obtained by the client.
and robustness control were performed after the media server receives each RTCP receiver report sent from the client. Rate control was carried out by switching the video files based on the packet loss rate reported from the RTP monitoring agent. We prepared three bit-rate files, 128kbit/s, 96kbit/s, and 64kbit/s. The media server selected the next lower bit-rate file when the average packet loss rate became more than 1.0%. The average packet loss rate, Pavg_agent, was calculated by the following equation: p avg _ agnet ← p avg _ agent + ( p agent − p avg _ agent ) / w ,
N +1
i N +1−i C i ⋅ p avg ≤ 0.01 . _ radio ⋅ (1 − p avg _ radio )
(3)
The network configuration was the same as in Fig. 5 except that the radio link rate was 128kbit/s in these simulations. The background traffic was generated at 20kbit/s, which made the network slightly congested. We used two video contents; news scene (58 sec.) and soccer scene (60sec.). Table 1 shows the video quality (PSNR) of each video file in error-free environment. We simulated four strategies; no QoS control (none), rate control only (rate), rate and I-picture interval control (rate & I-picture), and rate and FEC frequency control (rate & FEC), while changing the packet loss rate on the radio link. Each strategy started with the video file of the highest quality (i.e. 128kbit/s and 5sec. I-picture interval). We ran each simulation for 650 sec. in simulation time, and repeated each video sequence ten times.
0.14
0.08
soccer 5 sec. 1 sec. 30.74 30.40 29.45 29.34 28.29 27.94
In addition to the rate control, we implemented two kinds of robustness control mechanisms. One is changing the video files according to the average packet loss rate on the radio link, Pavg_radio. Pavg_radio was calculated by the same equation (2). We prepared two video files that have different I-picture intervals, 5 sec. and 1 sec., for each bit-rate. When Pavg_radio was less than 1.0%, the media server selected the video files whose I-picture interval was 5 sec., while the other files was chosen when Pavg_radio became more than 1.0%.
0.02 0.00 0.000
news 5 sec. 1 sec. 31.89 31.41 31.20 30.59 30.10 29.33
(2)
where w was incremented by one upon receiving RTCP receiver reports sent from the client, but reset to 1 when the media server selected the different bit-rate files. We introduced it to keep the transmission rate stable. On the other hand, the media server selected the next higher bit-rate file when the average packet loss rate was less than 0.1% and w reached its maximum value, max_w. We empirically set max_w to 8.
The video packet rates of the four strategies were shown in Fig. 9. Regardless of the packet loss rate of the radio link, the media server generated the video packets at the constant rate when no rate control was applied. When the simple rate control was applied, the media server changed the lowest bit-rate file in the case of more than 1.0% packet loss rate because the server considered the radio link errors as network congestion. The server with the I-picture interval control, on the other hand, kept its video rate at 96 kbit/s and changed its video file to the file more robust against packet losses. When the FEC interval control was applied, the server decreased the video rate with the packet loss rate on the radio link increased. This is because the server increased the FEC packet rate together with the packet loss rate, and therefore, it had to decrease the video rate to avoid network congestion. Fig. 10 shows the overall video packet loss rates. With the rate control, the packet loss rate became much less than without any rate control. The reason why the packet loss rate with the I-picture interval control was nearly 1.0% higher than with the simple rate control is that the server with the I-picture control aggressively tried to higher bit rate, which led to higher packet loss rate in the core network. While the FEC interval control could decrease the packet
2516
140
32 30
100
28
none rate rate & I-picture rate & FEC
80 60
PSNR
video packet rate
120
40
24
20
22
0 0
0.01
0.02
0.03
0.04
none rate rate & I-picture rate & FEC
26
20
0.05
0
packet loss rate on radio link
0.02
0.03
0.04
0.05
packet loss rate on radio link
Fig. 9. Video packet rate vs. packet loss rate on radio link.
Fig. 11. PSNR vs. packet loss rate on radio link (news). 32
0.18 0.16
30
0.14 0.12
28
none rate rate & I-picture rate & FEC
0.1 0.08 0.06
PSNR
video packet loss rate
0.01
none rate rate & I-picture rate & FEC
26 24
0.04
22
0.02 0
20 0
0.01
0.02
0.03
0.04
0
0.05
0.01
0.02
0.03
0.04
0.05
packet loss rate on radio link
packet loss rate on radio link
Fig. 10. Video packet loss rate vs. packet loss rate on radio link. loss rate, it could not make the overall packet loss rate less than 1.0%. This is because the packet losses in the core network could not be ignored. Fig. 11 and 12 shows PSNR of the video displayed at the client. Without any QoS control, the media quality was the lowest among the four strategies because of its high packet loss rate. While the simple rate control showed much higher video quality than without any QoS control, it was still lower than the other two strategies especially when the packet loss rate on the radio link was high. We can see from these figures that use of the feedback reports from the RTP monitoring agent and control of robustness against packet losses improve video quality compared with a simple rate control regardless of which robustness control mechanism is used. V. CONCLUSION
Fig. 12. PSNR vs. packet loss rate on radio link (soccer). REFERENCES [1] [2]
[3] [4] [5] [6]
In mobile packet networks, it is difficult to distinguish network congestion from radio link condition, only from the RTCP receiver reports sent from the receivers. To enable media servers to appropriately control their transmission rate and robustness, we introduced a new proxy named “RTP monitoring agent”. The information sent from the RTP monitoring agent allows the server to determine whether the problem is due to network congestion or radio link errors. Congestion state is indicated by the information sent from the RTP monitoring agent, while the radio link condition can be estimated by comparing the information sent from both the receiver and the RTP monitoring agent. Simulation results showed that the RTP monitoring agent provides adequate information to enable the media server to know both network congestion and radio link condition, and to achieve appropriate QoS control against both network congestion and radio link errors. Our rate and robustness control mechanisms for MPEG-4 video streaming obviously showed their superiority over a simple rate control mechanism. Future research includes more practical evaluations on subjective media quality, computational load, and operational complexity by implementing RTP monitoring agents as well as media servers in real environments.
[7] [8] [9] [10] [11]
[12] [13]
2517
H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. “RTP: A
Transport Protocol for Real-Time Applications”. RFC1889, Internet Engineering Task Force, January 1996. M. Handley, J. Padhye, S. Floyd, and J. Widmer. TCP Friendly Rate Control (TFRC): Protocol Specification. Internet-Draft draft-ietftsvwg-tfrc-01.txt (work in progress), Internet Engineering Task Force, March 2001. S. Floyd, M. Handley, J. Padhye, and J. Widmer. Equation-based congestion control for unicast application. In Proceedings of SIGCOMM ’00, pp. 57-66, 2000. J. Padhye, J. Kurose, D. Towsley, and R. Koodli. A model based TCP-friendly rate control protocol. In Proceedings of NOSSDAV ’99, 1999. D. Sisalem and H. Schulzrinne. The loss-delay based adjustment algorithm: A TCP-friendly adaptation scheme. In Proceedings of NOSSDAV ’98, pp. 215-226, July 1998. R. Rejaie, M. Handley, and D. Estrin. RAP: An end-to-end rate-based congestion control mechanism for realtime streams in the Internet. In Proceedings of INFOCOM ’99, 1999. H. Balakrishnan, V. N. Padmanabhan, S. Seshan, and R. H. Katz. A comparison of mechanisms for improving TCP performance over wireless links. In Proceedings of SIGCOMM ’96, pp.256-269, 1996. H. Balakrishnan, S. Seshan, and R. H. Katz. Improving reliable transport and handoff performance in cellular wireless networks. ACM wireless Networks, Vol. 1, No. 4, December 1995. A. Bakre and B. R. Badrinath. Handoff and systems support for indirect TCP/IP. In Proceedings of USENIX 1995, 1995. H. Balakrishnan and R. H. Katz, “Explicit Loss Notification and Wireless Web Performance,” Proc. GLOBECOM ’98, November 1998. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, LE. Jonsson, R. Hakeberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, and H. Zheng. Robust header compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed. RFC3095, Internet Engineering Task Force, July 2001. Packet Data Convergence Protocol (PDCP) Specification. 3rd Generation Partnership Project, Technical Specification Group Radio Access Network, 3GPP TS 25.323 V3.3.0, September 2000. J. Rosenberg and H. Schulzrinne. “An RTP Payload Format for Generic Forward Error Correction”. RFC2733, Internet Engineering Task Force, December 1999.
