Chapter 1

Copyright by Bo Zou 2000

MOBILE ID PROTOCOL: A BADGE-ACTIVATED APPLICATION LEVEL HANDOFF OF A MULTIMEDIA STREAMING TO SUPPORT USER

MOBILITY

BY

BO ZOU

B. S. Nankai University, 1990

THESIS

Submitted in partial fulfillment of the requirementsfor the degree of Master of Science in Computer Science

in the Graduate College of theUniversity of Illinois at Urbana-Champaign, 2000

Urbana, Illinois

To my family

Abstract

Current multimedia streaming applications, such as video on demand, are “machine- oriented”,

and do not support user mobility. In this thesis, I designed and implemented a badge-activated

application-level handoff protocol, called Mobile ID protocol, to implement user mobility

support for multimedia streaming applications. The protocol has a location-aware system to

detect user movement on the client side, a Mobility database to store all the interrupted sessions

on the server side, and Mobile ID client/server- side manager pair coordinates the events on

either side, work closely with location-aware system, Mobility database, and video client/server

pair to carry out the “user- oriented” streaming application we now have. The protocol is

implemented at the application level. Performance data shows that the time loss during the

handoff is in the acceptable range, and the frame loss during the handoff is related to encoding

pattern of the video file.

Acknowledgements

I sincerely thank my advisor Prof. Klara Nahrstedt for her guidance and support in completing

this thesis. I also thank Dongyan for the lengthy discussions for the project, Dao for all sorts of

support. Thanks to Yuxin for his friendship, and all the lab mates. I also thank my family for all

their support, love and encouragement.

Table of Contents

Chapter 1..........................................................................................................................................1Introduction......................................................................................................................................1Chapter 2..........................................................................................................................................3Related Work on User Mobility:.....................................................................................................3Chapter 3..........................................................................................................................................6Mobility issues related to video on demand....................................................................................6Chapter 4..........................................................................................................................................8System design..................................................................................................................................8

4.1 High-level Architecture..........................................................................................................84.2 System components:.............................................................................................................10

4.2.1 Location-aware system component:...............................................................................104.2.2 Mobile ID client-side manager:.....................................................................................104.2.3 Mobility database:..........................................................................................................124.2.4 Mobile ID server-side manager:....................................................................................124.2.5 Video client/server.........................................................................................................13

4.3 Event flow:...........................................................................................................................134.3.1 Current user starts a streaming session:.........................................................................13

Figure 3. Event flow chart when user starts a multimedia session...............................................144.3.2 Current user moves:.......................................................................................................14

Figure 4. Event flow chart when current user moves....................................................................154.3.3 New user is detected:.....................................................................................................15

Chapter 5........................................................................................................................................17Implementation:.............................................................................................................................17

5.1 Development environment...................................................................................................175.2 Location-aware System---AIR ID System...........................................................................18

5.2.1 Air ID system.................................................................................................................185.2.2 Implementation of integrating AIR ID system as location-aware system.....................195.2.3 Location-aware system can detect user movement........................................................20

5.3 Mobile ID client-side manager.............................................................................................215.3.1 Client-side manager implementation.............................................................................215.3.2 Message exchange and responding events in the client-side manager.........................22

5.4 Mobility information database.............................................................................................245.4.1 Implementation of mobility database.............................................................................245.4.2 Access Mobility database...............................................................................................25

5.5 Mobile ID Server-side manager:..........................................................................................255.5.1 Main Tasks of Mobile ID server-side manager.............................................................265.5.2 Implementation of Mobile ID server-side manager.......................................................26

5.6 Video Client and Server.......................................................................................................29Chapter 6........................................................................................................................................30Experiments and results.................................................................................................................30

6.1 Testing environment.............................................................................................................306.2 Measurement Metrics...........................................................................................................316.3 Test scenarios and results.....................................................................................................32

6.3.1 Test AIR ID system automatic logon response time......................................................326.3.2 Real world handoff experiment......................................................................................34

6.3.3 Time loss during handoff when user approaches a machine without logon process.....346.3.4 Time loss during handoff when user logons a machine using AIR ID system..............36

6.4 Performance issues of Mobile ID protocol...........................................................................38Chapter 7........................................................................................................................................40Future work....................................................................................................................................40Chapter 8........................................................................................................................................41Conclusion.....................................................................................................................................41References......................................................................................................................................43

List of Figures

Figure 1: Application-level handoff of multimedia streaming......................................................9Figure 2: Mobile ID protocol for multimedia streaming.............................................................11Figure 3: Event flow chart when user starts a multimedia session..............................................14Figure 4: Event flow chart when current user moves..................................................................15Figure 5: Event flow chart when new user is detected...............................................................16 Figure 6: AIR ID system hardware..............................................................................................18Figure 7: AIR ID logon response time for client 1......................................................................33Figure 8: AIR ID logon response time for client 2......................................................................34Figure 9: Time loss during handoff on client 1 without user logon process..............................35 Figure 10: Time loss during handoff on client 2 without user logon process...............................36Figure 11: Time loss during handoff on client 1 with user logon process....................................37Figure 12: Time loss during handoff on client 2 with user logon process....................................38

Chapter 1

Introduction

With the explosion of broadband technology in recent years, high quality video on demand over

the network, even over the Internet, becomes reality. Streaming technology, which allows the

delivering of frames in the sequence, is used in video on demand application to reduce the delay

caused by downloading large video files. A lot of work has been done in the field of streaming

multimedia content. Most of the effort has focused on avoiding or reacting to congestion within

the network. Both lossless and lossy approaches have been developed. Also, some approaches

provide guaranteed service by allocating resources necessary for data transmission beforehand

[1,2,3], while others use best-effort service networks [4]. Another aspect of video on demand

application, which is for the convenience of the viewing customer, is to provide the customer

(user) with mobility support while streaming content is in session.

User mobility has two implications: Terminal mobility refers to mobile terminals, and it will allow

terminals’ movement along with the user. The network will locate and configure the moving

terminals to provide service to the user. Personal mobility refers to the users, and it will allow uses

for change of physical location from terminal to terminal in a network, either within a room,

between rooms or between buildings, at the same time retaining their application sessions. This

means that defined services will follow the user to the terminal that user currently located in a

seamless way after movement.

In this thesis, a new protocol – mobile ID protocol for multimedia streaming, has been developed

to add the mobility support for the streaming of the multimedia content, such as video on demand

applications. I assume an environment of ubiquitous computer deployment, so I deal with personal

mobility. I have integrated in mobile ID protocol an electronic tags system – air ID security badge

system – as the location-aware system for the protocol, which constantly keeps track of the mobile

users’ whereabouts without user intervention, I have also developed an application-level handoff

of multimedia session routine for the protocol to redirect the session from one location to another

when user physically moves.

The thesis is organized as follows: Chapter 2 introduces some of the related work that has been

done in the field of user mobility, Chapter 3 discusses some of the issues in video on demand with

mobility support. Chapter 4 describes the design of Mobile ID protocol. A detailed description of

the system implementation is provided in Chapter 5. Chapter 6 presents the experiments we

conducted using the protocol and some performance analysis data. Chapter 7 discusses some

possible directions for the future research and Chapter 8 presents some concluding remarks.

Chapter 2

Related Work on User Mobility:

User mobility implies both terminal mobility and personal mobility. Many projects are currently

being conducted actively on the user mobility. Mobile IP [5] is dealing with terminal mobility,

which serves as the standard for mobile devices, such as laptops, PDAs, etc, which users carry

around to connect to the network. There is also a great demand for the network to support personal

mobility. Because my work is more related to personal mobility, here I concentrate on some of the

projects that target personal mobility support.

Teleporting project: Teleporting [6] supports user mobility by letting the user interface of an

application to follow the user. The application itself doesn’t move. The teleporting system is based

on the technology of X window system. A proxy X server can forward X protocol requests to

another server, so the display of X applications can be forwarded to different servers where the

user is currently at. A simple database provides the mapping between current location and

workstation display. Teleporting ties to X system, only user interface follows the user, underlying

application is still on the original machine, control messages need to relay back and forth between

the user current location and the original site which holds the application itself. This takes time

and congests the network. Furthermore, because application itself is not moving, dynamic

configuration is impossible.

Total Mobility Environment [7]: User registers and de-registers for use of a mobile computer in

disconnected state. User’s files are replicated at the mobile devices when he/she registers. A log

file is used to identify the modification that user makes while he/she is on the move and

disconnected from the network. When the user de-registers with the mobile device, which means

that user connects to the network again, the master copy of the user files on the network is updated

by the modification the user makes when he/she is on the move. The log file also helps to resolve

conflicting modifications by users sharing the same file. Total Mobility handles low-bandwidth

link or no connections at all situations, so user can gets a copy of his/her files and stores on a local

machine, and works on that machine, and later on updates the main copy.

Middleware support for mobile application: Many mobile agent systems have been developed.

The applications of these systems include active documents [8], managing hypermedia [9],

information gathering [10], migratory applications [11]. The system of Middleware support for

multimedia applications [12,13] is also a mobile agent system. It maintains a central database

storing user- location information for all the users in the system, location-aware mobile agent can

detect user movements and respond by moving to the user’s nearest computer or take other actions

to allow complex state migration. A scheme for locating and binding media object is also

provided, so the user can use exiting services on the machine he/she is currently at or the machines

near his location to provide service for him.

NetChaser: Agent systems are also developed for the Internet [14]. NetChaser [15] is a mobile

agent-based infrastructure for supporting personal mobility in accessing Internet services.

NetChaser’s mobile agents form a wrapper between applications and network, assist user by

following them when they change working terminals. The system uses Internet browser alone as

the user’s front end. The NetChaser uses agent mobility to track user movement, which allows

session to be suspended and then resumed from another terminal. By trying to predict user’s future

actions by exploiting agents’ intrinsic characteristics [16], agents can help provide more effective

and personalized service.

The latter two projects target what I focused on. They are dealing with broader issue and

implemented in system software level. I chose to focus on developing a protocol to support user

mobility at application level. The protocol, presented in the thesis, is a badge-activated application

level handoff of a streaming multimedia, which is a protocol to support user mobility for

multimedia streaming application such as video on demand.

Chapter 3

Mobility issues related to video on demand

Video on demand at current stage is a machine (location)-oriented application, in which user goes

to a computer (or entertainment center connected to the network) to request video and/or audio. A

streaming session corresponding to the user’s request is then set up between the machine and

server, and content is delivering to that specific client machine. When the user wants to move to a

different location, he/she has to stop the video play at current location, and make a new request at

the new location; also, he/she has to physically search for the frame that he/she just stopped at

previous location in order to continue viewing. There is no support for user mobility.

Building a system that supports personal mobility for video on demand is of great interest, with

the increasing popularity of the video on demand, which is fueled by the recent development of

the broadband technology. This will give a new meaning to video on demand, as we currently

know it. Here is a future scenario for the video on demand: in a future family, there could be

entertainment centers in different rooms, e.g. living room, bedroom, etc. When a user moves from

room to room, a location-aware system monitors the user location, when user moves, he/she

doesn’t need to physically stop the movie play on current location, the system detects the user

move-away and stops the session automatically. When the user moves to a new location, he/she

doesn’t need to request the same movie again or search chapters; rather, the location-aware system

detects the user presence and automatically resumes the session that has been stopped on the

user’s previous location. This establishes a system that multimedia streaming will follow the user

from location to location without any user involvement. Location-aware system monitors user’s

location, and streaming will then be forwarded to the user’s current location. This user-oriented

concept of video on demand is more desirable compared to the machine-oriented concept we see

today.

In this thesis, I developed a protocol, Mobile ID protocol for multimedia streaming with user

mobility support, to implement this user-oriented concept.

Chapter 4

System design

4.1 High-level Architecture

Figure 1 shows the high level architecture of the Mobile ID system. A server offers a collection of

movies. Upon request from a client, which is tied to the user currently on that client by location-

aware system, the server starts a streaming session to that client where the movie gets displayed,

in turn this streaming session is tied to the current user on that client.

During the playback, the user may move, the location-aware system will detect the user movement

and stop the streaming session automatically, in the mean time, server gets informed, and the

session state (user, file name, current frame, etc) is stored to a central database server (database

server could be a separate server machine or coexist with the video server machine).

When user’s presence is detected by the system again, and information is sent to the server, either

on the same client (user moves back) or on a different client (user moves to a different location),

the server will resume the session, which has stopped previously because of the user movement,

on the client machine that user is currently on.

Figure 1. Application-level handoff of Multimedia Streaming

Play a movie session Session stop

Store the session info

Session resume on a different machine

Session resume onthe same machine

4.2 System components:

Mobile ID system can be seen as made-up of the following functional separated yet tightly

coupled components, shown in Figure 2. They are location-aware component, Mobile ID client-

side manager, Mobile ID server-side manager, Mobility database, and video client/server pair.

We can think of location-aware system, client-side manager and video client make up the Mobile

ID client, and on the other side, server-side manager, Mobility database and video server make up

the Mobile ID server. The following sections will give an overview of each component in the

mobile ID system.

4.2.1 Location-aware system component:

Location-aware system component is an entity for locating the user. One way to accomplish this is

to let all the client machines on the network to have a way to detect user. The user is then bond to

the specific machine (location), which detects him/her. When the user moves to another machine,

his/her bond with the old machine is lost because he/she can’t be detected on the old machine any

more due to his/her move-away. At the same time, the new machine will detect the user.

Consequently he/she is then bond to the new location. This binding is reported when necessary,

network will use this binding information to keep track of user location.

4.2.2 Mobile ID client-side manager:

Mobile ID client-side manager manages the events in response to the user movement on a specific

client machine (a location). When it receives user movement information, such as “current user

moves away”, “new user arrives”, etc, the client-side manager will manage the response to those

information. According to the user movement information received and the current state of the

Figure 2. Mobile ID Protocol for Multimedia streaming

location aware system

Video server

MobilityInfo database

Video client

Media file

”new user”.

User has an interrupted session

“positive response ” to start playerMedia session

state

Session setup request/Move at frame

Updated session setup request

Media streaming

Database entry

File name,Frame number…

File nameFrame number…

Tom

audiovideouser

Client manager

Server manager

store“User move” toStop player

“User move” toStop player

Client Server

client, client-side manager could send instructions to video client, send various messages to the

server, and it also manages the client reactions to the server responses.

4.2.3 Mobility database:

Mobility database stores the session states for all the sessions that currently being interrupted

because of the user movement. It serves as the information center for all the users who are

currently on the move while have an active streaming session at the time they start moving.

4.2.4 Mobile ID server-side manager:

Mobile ID server-side manager manages events in response to client’s different requests on behalf

of the user on that machine. It works closely with the Mobility database by consulting and

updating the database to fulfill the client’s request. It serves as the only entry point to the mobility

database. When it receives "MOVE" from a client for an active session, it will store the current

session state to the Mobility database, and stop the current session. When it receives request for

playing, it first contacts the Mobility database, use information stored in the database to update the

request based on the user ID information in the request. This update will restore the previous

session state this user may have, which has been interrupted due to the user movement. When

server-side manager receives inquiry request from a client on behave of a user that client newly

detects, it will consult with the mobility database for that user and return the results, e.g. if the

user has an suspended session, what type of session (video session and/or audio session) the user

has.

4.2.5 Video client/server

The video client/server pair represents the components for displaying (client) and delivering

(server) streaming multimedia content.

4.3 Event flow:

Each system component has its own distinct functionality, but they closely work together to

accomplish a task. Figure 3 shows the event flow charts under various situations. Figure 3 shows

the event flow chart when the user starts a multimedia session on a client. Figure 4 shows the

event flow chart when user moves. Figure 5 shows the events take place when a new user is

detected. The following sections describe each situation in detail.

4.3.1 Current user starts a streaming session:

As shown in Figure 3, location-aware system ties the user with the client machine that user is

currently at. The user requests a movie through video client on that machine, the request will be

sent to the server. Server-side manager updates the request by consulting the Mobility database on

behalf of the user (if this user has a suspended session, the request will be updated to restore the

old session state, otherwise, it doesn’t do anything), and passes the updated request to the video

server. The video server then delivers video stream to video client according to the request. Movie

starts playing.

Video Server-side Mobility Video Client manager Database Server

Session setup request consulting

request

results

update setup request

updated session setup request

Video/audio stream

Figure 3. Event flow chart when user starts a multimedia session

4.3.2 Current user moves:

During the stream session, user moves (shown in figure 4), location-aware system detects user

movement, sends the signal to mobile ID client-side manager informing the user movement,

client-side manager check with the video client, if video client has an active session, it forces

video client to send “MOVE” message to the server-side manager, and stop the session on the

client side. When server-side manager receives "MOVE" signal on an active session, it stores the

session state (user, file name, frame number) to the Mobility database and stops that session on the

server side.

Location aware Client-side Video Server-side Mobility Videosystem Manager Client Manager Database Server

user moves

Invoking “Move” move

at framestore session

Stop state

stop

Figure 4. Event flow chart when current user moves

4.3.3 New user is detected:

When location-aware system of a client locates a new user (shown in figure 5), the user will be

bond to that client machine. The mobile ID client-side manager reacts to “new user detected” by

sending "INQUIRY" message to the server on behalf of the user. The server-side manager

responds to the inquiry by consulting the mobility database and sends the results back to the

inquiry client. Client-side manager receives the results for the inquiry. If the response is negative,

nothing happens. If the response is positive, client-side manager will invoke the video client, send

session setup request to server, server-side manager will update the request by consulting the

Mobility database to restore the suspended session state. The updated request is then sent to the

video server, and the old session is resumed on the new client (new location).

Location aware Client-side Server-side Mobility VideoSystem Manager Manager Database Server

New user new user inquiry

consulting

results

response to inquiry

Video Client

Positiveresponse

session consultingsetup

results

update session setup request

updated setuprequest

multimedia streaming

Figure 5. Event flow chart when new user is detected.

Chapter 5

Implementation:

This chapter provides a detailed description of the implementation of Mobile ID protocol. I

introduce my development environment first. Then each of the following subsections describes the

implementation of a different component of the system. I describe the location-aware system, the

client-side manager, the Mobility database, the server-side manager, and the video client/server

pair.

5.1 Development environment

Except for some of the location-aware system related code, all of the other codes are written in the

Java programming language, in order to take its cross-platform advantage. The java code was

developed on a Windows NT 4.0 workstation using Sun JDK 1.1.8 development environment.

However, some of the location-aware system related code is written in C++, because API for

underlying integrated hardware is written in C++. The location-aware system related code was

developed on a Windows NT 4.0 workstation using Microsoft Visual C++ 6.0 development

environment.

In Java programming language, the Runtime.exec methods create a native process and return an

instance of a subclass of Process that can be used to control the process and obtain information

about it. The class Process provides methods for performing input from the process, performing

output to the process, waiting for the process to complete, checking the exit status of the process,

and destroying (killing) the process. I used Runtime.exec to invoke the executables compiled from

C++ code in the java environment.

5.2 Location-aware System---AIR ID System

I integrated AIR ID system as location-aware system in my mobile ID protocol for multimedia

streaming. In the sections below, I introduce the AIR ID system in general, and discuss the

implementation of integration of the system as my location-aware system.

5.2.1 Air ID system

Figure 6. AIR ID system hardware

AIR ID hardware is shown in Figure 6. AIR ID is a proximity activated access control system that

tells the client PC when authorized user is present. Unlike password system, biometrics readers,

and smart card, AIR ID uses RF (radio frequency) and therefore no user involvement is needed.

The main components of the AIR ID System are the Base Unit and badge. The Base Unit is

attached to the serial port using the cable and adapter. The badge maybe clipped to the user belt,

jacket, collar, inside front pocket or wore around the neck. When a user approaches his/her PC, the

system automatically detects the user, using RF communication to exchange the user

authentication information, log the user on and grant immediate access.

5.2.2 Implementation of integrating AIR ID system as location-aware system

I use AIR ID system as a user locator rather than a security device for my Mobile ID protocol. In

order to enable AIR ID’s contiguous detecting capability to monitor the user movement, a client-

side ping program was developed. First, using AIR ID API (AIR ID API is written in C++), a C++

program extractID that extracts user ID from the badge was developed. extractID code sets the

necessary environment parameters for the underlying hardware to enable the information

exchange between the badge and the base, and a function call to getActiveID( ) is invoked, to

retrieve the current user ID that can be detected and return the current user ID.

Next, a Java class GetID to invoke executable extractID.exe was developed to provide a routine

that can be easily called directly in Java. Static function getID() is used to call the routine and

return the user ID that is currently being detected.

public static int getID() { int id=0; String fileName="execuableFile"; Runtime run=Runtime.getRuntime(); Process process=null;

try { process=run.exec(fileName); process.waitFor(); id = process.exitValue(); } catch(Exception e){} return id; }

The ping program is implemented by Java class TestID. This class starts a separate thread, and

makes function call to GetID.getID() periodically (every 10 second). The location-aware system is

based on the result of the ping program. When there is no user at current machine (location),

TestID will return "USER_NOT _DETECTED". If a user approaches the machine within range,

TestID will return current Active ID. When two contiguous calls to GetID.getID() return different

values, signify a user movement detected. The Run() method of TestID is shown below:

public void run () { while (!_finished) { try { Thread.sleep(10000); id = Getid.getID(); setChanged(); notifyObservers(new UpdateHolder(USER, new Integer(id))); } catch(Exception e){} } }

5.2.3 Location-aware system can detect user movement

By realizing the ping program results, the user movement can be detected, they include:

"USER NOT DETECTED" -> validID, means a new user approaches to this machine.

ValidID-> "USER NOT DETACHED", means current user moves out of current location.

ValidID->another validID, means old user leaves while new user comes.

These user mobility information, such as listed above (“new user comes”, “current user moves”,

“old user goes, new user comes”) will be analyzed and responded to by the client manager.

5.3 Mobile ID client-side manager

Mobile ID client-side manager is responsible for responding to user movement event based on the

current state of the application. It communicates with the server-side manager and takes action

accordingly. The sections below discuss the implementation of the client-side manager, message

exchange and events followed.

5.3.1 Client-side manager implementation

Client-side manager is implemented by class Begin.java, which is an observer of a class instance

TestID (the ping program of location-aware system). Any event of the user movement will update

client-side manager, therefore, the client-side manager is informed of any user movement and it

manages subsequent events to respond accordingly. There are three main objects in Begin.java.

The first object is _ deamon, an instance of class TestID, which is the ping program to pinpoint the

user movement. The class testID implements observable interface, and _ deamon adds Begin.java

as observer. Class function startDeamon() in Begin.java creates and starts running a instance of

Test ID _deamon, for requiring user mobility information. _deamon is running at the background

as long as the mobile ID protocol is instantiated..

public void startDeamon () { _deamon=new Testid(); _deamon.addObserver(this); _deamon.start(); }

The second object is _controller, an instance of class Controller, which is a TCP connection to the

server for client-side manager to communicate with the server-side manager. It will be

instantiated when client-side manager needs to contact the server, _controller is responsible for

sending the messages client-side manager generates based on the user movement information to

the server, accepting server responses, and then closes.

Class function StartController() manages an TCP connection to the server.

public void startController () { _controller=new Controller ("server", port); _controller.addObserver(this); _controller.start(); _controller.sendType (ClIENT_MANAGER); _controller.sendUser (_user); }

The third main object is a reference to video client, which is responsible for sending session setup

request and displaying the requested video.

5.3.2 Message exchange and responding events in the client-side manager

User movement detected (validID -> USE_NOT_DETECTED):

1. If user has an active session, then client –side manager forces video client to send "MOVE"

message to server, and stops current session on the client side.

2. If user has no session, do nothing.

New user detected ("USER_NOT_DETECTED" -> valid ID):

Send “INQUIRY” message to the server-side manager on behalf of the new user, and wait for

response.

1. If the response is positive, client-side manager calls startplayer() to invoke video player to

resume that session.

2. If the response is negative, do nothing.

Old user goes, new user comes (validID -> another validID)

This message will be interpreted as the two described above concatenate together.

1. validID -> USER_NOT_DETECTED

2. USER_NOT_DETECTED -> validID

The manager will do the events sequentially corresponding to each message.

The method checkUpdate(int aUser) manages events responding to user movement

public void checkUpdate(int aUser) { ………… if(_user==-“USER_NOT_DETECTED){ if(_player.isRunning()) _player.move(); } else { if(_user!=oldUer) { if(_player.isRunning()) _player.move(); startController(); } } }

The method play (int serverResponse) manages events following server response to the new user

inquiry.

public void play(int serverResponse) { if(serverResponse==”NEGATIVE”) _controller.stop(); else if (serverResponse==”POSITIVE) { if(frame.getState()==Frame.ICONIFIED){ frame.setState(Frame.NORMAL); } _player.start(); _controller.stop(); } }

5.4 Mobility information database

Mobility information database is the information center to store the session states that have been

interrupted because of the user movement. It can be accessed only through server-side manager. A

database entry is entered by server-side manager when a session is interrupted because of the user

movement. A database entry is removed by server-side manager when server-side manager

restores an interrupted session by updating the client request for a session setup.

5.4.1 Implementation of mobility database

The database was implemented as two separate hashTables, _recordListAudio and

_recordListVideo, using user ID as key. The two hashTables are, one for video streaming session,

and the other for audio streaming session, because the underlying video client/server uses separate

streams for video and audio. Using separate hashTables for the database can also ease the

contention problem which may occur when many accessing request try to update the database.

The database entry includes the userID, and a reference to the server-side engine of an interrupted

session, which includes all the session state information, such as file name, current frame, etc.

When the server-side manager accesses database, it will use user ID as key to find the interrupted

session that user may have.

5.4.2 Access Mobility database

The Mobility database can only be accessed through the server-side manager. Mobility database

will be accessed under the following situations,

1. When server-side manager receives "MOVE" message for a session, session state will be stored

to the database using user ID as key.

2. When server-side manager receives video client request for a session setup, database will be

contacted to retrieve the previous session information the current user may have, and update the

request to resume the interrupted session. If a previous session entry is found for that user, after

the update, that entry in the database will be removed because that interrupted session has now

been resumed.

3. When server manager receives inquire on behalf of a new user, it will consult the database,

using user ID as key.

5.5 Mobile ID Server-side manager:

New instance of Mobile ID server-side manager is created when a client contacts server, and the

created instance is to handle and fulfill that client’s request. Mobile ID server-side manager is the

entry point for both initializing a multimedia streaming session and accessing the Mobility

database. It handles the client-side manager inquiry on behalf of a new user, also video client

request for initializing a session and moving a session. It fulfills the client request by working

closely with Mobility database, consulting and updating the database.

5.5.1 Main Tasks of Mobile ID server-side manager

The main tasks for server-side manager is: (a) Respond to the “MOVE” message by storing the

disrupted session state to the Mobility database, and stop the session. (b) Update session setup

request by consulting with the Mobility database to resume previous disrupted session the current

user may have and update the database when a disrupted session is resumed. Then send the

updated setup request to the video server. (c) Handle the client-side manager inquiry on behalf of

a new user by consulting with the Mobility database. If the user does not have an interrupted

session, it sends negative reply to the client-side manager; if the user has a video session, or an

audio session or both, it will send positive reply with the type of suspended session(s) back to the

client-side manager, the client-side manager then can invoke the right service to resume those

disrupted sessions.

5.5.2 Implementation of Mobile ID server-side manager

Server-side manager is implemented as part of class ServerMediaManager.java. It has an instance

of class Controller, _controller, which is a TCP connection to communicate with the client,

reference to the Mobility database, and access to the video server.

For responding to “MOVE”, the task (a), method Move (int atFrame) is implemented. The method

stops the current session, sets the frame number of the session to atFrame which is sent by the

client. atFrame is the frame number that client stops displaying because of the user movement. So

theoretically no frame will be lost when the session is resumed. Method move then calls another

method modifyList() to store the current session state to the Mobility database.

private void move(int atFrame) { _frameNum=atFrame; modifyList(); try { wait(); } catch (InterruptedException e) { System.err.println("Exception: " + e.toString()); } }

private void modifyList() { if (_mediaType == 2) { _recordListVideo.put(new Integer(_user), this); } else if (_mediaType == 1) { _recordListAudio.put(new Integer(_user), this); } else { System.out.println("bad file type: "); } }

For updating session setup request, the task (b), method setupUpdate(int aUser) is implemented.

When the session setup request is received, method setupUpdate will update the request by

checking with the Mobility database. If it is video request, it will check with videoList, if it is

audio request, it will check with audioList. If there is an entry for that user in the database, it will

call another method reDirect to update the setup request by restoring old session state. Then that

database entry will be removed. When this updated request is fulfilled by video server, the old

streaming session of that user is thus resumed to the location that user is currently at.

private void setupUpdate(int user) { …… if (_mediaType==2) { val = _recordListVideo.get(new Integer(user)); if (!(val == null)) reDirect((ServerMediaManager)val); _recordListVideo.remove(new Integer(user));

} else if (_mediaType==1) { val = _recordListAudio.get(new Integer(user)); if (!(val == null)) reDirect((ServerMediaManager)val); _recordListAudio.remove(new Integer(user)); } …… }

private void reDirect(ServerMediaManager old) { _mediaFile=old._mediaFile; _frameNum=old._frameNum; }

For responding to inquiry on behalf of the new user, the task (c), method newUserInquiry(int user)

is implemented. When the inquiry of a new user is received, the method will consult the Mobility

database for this user, if he/she has no entry in the database, it will send “NEGATIVE” back to the

client, if he/she has audio session, or video session or both, send session type (VIDEO, AUDIO or

VIDEO_AUDIO) back to the client. The client-side manager can then invoke the appropriate

service to resume the previous session. [Note: Currently, client –side manager regards all the

session types returned by the server as “POSITIVE”. It means there are sessions being interrupted

for this user, and it will assume both video and audio sessions exist for this user if “POSITIVE” is

returned for the inquiry.]

private void newUserInquiry(int user) { …… valA = _recordListVideo.get(new Integer(user)); valB = _recordListAudio.get(new Integer(user));

if(valA==null && valB != null) _controller.sendCont (VIDEO); else if (valA !=null && valB = null) _controller.sendCont (AUDIO); else if (valA != null && valB != null) _controller.sendCont (VIDEO_AUDIO); else _controller.sendCont (NEGATIVE);

…… }

5.6 Video Client and Server

The video client/server pair is implemented using Media Streaming Protocol (MSP), which was

developed at the University of Illinois [17]. The MSP is designed to adapt to congestion when it

occurs within the network. Techniques to detect network congestion on the transmission path were

implemented, and by dropping and adding frames MSP can dynamically adapt to the available

network resources. The client and server are both written in Java programming language, while

MPEG software decoding engine is written in C programming language.

.

Chapter 6

Experiments and results

This chapter presents the experiments I conducted and the results of the performance analysis of

the mobile ID system. After introducing my experiment environment (6.1), I present the metrics

of the measurements I conducted (6.2), scenarios results of the experiments (6.3), Finally I sum up

my experiments and results (6.4).

6.1 Testing environment

Multimedia workstations in our lab are used to conduct the experiments. The workstations are

connected to the Local Area Network via 100 Mbps Fast Ethernet network adaptors. One machine

serves as server and two other machines serve as clients (client1 and client2). Server and client1

are in the same room, while client2 is in another room across the hall. AIR ID system is installed

in both Client 1 and client 2, each client has a base attached to serial port COM1. The machine

specifications for the workstations used in the experiments are given in Table 1, Table 2, Table 3.

Table 1: Server Specifications

Machine Name Munich.cs.uiuc.eduType PC WorkstationOperating System Microsoft Windows NT 4.0 ProfessionalRAM 128 MBCPU Type Intel Pentium 3CPU Clock Rate 600 MHz

Table 2: Client 1 Specifications

Machine Name Rome.cs.uiuc.eduType PC WorkstationOperating System Microsoft Windows NT 4.0 ProfessionalRAM 256 MBCPU Type Intel Pentium 3CPU Clock Rate 733 MHz

Table 3: Client 2 Specifications

Machine Name Moscow.cs.uiuc.eduType PC WorkstationOperating System Microsoft Windows NT 4.0 ProfessionalRAM 160 MBCPU Type Dual Pentium ProCPU Clock Rate 200 MHz

6.2 Measurement Metrics

Since the purpose of the system is to provide seamlessly streaming handoff from client to client

without user intervention, during the handoff process, time loss is a major concern. I conducted

experiments to test the time loss during the handoff process. Specifically, time difference between

the time point that a user is detected by the location-aware system and the time point that the

interrupted session is resumed. The event sequences including location-aware system locates the

new user, and client-side manager sends inquiry to server, sever-side manager handles the inquiry

by consulting the mobility database, and return the result to the client. If reply is “POSITIVE”,

client-side manager will invoke the video client to retrieve disrupted session.

AIR ID security badge system can perform automatic remote-logon, time it takes will influence

the time loss during the handoff, and so I included AIR ID system automatic logon response time

as one measurement.

The frame loss is also a major concern, but I didn’t do measurements for frame loss in the

experiments because the actual frame loss during the handoff is influenced greatly by the

implementation of the underlying video server if the video server uses lossy technique in response

to the network congestion, as MSP does. So the actual measurements will not reflect the frame

loss caused by the Mobile ID protocol, I will discuss frame loss issue in 6.4.

6.3 Test scenarios and results

I did the experiments under the following scenarios: User approaches two client machines and test

automatic logon process response time (6.3.1). Real world handoff experiments test protocol

correctness under various circumstances (6.3.2). Time loss during the handoff process when user

approaches a machine without logon process (6.3.3) or user logons to a machine using AIR ID

security badge (6.3.4).

6.3.1 Test AIR ID system automatic logon response time

The purpose of this experiment was to measure the AIR ID system automatic logon response time,

from user starting the logon process to user having full control of the system, time for AIR ID

authentication. Same badge was used to approach both client machines. In this experiment the

response time is measured between logon window, showing information exchange between the

badge and the base starts, and user to have full control of the system. Timer is used for the

measurements.

Figure 7 and Figure 8 show the results of AIR ID logon response time for client1 and client2

respectively. 20 testruns were conducted on each machine. The average logon response time for

the client 1, is 1.59 seconds, and 3.4 seconds for client 2. Results show that client 1, the faster

machine performs almost half the time better than client 2, the slower machine. However, it

should be taken into account that faster machine will load startup process quicker when logon than

slower machine, so the time for AIR ID authentication may not differ that much between the two

machines.

Figure 7: AIR ID logon response time for client1

Test-run=20Mean=1.59sSD=0.32sRange=1.3s – 2.5s

Figure 8: AIR ID logon response time for client 2

6.3.2 Real world handoff experiment

The purpose of these experiments is to test my protocol in real world. The two clients are in

different rooms. I start a movie in one client machine and then moved to another room to resume

the session on the other client machine, and move back to the original client machine, where the

session resumes again. I also test scenario where user starts a movie session, then moves out of the

room, then comes back to the same client. In all the cases, the protocol works correctly.


6.3.3 Time loss during handoff when user approaches a machine without logon process.

I did this experiment by starting a session on one client, and moved to another client in the other

room. In this scenario, the ping program detects the new user’s presence, and trigger the handoff

process. The time is measured between the ping program’s detection of new activeID and the first

frame’s display on the video player.

Figure 9 shows the experiment results on client 1, Figure 10 shows the experiment results on

client2. 20 testruns were run on each machine. The average time loss on client1 is 6.49 seconds,

on client 2 the average time loss is 7.61 seconds. Results show the average time loss during

handoff process are not hugely different between the fast and slow machines. This result is

expected, the events during this process mainly involves the client - server communication, and

server handles the inquiry and resume the disrupted session, because both clients use the same

server, and have the same type of communication link, so the speed of client machine makes only

a little difference in this scenario.

Figure 9: Time loss during handoff on client 1 without logon process.

Figure 10: Time loss during handoff on client 2 without logon process



6.3.4 Time loss during handoff when user logons a machine using AIR ID system.

I did this experiment by starting a session on one client, and moved to another client in the other

room. In this scenario, the AIR ID badge system logon process detects the new user’s presence,

and launches the Mobile ID protocol client, and triggers the handoff process. The time loss is

measured between the logon window showing and the first frame’s displaying on the video player.

Figure 11 shows the experiment results on client 1, Figure 12 shows the experiment results on

client 2. 20 testruns run on each machine. The average time loss on client 1 is 9.44 seconds, on

client 2 it is 15.62 seconds. Results show that the difference of average time loss for the two

clients is significant. This is also expected, because after the user logon, the Mobile ID protocol

client needs to be loaded. The machine speed makes huge difference when Mobile ID client is

loaded, so faster machine performes about 40% better than the slow machine in my

configurations.

Figure 11: Time loss during handoff on client 1 with user logon process

Figure 12: Time loss during handoff on client 2 with user logon process



6.4 Performance issues of Mobile ID protocol

The user was able to be detected by AIR ID system either through logon process or through ping

program. 1-2 seconds for the logon process on faster machine client1, and 3-5 seconds for slower

machine client2. For the restoring suspended session (handoff), when using ping program to detect

new user, it took about 6 – 8 second on both client machines, demonstrating that client machine

speed made little difference in this scenario because most events in this case were related to the

server and communication links. When using logon process to detect a new user, it took about 15-

17 seconds on the slower machine client2, but only 9-10 on the faster machine client1,

demonstrating that machine speed made difference when loading client side engine of the

protocol. On average, time loss for handoff is in the acceptable range, faster machine will provide

better performance when using logon process to detect user, while machine speed is not important

when using ping program to detect user. As the current protocol is designed, the frame loss during

the handoff is 5 in the worst case.

Frame loss is also a major concern during the handoff process. Mobile ID protocol handle

“MOVE” message by client sending the frame number, at which the video player stops, to the

server. Server-side manager stores that information to the Mobility database. So when the session

is resumed, it starts exactly at the frame number that being stopped previously. Theoretically,

there should be no frame loss during the handoff. But because of the way the video file is encodes,

the stopping frame could be any type of frames in the video file. Because only I frame contains the

full image information, if stopping frame is B or P frame, then when the session is resumed, the

first few frames will be scramble images, until the next I frame is shown. For example, in case the

video encoding pattern is (IBBPBBIBBPBB…), which my test video files is encoded, the worst-

case frame loss caused by session handoff will be 5. I can improve my protocol by keeping a

frame window on the client side, and instead of sending the actual stopping frame number when

“MOVE” is triggered, I send the last I frame before the stopping frame. In that case, no frame will

be lost during the handoff.

Chapter 7

Future work

Current implementation of Mobile ID protocol is tightly coupled to the video client/server

application. Future work could involve separating the protocol implementation as a separate

service application, so other applications can request the service with little effort to add the user

mobility support to their own.

Currently the location-aware system, integrated AIR ID system, supports only one active user at

one machine. I can change the location-aware related software, so all the active user IDs within

the range will be detected. A session then can be tied to a combination of users, and only when

that combination reappears, will session resume. Thus different combination of users will trigger

different sessions.

Chapter 8

Conclusion

The mobility support for multimedia streaming applications such as video on demand is of great

interest. Streaming following the user gives the video on demand a new meaning. In this thesis,

Mobile ID protocol - badge-activated application level handoff of a streaming multimedia was

designed and implemented. AIR ID security badge system is integrated as location-aware system

for the protocol, and streaming session handoff routine is developed. The protocol adds the user

mobility support to the video on demand applications.

Unlike some of other projects targeting the personal mobility issue that implement mobility

support service as system software, mobile ID protocol is designed and implemented at

application level. Mobile ID protocol introduces less intrusion and less interference with other

applications when compared to projects that tackle this issue at the system software level. Mobile

ID protocol is a totally new design based on our existing hardware and software. Also, unlike

similar systems which is designed to keep user-location information of all the users on the system

in a central database, Mobile ID protocol follows the path that each user only register to the

applications that he/she currently using, and application server holds the user-location information

only for the users that currently register to this application service. This is a more distributed

approach to hold the user location information of the system, so it may have better scalability than

the approach that has centralized control for all the user-location information. On the other hand,

it may suffer having to register multiple times (register to every active applications) for one

movement.

The implementation of the protocol is mostly written in Java programming language, which has

better cross-platform support. The exception is some of the code related to the integration of the

AIR ID system which is written in C++, because AIR ID API is written in C++. Also because the

AIR ID system currently only supports PC platform, Mobile ID protocol cross-platform support is

limited. The mobile ID clients have to be PCs, while Mobile ID server can be either a PC or a Sun

Solaris machine.

The Mobile ID protocol, a new design and implementation based on our existing hardware and

software, adds the mobility support to the multimedia streaming applications, such as video on

demand.

References

[1] D. Ferrari and D. C. Verma, “A scheme for real-time channel establishment in

wide-area networks “, in IEEE Journal on Selected Areas in Communications, June

1998, pp.368-379.

[2] A. Raha, S. Kamat, and W. Zhao, “Guaranteeing end-to-end deadlines in ATM

networks”, in Proc. of IEEE ICDCS, June 1995 , pp. 60-68.

[3] A. Raha, S. Kamat, and W. Zhao, “Admission Control for Hard Real-Time

Connections in ATM LANs”, in Proceedings of IEEE INFOCOM’96, March 1996,

pp180-188.

[4] R. H. Campbell, S-M. Tan, Z. Chen and D. Xie, “ Method of and System for

Transmitting and/or Retrieving Real-time Video and Audio Information over

Performance-Limited Transmission Systems”, Patent PCT/US96/19226.

[5] C. E. Perkins, “ Mobile Networking Through Mobile IP” in IEEE Internet

Computing, Jan. – Feb. 1998, pp. 58-69.

[6] T. Richardson, F. Bennett, G. Mapp and A. Hopper, “Teleporting in an X Window

System Evironment”, in IEEE Personal Communications, Aug. 1994, pp.6-12.

[7] M. Wachowicz and S. G. Hild, “Combining location and data management in an

environment for total mobility”, in Proceedings of the International Workshop on

Information Visualization and Mobile computing, Rostock, Germany, Feb. 1999.

[8] K. Arnold and J. Gosling, The Java Programming Language, Addison-Wesley,

1996.

[9] D. DeRoure, W. Hall, H. Davis and J. Dale, “ Agent for Distributed multimedia

Information Management”, in Presented at Practical Applications of Intelligent Agents

and Multi-Agents (PAAM ’96), London, UK, 1996, pp. 91-102.

[10] D. Rus, R. Gray and D. Kotz, “ Autonomous and Adaptive Agents that Gather

Information ”, in Proceedings of AAAI ’96 workshop on Intelligent Adaptive Agents,

1996. pp.107-116

[11] K. Bharat and L. Cardelli, “ Migratory Applications”, in Proceedings of ACM

Symposium on User Interface and Technology, Pittsburgh, USA, Nov. 1996, pp. 133-

142.

[12] J. Bates, D. Halls and J. Bacon, “ A Framework to Support Mobile Users of

Multimedia Applications” in Mobile Networks and Applications, Jan. 1996, pp409-

419.

[13] J. Bates, D. Halls and J. Bacon, “ Middleware Support for Mobile Multimedia

Applications”, in ICL Systems Journal, Nov.1998.

[14] H. Lieberman, “ Letizia: An Agent that Assists Web Browsing”, in Proceedings of

International Joint Conference on Artificial Intelligence, ACM SIGMOD’95, New

York, Aug. 1995, pp. 924-929.

[15] A. Stefano and C. Santoro, “ NetChaser: Agent Support for Personal Mobility”, in

IEEE Internet Computing, Mar. – Apr. 2000, pp. 74-79.

[16] M. JWooldridge, Multiagent Systems, G. Weiss, ed., MIT Press, Cambridge, Mass.,

Apr. 1999.

[17] C. Hess, “ Media Streaming Protocol: An Adaptive Protocol for the Delivery of Audio

and Video over the Internet”, Master-Thesis, University of Illinois at Urbana-

Champaign, 1998.

Chapter 1

Documents