User-centric mobility management for multimedia content access

Multimed Tools Appl DOI 10.1007/s11042-011-0827-9

User-centric mobility management for multimedia content access Raffaele Bolla · Riccardo Rapuzzi · Matteo Repetto

© Springer Science+Business Media, LLC 2011

Abstract Current mobility protocols and architectures are mainly targeted to devices or applications and they usually lack the ability to support user-centric paradigms; moreover, they usually face a single aspect of the problem, i.e., terminal handover or session mobility. Full mobility support is only available to specific applications or protocols (e.g., SIP) but these approaches do not exploit all facilities for movement detection at the network/link layers and do not allow to use the same framework for different applications. This paper proposes a generic mobility framework for terminal handover and session migration. It pursues the user-centric paradigm and builds a cross-layer architecture, yielding to a high level of generality, applicability and flexibility. Unlike other approaches, it does not require any modification in correspondent peers and works with a minimal network infrastructure. Software implementations are described for two representative real-time multimedia applications, i.e., media streaming and interactive conference. The effectiveness of the framework was analyzed by means of both performance measurements in local and Internet testbeds and user evaluation during a live demo conducted at a national science exhibition. Keywords Mobility architecture · Pervasive communication · User-centric media · Personal address

R. Bolla · R. Rapuzzi Department of Communications, Computer and System Sciences, DIST–University of Genoa, Via Opera Pia 13, 16145 Genoa, Italy R. Bolla e-mail: [email protected] R. Rapuzzi e-mail: [email protected] M. Repetto (B) Consorzio Nazionale Interuniversitario per le Telecomunicazioni (CNIT), Viale G. P. Usberti n. 181/A, 43124 Parma, Italy e-mail: [email protected]

Multimed Tools Appl

1 Introduction Since its beginning, the Internet has constantly evolved; it has brought new forms of communication, entertainment, business and education, where content is mainly addressed to humans rather than to their terminals, thus shifting the role of users from mere passive consumers of mainstream content to really active participants in the overall media handling chain [42]. This motivates new paradigms of communication known as User Centered Media (UCM), where users are at the center of the network, device and multimedia worlds, and they are not required an in-depth knowledge of the surrounding technology. One of the main implications of the user-centric approach is pervasive access to content, which should happen independently of where the user is (ubiquity) and what devices/interfaces he uses (heterogeneity). This implies transparent, continuous and seamless usage of networked resources, and falls under the topic of mobility. From a network perspective, the main aspects concern retaining connectivity while handing off among heterogeneous networks (terminal mobility) and transferring on-going sessions among different terminals (session migration). Terminal mobility has been thoroughly investigated and many algorithms and protocols are available; far less solutions have been proposed for session migration, which is a more recent issue, mostly related to multimedia traffic. These two aspects of mobility are usually treated separately. The only noticeable exception is the Session Initiation Protocol (SIP) [32], which provides a comprehensive framework for mobility management in a user-centric fashion; unfortunately, its applicability is limited to SIP-controlled sessions. In this paper, we present a general user-centric mobility framework acting as a “network service”, which provides both terminal mobility and session migration in a common and homogeneous way to all applications. We adopt a cross-layer infrastructure that deals with mobility mostly at the network layer; only minimal assistance from higher layers is required to cope with application-specific issues (i.e., starting the service, initiating the migration and transferring the current application context for session mobility). We show and evaluate the integration of our mobility framework with SIP [32] and with the Real-Time Streaming Protocol (RTSP) [34] for two-way interactive communications (i.e., Voice-over-IP) and media streaming (i.e., Video-on-Demand), respectively. Our approach brings important benefits over alternative solutions. First of all, every application exploits the same mobility framework. Second, it allows the highest degree of compatibility with the current Internet: it hides mobility to all terminals that are not directly involved in the migration (usually termed as “correspondent parties”); further, the mobility service can be implemented over this global infrastructure by adding a very limited number of “mobility agents”. Third, working at the network layer enables to deal with terminal handovers in an effective and timely way; at higher layers, applications must rely on DHCP for network unreachability detection and address change, and this is known to be very slow. Fourth, the framework could be easily extended to manage service portability, i.e., adapting the content to the current context (network conditions, terminal capability). Last but not least, our framework represents the demonstration that the user-centric paradigm can be implemented in the network as well, in addition to applications (as it has been done until now).

Multimed Tools Appl

The paper is organized as follows. Section 2 reports the outcomes from the user interview that have motivated our work. Section 3 provides a brief taxonomy about mobility in data networks, including the most recent paradigms related to our approach. Section 4 discusses the architecture of the proposed mobility framework and Section 5 describes the current implementations for Voice-over-IP and multimedia streaming. We provide performance analysis for the current implementations both in a local environment and over the Internet in Section 6; moreover, we discuss user feedback we got from a live demo at a national exhibition. Finally, we give our conclusions in Section 7.

2 Motivations Mobility management has traditionally been designed following device- or networkcentric approaches. However, the particular nature of multimedia communication suggests to pursue a user-centric paradigm; examples of this approach are available for specific applications (i.e., the SIP protocol and its mobility framework), but our aim is to apply it at the network layer, in order to build a more general and portable mobility framework. As of the central role of users in this new paradigm, it comes natural to argue about what they expect from mobility management; this outcome can motivate our approach and it can be used to derive the main design guidelines. We interviewed about 100 users aged between 14 and 69, with different background and degree of scholarship. Table 1 reports a simple profile of our sample in terms of age, sex and years spent in education. The first question was about which applications should support mobility. We proposed an heterogeneous set, ranging from phone calls, to Internet browsing, to office applications. Figure 1 shows the percentage of users who chose each application in the given set. Mobility is considered useful for almost every application by more than 35% of users; thus a common general framework is preferable compared to application-specific solutions. Related to applications are devices used for them. A large number of small and portable devices with ever increasing multimedia capability are used every day; nowadays users are becoming aware that their applications are not tailored to specific equipment and they would not like to break their sessions whenever they must (or simply wish) change the current terminal. Figure 2 shows that at least 50% of interviewees would like mobility features on four very common devices; further, near (or more than) 20% of them would like the same for all multimedia

Table 1 Profile of the sample of users

Age

Males (%)

Females (%)

Education (years)

50

13 20 9 7 3

11 16 6 9 6

6.04 9.94 14.73 14.92 16.75

Total

52

48

Multimed Tools Appl Fig. 1 Percentage of users who would like mobility management for typical applications

100 90 80 70

% of users

60 50 40 30 20 10 0 ne

g

kin

Ma

o ph

c g ls V es net usi ttin cal ng T gam Inter i o m Cha o t h e e c t g id th Wa tenin gv ng yin rowsi Lis Pla B

her

Ot

equipment. Providing mobility as a network service may help to reduce complexity of applications and operating systems of such heterogeneous set of devices; moreover, many devices are portable and thus optimizing the procedures is a must. From a networking perspective, it is worth knowing where users expect this technology to be available. Home is voted by 50% of users, but there is also a large interest in having this service available at work and on the road (see Fig. 3). Thus, mobile clients may lie in different access networks, both public and private: they should be ready to work without any local infrastructure or support. People cannot bring many devices along: this would break the pervasive communication and user-centric paradigms. However, when they are away home, pervasiveness must rely on the availability of third party’s devices in the environment;

Fig. 2 Percentage of users who would like mobility features to be present in widespread devices

90 80 70

% of users

60 50 40 30 20 10 0

r r TV laye p PC hone dheld aptop nsoletereo laye tereo hone honeOther P kto artp an L e co S 3 P ar s ed p ile p D s P H C Fix ob m M DV De Sm M Ga

Multimed Tools Appl Fig. 3 Percentage of users who expect the mobility service to work in different daily environments

60 50

% of users

40 30 20 10 0 me

d

Ho

Fig. 4 Percentage of users willing to let their own device available to other people

he

t On

roa

ere

wh

y ver

E

her

ere

Ot

wh

No

80 70

% of users

60 50 40 30 20 10 0

Fig. 5 Percentage of users willing to use public and third party’s devices

100 90 80

% of users

70 60 50 40 30 20 10 0 n’s

s’

nd

Ow

n’s

Ow

&

frie

Pu

ces

evi

cd bli

ice

y An

dev

Multimed Tools Appl

the main natural question that arises is: are they willing to share devices (i.e., to use third party’s devices or to let their ones available to other users)? The answer is quite clear from Figs. 4 and 5: they would be willing to share devices with friends, but very few would do the same with public and third party’s ones. This confirms the meaningfulness of pursuing a user-centric approach that makes multimedia sessions independent of devices.

3 Related work Mobility is a quite general term concerning several aspects; terminal handover and session migration are the most interesting and challenging issues, as other aspects must be faced for each specific application. This section provides a brief survey of the main protocols and architectures related to the above topics. Herein and in the following, the terms “mobile hosts” and “local hosts” will refer to user terminals involved in some form of mobility (terminal handover and session migration, respectively), correspondent hosts will be their (generally fixed) counterparts in the communication session, and agents, anchors and proxies will be fixed infrastructure elements providing mobility features. 3.1 Terminal mobility Terminal mobility can be faced at different layers of the Internet protocol stack: network, transport and application [1, 8]. Network layer handover often involves a change in the link layer (vertical handover). The main goal in this context is to maintain transparency for higher layers, which do not have to be bored about IP address changes due to host mobility. Protocols of such kind can be broadly classified into two classes, macromobility and micromobility, based on their scope of operation with respect to the administrative domains in the Internet. Macromobility protocols work on the global Internet, but they are quite inefficient for what concerns signaling and delay; some examples are Mobile IP (MIP) [14, 27], the Host Identity Protocol (HIP) [13, 22] and Daedalus [36]. Micromobility protocols provide more efficient and effective solutions in local domains, but they require significant changes of the protocol stack; the most known solutions are the regional registration and hierarchical extensions to MIP [9, 40], CellularIP [43] and HAWAII [29]. Many architectures take into account both kinds of protocols. Network layer mobility has been criticized because it offers transparent mobility support to all applications even if this comes at significant cost, complexity and performance degradation [39], although this is not always required (for example, for short UDP transactions). Mobility at the transport layer can be managed end-to-end (TCP-Migrate [39], Mobile SCTP [31], Virtual Network Address Translation (VNAT) [41]) or by splitting the connection (MSOCKS [20]). Another way to deal with mobility is to let applications manage it. At the application layer two approaches are possible: designing application-specific mobility frameworks (e.g., for the SIP protocol [2, 7, 46]) and using middleware- or proxybased architectures (WiOptiMo [10]).

Multimed Tools Appl

In SIP [32], the INVITE method can be used to update the session endpoints (often called re-INVITE) [46] when their addresses change; however, this may be inefficient and does not work in case of simultaneous mobility of both peers. An alternative solution is the use of intermediates (such as an RTP translator [7]). A further approach for terminal mobility concerns the use of cross-layer architectures, with suitable interfaces to coordinate the efforts among different layers [44]. The focus has been on how merging MIP and SIP into a unified framework: the main aims are typically to use different mechanisms for different kinds of traffic (SIP for real-time and MIP for non real-time) [28], to co-locate the mobility agents into few elements [45] and to bind user’s URLs to home addresses [4, 15]. The full list of protocols and architectures is very long; description and comparison of the most important ones can be found in many papers [5, 12, 18, 30]. 3.2 Session migration The migration process can be handled end-to-end or by an intermediate proxy [11]; we can distinguish between application-specific frameworks (e.g., SIP [33, 38]) and generic middleware-based frameworks (e.g., VNAT with MIPv6 [19], Delegated IP [16]). SIP provides two schemes for session migration, namely Third Party Call Control and Session Handof f modes [33]. In Third Party Call Control (3PCC), the current terminal transfers the media to a new device, but retains the control of the session until its termination. On the contrary, Session Handoff (SH) transfers the whole session to a new device by notifying the remote peer. SIP also enables advanced features related to session migration, as splitting the connection on different terminals [6, 37]. During migrations, sessions may be re-negotiated between peers: this enables service portability when the device moves into a different network or when the capabilities of the new terminal change. The same feature may also be realized through an RTP translator. VNAT with MIPv6 [19] and Delegated IP (DIP) [16] are the first attempts to bring the user-centric paradigm into the network layer. They let applications use the same address even when a migration between terminals occurs; this is possible by introducing inter-layer mechanisms to convert a virtual invariable address (seen by the applications) into the current network address (used on the current link). The translation is necessary at both the local nodes (where the migration happens) and the correspondent node. Both protocols are built upon a MIPv6 architecture; VNAT makes use of the concept of network address translation to convert between virtual and current addresses, whilst DIP modifies the Return Routability procedure of MIPv6. The virtual address used by applications is the address of the terminal where the session initially started; after the migration, the same address is used concurrently by applications running on different hosts and that may lead to wrong or unexpected behavior. In VNAT, port number conflicts are possible at the correspondent host, whether the latter should try to set up another session before the previous be closed [41] (this is quite likely, as each application usually uses the same port numbers). In DIP, the correspondent host cannot reach the local host for the whole duration of the migration because of a route update towards the target node (see [16] for protocol details).

Multimed Tools Appl

VNAT requires its framework to be present in the correspondent node as well and does not manage the simultaneous movement of the two endpoints. On the other hand, DIP only permits one single migration per session; moreover DIP violates the usual division in layers, as it requires the network entities to inspect packets for higher-layer information (i.e., source and destination ports), and this increases the complexity of the solution.

4 A user-centric mobility framework Despite the large numbers of protocols available for mobility management, a general and all-inclusive framework cannot be found in the literature. Indeed, SIP has a very good and complete mobility framework, but it has three main drawbacks: (i) it only works for SIP-controlled applications, (ii) it is not integrated with link- and networklayer mechanisms to detect link failures and (iii) it requires both peers to implement the framework. We pursue a new approach to the problem, which builds a unified framework for mobility management around the main principles and paradigms of the user-centric vision. The key aspects of our work can be summarized in the following items: • • • •

exploiting a common set of functionalities to manage both terminal handover and session migration; working mostly at the network layer to improve efficiency and versatility, requiring only minimal modifications to applications; maintaining compatibility with the current Internet infrastructure; binding communication sessions to users instead of devices, in order to make mobility transparent to correspondent entities.

Basically, we assign network identifiers (addresses) to users; these identifiers will then be used by applications on behalf of the user for networking issues. That means correspondent entities see the same endpoints (users’ identifiers) for the whole session duration, despite the network and/or the device may change. This approach extends the principles behind VNAT and DIP; however, users use their own identifiers instead of the device’s address, so we can overcome the main limitations of these two approaches. 4.1 The concept of Personal Address The core of our framework is the concept of Personal Address [25], i.e. a network identifier dynamically assigned to a user for a specific communication session.1 Any kind of network identifier may be suitable for this purpose (e.g., IP or HIP [22] addresses); at present, we focus on IP addresses in order to deploy our framework in the current Internet. In addition, mnemonic identifiers can be used at higher layers, similarly to what happens for SIP URI.2

1 The

same concept could also be extended to content in the context of Content Centric Networking; we are going to face this topic in the future.

2 Actually,

the user identifier may be a structure including information for different networks (see, for example, Chapter 15 in [17].)

Multimed Tools Appl Fig. 6 The Personal Address framework

Internet

Correspondent

Figure 6 depicts the basic idea behind the PA concept. The user is assigned a network identifier (the IP address 1.1.1.1 in this example), this address is used to manage multimedia content (like a VoIP session) on a small portable device (for example, a handheld), independently of user movements across different networks (dash and dot arrows). The same network identifier continues to be used when the session is transferred to a different device, for example a television with a bigger monitor (dash arrow). The correspondent node involved in the session sees at any time the same address, independently of the user movements and the devices used. Any migration (handover or session transfer) is transparent to remote applications and these are not required any specific functionality. This is one of the main assets of the PA scheme. According to the definition, the PA is specific for each communication session; that prevents the risk of having address/port conflicts in case the user set up multiple sessions with the same correspondent node. The user shall unlikely set up more than one multimedia session at a time, and the addresses are dynamically assigned, thus the use of a different address for each session should not be a limitation for our scheme.3 4.2 The mobility framework Several functions are needed to build a mobility framework around the concept of Personal Address. Figure 7 depicts its architecture. It exploits a cross-layer approach that mostly works at the network layer, because handover is most effective at this layer; however, some operations are still necessary at the application layer to manage the PA and to migrate the session context. The PA Management function retrieves a PA for the current user and makes it available to applications. This address appears as a network interface, so it can be used through the standard socket API. Our approach only allows a single application to bind to the PA; if more concurrently applications are running, more PAs are needed. However, this limitation has little practical importance, as mobility management (especially session migration) is most meaningful for multimedia applications and the user hardly may be able to use more than one of these sessions at a time.

3 The

idea of using a fixed IP for each user is not feasible in IPv4, which currently lacks addresses for devices, although it would be possible in IPv6. However, to maintain the approach as general as possible, we keep in mind the limitations of IPv4 and think at the PA as a dynamic address.

Multimed Tools Appl Fig. 7 The architecture of the user-centric mobility framework based on the Personal Address

Terminal 1

PA

Terminal 2

Network

PA

PA Management Application

Migration

Adaptation

Transport Network

Handover Handover Handover

Delivery

The PA is independent of the current access network, so the Delivery function has to locate the current user’s terminal and to take care for delivering packets to it. When the terminal moves to another network or the session is migrated to another device, the network address associated to the PA changes, and the Delivery function redirects packets towards the new location. The Handover task detects when the terminal moves to another network and manages the handover procedure. Movement detection can be done by listening for L3 advertisements (for example, from Foreign Agents in MIP or from routers in MIPv6), by L2 triggers (link down, link up and similar) and by physical measurement (signal-to-noise ratio, received signal strength, bit error rate, etc.). Depending on the detection mechanism available, handover can be handled in a proactive (makebefore-break) or reactive (break-before-made) way. The Migration function moves the user’s PA and the application context from one terminal to another in case of session migration. From a network perspective, there is no difference in the behavior of the Delivery function with respect to a terminal handover: in both cases, the PA must be associated to a new terminal’s address, no matter if the terminal remains the same or changes. Thus, the Handover function is also used for session migration. Multimedia traffic is usually transported by the Real-time Transport Protocol (RTP) [35] in UDP packets. RTP is directly controlled by applications, so its state can be included in their context and transferred by Migration; UDP is a stateless protocol and does not require any specific operation in case of mobility. However, sometimes multimedia sessions involves TCP (this often happens for signaling or for content transfer by the HTTP protocol), which is a stateful protocol; the TCP-Migration function takes care of migrating TCP connections in case of session migration. The migration may involve heterogeneous devices or even different implementations of the same application. In order to preserve transparency for the correspondent peer, the network should also provide an Adaptation function, which adapts the session to the new device (codec, framerate, aspect ratio, etc.). The concept of PA and the structure of the mobility framework lead to three great advantages with respect to previous works (i.e., VNAT, DIP). First, the device-independent nature of the address enables an arbitrary number of migrations. Second, the presence of a Delivery function in the network also makes it possible

Multimed Tools Appl

to account for simultaneous mobility of both peers. Third, correspondent nodes are completely unaware of any mobility issue.

5 Implementation of the mobility framework in the current Internet The framework described in Section 4 describes a set of abstract components which form a mobility infrastructure around the concept of Personal Address. It voluntarily does not mandate any specific mechanism, in order to be very general and technology-agnostic, so it can be used with different networking architectures. We built our own implementation in the current Internet to prove the feasibility and the substance of the framework and to carry out quantitative and qualitative evaluation. As of the cross-layer architecture, our software is made of common functions for all applications (network and transport layers) and application-specific extensions for meaningful multimedia protocols (i.e., SIP and RTSP). 5.1 Common functions The Handover and Delivery functions discussed in Section 4 need to address the following issues: • • • •

binding the user’s PA with the current device (especially its network address); forwarding packets towards the user’s current device; handling network and/or device changes at the user side; updating the forwarding process at the network side when the migration occurs.

There is no need, at least at this stage, to think at entirely new mechanisms for the Handover and Delivery functions; three alternatives are already available that manage topological-independent network addresses: multicast, anycast and Mobile IP. Multicast [23] provides an architecture to deliver packets to IP addresses (class D) that do not lie on the same network; unfortunately, at present multicast infrastructures are available only within few administrative domains. Anycast [26] uses the same unicast IP address for multiple hosts, delivering packets only to one of them through standard routing mechanisms. However, routing is known to be slow to converge and the user client would unlikely be allowed to propagate its own routing information. Mobile IP (MIP) [27] enables mobile nodes (MNs) to use a fixed network address (the Home Address, HoA) independently of their location. It only requires a minimal infrastructure: one Home Agent (HA), owned by the user himself or some

Home Agent

Foreign Agent Mobile Node

Foreign Network Correspondent Node

CoA Home Network

Fig. 8 The basic operations of Mobile IP

HoA

Multimed Tools Appl

a) Before the migration Foreign Network 170.0.0.0/16 Correspondent Node

Foreign Agent

Mobile user 200.0.0.25

170.0.0.10 Home Agent 200.0.0.1

HoA CoA

Home Network 200.0.0.0/24

170.0.0.1

b) After the migration Foreign Network 12.12.0.0/16 Foreign Agent 12.12.0.15 HoA CoA

Mobile user 200.0.0.25

12.12.0.1

Fig. 9 The implementation of the core functions of the mobility framework

service provider, and optional Foreign Agents (FAs) in local networks for the sake of improving performance (indeed, they are only needed for IPv4 networks). Moreover, it is transparent for Correspondent Nodes (CNs). MIP includes security mechanisms to prevent most attacks concerning flow redirection and spoofing. MIP is a suitable solution for our framework, at least for a first implementation. Figure 8 depicts the basic MIP operations when the MN (200.0.0.25) is currently out of its Home Network (200.0.0.0/24). In this situation, it uses a registration procedure to notify the HA about its current location in terms of a Care-of Address (CoA, 170.0.0.10), which is an address congruent with the topology that is used for communication by the MN. The standard routing mechanisms route packets addressed to the MN towards its Home Network. Here, packets are captured by the Home Agent; this is possible because it answers to ARP Requests on behalf of the MN with its own MAC address. The HA then forwards packets to the MN via a tunnel ending at the CoA. The CoA can be either the address of a local Foreign Agent (FA-CoA, as the case shown in Fig. 8) or a temporary address assigned to the MN (Co-locate CoA, CoCoA); in both cases, packets finally reach the MN (see [14, 27] for details about MIPv4/6). The MIP framework provides all components to build the Handover and Delivery functions: the MIP client (i.e., software running on the MN) accomplishes the tasks required by Handover, the HA and FA cope with the job of Delivery and the PA is used as HoA. As a matter of fact, MIP was developed for terminal mobility, but its framework does not require the registration to be updated by the same host. We exploit this consideration to update the Delivery function from a different host in case of session migration;4 from the Home Agent perspective, this appears as a standard terminal migration, thus packets are redirected to the new terminal. Figure 9 sketches the use of the MIP infrastructure for session migration; note that the FAs are not mandatory and the CoA may be the address of the user’s devices (CoCoA).

4 Obviously,

the hosts migrating the session must share the same secret material requested by MIP security mechanisms.

Multimed Tools Appl

The last common function in our framework is TCP-Migration. It is only needed for applications relying on connection-oriented services from the transport layer; we have not still taken into account this issue in our implementation. 5.2 Application-specific functions The PA Management, Migration and Adaptation functions must be integrated into applications. The PA Management function offers applications a network interface configured with the PA. In our first implementation, we simply add the PA to the existing network interface of the device; future releases will provide a virtual adapter which uses the best physical interface available. The PA Management function consists of four tasks: • • • •

acquiring the Personal Address; setting up the Personal Address on the network interface; saving, transferring and restoring the application context; removing the Personal Address from the network interface.

Adding or removing an IP address to a network interface (the second and fourth tasks) is a trivial task and can be done by the network APIs of the operating system. A generic and common protocol may be designed to accomplish the first and third tasks; however, in the current implementation we exploited the application’s specific framework.5 It is worth noting the four tasks must be triggered by the application in any case. The Adaptation function may be located at the Home Agent, because all traffic is forced to cross that point. Indeed, our focus was mainly on the mobility infrastructure, so we did not consider either any solution nor implementation for this element. Two multimedia protocols were taken into account in our implementation, accounting for two different communication paradigms: SIP for real-time interactive sessions among users and RTSP for real-time content streaming. In the following, we describe the addition we made to these signaling protocols in order to use the proposed mobility framework. 5.2.1 Interactive multimedia sessions The SIP architecture uses Proxy and Registrar servers to manage personal mobility; for the sake of simplicity, we co-located these functions with the Home Agent. Personal Addresses are taken from the Home Network address space and dynamically assigned by the Proxy as detailed in the following. Figure 10 shows the signaling flow for setting up the session and for migrating it from terminal T1 to terminal T2 (see [32] for details about SIP signaling). First, let us consider the called is a mobile user. The Correspondent Node (CN) initiates the session with an INVITE message, then the Proxy appends a PA to that message and forwards it to the user’s device (T1). The user client reads the PA extension in the message and starts the mobility framework; this means the PA is

5 We

will consider the possibility of designing an independent protocol in our next releases.

Multimed Tools Appl Fig. 10 SIP signaling for session setup and migration in the mobility framework

CN

T1

Proxy Server

PA Management

INVITE

T2

INVITE+ MIP up

PA MIP Registration RegReply OK

OK ACK RTP

Notification

RTP

REFER INVITE+ +Migrate OK

Migration

202 DeRegistr. DeRegReply MIP down

ACK

PA Registration RegReply

RTP

PA

MIP up

RTP

added to the network interface and the MIP client registers the current CoA for that address (FA- or Co-CoA). From now on, the SIP user agent begins to use the PA just set up and all signaling and media are routed through the Home Agent. If the caller (also) were a mobile user, its client would need to get a PA before initiating the session. That is possible by a REGISTRATION message including a “GetPA” extension: on receiving such message, the Proxy allocates a PA and returns it in the OK response. The user client then starts the mobility framework and begins the session by using the PA just set up. The migration to a new terminal (T2 in Fig. 10) can be manual or automatic; in both cases the first operation is to notify the Proxy. Manual transition may happen in different ways: the user simply logs into the new terminal, or he chooses the new terminal either by the current one or by an external device (Control Point); the notification to the Proxy consists of a REGISTRATION message, carrying the address of the new terminal. Automatic migration requires a Context Server that tracks the user movements, for example by means of external sensors; the Proxy has previously subscribed with that server to be notified every time the user moves and gets close to a new device (SIP provides SUBSCRIBE/NOTIFICATION messages).

Multimed Tools Appl Fig. 11 RTSP signaling for the migration of the PA in “pull” mode

T1

HA

Server

T2

Media

Migration trigger

MIGRATE PAUSE OK

MIP down

Migration

PA

OK (session status) MIP up

PA Registration RegReply PLAY (URL,sid) OK Media

Once the Proxy is informed about the need for a migration, it sends a REFER message to the previous registered device; if there is an active communication session, an INVITE/OK/ACK exchange is started to transfer the current session context to the new terminal T2. During this phase, the MIP client is stopped on T1 (after the OK is received) and the PA is removed from its network interface; then it is used by the MIP client instance on T2 (after the ACK message). That updates the location of the PA inside the network; this sequence of operations avoids the contemporaneous use of the address on the two terminals. Note that the remote peer is completely unaware of the migration procedure as the IP address used in the session has not changed.6 5.2.2 Streaming applications In a typical streaming application there are a Streaming Server (SS) and a multimedia client. The mobility framework runs on the client. The PA may be learned from the user profile (no RTSP intermediate is expected in this scenario); it is added to the network interface and MIP registers the current device/FA address as the CoA. Once the PA is ready, the application binds to the local PA and initiates RTSP signaling in the standard way. When the user wishes to migrate the session to another terminal, the application saves the current session status (e.g., PA used, SDP description, user profile and preferences, application-specific information). The migration can happen in both a “pull” or “push” way. In pull mode the migration process is initiated by the new terminal with a MIGRATE request (see Fig. 11); the old client pauses the media, then it stops the MIP operations and tears the PA down; finally, it answers the MIGRATE request with an OK response that includes the current session status. At this point, the new terminal adds the PA to its network interface, updates the

6 The

two local terminals may have different capabilities. The presence of the Adaptation on the Home Agent would take care of adaptation and transcoding, if needed.

Multimed Tools Appl

MIP registration with the new CoA and issues a PLAY command. In push mode the migration is initiated by the old client: it pauses the stream, removes the PA, and then it sends a MIGRATE request with the session description. The new terminal answers with an OK and then performs the same operations as in the previous case. The two operation modes are needed to account for two different schemes of migration control, either manual or automatic. In manual mode, users are likely to log into the new terminal and thus pull mode is the natural choice; in automatic mode, the old terminal subscribes with an external Context Server and gets notified about the movement, thus push mode is more suitable. Our scheme extends the RTSP protocol with a MIGRATE message. The server is not required to support pausing; in this case the stream is not suspended and some frames of video will be lost. That could be acceptable for a live streaming content. As a final remark, we note that without a TCP-Migration function the server is only required to keep the session alive if the client breaks the TCP connection for a while during the migration; on resuming, the new client reconnects using the same TCP pair. If a TCP-Migration is available, there is no need to break the connection with the RTSP server and so this correspondent node will not experience any change at all. 5.3 Software architecture and libraries Figure 12 shows the software architecture of our implementation. On the left side, there is the architecture of user’s applications (it is common for both of our examples), while on the right side that one of the SIP Proxy. All other elements depicted in Figs. 10 and 11 do not require specific mobility features. We built two simple applications for Windows platforms: the one to handle VoIP calls, the other to play video streams. We exploited the .NET framework and

User interface

Renderer

User application

Application core

SIP proxy Registrar

Mobility Service

PA/Context Manager Communication protocol

Proxy core

Transport

Network

Context Sensors

PA

(a) User’s device

Mobile IP Client

Mobility Manager Home Agent

SIP protocol

(b) SIP proxy server

Fig. 12 The software architecture for the user-centric mobility framework

Multimed Tools Appl

integrated several libraries for SIP and RTSP signaling, for acquisition and rendering of media streams and for the graphical interface. The Mobility Service is a Windows service that implements the Handover function and all operations of PA Management and Migration concerning network issues (add/remove addresses to the network interfaces). The interface of the Mobility Service is very simple and only exports two methods: “Start” is used to notify the Handover function about the PA to be used and to begin MIP operations (i.e., registration of the current CoA); “Stop” is used to remove the PA from the network interface (de-registration of the CoA is strictly required only if the session has to be closed). The MIP client was written from scratch, as no working opensource implementation was available for Windows platforms; it conforms to the MIP specification. For the sake of simplicity, the Proxy, Registrar and Home Agent were integrated into a single component, named as Proxy. The Proxy exploits the reSIProcate7 library for SIP operations; we developed a Mobility Manager library to deal with PA assignment and session migrations. For what concerns the first task, the library manages a set of Home Addresses, which are assigned as Personal Addresses when requested. For what concerns the second task, the Proxy notifies the current terminal of the requested migration with a REFER message (as shown in Fig. 10). The MIP implementation for the agents was derived from the Dynamics project,8 but optimized for performance and speed during the migration process. In our software architecture we also account for external context information to drive the migration. This is useful to automate the process, for example by tracking the user position. Finally, the standard RTSP server provided by the VLC9 application was used for video streaming. Currently, all our software works on IPv4 networks.

6 Performance analysis and user evaluation The software implementation described in Section 5 was used both on a local testbed and on the real Internet. Our work was devoted to assess the feasibility and correctness of the mobility framework and to carry out performance analysis, in order to extract useful indication for future development. Our evaluation only focuses on session migration; indeed, the behavior for terminal handover is the same as standard MIP, which has been largely analyzed and compared with other protocols in the past [21, 24]. Session migration is a network feature that is not transparent to users: often terminals may not be next to each other, and the user may spend some time to move between them, or just to turn his head or his body towards the new terminal. This means a short delay in the migration may be tolerated, unlike in case of terminal handover; unfortunately, there is no way to give an objective bound for this delay. This consideration motivates our choice of having both a quantitative and a qualitative

7 http://www.resiprocate.org 8 http://dynamics.sourceforge.net/ 9 http://www.videolan.org/

Multimed Tools Appl Proxy/HA

Blue site

CN/SS

FA T1

Internet

Proxy/HA

Red site

CN/SS FA FA

T1

T2

a) Local testbed

T2

Green site

b) Internet testbed

Fig. 13 The structure of the local and Internet testbeds. Several scenarios can be generated in the Internet testbed by placing the elements at different locations

analysis; the latter was conducted by setting up a live demo with potential users and getting back their feedback about the technology. With regard to quantitative analysis, comparison with alternative mobility schemes would be meaningful, especially with respect to other user-centric schemes, namely SIP, VNAT and DIP. Unfortunately, VNAT and DIP are quite complex and no public implementations are available.10 Currently, we are working to integrate the migration schemes supported by SIP (namely 3PCC and SH) in our software implementation. For what concerns RTSP, no alternative migration mechanisms are available, so we enrich our analysis by taking into consideration two variants of our migration procedure, with or without the PAUSE message. 6.1 Performance analysis Performance evaluation took into consideration two different network testbeds, indicated as “local” and “Internet” (see Fig. 13). The local testbed was mainly used for functional tests, in order to evaluate the impact of the mobility framework on the multimedia sessions. In this testbed, two terminals (T1 and T2) and one Foreign Agent were located on the same 100 Mbps Ethernet LAN. The FA also acted as a router and had a direct connection to the Home Agent (which includes the SIP Proxy/Registrar Server). The Correspondent Node (CN) and the Streaming Server (SS) were one hop away from the HA; these connections were 100 Mbps Ethernet as well. Three different sites were used in the Internet testbed; we will refer to them as the Red, the Green and the Blue site, as depicted in Fig. 13. The Blue site was connected to the Internet through an ADSL connection having downlink/uplink bandwidth up to 20 Mbps/512 kbps, while the Green and the Blue were two ADSL sites with downlink/uplink bandwidth up to 7 Mbps/384 kbps. The mean round trip times measured between the couples of sites during the trials were: 78 ms (Red– Blue), 363 ms (Green–Blue) and 634 ms (Red–Green). Performances in the Internet testbed depend upon the relative placement of clients and network servers. We distinguished seven representative topologies by placing the main elements of our framework into different sites, as reported in

10 No

evidence of any experimental setup are even found in [16, 19].

Multimed Tools Appl Table 2 Scenarios for the Internet testbed

Proxy HA CN/SS T1 T2

1A

2A

3A

3C

1B

2B

3B

B B B R R

B R B R R

B B G R R

B B R R R

B B B R G

B R B R G

B B R R G

Table 2. In the “A” group of topologies, T1 and T2 both lied in the Red site; the “B” group was characterized by session migrations which occurred between the Red and the Green sites; the “3C” topology consisted of a mixture of the “3A” and the “3B” ones. The two clients ran different versions of the Windows operating system, i.e., Windows XP and Vista. The presence of two different OSs allows to verify their impact on the whole framework, as we rely on OS APIs for setting up and removing IP addresses on network interfaces. The tests consisted in setting up a multimedia session between T1 and CN and then migrating that session back and for between T1 and T2. All the experiments (both in the local and in the Internet testbeds) were conducted during normal daily activity, so we could take into account realistic network conditions. 6.1.1 VoIP application Two users are involved in VoIP applications; we indicate the user who migrates his session as “local user” (or simply “user”), whilst the user at the corresponding node is called “correspondent user” or “remote user”. We distinguish three phases during the migration, namely “MIP”, “Migration” and “Shift”. The “MIP” phase is the time taken by MIP signaling to perform the registration of the current CoA; it consists of the Registration Request and Registration Reply messages that are exchanged between the local client (T1 or T2) and the HA. The “Migration” phase is the time elapsed between the indication to perform the migration and the redirection of the media flow to the new local terminal (see Fig. 10); this measurement does not include the MIP phase. However, the multimedia session is composed by two unidirectional media flows, i.e. the video from the local terminal and the video from the remote terminal. The first has to be interrupted and resumed at the new device, while the second is redirected towards the new destination by the mobility infrastructure. As a matter of fact, these two operations take a different amount of time to complete and so the rendering of the video after the migration starts at different time instants. This desynchronization can affect the user interaction: for example, if the local user sees his correspondent in the new terminal, he believes that the same happens on the remote side, but that might not be true. We take into account this effect at the local terminal after the migration by measuring the delay between the first video packet sent and the first one received from the CN; this measure is indicated as “Shift”. Figures 14 and 15 show the results we obtained in the local and Internet testbeds, respectively. The operations of the mobility framework marginally affect the procedure of call set up (see Fig. 10), thus we also take into account this phase in our analysis.

Multimed Tools Appl 2 Shift Migration MIP

Session Migrations

Duration [sec.]

Fig. 14 Mean delay of session setup and migration (from Vista to Windows XP and vice versa) over a local network

1

0

tup

Se

ta

Vis

>>

XP ta

Vis

> a V >> a >> > V a a t t t t Vis Vis XP XP Vis Vis XP XP

8 7 6 5 4 3 2 1 0

up W W /o Se tu p W W /o Se tu p W W /o Se tu p W W /o Se tu p W W /o Se tu p W W /o Se tu p W W /o

Video Play MIP Pause

Se t

Fig. 17 Mean delay over the real Internet for session setup (Setup) and migration with (W) and without (W/o) pausing

Duration [sec.]

were equipped with Windows XP and Vista as operating systems. The migration procedure worked well in all scenarios (push and pull mode, with and without pause); the whole migration process required less than one second. The signaling needed to pause and to resume the media brings most of the latency for the migration; the MIP signaling entails negligible delays (about 2–3 ms) with respect to the other three phases (about 100 ms for “Pause”, 200–470 ms for “Play” + “Video”). When the media is not paused, the “Video” phase mostly consists of the time taken to remove the PA from the old interface and to set it up on the new interface; this takes approximately 170 s. We can approximately assume about an equal amount of time is needed to configure the PA during the initial set up of the stream: it only represents about one half or one third of the “Play” phase. We should also notice that most of the time for the setup is devoted to wait for the video: that is probably due to the time needed by the server to start the streaming session. Thus, as the setup lasts about 2 s, we can conclude that the migration framework has a minimal impact (about one tenth). The results obtained in the Internet testbed are reported in Fig. 17. Here we can see a similar behavior to the previous situation, although the migration phase raises up to several seconds. That is due to the low bandwidth of the ADSL links with respect to the LAN, and to the presence of exogenous traffic from other users/hosts. In the most unfavorable scenarios, the migration takes about 7 s with pause and 3 s without pause; indeed, most of the delay concerns the “Play” and “Video” phases when the media is paused, and it is likely due to the internal operations of the media server. Although the MIP signaling also requires more time with respect to the local

1A

2A

3A

3C

1B

2B

3B

Multimed Tools Appl

T1

Sensor Network

SUBSCRIBE Proxy Server

NOTIFY

Context Server

Gateway

T2

Fig. 18 The integration of user localization into the mobility framework

testbed as of the distance between the clients and the HA, it again has a minimal impact on the overall procedure. As a final remark, we observe that pausing the media is indeed not necessary in local environments: the migration is so fast that the disruption in rendering is not noticeable (that was confirmed by the real experience during the evaluation); however, when the devices lie in different networks, pausing the media could avoid an annoying gap in media continuity. 6.2 Live demo and user evaluation Measurements in the Internet testbed gave us migration delays of several seconds. Even if we consider the 7-s delay for RTSP with pause as endogenous in the VLC media server, we must be aware that on average we can have up to 3–3.5 s of delay. However, as we have already pointed out, performance evaluation in terms of rough numbers may not be representative of the user feeling with such a system, mainly because users may have to move or to do something during the migration. Indeed, as we are pursuing a user-centric architecture, we are very interested in getting feedback from people. We worked towards this direction by setting up a live demo at an Italian national science exhibition, named “Science Festival”11 and held in Genoa on 23 October–1 November 2009. It was attended by a large number of both professional and non-professional visitors, with different education degree and age, thus making it an ideal place to meet a full range of potential users. Indeed, we only stayed at the Festival two days and got feedback from 101 users. We chose the VoIP application for the live demo, as it can be used by two users at a time. We enhanced our mobility infrastructure with user location by sensor networks, in order to make the migration fully automatic [3]. Figure 18 depicts the new architectural elements and the additional signaling. A couple of sensors are present near each user’s terminal, one sensor is carried by the user and one sensor acts as a gateway to the Context Server. This last element computes the device closest to the user by RSSI measurements from the sensor network; this information is sent to the Proxy Server that has previously subscribed such kind of service. SIP provides two methods for this purpose, namely SUBSCRIBE and NOTIFY12 [32].

11 http://www.festivalscienza.eu 12 Both

methods require a response, although it is not shown in Fig. 18.

Multimed Tools Appl Fig. 19 Statistics about age and sex of interviewees

30

Female Male

25

% of users

20 15 10 5 0 Under 14

15–19

20–30

31–50

Over 51

Age

During the demo, one user sat down at a “fixed” device (not shown in Fig. 18) and the other one sat down at the first terminal (T1 in Fig. 18). After setting up the call, the user at T1 was asked to move to the other terminals (T2 in Fig. 18) and it could see his session which moved between the terminals without him have to do any action. He usually moved back and for between the two terminals several times, in order to better assess his feeling with that feature. Users were asked to compile a questionnaire after they had tried the demo; questions were prepared with the support of a psychologist and took into account background skills, familiarity with technology, personal assessment of the system, social impact of this kind of technology. We collected 101 questionnaires; we could not find any significant difference between the feedback got from the 53 males and the 48 females. Visitors were mostly students under 24 years old. Figure 19 shows the number of people grouped by age and sex (all of them were above 11 years old). The whole migration framework looked quite innovative to users: 87 people had never seen anything similar. Using an evaluation rating from 1 (lowest) to 5 (highest), users liked a lot the possibility of migrating content (4.49 on average), they found it easy to use (4.02 on average) and they thought it is useful in everyday life (4.05 on average). About performance, they found the migration quick and

Table 3 General feedback from users

Scores range from 1 (lowest) up to 5 (highest)

Familiarity with technologies Satisfaction with migration Easy of use Usefulness Speed of migration Worth (willingness to spend money)

Mean score

St. dev.

3.92 4.49 4.02 4.09 4.16 3.87

0.74 0.75 0.72 0.68 0.75 1.14

Multimed Tools Appl Fig. 20 Where users would be willing to get located

80 70

# of users

60 50 40 30 20 10 0 d

On

roa

the

At

rk

wo

At

me

ere

wh

ho

No

timely (4.16 on average). Finally, from an economic point of view, most of them (84 persons) would even be willing to pay a small amount of money to use it. Table 3 summarizes the mean value and standard deviation about this general feedback from users. The high score about performance confirms that a delay of few seconds is tolerable by users. Large network latency, low bandwidth links and congestion will likely degrade the user experience, but this is an issue for multimedia transmission over the Internet, not only for our migration framework. The live demo proposed automatic migrations based on localization of users by sensor networks. However, not all people are available to be tracked everywhere (see Fig. 20); moreover, they often prefer taking over the migration process (see Fig. 21). Really, we should be aware that migration triggers to our mobility framework may come from heterogeneous sources.

Fig. 21 How users would like to control the migration

30

# of users

20

10

0 ion

nit

ic Vo

e

og rec

r

stu

Ge

er

ion

nit

g eco

nd

Ha

e

on

ph

d/ hel

Bu

tto

n no

ion

zat

ali

oc ic l

at

tom

Au

e vic

de

Multimed Tools Appl

7 Conclusions In this paper the user-centric paradigm has been implemented in a mobility framework dealing with terminal handover and session migration. This framework exploits a cross-layer architecture, which brings together efficiency at the network layer with flexibility at the application layer. The other important benefit of this framework is transparency for unaware correspondent applications. A working implementation has been proposed to prove the feasibility of the framework. Two applications have been considered as examples of applicability: interactive conversation and real-time streaming. Both of them were deployed in an evaluation testbed. Preliminary performance evaluation has shown the feasibility of the framework. Part of the testbed has been integrated with a Context Server in order to automate the migration process; it was shown at a national exhibition to get user feedback. Both the numerical analysis and the feedback from users have demonstrated the meaningfulness of our approach. Future work will be addressed to strengthen the performance analysis with more rigorous evaluation on the Internet, to compare the framework with other existing protocols (mainly the 3PCC and SH schemes of SIP), to derive an analytical model for the evaluation of the impact of different network topologies and to introduce new mobility functions in order to overcome the current limitations of the MIP protocol. Acknowledgements The authors would like to thanks Stefano Chessa and his staff at the Institute of Information Science and Technologies (ISTI) of the Italian National Research Council (CNR) in Pisa for their invaluable help in providing the localization by the sensor network framework used in the live demo. The authors would also like to thanks the psychologist Ludovica Primavera for her assistance in preparing and analyzing the questionnaires for the user evaluation.

References 1. Banerjee N, Wu W, Das SK, Dawkins S, Pathak J (2003) Mobility support in wireless Internet. IEEE Wirel Commun Mag 10(5):54–61 2. Banerjee N, Acharya A, Das SK (2006) Seamless SIP-based mobility for multimedia applications. IEEE Network 20(2):6–13 3. Bolla R, Rapuzzi R, Repetto M, Barsocchi P, Chessa S, Lenzi S (2009) Automatic multimedia session migration by means of a context-aware mobility framework. In: The international conference for mobility technology, applications and systems (ACM Mobility Conference 2009), Nice, France, 2–4 September 2009 4. Brännström R, Kodikara R, Åhlund C, Zaslavsky A (2006) Mobility management for multiple diverse applications in heterogeneous wireless networks. In: 3rd IEEE consumer communications and networking conference (CCNC 2006), Las Vegas, Nevada, USA, 8–10 January 2006, pp 818–822 5. Campbell AT, Gomez J, Kim S, Wan C-Y, Turanyi ZR, Valko AG (2002) Comparison of IP micromobility protocols. IEEE Wirel Commun Mag 1(2):72–82 6. Chen M-X, Peng C-J, Hwang R-H (2007) SSIP: split a SIP session over multiple devices. Comput Stand Interfaces 29(5):531–545 7. Dutta A, Madhani S, Chen W, Altintas O, Schulzrinne H (2004) Fast-handoff schemes for application layer mobility management. In: 15th IEEE international symposium on personal, indoor and mobile radio communications (PIMRC 2004), Barcelona, Spain, 5–8 September 2004, vol 3, pp 1527–1532 8. Eddy WM (2004) At what layer does mobility belong? IEEE Commun Mag 42(10):155–159 9. Fogelstroem E, Jonsson A, Perkins C (2007) Mobile IPv4 regional registration. RFC 4857. [Online]. Available: http://www.ietf.org/rfc/rfc4857.txt. Accessed 6 June 2011

Multimed Tools Appl 10. Giordano S, Lenzarini D, Puiatti A, Vanini S (2005) WiSwitch: seamless handover between multi-provider networks. In: Second annual conference on wireless on-demand network systems and services (WONS 2005), St. Moritz, Switzerland, 19–21 January 2005, pp 224–235 11. Hasegawa M, Morikawa H, Inoue M, Bandare U, Murakami H, Mahmud K (2003) Cross-device handover using the service mobility proxy. In: Proceedings of 6th international symposium on wireless personal multimedia comunications (WPMC2003), Yokosuka, Japan, vol 2, pp 357–361 12. Henderson TR (2003) Host mobility for IP networks: a comparison. IEEE Network 17(6):18–26 13. Henderson TR, Ahrenholz JM, Kim JH (2003) Experience with the Host Identity Protocol for secure host mobility and multihoming. In: Wireless communications and networking (WCNC 2003), New Orleans, LA, USA, 20 May 2003, vol 3, pp 2120–2125 14. Johnson D, Perkins C, Arkko J (2004) Mobility support in IPv6. RFC 3775. [Online]. Available: http://www.ietf.org/rfc/rfc3775.txt. Accessed 6 June 2011 15. Jung J-W, Mudumbai R, Montgomery D, Kahng H-K (2003) Performance evaluation of two layered mobility management using Mobile IP and Session Initiation Protocol. In: IEEE global telecommunications conference (GLOBECOM ’03), San Francisco, California, USA, 1–5 December 2003, pp 1190–1194 16. Kohn R (2008) Delegated IP: a Mobile IPv6-based protocol to support session delegation. In: IEEE international conference on communications (ICC’08), 19–23 May 2008, pp 3279–3285 17. Kumar V, Korpi M, Sengodan S (2001) IP telephony with H.323. Wiley, New York 18. Le D, Fu X, Hogrefe D (2006) A review of mobility support paradigms for the Internet. IEEE Commun Surv Tutor 8(1):38–51 19. Lu W, Lo A, Niemegeers I (2005) Session mobility support for personal networks using Mobile IPv6 and VNAT. In: 5th workshop on applications and services in wireless networks (ASWN’05), Paris, France, 29 June–1 July 2005 20. Maltz DA, Bhagwat P (1998) MSOCKS: an architecture for transport layer mobility. In: Proceedings of the 17th annual joint conference of the IEEE Computer and Communications Societies (INFOCOM’98), San Francisco, California, USA, 29 March–2 Apr 1998, vol 3, pp 1037–1045 21. Montavont N, Noël T (2003) Analysis and evalutation of Mobile IPv6 handovers over wireless LAN. Mob Netw Appl 8(6):643–653 22. Moskowitz R, Nikander P (2006) Host Identity Protocol (HIP) architecture. RFC 4423. [Online]. Available: http://www.ietf.org/rfc/rfc4423.txt. Accessed 6 June 2011 23. Mysore J, Bharghavan V (1997) A new multicasting-based architecture for Internet host mobility. In: Proceedings of the 3rd annual ACM/IEEE international conference on mobile computing and networking (MobiCom’97), Budapest, Hungary, pp 161–172 24. Nakajima N, Dutta A, Das S, Schulzrinne H (2003) Handoff delay analysis and measurement for SIP based mobility in IPv6. In: IEEE international conference on communications (ICC ’03), Anchorage, Alaska, USA, 11–15 May 2003, vol 2, pp 1085–1089 25. Niemegeers IG, Groot SMHD (2003) Research issues in ad-hoc distributed personal networking. Wirel Person Commun 26(2–3):149–167 26. Partridge C, Mendez T, Milliken W (1993) Host anycasting service. RFC 1546. [Online]. Available: http://tools.ietf.org/rfc/rfc1546.txt. Accessed 6 June 2011 27. Perkins C (2002) IP mobility support for IPv4. RFC 3344. [Online]. Available: http://www. ietf.org/rfc/rfc3344.txt. Accessed 6 June 2011 28. Politis C, Chew KA, Tafazolli R (2003) Multilayer mobility management for all-IP networks: pure SIP vs. hybrid SIP/Mobile IP. In: The 57th IEEE semiannual vehicular technology conference (VTC 2003-Spring), Jeju, Korea, 22–25 April 2003, vol 4, pp 250–2504 29. Ramjee R, Varadhan K, Salgarelli L, Thuel SR, Wang S-Y, Porta TL (2002) HAWAII: a domainbased approach for supporting mobility in wide-area wireless networks. IEEE/ACM Trans Netw 10(3):396–410 30. Reinbold P, Bonaventure O (2003) IP micro-mobility protocols. IEEE Commun Surv Tutor 5(1):40–57 31. Riegel M, Tuexen M (2007) Mobile SCTP. Internet draft, expired. [Online]. Available: http://tools.ietf.org/html/draft-riegel-tuexen-mobile-sctp-09. Accessed 6 June 2011 32. Rosemberg J, Schulzrinne H, Camarillo G, Johnston A, Sparks R, Handley A, Schooler E (2002) SIP: Session Initiation Protocol. RFC 3261. [Online]. Available: http://www.ietf.org/rfc/ rfc3261.txt. Accessed 6 June 2011 33. Schulzrinne H, Wedlund E (2000) Application-layer mobility using SIP. Mob Comput Commun Rev 4(3):47–57 34. Schulzrinne H, Rao A, Lanphier R (1998) Real Time Streaming Protocol (RTSP). RFC 2326. [Online]. Available: http://www.ietf.org/rfc/rfc2326.txt. Accessed 6 June 2011

Multimed Tools Appl 35. Schulzrinne H, Casner S, Frederick R, Jacobson V (2003) RTP: a transport protocol for real-time applications. RFC 3550. [Online]. Available: http://www.ietf.org/rfc/rfc3550.txt. Accessed 6 June 2011 36. Seshan S, Balakrishnan H, Katz RH (1997) Handoffs in cellular wireless networks: the Daedalus implementation and experience. Wirel Pers Commun 4(2):141–162 37. Shacham R, Schulzrinne H, Thakolsri S, Kellerer W (2005) The virtual device: expanding wireless communication services through service discovery and session mobility. In: IEEE international conference on wireless and mobile computing, networking and communications (WiMob’2005), Montreal, Canada, 22–24 August 2005, pp 73–81 38. Shacham R, Schulzrinne H, Thakolsri S, Kellerer W (2009) SIP session mobility. RFC 5631. [Online]. Available: http://www.ietf.org/rfc/rfc5631.txt. Accessed 6 June 2011 39. Snoeren AC, Balakrishnan H (2000) An end-to-end approach to host mobility. In: Proceedings of the 6th ACM/IEEE international conference on mobile computing and networking (MobiCom’00), Boston, Massachusetts, USA, pp 155–166 40. Soliman H, Castelluccia C, Malki KE, Bellier L (2005) Hierarchical Mobile IPv6 mobility management (HMIPv6). RFC 4140. [Online]. Available: http://www.ietf.org/rfc/rfc4140.txt. Accessed 6 June 2011 41. Su G, Nieh J (2002) Mobile communication with Virtual Network Address Translation. Technical Report CUCS-003-02, Columbia University. [Online]. Available: http://www.cs. columbia.edu/techreports/cucs-003-02.pdf. Accessed 6 June 2011 42. User centric media: future and challenges in european research. Office for Official Publications of the European Communities (2007). [Online]. Available: ftp://ftp.cordis.europa.eu/pub/fp7/ ict/docs/netmedia/user-centric-media_en.pdf. Accessed 6 June 2011 43. Valkó AG (1999) CellularIP: a new approach to Internet host mobility. In: ACM SIGCOMM computer communication review 44. Wang Q, Abu-Rgheff MA (2003) A multi-layer mobility management architecture using crosslayer signalling interactions. In: 5th European personal mobile communications conference, Glasgow, Scotland, 22–25 April 2003, pp 237–241 45. Wang Q, Abu-Rgheff MA (2003) Integrated Mobile IP and SIP approach for advanced location management. In: 4th international conference on 3G mobile communication technologies (3G 2003), London, UK, 25–27 June 2003, pp 205–209 46. Wedlund E, Schulzrinne H (1999) Mobility support using SIP. In: Proceedings of the 2nd ACM intl. workshop wireless mobile multimedia, Seattle, Washington, USA, pp 76–82

Raffaele Bolla received the Ph.D. degree in Telecommunications in 1994 from the University of Genoa. Since November 1996 he is a researcher in the Department of Communications, Computer and Systems Science (DIST) at the University of Genoa, and since September 2004 he is associate professor in the same Department. He is also a member of CNIT, the Italian inter-university consortium for telecommunications. He is currently responsible of the International relationships for Engineering Faculty of Genoa University and he is responsible for DIST and CNIT of many important research projects and contracts with both public Institutions and private companies. He acts as reviewer for many different international magazines and participates to technical committees of international congresses (SPECTS, QoS-IP, Globecom, . . .). He has co-authored over 140 scientific publications in international journals and international conference proceedings.

Multimed Tools Appl Most of his research experience has been focused on modeling and control of multimedia IP networks and on the study and development of high-performance software router platforms. His current research interests are in: i) mechanisms and techniques for energy consumption reduction in IP networks, ii) modeling and design of Service Specific Overlay Networks, iii) advance platform for Future Internet nodes (Flexible Software Router), iv) advance mobility management in “user centric” networking approaches.

Riccardo Rapuzzi received his “laurea” degree cum laude in Computer Science from University of Genoa in 2004. In 2009, he obtained the Ph.D. degree in Electronic, Computer Engineering and Telecommunications. Since 2006, he has been involved in both Italian and European research projects. He is co-author of several reaserch papers, which have been published in proceedings of international conferences or international journals. His main research interests include the Internet traffic classification and characterization, with a particular focus in peer-to-peer applications, the IP mobility issues in wireless networks and pervasive environments and the green networking. Since 2009, he is holder of research grants at the Department of Communication, Computer and System Sciences (DIST) of the University of Genoa.

Matteo Repetto received his “laurea” degree cum laude in Telecommunication Engineering in 2000 and the Ph.D. degree in Electronics and Informatics in 2004 from the University of Genoa. Currently, he is a researcher at CNIT, the Italian inter-university consortium for telecommunications. He has co-authored over 20 scientific publications in international journals and conference proceedings, and he has cooperated in many different national and European research projects in the networking area. His current research interests are in wireless networks, estimation of freeway vehicular traffic, pervasive communications and mobility management.