7/31/2019 10.1.1.63.6334

1/8

A Video Gateway to Support VideoStreaming to Mobile Clients 1

Jens Meggers, Thomas Strang, Anthony Sang-Bum Park

Aachen University of Technology, Department of Computer Science 4, Aachen, Germany{meggers|strang|park}@i4.informatik.rwth-aachen.de

Abstract: This paper describes how video streaming from or to mobile participants of a video conferencecan be supported by a so called Mobility Gateway. The gateway interconnects a mobile client,through a wireless link, to a fixed network LAN or WAN multicast environment and performs intelligent operations on the video stream like transcoding, congestion control etc. in order to provide the mobileuser with enhanced video services.

Introduction

The motivation of mobile communication systems is to enable interpersonal communication betweenarbitrary groups of people at any time, any place and in any form. Thus, concepts have been devel-oped to provide services for mobile communication. One of these concepts will result in the futureUniversal Mobile Telecommunications System (UMTS), a third generation wireless system. UMTSwill provide mobile users with new services enabling wireless multimedia like real-time audio andvideo in addition to those services already offered by second generation wireless telecommunicationsystems. In a heterogeneous network where local area networks and wide area networks are integratedinto one global communication system, interoperability will need to take into account the differentcharacteristics of the different components. This may lead to a need for special handling of the trans-ferred multimedia streams. In a multipoint configuration, where different parties share resources andhave different quality of service (QoS) parameters, there is also a need for time variant adaptation.

In order to support mobile multimedia, the OnTheMove 2 project specifies and implements a MobileApplication Support Environment (MASE) [3], which consists of middleware components, located inthe mobile clients, wireless access stations and information servers. The MASE elements located di-rectly on the border between the wireless and wireline network are called the "Mobility Gateway".This paper focuses on the video streaming support provided by the Mobility Gateway and shows howto adapt video transmission from or to mobile clients.

Our approach to support a global mobile system takes into account the heterogeneous networks,which are in use today, by establishing an adaptive application level video gateway at the MobilityGateway. The Gateway does not require any special media formats (i.e. any special video stream for-mat like [2],[6]). Although, support will be more efficient if the media format is known and specialsoftware components are installed, the video gateway operates generally media independent. This pa-per describes a layered video gateway architecture, a prototype implementation, and correspondingmeasurements.

1 This is a revised and extended version of the paper presented at the ACTS Mobile Summit97.2 The OnTheMove project is sponsored by the European Commission in the ACTS program, Bonnier Information Systems AB (S),

British Telecommunications plc (UK), Burda New Media GmbH (D), Centre for Wireless Communication CWC, Deutsche Telekom Mo-bilNet GmbH (D), Ericsson Eurolab Deutschland GmbH (D), Ericsson Radio AB (S), Tecsi (F), IBM (F), IONA, Royal Institute of Tech-nology (S), RWTH Aachen (D), Siemens AG (D), and Sony (D).

7/31/2019 10.1.1.63.6334

2/8

7/31/2019 10.1.1.63.6334

3/8

Another promising method that does not require transcoding is hierarchical coding. The video streamis composed of two or more streams, each enhancing the picture quality of its predecessor. In case of bandwidth bottlenecks, e.g. on wireless links, the higher quality streams are simply skipped. Newercoding schemes can easily be improved to support hierarchical coding modes. Some standards (e.g.MPEG-2) already contain provisions for hierarchical coding, emerging coding methods, e.g. wavelets,provide implicit support for hierarchical coding.

Application Framing

Application framing is closely related to the coding scheme. If knowledge about the syntax of thecoder output is available, the bitstream may be segmented into frames at the application layer. Thenewly created segments form the smallest loss unit that can be encountered at the application layer.This is the basis for graceful degradation in case of errors or losses. Because of the semantic knowl-edge of the bitstream, the error characteristics of the wireless network can be taken into account.

Network Adaptation

At this level full knowledge of the semantic structure of the bit-/frame-stream should be available andmay be exploited to enhance the loss or error properties: Possible methods include protection of vitalinformation, commonly known as unequal error protection, by retransmission or forward error control(FEC) codes. Whilst FEC schemes are often overly complex and require additional bandwidth, ARQ(automatic repeat request) schemes add additional delay. The choice of application controlled ARQschemes nonetheless has its benefits. The application can decide if and when a retransmission is nec-essary. If only non-vital information is corrupted the application can decide to use other methods toconceal the error.

By separating the error and loss protection from the network/transport layer and moving it to the ap-plication layer content-based corruption handling becomes possible. This is in strong contrast to cur-rent transport protocols where all packets are handled the same way. The application only defines theguidelines/policies, the application layer handles the rest to relieve the application and to provide a

predictable behaviour.

Because our gateway is located at application level anddesigned to be media independent, we focus here on thefirst three layers. However, the generic architecture al-lows us to deploy additional schemes that offer furtherbenefits for video transmission.

In contrast to [1] our primary aim is to deal with theconditions on the wireless side, including for instancehigh drop out and error rates as well as low bandwidthcapacities. Placing the gateway between the mobileparticipant and the multicast group, other members of the multicast group are not influenced by bandwidthreductions or other kind of QoS degradation. If onlyone participant in a conference is linked via a wirelessnetwork and one or more other participants are con-nected by a fixed network, the sender has not to reducethe QoS for the other participants as it would happenwhen using an adaptive application. Because of itsadaptive character the gateway is able to react to anykind of modification of the current quality of serviceparameters caused by roaming between networks [5],interferences or fading.

Media- and Channel-Selection

Transcoding and Filter

Application Framing

QoS

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

ABC

DEF

DEF

DEF

DEF

DEF

ABC

DEF

WLAN Ethernet

Network Adaptation

GSM

Figure 2: Layered gateway architecture

7/31/2019 10.1.1.63.6334

4/8

The Implementation

The implementation of our video gateway is based on the Internet protocol suite and makes use of theReal-Time Transport Protocol RTP/RTCP [7] for video transport. RTP is very widespread in Internetvideo conference systems and forms an integral basic part of the ITU standard H.323, which itself isthe most commonly used standard for LAN based video conference systems. This makes the multi-media gateway compatible to a large number of currently available video conference systems.

For measurements and graphical evaluations we use a RTCP monitor tool which observes the controlinformation in the multicast environment. It estimates the current quality of service for distributionmonitoring, fault diagnosis, and long-term statistics. Because the monitor itself does not take part inthe conference, it does not create any network traffic.

Our analyses take place in an environment comprising GSM and Wireless LAN access to multicastsessions on an Ethernet LAN.

RTP and RTCP

RFC 1889 [7] defines RTP as a transport protocol for real-time applications, which has been espe-cially designed for real-time transmissions of multimedia data like audio or video. RTP services haveend-to-end-characteristics and contain functions for packet numbering, timestamps and some controlmechanisms. Applications typically run RTP on top of UDP. RTP itself does not provide any mecha-nism to ensure timely delivery or provide other QoS guarantees, but relies on lower-layer services todo so. It does not guarantee delivery or prevent out-of-order delivery, nor does it assume that the un-derlying network is reliable and delivers packets in sequence. The sequence numbers included in RTPallow the receiver to reconstruct the senders packet sequence, but sequence numbers might also beused to determine the proper location of a packet, for example in video decoding, without necessarilydecoding packets in sequence.

While RTP packets contain chunks of multimedia data as payload, RTCP packets are used to transmit

control information like statistic information about sender or receivers point-of-view of a mediastream, or some other interesting information like jitter estimation etc. The Mobility Gateway - whichitself is a Translator Intermediate System in the RTP notation - evaluates the information provided bythe RTCP packets to do its work on each media stream, which are encapsulated in RTP packets.

Gateway Operation

Our gateway joins a multimedia conference using IP multicast mechanisms with one or more activesenders and any number of receivers.

Independently of the maximum availablebandwidth on the airlink side, the preferred

channel or media types of the mobile client,and other QoS parameters it performsmainly two tasks on the stream to the mobileclient: filtering and transcoding. We con-centrate our work on the video part of mul-timedia streams, because video has the high-

est demands on all components, and the results are fairly transferable to all other kinds of media types.

Transcoding

To meet the usual small bandwidth limitations in wireless networks, the gateway is able to transcodethe media streams into other coding schemes, which may be more easily satisfied with the available

bandwidth. Another reason for transcoding the media streams may be a higher error and loss protec-tion of other coding schemes than the ones used by the media sources in the LAN-based conference.

Table 1: Stream sizes (MPEG-I)Quantizer Scale Bitrate Relation

1 (good quality) 2,7 Mbit/s 100,00 %

15 (medium quality) 228 kbit/s 8,44 %

31 (bad quality) 123 kbit/s 4,55 %

7/31/2019 10.1.1.63.6334

5/8

One example of transcoding is to convert all originating H.261 video streams into the newer and morecompact video stream type H.263.

Another example may be the transcoding of MPEG-I video streams to a lower quality level. Thegateway has to decode parts of the video stream, modify a coding parameter (i.e. the Quantizer Scale ),and re-encode it again. If the original video stream was encoded in an excellent quality, and the mo-

bile client would prefer rather a bad quality than no quality, then transcoding can be used.To get a roughly understanding of the reduction gain by changing the quantizer scale, we coded atypical video as a MPEG-I video with the standard frametype-pattern IBBPBB and different settingsof the Quantizer Scale value. The resulting stream sizes are shown in Table 1. In this example there isthe potential of a compression-factor of 20 and more.

It has to be remarked, that every transcoding has also some disadvantages: Transcoding always addssome additional delay to the stream, and the RTP (packet number, payload type, flags, etc.) as well asthe RTCP information (packet- and byte counter, jitter, etc.) have to be recalculated. Especiallytranscoding schemes for typical video formats such as MPEG or H.261 include real-time decoding aswell as encoding of video information. This process makes extensive use of complex mathematicaloperations such as DCT-Transformation, and fast high-end hardware is necessary. Although the de-coding process may be processed by state of the art CPUs, efficient real-time encoding of video is stilla complex task, usually implemented in hardware. Amir et al. [1] have done work in evaluating dif-ferent transcoding schemes in high bitrate, fixed networks. Their results can be partly transferred tothe situation in our Mobility Gateway.

Filtering

The interarrival jitter and fraction lost estima-tion returned from the mobile client to thegateway may indicate network congestion. Oneuseful reaction is a kind of Load-Shedding : Thegateway may transmit packets with high im-portance and may filter (drop) packets with less

importance. For example, in a video stream, intra-coded frames are more important than inter-codedframes, because inter-frames need a reference-frame to be decoded. If the reference-frame gets lostdue to network congestion or natural loss, it makes no sense to transmit the inter-frame, because itis impossible for the receiver to decode the picture.

By shaping the incoming video stream to a bandwidth appropriate for transmission over the outputlink (wireless link), the Video Gateway avoids further dropping of packets at the network layer. Thisleads to an improved overall video frames per second presentation rate at receiver application.

MPEG-I elementary streams (ES) contain lots of temporal bindings between certain frame types. Fig-ure 3 shows a typical frame-pattern of a MPEG-I ES in display order.

The arrows indicate the dependencies of every frame type. Our gateway has set-up a priority systemto classify RTP packets containing MPEG-I frames according Table 2.

The gateway determines the maximumavailable bandwidth to the mobile client perstream due to RTCP and other QoS sources(i.e. general knowledge about the underlyingnetwork). It filters as many packets from theoriginating media stream according to thepriority order as necessary to reach thebandwidth limitation to the mobile client.

PI I IB B B B B B B B B B B BP PP

Intra-Frame Bidirectional-Predicted FrameForward-Predicted Frame

Figure 3: Typical MPEG-I frame sequence

Table 2: Priority ClassesPrio RTP packet containing1 I-frame + any MPEG Header2 I-frame w/o any MPEG Header3 P-frame referring to I-frame4 P-frame referring to P-frame5 B-frame

7/31/2019 10.1.1.63.6334

6/8

WaveLAN Network Adaptation

If the Mobility Gateway has some knowledge about the underlying network, deploying Network Ad-aptation will improve overall performance. In ourtestbed we installed a Wireless LAN, which isbased on the Lucent WaveLAN Technology.Measurements have shown that this system has aspecial throughput-behaviour in dependence on thetransmitted (UDP) packet size. Figure 4 shows theresults of our measurements.

The major observation deals with the inefficienttransport of small packets. Small packets are alsoproduced, when segmentation of UDP packetstakes place. This leads to the assumption that it

would be useful to transmit two packets, 736bytes and 737 bytes, instead of one packet of 1473 bytes. Indeed, further measurementshave shown that segmentation of packetsbigger than 1472 bytes at application levelgains some profit in the systems throughput,as is shown in Figure 5.

In our implementation, the network adapta-tion layer splits RTP packets bigger than1472 bytes in two or more packets, gainingoverall system-performance.

Integration in the OnTheMove Middleware

Figure 6 shows the overall architecture of the OnTheMove Mobile Application Support Environment(MASE) [3]. The MASE software components are located at the mobile client, Mobility Gateway and

information server. The MASE at the Mobility Gateway forms an ideal platform for the deploymentof the Video Gateway. It provides several functions that are needed by the Video Gateway imple-mentation. These functions and the corresponding APIs ease the development and installation of the

Profit by Segmentation (split-boundary = half packetsize)

0

200.000

400.000

600.000

800.000

1.000.000

1.200.000

1.400.000

1.600.000

1.800.000

1 .4 73 1 .5 73 1 .6 73 1 .7 73 1 .8 73 1 .9 73 2 .0 73 2 .1 73 2 .2 73 2 .3 73 2 .4 73 2 .5 73 2 .6 73 2 .7 73 2 .8 73

packetsize in bytes

t h r o u g

h p u

t i n

b i t / s

0

10

20

30

40

50

60

70

80

90

100

i n p

er

c e

n t

profit in percent with segmentation without segmentation

profit by segmentation in percent

with segmentation

w/o segmentation

Figure 5: Profit by segmentation

WaveLAN: Throughput vs. Packetsize

0

200.000

400.000

600.000

800.000

1.000.000

1.200.000

1.400.000

1.600.000

1.800.000

4 8 4 1 6 4

2 4 4

3 2 4

4 0 4

4 8 4

5 6 4

6 4 4

7 2 4

8 0 4

8 8 4

9 6 4

1 . 0 4

4

1 . 1 2

4

1 . 2 0

4

1 . 2 8

4

1 . 3 6

4

1 . 4 4

4

1 . 5 2

4

1 . 6 0

4

1 . 6 8

4

1 . 7 6

4

1 . 8 4

4

1 . 9 2

4

2 . 0 0

4

2 . 0 8

4

2 . 1 6

4

2 . 2 4

4

2 . 3 2

4

packetsize in bytes

t h r o u g

h p u

t i n

b i t / s

Figure 4: Throughput vs. packet size

Mobile API

UMTS Adaptation Layer

AgentManager

MobileTransaction

Manager

LocationManager Online

Software

UpdateGeneral Support Layer

Applications

PSTN B-ISDN GSM UMTS. . .

Accounting Manager

SystemAdaptability

Manager

Communi-cation

Manager

Figure 6: The Mobile Application Support Envorinment

7/31/2019 10.1.1.63.6334

7/8

Video Gateway. The following architectural components are accessed by the Video Gateway corecomponent which itself is a part of the Communication Manager.

UAL UMTS Adaptation Layer

The UAL offers a uniform API to transport services provided by different access networks and bearerservices. The API allows querying of complex QoS parameters and status information indicating theactual prevailing conditions of the installed access networks. The UAL is needed to allow a simplifiedtransport access and to get QoS parameters needed for the calculation of e.g. filtering functions andtranscoders.

SAM Session Adaptability Manager

The SAM provides means for multimedia conversion functions, like video transcoders. Transcodersmay be deployed, maintained and updated within the SAM. This would enable other MASE and ap-plication components to access transcoder services through the SAM API.

In addition, the SAM holds user and terminal profiles allowing the Video Gateway to start filteringand transcoding processing according to user preferences or hardware limitations. For example, theterminal profile contains information about the display type (colour, b/w, bits per pixel) that enablesthe Video gateway to configure appropriate transcoders or filters.Communciation Manager

The Communciation Manager provides a framework, which allows to deploy application level proto-cols, like HTTP, FTP or SMTP. The core video gateway implementation will reside in the Communi-cation Manager.

Online Software Update

Online Software Update will help to configure the Video Gateway components to the actual videocoding and access networks. An interesting approach is the use of the Agent Manager to instruct mo-bile agents to fetch needed software components (like special filters of software transcoders).

Future Work and Conclusions

We have introduced a video gateway and have shown how such a gateway can improve video servicesfor mobile users. We think, that the experiences from this work could be applicable to some lowbandwidth fixed networks as well, although the implementation incorporates special treatment forwireless LAN networks. A further interesting research direction is the application of error recoveryschemes for IP multicast networks.

Another important future task is the integration of signalling adaptation, in order to support wideinteroperability, like the deployment of this gateway in H.323 sessions.

References

[1] Amir, E.; McCanne, S.; Zhang, H. "An Application Level Video Gateway", Proc. ACM Multi-media 95, San Francisco, CA, 1995

[2] Dasen, M; Frankhauser, G.: "An Error Tolerant, Scalable Video Stream Encoding and Compres-sion for Mobile Computing", ACTS Mobile Communication Summit November 1996

[3] Harmer, J.; "The OnTheMove Project", 3rd International Workshop on Mobile MultimediaCommunications (MoMuC-3), Princeton New Jersey, September 1996

[4] Meggers, J.; Bautz, G.; Park, A. "Providing Video Conferencing for the Mobile User", 21st An-nual Conference on Local Computer Networks, Minneapolis October 1996, IEEE Press 1996

[5] Meggers, J.; Park, A.; Ludwig, R.: "Roaming between GSM and Wireless LAN", ACTS MobileCommunication Summit, Granada November 1996

7/31/2019 10.1.1.63.6334

8/8

[6] Moura, J.; Jasinschi, R.; Shiojiri, H. "Video over Wireless", IEEE Personal Communications,February 1996

[7] Schulzrinne, H. "RTP A Transport Protocol for Real-Time Applications", RFC 1889, January1996