Seamless User-Level Handoff in Ubiquitous Multimedia Service Delivery

Multimedia Tools and Applications, 22, 137–170, 2004 c 2004 Kluwer Academic Publishers. Manufactured in The Netherlands.

Seamless User-Level Handoff in Ubiquitous Multimedia Service Delivery∗ YI CUI [email protected] KLARA NAHRSTEDT [email protected] Department of Computer Science, University of Illinois at Urbana Champaign, Urbana, IL, USA DONGYAN XU Department of Computer Sciences, Purdue University, West Lafayette, IN, USA

[email protected]

Abstract. Advancing mobile computing technologies are enabling “ubiquitous personal computing environment”. In this paper, we focus on an important problem in such environment: user mobility. In the case of user mobility, a user is free to access his/her personalized service at anytime, anywhere, through any possible mobile/fixed devices. Providing mobility support in this scenario poses a series of challenges. The most essential problem is to preserve the user’s access to the same service despite changes of the accessing host or service provider. Existing system-level mobility solutions are insufficient to address this issue since it is not aware of the application semantics. On the other hand, making each application to be mobility-aware will greatly increase the development overhead. We argue that the middleware layer is the best place to address this problem. On one hand, it is aware of application semantics. On the other hand, by building application-neutral mobility functions in the middleware layer, we eliminate the need to make each application mobility-aware. In this paper, we design a middleware framework to support user mobility in the ubiquitous computing environment. Its major mobility functions include user-level handoff management and service instantiation across heterogeneous computing platforms. We validate the major mobility functions using our prototype middleware system, and test them on two multimedia applications (Mobile Video Player and Mobile Audio Player). To maximally approximate the real-world user-mobility scenario, we have conducted experiments on a variety of computing platforms and communication paradigms, ranging from T1-connected high-end PC to handheld devices with wireless networks. The results show that our middleware framework is able to provide efficient user mobility support in the heterogeneous computing environment. Keywords: user mobility, middleware, ubiquitous computing, multimeida service

1.

Introduction

Mobile Computing has been an active research area over the years. It has gained more intensive consideration since the recent proliferation of network-enabled portable devices and inexpensive wireless communication. All these advancing technologies are enabling “ubiquitous personal computing environment”. In such an environment, a user can access his/her personalized services at anytime, anywhere, through any possible mobile/fixed terminals in ∗ This work was supported by the National Science Foundation under contract number 9870736, 9970139, EIA 9972884EQ, and NASA grant under contract number NASA NAG 2-1406. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the view of the National Science Foundation, NASA or US government.

138

CUI, NAHRSTEDT AND XU

Home

Figure 1.

Office

Sample user mobility scenario.

a secure way. A wealth of research work has been conducted to approach this goal [2, 3, 13, 15, 18, 25, 27, 31]. Most of them focused on the host mobility problem. With host mobility, a user can access the same service while travelling. However, he/she is required to always carry the same mobile host. We argue that this is only a special case of user mobility. In the ubiquitous computing environment, user mobility not only includes host mobility, but also includes the case where a user is free to switch from one host to another. In a broader sense, a user is free to migrate his/her service environment. This means that the user, instead of host, is the real end receiver of any service. In this paper, we mainly consider the user mobility problem. In particular, we study it in the background of multimedia service delivery. We use a sample scenario to illustrate this problem. As shown in figure 1, a mobile user initially retrieved a Video-on-Demand (VoD) service on HDTV at home. At certain point of time, the user leaves to his/her working place. To continue the VoD service, the session migrates on his/her PDA, and the user receives the same service while travelling. Upon arrival to the working place, the same session is shifted from the PDA to the laptop in his/her office. This scenario reflects the goal of our study: to enable anytime, anywhere multimedia service access under heterogeneous computing environment. To achieve this scenario, we face two fundamental problems. The first one is to dynamically migrate the user’s session as the user moves, so that the service always follows him/her. We refer to this problem as user-level handoff. This is in contrast to the traditional host-level handoff scenario, where a mobile host switches from one network to another. The second problem is to track the user’s current location, so that the user is accessible by the mobility system and other users who wish to contact him/her. We refer to this problem as user location management. In this paper, we focus on the user-level handoff problem, assuming the existence of user location management mechanisms. We list the major challenges of the user-level handoff problem as follows. 1. How to seamlessly migrate the user’s video session, i.e., how to capture, store and forward the execution state of the video session, so that the service continuation is preserved? 2. How to migrate a session to a new system environment totally different from the previous one(host platform, network connection, or even the user application itself)? More challengingly, how to correctly reflect the user’s QoS preferences1 under such condition? 3. Upon addressing all the above problems, how to optimize the system performance, i.e., accelerate session creation and deployment, minimize handoff delay, etc.?

UBIQUITOUS MULTIMEDIA SERVICE DELIVERY

139

These problems demand mobility support from both system (OS, network) level [13, 27] and application level [2]. However, supporting user mobility at application layer is not a viable solution. Making each application to be mobility-aware will greatly complicate its development. Moreover, legacy applications are not considered. On the other hand, systemlevel solutions are insufficient since they are not aware of application semantics. This is quite essential to address the problem of user-level handoff across heterogeneous platforms (recall the second problem listed above). We believe that the middleware solution is the best to address these problems due to its following advantages. • The middleware system offers enough flexibility to be easily deployed on various computing platforms, even on the handheld device. It can also easily cooperate with existing system solutions. • By keeping the general mobility functionalities (user location management, personal information management, state transfer management, etc.) that are application-neutral in the middleware layer, applications are not needed to be mobility-aware. Another advantage is that the middleware framework is ready to accommodate a rich yet expanding set of applications. • Without loss of generality, the middleware layer still allows its overlying applications to inject any application-specific policies. In this paper, we design a middleware framework to support user mobility in the ubiquitous computing environment. Its major mobility functions include user-level handoff management and service instantiation across heterogeneous computing platforms. Furthermore, we make several enhancements to improve system performance, such as accelerating user-level handoff, therefore saving state information storage/transportation overhead. Our experimental middleware system validates our framework, as we tested it using two multimedia applications (Mobile Video Player and Mobile Audio Player). To maximally approximate the real-world user-mobility scenario, we have conducted experiments on a variety of computing platforms and communication paradigms, ranging from T1-connected high-end PC to handheld devices on wireless networks. The results show that our solution is able to provide efficient user mobility support in the heterogeneous computing environment. The rest of the paper is organized as follows. Section 2 describes the system overview of our middleware framework. Sections 3 and 4 present a series of user-level handoff schemes. Section 5 introduces our prototype system and presents the system performance results. Section 6 discusses the related work. Finally, we draw conclusion in Section 7. 2.

System overview

We show the overall picture of user mobility in multimedia service delivery in figure 2. We envision the computing environment to be highly heterogeneous and integrated into users’ living and working space. We divide the computing space into User Space and Service Space. We denote client host as any computing device in the user space that the user is free to work on. Based on the client host, a user can request multimedia service from any service provider in the service space. We further denote a user’s service environment to

140


User Space Service Space

Internet

User Movement Service Path

Figure 2.

Overall picture.

include his/her current client host, service providers and the services he/she is accessing. As shown in the picture, when user moves in the user space, his/her client host and service providers keep changing. The corresponding service paths are also updated. In this case, although the physical service environment is changed, its logical view remains unchanged from the user’s perspective. Therefore, the goal of our framework is to keep the user’s logical service environment despite changes in the physical environment. The key challenges of the user mobility problem are (1) how to preserve the state information of the service environment, and (2) how to instantiate the same service across heterogeneous platforms. With respect to the first challenge, we regard the state information as a “snapshot” of the service environment. It mainly includes the execution state of each running application, as well as all contextual information that helps to reinstantiate the same service environment. For example, in the VoD service, the state information includes the title of the video file, its data format, the current frame/sequence number of the video playback, etc. With respect to the second challenge, it involves choosing different application services, reforming service path, and adapting service content if necessary. These two challenges will be discussed in Sections 2.2 and 2.3, respectively. The key difference between the user space and service space is that the user space is mobility-aware, while the service space is not. Obviously, since user mobility occurs in the user space, each client host must have mobility functionalities such as state information management. However, a service provider can view a migrated service session as a newly established one. In other words, the service provider is stateless. Therefore, our mobility system only needs to be deployed in the user space. Note that the service space does not include special services which facilitate the user mobility support, such as user location detection, but the user space does. The mobility-supporting services are deployed in the user space, in conjunction with our middleware system, as we will discuss in Section 2.1.


141

In the remainder of this section, we first state key assumptions of our framework. Then we introduce the state information management operations. Finally, we discuss the problem of service instantiation across heterogeneous platforms, and present out solution. 2.1.

Assumptions

First, we assume the existence of User Location Detection System. The system keeps track of user’s current location, and maintains information about each user’s ID, profile, etc. Such a system is usually equipped with advanced detection techniques to recognize the user automatically, such as Active Badges [32]. The system also opens event channel, where the client host can register to listen to certain events about user movement, arrival or exit. Our assumption is validated by the emergence of “smart spaces” [9, 14], such as Smart Office [4], Smart Home [17]. User location detection is one of the basic services these smart spaces provide. In fact, our framework is designed toward this type of computing space, where a user has abundant computing resources and a variety of access devices to receive the multimedia services at anytime, anywhere. User location detection techniques have been well studied in [20, 33, 35]. Second, we assume that a service discovery service is available. As shown in figure 2, during the service environment migration, the service provider can be changed to a new one, as long as it provides the same service. This is quite essential since if a user moves to a new location, the old service provider he/she used to contact may not be accessible anymore. Service discovery can also help a mobile user to locate the service provider with the best quality of service. Existing works on service discovery include [11, 38]. 2.2.

Middleware architecture

As stated earlier in this section, the central issue of service environment migration is the state information management and maintenance. The basic tasks are as follows. On detecting the “user leave” event, the user’s current client host captures the state information of the running application and forwards it to the new client host the user will work on. Based on the received state information, the new client host starts the same application and restores the state information to it. As we can see, it involves interactions between different client hosts, client host and user location service, and client host and service discovery service if a new service provider is needed. If we let application itself to handle these tasks, it will greatly complicate its development overhead. Our solution is to insert a middleware component, called Handoff Manager, as shown in figure 3. The handoff manager achieves the above state information management tasks. We show the basic handoff control procedure of the handoff manager in figure 4. There are two types of handoff scenarios: Proactive Handoff and Reactive Handoff. In proactive handoff, the state information is sent directly between client hosts. This happens in the case that the user mobility sequence is known a priori. An example is a presenter driving a video session from his/her laptop to the display wall during a presentation. In reactive handoff, the user movement is unpredictable. We note that this is the default case. To address the reactive handoff problem, we introduce a new entity, called User Metadata Server, which acts as the

142


Client Host Application User Location Service

API Get State Information

Put State Information

Client Host Handoff Manager

Service Discovery Service

Figure 3.

Handoff Manager

Middleware Layer OS & Network

Middleware architecture on the client host.

Client Host 1

Client Host 2

Client Host 1

Client Host 2

Application

Application

Application

Application

(1) Get State Information

(3) Put State Information

Handoff Manager

(2) State Information Update

(2) Get State Information

Handoff Manager

(3) State Information Update

Handoff Manager

User Metadata Server

(5) State Information Retrieval

(1) User Leave

Handoff Manager (4) User Arrival

(a) Proactive Handoff Case Figure 4.

(6) Put State Information

(b) Reactive Handoff Case

Handoff control.

“anchor point” between the old and new client hosts. In general, the user metadata server maintains a record for every user. The state information is part of a user metadata record. We show the state information of a VoD service in Table 1. It mainly includes the service name, its XML description and the service data. It also includes the state information left off during the handoff, e.g., the paused scene/frame sequence number. More details about the user metadata server will be introduced in Section 3.

Table 1.

State information representation of the VoD service. Service name

Video-on-demand

Service description

?/xml version = “1.0”? Video-on-demand protocol Media streaming protocol/protocol format MPEG-1, MPEG-2 /format /Video-on-demand

Service content

msp://cairo.cs.uiuc.edu:simpsons.mpg

Service state information Handoff granularity

Frame level

Offset value

Frame #241

...

...


143

Figures 3 and 4 show that, by concentrating mobility functions in the middleware layer, application is freed of the burden to be mobility-aware. Rather, it only exports a set of APIs to be driven by the middleware. Our implementation experiences show that this simple “wrap-up” method incurs little additional development overhead and applies to legacy applications. In fact, many application developers already provide such APIs, which we can leverage without further development [6]. On the other hand, different user location services and service discovery services can be easily integrated into our framework, since they only need to interact with the handoff manager instead of application itself. This feature greatly increases the application portability to other “smart space” environments with different user location service or service discovery service. 2.3.

Service instantiation across heterogeneous platforms

So far in this section, we have mainly presented the state information management problem and its solution. The next problem is how to reinstantiate the user’s service environment on the new client host. This is not as trivial as starting an application. For example, in figure 1, when the user tries to migrate the video session to the PDA, the following problems arise. First, the same VoD application on the former client host cannot be running on the PDA because their system platforms are different. Therefore, the PDA has to find a different application, which is able to access the same VoD service and be compatible with its platform. Second, the original high-quality video stream may not fit into the PDA’s small display and low-bandwidth wireless connection. Therefore, transcoding service is necessary to adapt the video content into low quality, low frame rate stream. Finally, even though the video quality degradation is unavoidable, the user may still like to maximally preserve certain QoS parameters, which he/she considers critical. For example, some users may prefer better image quality, while others may prefer smooth playback with higher frame rate. The first problem can be addressed as follows. Recall in Table 1, each application is accompanied with the XML description about its basic properties. This description is platformindependent. Thus, the PDA can use it to search for the appropriate application program. This task can be carried out with the aid of service discovery service. Furthermore, extensive research has been conducted for the dynamic program downloading and instantiation [11, 28]. The second problem refers to transcoding service lookup and reforming the service path. This problem can be also addressed by leveraging existing solutions on media gateway discovery [37] and service path setup [8, 36]. The third problem refers to adapting the service content according to the user’s QoS preferences. There are existing works on data adaptation [7, 16] for mobile computing. However, customizable content adaptation is still an open problem. In this paper, we address this problem by proposing a QoS mapping algorithm. The algorithm quantifies the user’s QoS preferences and map them into customized QoS parameter setting, which best reflects the user’s QoS preferences and maximally utilizes the available system resource. The algorithm is presented in detail in Section 4. To summarize, this section presents the overall architecture of our middleware framework. The main goal of the framework is to preserve the user’s service environment during

144


mobility. It targets on two essential problems: state information management and service environment instantiation across heterogeneous platforms. Our solutions to these problems are examined in greater details in Sections 3 and 4. 3.

User-level handoff scheme design

In this section, we explore in greater details the user-level handoff control problem. We start by introducing the basic handoff scheme, which has been briefly previewed in Section 2.2. We then present a series of enhanced handoff schemes to save the handoff delay and state information storage/transportation overhead. Note that we only consider the case of single application session, which we simply refer to as session in the remainder of this section. Multiple application session handoff problem can be addressed by repeating the single session handoff scheme in parallel. 3.1.

Basic scheme

We first analyze the basic scheme of session handoff control. The timeline is shown in figure 5. We subdivide the handoff procedure from Client Host 1 (CH1) to Client Host 2 (CH2) into Phase A, Phase B and Phase C. CH1 and CH2 receive data stream from the Content Server (CS), and interact with the User Metadata Server (MS) to request/update the session state information. We list the frequently used notations in Table 2. They will also be used in the remainder of this paper.

Client Host 1 (CH1)

Content Server User Metadata Server (CS) (MS) A1

User Leave

A2 A3 B1

Client Host 2 (CH2) Handoff Delay

B2 User Arrival B3 C1 C2

Figure 5.

Basic handoff timeline.

UBIQUITOUS MULTIMEDIA SERVICE DELIVERY Table 2.

145

Key notations in user-level handoff schemes. CH1

Client Host 1, the original client host the user leaves during handoff

CH2

Client Host 2, the new client host the user arrives at during handoff

CS

Content server

MS

User metadata server

Phase A

Session start and suspension at CH1

Phase B

Session state transfer from CH1 to CH2

Phase C

Session resumption at CH2

3.1.1. Handoff procedure. First in Phase A, the session is initiated by CH1 sending “Play” message to CS (Step A1). The data stream is then transferred to CH1 (Step A2). Upon detecting the user leaving, CH1 sends “Stop” message to CS to terminate the connection (Step A3) and enters Phase B. During Phase B, CH1 first contacts MS to update its current session state information (Step B1). This message is sent out right after Step A3. Upon finishing this step, CH1 is done with its part in the handoff control and ready to serve new mobile user. The next step in Phase B is carried out by CH2. Upon detection of user arrival, it contacts MS for corresponding session state information indexed by the user ID (Step B2). As reply, MS transfers the requested data to CH2 (Step B3). After receiving the needed state information, CH2 is ready to start the new session and enters Phase C. As the first step in Phase C, CH2 sends out connection request to CS to request the same stream (with an offset corresponding to the current breakpoint position) (Step C1). CS then creates a new session to CH2 (Step C2). To this end, the session is reestablished between CH2 and CS. Hence the handoff is accomplished. 3.1.2. Assumptions. The basic handoff scheme makes the following assumptions. First, step B1 happens before B2. It means that the update message from CH1 arrives at MS before the request message from CH2. Although remaining true in most occasions, these messages are not guaranteed to arrive in order. As a consequence of out-of-order message arrival, CH2 may get incorrect state information or not at all. To avoid the conflict, we use the Current Holder field in each user record to indicate the current client host serving the user. Initialized as null, this field is filled by CH1 of its own address when it first sends out the request message to MS upon user arrival. The field is nullified by MS after receiving the update message from CH1. Therefore, if the request from CH2 gets to MS before CH1 finishes updating the state information, it will be blocked since the Current Holder field still appears as CH1. Not until the field is nullified by CH1, the request is processed by MS and the field is renewed as CH2. This solution solves the out-of-order message conflict through sequentializing simultaneous operations on the same user record. It can also solve the request conflict problem when there are multiple client hosts competing to serve the same user.2 MS simply accepts the first arrived request message and fills its owner into the Current Holder field. Second, for the purpose of simple illustration, we assume that CH1 and CH2 contact the same CS. However, as presented in Section 2.1, CH2 can choose a new content server as long

146


Table 3.

Handoff delay parameters. tupdate

Time to send the session state information to the metatdata server

trequest

Time to send request to the metadata server

tretrieve

Time to retrieve the session state information from the metadata server

tclient

setup

Time the client host spend to setup the new session

tserver

setup

Time the server spend to create a new connection upon request

treply

Time to reply from the metadata server to the client host

tredirect

Time to redirect the state information request to the previous client host

trequest

buffer

Time to request the previous client host for buffered data

as it provides the same service with CS. In terms of handoff delay analysis (will be presented shortly), these two cases do not make any difference, since we assume the Content Server to be stateless. Resuming an old session on the server side is equal to creating a new one. Therefore, we do not specifically consider the case of multiple content servers in this paper. 3.1.3. Handoff delay analysis. We use handoff delay to evaluate the performance of the above scheme. We define the handoff delay as the time elapsed since CH1 stops streaming from CS until CH2 receives the first stream packet (from Step A3 to C2. Note that there may be a gap between Step B1 and B2, when the user is absent for arbitrary amount of time. We do not count this gap in. We list all delay parameters in Table 3. Some of them will appear in the analysis of later handoff schemes. We denote the delay of the basic handoff scheme as below. Delay = tupdate + trequest + tretrieve + max{tclient

setup , tserver setup }

(1)

The delay mainly occurs during Phase B and Phase C. We identify the major causes of handoff delay as follows: tupdate , tretrieve , tclient setup and tserver setup . We pick the first two items because the amount of a session state information can be large. Take MPEG streaming as an example, the session state may include information required to reconstruct the next frame of original input video, such as YUV pixel information as well as side information such as macroblock mode for the reference frames. The resulting data set can be several megabytes. tclient setup refers to the time complexity for CH2 to setup the client program and request for streaming from CS. tserver setup is the time spent by CS to spawn a new streaming connection to CH2. These two procedures can proceed in parallel but have to be finally synchronized for data streaming. We thereby consider the maximum overhead of them. In Section 3.2, we propose a series of enhanced handoff schemes to eliminate these factors. We also quantitatively analyze each of them and their possible combination. Finally, we discuss the optimal handoff schemes under different mobility situations and their tradeoffs. 3.2.

Enhanced handoff schemes

In this section, we present a series of enhanced versions to the basic handoff scheme. Each scheme is targeted to eliminate certain delay factors in either Phase B or Phase C. Therefore,

147


Client Host 1 (CH1)


User Leave

A2 A3

Client Host 2 (CH2)

User Arrival Handoff Delay

B1*

B3*

B2*

B5*

B4* C1 C2

Figure 6.

Direct state transfer handoff timeline.

they are orthogonal and can be combined to produce even more efficient handoff schemes. This issue will be discussed in Section 3.2.5. 3.2.1. Direct state transfer. We first consider the possibility of saving handoff delay during Phase B. The basic handoff scheme uses the User Metadata Server as the “anchor point” to store and forward the state information of a session. This approach is suitable for the longterm handoff case, e.g., the user relocates from his/her home to the office. In this scenario, it is better to transfer the session state to the metadata server (MS) so that the old client host (CH1) is freed from the state maintenance task. However, in the case of immediate handoff (e.g., a user walking around the smart space and having his/her video session following him/her to the nearest display), it is inefficient to transfer the state information back and forth. Instead, it should be directly relayed from CH1 to CH2. We argue that this change will greatly reduce the delay of Phase B, since the old and new client hosts are closely located in the case of immediate handoff. We show the timeline in figure 6, where the newly inserted or modified steps are marked with ∗. In Step B2∗ and B3∗ , MS redirects CH2’s request to CH1 according to the Current Holder field (introduced in Section 3.1.2) in its record. In Step B5∗ , CH1 sends the state information directly to CH2. We show the handoff delay as below. In (2), trequest + treply roughly equals to the round trip time from CH2 to MS. Delay = trequest + treply + tredirect + tpropagate + max{tclient


(2)

Note that upon receiving the state request message from CH2 (Step B3∗ ), CH1 still needs to contact MS (Step B4∗ ), not to update state, but to nullify the Current Holder field of the user record. After this step, MS immediately set the Current Holder as CH2, whose request

148


has been blocked since Step B1∗ . Thus the Current Holder ownership is sequentialized even if the state transfer is not accomplished on MS. The up-to-date state information is kept either at the Current Holder client host, or at MS if the field is null. However, if the the Current Holder client host crashes, the state information will roll back to the one stored at MS, which can be arbitrarily old. To avoid this problem, we can combine the basic handoff scheme with the current one. Namely, we still let CH1 update its session state to MS in Phase B. If the request from CH2 arrives when the update is not finished yet, it is redirected to CH1 so that CH1 updates to both CH2 and MS. This method ensures both fast state transfer and secure state backup at the cost of duplicated data transmission. 3.2.2. Proactive handoff. In the Direct State Transfer scheme, the state request message of CH2 travels three times from MS to CH1. The reason is that the handoff is assumed to be reactive. CH1 does not know its successor a priori and vice versa for CH2. However, Proactive Handoff can happen, e.g., a presenter driving a video session from his/her laptop to the display wall during a presentation. In this case (CH1 knows its successor as CH2 before handoff happens), we can further eliminate the propagation delay of the state request message. The timeline is shown in figure 7. We show the handoff delay as below. In Eq. (3), trequest + treply + tredirect is further removed from Eq. (2). Delay = tpropagate + max{tclient


(3)

Note that CH1 still needs to contact MS to resign itself as the Current Holder (Step B1∗ ). Similarly, CH2 needs to contact MS (Step B3∗ ) to declare itself as the Current Holder. However, this field needs to be locked during the period from B1∗ to B3∗ , even though its value is null. This will prevent other competing client hosts to wrongfully become the Current Holder.

Client Host 1 (CH1)


User Leave

A2 A3

Handoff Delay

B1*

Client Host 2 (CH2) B2* User Arrival

C1 C2

Figure 7.

Proactive handoff timeline.

B3*

149


Client Host 1 (CH1)


User Leave

A2 A3 B1


B2 User Arrival B3 C1* C2*

Figure 8.

Stateful server handoff timeline.

3.2.3. Stateful server. We now consider saving handoff delay during Phase C. One possibility is to decrease handoff overhead on the server side. This can be done by turning the stateless Content Server into a stateful one. At the beginning of the handoff, CH1 notifies CS to suspend its session instead of terminate it. CH1 then records the session identifier as part of the state information and sends it to MS. After receiving the state information, CH2 asks CS to simply wake up the sleeping session indexed by the recorded session identifier (Step C1∗ and C2∗ ). The handoff timeline is shown in figure 8. We show the handoff delay as below. Equation (4) differs from Eq. (1) in that tserver setup is eliminated. Delay = tupdate + trequest + tretrieve + tclient

setup

(4)

Note that the session suspension/resumption in this case differs from traditional one in that the client side is changed. Therefore, the new client host (CH2) needs to authenticate itself to the server (CS) in order to prevent impersonating intruders. The authentication information could be the username/password pair. It could also be any certificate or token negotiated by CH1 and CS [27], and later handed to CH2 through state information transfer. We choose the former option in our prototype system. Stateful server can help reduce server response time, thus accelerate the session setup at the new client host. On the other hand, it lowers the server resource utilization(process, network sockets, memory, etc.). To address this problem, we let the content server associate with each suspended session a timeout value, so that certain resource occupied for long enough time will be recycled. Additionally, admission control should be enforced to limit the portion of resources allocated to sleeping sessions.

150


Handoff Point

Handoff Point

Residual Buffer

Client Host 1 (CH1)

Client Host 1 (CH1)

Client Host 2 (CH2)

Client Host 2 (CH2)

Content Server (CS)

Content Server (CS) Data Stream

Server Breakpoint

Data Stream

Basic Handoff Scheme Figure 9.

Residual Buffer

Enhanced Handoff Scheme

Residual client buffer smoothing.

3.2.4. Residual client buffer smoothing. We just discussed saving handoff delay on the server side during Phase C. We can also reduce the Phase C delay on the client side by leveraging the client buffering technique in data streaming. We notice that the client host normally buffers streaming data locally to ensure smooth video/audio playback. However, figure 9 shows that in the basic handoff scheme, the buffered data at CH1 is simply discarded and retransmitted later from CS to CH2. Alternatively, CH2 can request the residual data left in CH1’s buffer, which is instantly available (Step C1∗ ). It happens right after CH2 receives the state information(Step B3), in parallel with the client session setup (Step C3∗ ). Upon receiving data from CH1 (Step C2∗ ), the playback can be started immediately. The handoff timeline is shown in figure 10. As shown in figure 9, the state in the enhanced handoff scheme is split into two points. The first point is the same with the one in the basic scheme, so that CH2 can use it to reconstruct data frames from CH1. The second point is the breakpoint from which CS will send data to CH2. The space between these two points represents the residual data buffered at CH1. We show the handoff delay as below. In Eq. (5), max{tclient setup , tserver setup } is replaced by trequest buffer . Delay = tupdate + trequest + tretrieve + trequest

buffer

(5)

On the flip side, this scheme makes the client host stateful. CH1 has to keep the buffered data until CH2 requests it. To address this problem, we employ the same solution taken by the Stateful Server scheme. We associate the buffer with certain timeout value. If the buffer becomes unavailable, CH2 has to request data from CS starting at the first breakpoint. This case falls back to the basic handoff scheme.

151


Client Host 1 (CH1)


User Leave

A2 A3 B1


B2 User Arrival B3 C1*

C3*

C2* C4*

Figure 10.

Residual client buffer smoothing handoff timeline.

Also note that to ensure smooth playback, the playback time of the buffered data on CH1 has to be longer than the new session setup time. Otherwise, CH2 will experience transient delay after draining the buffered data from CH1. 3.2.5. Enhanced handoff scheme analysis. Up to now, we have presented the basic handoff scheme and its enhanced versions. Among the four enhanced schemes discussed in Section 3.2, the former two reduce the handoff delay during session state transfer (Phase B), while the latter two try to accelerate the new session setup (Phase C). All these solutions are orthogonal to each other. Thereby, we can combine them to yield even more enhanced handoff schemes. For the purpose of simple illustration, we consider the above four enhanced schemes as primitives and denote them as follows. T : Direct State Transfer P: Proactive Handoff S: Stateful Server B: Residual Client Buffer Smoothing In Table 4, we enumerate result schemes of all possible combinations of the above primitives as well as their delay time. We use + to denote combining operation. Table 4 shows that we only need to combine at most two schemes to minimize the handoff delay. Obviously, a good combination can reduce both delays in Phase B and Phase C. We find that combining Proactive Handoff and Residual Client Buffer Smoothing (P + B)

152


Table 4.

Enhanced handoff schemes. Handoff scheme

Handoff delay

T+P

Delay(P)

T +S

trequest + treply + tredirect + tpropagate + tclient

T+B

trequest + treply + tredirect + tpropagate + trequest

P+S

tpropagate + tclient

P+B

tpropagate + trequest Delay(B)

T +P+S

Delay(P + S)

T+P+B

Delay(P + B) Delay(T + B)

P+S+B

Delay(P + B)

T +P+S+B

Delay(B + P)

buffer

setup

S+B

T +S+B

setup

buffer

will create the optimal result. However, it makes the strongest assumption that the handoff sequence is known a priori by the client hosts. In the case of reactive handoff, the best choice is the combination of Direct State Transfer and Residual Client Buffer Smoothing (T + B). Interestingly, our analysis shows that Stateful Server is of little help (as verified in the case study). This observation seemingly contradicts with previous study. This is because in the case of user mobility, the new client host has to reinstantiate the session program of the old client host from scratch. Such overhead is unavoidable, thus offsets the benefit of fast session resumption brought by the stateful server approach. If the client host remains unchanged during the handoff (traditional host mobility problem), this benefit will still be significant. To summarize, this subsection mainly presents the design of a series of handoff schemes to support user level mobility. We also explored the possibility of combining these schemes into more advanced solutions. All of them are applicable for generic multimedia applications, such as audio/video streaming, web browsing, etc. We note that our solutions can be further enhanced through application-specific optimization. For example, we assume the state transfer to be transactional, i.e., only after the complete state information is acquired, the new client host can setup the session program. However, if the application only needs a starting portion of state information to get started [22], we can make the program setup and transmission for the rest part of the state proceed in parallel, which greatly saves the state transfer delay. 4.

Transcoding-based handoff

In the last section, we have discussed solutions for the user-level handoff problem, mainly focusing on the state information transfer and session resumption. However, as mentioned in Section 2.3, when the handoff occurs across heterogeneous client host platforms, three problems arise. First, we must find the right application, which is able to access the same

153


service and be compatible with the current client host. Second, certain transcoding task may need to be performed to adapt the service content. This happens mostly when the resource availability drops during the handoff, e.g., from PC to PDA. Finally, if the service content degradation is unavoidable, we should maximally preserve the service data fidelity according to the user’s QoS preferences. The first problem can be addressed by leveraging existing solutions on service discovery and dynamic program downloading/execution, as mentioned in Section 2.3. In the remainder of this section, we will present solutions for the latter two problems. Specifically, Section 4.1 presents the modified handoff scheme when the transcoding service is incorporated. Section 4.2 discusses the transcoding-based QoS adaptation problem.

4.1.

Transcoding-based handoff scheme design

In order to incorporate the transcoding service into the user-level handoff, we add a new entity to the basic handoff scheme: Transcoding Server (TS).3 Let CH2 be a handheld device, which must receive data from CS via TS, the handoff timeline is shown in figure 11. Compared to the basic handoff scenario in figure 5, only Steps B2 a and C2 a are added. In B2 a, CH2 asks TS to retrieve the session state information on its behalf. In C2 a, TS sends the adapted data to CH2. Therefore, in order to get the delay analysis for the transcodingbased handoff scheme, we only need to add the delay of B2 a and C2 a to the original delay analysis in Eq. (1) in Section 3.1.3. Note that this method applies to all other enhanced handoff schemes presented in Section 3.

Client Host 1 (CH1)


User Leave

A2 A3 B1

Handheld Transcoding (CH2) Server (TS) Handoff Delay

B2

B2-a B3

User Arrival

C1 C2 C2-a

Figure 11.

Handheld device handoff timeline.

154


Client Host 1

Client Host 2

(PC) VoD Application 1 1 1 Q = (qframesize , qframerate )

(Handheld Device)

QoS Mapping

Q-R Mapping OS & Network 1 1 R = (rCPU , rbandwidth )

R-Q Mapping User-level Handoff

1

Figure 12.

4.2.

VoD Application 2 2 Q2 = (qframesize , qframerate )

OS & Network 2 2 , rbandwidth ) R2 = (rCPU

Illustration of QoS mapping problem.

Transcoding-based QoS adaptation

We illustrate the transcoding-based QoS adaptation problem on TS in figure 12. Suppose the 1 1 user originally used the VoD application with certain QoS setting Q 1 = (qframesize , qframerate ) 1 1 1 1 on CH1. Q consumed certain amount of resources, denoted as R = (rCPU , rbandwidth ). Upon user handoff to the handheld device CH2, the available resource on CH2 (R 2 ) is much less than R 1 . As a result, the original QoS setting Q 1 cannot be satisfied by R 2 . Therefore, we should use the inverse Resource-to-QoS mapping to get the feasible QoS setting Q 2 , which can be satisfied by R 2 . We call the whole process illustrated in figure 12 as QoS mapping, i.e., to map the original QoS setting Q 1 on CH1 to the new setting Q 2 on CH2 upon user handoff. The challenge of this problem is that the mapping from R 2 to Q 2 is ambiguous. For example, let us consider the video adaptation, where the transcoding server has to perform a MPEG-to-BMP transcoding. The quality of the transcoded BMP stream will depend on the wireless bandwidth availability between TS and the handheld device. However, the bandwidth availability can influence any of the QoS parameters in the QoS setting of the BMP stream: frame size, pixel resolution, and frame rate. If the user prefers high quality image, we can keep the color depth and frame resolution of the original video data. However, the frame rate is dropped significantly. On the other hand, if the user prefers smoother playback, we can increase the frame rate by degrading the image quality of each frame. The optimal QoS setting should correctly reflect the user’s QoS preferences and maximally utilize the system resource. However, given a potentially large number of candidate QoS settings, what we need is an evaluation mechanism to choose the best one. 4.2.1. Information needed for QoS mapping. Before presenting solution to the QoS mapping problem, we first extend the service information in Table 1 with several new entities. These entities are critical for the QoS mapping calculation, as shown in Table 5. Original QoS Setting includes a set of tunable QoS parameters. They are provided by the application itself, such as the frame rate, frame size in the VoD application. The values in this entry represent the original QoS setting (Q 1 in figure 12). QoS Preferences is a set of nonnegative values corresponding to a weight for each QoS parameter in QoS Setting. This entry is filled by the user when the application is initiated. The user is also allowed to specify Additional Constraints. For example, he/she can specify that the adapted frame rate is no less than 5 frame/second, etc. All this information belongs to the user metadata information.

155


QoS setting and preferences of the VoD service. Service name

Video-on-demand

Service description

Same as in Table 1

Service content

...

Service state information

...

Original QoS setting

QoS preferences

Additional constraints

Frame rate

30 frame/second

Frame size

192 × 144

...

...

Frame rate

0.6

Frame size

0.3

...

...

Minimal frame rate

5 frame/second

Minimal frame size

48 × 36

...

...

4.2.2. QoS region and evaluation function. As mentioned earlier in this subsection, an evaluation mechanism is needed to choose the best QoS setting among a number of candidate QoS settings. To achieve this, we must make two distinct QoS settings comparable. Hull et al. [12] and Shankar et al. [26] propose the notion of Value Function, which establishes a partial-order relation among different QoS parameters for comparison of overall qualities of two QoS settings. In this paper, we reuse the idea of Value Function to address the QoS mapping problem. We first introduce the notion of QoS region, which is defined as the set of all QoS settings that can be satisfied by the resource capacity of the current client host. In figure 12, it refers to the set of all QoS settings that can be satisfied by R 2 . We use the MPEG-to-BMP transcoding example to illustrate the QoS region. We consider two QoS parameters: qframesize max max and qframerate . The maximum values qframesize and qframerate are bounded by the original video stream, which has the highest quality (192×144 bytes, 30 frame/s).4 For resources, we only consider network bandwidth, i.e., R = (rbandwidth ). Therefore, any candidate QoS setting must satisfy qframesize · qframerate ≤ rbandwidth . If we denote the bandwidth of a handheld device as 250 Kbps, its QoS region is shown as the shadow area in figure 13(a). Each point in the region represents a candidate QoS setting. Our next step is to design an Evaluation Function (EF), which makes the QoS settings in the QoS region comparable. The function is designed as the weighted sum of all normalized QoS parameters. The weight of each QoS parameter is given by the corresponding QoS Preference value in Table 5. Formally, for a QoS setting n Q = (q1 , . . . , qn ) and the corresponding QoS preference vector W = (w1 , . . . , wn ) ( i=1 wi = 1), the evaluation function is denoted as follows:

EF(W, Q) =

n i=1

wi ·

qimax

qi − qimin

(6)

Figure 13.

192x144

Frame Size

(a) Original QoS Region

Increasing Quality

Maximum Allowable Bandwidth

Illustration of QoS region.

30 frame/s

Frame Rate

1

1

1

Normalized Frame Size

(b) Normalized QoS Region

Normalized Frame Rate

Qopt 1

Normalized Frame Size

(c) Optimal QoS vector


1

d

1

Frame Size

Qopt Normalized

(d) Optimal QoS vector under additional constraint


156 CUI, NAHRSTEDT AND XU


Figure 14.

157

Video adaptation results of different QoS preferences.

In the MPEG-to-BMP transcoding example, let W = (wframesize , wframerate ) be the QoS preferences, Q = (qframesize , qframerate ) be the QoS setting, the evaluation function is denoted as: EF(W, Q) = wframesize ·

qframesize qframerate + wframerate · max max min min qframesize − qframesize qframerate − qframerate

(7)

Now our goal is to find the optimal QoS setting Q opt , which is able to maximize Eq. (7). Formally, let W p be a fixed QoS preference vector, Q opt should satisfy: EF(W p , Q opt ) = max(EF(W p , Q))

(8)

min max min For example, let us suppose qframesize = 0 byte, qframesize = 192 × 144 bytes, qframerate =0 max frame/s, qframerate = 30 frame/s, W = (0.6, 0.4), then the goal is to maximize the evaluation qframesize function (0.6 · 192×144−0 + 0.4 · qframerate ). If we normalize the QoS region as shown in 30−0 figure 13(b), the problem becomes to find such a line c = 0.6 · qframesize + 0.4 · qframerate , which crosses the region and maximizes c. This line is shown in figure 13(c) and its crossing point is Q opt = (192 × 144 bytes, 1.25 frame/s). Note that we can impose any additional constraints (provided in Table 5). For example, as shown in figure 13(d), if the frame size is constrained to be no more than d · (192 × 144) bytes (normalized value is d), we will get another Q opt . Figure 14 shows the adaptation results from our transcoder experiments. The transcoder decreases the frame size by lowering the color depth. As we can see, different QoS preferences or constraints result in different configurations of QoS settings about image quality and frame rate. They all maximally utilize the available bandwidth, and correctly reflect the user’s preferences.

5.

Validation

To prove the soundness of our user-level handoff solution in heterogeneous computing environment, we have prototyped our framework on a variety of system platforms, ranging

158


Figure 15.

Prototype system setup.

from handheld PC to Windows NT and Unix machines. To testify the framework, two multimedia applications were built as case studies: Mobile Video Player, and Mobile Audio Player. In the remainder of this section, we briefly overview the experiment settings and system implementation. We then present the experimental results. 5.1.

Experiment settings and implementation

Our prototype system is deployed in the Active Space [9], an enabling infrastructure for ubiquitous computing. We choose two rooms in the DCL building to setup our experiments, as shown in figure 15. PCs located in these two rooms are selected as client hosts. Besides these fixed ones, each mobile user is assigned with a handheld PC (iPaq or HP Jornada) as his/her mobile client host. We employ the Air ID system [1] to be our underlying user detection component. Each user wears an active badge carrying his/her user ID and password. Each fixed client host is equipped with a base station, which is able to detect the badge signal when the user walks in or out of its RF range. Thus, both user arrival and leaving can be detected automatically.


159

The user is free to walk around in the room, with the multimedia service session following him/her to the client host at his/her proximity. When the user is on the way from Room A to B or vice versa, the same session is shifted to his/her handheld PC through in-building WaveLAN connection. This realizes the exact scenario we have described in Section 1. As described in Section 2.2, each client host carries a lightweight middleware layer to deliver mobility functionalities. We have implemented the middleware system on multiple platforms using different languages. More specifically, we have implemented it on iPaq and HP Jornada by C++, as well as on PC by Java. All implementations are CORBArized to facilitate their interaction with each other and with the overlying applications. We have built two testbed applications on top of the middleware layer: Mobile Video Player and Mobile Audio Player. While the audio player is built from scratch, the video player is the upgrade version of a legacy MPEG streaming player [10]. We modify the original application by wrapping it with a set of CORBA APIs, through which the middleware layer can inject or pull out state information of the current video session. For the same purpose, the audio player also exposes a set of CORBA APIs. The Mobile Video Player mainly consists of three components: client, content server, and transcoding server. Implemented by Java, the latter two components are deployed on highperformance PCs. To test the performance of our framework in heterogeneous environment, we implemented different versions of video client on iPaq, HP Jornada and PC respectively. Figure 16 shows the interfaces of some video client implementations. When deployed on high performance PC, the client directly retrieves MPEG stream from the content server and performs decoding on its own. However, if it is located on thin client hosts (e.g., HP Jornada) with neither enough CPU capabilities nor enough bandwidth, the transcoding server is involved to adapt the video stream. In our implementation, the transcoding server is able to perform MPEG-to-BMP transformation and downgrade the stream to any frame rate, frame size and color depth. The Mobile Audio Player also consists of client, content server, and transcoding server. For the same purpose as in the video player, we implemented different versions of audio client on iPaq, HP Jornada and PC respectively. Figure 17 shows the interfaces of some

Figure 16.

Mobile video player: Video session migration from PC to iPaq.

160


Figure 17.

Mobile audio player: Audio session migration from PC to HP Jornada.

audio client implementations. The audio player supports MP3 format. Our implementation makes improvement on the MAPLAY MP3 decoder to support high, medium and low audio qualities. Streams with different qualities consume bandwidth from 128 Kbps to 32 Kbps. Additionally, the transcoding server can transform the encoded data to WAV format, which is directly playable on the handheld PC. 5.2.

Performance evaluation

In this section, we present the experimental results of our prototype system. The major goal of our experiments is to evaluate the system performance at supporting user-level handoff and QoS mapping during transcoding. We first compare the performance of different handoff schemes presented in Section 3.2. We then show the result of QoS mapping algorithm presented in Section 4. 5.2.1. Handoff performance evaluation. We evaluated the system handoff performance based on the experimental settings introduced in Section 5.1. We use the same set of terminologies introduced in Section 3. Namely, the application session is migrated from Client Host 1 (CH1) to Client Host 2 (CH2). CH1 and CH2 receive data stream from the Content Server (CS), and interact with the User Metadata Server (MS) to request/update the session state information. Note that the absolute handoff delay time is impossible to acquire in this case, since it involves different client hosts. Instead, we collect delay information from CH1 and CH2 separately and aggregate them to approximate the real handoff delay time. Figure 18 shows the timeline of a handoff scenario in our experiment. We exclude several factors included in the handoff phase. For example, the period when user is on the fly should not be considered. We also exclude delays caused by the user location detection system, i.e., Air ID in our experiment. The main reason is that the handoff manager (Section 2.2) is able to depend on any user detection/tracking solution (e.g., active badges, face recognition, user manual login, etc.), whose performance can be greatly varied. Additionally, by doing so, we compare different handoff schemes fairly, since in proactive handoff scenario, the user detection module is not needed, while in other scenarios it is. Therefore,

161


Handoff Phase Video Session

User Leaving Event Detected

Session State Update

User On the fly

User Arrival Event Detected

Session State Retrieval

CH1

Session Setup

Session Begin

CH2

User Leaving

User Arrival

Figure 18. The timeline of a typical user-level handoff scenario. Only the shaded regions are evaluated in the experiment.

we regard location detection delays as orthogonal parts in evaluating the efficiency of our handoff schemes. As a result, only shaded regions in figure 18 are considered in our experiment. We mainly test the performance of our middleware framework at supporting the Video Player handoff. Instead of testing all possible handoff schemes listed in Section 3.2.5, we select four most representative ones, i.e., Basic Scheme, Direct State Transfer, Stateful Server, and Proactive Buffering (P + B in Table 4). Table 6 lists the testing video clips. The first experiment is to compare the handoff delay of the above four schemes under identical scenario. We let CH1 plays the “simpsons” video. The handoff happens when the Frame 286 is played. When user arrives at CH2, the same video session is resumed from Frame 287. Therefore, the handoff delay is denoted as the inter-arrival time between Frame 286 and Frame 287. CH1 is a Pentium III 700 MHz desktop. CH2 is a IBM ThinkPad notebook with the same settings. Both CS and MS are Sun Ultra-60 workstations. All these machines are connected via the local area network. As shown in figure 19, in basic handoff scheme, the handoff delay is approximately 1.3 second. The direct state transfer scheme reduces the delay by less than 200 ms since it eliminates updating the state information to MS. The stateful server scheme reduces the delay for about the same amount (The reason is explained later in figure 20). The proactive buffering scheme lets CH1 push the frames in its buffer to CH2 (Frame 287 to Frame 346). Note that CH1 sends data faster than the video streaming rate. This is because it sends them as a chunk of data without any streaming regulation. The underlying assumption here is that CH2 has at least the same buffering capabilities with CH1, so that it will not be overflowed. Also in this scheme, CS sends frames starting from Frame 347, instead of Frame 287. As a result, the handoff delay is greatly reduced to around 200 ms. Table 6.

Experimental video clips.

Title

Frame rate (frame/s)

Frame resolution

Colors

Avg. frame size (byte)

Max. frame size (byte) 7630

Simpsons

30

192 × 144

256

2415

Fargo

30

160 × 120

256

536

1890

Modem

30

160 × 120

256

264

1061


380

380

360

360

340

340

320

320 frame num

frame num

162

300 280 Frame #286

260

Frame #287

280 Frame #286

260 CH1 Playback CH1 Buffer CS to CH2

240

Frame #287

CH1 Playback CH1 Buffer CS to CH2

240 220

220 7000

300

8000

9000

10000 11000 time (ms)

12000

13000

14000

7000

8000

(a) Basic Scheme

9000

10000 11000 time (ms)

380

360

360

340

340

300 280 Frame #287

300

Frame #287 Frame #287

280 Frame #286

260 CH1 Playback CH1 Buffer CS to CH2

CH1 Playback CH1 Buffer CS to CH2 CH1 to CH2

240

220 7000

Frame #346

320 frame num

frame num

320

240

220 8000

9000

10000 11000 time (ms)

12000

(c) Stateful Server

14000

Frame #347

Frame #346

Frame #286

13000

(b) Direct State Transfer

380

260

12000

13000

14000

7000

8000

9000

10000 11000 time (ms)

12000

13000

14000

(d) Proactive Buffering

Figure 19. Frame sequence traces of different handoff schemes. The handoff delay is denoted as the inter-arrival time between Frame 286 and Frame 287, as marked in the graphs.

Next, we experiment two alternative handoff scenarios besides the normal one. The first scenario is the handoff from PC to handheld device (iPaq), as discussed in Section 4.1. Recall in figure 11, only Steps B2 a and C2 a are added compared to the basic handoff scenario in figure 5. Both B2 a and C2 a occur on the wireless link from the handheld device to the transcoding server. Therefore, we only need to add a new component to the total handoff delay time: Wireless Delay. This component is the total delay of Step B2 a and C2 a. In the second scenario, we change the handoff granularity from frame level to GOP level. As shown in Table 7, in the normal handoff scenario, the state information has to include not only the basic information about the video stream, but also the reference frames needed to decode the current frame (in our example, Frame 287). However, if we coarsen the handoff granularity to the GOP level, i.e., to skip the starting frame to the I frame of next GOP, reference frames are not needed. Figure 20 shows the delay time of different handoff scenarios acquired in the second experiment. Each column is the average result of running the same test on each video clip in Table 6, each clip three times. As we can see, the client/server setup overhead dominates the handoff delay. Unfortunately, the client side setup is unavoidable. This explains why the stateful server approach does not help much, since the server side setup proceeds largely in parallel

163


State information in different handoff granularities. Type

Description

Size (byte)

Frame level handoff Media info

File length, frame rate, starting frame (287), etc.

32

File header

Frame resolution, color depth, etc.

12

Reference frames

Frames 286 (I) and Frame 289 (P)

8266

GOP level handoff Media info

File length, frame rate, starting frame (292), etc.

32

File header

Frame resolution, color depth, etc.

12

ms

Norma l Hand off Handh eld De vice H GOP L andoff evel H andoff

1600 1400 1200 1000 800 600

Wireless Delay Server Side Setup Parallel Client/Server Setup Client Side Setup State Retrieval State Update

400 200 0

Figure 20.

Basic Scheme

Direct State Transfer

Stateful Server

Proactive Buffering

Handoff delay.

with the client side setup. Therefore, decreasing the server setup delay still cannot reduce the delay caused by the client side setup. The proactive buffering approach, on the other hand, does not try to reduce this delay, but to bridge it by utilizing the residual client buffer data. Our experimental results may be biased by the following factors. First, the state information is sized several kilobytes in our experiment, which is rather small. This number may increase significantly when dealing with high-quality video playback or more complicated multimedia applications such as video telephony or conference. In this case, the coarse-granularity handoff control solutions will become more attractive since it greatly saves the state information management overhead. Our initial experience with GOP-level handoff scheme shows that it does not cause much visual defection. Second, we do not consider some other factors which may increase the handoff delay. For example, client side data buffering may further delay the video playback. This problem can be solved by forcing the video player to flush the newly arrived data to the decoder right away. However, we consider it as application-specific operations. 5.2.2. QoS mapping algorithm evaluation. In Section 4, we presented a QoS mapping algorithm to find the best QoS setting, which reflects the user’s QoS preferences. To verify its usability, we made a series of experiments on multimedia data adaptation. We implement

164


a MPEG-to-BMP transcoder at the transcoding server, which is able to convert the MPEG stream into BMP sequence and downgrade the image into different frame resolution and color depth. The QoS mapping scheme is formalized as follows. We consider three QoS parameters: frame resolution, frame rate and color depth. Thus Q = (qresolution , qframerate , qcolor ). The maximum values of qresolution , qframerate and qcolor are determined by the test video clip “simpson” (192 × 144, 30 frame/s, 8 bit (256 colors)). We consider network bandwidth resource, i.e., R = (rbandwidth ). CPU resource is not considered since BMP image does not need any decoding operation. Therefore, we have qresolution · qframerate · qcolor ≤ rbandwidth . We denote the system capacity of the iPaq

Figure 21. Screen shots of different video data adaptation results on iPaq. From top down, each row has the color depth of 8 bits (256 colors), 4 bits (16 colors) and 2 bits (4 gray scale). From left to right, each column has the frame resolution of 192 × 144, 96 × 72 and 48 × 36. Note that the lower resolution images are stretched to the original size using mosaic effects. The frame rates are ranged from 1.25 frame/second to 30 frame/second.


165

iPaq

as R iPaq = (rbandwidth ) = (250 Kbps). Figure 21 shows the adaptation results of different QoS settings. These QoS settings are calculated based on QoS preference vector W and additional constraints. We list them under each image clip in figure 21. 6.

Related work

There has been a wealth of research work to provide mobility support on system and application levels. All of them need to cope with two fundamental problems: handoff and location management. Handoff refers to dynamically migrating a running session as mobility happens. Location management refers to tracking the location of a mobile host/user, so that the incoming data can be successfully redirected. We will briefly review existing solutions, examining their approaches for these two problems. 6.1.

System-level solutions

We review the system-level (OS and network) mobility solutions based on the OSI layering model from bottom up. First, on the network layer, Mobile IP [13, 18] laid down the foundation for IP-based mobility solutions. In Mobile IP, a mobile host owns two addresses: its home address and a temporary Care-of-Address in a foreign network. The correspondent host addresses the mobile host via its home address. Two new entities are added to the network infrastructure: Home Agent and Foreign Agent. The packet from the correspondent host to the mobile host is first sent to its home address. The home agent intercepts and tunnels the packet to the Care-of-Address. The foreign agent then captures the packet and forwards it to the mobile host. Mobile IP has several technical limitations such as indirect routing, incompatibility with ingress filtering, etc. Several extensions to the basic Mobile IP have been proposed to address these problems [5, 19]. On the transport layer, existing works include Snoop TCP[3], MSOCKS [15], etc. One of the most representative is TCP Migrate [27] by Snoeren and Balakrishnan. The paper argues that the mobility problem should be addressed in an end-to-end manner, requiring no changes to the IP substrate. An end-to-end transport layer solution is thereby proposed to support secure migration of an established TCP connection across IP changes. In TCP Migrate, a TCP peer can suspend an open connection and reactivate it from another IP address, transparent to the application on top of it. Security is achieved through the use of a connection identifier, which is negotiated during the connection establishment phase. However, since the mobile host does not have a permanent home address as in the Mobile IP, its IP address is modified when it changes the network attachment point. Rather, the paper assumes that the mobile host is associated with a host name and uses dynamic DNS update to change the mapping from its host name to its current IP address. To summarize, all these works belong to the host mobility solutions according to our categorization in Section 1. They are designed to provide transparent mobility support to the applications. However, the price of transparency is that the existing system infrastructure is changed. Mobile IP changes the IP substrate by inserting home agent and foreign agent to each network. TCP Migrate keeps the IP layer untouched, but modifies the TCP protocol stack. Both approaches are expensive to be widely deployed.

166


Despite the argument of whether it worths to adopt these solutions, our middleware framework can coexist with them and leverage the mobility support already provided. Furthermore, it compensates the deficiency that system-level solutions are not aware of application semantics. Our framework also works in traditional system infrastructure, where mobility is not supported. This makes our solution instantaneously deployable on today’s network architecture and any commodity operating system. 6.2.

Application-level solutions

On the application layer, The Berkeley ICEBERG project [21, 31] targets to support personal mobility in the context of heterogeneous communication paradigms, such as cellular phones, pagers and PDAs. Therefore, it aims at integrating cellular telephony networks with the Internet. In ICEBERG, a user is uniquely identified by his/her user ID. Additionally, the user is associated with one or several service IDs, e.g., phone number, email address and IP address. A user’s service access point is either specified by the user through the user preference registry or detected by the personal activity tracker. Based on this information, a call to the user is first mapped from the user ID to the service ID of his/her service access point, then routed through IAP (Iceberg Access Point). IAP is also responsible for media transformation (e.g., transforming email to voice message if the user is on his/her telephone). Mobile People Architecture (MPA) [2, 23] shares the same goal with ICEBERG. However, it tackles the problem of personal mobility by introducing a person layer on top of the application layer. A personal proxy is then introduced to achieve person-level routing. The personal proxy consists of tracking agent, dispatcher and application driver. The tracking agent maintains the list of devices or applications through which a user is accessible. The dispatcher directs the incoming call to the user’s current location. The application driver is responsible for converting the incoming data into the format compatible with the user’s communication device. The personal proxy also supports location privacy by filtering out unwanted calls or spam messages at the dispatcher. Session Initiation Protocol (SIP) [25, 34] is an IETF-developed signaling protocol. SIP is initially motivated by the need of providing mobility support for real-time applications over IP. It is argued that for real-time traffic based on RTP [24], there is a need for lightweight handoff, which has low latency and high bandwidth utilization. SIP introduces mobility awareness at a higher layer than the network layer. In SIP, each user is identified by a unique address (e.g., email address). This address is mapped to the current IP address of the user’s end system. A user agent and a SIP server is introduced. A caller wishes to initiate a session sends out an invitation to the callee’s SIP server. The SIP server then forwards the invitation to the current IP address of the callee’s end system, which in turn sets up the session. If handoff happens in the middle of the session, the mobile host first registers its new location with the SIP server, then sends out a reinvitation message to its correspondent host, including the same session identifier and its current IP address. Then the session can be resumed. A common feature shared by the ICEBERG, MPA and SIP is that they are all designed toward the personal communication applications, such as mobile telephony and messaging.


167

A central issue in this type of applications is that the system should be able to pinpoint the current location of a user, so that the message or call to this user can be redirected. As a result, the user location management problem is well addressed. However, handoff management is not the highlight of these approaches. This is because most applications targeted by them have short-lived or transactional connections, such as the transmission of voice mail. ICEBERG assumes that the handoff is supported transparently in the underlying cellular network. SIP explicitly supports mid-call handoff in the mobile telephony service, but only involves simple signalling operations to reestablish connections between users. The session state management is not considered. This is not the case for multimedia services with complicated state information, which our solution is mainly targeted. To provide mobility support for this type of application, service continuation is the most essential issue. Therefore, we mainly focus on efficient handoff and seamless state migration. Although user location management is not the highlight of this paper, our framework can be easily extended to support it. In fact, the user metadata server can be used for the same purpose as the personal activity tracker in ICEBERG, or personal proxy in MPA (Recall the usage of Current Holder field in each user record). We claim that our solution is complementary, not exclusive to the existing works. For example, SIP-supported applications can be easily integrated into our middleware framework. In this case, SIP server and user metadata server will be merged as one. 7.

Conclusion

Advancing mobile computing technologies are enabling “ubiquitous personal computing environment.” In this paper, we focus on an important problem in such environment: user mobility. In particular, we study the the user-level handoff problem in the background of multimedia service delivery in ubiquitous computing environment. We argue that the middleware layer is the best place to support user mobility in such an environment. To prove our concept, we have implemented a prototype middleware system. Two multimedia applications (Mobile Video Player and Mobile Audio Player) have been developed as testbed. The results show that our middleware framework is able to provide efficient user mobility support in the heterogeneous computing environment. Acknowledgments We would like to thank our past group members, Bo Zou, Vanish Talwar and Long Wang, for their contributions to the Mobile ID system [39], Security Architecture for User Mobility [29] and Mobile Audio Testbed [30]. Notes 1. Although we do not have a rigorous definition about QoS preference yet since it is very application-specific, we can view it as a user-defined preference list from a set of QoS parameters, which the user regards as critical compared to others. Examples are tracking precision in a visual tracking system and image quality in a video streaming application.

168


2. This problem happens mostly when advanced user detection technique is employed (see Section 5). For example, a user carrying a badge or wireless device to identify himself/herself may be detected by multiple base stations simultaneously. As a result, all these base stations assume themselves as the user’s client host, and request his/her record from the metadata server. 3. The transcoding server can be found by the service discovery service. 4. These values are provided by the Original QoS Setting entry in Table 5.

References 1. “Air ID system,” in http://www.pcprox.com/. 2. G. Appenzeller, K. Lai, P. Maniatis, M. Roussopoulos, E. Swierk, X. Zhao, and M. Baker, “The mobile people architecture,” ACM Mobile Computing and Communication Review, Vol. 1, No. 2, 1999. 3. H. Balakrishnan, S. Seshan, and R. Katz, “Improving reliable transport and handoff performance in cellular wireless networks,” ACM Wireless Networks, Vol. 1, No. 4, pp. 279–289, 1995. 4. B. Brumitt, B. Meyers, J. Krumm, A. Kern, and S. Shafer, “EasyLiving: Technologies for intelligent environments,” in Handheld and Ubiquitous Computing ’00, 2000. 5. S. Cheshire and M. Baker, “Internet mobility 4×4,” in ACM SIGCOMM ’96, 1996. 6. E. de Lara, D.S. Wallach, and W. Zwaenepoel, “Puppeteer: Component-based adaptation for mobile computing,” in Proceedings of SPIE Multimedia Computing and Networking (MMCN’02), 2002. 7. A. Fox, S. Gribble, Y. Chawathe, and E. Brewer, “Adapting to network and client variation using active proxies: Lessons and perspectives,” IEEE Personal Communications, 1998. 8. X. Fu, W. Shi, A. Akkerman, and V. Karamcheti, “CANS: Composable, adaptive network services infrastructure,” in Proceedings of the USENIX Symposium on Internet Technologies and Systems (USITS ’01), 2001. 9. “GAIA: Active space for ubiquitous computing,” in http://devius.cs.uiuc.edu/gaia. 10. C.K. Hess and R.H. Campbell, “Media streaming protocol: An adaptive protocol for the delivery of audio and video over the internet,” in ICMCS ’99, 1999. 11. T.D. Hodes, S.E. Czerwinski, B.Y. Zhao, A.D. Joseph, and R.H. Katz, “An architecture for secure wide-area service discovery,” Wireless Networks, Vol. 8, pp. 213–230, 2002. 12. D. Hull, A. Shankar, K. Nahrsted, and J. Liu, “An end-to-end QoS model and management architecture,” in Proceedings of IEEE Workshop on Middleware for Distributed Real-time Systems and Services, 1997. 13. D. Johnson, “Scalable support for transparent mobile host internetworking,” Mobile Computing, 1996. 14. B. Johanson, S. Ponnekanti, C. Sengupta, and A. Fox, “Multibrowsing: Moving web content across multiple displays,” in UBICOMP ’01, 2001. 15. D.A. Maltz and P. Bhagwat, “MSOCKS: An architecture for transport layer mobility,” in IEEE Infocom ’98, 1998. 16. B. Noble, M. Satyanarayanan, D. Narayanan, J.E. Tilton, J. Flinn, and K. Walker, “Agile application-aware adaptation for mobility,” in Proceedings of the 16th ACM Symposium on Operating System Principles (SOSP ’97), 1997. 17. R. Orr and G. Abowd, “The smart floor: A mechanism for natural user identification and tracking,” in Proceedings of the 2000 Conference on Human Factors in Computing Systems (CHI ’00), 2000. 18. C. Perkins, “IPv4 mobility support,” Request for Comments 2002, 2002. 19. C. Perkins and D. Johnson, “Route optimization in mobile IP,” in Internet Draft Work in Progress, 2000. 20. N.B. Priyantha, A.K.L. Miu, H. Balakrishnan, and S. Teller, “The cricket compass for context-aware mobile applications,” in Proceedings of ACM/IEEE International Conference on Mobile Computing and Networking (MOBICOM ’01), 2001. 21. B. Raman, R.H. Katz, and A.D. Joseph, “Universal Inbox: Providing extensible personal mobility and service mobility in an integrated communication network,” in Workshop on Mobile Computing Systems and Applications (WMCSA’00), 2000. 22. S. Roy, Bo Shen, and V. Sundaram, “Application level hand-off support for mobile media transcoding sessions,” in NOSSDAV ’02, 2002.


169

23. M. Roussopoulos, P. Maniatis, E. Swierk, K. Lai, G. Appenzeller, and M. Baker, “Person-level routing in the mobile people architecture,” in Proceedings of the USENIX Symposium on Internet Technologies and Systems (USITS ’99), 1999. 24. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A transport protocol for real-time applications,” Request For Comments 1889, 1996. 25. H. Schulzrinne and E. Wedlund, “Application-layer mobility tsing SIP,” ACM Mobile Computing and Communication Review, Vol. 1, No. 2, 1999. 26. M. Shankar, M. DeMiguel, and J. Liu, “An end-to-end QoS management architecture,” in Proceedings of Real-Time Applications Symposium (RTAS ’99), 1999. 27. A. Snoeren and H. Balakrishnan, “An end-to-end approach to host mobility,” in Proceedings of ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom ’99), 1999. 28. Sun Microsystems, “Jini technology specifications,” http://www.sun.com/jini/specs/. 29. V. Talwar, “A QoS-aware, secure architecture for supporting user identification and user mobility,” Master’s Thesis, Department of Computer Science, University of Illinois at Urbana-Champaign, 2001. 30. L. Wang, “MobAudio: Architecture of distributed audio on demand services with user mobility support,” Master’s Thesis, Department of Computer Science, University of Illinois at Urbana-Champaign, 2002. 31. H.J. Wang, B. Raman, C. Chuah, R. Biswas, R. Gummadi, B. Hohlt, X. Hong, E. Kiciman, Z. Mao, J.S. Shih, L. Subramannian, B.Y. Zhao, A.D. Joseph, and R.H. Katz, “ICEBERG: An Internet-core network architecture for inregrated communication,” IEEE Personal Communications, Special Issue on IP-based Mobile Telecommunication Networks, 2000. 32. R. Want, A. Hopper, V. Falcao, and J. Gibbons, “The active badge location system,” ACM Transactions on Information Systems, Vol. 10, No. 1, pp. 91–102, 1992. 33. A. Ward, A. Jones, and A. Hopper, “A new location technique for the active office,” IEEE Personal Communications, Vol. 4, No. 5, pp. 42–47, 1997. 34. E. Wedlund and H. Schulzrinne, “Mobility support using SIP,” Request For Comments 2543, 1999. 35. J. Werb and C. Lanzl, “Designing a positioning system for finding things and people indoors,” IEEE Spectrum, Vol. 35, No. 9, pp. 71–78, 1998. 36. D. Xu and K. Nahrstedt, “Finding service paths in a media service proxy network,” in Proceedings of SPIE Multimedia Computing and Networking (MMCN ’02), 2002. 37. D. Xu, K. Nahrstedt, and D. Wichadakul, “MeGaDiP: A wide-area media gateway discovery protocol,” in Proceedings of IEEE International Performance, Computing, and Communications Conference (IPCCC ’00), 2000. 38. D. Xu, K. Nahrstedt, and D. Wichadakul, “QoS-aware discovery of wide-area distributed services,” in Proceedings of IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid ’01), 2001. 39. Bo Zou, “Mobile ID protocol: A badge-activated application level handoff of a multimedia streaming to support user mobility,” Master’s Thesis, Department of Computer Science, University of Illinois at UrbanaChampaign, 2000.

Yi Cui received his B.S. and M.S. degrees in computer science from Tsinghua University, Beijing, China. Currently he is a Ph.D. candidate in the department of computer science at University of Illinois at Urbana-Champaign. His research interests include mobile computing, quality of service, distributed middleware, multimedia service delivery and scalable multimedia content distribution.

170


Klara Nahrstedt is an associate professor at the University of Illinois at Urbana-Champaign, Computer Science Department. Her research interests are directed towards reconfigurable multimedia services, multimedia protocols, middleware systems, quality of service (QoS) provision, QoS routing, QoS-aware resource management in distributed multimedia systems, and multimedia security. She is the coauthor of the widely used multimedia book ‘Multimedia: Computing, Communications and Applications’ published by Prentice Hall, the recipient of the Early NSF Career Award, the Junior Xerox Award, Lucent Award, IEEE Communication Society Leonard Abraham Award for Research Achievements, and the Ralph and Catherine Fisher Professorship. Klara Nahrstedt received her B.A. in mathematics from Humboldt University, Berlin, in 1984, and M.Sc. degree in numerical analysis from the same university in 1985. She was a research scientist in the Institute for Informatik in Berlin until 1990. In 1995 she received her Ph.D. from the University of Pennsylvania in the department of Computer and Information Science. Klara Nahrstedt is the member of ACM, ACM SIGMM, and IEEE.

Dongyan Xu is an Assistant Professor of Computer Science at Purdue University. He received his Ph.D. from the University of Illinois at Urbana-Champaign in 2001, and B.S. from Zhongshan University, China in 1994, both in Computer Science. Dr. Xu’s research areas include distributed middleware and operating systems, ubiquitous and mobile computing, and peer-to-peer overlay networks and services. Dr. Xu is on the Program Committees of IEEE INFOCOM 2003, IEEE ICDCS 2003, and SPIE/ACM International Conference on Multimedia Computing and Networking 2003. In 2000, he received the C.L. and Jane W-S. Liu Award from UIUC. He is a member of ACM, IEEE, and the e-Enterprise Center at Discovery Park, Purdue University.