TOC 
SIPPING Working GroupS. Niccolini
Internet-DraftNEC
Intended status: InformationalS. Salsano
Expires: May 7, 2009Univ. of Rome Tor Vergata
 H. Izumikawa
 KDDI Labs
 R. Lillie
 Motorola Labs
 L. Veltri
 Univ. of Parma
 Y. Kishi
 KDDI Labs
 November 03, 2008


Requirements for vertical handover of multimedia sessions using SIP
draft-niccolini-sipping-siphandover-05

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 7, 2009.

Abstract

A vertical handover occurs in heterogeneous networks when a session media is moved among different access network technologies within the same device. This document analyses the issue of handling the vertical handover using the Session Initiation Protocol (SIP) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [1].



Table of Contents

1.  Introduction
2.  Terminology
3.  Scenario for vertical handover
4.  Requirements for Vertical Handovers
5.  Taxonomy of possible approaches
6.  Conclusions
7.  Security considerations
8.  IANA Considerations
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

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 [15] (Dutta, A., Lyles, B., Schulzrinne, H., Chiba, T., Yokota, H., and A. Idoue, “Generalized Modeling Framework for Handoff Analysis,” September 2007.) and [14] (Le, D., Fu, X., and D. Hogrefe, “A review of Mobility Support Paradigms for the Internet,” 1st quarter 2006.). 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 [11] (Vakil, F., Dutta, A., Chen, J-C., Baba, S., Nakajima, N., Shobatake, Y., and H. Schulzrinne, “Mobility Management in a SIP Environment Requirements, Functions and Issues,” December 2000.) 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 [8] (Shacham, R., “Session Initiation Protocol (SIP) Session Mobility,” November 2007.) 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" [17] (3GPP, “Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) Study,” December 2005.) and "Multimedia Session Continuity" [18] (3GPP, “Feasibility study on multimedia session continuity; Stage 2,” June 2008.), 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.



 TOC 

2.  Terminology

This section presents a few terms used throughout the document.



 TOC 

3.  Scenario for vertical handover

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).



                            +-------+
                            |  AN1  |-----+
                        ----|       | NAT |                +--------+
                       /    +-------+-----+                |Corresp.|
          +-------+                         __________     | Host 1 |
          | Mobile|         +-------+      /          \    +--------+
          | Host  |         |  AN2  |     /            \
          +-------+     ----|       |    |   INTERNET   |
                            + - - - +     \            /
                                           \__________/
                       \    +-------+                      +--------+
                        ----|  AN3  |-----+          +-----|Corresp.|
                            |       | NAT |          | NAT | Host 2 |
                            +-------+-----+          +-----+--------+

 Figure 1 - Network architecture for vertical handover 

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.



 TOC 

4.  Requirements for Vertical Handovers

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

Optional Desirable Requirements



 TOC 

5.  Taxonomy of possible approaches

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.

RFC 3261 [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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 [7] (Schulzrinne, H. and E. Wedlund, “Application-Layer Mobility Using SIP,” July 2000.). 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.

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 [6] (Banerjee, N., Acharya, A., and S. Das, “Seamless SIP-Based Mobility for Multimedia Applications,” March/April 2006.), 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 [12] (Tsiakkouris, S. and I. Tsiakkouris, “PROFITIS: architecture for location-based vertical handovers supporting real-time applications,” April 2006.), which also deals with location based selection of the "optimal" intermediate entity and of wireless access points. In [10] (Salsano, S., Mingardi, C., Niccolini, S., Polidoro, A., and L. Veltri, “SIP-based Mobility Management in Next Generation Networks,” April 2008.) the intermediate entities fully handle the user mobility, hiding the mobility to the Corresponding Nodes. In [13] (Izumikawa, H., Fukuhara, T., Matsunaka, T., and K. Sugiyama, “User-centric Seamless Handover Scheme for Realtime Applications,” September 2007.), the intermediate entities are used to support MH's mobility as well as adjusting service quality to the MH's target access network. [16] (Dutta, A., Madhani, S., Chen, W., and H. Schulzrinne, “Fast-handoff Schemes for Application Layer Mobility Management,” September 2004.) also describes different ways "intermediate element"-based approach can expedite handover for single-interface-based terminals.

According to [8] (Shacham, R., “Session Initiation Protocol (SIP) Session Mobility,” November 2007.) session mobility is the transfer of media of an ongoing communication session from one device to another. [5] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.), based on the previous work in [7] (Schulzrinne, H. and E. Wedlund, “Application-Layer Mobility Using SIP,” July 2000.) has defined a framework for session mobility that allows a mobile node to discover available devices and to include them in an active session. [5] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) has demonstrated the suitability of employing either 3PCC (3PCC) (Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” April 2004.) [4] or SIP's REFER [5] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.) 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



 TOC 

6.  Conclusions

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 [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).



 TOC 

7.  Security considerations

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.



 TOC 

8.  IANA Considerations

This memo includes no request to IANA.



 TOC 

9.  Acknowledgments

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.



 TOC 

10.  References



 TOC 

10.1. Normative References

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT).
[2] Perkins, C., “Mobility Support in IPv6,” RFC 3344, August 2002 (TXT).
[3] Johnson, D., Perkins, C., and J. Arkko, “IP Mobility Support for IPv4,” RFC 3775, June 2004 (TXT).
[4] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” BCP 85, RFC 3725, April 2004 (TXT).
[5] Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” RFC 3515, April 2003 (TXT).


 TOC 

10.2. Informative References

[6] Banerjee, N., Acharya, A., and S. Das, “Seamless SIP-Based Mobility for Multimedia Applications,” IEEE Network , March/April 2006.
[7] Schulzrinne, H. and E. Wedlund, “Application-Layer Mobility Using SIP,” ACM Mobile Computing and Communications Review Vol.4, No.3, July 2000.
[8] Shacham, R., “Session Initiation Protocol (SIP) Session Mobility,” draft-shacham-sipping-session-mobility-05 (work in progress), November 2007 (TXT).
[9] Salsano, S., Veltri , L., Polidoro , A., and A. Ordine , “Architecture and testbed implementation of vertical handovers based on SIP Session Border Controllers,” Wireless Personal Communications, Springer , November 2007.
[10] Salsano, S., Mingardi, C., Niccolini, S., Polidoro, A., and L. Veltri, “SIP-based Mobility Management in Next Generation Networks,” IEEE Wireless Communication , April 2008.
[11] Vakil, F., Dutta, A., Chen, J-C., Baba, S., Nakajima, N., Shobatake, Y., and H. Schulzrinne, “Mobility Management in a SIP Environment Requirements, Functions and Issues,” draft-itsumo-sip-mobility-req-02.txt (work in progress), December 2000.
[12] Tsiakkouris, S. and I. Tsiakkouris, “PROFITIS: architecture for location-based vertical handovers supporting real-time applications,” 25th IEEE International Performance, Computing, and Communications Conference (IPCCC 2006), April 2006.
[13] Izumikawa, H., Fukuhara, T., Matsunaka, T., and K. Sugiyama, “User-centric Seamless Handover Scheme for Realtime Applications,” IEEE Internation Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC'07), September 2007.
[14] Le, D., Fu, X., and D. Hogrefe, “A review of Mobility Support Paradigms for the Internet,” IEEE Communications Surveys & Tutorials Vol.8, No.1, 1st quarter 2006.
[15] Dutta, A., Lyles, B., Schulzrinne, H., Chiba, T., Yokota, H., and A. Idoue, “Generalized Modeling Framework for Handoff Analysis,” 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2007), September 2007.
[16] Dutta, A., Madhani, S., Chen, W., and H. Schulzrinne, “Fast-handoff Schemes for Application Layer Mobility Management,” 15th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2004), September 2004.
[17] 3GPP, “Voice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS) Study,” 3GPP TR 23.806 7.0.0, December 2005.
[18] 3GPP, “Feasibility study on multimedia session continuity; Stage 2,” 3GPP TR 23.893 8.0.0, June 2008.
[19] ITU-T, “ITU-T G.1010 End-user multimedia QoS categories,” 2001.


 TOC 

Authors' Addresses

  Saverio Niccolini
  Network Laboratories, NEC Europe Ltd.
  Kurfuersten-Anlage 36
  Heidelberg 69115
  Germany
Phone:  +49 (0) 6221 43 42 118
Email:  saverio.niccolini@netlab.nec.de
URI:  http://www.netlab.nec.de
  
  Stefano Salsano
  DIE, University of Rome "TorVergata"
  Via Politecnico, 1
  Rome 00156
  Italy
Phone:  +39 06 7259 7770
Email:  stefano.salsano@uniroma2.it
URI:  http://netgroup.uniroma2.it/Stefano_Salsano
  
  Haruki Izumikawa
  KDDI Labs
  Postfach 330440
  Bremen 28334
  Germany
Phone:  +49-421/21863908
Email:  izumikawa@kddilabs.jp
  
  Ross Lillie
  Motorola Labs
  1301 East Algonquin Road, IL02/2240
  Schaumburg, IL 60196
  US
Phone:  +1 847 576 0012
Email:  ross.lillie@motorola.com
  
  Luca Veltri
  DII, University of Parma
  Parco Area delle Scienze 181/A
  Parma 43100
  Italy
Phone:  +39 0521 90 5768
Email:  luca.veltri@unipr.it
URI:  http://www.tlc.unipr.it/veltri
  
  Yoji Kishi
  KDDI Labs
  2-1-15 Ohara
  Fujimino 356-8502
  Japan
Email:  kishi@kddilabs.jp


 TOC 

Full Copyright Statement

Intellectual Property