Requirements for vertical handover of multimedia sessions using SIP draftniccolinisippingsiphandover

1
Requirements for vertical handover of multimedia
sessions using SIPdraft-niccolini-sipping-siphand
over-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-s
  iphandover-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 issue out 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?