Chapter 1
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
493
On Slideshare
493
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ©Copyright by Bo Zou 2000
  • 2. 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 requirements for the degree of Master of Science in Computer Science in the Graduate College of the University of Illinois at Urbana-Champaign, 2000 Urbana, Illinois
  • 3. To my family
  • 4. 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.
  • 5. 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.
  • 6. Table of Contents Chapter 1 .....................................................................................................................................viii Introduction..................................................................................................................................viii Chapter 2..........................................................................................................................................x Related Work on User Mobility:......................................................................................................x Chapter 3.......................................................................................................................................xiv Mobility issues related to video on demand.................................................................................xiv Chapter 4.......................................................................................................................................xvi System design...............................................................................................................................xvi 4.1 High-level Architecture.......................................................................................................xvi 4.2 System components:...........................................................................................................xvii 4.2.1 Location-aware system component:...........................................................................xviii 4.2.2 Mobile ID client-side manager:..................................................................................xviii 4.2.3 Mobility database:..........................................................................................................xx 4.2.4 Mobile ID server-side manager:.....................................................................................xx 4.2.5 Video client/server.........................................................................................................xx 4.3 Event flow:..........................................................................................................................xxi 4.3.1 Current user starts a streaming session: .......................................................................xxi Figure 3. Event flow chart when user starts a multimedia session.............................................xxii 4.3.2 Current user moves:.....................................................................................................xxii Figure 4. Event flow chart when current user moves.................................................................xxiii 4.3.3 New user is detected:..................................................................................................xxiii Chapter 5.....................................................................................................................................xxiv Implementation:..........................................................................................................................xxiv 5.1 Development environment.................................................................................................xxv 5.2 Location-aware System---AIR ID System.........................................................................xxv 5.2.1 Air ID system .............................................................................................................xxvi 5.2.2 Implementation of integrating AIR ID system as location-aware system.................xxvii 5.2.3 Location-aware system can detect user movement...................................................xxviii 5.3 Mobile ID client-side manager........................................................................................xxviii 5.3.1 Client-side manager implementation..........................................................................xxix 5.3.2 Message exchange and responding events in the client-side manager........................xxx 5.4 Mobility information database..........................................................................................xxxi 5.4.1 Implementation of mobility database.........................................................................xxxii 5.4.2 Access Mobility database .........................................................................................xxxii 5.5 Mobile ID Server-side manager:.....................................................................................xxxiii 5.5.1 Main Tasks of Mobile ID server-side manager........................................................xxxiii 5.5.2 Implementation of Mobile ID server-side manager..................................................xxxiv 5.6 Video Client and Server..................................................................................................xxxvi Chapter 6..................................................................................................................................xxxvii Experiments and results...........................................................................................................xxxvii 6.1 Testing environment.......................................................................................................xxxvii 6.2 Measurement Metrics....................................................................................................xxxviii 6.3 Test scenarios and results................................................................................................xxxix 6.3.1 Test AIR ID system automatic logon response time.................................................xxxix Mean=1.59s.................................................................................................................................xl
  • 7. 6.3.2 Real world handoff experiment......................................................................................xli 6.3.3 Time loss during handoff when user approaches a machine without logon process.....xli 6.3.4 Time loss during handoff when user logons a machine using AIR ID system............xliii SD=0.49s..................................................................................................................................xliv 6.4 Performance issues of Mobile ID protocol .........................................................................xlv Chapter 7........................................................................................................................................47 Future work....................................................................................................................................47 Chapter 8........................................................................................................................................48 Conclusion.....................................................................................................................................48 References......................................................................................................................................50
  • 8. List of Figures Chapter 1 .....................................................................................................................................viii Introduction..................................................................................................................................viii Chapter 2..........................................................................................................................................x Related Work on User Mobility:......................................................................................................x Chapter 3.......................................................................................................................................xiv Mobility issues related to video on demand.................................................................................xiv Chapter 4.......................................................................................................................................xvi System design...............................................................................................................................xvi 4.1 High-level Architecture.......................................................................................................xvi 4.2 System components:...........................................................................................................xvii 4.2.1 Location-aware system component:...........................................................................xviii 4.2.2 Mobile ID client-side manager:..................................................................................xviii 4.2.3 Mobility database:..........................................................................................................xx 4.2.4 Mobile ID server-side manager:.....................................................................................xx 4.2.5 Video client/server.........................................................................................................xx 4.3 Event flow:..........................................................................................................................xxi 4.3.1 Current user starts a streaming session: .......................................................................xxi Figure 3. Event flow chart when user starts a multimedia session.............................................xxii 4.3.2 Current user moves:.....................................................................................................xxii Figure 4. Event flow chart when current user moves.................................................................xxiii 4.3.3 New user is detected:..................................................................................................xxiii Chapter 5.....................................................................................................................................xxiv Implementation:..........................................................................................................................xxiv 5.1 Development environment.................................................................................................xxv 5.2 Location-aware System---AIR ID System.........................................................................xxv 5.2.1 Air ID system .............................................................................................................xxvi 5.2.2 Implementation of integrating AIR ID system as location-aware system.................xxvii 5.2.3 Location-aware system can detect user movement...................................................xxviii 5.3 Mobile ID client-side manager........................................................................................xxviii 5.3.1 Client-side manager implementation..........................................................................xxix 5.3.2 Message exchange and responding events in the client-side manager........................xxx 5.4 Mobility information database..........................................................................................xxxi 5.4.1 Implementation of mobility database.........................................................................xxxii 5.4.2 Access Mobility database .........................................................................................xxxii 5.5 Mobile ID Server-side manager:.....................................................................................xxxiii 5.5.1 Main Tasks of Mobile ID server-side manager........................................................xxxiii 5.5.2 Implementation of Mobile ID server-side manager..................................................xxxiv 5.6 Video Client and Server..................................................................................................xxxvi Chapter 6..................................................................................................................................xxxvii Experiments and results...........................................................................................................xxxvii 6.1 Testing environment.......................................................................................................xxxvii 6.2 Measurement Metrics....................................................................................................xxxviii 6.3 Test scenarios and results................................................................................................xxxix 6.3.1 Test AIR ID system automatic logon response time.................................................xxxix
  • 9. Mean=1.59s.................................................................................................................................xl 6.3.2 Real world handoff experiment......................................................................................xli 6.3.3 Time loss during handoff when user approaches a machine without logon process.....xli 6.3.4 Time loss during handoff when user logons a machine using AIR ID system............xliii SD=0.49s..................................................................................................................................xliv 6.4 Performance issues of Mobile ID protocol .........................................................................xlv Chapter 7........................................................................................................................................47 Future work....................................................................................................................................47 Chapter 8........................................................................................................................................48 Conclusion.....................................................................................................................................48 References......................................................................................................................................50 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
  • 10. 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.
  • 11. 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.
  • 12. 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
  • 13. 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.
  • 14. 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
  • 15. 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.
  • 16. 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. Session resume on a different machine Figure 1. Application-level handoff of Multimedia Streaming Session resume on Play a movie session Store the session info Session stop the same machine
  • 17. 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-
  • 18. 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 Database entry user video audio File name File name, Tom Frame number Frame number … … Mobility Client location Client Server Video server Info database Server file Media Video client aware system move” to manager“User manager Session setup request “User move” to Updated session “positive response ” to StopUser has /Move user”. session request start player an interrupted setup Stop player Media session state player ”new at frame Media streaming
  • 19. store Figure 2. Mobile ID Protocol for Multimedia streaming 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.
  • 20. 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.
  • 21. 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
  • 22. 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 Video system Manager Client Manager Database Server user moves Invoking “Move” move at frame store session Stop state
  • 23. 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 Video System Manager Manager Database Server New user new user inquiry consulting results response to inquiry
  • 24. Video Client Positive response session consulting setup results update session setup request updated setup request 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
  • 25. 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.
  • 26. 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.
  • 27. 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),
  • 28. 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.
  • 29. 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);
  • 30. _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.
  • 31. 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
  • 32. 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
  • 33. 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.
  • 34. 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: "); } }
  • 35. 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
  • 36. 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. .
  • 37. 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.edu Type PC Workstation Operating System Microsoft Windows NT 4.0 Professional RAM 128 MB CPU Type Intel Pentium 3 CPU Clock Rate 600 MHz Table 2: Client 1 Specifications
  • 38. Machine Name Rome.cs.uiuc.edu Type PC Workstation Operating System Microsoft Windows NT 4.0 Professional RAM 256 MB CPU Type Intel Pentium 3 CPU Clock Rate 733 MHz Table 3: Client 2 Specifications Machine Name Moscow.cs.uiuc.edu Type PC Workstation Operating System Microsoft Windows NT 4.0 Professional RAM 160 MB CPU Type Dual Pentium Pro CPU 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.
  • 39. 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.
  • 40. 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. Test-run=20 10 Mean=1.59s 9 SD=0.32s Range=1.3s – 2.5s 8 7 6 Second 5 4 3 2 1 0 0 5 10 15 20 Test-run Figure 7: AIR ID logon response time for client1
  • 41. Test-run=20 Mean=3.41s 10 SD=0.48s 9 Range=2.7s – 4.5s 8 7 6 Second 5 4 3 2 1 0 0 5 10 15 20 Test-run 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.
  • 42. 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. Test-run=20 10 Mean=6.45s SD=0.38s 9 Range=5.7s – 7.3s 8 7 6 Second 5 4 3 2 1 0 0 5 10 15 20 Test-run Figure 9: Time loss during handoff on client 1 without logon process.
  • 43. 10 9 8 7 6 Second 5 4 Test-run=20 3 Mean=7.61s 2 SD=0.54s Range=6.9s – 8.8s 1 0 0 5 10 15 20 Test-run 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
  • 44. loaded, so faster machine performes about 40% better than the slow machine in my configurations. Test-run=20 Mean=9.44s 20 SD=0.49s 19 18 Range=8.5s – 10.6s 17 16 15 14 13 12 11 Second 10 9 8 7 6 5 4 3 2 1 0 0 5 10 15 20 Test-run Figure 11: Time loss during handoff on client 1 with user logon process
  • 45. 20 19 18 17 16 15 14 13 12 11 Second 10 9 8 Test-run=20 7 6 Mean=15.62s 5 SD=0.61s 4 Range=15.1s – 17.4s 3 2 1 0 0 5 10 15 20 Test-run 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
  • 46. 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.
  • 47. 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.
  • 48. 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.
  • 49. 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.
  • 50. 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.
  • 51. [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.
  • 52. 45 Number of Segments 40 35 30 25 20 15 10 5 0 0 2 4 6 8 10 12 Time(secs) Figure 5.6.2 Scenario 3 TCP Vegas Receiver