Real-time Service Migration for Voice over Internet Protocol Services

Transcription

1 HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering Master's Programme in Mobile Computing - Services and Security Real-time Service Migration for Voice over Internet Protocol Services Master's Thesis Tan Miaoqing Telecommunications Software and Multimedia Laboratory Espoo 2008

2 HELSINKI UNIVERSITY OF ABSTRACT OF TECHNOLOGY MASTER'S THESIS Department of Computer Science and Engineering Master's Programme in Mobile Computing - Services and Security Author: Tan Miaoqing Title of thesis: Real-time Service Migration for Voice over Internet Protocol Services Protocol Date: May Pages: Professorship: Telecommunications Software Code: T-110 Supervisor: Professor Antti Ylä-Jääski Instructor: Andres Arjona Service migration enables continuity of service experiences while changing devices, without terminating or disturbing the running sessions of the service. It has been proposed as an important application for emerging ubiquitous computing environments. Service migration consists of three major components: service discovery, session transfer, and service environment re-instantiation. Service discovery is essential to locate target devices for migration, session transfer requires maintaining a media session while changing devices, and service environment re-instantiation aims at providing a unied access to services and the same personalized experience across devices. Providing a unied access to services particularly requires keeping the same service identier in the new device. This thesis specically studies Voice over Internet Protocol (VoIP) service migration by applying Session Initiation Protocol (SIP) as the main method. Service discovery is achieved with IP-Multicasting based approaches. Session transfer is realized within the scope of standard signaling and built-in call management of SIP. The same service identier is maintained across devices based on personal mobility. Likewise, we implement a prototype application to validate our design. The measurements results show that seamless session transfer of VoIP services is possible with simple enhancements on their underlying signaling protocols. Keywords: Language: service migration, session mobility, personal mobility, service discovery, SIP, VoIP English ii

3 Acknowledgements I would like to express my sincere thankfulness to my supervisor, Professor Antti Ylä-Jääski for his support to this work, in both academic and nancial aspects. I am also thankful to my instructor Andres Arjona for his valuable guidance through weekly meeting and numerous . Without your challenge and encouragement, I would not go this far for this thesis. Additionally, I thank Professor Jukka Manner for his supervision during the implementation phase of this work. This thesis is done as a part of the Nomadic Applications (NomAp) project. I would like to thank all funders of this project, including Tekes, Nokia, Erricson, TATA and Starcut. I especially thank Professor Heikki Saikkonen for leading the project. I also thank other colleagues, particularly Nie Pin, Jin Zhihua and Jari Kirma, for cooperating in this project. I thank Lv Xiaopeng, Nie Cong, Jiao Dapeng, Yu Bin and Xiao Yu for assisting me with measurement experiments. Thank all of you for your time and suggestions. I also thank Pekka Pessi at Nokia for his help with the Soa-SIP library, and Johannes Eickhold at Universität Karlsruhe for making Sofsip-cli work on Nokia Internet tablets. My deepest thanks go to my parents, who have given me their endless love and support throughout my life. Sorry that I can not be with you as I have grown up and gone to Finland for my study and work. I'm forever in your debt. I thank my girlfriend Yang Ying for her love and patience. Thank you for caring me and listening to me. I love you all. Espoo May 16th 2008 Tan Miaoqing iii

4 Abbreviations and Acronyms VoIP SIP RTP RTCP SDP SLP UPnP HTTP HTTPMU HTTPU XMPP NAT DNS UDP UMTS WLAN PAN IMS IETF 3GPP FMC Voice over Internet Protocol Session Initiation Protocol Real-time Transport Protocol Real-time Transport Control Protocol Session Description Protocol Service Location Protocol Universal Plug and Play Hypertext Transfer Protocol HTTP Multicast over UDP HTTP Unicast over UDP Extensible Messaging and Presence Protocol Network Address Translation Domain Name System User Datagram Protocol Universal Mobile Telecommunications System Wireless Local Area Network Personal Area Network Internet Multimedia Subsystem Internet Engineering Task Force Third Generation Partnership Project Fixed Mobile Convergence iv

5 MN CN UA AoR URI URL MNC SH 3PCC MLT CLT TTT SIT PDA UI OS API Mobile Node Correspondent Node User Agent Address of Record Uniform Resource Identier Uniform Resource Locator Mobile Node Control Session Hando Third Party Call Control Mobile User Lapse Time Correspondent Node Lapse Time Total Transfer Time Session Initiation Time Personal Digital Assistant User Interface Operating System Application Programming Interface v

6 Contents Abbreviations and Acronyms 1 Introduction Problem Statement Organization of the Thesis Background Use Cases for Multimedia Service Migration Related Work System Level Middleware Level Application Level SIP Session Mobility Session Initiation Protocol (SIP) Overview SIP Entities SIP Addresses SIP Messages Transactions and Dialogs Session Description Protocol The IETF Approach for Session Mobility Other SIP-based Approaches for Session Mobility Methodology 19 vi iv

7 4.1 Requirements General Requirements Service Discovery Requirements Session Mobility Requirements Personal Mobility Requirements Performance Experiments Limitations Design Design Overview Architecture of Components Service Discovery Session Mobility Personal Mobility Implementation Implementation Overview Soa-SIP Library SIP Messages Handling NUA Objects Tags Implementation of Session Mobility Component Mobile Node Control Mode Session Hando Mode Linux Tablets Implementation Results Evaluation Requirements Evaluation Comparison of MNC Mode and SH Mode Test Environment for Session Mobility vii

8 7.4 Results and Performance Analysis Mobile Node Control vs. Session Hando Mobile vs. Fixed Conclusions Future Work viii

9 List of Figures 2.1 Use cases for multimedia service migration Session establishment and termination Transactions and dialogs PCC and REFER method for session mobility (adapted from [38]) Usage scenario for a VoIP service migration: (a) call establishment; (b) call migration; (c) a call termination; (d) new incoming call Session transfer to a device with a dierent identier Function components UPnP device description for service migration enhanced devices UPnP service description for the capabilities of a device UPnP device description for legacy devices MNC call ow for session transfer and retrieval Call ow for basic call transfer and SH Simultaneous session transfer Example of personal mobility Discovery of personal devices Overview of the implementation State diagram of MN in MNC mode for session transfer State diagram of MN in MNC mode for session retrieval ix

10 7.1 Device centric and network centric architecture for the service migration system Session retrieval in SH mode Simultaneous session transfer where two endpoints are using dierent mode at the same time Metrics in MNC call ow Metrics in SH call ow Testbed setting for experiments Comparison between MNC mode and SH mode Results of EXP2 (SH mode, CN is laptop without optimization) Results of EXP3 (SH mode, CN is N800 with optimization). 75 x

11 List of Tables 3.1 Request methods Response classes and examples Channel change delay and interruption times in GSM [1] Three experiments for performance measurement Results of EXP1 (MNC mode, CN is laptop without optimization) Results of EXP2 (SH mode, CN is laptop without optimization) Results of EXP3 (SH mode, CN is N800 with optimization). 72 xi

12 Chapter 1 Introduction With the convergence of the Internet and the mobile technology, the future mobile networks are evolving towards an all Internet Protocol (IP) architecture. This evolution leads to the emerging integration of the Internet and mobile networks. Likewise, the capabilities of mobile devices are increasingly improved in terms of connectivity, processing power, and storage space. These trends provide the possibility of ubiquitous access of multimedia services across heterogeneous networks, as well as various mobile and xed devices. Converged mobile devices such as smartphones and Internet tablets are now capable of providing IP multimedia services, such as Voice over IP (VoIP) services and video streaming, but they are still limited in terms of display size, processing power and bandwidth. On the other hand, xed devices such as PC and hardware-based IP phones can oer better usability and bandwidth, but they can not be accessed by users on the go. Therefore, integration of heterogeneous devices is necessary in order to combine their advantages. This requires that devices in the vicinity can borrow the capabilities from each other, so that multimedia services can be moved between mobile and xed devices to either gain better quality, performance and usability, or enable mobility. In particular, service migration should be seamless and with minimal disruption of the running sessions. From the user's perspective, the benet is that they could use multimedia services to their best convenience, and maintain the continuity of their service experiences while changing devices, without terminating or interrupting the remote participant. This thesis studies the performance of VoIP service migration using SIP as the main method as described in an IETF Internet-Draft [40]. In the study we evaluate two modes of migration. Likewise our study will encompass the 1

13 CHAPTER 1. INTRODUCTION 2 performance of both mobile-to-xed as well as xed-to-mobile test scenarios. The key contribution of the paper is a performance evaluation of a functional VoIP service migration prototype implemented based on the Internet-Draft [40]. Subsequently, we compare the results with those available in the literature. Further, we propose modications to the IETF draft that can improve service experience. Finally, we describe the main delay components aecting VoIP service migration. 1.1 Problem Statement This section states the denition of the research problem. Before presenting the problem statement, some terminologies are dened. Service is the provision of software-based functions to an end-user or software application. Multimedia service is the service provided by Internet Protocol (IP) multimedia applications, such as Internet telephony, streaming, instant messaging and interactive games. Session is a continued connection between two endpoints, usually involving the exchange of many packets between them. A multimedia session, as dened in [15], "is a set of multimedia senders and receivers and the data streams owing from senders to receivers. A multimedia conference is an example of a multimedia session." Service migration is a mechanism of seamlessly transferring multimedia services and the respective sessions from one device to another. Session Initiation Protocol (SIP) is "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants." [34] Besides session management, SIP is also utilized to provide various types of mobility in the application-layer [38]. With the knowledge of above terms, the objective of this thesis is to address the problem of service migration by applying SIP as the fundamental method. Service migration consists of three major components: service discovery, session transfer, and service environment re-instantiation. Service discovery is essential to locate target devices for session transfer. For instance, if a user

14 CHAPTER 1. INTRODUCTION 3 is roaming to a foreign network, his devices should be able to discover available public devices in their vicinity so that the user can utilize surrounding resources dynamically. Session transfer requires maintaining a media session while changing devices. A service must seamlessly move from one device to another without disrupting its ongoing media session. Service environment re-instantiation aims at providing a unied access to services across devices, and thus maintaining the same service experience for end users. Providing a unied access to services implies that services are associated with the user rather than his devices. This particularly requires keeping the same service identier in the new device. To summarize, these components lead to the following three fundamental research questions, which will be discussed throughout this thesis: 1. How to discover devices which are available in a user's proximity? 2. How to maintain a media session while changing devices? 3. How to keep the same service identier in the new device? 1.2 Organization of the Thesis The reminder of the thesis is organized as follows. Chapter 2 provides background information, including several use cases and related works. Chapter 3 reviews the basic elements of SIP and surveys SIP session mobility that being developed in the IETF [40]. Chapter 4 categorizes the requirements for a service migration system based on the above three research questions, describes the plan for the performance experiment, and states the limitations of the thesis. Chapter 5 presents the architecture design, which mostly follows the IETF work [40], and also extends it to provide the consistent use of service identier in the new device. Then, Chapter 6 depicts a prototype implementation based on the design. Subsequently, chapter 7 evaluates the requirements proposed in Chapter 4 by comparing with the outcome of the design and implementation, as well as data gathered from the performance experiment. Finally chapter 8 presents the conclusions of the thesis and ideas on future works.

15 Chapter 2 Background This thesis is done as a part of the Tekes funded Nomadic Applications (NomAp) project in Helsinki University of Technology. The goal of the project is "to design a demonstrator-prototype of the nomadic application concept that paves the way towards the future dynamically changing virtual computing environment, that allows applications to suspend in a one computing environment and later resume in the same or a dierent computing environment that may have signicantly dierent properties in respect of computing resources, such as processing power, energy, communication capabilities and user interfaces". The project consists of four demonstrators in regarding to the migration of service, process, user interface and identity respectively. This thesis corresponds to the service migration-demonstrator, which shows how services and the respective sessions can be moved from one machine to another. This chapter provides relevant background information concerning the topic of this thesis. First, several use cases are presented in order to draw an intuitive image of the service migration system. Also, related work is discussed. As this thesis mainly follows the IETF Internet-Draft "SIP Session Mobility" [40], SIP thus serves as the main functional compnent in this work. All SIP related topics will be presented in the next chapter. 2.1 Use Cases for Multimedia Service Migration The rst use case is to achieve user mobility. A user can avoid losing a session by transferring it to a mobile device when he moves away from a xed device. 4

16 CHAPTER 2. BACKGROUND 5 For instance: "A user is having a VoIP call in his home computer, but has to leave for work. He does not want to hang up the phone since the conversation is really important. He simply pushes a button in his computer and the call is immediately transfered to his mobile. Thus, the user continues the conversation in his mobile while on the go, and the person calling him does not feel any interruption at all." The second use case is achieving better user perception of service. "Assuming when the user arrives at his oce, his VoIP call is still going on. However, since his mobile is receiving much weaker 3G signal inside the building, the voice quality is degraded. Moreover, the call may be a video call, but since the screen size of his mobile is small, he can not see his contact clearly. The user then simply transfers the call from his mobile to his oce PC that is running a VoIP phone. The oce PC is connected to the Internet via the oce LAN and the voice quality is improved. Also, thanks to the big LCD screen, the image of the other person can now be shown very clear." Above two use cases are illustrated in Fig They can be also applied to multimedia streaming services such as IPTV. For instance: "When a user is leaving for work, he can transfer the current TV program to his mobile. This is much more convenient than searching and opening the program again in his mobile. When he has arrived at home after work, he can again transfer the TV program watching in his mobile back to his home TV with a bigger display screen and a better audio quality." In another use case, the user may also transfer a session to another device if the battery of the current device is running out. This frequently happens to smartphones which have powerful multimedia capabilities but the battery is usually discharged completely almost in one day.

17 CHAPTER 2. BACKGROUND 6 Figure 2.1: Use cases for multimedia service migration 2.2 Related Work There are solutions for service migration in three dierent levels, namely, system level, middleware level, and application level. We will discuss several related work in each level in this sections System Level Internet Suspend/Resume Internet Suspend/Resume (ISR) [37] is co-developed by researchers at Intel Research Pittsburgh and Carnegie Mellon University. Under the ISR approach, a user's entire computing environment can be suspended at one location and resumed at another, on a dierent machine. The environment is saved in a centralized storage location. The key concept in ISR is to layer virtual machine technology on a distributed le system. Virtual machine technology is utilized to capture the user's computing environment which consists of the user's operating system, applications, data

18 CHAPTER 2. BACKGROUND 7 les, customizations and the current execution state at the time of suspend. This state is re-instantiated directly on the machine at the resume site. Unlike any thin-client approaches, in ISR, all process execution and computation takes place on hardware the user is actually using. Distributed les systems are employed to manage the transport of the state across both space (from suspend site to resume site) and time (from suspend instant to resume instant). As for the implementation, ISR employs VMware Workstation as its virtual machine, and Coda [36] as the distributed le system Middleware Level Middleware Framework for User-Level Hando [6] proposes a middleware framework to support user mobility in the ubiquitous computing environment. User mobility does not only include host mobility, but also includes the cast where a user is free to migrate his service environment. The middleware framework tries to minimize application level support for session transfer mechanisms, thus eliminating the need to make each application mobility-aware. It includes two major functions, namely, user-level hando management and service instantiation across heterogeneous computing platforms. The goal of the framework is to keep the user's logical service environment despite changes in the physical environment. There are two assumptions for the framework: the existence of user location detection system which keeps track of user's current location, utilizing automatic detection techniques such as active badges, as well as service discovery service which searches new service provider during the service environment migration. Two main issues concerning service environment migration are addressed in this middleware framework. The rst issue is the state information management and maintenance. State information includes the execution state of each running application, and contextual information that helps to re-instantiate the same service environment. The proposed solution is that each client host installs a middleware layer called Hando Manager, which captures and manages the state information in an XML format, interacts with applications by providing a set of APIs for getting and putting the state information, and communicates with

19 CHAPTER 2. BACKGROUND 8 User Metadata Server, which acts as the "anchor point" between the old and new client hosts, thus after the old client host updates its state information, the new one, to which the service will migrate, can retrieve it. The second issue is re-instantiating the user's service environment on the new client host, including nding dierent applications on heterogeneous platforms between which a service is migrating, transcoding service, and preserve certain QoS parameters. Solutions include selecting the appropriate application according to the XML description of the state information of the service, and also possibly dynamic program downloading and instantiation; transcoding service lookup and reforming the service path; QoS mapping algorithm. Session-layer API Researchers in University of Tokyo propose a session-layer API method [19] for service migration. Similar to the middleware framework discussed in [6], this approach introduces a session layer middleware that must be installed on every terminal. Thus, an apparent drawback of this approach is that the correspondent node must have special capabilities for signaling handling during session migration. The session layer middleware provides two signicant functions: the communication interface provided to applications and the association organized for mobility support. Unlike BSD socket API, the interface is not tied to the detail information such as DNS name, port number, IP address, and MAC address. On the contrary, it is only related to an association corresponding to the service session. The association is between communication end points, thus dierent from Mobile IP, where the association is between mobile host and home agent. Furthermore, the association does not have any lower layer dependency, and is dynamically modied during service migration. In order to achieve above requirements, this work adopts Key-insulated public key cryptosystem [7], in which the private key can be dynamically changed while the same public key is maintained.

20 CHAPTER 2. BACKGROUND Application Level Service Mobility Proxy The researchers from University of Tokyo have also proposed a proxy-based approach for cross-device handover [16]. This approach employs an entity named service mobility proxy to handle all session migration and media adaption to dierent devices. The service mobility proxy has functions for switching the destination terminal and transcording. This approach also introduces a compact and simple network-oriented device called NetSpeaker as one of the destination terminals for cross-device handover using the service mobility proxy. NetSpeaker devices can be easily embedded in the environment and enable dynamic device cooperation. An apparent drawback of this approach is triangular routing, as data ow between two calling parties must always traverse the proxy even when a session is not migrated. Dynamic Device Association Dirk Kutscher and Jörg Ott proposes Dynamic Device Association (DDA) in [20]. DDA includes service and device discovery, device selection, and associating with devices for authorized users. Also, it allows for bootstrapping application protocols and provides means for dissociation after use. One usage scenario for DDA is the dynamic association and control of public IPtelephony systems. For instance, a user can utilize a PDA to congure and control IP telephones. Rather than utilizing common service discovery protocols such as Service Location Protocol (SLP) [14] and Universal Plug and Play (UPnP) [50], DDA employs an announcement-based scheme, where services actively announce their availability and user agents receive and lter announcements depending on the service description. In order to scale to large numbers of services, DDA adopts a rate adaptation scheme, which requires that each service agent adapts its own transmission frequency so that the total announcement data rate of all service agents in the multicast group remains constant. For Service and Device Association, security is the most signicant issue to consider, including authentication, condentiality and integrity. Moreover, the design of DDA framework is not tied to any specic session protocol, thus SIP, Mbus, HTTP, SOAP are all applicable. In the current implementation, Session Announcement Protocol (SAP) is employed for service discovery, Session Description Protocol (SDP) is used

21 CHAPTER 2. BACKGROUND 10 for describing service attributes, and HTTP GET request is used for service association while TLS is applied for security. Browser Session Preservation and Migration Designed by researchers in DoCoMo Communications Labs in the USA, Browser Session Preservation and Migration (BSPM) infrastructure [44] allows the user to take a snapshot of an active Web session state on a browser, and then retrieve the snapshot on another device to continue the same active Web session. The Web session snapshot includes the current state of the browser such as history, text data, and cookies. A proxy server is utilized to store browser session snapshots securely.

22 Chapter 3 SIP Session Mobility 3.1 Session Initiation Protocol (SIP) Overview Session Initiation Protocol (SIP) is an application layer signaling protocol for initiating, managing and terminating IP multimedia sessions. SIP is transport-independent, as it can be used with dierent transport protocols such as UDP, TCP, SCTP. Further, it is text-based and highly extensible. Humans can read and analyze SIP messages, and SIP can be easily extended to implement services such as call control and mobility. SIP is being developed by the SIP Working Group within the Internet Engineering Task Force (IETF). This section briey discusses the key elements of SIP SIP Entities The SIP architecture is composed of ve types of logic entities: A user agent (UA) is an endpoint entity, which consists of two logical parts: User Agent Client (UAC) that sends requests and receives responses, and User Agent Server (UAS) that receives requests and sends responses. A proxy server is an intermediary entity that forwards requests and responses on behalf of SIP endpoints. It can be regarded as an application layer router on the SIP network. A redirect server accepts a SIP request from a SIP client, but rather than forwarding the request, it pushes routing information for the request back in a response to the client. 11

23 CHAPTER 3. SIP SESSION MOBILITY 12 A registrar is a server that accepts registrations from SIP endpoints, and updates their contact information in location servers. A back-to-back user agent (B2BUA) is a logical entity that receives a request from one endpoint and processes it as a UAS. It also acts as a UAC and generates requests to the other endpoint. In contrast to a proxy server, it maintains dialog state and allows the operators to oer value-added features to the call SIP Addresses SIP users are identied by -like identier, which is called SIP Uniform Resource Identier (URI). SIP URI has format in the form of sip:user@host, for instance, sip:user@example.com. The user part can be either usrename or phone number or omited, and the host part can be either hostname or IP address SIP Messages There are two types of SIP messages. One is requests, which are sent from clients to servers. The other is responses that are sent from the servers to the clients. Table 3.1 shows some typical SIP requests. Method INVITE ACK BYE CANCEL OPTIONS Table 3.1: Request methods Description Initiates a call or update call parameters (re-invite) Acknowledges a nal response for an INVITE request to complete the establishment of a session Terminates a session Cancels a previous request sent by a client before the UAS gives the nal response Queries the capabilities of another UA or a proxy server, for instance, supported methods and content types REGISTER Adds a new binding between an address-of-record and one or more contact addresses. It can also remove or query bindings.

24 CHAPTER 3. SIP SESSION MOBILITY 13 Table 3.2 shows SIP response classes and examples. Table 3.2: Response classes and examples Class Meaning Example 1XX provisional: request received, continuing to process the request 180 RINGING 2XX success: the action was successfully received 200 OK 3XX redirection: further action needs to be 301 MOVED TEMtaken to complete the request PORARILY 4XX client error: the request contains bad 400 BAD REQUEST syntax or cannot be fullled at the server 5XX server error: the server failed to fulll 500 SERVER ERROR a valid request 6XX global failure 603 DECLINE SIP is based on request and response model. Fig. 3.1 shows the interaction between two user agents during session establishment and termination. Figure 3.1: Session establishment and termination A session is initiated by an INVITE request containing the media capability of one endpoint (Alice's UA). After receiving the request the other endpoint (Bob's UA) responds by sending the provisional responses 100-Trying and 180-Ringing. After Bob picks up the call, his UA sends its media capability

25 CHAPTER 3. SIP SESSION MOBILITY 14 in a 200-OK response. After initial exchange the call session is nally established by an ACK request. The session can be terminated by sending a BYE request from either endpoint Transactions and Dialogs A SIP Transaction consists of a single request and any responses to that request. Transaction is created on incoming Request or may be created to send outgoing request. A Dialog is a P2P association between communicating SIP endpoints, it maintains Route Sets and Sequence Numbers, and is established by INVITE, MESSAGE, SUBSCRIBE, REFER, etc. A dialog consists of transactions, and is identied at each User Agent with a dialog Id, which consists of a Call-Id value, a local tag and a remote tag. The dialog Id at each User Agent involved in the dialog is not the same. Fig. 3.1 illustrates these two concepts with a basic SIP call ow consisting of both session establishment and termination. Figure 3.2: Transactions and dialogs

26 CHAPTER 3. SIP SESSION MOBILITY Session Description Protocol Session Description Protocol (SDP) is a textual protocol used to describe multimedia session attributes and capabilities [15]. SDP is SIP is utilized for negotiating and setting up session parameters between endpoints [33, 18]. These session parameters include media type, format, codec, address and port for receiving media stream. The following example shows a SDP body included in SIP messages during session establishment: v=0 o= IN IP s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 The o= line indicates the session ownership, IP protocol version and the host's address. The c= line describes connection information. In the above example, the IP address for connection is dierent from the host address of the session owner, since the session endpoint is not necessarily the media endpoint in SIP. We will later discuss how this can be utilized to achieve service migration. The m= line informs that in this session, only audio is used with media port number The following a= line describes the candidate media codes. 3.2 The IETF Approach for Session Mobility SIP session mobility is rst given in [38] in the year of It allows a user to transfer an ongoing session from one device to another device. Two dierent methods are proposed, namely, third party call control (3PCC) [32] and the REFER method [45]. Third party call control enables one entity to create a call in which communication is actually between other parties. The central party that establishes the session for the other two parties is called controller. RFC 3725 [32] depicts four types of call ow that can be utilized by the controller to provide 3PCC. Fig. 3.3 (a) shows the main idea of 3PCC. The controller rst obtains the media parameters of A by sending an INVITE

27 CHAPTER 3. SIP SESSION MOBILITY 16 Figure 3.3: 3PCC and REFER method for session mobility (adapted from [38]) without its own SDP, then it establishes a session with B by sending an INVITE with A's SDP. Subsequently, B will respond with its own SDP, hence the controller can include the media parameters of B in the ACK sending to A. In this way, A and B establish a media session, while the controller maintains signaling sessions with A and B respectively. The REFER method indicates that the recipient (identied by the Request- URI) should contact a third party using the contact information provided in the request. REFER request implicitly establishes a subscription to the refer event, which is the same as a subscription created with a SUBSCRIBE request. Therefore, the referrer that issued the REFER will receive NOTIFY requests from the referee (the REFER receiver). The NOTIFY message will inform the referrer of the status of the refer target, for instance, whether it has accepted the INVITE request from the referee. This procedure is shown in Fig. 3.3 (b). The SIP session mobility approach described in [38] has been under actively research in the IETF. An Internet-Draft [40] was submitted in February The authors include researchers in Columbia University, including Henning Schulzrinne, and DoCoMo Communications Laboratories Europe. The newest version of the draft was released in November Moreover, the authors of the Internet-Draft published a journey paper [41] in late In their paper, they have integrated SIP session mobility with other works, proposing a comprehensive system that provides seamless and personalized

28 CHAPTER 3. SIP SESSION MOBILITY 17 usage of public and private devices discovered in the vicinity of a user. The system integrates device discovery, session mobility, and prole mobility. Its features include location tracking, interoperability with simple existing devices, split of sessions between devices, the use of several devices as a single "virtual device", reconciling device capability dierences, as well as handling of security and privacy concerns. The system applies both 3PCC and REFER method to implement the session mobility and several options are provided. The rst option is transfer and retrieval. Retrieval means to remotely transfer a session currently on another device to the local device, which may either have previously carried it or not. The second option is complete or splitting session transfer. One example of splitting session transfer is that a user only transfers the video of his session to an external LCD screen, while maintaining the audio on his Internet tablet. The third option is mobile node control (MNC) mode and session hando (SH) mode. MNC mode utilizes 3PCC while SH mode utilizes REFER method. MNC mode requires the entity which starts the session transfer to maintain the signaling sessions after transferring the media session to one or more devices. It is a shortcoming compared to session hando mode, which completely transfers both the signaling session and media session to another device. However, MNC mode is more convenient to split a session to multiple devices, and has better interoperability with legacy applications which only support common SIP signaling features. Two signicant aspects have been taken into account for reconciling device capability dierences, namely, codec dierences, and display resolution and bandwidth dierences. To cope with codec dierences, the device must check the capabilities of the correspondent node (CN) and the new device before transfer a session. This can be achieved either through SIP OPTIONS method or SLP service attributes. Moreover, an intermediate transcoding service is deployed for CN and local devices to which a session will be transferred. For the second issue, changing the image resolution and framerate requires no special handling other than SDP. Additionally, the system utilizes Service Location Protocol (SLP) to discover available devices in a user's local area, along with their capabilities, thus the user can be always aware of the potential transfer devices.

29 CHAPTER 3. SIP SESSION MOBILITY Other SIP-based Approaches for Session Mobility Since the introduction of SIP application layer mobility in 2000 [38], many other SIP-based approaches have been proposed in this area, including the following work. SSIP addresses issues of splitting a SIP session over multiple devices [3]. Specically, it proposes an SIP extension header "Mobility" to improve the call transfer mechanism and hide the changing of terminal from the remote party. However, the drawback of this proposal is that this "Mobility" header approach is not accepted by IETF, as "Replaces" header has similar functionality and is standardized. Additionally, this approach does not support simultaneous session transfer. Japanese researchers proposes a service initiation and migration system for real-time communication services [17]. It utilizes SIP INFO method rather than REFER method adopted by the call transfer mechanism. The advantage is to support simultaneous session transfer comparing to basic call transfer. However, the IETF Internet-Draft [40] extends the basic call transfer and thus supports simultaneous session transfer very well. Researchers in Columbia University applies the ubiquitous computing concept to home networks [39]. They develop such a system based on SIP, with Bluetooth devices for location sensing and SLP for service discovery. The major application of this system is to allow the visitor's device to use the media I/O devices in the new home environment without terminating the ongoing sessions. It adopts a secure and exible way that makes the vistor's device work as a SIP back-to-back user agent and follow the 3PCC method to control other devices. Thus, this approach is basically similar to MNC mode described in the IETF Internet-Draft [40]. There are also works that extend and enhance the IETF SIP session mobility approach. [9] enables session mobility in a multiparty conferencing, like the full mesh communication model. [49] proposes the accounting management for session mobility in order to do charging and billing properly. [28] enhances SIP session mobility with privacy protection and interdomain mobility across access and core networks managed by dierent providers in a converged network.

30 Chapter 4 Methodology Figure 4.1: Usage scenario for a VoIP service migration: (a) call establishment; (b) call migration; (c) a call termination; (d) new incoming call. This thesis aims to address the problem of service migration in a dynamic and heterogeneous environment. A scenario of Voice over Internet Protocol (VoIP) service migration is shown in Fig In the beginning, a user with the service identier sip:user@example.com uses his mobile phone to setup a call session with the contact A. In the 19

31 CHAPTER 4. METHODOLOGY 20 middle of the session, he enters his oce and his mobile phone automatically detects his oce PC. Now the user wants to move the call session to his oce PC and continue his conversation there. Thus, he chooses his oce PC as the transfer target from his mobile phone and starts the session migration. Afterwards, the session is seamlessly moved to his oce PC, and the contact A does not aware of the change of terminal on the other side at all. After the user terminates this call session, another contact B calls the user using his service identier sip:user@example.com. The call directly reaches the user's oce PC rather than his mobile phone, as he is currently working on his oce PC. Nevertheless, the user also has freedom to not move his service identier to his oce PC after this call session terminates. Therefore, in this case, all future calls will still reach his mobile phone. 4.1 Requirements This section discusses the requirements regarding to the service migration system based on the above scenario. Requirements are categorized to one general type and three specic types, namely, service discovery requirements, session mobility requirements, and personal mobility requirements. General requirements depicts the high level characteristics, while each specic type of requirements addresses a respective research question presented in Sec General Requirements As next generation cellular networks are evolving towards a packet-switched architecture, VoIP services will be supported with the deployment of Internet Multimedia Subsystem (IMS). Although this trend has been blocked as the penetration of IMS is stagnate, VoIP has already become a mainstream service as well as big business nowadays, mainly due to the rising force from the Internet domain. Skype, Gtalk and public SIP services are the best representatives of this kind. Therefore, service migration system should be easy to deploy into the existing architectures of current VoIP services without imposing major changes to their infrastructures. Moreover, it must t the high scalability of VoIP services, which are typically provided in a world wide area. This analysis leads to the rst requirement: R1. The service migration system should be easy to deploy within current VoIP services. It must be also scalable since VoIP services are typically provided globally.

32 CHAPTER 4. METHODOLOGY 21 One of the main design goals of the service migration system is to support a heterogeneous devices and applications environment. This environment consists of various type of public devices, including stationary computers along with Internet appliances embedded into the environment, such as LCD screen, TV camera, and loudspeaker. It also consists of all kinds of personal devices, as nowadays users are likely to own multiple personal devices that support Internet connection, for instance, PCs, laptops, smartphones, Internet tablets and Personal digital assistant (PDA). These heterogeneous devices are possibly running both service migration enhanced applications and legacy applications. Therefore, the service migration system must be able to interoperate with the legacy applications. Furthermore, as mainly targeting at VoIP services, it must be also capable of cooperating with applications in future IP telephony system. Thus: R2. The service migration mechanism must support both service migration enhanced applications and legacy applications. Moreover, it must be capable of cooperating with future IP telephony systems Service Discovery Requirements Service discovery requirements aim to answer "How to discover devices which are available in a user's proximity?". Service discovery protocols allow automatic detection of devices and services oered by these devices on a computer network. In order to provide dynamic usage of surrounding resources, the user needs to nd transfer target devices automatically without any prior conguration. Furthermore, as it is only reasonable when the transfer target device is in the vicinity of a user, service discovery in a user's local area is necessary. This leads to the following requirement: R3. The user's devices should support service discovery in his local network. After users' devices obtain the existence of available devices in the local area, the user may also need to know their capabilities such as codec support, resolution display, location information such as room number so that he can decide to select a suitable transfer target device. Therefore: R4. Users' devices should be able to learn the capabilities of potential transfer target devices.

33 CHAPTER 4. METHODOLOGY Session Mobility Requirements Session mobility requirements aim to answer "How to maintain a media session while changing devices?". It is important to make session transfer as seamless as possible, so that media disruption is minimal to both participants. Therefore: R5. Session transfer should involve minimal disruption of the media ow. The session transfer should be also transparent, requiring no manual interruption from the remote participant. In other words, the remote participant is unaware of session mobility. This leads to the following requirement: R6. Session transfer should not either require any manual interruption, or appear to the remote participant as a new call. A user may transfer a session begun on his mobile device to the desktop PC when entering his oce. He may also want to retrieve the session back to his mobile device while walking out of the oce. Therefore: R7. It must be possible to retrieve a session after session transfer. One participant can transfer the session to a new device without interrupting the remote participant. On the other hand, the remote participant may also initiate a session transfer on his side. Therefore: R8. The service migration mechanism should support simultaneous session transfer Personal Mobility Requirements Personal mobility requirements aim to answer "How to keep the same service identier in the new device?". As described in [38], personal mobility allows to address a single user located at dierent devices by the same logical address. This logical address is the service identier of the user, which is identical to the Skype name for Skype, and the Gmail account name for Gtalk. A drawback of the IETF Internet-Draft [40] is that it assumes all devices, either public or personal, have dedicated service identier. This means,

34 CHAPTER 4. METHODOLOGY 23 Figure 4.2: Session transfer to a device with a dierent identier as shown in Fig. 4.2, the user needs to login his VoIP service in dierent devices with dierent identiers, for instance, user.homepc@example.com for his home PC, and user.mobile@example.com for his mobile phone. For a public device, it is reasonable to use a dedicated identier, such as sip:public.device1@example.com. However, it is apparently neither desirable nor convenient for a user to maintain a dedicated service identier for each personal device, as the user may care about the service rather than which device is running the service. Furthermore, for a caller who wants to contact the user, it is also inecient to try the next service identier if the previous device does not answer. On the contrary, with personal mobility enabled, the user only needs to maintain and distribute one single identier for his VoIP service, and the caller can reach him at any of his personal device with this identier. This leads to the following requirement: R9. All personal devices owned by the same user should have the same service identier, and can be registered at the same time. Besides, as shown in the above usage scenario, the user can either use the transferrer (his mobile phone in this scenario) or transfer target device (his oce PC) to receive the future calls. Therefore: R10. The user should have the freedom to determine which personal device to answer the future calls.

35 CHAPTER 4. METHODOLOGY Performance Experiments Most of the requirements will be evaluated against the outcome of the design and the prototype implementation, except for the requirement 5 "Session transfer should involve minimal disruption of the media ow", which can be only evaluated by measuring the performance of the prototype implementation. The measurement experiments in this thesis will mostly follow the Schulzrinne et al paper [41]. The basic method is to utilize Wireshark [51] to capture and analyze packet dumps on all parties involved in service migration. In addition, the system time of transferrer device and transfer target device are synchronized using NTP [27]. We assume that the time between a device receiving an RTP stream and playout is negligible, and all devices are congured to automatically answer any incoming calls. 4.3 Limitations The multimedia service in this study is only limited to bidirectional Voice over Internet Protocol (VoIP). Other type of multimedia services such as unidirectional streaming and instant messaging are not taken into account. A VoIP session may consist of both audio and video, but this study only focuses on the case of audio call. Furthermore, this work only studies the case of complete session transfer. This means the whole set of session media is transferred to a single device. Splitting transfer across multiple devices is not considered. An example of the later case can be splitting the video session of a call to a TV camera with bigger LCD screen while maintaining the audio session on the original device. Another example can be splitting a full-duplex audio session from a mobile phone to an input device and an output device, such as a microphone and a speaker. One core assumption of this work is that all devices involved with the service migration are SIP enabled. Though the mechanism presented in this work can be easily applied to other VoIP protocols such as Extensible Messaging and Presence Protocol (XMPP) [53], this work does not solve the interoperability problem with VoIP applications implemented with dierent protocols. Moreover, security and privacy problems are not discussed in this study though they are apparently very important for this type of system. Lastly, this work assumes that no network intermediaries such as rewalls and NAT boxes are present.

36 Chapter 5 Design This chapter describes the architecture for the service migration system. Before discussing the architecture design, three entities are described below, as they are central parties involved in service migration: Mobile Node (MN) - the party initiating the session transfer. The MN does not necessarily need to be a mobile device. For instance, when a user leaves for work, he transfer the call session from his home computer to his mobile phone. In this case, the MN is the xed home computer. Local Device - the new party to which the session is transferred. The local device must be physically near to the user. Correspondent Node (CN) - the remote participant with which a Mobile Node is communicating. 5.1 Design Overview Fig. 5.1 shows all function components on a service migration enhanced device, as well as its interactions with other parties. There are three central components concerning service migration, namely, service discovery component, service mobility component, and personal mobility component, each one corresponds to a specic type of requirement in Sec The Mobile Node (MN) must be a service migration enhanced device, as it is the initiator of service migration. It consists of a SIP User Agent (UA) for session management, a media subsystem for multimedia services, and 25

37 CHAPTER 5. DESIGN 26 Figure 5.1: Function components a service discovery component to detect available devices in the local area. The SIP UA contains specialized components to support session mobility and personal mobility. The local device can be either a public or personal device, and either an enhanced or legacy device. The enhanced local device has the same function components as the MN. On the other hand, legacy local device does not contain specialized components to support service migration. This constraint leads to the following two considerations: rstly, an external service discovery agent must be introduced to assist legacy local devices in order to announce their existence to the MN; secondly, session must be able to transfer to legacy devices only using standard SIP signaling. The Correspondent Node (CN) can be also either an enhanced device or legacy device. SIP servers, including proxy, registrar or redirect server [34], are applied to deploy a full SIP architecture, which provides services such as naming and routing. Moreover, while service discovery and session mobility can be achieved in a device centric approach [24], the provision of personal mobility

38 CHAPTER 5. DESIGN 27 should be cooperated with the network infrastructure, such as SIP registrar. 5.2 Architecture of Components Service Discovery This thesis adopts UPnP [50] as its service discover protocol. It is an open architecture that leverages standard Internet protocols such as TCP/IP, UDP, HTTP, XML and SOAP. UPnP enables pervasive P2P network connectivity of PCs, intelligent appliances and wireless devices without prior conguration. It allows any UPnP compatible device to dynamically join a network, obtain an IP address, announce its service along with its capabilities to the network, and discover the presence and capabilities of available devices in the same network. UPnP also allows devices to leave the network automatically without leaving any unwanted state information. With all these benets, UPnP is widely deployed in commercial products, such as smartphones, Internet tablets and rewalls. Discovery Two logical entities are dened in UPnP, namely, devices and control points. Devices are the providers of services, and control points are users of those services. A physical device can be both a device and a control point. Simple Service Discovery Protocol (SSDP) is utilized as discovery protocol in UPnP. It consists of 2 types of request messages, which are represented as extended HTTP messages with additional method and headers. The rst category is service advertisement messages with NOTIFY method. It can announce both device availability (alive) and device unavailability (byebye). The other category is search messages (discover) with M-SEARCH method. It allows a control point to search for suitable devices with specic criteria. All request messages are delivered via HTTP Multicast over UDP (HTTPMU), while the responses of search messages are delivered via HTTP Unicast over UDP (HTTPU). When a device is added to the network, it advertises its services to control points on the network. On the other hand, when a control point is added to the network, it can either search for devices or services by actively searching the network, or passively listening to service advertisement from devices. The MN must be a control point in order to dynamically nd computing

39 CHAPTER 5. DESIGN 28 resources in its environment. The local device must be a device, announcing its services to the MN. Legacy local devices may not have UPnP functionality. Therefore, an external service discovery agent is introduced to announce their services to the MN. Apparently, the agent must be a device. Resource Description After a control point has discovered a device, it will further retrieve the device's description to learn more about its capabilities. The UPnP description for a device consists of a device description and one or more service descriptions that describe the capabilities of the device. Fig. 5.2 shows an example of the device description for a service migration enhanced device. Several important elds are underlined in the gure. Figure 5.2: UPnP device description for service migration enhanced devices The devicetype element describes the type of a specic device, such as mobile, PC and camera. The friendlyname element describes the device name for end users. Mostly importantly, the SIP UA is described as a service for the device: the servicetype element is dened as "sip-device", which can be utilized as the value for the ST (search target) header in discovery messages; the serviceid element represents the address-of-record of the SIP UA, which is the user's service identier in this thesis; the SCPDURL element points to the detailed service description, as shown in Fig. 5.3.

40 CHAPTER 5. DESIGN 29 Figure 5.3: UPnP service description for the capabilities of a device Currently, no action element is dened. The state variable element describes the capabilities of the device such as supported codec and display resolution, as well as location information such as GPS coordinates and room number. This information can be both congured by the SIP UA by default and further edited by the user. As stated above, a service discovery agent is introduced to assist legacy local devices to announce their services to the MN. Fig. 5.4 shows the device description for a service discovery agent. Figure 5.4: UPnP device description for legacy devices

41 CHAPTER 5. DESIGN 30 The service discovery agent needs the manual conguration from local administrators. Each legacy device is described as a service in the service list, and identied by a unique serviceid Session Mobility The design of the session mobility component mainly follows the IETF Internet- Draft [40]. Two dierent modes for session mobility will be discussed in this section, as well as SIP call ows of both modes. Notice that the session initialization between the MN and the CN will not be included in the call ow gures. In addition, we will justify certain design decisions and compare them to alternative design approaches. Mobile Node Control Mode In Mobile Node Control (MNC) mode, the MN only transfers the media session to the local device while maintaining the signaling session. MNC mode utilizes third party call control (3PCC). The IETF Internet-Draft [40] uses Flow I specied in [32]. Fig. 5.5 (a) shows the call ow for session transfer in MNC mode. Figure 5.5: MNC call ow for session transfer and retrieval The MN (IP address is ) rst sends INVITE without SDP

42 CHAPTER 5. DESIGN 31 body to the local device (IP address is ). The local device responds with its own media parameters, which include the address and port number of its media subsystem, as well as a list of codecs it supports. MN will then update the session with the CN by sending a re-invite containing the media parameters of the local device. The re-invite request (3) looks like: INVITE sip:cn@example.com SIP/2.0 From: <sip:mn@example.com>;tag=n1m64mxqaqn2b To: <sip:cn@example.com> Call-ID: 9a4a206a-4b59-122b-6ba c5a0 Content-Type: application/sdp Content-Length: 166 v=0 o= IN IP s=c=in IP t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 After the CN responds to the MN, the MN will complete the session migration by sending an ACK request containing the CN's media parameters to the local device. 3PCC Flow I is utilized in MNC mode because as shown in Fig. 5.5 (a), after the local device responds to the MN with 200 OK (2), it needs to wait the MN to send ACK with the CN's media parameters (6). A SIP UAS will periodically retransmits the 200 OK response until the ACK arrives [34]. If the ACK is not received in a certain amount of time, the session should be terminated. This is accomplished with a BYE. In the case of session mobility, the MN has established a session with the CN before transferring the session to the local device, thus the re-invite (3) will be immediately answered by the CN unless the CN is suddenly disconnected. Retrieval of a session is straightforward in MNC mode, since the signaling session is maintained in the MN after session transfer. Fig. 5.5 (b) shows the call ows for session retrieval. The MN simply sends a re-invite to the CN with its own media parameters. As a result, a new media session will be established between them, replacing the media session between the local

43 CHAPTER 5. DESIGN 32 device and the CN. The MN then sends a BYE request to the local device to terminate the signaling session between them, as well as the media session between the local device and the CN. Session Hando Mode In Session Hando (SH) mode, the MN completely transfers both the signaling session and media session to the local device. SH mode utilizes SIP REFER method [45]. REFER method is typically utilized to implement Call Transfer [46], a telecommunications mechanism that enables a user to relocate an existing call to another telephone or attendants console. When session mobility using REFER is rst proposed in [38], from the perspective of SIP signaling, it is identical to a basic call transfer, which is shown in Fig. 5.6 (a). Notice that the session initialization between the MN and the CN is left out in the call ow. This procedure takes place before session mobility. Figure 5.6: Call ow for basic call transfer and SH An important dierence is that in a basic call transfer, the refer target is typically a dierent person or logical identier from referrer; by contrast, in

44 CHAPTER 5. DESIGN 33 session mobility, the referrer will continue to use the session on the transfer target device. This dierence leads to the dierent design principle of session mobility. As Fig. 5.6 (a) depicts, in a basic call transfer, the MN explicitly requires the CN to contact a local device, which URI is presented in the Refer-TO header [45]. Hence, in a typical implementation, the User Agent (UA) of CN will notify the user of the transfer request, and let user determine whether to accept it. However, this does not apply to session mobility, as it conicts with the requirement 6 in Sec : "session transfer should not either require any manual interruption, or appear to the remote participant as a new call". This requirement constrains that session mobility should be transparent from the user of CN, thus neither as a explicit call transfer nor a new call. Therefore, in the IETF Internet-Draft [40], the signaling of SH mode is eventually similar to an attended transfer [46], as shown in Fig. 5.6 (b). Dierent from a basic call transfer, in SH mode, the MN (referrer) sends a REFER request to the local device instead of the CN, and let the local device contacts the CN. The INVITE request from the local device includes a Replaces header [23], which identies the dialog [34] between the MN and the CN. Therefore, after receiving this request, the CN uses the new session with the local device to replace the session with the MN. A simplied example of the REFER request (1) looks like: REFER sip:local.device@example.com SIP/2.0 From: <sip:mn@example.com>;tag=ad0pm797zuc1j To: <sip:local.device@example.com> Call-ID: 8c6d081a-4b57-122b-acb c5a0 Refer-To: <sip:cn@example.com? replaces=7d3eb172-4b57-122b-acb c5a0; from-tag%3d936xjcs42jpeq;to-tag%3dj5qs5ee399s7p> Referred-By: <sip:mn@example.com> An INVITE request with Replaces header (3) looks like, in part: INVITE sip:cn@example.com SIP/2.0 From: <sip:local.device@example.com>;tag=j68uz3adkvjas To: <sip:cn@example.com> Call-ID: 8c6d4546-4b57-122b-6ba c5a0 Replaces: 7d3eb172-4b57-122b-acb c5a0; from-tag=936xjcs42jpeq;to-tag=j5qs5ee399s7p

45 CHAPTER 5. DESIGN 34 Simultaneous Session Transfer Simultaneous session transfer means both endpoints can move their session without locking the other side. There are two cases concerning simultaneous transfer. The rst case is that after one participant (the MN) has transferred the session on his side, the other participant (the CN) also carries out a session transfer. This case is trivial if the rst transfer is done in SH mode, as the session in the MN's side has completely transferred to the local device, and the signaling session is established between the local device and the CN. Thus, the transfer request from the CN's side, either re-invite in MNC mode or INVITE with Replaces header in SH mode, will reach the local device directly, see Fig. 5.7 (a). The local device in the MN's side will process this INVITE request as the CN in the rst transfer. Figure 5.7: Simultaneous session transfer If the rst transfer is done in MNC mode, the second transfer will be more complicated. The signaling session is still maintained in the MN, thus the transfer request from the CN's side will reach the MN, see step 7 in Fig. 5.7 (b). Apparently, an additional mechanism is needed to support this case. The IETF Internet-Draft [40] suggests that when the MN receives a transfer request from the other participant in the CN's side, it must send a re-invite to the local device with the media parameters contained in this transfer request (step 8 in in Fig. 5.7 (b)). Subsequently, the MN includes the param-

46 CHAPTER 5. DESIGN 35 eters returned from the local device in the 200 OK response to the transfer request (between step 8 and step 9). Eventually, the media session will be established between the two local devices in both sides, see step 9 in Fig. 5.7 (b). Fig. 5.7 only shows the procedure when the second transfer is done in SH mode. The same procedure is applied to the second transfer in MNC mode, so the MN processes the transfer request similarly. The dierence is in the CN's side: the second transfer request (a re-invite) is sent from the CN, instead of the local device in the CN's side. The second case is that both participants transfers the session at the same time. The IETF Internet-Draft [40] has also provided solutions to this case. In MNC mode, each endpoint sends a re-invite to the other one, so that both sides will receive a re-invite after sending a re-invite. Section 14.2 in [34] denes: "a UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE". Therefore, both endpoints will respond to the other with 491 response. Both parties will start a random timer once receiving this response, and each of them will send the re-invite again immediately when the timer res. If a re-invite reaches the other endpoint when this endpoint has also sent its re-invite, the above procedure will repeat again. Otherwise, the rst to receive the re-invite responds to it with the media parameters of its local device. Eventually, both endpoints send an ACK to their local device containing the media parameters of the other side. Likewise, 491 responses and the random timer are also applied to the situation where a session are moving in both endpoints using SH mode at the same time Personal Mobility The design outline of the personal mobility component is: the user has a unique service identier for all his personal devices, and the user can login his service in multiple personal devices with this identier at the same time, as shown in Fig Therefore, after the service is migrated between two personal devices owned by the same user, the user's service identier is kept in the new device. Furthermore, if the user wants to receive future calls in the new device, it only requires the SIP UA on the new device to inform the registrar server that it is active at the moment, and the SIP proxy server will route future incoming calls to it. Based on this design outline, the personal mobility component must provide the following services.

47 CHAPTER 5. DESIGN 36 Home PC Call Mobile Phone example.com Internet Tablet User Office PC Naming Service Figure 5.8: Example of personal mobility The naming service maps a user's service identier to all his registered personal devices and their location. SIP inherently supports this service by associating a group of contact addresses with a single address-of-record (AoR), and making proxy server and redirect servers do the translation. As described in [29], an AoR represents an identity of the user, and is not related to any device. Thus, in the case of this thesis, where only VoIP service is discussed, AoR is the user's service identier. SIP AoR is typically represented by an -like address, for instance, "sip:user@example.com". On the other hand, a contact address is associated with a particular device, and has a device-specic form, either related to the current location of the device, such as "sip: " or its DNS host name, such as "sip:user@ua1.example.com". By sending a registration to a SIP registrar, a SIP device can temporarily associate its contact address with the user's AoR, so that the device can receive requests that are sent to the AoR. In addition, multiple devices can be associated with the same AoR at the same time. The call to the AoR is routed either to all of them by parallel or sequential forking, or to a specic device by the active device tracking function that will be described in the next section. This section only focuses on the naming service, which must address the following two questions. The rst question is from the perspective of a user: How does a user congure the characteristic of his personal de-

48 CHAPTER 5. DESIGN 37 vices? Characteristic, as dened in [35], describes an aspect of a UA (device) which is not negotiable. For instance, whether the UA is a mobile phone or a PC. The main purpose of the characteristic is to distinguish dierent personal devices sharing the same service identier. A simple approach is to utilize the host name of a device, for instance, alicelaptop and alice-n800, in SIP registration messages. This is feasible because the host name of a particular device is usually associated with its characteristic by default. Even though the user can personalize the host name of any device to break this association, the host name can be still utilized to distinguish personal devices from the each other. Bluetooth [2] adopts a similar approach for its service discovery protocol, which dierentiates devices in a Personal Area Network (PAN) depending on their host names. The second question is from the perspective of a SIP User Agent (UA) representing the user: How does a SIP UA registers a personal device? The registration must convey both the characteristic and contact address of the personal device. Furthermore, UA capabilities can be also registered. As described in [35], characteristic of a device is described with the sip.description feature tag, which provides a textual description of the device, such as a phone or a PDA. As an example, a home PC would register with a contact that looks like, in part: REGISTER sip:example.com SIP/2.0 To: sip:user@example.com Contact: <sip:user@homepc.example.com> ;methods="invite,bye,options,ack,cancel,subscribe" ;audio ;video ;schemes="sip" ;description="<home-pc>" ;mobility="xed" ;class="personal" In addition, for legacy UAs which may not support sip.description feature tag, the characteristic can be also conveyed in the user part of the contact

49 CHAPTER 5. DESIGN 38 URL. For example, a mobile phone would generate a registration that looks like, in part: REGISTER sip:example.com SIP/2.0 To: sip:user@example.com Contact: <sip:mobile-phone@ > ;methods="invite,bye,options,ack,cancel,subscribe" ;audio ;schemes="sip" ;mobility="mobile" ;class="personal" Active Device Tracking Active device tracking function addresses the problem of routing the future incoming calls to a specic device preferred by the user. This preferred device should be the active device that is lastly used by the user. The personal mobility component must be capable of tracking the active device automatically. This means, it does not necessarily require users to explicitly congure the routing policy. By default, the future incoming calls will be forwarded to the Mobile Node (MN) in Mobile Node Control (MNC) mode, as the MN remains active after session transfer; and to the local device in Session Hando (SH) mode, as the session is completely transfered to the local device. In either way, the SIP UA on the active device will inform the registrar server that it is active at the moment after session transfer. The system should also be able to track the change of the active device. For instance, the user transfers his session from his mobile to the oce PC while entering the oce. After this call session, he makes a new call in his mobile. Thus, the mobile becomes the active device instead of the oce PC. This can be achieved by dening a set of actions that make a device active, such as making a call and sending an instant message. Each time when any action is performed, the SIP UA on the device must update the active device information to the registrar server. Besides automatic tracking of the active device, the user should also be able to explicitly specify a device as the current active device. This can be done by applying the concept of updating the status information such as online and oine in the presence service. The active device information must be visible to all personal devices that are registered to the same identier. Therefore,

50 CHAPTER 5. DESIGN 39 in one personal device, the user can specify any personal device as the active device via the User Interface (UI), not necessarily the current device that the user is actively using. Discovery of Personal Devices Since dierent personal devices of a user share the same identier, the current service discovery component needs to be extended for indicating the characteristic and contact address of each personal device, so that they can be distinguished from each other. However, there is another problem: even if two devices are in close proximity, they are not necessarily in the same network. For instance, a user is having a VoIP call in his mobile phone that uses 3G data network, when he enters his oce, he wants to move the call to his oce PC that uses the oce LAN. However, in this case, the mobile phone can not automatically detect the oce PC using service discovery protocol such as SLP and UPnP. Therefore, the question is: How to make devices physically near each other, but far away in the network, be able to discover each other? When a device is successfully registered to an address-of-record (AoR), the response to the REGISTER request contains the complete list of of existing registered contact addresses. Thus, this device can discover all other personal devices of the same user. However, another problem is how can other previously registered devices immediately discover this newly registered devices of the same user. To address this problem, this thesis employs the SIP event package for registrations [31], a standardized solution provided by IETF. This approach is based on the asynchronous event notication mechanism [30] of SIP. Generally, when a SIP UA successfully registers to an AoR, it also subscribes to the registration event package for this AoR. Thereby, the SIP UA will be notied with the information in regarding to this registration. A registration is the binding between an AoR and one or more contact addresses. Registrations are soft state, changing dynamically because new contact may be added and old contact may be deleted or expired. The SIP registrar server will generate a notication to all subscribers when any change occurs in the state of a registration. Since all personal devices of the same user share the same service identier, which is the AoR in the case of this thesis, they are able to discover each other if they subscribe to the registration event package for this service identier. In this way, any personal device

51 CHAPTER 5. DESIGN 40 will be notied whenever a new device has registered to the same service identier, or the registration of an existing device is expired. Based on the above analysis, the discovery service can be illustrated with Fig It presents a following usage scenario: a user is having a VoIP call in his mobile phone; he turns on his home PC after arriving at home, and logins his VoIP service using his service identier; his mobile phone automatically retrieves the contact information of the home PC, thus subsequently the user transfers the VoIP session from the mobile to the home PC. As Fig. 5.9 shows, the provision of the discovery service consists of the following steps: Figure 5.9: Discovery of personal devices 1. When a user logins his service in one of his personal devices, its SIP UA immediately registers the device with its characteristic and contact address. In the above scenario, the SIP UA on the home PC

52 CHAPTER 5. DESIGN 41 registers to the SIP registrar server, which will establish a new binding between the AoR sip:user@example.com and the contact address sip:user@hompc.example.com if the registration is successful (See step 1 in Fig. 5.9). 2. The response to the REGISTER request contains the complete list of existing bindings. The SIP UA on the home PC will present these information to the user via a special buddy list, with a name like "Personal device list". Each item in the list indicates the characteristic of a personal device, for instance, mobile phone and oce PC. In addition, the underlying device of this SIP UA is excluded out of the list. Instead, it is explicitly marked as the "self device" (See step 2 in Fig. 5.9). 3. The SIP UA on the home PC subscribes to the registration event package for its service identier (See step 3 in Fig. 5.9). This Implies that previously registered devices have also subscribed to this same event package. The subscription is done by sending a SUBSCRIBE request to the SIP registrar server. For instance, the mobile phone sent the following SUBSCRIBE message, in part: SUBSCRIBE sip:registrar.example.com SIP/2.0 From: sip:user@example.com;tag=123aa9 To: sip:user@example.com Contact: sip:mobile-phone@ Event: reg Accept: application/reginfo+xml The SIP events specication requires to specify the name of the event package [30]. The name for registration event package is "reg" and appeared in the Event header in SUBSCRIBE and NOTIFY requests [31]. Furthermore, the To header species the AoR for the registration event package to which this SIP UA wants to subscribes. 4. The registrar server noties all SIP UAs that have registered to the AoR sip:user@example.com. As step 4 in Fig. 5.9 shows, both the mobile phone and the oce PC are immediately notied about the contact address and characteristic of the home PC. This information is included in a NOTIFY message, which looks like, in part: NOTIFY sip:mobile-phone@ SIP/2.0 From: sip:user@example.com;tag=xyzygg

53 CHAPTER 5. DESIGN 42 To: Contact: sip:registrar.example.com Event: reg Content-Type: application/reginfo+xml Content-Length:... <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="1" state="partial"> <registration id="a7" state="active"> <contact id="76" state="active" event="registered" duration-registered="0"> <display-name>home-pc</display-name> </contact> </registration> </reginfo> The registration information document is included in the body of NO- TIFY message. It begins with the root element tag "reginfo". The value of the state attribute is "partial", which indicates that this document contains only information about those contacts which have changed state, instead of all contacts registered to this AoR. The "registration" element refers to one registration event package. The aor attribute represents the AoR for this registration. The "registration" element has a list of "contact" elements, each one corresponds to a single contact registered to this AoR. Each "contact" element contains an "uri" element, which indicates the contact address of this contact; it also contains an optional "display-name" element if this contact address was registered with the sip.description feature tag, which indicates the characteristic of this contact. In addition, the event attribute of the "contact" element indicates the event which caused the state change of this contact. In the above example, the value of the event attribute is "registered", meaning this contact is newly registered to this AoR. Other valid values include "expired", "deactivated" and "unregistered". Eventually, an item representing the home PC appears in the "Personal device list" on the mobile phone. Thus, the user can simply select the corresponding item in the list and press the transfer button. Afterwards, the SIP UA on the mobile phone will automatically transfer the user's current session of his VoIP service to the contact address of the home PC.

54 Chapter 6 Implementation The main purpose of the following implementation is to validate our design on a heterogeneous testbed setting which consists of both xed and mobile devices, as well as both wired and wireless network. In practice, this implementation work is done in an all-linux environment, which consists of Linux PCs and laptops, as well as mobile Linux devices. Furthermore, the underlying network infrastructure consists of xed Ethernet and WLAN segments. Cellular packet-switched networks such as Universal Mobile Telecommunications System (UMTS) are left out in this study. Despite the limitation of this testbed setting, our intention is to investigate aspects of deployment, provisioning, performance and latency. The observation will eventually guide us to rene the usability of the proposed service migration system further. 6.1 Implementation Overview Our strategy for implementation is to extend the service migration functionality to an existing SIP phone. We nally decide to modify Sofsip-cli [42], because it is open source and free. Further, it is a console mode client demonstrating how to use Soa-SIP library [43], thus it is easier to edit than other open source SIP phones. Despite its simplicity, Sofsip-cli is a fully functional VoIP client, and its functions includes call establishment and termination, instant messaging, registration and NAT traversal. Moreover, Sofsip-cli is completely written in C,thus it is potentially easier ported to embedded platforms. Likewise, we decide to utilize Nokia Internet tablets [25, 26] as the mobile platform for this work because it is a Linux-based mobile device, thus ac- 43

55 CHAPTER 6. IMPLEMENTATION 44 cording with all-linux environment for this work. Its development platform maemo [22] consists of well-known desktop Linux libraries such as GTK+ [13], GLib [11] and GStreamer [12], thus making application porting trivial, especially for command line based applications. In addition, with the Scratchbox cross-compilation toolkit, development for Maemo is much easier than many other embedded Linux platforms. Besides Soa-SIP, our application also utilizes other libraries, see Fig Figure 6.1: Overview of the implementation The service discovery component is composed of a UPnP control point and a device. It is implemented on top of CyberLink for C library, a development package for UPnP. It controls protocols that are applied in UPnP automatically, including SSDP, SOAP, HTTPU and HTTPMU. CyberLink library enables quick creation of UPnP devices and control points. Multiple media engines are implemented in Sofsip-cli. The default one is GStreamer plus Farsight plugins (fsgst). It employs gstreamer-0.10 and additional RTP plugins from the Farsight project [10] to support basic media for voice calls. Another engine is plain GStreamer (gstreamer), which only uses plugins in the main gstreamer packages. Both engines utilize G711 codec. In addition, a dummy implementation is also included for testing

56 CHAPTER 6. IMPLEMENTATION 45 purposes. It does not send any RTP packets and drops any RTP packets received. OpenSER is utilized to congure SIP registrar and proxy servers, which is necessary for implementing personal mobility component. This chapter concentrates on the implementation of the SIP UA with signaling features presented in the session mobility component. Therefore, in the following sections, we will briey introduces the Soa-SIP library, and give the implementation details of the session mobility component. 6.2 Soa-SIP Library Soa-SIP is composed of several layered modules that are categorized into several groups, including common runtime libraries, which contains SU module that provide functionality of sockets, memory management and threads; SIP Signaling, which contains NUA module, NTA module, and SIP module that processes SIP messages and headers; SDP processing, which contains SOA module that serve as the SDP Oer/Answer engine; other group includes STUN module that provides NAT traverse functionality. NUA and NTA provide the primary application programming interfaces (APIs) to application developers. NUA, which stands for High-Level User Agent Module, is utilized for implementing SIP clients such as VoIP and IM applications, as it provides very high-level API to fully control to the SIP protocol engine below it. NUA hides low-level signaling and media management, such as SIP message parsing, dialog management, oer/answer negotiation, and registration management, from the application developer. On the other hand, NTA, the Transaction API, provides direct APIs to SIP transaction, transport and message handling, thus it is designed for building SIP server elements such as proxies and registrars. Also, NUA is implemented on top of NTA. NUA is applied to the implementation of this work, as the service migration system is integrated with a SIP UA. In the following sections, some fundamental characteristics of NUA will be discussed SIP Messages Handling Incoming Messages NUA uses event driven pattern to handle incoming SIP messages. An application must create a root object and the callback routine to handle NUA

57 CHAPTER 6. IMPLEMENTATION 46 events. The root object represents the main event loop of the task, and the call back routine handles NUA events, including I/O activity, timers and most importantly, incoming SIP messages. The call back routine will be invoked by the event loop when a certain event, such as successful registration or an incoming call, occurs. The NUA denes an enumeration type for events, and each event is identied by a predened value. Thus, based on the value of the event, the call back routine can dispatch a event to a corresponding function. An example of a switch statement inside the call back routine body is shown as follows: switch (event) { case nua_i_invite: ssc_i_invite(...); break; } case nua_i_refer: ssc_i_refer(...); break; case nua_r_invite: ssc_r_invite(...); break;... nua_i_invite identies an incoming INVITE request; likewise, nua_i_refer identies an incoming REFER request; nua_r_invite represents a response to an INVITE request. Outgoing Messages On the other hand, for outgoing SIP messages, NUA also has built-in functions support: for requests, NUA denes a dedicated function for every method, such as: nua_invite(), nua_bye(), nua_refer(), etc; for responses, NUA denes nua_respond() function to generate responses with given status code. Sec will give more details of generating a SIP request message NUA Objects NUA has object-oriented API. The root object has been introduced in the previous section. Several other NUA objects will be described in this section.

58 CHAPTER 6. IMPLEMENTATION 47 NUA Stack An instance of SIP stack is represented by the NUA stack object, which has the type nua_t. A stack object is created by nua_create() function and deleted by nua_destroy() function. When creating an NUA stack object, it is associated with the root object of this stack (root), the call back routine (callback), and the application using NUA services (app): nua_t *nua_stack = nua_create( root, callback, app,..., TAG_NULL()); Application The application is responsible for dialog management, memory handling, media engine maintenance, etc. It is dened as a structure, for instance: typedef struct ssc_s { su_home_t *ssc_home; su_root_t *ssc_root; nua_t *ssc_nua; SscMedia *ssc_media; ssc_oper_t *ssc_operations; char *ssc_address... } ssc_t; The application denes data areas for storing context information it needs for processing the events, including: ssc_home is a pointer to the memory home object (type su_home_t), which provides memory management with a set of APIs. The home object and its APIs belong to the su module of Soa-SIP library; ssc_root is a pointer to the root object; ssc_nua is the pointer to the NUA object utilized by this application; ssc_media is a pointer to the media subsystem. SscMedia is a self-dened structure; ssc_operations is a pointer to a linked list which stores all active SIP dialogs maintained by this application. Alternatively, other data structure such as hash table can be also utilized for dialog management; ssc_address stores the current AoR of this SIP UA.

59 CHAPTER 6. IMPLEMENTATION 48 An application pointer is passed to the call back routine when any event occurs, thus each subroutine can utilize context information maintained by the application. For instance, when receiving an INVITE request, the NUA stack will invoke the call back routine, and pass the application pointer along with the nua_i_invite event to it. Subsequently, the call back routine will call the ssc_i_invite() function, and eventually pass the application pointer to it. ssc_i_invite() checks if this incoming INVITE request has Replaces header. If yes, it compares the dialog information included in the Replaces header with its current INVITE dialog, which can be retrieved from the dialog list maintained by the application (ssc_operations). Operation Handle A SIP session consists of SIP dialog, media session, and state machine. It is represented by the operation handle object in NUA. The operation handle object has type nua_handle_t, and is created by the application using nua_handle() function for sending messages, and by stack for incoming requests such as INVITE or REFER that initiates a new dialog. Sec will further describe how to create an operation handle object. Operation Context The application usually encapsulates the operation handle with operation context. As the above application sample code shows, the application uses ssc_oper_t structure to store the nua_handle_t object, which includes SIP dialog information. ssc_oper_t can also store other context information such as the SIP URI of the remote participant, which method initiates this operation handle (IN- VITE or REFER), and the call state of this handle, such as pending (waiting for the creation of media subsystem), sent (INVITE has been sent) and recv (INVITE received), together with a pointer to the next ssc_oper_t object maintained by the application. When receiving responses, the NUA stack pass the operation handle object along with its operation context (ssc_oper_t) to the call back, so that the corresponding subroutine can process the event utilizing the related context.

60 CHAPTER 6. IMPLEMENTATION Tags NUA uses tags to pass arguments to functions. Tags enable passing a variable number of parameters having non-xed types, and they are mainly utilized by applications to generate SIP messages. For instance, when a SIP UA initiates a session, it creates a new operation handle object for establishing an INVITE dialog. The URI of the remote endpoint is passed to the operation handle object using SIPTAG_TO_STR() tag, thus will be placed in the To header: nua_handle_t *op_handle = nua_handle(nua, NULL, SIPTAG_TO_STR("sip:cn@example.com"), TAG_END()); The application subsequently sends an INVITE request by passing the operation handle object to the nua_invite() function: nua_invite(op_handle, SOATAG_USER_SDP_STR(local_sdp), SOATAG_RTP_SORT(SOA_RTP_SORT_REMOTE), SOATAG_RTP_SELECT(SOA_RTP_SELECT_ALL), TAG_END()); SOATAG_USER_SDP_STR() passes the SDP string to the INVITE request. SOATAG_RTP_SORT(SOA_RTP_SORT_REMOTE) tag indicates that when selecting the common codecs, the rst local codec supported by remote end is preferable. SOATAG_RTP_SELECT(SOA_RTP_SELECT_ALL) tag indicates that when generating answer or second oer, all supported codecs are included in the list of payload types.

61 CHAPTER 6. IMPLEMENTATION Implementation of Session Mobility Component Mobile Node Control Mode As the MNC mode is capable of interoperating with legacy applications, it does not require any special changes to the local device and the CN. Therefore, this section only focuses on the implementation details of the MN. Both session transfer and session retrieval will be discussed, and relative state diagrams will be illustrated. Only the most important state transitions will be discussed in detail. During these transitions, the MN explicitly sends requests to the other two entities involved in the session transfer. Session Transfer Based on the SIP call ows in Sec , Fig. 6.2 describes the state diagram of the MN in MNC mode for session transfer. Figure 6.2: State diagram of MN in MNC mode for session transfer 1. Init - Calling_local During the transition of above two states, the MN sends a INVITE request without any SDP body to the local device, see call ow (1) in Fig. 5.5 (a). This is done by calling nua_invite() function:

62 CHAPTER 6. IMPLEMENTATION 51 nua_invite(local_handle, NUTAG_AUTOACK(0), NUTAG_MEDIA_ENABLE(0), TAG_END()); local_handle represents the operation handle for sending the INVITE to the local device. This handle is created by the MN. NUTAG_MEDIA_ENABLE(0) tag disables built-in media session handling. Otherwise, by default, nua_invite() creates a soa media session, and the SDP description of the soa media session is included in the INVITE request as the message body. Therefore, as no extra tag containing SDP is given to this function, the INVITE request will not include any message body. NUTAG_AUTOACK(0) tag prevents the NUA stack acknowledging the local device automatically, as the application will insert the CN's media parameters in this ACK request. See call ow (6) in Fig. 5.5 (a). 2. Completing_local - Calling_cn During the transition of these two states, the MN sends a INVITE including the media parameters of the local device to the CN, see call ow (3) in Fig. 5.5 (a). This is achieved by the following code: nua_invite(cn_handle, NUTAG_AUTOACK(0), NUTAG_MEDIA_ENABLE(0), SIPTAG_CONTENT_TYPE_STR("application/sdp"), SIPTAG_PAYLOAD_STR(local_sdp), TAG_END()); cn_handle represents the operation handle for sending INVITE to the CN. It is also created by the MN. NUTAG_AUTOACK(0) also disables the automatic acknowledgment to the CN. Thus, after receiving 200 OK response to this INVITE request, the MN will acknowledge both the CN and the local device in parallel. NUTAG_MEDIA_ENABLE(0) is also set for this function, because the MN will not use its own media parameters for this INVITE request. SIPTAG_PAYLOAD_STR(local_sdp) indicates the NUA stack to include

63 CHAPTER 6. IMPLEMENTATION 52 the media parameters of the local device in the outgoing INVITE. In addition, the SIPTAG_CONTENT_TYPE_STR() tag indicates the Content- Type header is "application/sdp". 3. Completing_cn - Controlled During the transition of these two states, the MN sends an ACK with the media parameters of the CN to the local deviec, see call ow (6) in Fig. 5.5 (a). This is done by calling nua_ack() as follows: nua_ack(local_handle, SIPTAG_CONTENT_TYPE_STR("application/sdp"), SIPTAG_PAYLOAD_STR(cn_sdp), TAG_END()); local_handle is the same operation handle for sending the INVITE request to the local device. Besides, SIPTAG_CONTENT_TYPE_STR() tag and SIPTAG_PAYLOAD_STR() tag do the same job as in the above nua_invite() function. Session Retrieval Fig. 6.3 describes the state diagram of the MN in MNC mode for session retrieval. 1. Controlled - Retrieving nua_set_hparams(cn_handle, NUTAG_AUTOACK(1), NUTAG_MEDIA_ENABLE(1), TAG_END()); cn_handle is the same handle for sending the INVITE to the CN. NUTAG_MEDIA_ENABLE(1) enables the built-in SOA media session handling, as the MN will send a re-invite request containing its own SDP to the CN when retrieving the session. NUTAG_AUTOACK(1) is set as the MN will automatically acknowledge the CN after receiving 200 OK response.

64 CHAPTER 6. IMPLEMENTATION 53 Figure 6.3: State diagram of MN in MNC mode for session retrieval Afterwards, the MN generates a re-invite messge using a similiar nua_invite() function presented in Sec Session Hando Mode The Refer request raises complicated state transitions, as it creates an implicit subscription between the local device and the MN. However, Soa-SIP manages this subscription automatically, thus, unlike MNC mode, the implementation of SH mode does not involve very complex state transitions. On the other hand, each entity participated in the SH mode needs special handling features for SIP signaling. Thus, this section will be discussed from the viewpoint of the MN, the local device and the CN respectively. Mobile Node In SH mode, the MN sends a REFER request to the local device, see call ow (1) in Fig. 5.6 (b). This REFER request indicates the contact information of the CN in the Refer-To URI: nua_refer(local_handle, SIPTAG_REFER_TO(refer_to), TAG_END());

65 CHAPTER 6. IMPLEMENTATION 54 A Replaces header eld is also included in the Refer-To URI, containing the Call-ID value, From and To tags of the current call dialog between the MN and the CN. The application gets a Replaces header by passeing the operation handle object for the call session to the nua_handle_make_replaces() function. Furthermore, it uses sip_headers_as_url_query to format the Replaces header as a URL query. Subsequently, the application constructs the Refer-To header by concatenating the CN's URL and the query containing the Replaces header, and nally sends the REFER request to the local device using nua_refer() function: Local Device The local device makes a call in response to the REFER request, by sending a INVITE request with Replaces header: nua_invite(cn_handle, NUTAG_NOTIFY_REFER(mn_handle), NUTAG_REFER_EVENT(event), SOATAG_USER_SDP_STR(local_sdp), TAG_END()); A REFER request implicitly establishes a subscription to the refer event, thus the local device will use SIP events to report the results of the CN [45]. Soa-SIP stack can manage this subscription automatically. NUTAG_NOTIFY_REFER() tag associate the REFER dialog (mn_handle) with INVITE dialog (cn_handle). In addition, When the local device receives the Refer request, the nua_i_refer event will contain a suitable event header for sending NOTIFY to the MN. NUTAG_REFER_EVENT() tag passes this event header back to the stack, thus the stack will automatically generate NOTIFY requests to the MN to inform the call progress to the CN. Correspondent Node While the MN must take care of generating Replaces header from a dialog, the CN is responsible for matching the current call session with the Replaces header in the received INVITE request. The application can utilize nua_handle_by_replaces() function to obtain a new reference to an existing handle based on Replaces header. If the

66 CHAPTER 6. IMPLEMENTATION 55 function returns NULL, it means the Replaces header does not match the current call session, thus the application must refuse the transfer request with a "481 Call/Transaction Does Not Exist" response. Otherwise, it can accept the transfer request and updates its media subsystem according to the SDP parameters included in the INVITE request Linux Tablets Our implementation has been also validated on Nokia 770 and N800 Linux tablets. Their OS versions are Maemo OS 2006 and 2007 Linux distribution respectively. All versions support libglib2.0 and libgstreamer0.10. Development for Maemo is done in Scratchbox, a cross-compilation toolkit for embedded Linux platforms. Dierent Scratchbox versions correspond to dierent Maemo OS. However, all of them provide a virtual Linux environment with a full set of libraries supported by tablets. Thus, application porting is easy, generally involving the following steps: 1. Building and installing the Soa-SIP library in Scratchbox. It is identical to doing this procedure in the PC environment. This is done by executing the following commands in the source folder of Soa-SIP sequentially:./congure, make, make install. 2. Compiling the Sofsip-cli program. The binary outcome can be copied to tablets via USB, Bluetooth or SSH. 3. Before executing the binary in tablets, we need to make Debian packages of the Soa-SIP library for tablets, as it is not supported in Maemo OS 2006 and 2007 by default. This procedure is as trivial as building applications: in Scratchbox, executing "dpkg-buildpackage -rfakeroot" from the source folder of Soa-SIP will make the Debian packages. 4. In order to install the Soa-SIP library in tablets, we need to get root access on tablets. A easy way is to install both a SSH client and server on tablets. Maemo website provideds one-click installation le for both OS 2006 and With SSH tools installed, there are two ways to get root access. The rst way requires an X terminal installed on tablets, so that we can use "ssh root@localhost" to become root. The other way is using SSH to remotely access to tablets with root account from a PC. The second way is preferable, as working in PC is much more ecient than in tablets. Finally, with root access enabled, the Soa-SIP library

67 CHAPTER 6. IMPLEMENTATION 56 can be uploaded to tablets using "scp" command, and installed with "dkpg -i *.deb". 6.4 Implementation Results At the moment of writing this thesis, the service migration demonstrator has implemented the following features: 1. Two dierent modes are implemented: Mobile Node Control (MNC) and Session Hando (SH). These two modes are presented to end users as "control device" and "switch device". 2. Support for heterogeneous devices. The prototype implementation can work on both Linux PC and Nokia Internet Tablets, including 770 and N Interoperability with legacy applications. In MNC mode, both the local device and the correspondent node (CN) can be ekiga [8], an open source SIP phone for Linux. 4. A straightforward implementation of session transfer is done in a way that the CN stops sending media stream to the MN, restarts the media engine, and sends the media stream to the local device. A more optimized implementation is that the CN redirects destination IP address and port number while running. Our implementation follows the straightforward way in PCs and laptops, and optimized way in N800 mobile devices. We will later justify the reason for this in Sec Session retrieval. A device can retrieve a session after transferring it to another device. 6. Service discovery using Universal Plug and Play (UPnP). However, service discovery component is not integrated with the session mobility component yet. 7. The personal mobility component is implemented and provided by the integration framework of the Nomadic Applications (NomAp) project. It is designed by another NomAp project member in a dierent way from this thesis. Though not based on SIP, the implementation of this componnet feasibly proves the concept of maintaining the same service identier in the new terminal after service migration.

68 Chapter 7 Evaluation 7.1 Requirements Evaluation In this section, the requirements presented in Sec. 4.1 are evaluated against the outcome of the design and implementation. In addition, some requirements are also evaluated against related work presented in Sec. 2.2 and Sec. 3.2, which are eventually compared with the service migration system proposed in this thesis. General Requirements R1. The service migration system should be easy to deploy within current VoIP services. It must be also scalable since VoIP services are typically provided globally. In this thesis, the proposed service migration system is deployed in the application level, similar to other SIP-based approaches. An apparent drawback of choosing application level is that the system can not be reused by other service migration applications. For instance, another Video-on-demand services that leverages service migration must implement its own component. In contrast, the middleware framework [6] introduced in Sec deploys application-neutral mobility functions, including the management of user location, personal information and state transfer, in the middleware layer. Therefore, this framework eliminates the need to make each application mobility-aware. Rather, applications can share the services provided by the middleware, thus the additional development overhead is small. The system level solution is rst excluded, as it imposes huge changes to 57

69 CHAPTER 7. EVALUATION 58 infrastructures (OS, network). As a result, its deployment leads to unreasonable high costs to both end users and VoIP service providers. Comparing to the middleare level, the application level is more suitable for this work, because VoIP services can be regarded as stateless services, as a VoIP session has no complicated state. Thus, there is no need for transferor device and transfer target device to exchange any state information concerning the VoIP call. A session transfer only involves simple signaling operations to reestablish connections with the remote participant in the new device. On the contrary, the middleware framework [6] mainly targets at multimedia services with complicated state information, such as video and audio streaming. The main functionality of the middleware component is managing the service state and context information, such as streaming URL, the position of last frame, the media streaming protocol and its format. As VoIP services do not involve complicated state management, it would be complex to extract simple signaling operations from the application to a middleare component. Especially when they are within the scope of standard SIP signaling, and coupled with call management which are tightly integrated with SIP architecture. Consequently, this thesis applies an application level approach. From another perspective, the service migration system can be also categorized into two classes: device centric and network centric [24], see Fig Figure 7.1: Device centric and network centric architecture for the service migration system In a device centric approach, the main session transfer mechanism resides in

70 CHAPTER 7. EVALUATION 59 the device. Obviously, the proposed system in this thesis falls into this category, as all signaling mechanisms concerning session mobility are performed in an end-to-end manner. The only need for infrastructure is to support device location management and personal mobility. In contrast, in a network centric approach, the network infrastructure takes care of most session transfer mechanisms. End devices only inform the network infrastructure to initiate the session transfer. This category includes the following works. Service mobility proxy [16] employs a proxy entity to handle all session migration and media adaption to dierent devices. The middleware framework [6] utilizes a network entity named User Metadata Server, which stores service state information. Thus, during a service migration, the old client host stores the service state information to the server, while the new client host retrieves this information to reinstantiate the same service. Likewise, browser session preservation and migration [44] utilizes a proxy server to store browser session snapshots during a session migration. The device centric approach is adopted in this thesis, because of our requirement for high scalability. The other approach increases complexity in the network, which possibly results in high deployment cost. Therefore, the network centric approach would be limited to localized smart spaces [24], rather than VoIP services that typically require global wide provision (considering Skype and Gtalk). Moreover, in a network centric approach, triangular routing is involved during a session transfer. This would possibly aect the performance. Obviously, because of the real-time characteristic of VoIP services, a low end-to-end latency during a session transfer is absolutely necessary. Therefore, similar to Mobile IP without route optimization may be not suitable for real-time services, a device centric approach is more preferable for this thesis. R2. The service migration mechanism must support both service migration enhanced applications and legacy applications. Moreover, it must be capable of cooperating with future IP telephony systems. Most of current hardware-based SIP phones or software-based SIP phones such as ekiga and KPhone do not support the signaling of Session Hando (SH) mode. In contrast, Mobile Node Control (MNC) mode only utilizes common signaling for session establishment, namely, INVITE and re- INVITE, thus it can interoperate with legacy devices and applications. Our implementation shows that a session can be transferred from our modied Sofsip-cli to an ekiga SIP phone [8], while the remote participant is also using

71 CHAPTER 7. EVALUATION 60 ekiga. Furthermore, as mainly targeting at VoIP services, it is essential for the proposed service migration system to be capable of cooperating with emerging IP telephony services in next generation cellular networks. The choice of SIP helps to achieve this, as SIP is chosen by Third Generation Partnership Project (3GPP) as the standard for session management in the Internet Multimedia Subsystem (IMS). Service Discovery Requirements R3. The user's devices should support service discovery in his local network. R4. Users' devices should be able to learn the capabilities of potential transfer target devices. These two requirements for service discovery are analyzed together as follows. There are three general approaches for discovering devices that are in close proximity. The rst way is to use short-range wireless protocols such as Bluetooth Service Discovery Protocol [2]. In this approach, devices are communicating directly over a short-range radio frequency. The second way is to use IP-Multicasting based protocols, such as Universal Plug and Play (UPnP) [50], Zeroconf (Multicast DNS) [5], and Service Location Protocol (SLP) [14]. The service discovery component in this thesis adopts this approach, in which devices must be within the same subnetwork in order to discover each other. The third way aims to discover devices that are part of the same DNS domain, and possible solutions include server-mode SLP and DNS-based service discovery [4]. The rst approach has the disadvantage of depending on special radio interface, so it does not apply to devices without this interface. For instance, stationary computers do not usually have Bluetooth capacity. Furthermore, the other two approaches have the shortcoming of assuming that devices that are physically close are also within the same network or part of the same DNS domain. This assumption does not apply to many practical situations where devices are not belong to the same network even when they are physically nearby, as discussed in Sec In this work, the discover service provided by the personal mobility component gives an simple solution to this problem. However, it only ts the situation where all personal devices share the same service identier, thus they can discover each other by subscribing to the event package for registra-

72 CHAPTER 7. EVALUATION 61 tions of this identier. Apparently, this solution is not suitable as a general service discovery approach. Session Mobility Requirements R5. Session transfer should involve minimal disruption of the media ow. Most functional requirements can be analyzed with qualitative method. By contrast, this requirement can be only evaluated with quantitative method. Thus, it will be analyzed in Sec. 7.3, based on the performance measurement of our prototype implementation. R6. Session transfer should not either require any manual interruption, or appear to the remote participant as a new call. This requirement constraints that the session mobility should be transparent to the CN, thus the remote participant is unaware of a session transfer in the MN's side. In the proposed system, it is achieved by applying re-invite in MNC mode and INVITE with Replaces header in SH mode. See Sec Since a transfer request, either INVITE with Replaces header or re-invite, is not intended as a new call, with proper implementation techniques, the CN does not need to recreate the whole media subsystem when receiving the transfer request. Instead, it only updates it. The socket for incoming media stream is reserved, while the socket for outgoing media stream is modied according to the media parameters included in the transfer request. This results to a potential advantage for mobile devices. Due to their limited processing ability, recreating media subsystem may take a long time, especially when video calls are also enabled. This additional time may increase the session transfer latency as well as the disruption of media during transfer. However, our proposed system can possibly improve the performance by decreasing these values, as the CN only updates its media subsystem during a session transfer. This will be validated with the measurement of our prototype implementation in the next section. R7. It must be possible to retrieve a session after session transfer. Session retrieval means transferring the session back to the MN from the local device. It is straightforward in MNC mode, as discussed in Sec For SH mode, there are two cases regarding to session retrieval. The rst

73 CHAPTER 7. EVALUATION 62 case is trivial: transferring the session back from the local device to the MN. In this case, the user operates on the local device, specifying the URI of the MN and pushing the "switch device" button. In other words, this case of session retrieval is identical to a session transfer in SH mode, except the local device and the MN exchange their roles. The other more complex case is not addressed by our design: retrieving the session from the MN. This means, similar to MNC mode, the user operates on the MN and pushes a "retrieve" button, causing the session currently on the local device to be returned. In contrast to MNC mode, the MN does not maintain the signaling session after session transfer, thus it makes no dierence whether the MN had the session before transferring to the local device, or had not previously carried it. Therefore, for VoIP services, this case of session retrieval in SH mode can be viewed as a more general case: session transfer by pulling. It can be illustrated with the following usage scenarios: A user enters his oce while having a VoIP call in his mobile. He pushes a button in his oce PC, and the VoIP session automatically moves there. In this case, the user only needs the other free hand to operate on the PC while not interrupting the usage of his mobile until the call is transferred to the PC. An even greater user experience is when the session follows the user. This can happen in an intelligent home network where the sensors in the home track the user location and automatically transfer the session to the device in the vicinity of the user. The IETF Internet-Draft [40] provides a device centric solution for session retrieval in SH mode, see Fig It is accomplished by sending a nested REFER request from the new device to the old device which currently holds the session. Subsequently, the old device will act as the MN in a session transfer, sending a REFER request including its current session information to the new device, which acts as the local device and sends an INVITE request with Replaces header to the CN. A simplied example of the nested REFER request (step (1) in Fig. 7.2) looks like:

74 CHAPTER 7. EVALUATION 63 Figure 7.2: Session retrieval in SH mode REFER SIP/2.0 From: To: Call-ID: 8c6d062a-4b26-12cb-a6a a76c7b0 Refer-To: More detailed description of the above pulling mechanism, as well as its security consideration, can be found on the IETF Internet-Draft [40]. We have discussed in R1 of how a service, whether stateful or stateless, aects the choice of deployment level. Furthermore, it also aects how the pulling mechanism is conducted.

75 CHAPTER 7. EVALUATION 64 For stateless services such as VoIP, service migration by pulling can be treated as a trigger of pushing. When a user operates on the old device to push the session to a new device, the trigger is the user pushes the transfer button. On the other hand, when the user operates on the new device to pull the session from the old device, the new device sends a nested REFER request. After the old device receives this REFER request, it begins to push the session to the new device. Thus, apparently in the case of pulling, the trigger for the old device is replaced by receiving the nested REFER request. For stateful services, the pulling mechanism has an additional method: suspending the service at one device, and resuming it at another device. This is typically applied to network centric approaches, where the network infrastructure component serves as an anchor point for storing the service state. Thus, the old device pushes the service state to the server when suspending, while the new device pulls this state when resuming the service. The middleware framework [6], Browser session preservation and migration [44] and Internet Suspend/Resume [37] are all belong to this class. R8. The service migration mechanism should support simultaneous session transfer. Sec describes the solution to the situation when both endpoints attempt to transfer their sessions using the same mode. However, the IETF Internet-Draft [40] does not answer the situation where two endpoints are using dierent mode to transfer their sessions. Fig. 7.3 shows a possible solution for this case. From the step (1) to (3), both endpoints initiate a session transfer in their side, thus they will receive the transfer request from the other side after sending theirs. The CN will ignore the re-invite from the MN, while the MN can send a CANCEL request to the CN, see step (4). The MN obtains the media parameters of the local device in the CN's side (local device 2 in Fig. 7.3) from the INVITE request with Replaces header. Therefore, it sends an ACK containing these parameters to its local device (local device 1 in Fig. 7.3), and respond to CN's local device with the media parameters of its local device, see step (6) and (7) respectively. Afterwards, a new media session is established between the local devices in both sides.

76 CHAPTER 7. EVALUATION 65 Figure 7.3: Simultaneous session transfer where two endpoints are using dierent mode at the same time Personal Mobility Requirements R9. All personal devices owned by the same user should have the same service identier, and can be registered at the same time. It is not dicult to implement the signaling mechanisms of a service migration system by applying the SIP architecture. However, how to make the system usable and intuitive to end users, is not straightforward. By integrating personal mobility into a service migration system, this work improves its usability by allowing the user to use and identify all his personal devices with a unique service identier. In this way, the service is associated with the user rather than his devices, thus the access to services is also seamless and unied. The concept of buddy list is utilized to present all actively registered personal devices to the user. Since it is an essential feature for any IM or VoIP services, users have been already familiar with it. This makes the recognition and selection of personal devices intuitive.

77 CHAPTER 7. EVALUATION 66 The integration of personal mobility and session mobility must be seamless. Personal mobility does not aect the signaling procedure of session mobility, but it aects how the user species the transfer target device. The user can not utilize the service identier as the URI for the transfer target device, but instead he needs to specify its contact address. Moreover, in order to distinguish dierent personal devices sharing the same service identier, a contact address needs to convey the characteristic of the corresponding device. In the proposed design, the naming service dierentiates personal device from each other. The event notication mechanism ensures a personal device is able to obtain contact addresses of all other devices registered to the same identier in an asynchronous way. Therefore, at any time when a user wants to transfer the current session to another registered personal device of him, the contact address of the new device has always been pushed to his current device, and thereby its characteristic and contact information are displayed to the user via the buddy list of personal devices. R10. The user should have the freedom to determine which personal device to answer the future calls. Our design provides some basic mechanisms in the proxy server to forward incoming calls to the active device that is being used by the user. Besides automatic tracking of the active device, the user can also explicitly specify a device as the current active device. However, this requires manual operation from end users. End users can congure their preferences for processing incoming calls in more intelligent way using call processing language [21]. This callee preferences can be potentially associated with users' location information and presence data to enable location-based Internet telephony services [52]. 7.2 Comparison of MNC Mode and SH Mode Session Hando (SH) mode is a more general approach for service migration comparing to Mobile Node Control (MNC) mode, as it completely transfers a service and its ongoing sessions to a new device. A major disadvantage of MNC node is that the transferrer device has remained active to maintain the signaling sessions after service migration. Comparing to SH mode, one advantage of MNC mode is its interoperability with legacy applications. However, our prototype implementation has proved that the signaling of SH mode is not hard to implement, thus future

78 CHAPTER 7. EVALUATION 67 SIP devices and applications can easily support SH mode, if service migration eventually becomes a mainstream application for future IP multimedia services. If this comes true, is MNC mode still necessary for a service migration system? Our answer is yes. Because of its interoperability with devices that have only a limited user interface (UI). Nowadays, most Internet capable devices are designed to be very PCs alike, including Internet Tablet and smartphones, as they have operating systems and can install and run native applications. However, a future computing environment may consist of Internet appliances, which has only a specic function and limited conguration ability. These appliances can be LCD screen, TV camera, loudspeaker, projector, etc. Since MNC mode only transfers the media session while maintaining the signaling session in the original device, the MN can act as a controller to these appliances. Thereby, the user can take advantage of the UI in his mobile device while enjoying better service quality using these appliances. Moreover, as discussed in Sec. 3.2, MNC mode is more suitable for session splitting across multiple devices. Thus, a useful application of MNC mode is distributing an incoming call between multiple appliances immediately when user accepts the call in his mobile device. For instance, a user can congure his TV camera as the video input/output device for his mobile, thus whenever he answers a call in his mobile, the TV camera will be automatically included in the call for an additional video session. The next section will give a comparison of the two modes by analyzing the quantitative data from the performance measurements. 7.3 Test Environment for Session Mobility The main goal of the performance measurements is to evaluate and validate the requirement 5 "Session transfer should involve minimal disruption of the media ow" presented in Sec The system under measurement is the session mobility component instead of the whole service migration system, as the main interest of this measurement work is in the end-to-end latency. Thus, we eliminate the time for naming lookup by utilizing the binding of IP address and port number as the SIP URI for both endpoints. Moreover, no SIP proxy server is located in the path between the two endpoints, so there is no extra overhead for application layer routing. The measurement experiments in this thesis mostly followed Schulzrinne et al paper [41]. Besides, we also take mobile devices into account to

79 CHAPTER 7. EVALUATION 68 investigate not only the dierences between two transfer modes, but also the dierences between the xed and mobile devices in terms of processing capacity and network bandwidth. In the following, two important metrics are dened. They are marked in the call ow Fig. 7.4 and Fig. 7.5 for Mobile Node Control (MNC) mode and Session Hando (SH) mode respectively. Figure 7.4: Metrics in MNC call ow The most important metric is the disruption of media stream during session transfer. To end users, it means the "dead time" between the termination of the current media stream and the re-establishment of the new stream, during which either participant may not hear any sound on any device on his side. This disruption divides to Mobile User Lapse Time (MLT) on the MN's side and Correspondent Node Lapse Time (CLT) on the CN's side. Another important metric is Total Transfer Time (TTT), which refers to the delay in transferring a session. It starts when the mobile user initiates the transfer request and terminates when the new bidirectional media streams are established in the local device. The mobile user can switch the device afterwards. Seamless session mobility is mainly aected by MLT and CLT, and not related to TTT. Further, TTT only matters to the mobile user, not the CN,

80 CHAPTER 7. EVALUATION 69 Figure 7.5: Metrics in SH call ow to which session transfer should be transparent. According to the call ows described in Fig. 7.4 and Fig. 7.5, for both modes: TTT = MLT + CLT + Additional Signaling Time The additional signaling time (AST) consists of two parts: the rst part is before MLT, during which the MN and the CN are communicating with each other; the second part is after MLT, during which the MN keeps sending audio to the CN but the CN has started transmitting to the local device. This means, if the second part of AST is too long, the user needs to talk in the old device and listen in the new device in order to get a seamless feeling. In the next section, we will give our method to improve the user experience regarding to this issue based on our measurement. Further, the study of session transfer is comparable with handover in GSM. There are two important metrics concerning the timing of channel change in GSM: channel change delay (T_GSM_Delay) and interruption times (T_GSM_Interrupt) [1], which can be compared to TTT and MLT respectively. Their reference values for synchronized GSM cell and not synchronized GSM cell under good radio conditions are described in Table 7.1:

81 CHAPTER 7. EVALUATION 70 Table 7.1: Channel change delay and interruption times in GSM [1] Target cell T_GSM_Delay T_GSM_Interrupt Sync GSM cell 120 ms 20 ms Not Sync GSM cell 220 ms 120 ms Table 7.2 summarizes the three experiments in this study. Each experiment is repeated with 20 iterations. Table 7.2: Three experiments for performance measurement EXP 1 MNC mode. CN is laptop connecting to LAN. EXP 2 SH mode. CN is laptop connecting to LAN. EXP 3 SH mode. CN is N800 connecting to WLAN. All experiments were carried out in the same testbed setups, which consist of two separate rooms in a university campus network. Each room has a wireless router. N800 Internet tablets serve as mobile devices while laptops serve as xed devices. Tablets were connected via WLAN while laptops were connected via xed Ethernet interfaces. All devices obtained public IP addresses as both wireless routers serve as switches (see Fig. 7.6). Figure 7.6: Testbed setting for experiments

82 CHAPTER 7. EVALUATION Results and Performance Analysis Table 7.3, 7.4, 7.5 present the performance measurement results for each experiment respectively. In these tables, STDV stands for standard deviation. Table 7.3: Results of EXP1 (MNC mode, CN is laptop without optimization) EXP1 mobile-to-xed Range STDV Avg. Mobile User Lapse Time (ms) CN Lapse Time (ms) Total Transfer Time (ms) Table 7.4: Results of EXP2 (SH mode, CN is laptop without optimization) EXP2 mobile-to-xed EXP2 xed-to-mobile Range STDV Avg. Range STDV Avg. Mobile User Lapse Time (ms) CN Lapse Time (ms) Total Transfer Time (ms)

83 CHAPTER 7. EVALUATION 72 Table 7.5: Results of EXP3 (SH mode, CN is N800 with optimization) Mobile User Lapse Time (ms) CN Lapse Time (ms) Total Transfer Time (ms) EXP3 mobile-to-xed EXP3 xed-to-mobile Range STDV Avg. Range STDV Avg Mobile Node Control vs. Session Hando Experiment 1 and 2 give the comparison between two transfer modes. The session was transferred from N800 to laptop in both experiments. The results show that Session Hando (SH) mode has better performance than Mobile Node Control (MNC) mode in two aspects (see Fig. 7.7). Figure 7.7: Comparison between MNC mode and SH mode First, SH mode has considerably less Total Transfer Time (TTT), only around 200 ms with a very small standard deviation (12 ms), hence the

84 CHAPTER 7. EVALUATION 73 session transfer is almost seamless. On the contrary, average TTT in MNC mode is close to one second, more than four times of TTT in SH mode. This is likely because in MNC mode, all signaling ows between the transfer target (the local device) and the remote endpoint (the CN) must be relayed by the MN. More signicantly, SH mode contains no Correspondent Node Lapse Time (CLT) while MNC mode suers from a relatively large CLT, which constitutes more than 77% of TTT. This is because SH mode employs a soft session hando scheme while MNC mode does not. Both modes have a similarly low Mobile User Lapse Time (MLT) (159.9 ms in SH and 163 ms in MNC). This is due to the same behaviour of the CN during session transfer in two modes. Schulzrinne et al. [41] also shows that SH mode has smaller TTT than MNC mode, so it is faster for session transfer. In contrast to our results, it shows that MNC mode has a smaller media disruption than SH mode in both sides. Particularly, CLT can be also reduced to zero in MNC mode by modifying the MNC signalling: the INVITE request to the local device contains the CN's media parameters in the SDP body (see ow 1 in Fig. 7.4), so that the local device will start transmitting to the CN immediately. This requires the CN not to change the existing media parameters during session transfer. On the other hand, Schulzrinne et al. [41] shows that a small disruption is experienced in SH mode. However, both call ows (Fig. 7.5) and our results prove that SH mode causes no disruption on the CN's side. Further, our results show that the performance of SH mode is close to GSM handover with unsynchronized target cell: the delay of them are 221.5ms and 220ms correspondingly, and the disruption of them are 159.9ms and 120ms respectively Mobile vs. Fixed We choose SH mode for this study, because SH is a more general transfer mode as it completely transfers the whole set of a session to a new device. Experiment 2 shows the dierence between mobile devices (N800) and xed device (laptop), see Fig The results show that session transfer is much faster from N800 to laptop than the reversed order. The primary reason for this, however, is not due to the dierence of bandwidth, as our testbed is deployed in a campus LAN environment. The main factor is media engine setup, which starts instantly in laptops and PCs, costs more than one second in N800.

85 CHAPTER 7. EVALUATION 74 Figure 7.8: Results of EXP2 (SH mode, CN is laptop without optimization) A more important factor aecting the user experience is the media disruption. We can eectively improve the user experience by applying a bidirectional soft session hando in the xed-to-mobile case: before the CN receives any media stream from the local device, it keeps sending media stream to both the MN and the local device. Thus, during session transfer, the user can keep talking in the xed device (MN) and only switch to the mobile device (local device) until the new session is established. Both participants will not feel any disruption, as the bidirectional media stream is always maintained between the MN and the CN within TTT. The above analysis shows that mobile devices aect session transfer due to their limited processing power. This inevitably leads to another potential problem: how the performance of session transfer will be degraded if the remote participant (the CN) is also a mobile device? When we rst tested N800 as the CN, it was also implemented in the straightforward way (stopping and restarting the media engine during session transfer). As expected, the performance of session transfer is much degraded. Both MLT and TTT are much higher than the results of experiment 2 due to media engine re-setup in N800. Schulzrinne et al. [41] also reports similar problems with video call transfer. Its video application cannot have its des-

86 CHAPTER 7. EVALUATION 75 tination IP address and port switched without stopping and restarting. This delay causes much larger disruptions and TTT as the media engine setup time for video is longer than audio. Hence, we have optimized the CN in N800. It only updates its media engine rather than restarts during session transfer, thus the destination of the media stream is immediately redirected while running. Fig. 7.9 shows the results of experiment 3. Figure 7.9: Results of EXP3 (SH mode, CN is N800 with optimization) The results show that MLT is close to 0ms in both mobile-to-xed and xedto-mobile cases. The optimization also signicantly reduces the total transfer time in both cases. Further, after optimization, the performance of the mobile-to-xed transfer in SH mode is close to GSM handover with synchronized target cell: the delay of them are 132.8ms and 120ms correspondingly, and the disruption of them are 22.1ms and 20ms respectively. We can expect that experiment 2 will have better performance if applying the same optimization to xed devices. Therefore, we can conclude that session transfer in SH mode can be regarded as seamless in a LAN environment.