1 / 8

Requirements for Vertical Handover of Multimedia Sessions Using SIP

This document outlines the requirements for seamless vertical handover of multimedia sessions using SIP (Session Initiation Protocol). It addresses the need for fast, reliable handover solutions that maintain active sessions as mobile hosts switch between different network interfaces (e.g., WiFi, 3G, WiMax). The proposed solution aims to minimize service disruption, ensuring compatibility with NATted networks without imposing restrictions on correspondent hosts. By leveraging existing work, this draft identifies gaps in current solutions and promotes a collaborative approach to establish a common set of requirements for developers and network operators.

corby
Télécharger la présentation

Requirements for Vertical Handover of Multimedia Sessions Using SIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements for vertical handover of multimedia sessions using SIPdraft-niccolini-sipping-siphandover-04 Saverio Niccolini (NEC), S. Salsano (Univ. of Rome “Tor Vergata”),H. Izumikawa (KDDI Labs), R. Lillie (Motorola Labs),L. Veltri (Univ. of Parma), Y. Kishi (KDDI Labs)

  2. Introduction • Terminal (“Mobile Host”, MH) • Different network interfaces (e.g. WiFi, 3G, WiMax, etc.) connected to different Access Networks (AN) • possibly active at same time • each one with different IP addresses • MH moves, “interface being used” may become not available (or suffering from bad performances, e.g. loss, delays) • MH wants to keep running sessions active (or achieve better performances)

  3. Reference scenario IETF 72 – Dublin – SIPPING

  4. Requirements (the basics) • The handover solution should be as fast as possible • The goal is to provide a "seamless" handover with no perception from the user point of view • The handover solution should not require a support in the different access network (no “network level mobility” e.g. MIP/MIPv6) • The access networks are only required to provide IP connectivity so that mobility support can be rapidly deployable • No special support from Correspondent Hosts (CHs) • CHs should be basic User Agents (UAs) with 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 • NAT discovery should not increase the handover delay

  5. Why a new solution? • There are solutions out there, why do you require a new one? • need to be faster • service disruption as small as possible, bound to 0 • do not want to rely on network capabilities • do not want to rely on correspondent host capabilities • need to be NAT-independent • More details in the additional requirements in the draft (here only 15 minutes) • details currently not addressed with available solutions

  6. References (running code?) • Currently two available (independent) “solution” drafts • http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution-02 • http://tools.ietf.org/html/draft-izumikawa-sipping-sipbicast-01 • The authors of the solution draft teamed up in the requirement draft to define a common set of requirements • Solutions to this problem have been designed and implemented • (At least) 3 (known) independent implementations • NEC Laboratories Europe, University of Rome “Tor Vergata”, KDDI Labs/Motorola • 2 of them tested interoperability already in 2006 • NEC Laboratories University of Rome “Tor Vergata” • Results of implementation and tests on operational networks documented • PIMRC conference, Sept. 2007 • IEEE Wireless Personal Communications, Nov. 2007 • IEEE Wireless Communications, Apr. 2008 • WCNC 2008, April 2008 • Trial with Italian operators

  7. Feedback received and addressed • Differences from Session Mobility ID (draft-shacham-sipping-session-mobility)? • difference in focus: Shacham's I-D is addressing "service mobility", Niccolini and Izumikawa I-Ds are addressing "terminal mobility“ • It is necessary to consider the solution to minimize the service disruption during handoff  explained in the draft • Are there any advantages/merits to perform a terminal mobility using SIP? • ease of deployment, no support needed in all terminals/networks, different roles and utilizations  reflected in the requirements • do you want to wait for an ubiquitous deployment of mobile IPv6 to start using network level mobility keeping your IP address when you roam across networks? • You are fixing some problems with an SBC!!! • solutions based on an intermediate element are promising without the need to rely on Correspondent Host capabilities  reflected in the requirements • anyway this draft does not hint any solutions, it just says current ones are not enough for the requirements • What about media like IM, File Transfer using MSRP? • added additional requirement • Decide which media stream to render when doing bicast • implementation issueout of the scope of SIP/SIPPING?

  8. Conclusions • Do SIPPING folks agree on requirements? • Is the work interesting for SIPPING? • Should this be chartered in SIPPING WG and become a WG item?

More Related