Requirements for vertical handover of multimedia sessions using SIP

Let us consider a terminal (hereafter named "Mobile Host" or MH), that is possibly equipped with different network interfaces (i.e. a subset of WiFi, Bluetooth, GPRS, 3G, 3.5G (HSDPA), fixed Ethernet, WiMax). A user needs to be able to access the Internet using the same MH irrespective the type of network it connects to. Such multimode terminals are already in the market, and we will be gradually get surrounded by a heterogeneous network where several access networks (ANs) supplement each other. Each interface of the MH will receive an IP address from the corresponding AN it connects to. Therefore the mobile host will have a set of different IP addresses and will have to select which one to use when running multimedia sessions with correspondent terminals. While the mobile host moves, the "selected" interface may become not available due to loss of signal, or could suffer high packet loss or packet delay. Under these circumstances, the MH would like to switch to another interface (using a different IP address) keeping the running sessions active, and might adjust the service quality to be optimal depending on circumstances. Even with a single interface the connected access network can become not available anymore and the terminal could connect to another Access Network (in this case on the same technology), which provides a different IP address. If the switch to the new AN is fast enough, the MH could also be interested in keeping the running session active. This problem can be addressed with many different approaches, at all the different levels of the protocol stack from link layer to application layer. For a review and comparison of these different approaches, see for example and . We are interested here in "application level" mobility solutions. The main advantage of application level mobility solutions is that they do not require any support at the networking level and below from the different access networks, which only needs to provide plain IP connectivity. Application level mobility can conduct flexible mobility management, which is another advantage. Within IETF, discussions on using SIP for mobility management date back several years ago and have been mostly carried on in SIPPING WG. For example analysed preliminary requirements and identified issues that need to be resolved in order to develop a mobility management mechanism in a SIP environment. . Furthermore, session mobility using SIP has been discussed in SIPPING WG, and is now awaiting processing and publishing as RFC. This document addresses issues and requirements regarding a SIP based "application level" mobility solution, focusing on "terminal mobility". Although "terminal mobility" could be considered as a sub-set of "session mobility", we believe that some requirements (e.g. vertical handovers, fast switching) are not adequately covered by the mobility features of current SIP specifications and therefore they need a careful consideration within the SIPPING WG. The relevance of this topic is also confirmed by the ongoing work within 3GPP on "Voice Call Continuity" and "Multimedia Session Continuity" , which is providing specification of vertical handover solutions using SIP. A discussion of mobility requirements and solution within SIPPING WG provides the chance to consider this 3GGP work.

This section presents a few terms used throughout the document. Vertical handover: A vertical handover refers to changing a MH's point of attachment between different types of access networks, e.g. GPRS and WiFi. The feature of a vertical handover is that the transmission rate and latency may well differ significantly before and after handover, respectively. Network level mobility: Network level mobility refers to managing an MH's mobility at the network layer. Mobile IP (MIP) and Mobile IPv6 (MIPv6) are well-known as network level mobility. One of the merits of network level mobility is making the mobility of an MH transparent to an application by keeping the same IP address. This type of mobility management is useful to run existing applications. However, an ubiquitous deployment of MIP/MIPv6 is needed if a MH's mobility is globally supported. In addition, it is difficult for an application to recognize an available bandwidth and delay before or during handoff and to adjust a transmitting rate or buffer space to a target network since network level mobility makes the MH's mobility transparent to the upper layer. Application level mobility: Application level mobility refers to managing an MH's mobility at the application layer. SIP mobility is well-known as application level mobility. Application level mobility has its merits in terms of its ease of deployment. This does not require whole networks to be changed. Therefore, the mobility support can be more and more rapidly deployable using application level mobility. Furthermore, SIP has an affinity for applications, which can make handoff more flexible. The feature can fit heterogeneous networks where an available bandwidth and delay may well differ significantly among access networks. Terminal mobility: Terminal Mobility allows a device to move between IP subnets, while continuing to be reachable for incoming requests and maintaining sessions across subnet changes. (Definition from ) Session mobility: Session mobility allows a user to maintain a media session even while changing terminals. (Definition from )

In this document, we focus on Terminal Mobility. The figure below shows a Mobile Host that wants to communicate with a "Correspondent Host" (CH). The Mobile Host can connect to different Access Networks (AN1, AN2, AN3 are represented in the figure). The different ANs could have different wireless or wired technologies and difference bandwidth/delay, and the Mobile Host could be connected to more than one Access Network at the same time if it has more than one physical network interface. Note that the Access Networks can provide public or private addresses to the mobile host (in most typical scenarios the Access Networks are likely to provide private IP addresses). For example in the figure below AN 1 and AN 3 provide a private address (as shown by the NAT box), while AN2 provides a public address. Similarly, the Correspondent Host can have a public address (like CH 1 in the figure) or a private IP address (like CH 2 in the figure).

The goal of the handover mechanism is to let the MH roam among different Access Networks in a seamless way. Therefore we are addressing the issue of "Terminal Mobility" as defined in previous section. The mobility management mechanism should consider the roaming of the MH both "off call" and during an active call. The MH should be able to dynamically choose among the available ANs the one that better suits its needs (e.g. perceived quality of media flows and cost) in a given moment. It is important to notice that this draft does not address the criteria and tools for selection of the "best" access network, it only details the issues and the requirements regarding the mobility management and handover execution mechanism.

In this session we discuss a set of requirements that a mobility management solution based on SIP should have. The requirements are divided into two types, i.e., mandatory requirements and optional requirements. Mandatory Requirements The solution should take care of handover as fast as possible. The goal is to provide a "seamless" handover with no perception from the user point of view. If it is not possible to provide a truly seamless solution, the impairment should be minimized. For example, voip application is used to evaluate for the performance of SIP-based terminal mobility in and also video-phone is used in . According to the ITU requirement, one-way delay and packet loss rate for conversational voice and video-phone are required to be less than 150 ms and 3%, and 150 ms and 1%, respectively. The handover solution should not require a support in the different access network. The access networks are only required to provide IP connectivity (either with public or private addresses) for the forwarding of signalling SIP packets and media RTP packets. Correspondent Host (CH) (which in general are not moving, but they are communicating with a moving terminal) should be a basic User Agent (UA) which only has basic SIP capabilities. If this requirement is not fulfilled there is the need to change all SIP terminals to support the handovers of Mobile Host. The handover solution should be compatible with NATted networks, i.e. it should interoperate gracefully with NAT traversal mechanisms for SIP signaling and for session media flows. Optional Desirable Requirements The solution may support a "forward handover" (i.e. in which all the procedure is performed on the new target Access Network). This is important if the connection on the old Access Network is suddenly broken. If possible (i.e. if the connection with the old access network does not break suddenly) the solution could exploit the communication on the old access network in order to better control the handover procedure. Soft handovers (i.e. where the two active connections can be exploited in the same moment to send the session data) could be exploited. The switch of the "active" interface during a SIP transaction may be supported. As an example the terminal should be able to send (receive) an INVITE on the currently active interface, switch to another interface and receive (send) the 200 OK on the other interface. Decoupling of "user level" registration and mobility and "terminal level" mobility may be allowed. As an example a user with AOR "sip:user@domain.com" should be allowed to use different terminals (i.e. Mobile Hosts supporting the handover solutions as well as normal SIP terminals). These terminals can be used in sequence or at the same time depending on the capability of his own "home" registrar/proxy server, and this is independent of the vertical handover solution which takes care of the mobility of only one specific Mobile Host. A concrete example for this requirement is to support a user "sip:user@domain.com" who owns three Mobile Hosts (one could be his phone, one his PDA, one his laptop) and two fixed terminals (his desktop and his home VoIP phone). The vertical handover solution takes care of the mobility of the phone, PDA and laptop as three separate Mobile Hosts (which can also be all active in the same time). Providing privacy with respect to user location and user movements would be preferable. Existing user agents for the Mobile Host may inter-work with the handover procedure without the need to be updated. It would be desirable to reuse existing SIP clients (User Agents) without updating them to support the terminal mobility. It is desirable that the service quality is adjusted to optimal levels according to the access network after every handover. Non-RTP media such as IM or file transfer using MSRP may be supported.

The application level terminal mobility solutions based on SIP can be classified in "Correspondent host based" or "Intermediate Element based". In addition, a session mobility is introduced just for reference. Correspondent Host based terminal mobility solutions RFC 3261 has a built in mechanism for mobility management. The "off-call" mobility management consists in the Registration process. The "on-call" handover is performed using RE-INVITE messages towards the Corresponding Node . No intermediate entities are directly involved in the handover process. This has the advantage that no additional procedures for the handover need to be implemented in intermediate elements, and that there is no additional load in the networks due to the handovers. On the other hand, the procedure requires that the Corresponding Node (which in general is not a mobile host) supports the RE-INVITE mechanism. A second drawback is that the handover delay is directly proportional to the end-to-end delay, and this could be higher with respect to the delay occurring between a mobile node and an intermediate element. Intermediate Element based terminal mobility solutions In order to overcome the drawbacks of the Correspondent Host based solutions, "intermediate" entities that take an active role in the handover can be introduced. Several proposals can be found in the literature, but to our knowledge no internet draft has been proposed in this respect. Hereafter we mention some of the existing proposals. In , intermediate entities are used only to speed up the handover process, but the handover procedure still involves the Corresponding Node as well. A similar approach is followed in , which also deals with location based selection of the "optimal" intermediate entity and of wireless access points. In the intermediate entities fully handle the user mobility, hiding the mobility to the Corresponding Nodes. In , the intermediate entities are used to support MH's mobility as well as adjusting service quality to the MH's target access network. also describes different ways "intermediate element"-based approach can expedite handover for single-interface-based terminals. Session mobility solutions According to session mobility is the transfer of media of an ongoing communication session from one device to another. , based on the previous work in has defined a framework for session mobility that allows a mobile node to discover available devices and to include them in an active session. has demonstrated the suitability of employing either 3PCC (3PCC) or SIP's REFER method as suitable mechanisms for session mobility between mobile devices. The problem of session mobility is more general and more complex than the problem of terminal mobility that is addressed by this requirement analysis. It is likely that a solution for the session mobility problem can also solve the terminal mobility problem, but it also needs to consider several aspects that are not relevant to terminal mobility. Just to give two examples: 1) device discovery; 2) signaling procedures to communicate the intention or need to transfer the session from the original device and the target devices. These two aspects are not needed in a solution for terminal mobility, as all the network interfaces are local to the terminal and they do not need to be discovered nor there is the need to communicate the session transfer from one interface to another. On the other hand, there are some specific requirements that could be taken into consideration in terminal mobility. One example is the avoidance of media disruption during the handover. The gap of the media stream in terminal mobility case (on the same terminal) would cause more severe degradation in the user's experience than that in the session mobility case. Such gap should be made minimum or avoided during the handover in terminal mobility. For the above reason, we believe that requirements for terminal mobility should be addressed in a separate context than session mobility. Obviously solutions for session mobility could become a part of the solution for terminal mobility

As a concluding remark, we believe that it is important to consider a new solution for vertical handover that meets the set of requirements that has been analysed. This solution will help providing seamless handover to SIP based application with a better performance and overcoming some shortcomings of the current solution based on .

The security considerations should be taken into account in the design of the handover solution, so that no new additional security issues will be introduced.

This memo includes no request to IANA.

The authors would like to thank a number of people that recently contributed to the development of this draft in a more clear direction pointing out the issues that need to be addressed to advance this document. Acknowledgement go to people in the SIPPING working group, including: Ashutosh Dutta, Salvatore Loreto, Henning Schulzrinne and Henry Sinnreich.