Design and Implementation of Mobile QoS Testbed “MOBIQ” for Multimedia Delivery Services Takeshi Yoshimura, Tomoyuki Ohya, Hosei Matsuoka, and Minoru Etoh Multimedia Laboratories, NTT DoCoMo, Inc. 3-5, Hikari-no-oka, Yokosuka, Kanagawa, 239-8536, Japan {yoshi, ohya, matsuoka, etoh}@spg.yrp.nttdocomo.co.jp Abstract: In this paper, we introduce our mobile QoS testbed “MOBIQ”, which is designed for mobile multimedia services including VoIP (Voice over IP) and audio/video streaming. The key components on this are 1) multiple-reference compression of RTP/UDP/IP headers for efficient media packet delivery on radio links, 2) layer2 combined queueing, which integrates wireless layer2 functionality into an IP-layer queueing model to provide low latency for real-time applications, and 3) QoS (Quality of Service) control utilizing feedback information from a network agent called “RTP monitoring agent” in the face of both network congestion and radio link errors. These components enhance quality of multimedia delivery services in 3G and future mobile networks.

1.

Introduction

In recent mobile environments, Internet access has become very popular as represented by i-mode[1] and WAP (Wireless Access Protocol)[2]. In addition, IMT-2000 (International Mobile Telecommunications-2000)[3] has begun in Japan, and users can now access the Internet at up to 384 kbit/s through mobile devices. At the same time, multimedia delivery services, including VoIP (Voice over IP) and audio/video streaming, are becoming popular over the Internet. Mobile networks are also expected to provide IP-based multimedia delivery services in addition to web access services. From this requirement, 3GPP (3rd Generation Partnership Project), a standardization body of IMT-2000, has begun to discuss “IP multimedia subsystem (IMS)[4]” to support VoIP service, and also has defined “packet streaming service (PSS) specifications[5]” as a standard for streaming services over 3G mobile networks. These multimedia delivery services, however, present a number of challenges for network engineers. Unlike TCP applications, real-time and streaming applications require a certain amount of bandwidth to ensure the bit-rate needed by each media stream and the strict delay or delay variation (i.e., jitter) needed to avoid buffer underflow at receivers. In addition to the requirements from the applications, the intrinsic characteristics of radio links cause the following problems in mobile networks: •

Limited bandwidth: Efficient radio resource utilization is required due to the limited bandwidth of radio links. Especially, since RTP[6]/UDP/IP header overheads are large for audio/video payloads, header compression is essential for real-time and streaming packet delivery. Another problem caused by the bandwidth limitation is the long delay spent by waiting for the transmission of large packets to complete. If a real-time packet arrives just after the commencement of large packet, the real-time packet shall wait the completion of the large packet transmission.

•

Error-prone links: Since radio links have higher bit error rates than wired links, packet loss occurs frequently. Although retransmission is one way to conceal the high bit error rates, it leads to a significant increase in delay. In addition, the packet losses or jitters caused by radio link errors make media senders misunderstand the network condition. Thus, since usual media senders in wired networks consider packet losses and jitters are caused by network congestion, they reduce their transmission rates in the face of the above phenomena.

To solve the above problems, we believe that technical enhancements on both wireless link layer and application layer are essential. Towards future mobile network architecture suitable for multimedia delivery 1

3GPP PSS-compliant Streaming Servers

Traffic Generator

QoS Management Server

Traffic Monitor 3GPP PSS-compliant Streaming Clients

Edge Router Core Router

Edge Router

Edge Router Traffic Generator

W-CDMA RAN emulator

Header Compression & Header Compression RTP Monitoring Agent

Diffserv Core Network

Radio Access Network

Fig. 1. Architecture of mobile QoS testbed (MOBIQ). services, we have built a mobile QoS testbed called “MOBIQ”, on which we implemented several wireless link layer and application layer technologies to improve quality of mobile multimedia delivery. In this testbed, the following technologies are integrated. •

Multiple-reference compression (MRC): MRC is an RTP/UDP/IP header compression method based on CRTP[7] that calculates multiple deltas from the reference headers that have already been sent, and inserts them into a compressed header. The receiver can decompress the compressed header as long as at least one of the reference headers is correctly received and decompressed. MRC improves robustness against packet losses compared with CRTP, and imposes less overheads and computational burden than ROHC (robust header compression)[8].

•

Layer2 combined queueing (L2CQ): L2CQ is a queueing model that combines layer2 functionality (segmentation, retransmission, and header compression). L2CQ conducts packet scheduling in units of layer2 segments to decrease the delay of real-time packets when large packets are transmitted simultaneously. In addition, different retransmission policies are applied according to the requirement of each service class in order to avoid unnecessary retransmission delay.

•

QoS (Quality of Service) control with RTP monitoring agent: We introduce a network agent called “RTP monitoring agent” which lies at the wired/wireless intersection, monitors RTP media streams, and feeds back information to senders about the packet loss and jitter observed at the agent. From the feedbacks from both the RTP monitoring agent and mobile client, the senders can correctly determine the network and radio link conditions, and can adapt their media quality to both conditions.

The rest of this paper is organized as follows. First, we introduce our mobile QoS testbed “MOBIQ” in section 2. In section 3 through section 5, each key technology to support our mobile network architecture, i.e., multiple-reference compression, layer2 combined queueing, and QoS control with the RTP monitoring agent, is described. Section 6 show some results of our experiments on the testbed. Finally, section 7 concludes this paper.

2.

Mobile QoS Testbed “MOBIQ”

We have built a mobile QoS testbed called “MOBIQ” shown in Fig. 1 and Fig. 2. Diffserv[9]-based core network and 3G RAN (radio access network).

MOBIQ consists of

The core network is composed of FreeBSD routers with ALTQ[10] module. ALTQ provides packet classifier, packet-scheduling disciplines including Priority Queueing, WFQ (Weighted Fair Queueing)[11], CBQ (Class-Based Queueing)[12], and queue management schemes including RED (Random Early Discard)[13] and RIO (RED with In and Out)[14]. These functions are necessary for Diffserv core routers. It also provides TOS (Type of Service) field marking and traffic meter functions, which are necessary for Diffserv edge routers. Mobile IPv6 and multicast routing are also running on these routers. 2

Diffserv Core Network with QoS config. interfaces

Streaming Clients

Streaming Servers RTP Monitoring Agent & Header Compression

W-CDMA RAN emulator

Video coding

Speech coding

Audio coding

Session control

Scene description

H.263 MPEG-4 Basevideo line

AMR

MPEG-4 AAC

SDP

SMIL

RTP/UDP (from MP4 file format)

RTSP

HTTP TCP

IP

Fig. 2. Picture of our mobile QoS testbed (MOBIQ).

Fig. 3. Protocol stack of 3GPP PSS-compliant streaming software.

Over the Diffserv-based core network, we have developed a QoS management server, which manages QoS policies and configures all of the ALTQ routers according to the QoS policies. The QoS management server has SOAP[15] interfaces for QoS policy configuration, traffic monitoring, and so on. Through these SOAP interfaces, the mobile network provides flexible QoS provisioning requested by mobile clients or media servers. The 3G RAN includes W-CDMA (Wideband Code Division Multiple Access) RAN emulator[16] and two header compression nodes. The W-CDMA RAN emulator provides Acknowledged mode, which provides retransmission and segmentation functions, and Unacknowledged mode, which provides only segmentation function, defined in 3GPP RLC (Radio Link Control) specifications[17]. The header compression nodes implement three RTP/UDP/IP header compression algorithms, CRTP, ROHC, and MRC (see section 3). The packets whose RTP/UDP/IP headers are compressed are transmitted over the W-CDMA RAN emulator. In addition to the core network and the 3G RAN, we have also developed 3GPP PSS-compliant streaming server and client. The protocol stack of this streaming software is shown in Fig. 3. The streaming server uses RTSP (Real Time Streaming Protocol)[18]/SDP (Session Description Protocol)[19] as its session control protocols, and supports MP4 file format[20] as its input file format. The streaming client also uses RTSP/SDP session control, and supports AMR (Adaptive Multi-Rate), H.263 baseline, MPEG-4 video simple profile, and MPEG-4 AAC (Advance Audio Coding). It works as a SMIL player and issues RTSP requests according to SMIL files downloaded from network. The RTP monitoring agent and a streaming server with QoS control functionality described in section 5 have also been implemented on top of this PSS-compliant streaming software. We are currently implementing L2CQ emulator that integrates W-CDMA RAN emulator, header compression and a simple queueing model. From the next section, each key technology is described in more detail.

3. 3.1.

Multiple-Reference Compression Existing Header Compression

To reduce the overhead of the RTP/UDP/IP header and provide efficient multimedia packet delivery in a limited-bandwidth IP communication link, RFC 2508 has defined an RTP/UDP/IP header compression method called CRTP. CRTP compresses RTP/UDP/IP headers by sending only the differences calculated from its previous header. Although CRTP achieves efficient header compression, its robustness against packet losses is intolerable especially for supposed mobile applications. Since CRTP compresses an RTP/UDP/IP header by referring to just the previous header information, one packet loss causes 3

Compressor

Loss!!

Decompressor

Fig. 4.

Burst Loss!!

FULL_HEADER COMPRESSED_HEADER

Header compression sequence in MRC.

synchronization loss, that is, consecutive packet discards at the receiver even if these compressed packets are transmitted without errors. To complement CRTP’s functionality in an error-prone environment, a new header compression method, ROHC (robust header compression), which considers packet losses expected on error-prone radio links and provides optimum packet loss rate, was defined in IETF RFC3095. ROHC employs LSB (Least Significant Bit) encoding method, which compresses the changing fields by transmitting their LSBs. The LSB encoding method improves robustness because a compressed packet can be decompressed from more than one prior packets according to LSB length. The LSB encoding method, however, causes incorrect header decompression if LSB length is insufficient. To avoid this, ROHC U-mode and O-mode require CRC calculated from the original RTP/UDP/IP header to be transmitted with the compressed header; and the CRC is used to check the correctness of the decompressed header at the decompressor. ROHC R-mode, on the other hand, requires the decompressor to send acknowledgements and the compressor adjusts the length of LSBs in response to the acknowledgements in order to ensure correct decompression at the decompressor. These CRC and acknowledgement mechanisms require more overheads and computational burden and make this implementation more complicated. 3.2.

Basic Operation of Multiple-Reference Compression

Multiple-Reference Compression (MRC) is based on CRTP and uses delta encoding for compressing the changing fields. Since MRC does not employ the LSB encoding used in ROHC, it requires neither CRC nor acknowledgement mechanisms to ensure correct decompression at the decompressor and, therefore, enables easier implementation than ROHC. In addition, MRC offers improved robustness against packet losses by transmitting redundant delta information; and at the same time, it suppresses the overhead of the redundant information. When compressing an RTP/UDP/IP header, the compressor refers to a certain number of headers already sent prior to the header being compressed. At the decompressor, this compressed header can be decompressed correctly as long as at least one of the reference packets was transmitted without link error. Thus, the loss of synchronization between the compressor and the decompressor due to one or more packet losses can be avoided by increasing the number of reference packets. This, on the other hand, increases the overhead to enable correct decompression to be achieved from any of the reference packets. To reduce the overhead, MRC considers the characteristics of deltas from the reference headers and compresses them well as described later. Fig. 4 shows an example of MRC header compression sequence. In this figure, the compressor refers to the first and the fourth packets prior to a packet being compressed. The first four packets are sent as FULL_HEADER packets since they do not have four prior packets. The following compressed packets (MRC packets) are transmitted with deltas calculated from the first and the fourth prior packets. Even if three packets are lost in series, subsequent compressed packets can be reconstructed as before. 3.3.

Selection of Reference Packets

How many and which packets are selected as reference packets are negotiated between the compressor and the decompressor beforehand. These can be decided according to link characteristics (packet loss rate, 4

0

1

2

3

4

5

6

MSB of CID

7 (if 16bit CID)

LSB of CID M

S

T

I

link seq.

UDP checksum

(if nonzero in context)

IPv4 ID multiple-delta code

(if I=1)

RTP SN multiple-delta code

(if S=1)

RTP TS multiple-delta code

(if T=1)

X

1

2

3

4

MRC_RTP format.

5

D1 common factor

Fig. 6.

6

7

D2

field value

RTP payload

Fig. 5.

0

if X=1 & (X,D1,D2)!=0xff If (X,D1,D2)=0xff

Multiple-delta code format.

burst loss length, round trip delay, etc.) and/or media stream types. It is expected that deltas from closer packets (e.g. the previous packet) can be compressed well. Though the compression efficiency worsens if reference packets are far from the packet to be compressed, the robustness against burst packet losses is improved. If the n’th preceding packet is used as one of reference packets, compressed packets can be decompressed correctly in the face of up to n-1 consecutive packet losses. 3.4.

Multiple-Delta Encoding

Since the MRC compressor has to transmit compressed packets including multiple deltas calculated from each reference packet, the number of deltas needed for each changing field equals the number of reference packets. This means MRC creates larger overhead than CRTP, which needs only one delta information for each changing field. These multiple deltas, however, are expected to have a “common factor”. For example, in case of an audio stream whose timestamp sampling rate is 8 kHz and frame interval is 20 ms, its timestamp value increases by the unit of 160 (= 8,000 x 0.02) every packet. In case of a video stream whose timestamp sampling rate is 90 kHz and whose frame rate is 30 frame/sec, its timestamp value changes by the unit of 3,000 (=90,000 / 30). Thus, multiple deltas can be represented by their common factor and normalized deltas that are calculated by dividing original deltas by the common factor. Since the common factor rarely changes, it can usually be omitted as long as it is unchanged, and the decompressor reconstructs the original deltas from the normalized deltas and the common factor transmitted before. Furthermore, normalized deltas can also be omitted if they are equal to those of all reference packets. If the decompressor receives a compressed header without any delta information, it can take the delta information out of the reference packets. 3.5.

Header Formats

MRC defines the following header formats. •

MRC_RTP: Fig. 5 shows this packet format. This packet is used when all static fields are unchanged from all those of the reference packets. The basic format is the same as the COMPRESSED_RTP format used in CRTP, but the multiple-delta codes described later are inserted instead of the deltas used in COMPRESSED_RTP.

•

MRC_UDP: This packet format is used when all static fields of a UDP/IP header are unchanged, but some static fields of an RTP header are changed from at least one of the reference packets. Multiple-delta codes are inserted like MRC_RTP.

•

Multiple-delta code: Fig. 6 shows this format that represents two deltas of a changing field. 3bit D1 field indicates the first normalized delta in the range between –1 and 6, and 4bit D2 field indicates the second normalized delta in the range between –1 and 14. X bit is set to 1 when a new common factor is transmitted, and it is inserted from the next octet after being variable length encoded. If two original deltas cannot be represented by the above format, the escape code (=0xff) is put in the first octet, and the field value is inserted from the second octet as it is. 5

4. 4.1.

Layer2 Combined Queueing General Queueing Model

QoS is one of key elements needed to satisfy the delay requirements of real-time applications. RSVP (Resource ReSerVation Protocol)[21] and Diffserv[9] have already been defined for providing various QoS levels. Regardless of which signaling protocol or architecture is used, each network node needs to have a queueing entity shown in Fig. 7. In general, the queueing entity consists of the following three functions. One is classification: each packet is classified into one of several service classes. In case of RSVP, the classification is based on the IP and other header fields defined by RSVP messages, while it is based on the type of service (TOS) field in the IP header in case of Diffserv. After being classified, IP packets are inserted into the corresponding IP queue. Each IP queue has a buffer management policy to determine whether it drops the inserted packets or not. Drop Tail, RED[13], or RIO[14] can be applied as buffer management policies. Finally, the scheduler selects one IP queue and forwards the first packet of the selected queue to layer2. Priority queueing, WFQ[11], CBQ[12], or any other scheduling policy can be applied here. The mechanisms selected in these components depend on the QoS policy of the network. When the above queueing model is adopted on top of existing radio layer2 entities, the low transmission rate and high packet loss rate of radio links raises two issues. One is the long delay spent waiting for the transmission of large packets to complete. For example, the delay becomes nearly 100 ms if a 1500 byte packet is transmitted over 128 kbit/s radio link. Suppose a real-time packet arrives just after the commencement of large packet, the real-time packet shall wait 100 ms regardless of which scheduling method is used. 100 ms is too long for real-time applications. The other issue is retransmission delay. Since radio links have higher bit error rates than wired links, retransmission occurs often. Retransmission, however, leads to a significant increase in delay. In typical cellular networks, the delay of radio links is nearly 100 ms regardless of packet size; this means that retransmission delay is at least 200 ms, and if several retransmissions are needed, the total delay amounts to 1 second. To preserve in-sequence packet delivery, a packet received cannot be used until all previous packets are received correctly. The retransmission delay is critical for real-time applications. 4.2.

Layer2 Combined Queueing Architecture

To solve the problems mentioned in the previous subsection, we propose a queueing model called layer2 combined queueing (L2CQ) shown in Fig 8. Classifier, IP queue, and scheduler play the same roles as depicted in Fig. 7. Any QoS policy can be applied to these components. That is, any classification policy, any buffer management scheme (Drop Tail, RED, RIO, etc.), and any queueing discipline (PQ, WFQ, CBQ, etc.) can be applied to the classifier, IP queues, and scheduler, respectively. The difference between Figs. 7 and 8 is that the layer2 functions (header compression, segmentation, and retransmission) are placed between IP queues and the scheduler. Each service class has segmentation functionality before packet scheduling. That is, packet scheduling is executed in units of layer2 segments, not in units of IP packets. This enables real-time packet transmission interleaved with large data packet transmission; the waiting time can be determined by adjusting the size of the layer2 segments. Although segmentation incurs more overheads, this is not a problem since radio systems commonly include the equipment needed to perform segmentation. Note that packet dropping should be performed in units of IP packets according to IP queue management policy, not in units of layer2 segments. Therefore, segmentation circuits keep small number of layer2 segments and never drop them. In addition, each segmentation circuit needs to insert its service class ID and a sequence number into each layer2 segment so that the receiver can identify which service class the received layer2 segments belong to and correctly reconstruct the original IP packets.

6

From upper layer

From upper layer

Classifier Real-time

Classifier

Data ・・・・・

Real-time

Data ・・・・・

IP Queue

IP Queue

Scheduler Layer 2

HC

HC

HC

Seg

Seg

Seg

HC ・・・・・

RC

To lower layer

Seg

Layer2 Functions

RC

Scheduler

Fig. 7. General queueing model. To lower layer HC: header compression Seg: segmentation function RC: retransmission control

Fig. 8. Architecture of L2CQ. Retransmission functionality is performed before packet scheduling. This is because the layer2 segments to be retransmitted should also be scheduled according to an appropriate scheduling policy. In addition, retransmission functionality is not provided for all service classes, only for the service classes that require reliability and that accept retransmission delay. The service classes that require real-time packet delivery do not have retransmission functionality; real-time packets are forwarded to the upper layers as soon as they are reconstructed, without waiting for packet retransmission. Another advantage is isolation of the effect of packet losses. That is, when a segment of one service class is lost and retransmitted, the other service classes do not need to wait for the retransmission of the lost segment. Header compression should be carried out just before an IP packet is segmented into layer2 segments in order to minimize the round trip time (RTT) between header compressor and decompressor. Minimizing RTT is important because all of the compressed packets received during one RTT are discarded once synchronization is lost between the compressor and decompressor. When a layer2 segment is received, the receiver checks the service class of the segment and forwards it to the corresponding layer2 entity. As mentioned above, the service class ID is inserted into each layer2 segment at the transmitter. If header compression is provided at the transmitter, the receiver decompresses the header and then forwards the reconstructed IP packets to the upper layers.

5. 5.1.

QoS Control with RTP Monitoring Agent Conventional Rate Control

In the Internet, senders of IP traffic must continually adapt their transmission rates to the network congestion condition. While TCP’s congestion controls are widely known, multimedia applications such as VoIP, video conferencing, and multimedia streaming generally use UDP and RTP as their transport protocol. Neither protocol, however, has any inherent congestion control mechanism. At the moment, a number of papers have considered how to control the transmission rate of non-TCP flows. TCP-friendly rate control (TFRC)[22] and other equation-based congestion controls[23] have been proposed. Some rate control mechanisms utilize the RTP Control Protocol (RTCP) to obtain feedback information from receivers[24][25]. RTCP is used along with RTP to provide quality information on the corresponding RTP media stream as well as some user-specific information. The receiver of an RTP media stream sends back RTCP receiver reports, which include packet loss and jitter information, so that the RTP sender can identify network congestion condition and control its transmission rate accordingly. 7

QoS control (rate & robustness)

packet loss/jitter calculation

packet loss/jitter calculation

RTP media stream BS RTCP receiver report

Media Server

Mobile client

RTP monitoring agent with L2CQ schaping point

Fig. 9.

QoS control architecture with RTP monitoring agent.

These rate control mechanisms 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. When conventional rate control mechanisms are applied to the senders, they 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. 5.2.

Basic Architecture with RTP Monitoring Agent

To enable the senders to realize appropriate QoS control, we introduce a new type of proxy named “RTP monitoring agent” and a QoS control mechanism utilizing the RTP monitoring agent. Fig. 9 shows the network architecture with the RTP monitoring agent. The RTP monitoring agent returns feedback reports corresponding to RTCP receiver reports, but clients also return RTCP receiver reports to the senders. Note that the scheduling point with L2CQ, which adjusts the outgoing rate of all packet traffic to the rate of the radio link, is collocated with the RTP monitoring agent, and the agent monitors RTP packets output from IP queues of the L2CQ entity. This limits the occurrence of network congestion on the path between the senders and the RTP monitoring agent, and eliminates it on the radio link. The reports from the RTP monitoring agent indicate network congestion condition, while those from the client cover network congestion and radio link conditions. Therefore, the senders can determine radio link condition by comparing these two reports. The RTP monitoring agent is a network agent located at the boundary between the wired core network and the wireless link. During streaming sessions, it collects statistics about packet loss, jitter, etc. for each RTP media flow and sends feedback reports to the corresponding senders. To do this, the RTP monitoring agent has to identify each flow by analyzing IP addresses and UDP port numbers. Although someone may point out computational burden, supposed heavy, at the RTP monitoring agents, one agent will not carry so many flows because it is located just before radio links. The supposed overhead 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 senders can determine the correct congestion status and can do appropriate rate control. The RTP monitoring agent does not interrupt any media streams, which means streaming sessions can be continued even in case of agent’s malfunction. 5.3.

QoS Control at Media Sender

The senders have to separate the feedback reports sent from the RTP monitoring agent from those sent from the mobile clients. 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. The senders can control their transmission rates upon analyzing the reports from the RTP monitoring agent 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 senders, therefore, need to estimate radio link condition from the two reports. In the case of radio link errors, the senders have to make their media streams more robust against packet losses. Robustness can be controlled 8

100.0

50 IP Packet Loss Rate (%)

Maximum Video Coding Rate (kbit/s)

55

45 40

Legacy CRTP MRC

35 30

10.0 Legacy CRTP MRC 1.0

25 20

0.1 100

200 Video Packet Size (byte)

500

0.1

Fig. 10. Maximum video rate vs. video packet size.

1.0 RLC-PDU Loss Rate (%)

10.0

Fig. 11. IP packet loss rate vs RLC-PDU loss rate for audio stream

100.0

32

10.0

28 PSNR (dB)

IP Packet Loss Rate (%)

30

Legacy CRTP MRC 1.0

Legacy CRTP MRC

26 24 22

0.1

20 0.1

1.0 RLC-PDU Loss Rate (%)

10.0

0.1

Fig. 12. IP packet loss rate vs RLC-PDU loss rate for video stream.

1.0 RLC-PDU Loss Rate (%)

10.0

Fig. 13. Video quality vs RLC-PDU loss rate.

by several ways. One example is changing the frequency of transmitting forward error correction (FEC) packets[26]. Increasing the frequency of FEC packet transmission increases robustness against packet losses. Changing the media encoding parameters is another way to control robustness. For example, robustness increases with the intra-refresh rate of video encoding.

6.

Preliminary Results

In this section, we show some preliminary results of our experiments over the testbed. 6.1.

Results of Header Compression

We experimented audio/video streaming through the W-CDMA RAN emulator ant the header compression nodes. The streaming server sends both an audio stream of adaptive multi rate (AMR) 12.2 kbit/s without silence suppression and a video stream of MPEG-4 simple profile. The W-CDMA RAN emulator emulates the 3GPP radio link control (RLC) unacknowledged mode[17]. In this mode, packets to be transmitted are segmented into fixed-length sized RLC-protocol data units (PDUs) and transmitted by the unit of RLC-PDU, while retransmission is not applied even if RLC-PDUs are lost on the air. In MRC operations, the first and the fifth preceding headers were selected as the reference headers. Fig. 10 shows the maximum video coding rates with various video packet sizes over 67.2 kbit/s W-CDMA channel. When no header compression was applied (Legacy), the video rate was at most 32 kbit/s. However, when CRTP was applied, the video rate increased up to 50 kbit/s. The video coding rate of MRC was a little lower than CRTP. This means the overhead of multiple-delta codes inserted in MRC_RTP were slightly lager than the delta information inserted in COMPRESSED_RTP. We measured IP packet loss rates, which includes the packet losses caused by the synchronization loss at the decompressor, with various PDU loss rates. Fig. 11 and 12 show the IP packet loss rates for the AMR audio and MPEG-4 video streams, respectively. We can find from these graphs that the IP packet loss rates of 9

128 kbit/s

no-control(128k)

112 kbit/s 96 kbit/s 80 kbit/s 64 kbit/s

140

Loss rate: 1% I-picuture: 1 sec. VP size: 200 byte

Avg. Video Packet Rate (kbit/s)

Loss rate: 0 - 1 % robustness Loss rate: 0 % I-picture: 5 sec. I-picture: 3 sec. VP size: 1000byte VP size: 500 byte bit rate

Rate-control

rate & robustness control no-control(64k)

130 120 110 none(64K) none(128K) rate rate & robustness

100 90 80 70 60 50 40 0.0

Fig. 14. File table at media server.

1.0

2.0

5.0

RLC-PDU Loss Rate (%)

Fig. 15. Video packet rate vs RLC-PDU loss rate. CRTP were approximately five times or more than those of Legacy because the synchronization loss frequently occurred and caused additional packet discards at the decompressor. The IP packet loss rates of MRC, on the other hand, were almost equal to that of Legacy. From these figures, it is obviously shown that MRC reduces IP packet loss rate at near optimum level for both audio and video streams. Finally, we evaluated peak signal to noise ratio (PSNR) of the video streams as a criterion of video quality. Fig. 13 shows the PSNR values measured in the experiments. Since we used the maximum video coding rates at 200-byte packet size obtained in Fig. 10, i.e., the video coding rates of CRTP and MRC were higher than Legacy, their PSNR values outperformed that of Legacy by 2 dB when the PDU loss rate was sufficiently low. The PSNR value of CRTP, however, decreased drastically when the PDU loss rate became higher than 1.0 %. This is because its packet loss rate became very high due to the synchronization loss of header compression. MRC, on the other hand, provided the best video quality even when the PDU loss rate was high. 6.2.

Results of QoS Control with RTP Monitoring Agent

We implemented the RTP monitoring agent and a streaming server with a rate/robustness control mechanism for MPEG-4 video using the RTCP receiver reports sent from both the client. Our media server switches several content files encoded in advance at different bit-rate and robustness. When network congestion is detected from the RTCP reports from the agent, the server changes the file currently served to a different bit-rate file. On the other hand, it changes the content file to a different robustness file when wireless link error condition is detected based on the feedbacks from both the receiver and the agent. As shown in Fig. 14, we experimented four strategies; no QoS control with 64kbit/s content (64k), no QoS control with 128kbit/s content (128k), rate control only (rate), and rate/robustness control (rate & robustness), over the 134.4 kbit/s W-CDMA radio link while changing the RLC-PDU loss rate. Background UDP traffic was injected at 20 kbit/s to make network congestion. The video packet rates of the four strategies are shown in Fig. 15. 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 decreased its transmission rate along with the RLC-PDU loss rate because the server considered the packet losses caused by radio link errors as network congestion. The server with the rate/robustness control, on the other hand, kept its video rate at approximately 90 kbit/s and changed its video file to the file more robust against packet losses. Fig. 16 and Fig. 17 show the overall packet loss rates and video quality (PSNR), respectively. With the rate control, the packet loss rate became much less than the case of 128kbit/s content, and therefore, much better video quality was provided. However, PSNR of the simple rate control was still lower than the rate and robustness control strategy especially when the RLC-PDU loss rate was high. From these figures, we can see that use of the feedback reports from the RTP monitoring agent and control of robustness against packet losses improve media quality in a wide range of the packet loss rate.

10

34

35

32

30

30

25

none(64K) none(128K) rate rate & robustness

20 15

PSNR (dB)

Packet Loss Rate (%)

40

none(64K) none(128K) rate rate & robustness

26 24

10

22

5

20

0

18 0.0

1.0

2.0

5.0

0.0

RLC-PDU Loss Rate (%)

1.0

2.0

5.0

RLC-PDU Loss Rate (%)

Fig. 16. Packet loss rate vs. RLC-PDU loss rate.

7.

28

Fig. 17. Video quality vs. RLC-PDU loss rate.

Conclusion

In this paper, we showed our mobile QoS testbed called “MOBIQ” which is composed of Diffserv-based core network and 3G RAN. On this testbed, we implemented and evaluated several new technologies designed for mobile multimedia delivery services. The key components for supporting mobile multimedia services are as follows. •

Multiple-reference compression: An RTP/UDP/IP header compression based on CRTP, but robust against packet losses

•

Layer2 combined queueing: A queueing model that combines layer2 functionality for providing low latency for real-time applications

•

QoS control with RTP monitoring agent: Appropriate rate and robustness control at media senders utilizing feedbacks from the RTP monitoring agent in the face of network congestion and wireless link errors

Towards future extension, we are now prototyping a mobile streaming media CDN (Content Delivery Network)[27] on top of the current testbed. In this CDN architecture, all of the CDN-related technologies including content segmentation, request routing, pre-fetch scheduling, and session handoff, are controlled by SMIL (Synchronized Multimedia Integration Language)[28] modification. In this architecture, all of the interfaces to control CDN nodes are provided by SOAP messages.

References [1] [2] [3] [4] [5]

NTT DoCoMo, Inc., i-mode, http://www.nttdocomo.co.jp/english/i/index.html. WAP Forum, Wireless Access Protocol, http://www.wapforum.org. NTT DoCoMo, Inc., FOMA (Freedom Of Mobile multimedia Access), http://foma.nttdocomo.co.jp/english/. 3GPP TS 23.002 v 5.2.0, “Network architecture (Release 5),” April 2001. 3GPP TS 26.234 v 4.1.0, Transparent end-to-end packet switched streaming service (PSS); Protocol and codecs, September 2001. [6] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” IETF RFC 1889, January 1996. [7] S. Casner and V. Jacobson, “Compressing IP/UDP/RTP headers for low-speed serial links,” IETF RFC 2508, February 1999. [8] C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. 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,” IETF RFC3095, July 2001. [9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Services,” IETF RFC 2475, December 1998. [10] K. Cho, “Managing Traffic with ALTQ,” In Proceedings of USENIX 1999, June 1999. [11] Demers, S. Keshav, and S. Shenker, “Analysis and simulation of a fair queueing algorithm,” In Proceedings of SIGCOMM ’89, September 1989.

11

[12] S. Floyd and V. Jacobson, “Link-sharing and resource management models for packet networks,” IEEE/ACM Transactions on Networking, Vol. 3, No. 4, August 1995. [13] S. Floyd and V. Jacobson, “Random early detection gateways for congestion avoidance,” IEEE/ACM Transaction on Networking, Vol. 1, No. 4, pp. 397-413, August 1993. [14] D. D. Clark and W. Fang, “Explicit Allocation of Best Effort Packet Delivery Service,” ACM Transactions on Networking, August 1998. [15] Simple Object Access Protocol (SOAP) 1.1, W3C Note, May 2000. http://www.w3.org/TR/SOAP/. [16] H. Inamura, T. Ishikawa, and O. Takahashi, “Evaluation of TCP traffic over W-CDMA network,” IPSJ Technical Report, MBL18-33, September 2001. [17] 3GPP TS 25.322 v 3.5.0, RLC Protocol Specification, December 2000. [18] H. Schulzrinne, A. Rao, and R. Lanphier, “Real Time Streaming Protocol,” IETF RFC 2326, April 1998. [19] M. Handley and V. Jacobson, “SDP: Session Description Protocol,” IETF RFC 2327, April 1998. [20] International Standard ISO/IEC 14496-1: “Information technology - Coding of audio-visual objects -- Part 1: Systems”, 2000. [21] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource ReSerVation Protocol (RSVP),” RFC 2205 Internet Engineering Task Force, September 1997. [22] 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. [23] J. Padhye, J. Kurose, D. Towsley, and R. Koodli. A model based TCP-friendly rate control protocol. In Proceedings of NOSSDAV ’99, 1999. [24] 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. [25] 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. [26] J. Rosenberg and H. Schulzrinne, “An RTP Payload Format for Generic Forward Error Correction,” IETF RFC2733, December 1999. [27] T. Yoshimura, Y. Yonemoto, T. Ohya, M. Etoh, and S. Wee, “Mobile Streaming Media CDN enabled by Dynamic SMIL,” to appear in World Wide Web Conference 2002, May 2002. [28] Synchronized Multimedia Integration Language (SMIL 2.0), W3C Recommendation, August 2001. http://www.w3.org/TR/smil20/. [29] T. Yoshimura, T. Kawahara, T. Ohya, and M. Etoh, “Multiple-Reference Compression of RTP/UDP/IP Headers for Mobile Multimedia Communications,” to appear in IEICE Trans. on Fundamentals of Electronics, Communications and Computer Sciences, July 2002. [30] T. Yoshimura, T. Kawahara, T. Suzuki, and M. Etoh, “Multi-Reference Compression of IP/UDP/RTP Headers for Wireless Communications,” In Proceeding of Wireless Personal Multimedia Communications (WPMC) 2000, pp. 397-402, November 2000. [31] T. Yoshimura, T. Kawahara, and M. Etoh, “Layer2 Combined Queueing for Real-time Communications in Wireless Networks,” IEICE Technical Report, MoMuC2001-7, April 2001. [32] T. Yoshimura, T. Ohya, T. Kawahara, and M. Etoh, “Rate and Robustness Control with RTP Monitoring Agent for Mobile Multimedia Streaming,” to appear in IEEE International Conference on Communications (ICC) 2002, April 2002. [33] T. Yoshimura, T. Kawahara, T. Ohya, and M. Etoh, “QoS Control Architecture with RTP Monitoring Agent for Mobile Multimedia Streaming,” IPSJ Symposium on Multimedia, Distributed, Cooperative and Mobile Systems (DICOMO 2001), June 2001.

12