VOD services for mobile wireless devices
D. Bruneo, M. Villari, A. Zaia, A. Puliafito University of Messina, Department of Mathematics Contrada Papardo, Salita Sperone, 98166 Messina, Italy e-mail: apulia{dbruneo,mvillari,azaia}@ingegneria.unime.it
Abstract
Wireless devices are becoming very popular and pow- erful enough to be commonly adopted to access dis- tributed services. More and more sophisticated applica- tions are being developed and a very promising market is quickly being established where mobile users may ac- cess multimedia data while roaming from a cell to an- other, anytime and everywhere. Such scenario requires a strong infrastructure in order to adequately manage all the different issues related with high level service provisioning. QoS represents one of the most crucial issues as it involves many different aspects and directly impacts the user satisfaction. In order to achieve this target, we propose an architecture which allows mo- bile devices to access advanced services available in the wired part of the network. This architecture, based on mobile agents technology, assumes the presence of a VOD Virtual Server. The strategy adopted is to hide all the basic mechanisms inside a middleware layer that provides the necessary interfaces to allow a sim- ple interaction between the user on the one side and the network and the distributed services on the other.
The overall architecture, that is currently being imple- mented and tested, has been used as an experimental environment to provide mobile users with a new ser- vice to access MPEG-4 flows.
1 Introduction
During the last few years, wireless devices have be- come more and more widely adopted, due to the users’
needs for mobility and information anywhere and at any time [6][8]. New and very powerful wireless hand- held equipments are now available at reasonable costs, and times are mature to develop new services that can
be easily accessed by the final user. Video stream- ing over the Internet [4] is no longer a far imagina- tion. Video On Demand (VOD)[5] should emerge in mid term, with the availability of high bandwidth ac- cess medium (ADSL or cable) directly in the final cus- tomer’s premises. The next step is to allow mobile users to access these services. Big efforts are then re- quired to develop new and powerful mobile devices, to improve the network capacity and to produce more efficient video formats. Mobile devices are already able to support more and more functionalities and are equipped with at least one multimedia player. With regard to video streaming, MPEG-4 video [1] recently hit the radar screen of many popular and trade off pub- lications, mainly as a mechanism for pirating movies.
A reference architecture must be developed, which al- lows to resolve the user mobility issues, while respect- ing the narrow constraints of VOD-like services, mainly in terms of guaranteed Quality of Services (QoS). Mo- bility poses new and challenging issues to be solved [3], among which the QoS management is one of the most crucial, due to the immediate consequences it has on the user’s satisfaction.
It is extremely important to develop an infrastructure enabling an effective QoS management, and allowing the mobile users to benefit from the service requested significantly, notwithstanding the device used and the user’s moves. In [2] we have proposed a reference archi- tecture that makes wide use of the mobile agents com- munication paradigm. In this paper, we focus on the Access Points area and on the design and implementa- tion of a VOD Virtual Server (VS) in particular.
2 Architecture
The proposed reference architecture includes all the
software components involved in providing guaranteed
QoS to mobile users. The scenario we are examining,
(a) Reference Scenario. (b) User Mobility.
Figure 1. Architecture.
which is shown in Figure 1(a), consists of the following areas:
• Wireless Area (mobile devices)
• Access Area (Access Point)
• Wired Area (Internet, Grid)
The Wireless Area is the coverage area of an Access Point, where one or more mobile devices can be found.
Each mobile device is characterized by the presence of a fixed agent called Personal Agent (PA). The task of the Personal Agent is to establish a connection between the user and the agents present in the other areas of the scenario. The hardware and software features of the device used must be considered. In particular, the PA will need to:
• know the user’s identity and profile
• know the physical features of the device where it is resident (screen, CPU, and RAM)
• monitor the ”degradable” components of the de- vice (the battery in particular)
• know the user’s actual position, by means of a GPS, for instance.
The PA is automatically created during the boot stage of the device. The initialization of the PA consists of the loading of data corresponding to the user’s pro- file and to the device features. Once the initialization has ended, the PA monitors the network activity, in order to check the input and the output of the Wire- less Area. When the device enters the Wireless Area, the PA immediately creates a User Agent (UA) in the corresponding Access Point. This User Agent will rep- resent the PA within the Wired Area. The informa- tion exchanged between the PA and the UA concern
the data about the device, the user, the state of some device components (battery, wireless card), position, direction, and speed.
The Access Area is the contact area between the Wire- less Area and the Wired Area. It consists of the Access Points, which allow the mobile devices to access the ser- vices present in the Wired Area. The task of the Ac- cess Points is the management of the issues concerning the user’s mobility and his/her movements from a cell to another, by assuring a high level of transparency and continuity of the service. The Access Points need to manage the user’s mobility (handoff) and to im- plement the management policies of the QoS (reser- vation, allocation and distribution of the bandwidth).
The algorithm used for the management of the QoS in the wireless infrastructure is based on the proactive- reactive hybrid approach described in [9].
The following types of agents will be present in the Access Area: User Agents (UA), GeoLocation Agents (GLA), and QoS Agents (QA). Each time a user en- ters a cell, a UA is created in the corresponding Access Point. The UA will act as an intermediary for the user within the wired area. As soon as a specific service is requested, the UA starts communicating with the ser- vice manager, in order to make it perform the tailoring operations according to the data received from the PA.
These operations are the changes needed for adapting the service features as effectively as possible. Then the UA starts the mediation with the QA present in the Access Point, in order to reserve the bandwidth needed for using the service with an adequate QoS. As we show in Figure 1(b), each time a handoff takes place (that is, each time the mobile device switches from a cell to an- other), the UA migrates to the new Access Point, and therefore follows the user during his/her movements.
In order to know the identity and the address of the new Access Point, the UA sends the data (provided by the PA) about the user’s position, direction, and speed to the GeoLocation Agent present in the Access Point.
Each GLA knows the position, the addresses, and the identity in detail for all of the Access Points present in the Access Area.
Once the UA has received such data, it immediately notifies the QA that the user has moved from a cell to another. This way, the mechanisms of QoS manage- ment (bandwidth reservation in the destination cell, and reorganization of the reserved bandwidth in the wired area) are enabled.
Furthermore, the UA can migrate to the new Access
Point, by using the data coming from the GLA. A
QA will be present in each Access Point. Its task
will be the management of the QoS policies, accord-
ing to the algorithm described before. Considering the
requests coming from the UAs and the QoS policies implemented, the QA performs the bandwidth reser- vation operations, in order to guarantee each user with the QoS required. The QAs exchange some messages, in order to manage the user’s mobility effectively. They reserve the resources appropriately, so to ”anticipate”
the handoff. In the Wired Area, that is the fixed net- work infrastructure, we can find the servers that pro- vide the services (MPEG-4 flows) requested by mobile users. Moving from an Access Point to another might cause considerable changes in the delays in the Wired Area. This might prejudice the QoS policies estab- lished among the Access Points.
In order to try to deal with the issue of the coordination of computational and storage activities and resources present in the Wired Area of the architecture, we as- sume the presence of a Grid computing environment (see Figure 1(a)).
The MA will have the task of monitoring the service requests and the state of the server. The Grid Agent will have the task of managing the Grid services and the movements of data and/or code, the execution of remote jobs, or the access to distributed resources. The MPEG Agents will communicate with the QAs, in or- der to obtain the data concerning the user’s needs for QoS and their mobility. Some nodes will be present in the Grid Area, which will make their resources avail- able. However, they will not act as MPEG-4 servers.
In order to select the most convenient MPEG-4 server, the following relation has been used:
V al
%(S
i, A
j) = 100 ∗ (wl ∗ (load(S
i)/100)+ (1) +wu ∗ (user(S
i)/M AXuser(S
i)) +
+wthr ∗ (throughput(S
i)/M AXthroughput(S
i)) + +wdst ∗ (distance(S
i, A
j)/M AXdistance)) where:
• V al
%is the percentage value assigned to the ith MPEG-4 server (S
i) at the jth Access Point (A
j);
• load is the CPU load of S
i. This value is included between 1 and 100;
• throughput denotes the current throughput of S
i. This is normalized through the maximum possible throughput (M AXthroughput) for S
i;
• user is the current number of users of S
i. This value is normalized through the maximum number of users (M AXuser) accepted by the server;
• distance denotes the distance (in terms of la- tency) between S
iand A
jmeasured in millisec- onds and normalized through the maximum ac- ceptable value (M AXdistance);
wl, wu, wthr, and wdst are the weights assigned to the parameters load, user, throughput, and distance.
Their sum will equal 1.
The previous relation can be periodically evaluated in order to keep trace of changes in the system. When the user wishes to access the system for viewing an MPEG- 4 video (stored in the Grid zone), he/she runs the PA GUI. After an authentication phase, the PA sends the userID to the Access Point. It is checked that a UA corresponding to this userID is not already active or suspended, and then a new UA is created. If a UA with the same userID already exists, it is required to migrate from the old Access Point, where it is either active or suspended, to the new Access Point. Thus, the UA sends an acknowledge message to the PA running on the mobile device. The mobile device sends the user’s request, the information about the user’s profile, and the hardware and software features of the client. This stage is necessary, since the user might change his/her access device while moving from an Access Point to another. In general, the user’s request consists of a set of keywords representing the video he/she is inter- ested in. According to the information received, the UA requests each MA for the list of movies that match with the user’s preferences, and creates a merge for all the lists received. This list, that indicates also the server where the movie is available, is sent to the PA.
At this stage of development, the communications with the MAs are done through broadcast mechanisms man- aged by the agent platform. This might make the sys- tem less scalable. Some solutions are therefore being studied. They are based on peer-to-peer mechanisms, which allow to solve this problem. In order to man- age the video streaming, the Virtual Server described in section 3 has been installed on each Access Point to hide the MPEG-4 server from the PA. This will help to manage frequent situations of server overload and handoff, which require to change run time the MPEG- 4 server used for the video streaming. Thus, the PA will always make reference to the following address:
rtsp://AccesPointAddress:554/SelectedMovie.mp4.
3 VOD Virtual Server
The VOD Virtual Server (VS) shown in Figure 2, is a software layer interposed between multimedia servers and clients. It manages the connection (setup and maintenance) and the data transfer in a wireless en- vironment.
In order to combine the VS into the architecture
described in section 2, it has been designed according
to the agents technology. Whenever a user asks for a
video, the request is sent, through the Personal Agent -
Figure 2. VOD Virtual Server.
User Agent chain, to the QoS Agent located in the cor- responding Access Point. Once the request is accepted, the QoS Agent interacts with the VS, activating all the tasks needed for the video streaming (video search, MPEG-4 server selection, etc.) on the one hand, and creating an agent called Streaming Agent (SA) on the other hand. The SA interacts with the UA during the whole video session, and takes care of the user movements and of his/her requests such as video start- ing, stopping, pausing, restarting, and rewinding. The VS operates as an intermediary between the MPEG-4 server and the client dealing with the following situa- tions:
• the user suddenly loses the connection
• the user disconnects in order to reconnect with a different device
• the user moves from an AP to another
Let consider the first scenario of a sudden disconnec- tion. In this case, the SA, advised by the UA, begins to bufferize video packets till a maximum buffer size is reached. Such buffer size has to be selected according to the available memory and to the number of users to be managed.
Once the buffer is full, the SA activates the video- pausing function in order to stop the video streaming and sets a timer, waiting for a possible user reconnec- tion. If a user reconnection appears by the given dead- line, the UA asks the SA to restart the video stream- ing, flushing the buffer and retrieving new video frames from the MPEG-4 server. We need to notice that in this case the VS is hiding the client disconnection to the server, which otherwise would have stopped the video streaming. If the deadline expires, the VS empties the buffer and tears down the video streaming. Any re- connection of the client will therefore be managed as a new request for service. If a user reconnects by using a different device (for instance, by switching from a PDA to a notebook), the PA present in the device will rec- ognize the UA present in the Access Point, and the VS will therefore need to repeat the same operations to be done in the previous case. Due to the different devices
used, some tailoring operations may be necessary on the video. In fact, if the user switches from a PDA to a notebook, the quality of the screen will be bet- ter. This will enable the user to see a higher resolution video stream. As described in the architecture, these operations will be done by the Grid Nodes present in the Wired Area. However, such operations will be done in background, in order to guarantee the continuity of the service. The VS will switch the streaming only when the video is ready in the correct format.
This will be done transparently for the player. The case of a user who disconnects and then connects again in a different Access Area within the deadline can be considered the same way as we have described in [7].
Let us see what happens during the handoff operation.
The UA anticipates the user’s roaming, and migrates
to the new AP for allocating the resources needed. Fur-
thermore, the UA asks the QoS Agent to create a SA,
and to put it in contact with the SA present in the
former AP. The SA will be informed about the state
(MPEG-4 server, video, and progress of the view), and
will get in contact with the MPEG-4 server, in order
to obtain a streaming of the video requested, starting
from the point reached by the user. Furthermore, the
SA will wait for the user to pass. Once the handoff
takes place, the stream to the client starts. From the
user’s point of view, this allows to view the video con-
tinuously. In the worst of the cases, some frames may
be lost, due to the synchronization problems. In fact,
even if the exact time of the user’s roaming to another
cell can be anticipated, in a real case this can hap-
pen later or earlier. This can be solved by designing
the cells so to make them partially overlapped. The
VS plays an important role during the load balancing,
as well as during the selection of the most appropri-
ate MPEG-4 server. Such operations take place in the
Wired Area, as we have described in section 2. The
Grid Zone will try to make a new distribution of the
load among the MPEG-4 servers either periodically or
as a reaction after a handoff. This operation may move
the video from a MPEG-4 server to another, and con-
sequently disconnect the player present in the mobile
device. The VS (which is appropriately notified by the
Grid Zone through the chain Grid Agent - Streaming
Agent) can make the operation of server change trans-
parent for the user, by buffering several packets, so to
assure the continuity of service while switching from
an MPEG-4 server to another. Furthermore, the VS
enables to synchronize the MPEG-4 servers, by notify-
ing the new MPEG-4 server with the exact point the
streaming must be resumed from. The VS is designed
to be run in wireless 802.11b APs. Multimedia com-
munications are synchronized and managed by the Real
Time Streaming Protocol (RTSP) which uses the Real Time Protocol (RTP) as transport layer. The RTSP protocol uses the TCP protocol to communicate with its peer. The RTSP and HTTP protocols have similar syntax and operations, even if the RTSP semantically introduces some new methods and has a different pro- tocol ID. Since the TCP is a transport protocol with connection, if the wireless device temporarily discon- nects, the VS needs to restore a connection through the setup phase.
The RTP protocol enables to send multimedia data, and uses the UDP as transport protocol. Consequently, all the weaknesses in the management of multimedia communication are overcome by using the RTP on the UDP. The RTP Control Protocol (RTCP) is often used together with the RTP. The RTCP provides the sender with a feedback about the quality of the current trans- mission. If the client disconnects, the RTP packets are buffered. When the client connects again, the packets are sent from the VS to the client. In order to make the client transparent to the server and vice versa, the VS receives the incoming RTSP packets, then processes and sends them. The RTP packets do not need any pro- cessing, since no track of the sender and the recipient is contained in them. The VS therefore receives the UDP datagram and sends it. Basically, the VS can be placed one level higher than the RTSP. It implements the fea- tures needed for making the video streaming reliable in a wireless environment. In conclusion, the VS is a device that emulates a multimedia MPEG-4 server pro- viding a good QoS for the wireless systems that want to interact with multimedia applications.
4 Implementation and Experimental Results
Our measurements concern the delays introduced by the use of the VS with reference to both RTSP control packets and RTP data packets. The testbed consists of the following components:
• A MPEG-4 Server.
• Some Clients equipped with Multimedia Players.
• Three APs on which the Virtual Server is running.
The MPEG-4 streaming server, based on a Pentium IV architecture with Red Hat Linux (Kernel 2.4.18-3) OS, has been tested with two Software Suites:
1. RealNetworks Helix Universal Server Basic.
2. Apple Darwin Streaming Server 4.1.2.
We have used some clients based on a Pentium architec- ture, as well as the OS Linux Red Hat, Windows 2000 and XP, equipped with the following Players compati- ble with the MPEG-4 streaming:
• MPEG4IP Player (Windows/Linux).
• QuickTime Player 5.0.2 (Windows).
• RealNetworks RealOne Player + Envivio Plugin (Windows).
The multimedia flow has been tested by a Compaq iPAQ 3870 equipped with Windows PocketPC 2002 OS, Wireless card 802.11b, InterObject SMIL Player, and RealOne Real Player. The APs we have used are based on a Pentium MMX @ 166 MHz architecture, 128 MB of RAM and 64 MB DOM (Disk On Module) of mass storage, and are equipped with an embedded version of Linux based on the kernel 2.4, and with Kaf- feVM. Several movies of different resolution and dura- tion, codified according to the standard MPEG-4 and bitrate up to 370 Kbps, have been used. The VS has shown to be able to work also with other types of cod- ing such as Real Media, MP3, MPEG1, and SWF. In order to check the correct operation of the VS, two experimental trials have been organized: the first one aims to show the correct operation of the player in a single user configuration, while the second one tests the behavior of the VS in a multi-user configuration. The results of the trials are shown in Figures 3(a)/3(b) and 4(a)/4(b) respectively. In the single user session, we have measured the flow of the RTP and RTSP pack- ets in a high mobility scenario. The client, while fre- quently roaming among the areas covered by the three APs, has produced a large amount of RTSP packets, which are necessary for the control phases of the flow and for redirecting the flow to the various APs.
In Figure 3(a) we can see the delays introduced by the
VS on the flow of RTP packets. In the upper figure
we can see that the VS introduces a delay shorter than
70ms for almost all of the packets, while in the lower
figure we observe that more than 60% of the RTP pack-
ets are processed by the VS in less than 15ms. Another
interesting consideration concerns the packets related
to the multimedia flow. In fact, we have observed that
most of the packets with a delay longer than 30ms are
the first RTP packets processed immediately after the
connection phase. In the other phases, the delays are
almost constant and shorter than 30ms. This affects
the view of the movies (and of the multimedia flows
in general) with a small initial delay introduced by the
VS, but it does not influence the correct use of the
stream during the view. Conversely, with reference to
the RTSP packets, in Figure 3(b) we observe that more
(a) RTP Packets. (b) RTSPb Packets.
Figure 3. Number of RTP and RTSP Packets in a single-user/high mobility session.
(a) RTP Packets - 5 Players.
(b) RTSP Packets - 5 Players.