architecture and testbed implementation of vertical handovers

Wireless Pers Commun (2007) 43:1019–1034DOI 10.1007/s11277-007-9259-2

Architecture and testbed implementation of verticalhandovers based on SIP session border controllers

Stefano Salsano · Luca Veltri ·Andrea Polidoro · Alessandro Ordine

Received: 25 May 2006 / Accepted: 20 January 2007 / Published online: 31 March 2007© Springer Science+Business Media B.V. 2007

Abstract This paper describes a Session Initia-tion Protocol (SIP) based solution for mobilitymanagement that provides seamless mobile mul-timedia services in a heterogeneous scenario wheredifferent radio access technologies are used(802.11/ WiFi, Bluetooth, 2.5G/3G networks). Thesolution relies on the so called “Session BorderControllers” which are now widely used in manycommercial SIP telephony solutions, mainly to dealwith NAT traversal. Session Border Controller fun-ctionality has been extended to support seamlessmobility for multimedia applications. A prototypeof the proposed solution focused on VoIP serviceshas been implemented in a test bed which is able toperform seamless handovers (and NAT traversal)using the 802.11, Bluetooth and 3G (UMTS)access networks. Measurements results arereported which analyze the performance of thesolution in a real world environment, usingcommercial WiFi and 3G services.

S. Salsano (B) · A. Polidoro · A. OrdineDepartment of Electronic Engineering,University of Rome “Tor Vergata” Via del Politecnico1, 00133 Rome, Italye-mail: [email protected]

L. VeltriDepartment of Information Engineering, University ofParma, Parma, Italy

Keywords Seamless handover-SIP · Applicationlayer mobility · Session Border Controller · WiFi ·3G networks

1 Introduction

Several different wireless access technologies arenow available that can support real time services,in particular voice over IP (VoIP). Currently, thesetechnologies span from cellular networks (UMTS),LAN technologies (802.11 a/b/g) and even PANtechnology (Bluetooth), but other technologies willbecome mature in the very near future (e.g. 802.16).Multi standard terminals, laptops, tablet PCs, PDAsand even phones are now able to use more thanone interface at a time. One of the goal of nextgeneration mobile networks (often referred to as4G network) is the integration and interoperabil-ity of different access technologies (including fixedaccess with “fixed mobile convergence”) into a sin-gle system or better into a single service presentedto the user. The integration can happen at differentlevels of the protocol stack and various solutionsare under study which operate at these differentlevels. In this paper we focus on an applicationlevel solution based on the SIP protocol [18,23].The advantage of this type of solution is that it eas-ily adapt to whatever underlying access technologyis used.

The service scenario that we have consideredis wireless VoIP. Nothing prevents to extend it to

1020 S. Salsano et al.

wireless multimedia (e.g. for video communica-tion) provided that the access network(s) offer suit-able capacity. Wireless VoIP service can beaccessed over: (i) Local Area Networks (LAN)where voice communication are provided to a com-pany over an enterprise wireless LAN (WLAN)or to people accessing public WLAN hot spots; (ii)Personal Area Networks (PAN) for example offer-ing voice communication using Bluetooth technol-ogy in a domestic environment or in a small office;(iii) Wide Area Network (WAN) thanks to highdata rate 2.5G/3G cellular technologies. The abil-ity to use multiple networks in parallel gives theuser a possibility to choose the most economicalor the most performing access network at a giventime, or conversely it gives the service provider thepossibility to use the most suitable connection foreach application. Therefore we face the require-ment to support seamless mobility on multi-modeterminals, with the ability to place and receive callsover the most suitable wireless interface and tomaintain VoIP sessions alive while handing offbetween the different access networks. As mostof the wireless access networks are currently usingprivate IP addresses and are connected throughNetwork Address Translation (NAT) elements, the“NAT traversal” is one of the most critical issuesto ubiquitously deploy VoIP services in the realworld. The support of the “NAT traversal” com-bined with mobility and handover functionality isa very important requirement.

In this paper we describe a solution for this issue.The solution takes care of the “vertical mobility”of a user among different access networks/technol-ogies, considering that for each different attachednetwork the terminal will receive and use a differ-ent IP address. On the other hand, the movementof the user among base stations of the same tech-nology/network (e.g. among different access pointsin the same WiFi campus, or among different 3Gcells in the cellular network of an operator) is han-dled by specific mechanisms of the given accessnetwork and no IP re-configuration is required.

In our solution, we consider a Mobile Terminal(MT) with multiple network interfaces that can beactive at the same time making it possible to realizea “soft handover”. As an example Fig. 1 illustratesthe scenario of a handover between a WiFi and a3G network (this scenario is a subset of what has

WiFi coverage

3Gcoverage

MobileTerminal

Correspondent Terminal

Internet

1

2

Fig. 1 VoIP handoff scenario in a WiFi/3G interworkingscenario

been also implemented in our testbed that will bedescribed later on). The Session Initiation Proto-col (SIP) will be used for both “traditional” VoIPsignaling and for supporting terminal mobility. Thesolution integrates mechanisms to enable MTs tomake and receive VoIP calls regardless if they arelocated inside a public or private IP network.

The paper is organized as follows. We introducethe main concepts of the proposed solution (Sect.2) and then discuss the details of the signaling pro-cedures (Sect. 3). Section IV describes our testbedand the achieved measurement results, while Sect.5 provides a report of existing work linked to oursolution.

2 Proposed solution

The fundamental concepts of the proposed solu-tion can be illustrated with the help of Fig. 2. MTshave access to different networks (in the figure,WiFi, Bluetooth and cellular 3G network), whichcan overlap their coverage areas. The MT has sep-arate interfaces, each one dynamically receives its(private or public) IP address from the correspond-ing wireless network. The MT logically contains theUser Agent (UA, i.e. the SIP client) and a MobilityManagement Client (MMC). The MT uses a Ses-sion Border Controller (SBC) [8] to access VoIPservices from IP access networks often based on aprivate IP addressing scheme and operating behinda NAT/FW box. The SBC contains a Mobility Man-agement Server (MMS) which is the main entitycontrolling the user mobility. Thanks to the inter-action between the MMC in the MT and the MMSin the SBC the device can move between IP sub-nets, allowing the UA to be reachable for incomingrequests and to maintain VoIP sessions across sub-net changes. The “CT” node shown in the picture

Architecture and testbed implementation 1021

Fig. 2 Architecture

Public IP network (Internet)

CT

1

3

3Gwireless coverage

[NAT]

SBCMMS

WiFi wireless coverage

SIP Registrar

LAN yy

3Gcore networkUA

MMC

LAN xx

UAMMC

BTwireless

coverage

2

UAMMC

MT

[NAT]

[NAT]

is the Correspondent Terminal that communicateswith the MT. SIP Registrar functionality that arenot directly related to handover/mobility manage-ment procedures can be performed by an externalSIP Registrar, as shown in the figure. Obviouslythe MMS and SIP Registrar can be implementedin a single element if required.

2.1 From SIP SBCs to MMS

While a large part of the target terminals are us-ing private IP addresses and are “hidden” behind aNAT, signaling protocols for VoIP, like SIP, do not“natively” support full NAT traversal. NAT tra-versal mechanisms are needed to allow terminalsin “private” networks to be reached (i.e. “invited”to a phone call), and to allow the media streamsto be setup between the caller and the called UAs,notwithstanding NAT boxes that could be placedat the borders between the private and the publicnetwork. IPv6 promises to overcome the NAT is-sues but wide spread diffusion of IPv6 is not fore-seen in the short/medium term. Morever, in fu-ture IPv6 networks, the problem of address/portmapping may still be present due to some restric-tions introduced for security reasons. A SIP SBCis a session-aware device that manages SIP calls atthe border of an IP network. It is aware of bothsignalling and media flows. An SBC may have sev-eral functions, one of the more interesting is solv-ing the problem of NAT/firewall traversal, dealingwith different NAT and/or UA behaviors. In this

respect, an SBC provides NAT/firewall traversalwithout additional customer premise equipment,and without the replacement of existing firewallsand NATs. An SBC does not require any addi-tional STUN/TURN node nor STUN/TURN pro-tocol support [17,20], neither at UA nor at SBCside. Besides NAT traversal, the SBC may haveseveral function, we will only list two of them: (i)the SBC can provide media interworking functionfor different media-related functionalities such as:media transcoder, media encryption and protec-tion against various media-based attacks; (ii) theSBC can provide signaling and media wiretappingsystem, which can be used to enforce requests forthe lawful interception of communication sessions.

From the point of view of SIP signaling, an SBCcan act as a SIP B2BUA (Back-to-Back UA) or asa special SIP proxy. In the former case, the SBCworks as an intermediate node that breaks the sig-naling path between two UAs and interconnectsthem (e.g. setting up a call) by means of estab-lishing separate end-to-end connections betweenitself and each remote UA. In the latter case theSBC does not break the signaling path between thetwo UAs; instead it relays signaling requests andresponses between remote UAs and other proxies,operating all SBC-specific function extending thenormal proxy behavior as defined by RFC 2361. Inaddition to what is defined in the SIP standard forthe operation of a SIP proxy, the SBC will mod-ify the description of media session contained inthe SDP, and some other SIP header fields likefor example the Contact header field. Despite this


extended behavior, obviously all outgoing signal-ing remains fully compliant with SIP standards. Inour solution, we preferred to use a “proxy like”SBC as it is lighter and more “transparent” withrespect to the SIP signaling among the endpointUAs.

In order to manage the user mobility, we pro-pose to add the MMS element into the SBC. TheMMS is an “anchor point” for the media flowswhich are transmitted over the wireless access net-works directed to (and coming from) the MT. Whenthe MMC in the MT detects that a handover isneeded, it will request the handover to the MMS(via a SIP message) over the “target” network.Then the MMS (in the SBC) will update itsmedia proxy and will start transmitting and receiv-ing the media over the target network (details areprovided in the next section). Note that the en-tire handover procedure is handled by the MT andthe SBC, letting the CT (and other SIP intermedi-ate nodes) completely unaware of what is occur-ring. Instead, in the traditional SIP approach theCT is directly involved by the MT with a new“Re-INVITE” transaction. In such case, the CT isin charge of performing the handoff by establishinga new media flow using the IP address of the ter-minal in the “target” network. A first advantage ofthe SBC based handover with respect to CT-basedhandover is that the solution does not rely on theCT capability to perform the handover. Thoughthe SIP standard requires that terminals are ableto support Re-INVITE, compatibility issues mayarise and it will be difficult to verify that the hand-over works with all possible SIP terminals. More-over executing the handover with the CT couldlead to high delays, for this reason various solutionshave been proposed trying to overcome this prob-lem by introducing intermediate entities as tem-porary anchor points (see [1,10]). In our solutionthe anchor point is not temporary, but permanent.This permanent media relay in the path is not a veryefficient solution, but in practice we witness severalrunning services that are implemented in this way.It is also worth noting that the only other solutionwhich allows to overcome a “symmetric NAT” isusing TURN [17], but this exactly requires a mediaproxy box that acts as permanent media relay (andit introduces greater setup and handover latencyrespect to a SBC-based solution). If we can assume

that a SBC is already in the path the introductionof a media relay is definitely not a shortcomingintroduced by our solution. We are simply extend-ing the SIP and media processing capability of theSBC in order to support the handover.

Note that the proposed solution can be appliedexactly as described both in networks with pri-vate IP addresses and in networks with public IPaddresses. In a scenario with private IP networksand in a mixed scenario (where the MT can roamamong both networks with private IP addressesand networks with public IP addresses) the pro-posed solution is able to solve the NAT traversalissues together with the mobility management. Ifwe consider a scenario where the terminal is onlyroaming among networks with public IP addresses,we loose one of the advantages of our solution (asno NAT traversal is needed). This scenario doesnot seem realistic in current networks. Anyway,our solution could also prove useful in this con-text, due to the other advantages listed above: thehandover procedure does not rely on the remoteterminal, the handover delay could be better con-trolled. Moreover for VoIP services offered by apublic network operator, the need to provide “law-ful interception” could imply that media flows areconveyed in any case through a media relay.

For the sake of simplicity, we only describe thesolution considering a single centralized SBC. Inreal life, redundancies must be considered toachieve reliability (e.g. the SBC needs to be repli-cated). Likewise, the SBC functionality could needto be distributed for scalability reasons. A possibleinteresting approach is to split the signaling andmedia relay capability of the SBC (see for exam-ple [14]), which allows to deploy a set of mediarelay boxes that can be placed “close” to the MT.Replication mechanisms for reliability and distri-bution mechanisms for scalability are out of thescope of this paper.

2.2 The MMC in the MT

The MMC can be implemented as shown in Fig. 3 asa separate entity running on the MT that masquer-ades all mobility and NAT traversal functional-ity by relaying both signaling and media flows. Inthis case the SIP User Agent sees the MMC as


SIP User Agent Canonical SIP signalling

Mobility Management SIP signaling

Media packets

MMC

Operating System

Mobile Terminal

Fig. 3 The MMC in the MT

default “outbound proxy” (which means that theUA will send all SIP message to the MMC) and ithas no knowledge of the handovers. Existing SIPUAs can be easily supported/reused without anychanges. A different solution would be to integratethe MMC functionality within the UA, which willlikely imply a greater efficiency in the use of pro-cessing resource of the MT. The two solutions onlydiffer in the internal implementation, while thereis no difference in the external behavior of the pro-cedures. In our test-bed we used the first solution(the one depicted in Fig. 3) so that we can use anyexisting SIP User Agent.

In order to configure the IP addresses on theMT interfaces, existing mechanisms are used (e.g.PPP on the 3G interface, DHCP on WiFi LANand Bluetooth PAN). When multiple interfaces areactive, the MMC needs to select the preferred inter-face for sending/receiving the media flows (whilethe terminal is involved in a call) or for exchangingSIP signaling (both during calls and in idle state).The choice of the selected interface performedby MMC may depend on cost aspects and/or onQoS issues (signal strength, perceived packet lossand/or delay). The discussion of these criteria areout of the scope of this paper.

3 Specification of the procedures

As described in the previous section, the mobilitymanagement involves four main functional enti-ties. On the MT sides there are the SIP UA andthe MMC, while on the network side there are theSBC with the MMS and a SIP Registrar.

The SBC enhanced with the MMS is neededto manage MT handoffs between different accessnetworks providing service continuity and NATtraversal. The SBC is able to process both SIP

protocol header fields and Session Description Pro-tocol (SDP) [12] bodies in order to force itself asrelay for the media packets.

In the SIP architecture, the SIP Registrar recordsthe current location(s) of the user. An SBC cou-pled with an external backend SIP Registrar intro-duces a two levels user location mechanism, wherethe SIP user address (called “Address of Record”or AoR) is mapped by the Registrar server to anew user Uniform Resource Locator (URL) refer-ring to the SBC and then the SBC maps this newURL to the actual address of the user’s UA. Thepresence of a backend Registrar server can let theoverall architecture be more flexible and compat-ible with other server-based services, leaving thecomplete control of such services (e.g. AoR reso-lution or Call Processing Language (CPL)-basedservices) to the backend Registrar/Proxy. Follow-ing this approach, in our proposal the mobility ofthe terminal amongst different access networks iscontrolled by the MMS/SBC, while the externalSIP Registrar simply points to the MMS/SBC ofeach registered user (this means that the user’sAoR is simply mapped to a user-specific URLpointing to the MMS/SBC). The SBC/MMS willtake care of NAT traversal, so that the MT canbe reached by SIP signaling and can send/receivemedia flows even beyond a NAT. As for SIP sig-naling, the MMC in the MT and the MMS in theSBC implement the SIP extension described in [19]which allows the MMC to receive SIP responseson the same port where it sent corresponding SIPrequests. A “keep-in-touch” mechanism is neededto keep the pinhole in the NAT open. Various tech-niques can be used [18] such as dummy UDP pack-ets (from the MMC to the MMS or vice-versa),mal-formed SIP messages, well-formed SIP mes-sages. We use periodic SIP register messages fromMMC to MMS. The “keep-in-touch” packets aresent every 30 s, so they use a very limited amountof resources.

3.1 Location Update Registration: initialand “off-call” mobility management

The Location Update Registration is the basicmobility procedure that allows a MT to notify theMMS about its “position” (or better its IP address)


and select the currently preferred interface forsending/receiving SIP signaling and media flows.The sequence diagram of this procedure is shownin Fig. 4.A. The MMC in the MT sends a Reg-istration Request to the MMS over the “selected”interface. When the 200 OK is received, the “keep-in-touch” mechanism is activated on that inter-face (and deactivated on the previous interface ifneeded). This procedure is activated at the startup of the MT (or when the MT first enters ina coverage area), or whenever the MT wants tochange the selected interface if it is under cover-age of more than one network. We can refer tothis procedure as “off-call” mobility managementbecause we assume that terminal is not engagedin a call. If the terminal is engaged in a call, thehandover procedure will be executed (see lateron).

As result of the Location Update Registrationprocedure, the SBC/MMS becomes aware of thecurrent position of the MT, and can correctly routeany new request or response messages addressedto the mobile UA. A key aspect concerning thisprocedure and its usage is the UA identificationand addressing. In general a user may have morethat one UA active, each one attached to a net-work with its own IP address (and SIP port). Whensending a request or receiving a response, SIP usu-ally identifies the users through the URLs presentwithin the From and To header fields and throughthe request URI, while the actual address of theUA is normally present in the Via and Contactheader fields. Unfortunately, neither the user URLnor the UA address can be used for UA identi-fication since the former is not bound to a spe-cific UA (more user’s UAs can be present) whilethe latter changes each time the UA moves fromone network to another and, in presence of NATs,it is not unique due to the normal reuse ofprivate addresses. For this reason a proper UAidentification mechanism would be needed, butcurrent SIP standard does not provide such mecha-nism. Several solutions are possible and a detailedanalysis of this issue cannot be included in thispaper for space constraints. We used an identi-fier that the MMC inserts in the Contact and inthe Via header fields, and it is denoted as Ter-minal-ID in the SIP messages shown in Fig. 5.The details of the solution have used in the test-

bed can be found in [11], which reports the com-plete SIP messages related to the various proce-dures.

3.2 User Registration

This procedure consists in the UA registration withits own SIP Registrar server (the backend SIP reg-istrar). The sequence diagram of this procedure isdescribed in Fig. 4B. As any other SIP message,when the UA sends its own registration request tothe SIP Registrar, the message is sent by the UAto the MMC which is seen as outbound proxy. TheMMC forwards it to the MMS. Acting on behalfof the MT, the MMS will forward the registrationto the SIP Registrar, which will update the contactaddress associated with the user’s AoR (that is thepublic user identifier). When forwarding the Reg-ister message, the MMS/SBC modifies the Contactheader in such a way it becomes the new “con-tact” for the user. This is required in order to forcethe routing through the SBC/MMS of all furtherrequests addressed to the user. Such mangling ofthe contact URL should be unique and reversible.It can be done in several ways, using either a state-less approach (e.g. by mapping the previous URL,opportunely stuffed, within the new URL) or astateful one (e.g. by using a local mapping table).We have chosen a stateless approach. In messageM5 of Fig. 5 there is an example of the rewrit-ten contact (further details can be found in [11]).From now on, only the MMS will keep track of theMT movements, while the SIP Registrar will justbelieve that the MT location is the IP address ofthe SBC.

3.3 Session establishment

The session establishment procedure consists in astandard SIP session setup procedure. All sessionestablishment messages for MT are handled by theSBC. Before relaying an INVITE request sent bythe caller and the corresponding 200 OK responsesent by the callee the SBC modifies the correspond-ing SDP bodies in order to act as RTP proxy formedia flows in both directions. This is needed tocorrectly handle NAT traversal in the path towards


MMSMMCUA

REGISTER

200 OKA. Location

UpdateRegistration

Mobile TerminalSession Border

Controller

MMSMMCUA

REGISTERREGISTER

REGISTER

200 OK200 OK

200 OK

B. User Registration


Controller

M1

M2

M8

M5M4

M3

M6M7

MMSMMCUA

200 OK

INVITE C. Session Establishment


Controller

CT

REGISTER

200 OK

D. Handover

Corrispondent Terminal

M14

M11INVITE

M10

INVITEM12

200 OK M15

200 OK M13

M18

M17

INVITEM9

200 OKM16

SIP Registrar and Proxy



Fig. 4 Signaling procedures

the MT, and it is done by exploiting the symmetricRTP approach as in a typical SBC implementa-tion.

Once the session is established, the mediapackets start to flow over the selected wirelessinterface. In principle, there is no need to sendanything on the unselected active interfaces, thatshould be used only when an “on-call” mobilityprocedure occurs. On the other hand our practi-cal experience suggested that starting sending thepackets on the 3G interface introduces an initialdelay that can be quite large and can cause notice-able disruption in the voice communication duringthe handoff. Therefore we introduce a “keep-alive”mechanism between MMC and MMS during thecall phase: the MMC sends dummy UDP packetsto the MMS over the unselected wireless interfaces.

The MMS will take care of discarding the receivedkeep-alive packets so that they are not forwardedto the CT.

3.4 On-call mobility: the handover procedure

The on-call mobility management procedure takesplace when the UA identifies the need for hand-off during an ongoing VoIP session. In our pro-posal, all the handover signaling messages can beexchanged on the target network (this approachis commonly referred to as “forward” handover).Therefore the handover can be performed even ifthe communication on the old network is inter-rupted abruptly. The handover procedure is MTinitiated. The MMC in the terminal sends an


Message 1: MMC to MMS REGISTER sip:MMS_IP SIP/2.0 Via: SIP/2.0/UDP Terminal_ID; branch=z9h To: <User_ID> From: < User_ID >;tag=dba Call-ID: 7bb@002 CSeq: 1 REGISTER Contact: <sip: Terminal_ID>

Message 2: MMS to MMC SIP/2.0 200 OK Via: SIP/2.0/UDP Terminal_ID;branch=z9h; received=IP_NAT To: <User_ID> From: < User_ID >;tag=dba Call-ID: 7bb@002 CSeq: 1 REGISTER

Message 3: UA to MMC REGISTER sip:domain.net SIP/2.0 Via: SIP/2.0/UDP MMC_IP;rport;branch=z9h From: <sip:[email protected]>;tag=25 To: <sip:[email protected]> Contact: <sip:User_ID@MMC_IP> Call-ID: FDA@domain CSeq:1 REGISTER

Message 4: MMC to MMS REGISTER sip:domain.net SIP/2.0 Via: SIP/2.0/UDP Terminal_ID;branch=z9h; Via: SIP/2.0/UDP MMC_IP;rport;branch=z9h From: <sip:[email protected]>;tag=25 To: <sip:[email protected]> Contact: <sip: Terminal_ID> Call-ID: FDA@domain CSeq: 1 REGISTER

Message 5: MMS to Registrar REGISTER sip:Reg_IP SIP/2.0 Via: SIP/2.0/UDP MMS_IP;branch=z9h Via: SIP/2.0/UDP Terminal_ID;branch=z9h; Via: SIP/2.0/UDP MMC_IP;rport;branch=z9h Route: <sip: Reg_IP;lr> From:<sip:User_ID@REG_IP>;tag=157 To:<sip:User_ID@REG_IP> Call-ID: FDA@domain CSeq: 1 REGISTER Contact: <sip:/MMS_ID-Terminal_ID@MMS_IP>

Message 6: Registrar to MMS SIP/2.0 200 OK Via: SIP/2.0/UDP MMS_IP;branch=z9h Via: SIP/2.0/UDP Terminal_ID;branch=z9h; Via: SIP/2.0/UDP MMC_IP;rport;branch=z9h From:<sip:User_ID@REG_IP>;tag=157 To:<sip:User_ID@REG_IP> Call-ID: FDA@domain CSeq: 1 REGISTER

Message 7: MMS to MMC SIP/2.0 200 OK Via: SIP/2.0/UDP Terminal_ID;branch=z9h; Via: SIP/2.0/UDP MMC_IP;rport;branch=z9h From: <sip:[email protected]>;tag= 25 To: <sip:[email protected]> Call-ID: FDA@domain CSeq: 1 REGISTER

Message 8: MMC to UA SIP/2.0 200 OK Via: SIP/2.0/UDP MMC_IP;rport;branch=z9h From: <sip:[email protected]>;tag=25 To: <sip:[email protected]> FDA@domain CSeq:1 REGISTER

Message 9: CT to Proxy INVITE sip:/MT_Terminal_ID@MMS_IP SIP/2.0 Via: SIP/2.0/UDP CT_IP; branch=z9h From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Call-ID: F16@192 CSeq: 1 INVITE Contact: <sip:CT_contact> Content-Length: 214

Message 10: Proxy to MMS INVITE sip:/ MMS_ID-MT_Terminal_ID@MMS_IP SIP/2.0 Via: SIP/2.0/UDP Proxy_IP;branch=z9h Via: SIP/2.0/UDP CT_IP From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Call-ID: F16@192 CSeq: 1 INVITE Contact: <sip:CT_contact> Content-Length: 214

Message 11: MMS to MMC INVITE sip:/ MT_Terminal_ID@ SIP/2.0 Via: SIP/2.0/UDP MMS_IP;branch=z9h Via: SIP/2.0/UDP Proxy_IP;branch=z9h Via: SIP/2.0/UDP CT_IP From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Record-Route: <sip:MMS_IP;lr> Call-ID: F16@192 CSeq: 1 INVITE Contact: <sip:/MMS_ID-/~CT_ID/AT-MMS_IP/PORT-5070@MMS_IP> Content-Length: 214

Message 12: MMC to UA INVITE sip:/ MT_Terminal_ID SIP/2.0 Via: SIP/2.0/UDP MT_Terminal_ID;branch=z9h Via: SIP/2.0/UDP MMS_IP;branch=z9h Via: SIP/2.0/UDP Proxy_IP;branch=z9h Via: SIP/2.0/UDP CT_IP From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Call-ID: F16@192 CSeq: 1 INVITE Contact: <sip:/MMS_ID-/~CT_ID/AT-MMS_IP/PORT-5070@MMS_IP> Content-Length: 214

Message 13: UA to MMC SIP/2.0 200 OK Via: SIP/2.0/UDP MT_Terminal_ID;branch=z9h Via: SIP/2.0/UDP MMS_IP;branch=z9h Via: SIP/2.0/UDP Proxy_IP;branch=z9h Via: SIP/2.0/UDP CT_IP From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Call-ID: F16@192 CSeq: 1 INVITE Contact: < sip:MT_User_ID@MMC_IP >

Message 14: MMC to MMS SIP/2.0 200 OK Via: SIP/2.0/UDP MMS_IP;branch=z9h Via: SIP/2.0/UDP Proxy_IP;branch=z9h Via: SIP/2.0/UDP CT_IP From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Call-ID: F16@192 CSeq: 1 INVITE Contact: < sip:MT_User_ID@MMC_IP >

Message 15: MMS to Proxy SIP/2.0 200 OK Via: SIP/2.0/UDP Proxy_IP;branch=z9h Via: SIP/2.0/UDP CT_IP From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Call-ID: F16@192 CSeq: 1 INVITE Contact: < sip:MT_User_ID@MMC_IP >

Message 16: Proxy to CT SIP/2.0 200 OK Via: SIP/2.0/UDP CT_IP; branch=z9h From: <sip:[email protected]>;tag=871 To: <sip:[email protected]> Call-ID: F16@192 CSeq: 1 INVITE Contact: < sip:MT_User_ID@MMC_IP >

Message 17: MMC to MMS REGISTER sip:MMS_IP SIP/2.0 Via: SIP/2.0/UDP Terminal_ID; branch=z9h To: <User_ID> From: < User_ID >;tag=dba Call-ID: 7bb@002 CSeq: 1 REGISTER Contact: <sip: Terminal_ID> HO_Call_Id:F16@192

Message 18: MMS to MMC SIP/2.0 200 OK Via: SIP/2.0/UDP Terminal_ID;branch=z9h; received=IP_NAT To: <User_ID> From: < User_ID >;tag=dba Call-ID: 7bb@002 CSeq: 1 REGISTER

Fig. 5 SIP messages


“handover” Register message over the target net-work interface addressed to the MMS in the SBC.Differently from a Location Update Registerrequest, the handover Register request containsin the message body the reference to the activesession to which the handover is referred.

At the same time, the MT starts duplicating theoutgoing media packets on both interfaces (unlessthe old interface has gone down). As soon as theMMS in the SBC receives the Register message, itwill start accepting packets coming from the newinterface and discarding the ones coming from theold interface for the media flows corresponding tothe call ID contained in a specific header in thehandover Register message. Then it will send backthe SIP 200 OK message to the MMC and startsending the media packets directed to the MT usingthe new interface. Thanks to the fact that the ter-minal has already started sending the packets onthe new interface, the duration of the handover isminimized.

The most critical issue is that the “handover”Register message could be lost for any reason,delaying the handoff procedure. The standard SIPprocedure foresees that the client performs a setof retransmission of the Register if the 200 OKis not received back. The SIP standard suggests adefault value of the retransmission timeout equalto 500 ms, that is doubled on each retransmission.However this is not compatible with a reasonableperformance of the handover in case of the lossof the Register message. Therefore we mandatethat for the “handover” Register message a differ-ent duration of the retransmission timer is used.Register messages are sent with a fixed interval of200 ms until the 200 OK is received or a transac-tion timeout occurs. The transaction timeout is setto 3 s corresponding to a maximum of 15 retrans-missions. On the terminal side, the MMC will stopduplicating the packets on both interfaces as soonas the 200 OK is received or the first media packetis received on the new interface. Note that if themedia packet is received, but no 200 OK message,the MMC will still continue sending the Registermessage until the Register transaction expires.

The criteria for taking the handover decision canbe based on:

- the quality of the received signal (power, S/Nratio)

- on IP level measurements of the QoS in the pathbetween the MT and the SBC over the differentwireless networks (packet loss, jitter)

- on the cost of the connections.

The analysis of these criteria is out of the scope ofthis paper.

3.5 Comparison with canonical SIP basedmobility

In classical SIP based mobility, when the MT movesto a new access network changing its IP addressduring a call it re-invites the remote CT in orderto re-establish a new media streams (the handoveris handled by the remote CT). Then the MT hasto register the new address to the SIP registrar.Instead, in the proposed solution the two func-tions are tied in just one registration procedurebetween the MT and the SBC, while the corre-sponding terminal is let completely unaware of theMT movement. This increases the handover per-formances, increases the compatibility with legacyremote terminals that might not handle correctlythe re-invitation procedure, guarantees a betterprivacy (since the position and movement of theMT are hidden by the SBC).

4 Implementation and measurements

We have implemented the proposed solution andrealized a testbed across our University campusnetwork (both over WiFi and Bluetooth), a WiFinetwork connected to an operator’s network (Tele-com Italia) via ADSL and two different 3G net-works (Vodafone and TIM). The testbed layout isshown in Fig. 6. The MTs has been implementedusing laptops with Windows XP SP-2 (this ver-sion of XP is only required for Bluetooth), theSBC and the SIP Registrar are implemented on astandard PC (both Windows XP and Linux can beused). MMC and MMS have been implemented inJava using (and modifying) the open source MjSipJava SIP stack [15]. As SIP User Agent we used


Fig. 6 Testbed layout

the Xlite software client [24]. The laptop is equippedwith an internal WiFi card, with a PCMCIA cardfor 3G access, and a BT dongle compatible withXP SP-2. As WiFi access network we used bothan our own Access Point connected to the Cam-pus Fixed Lan, and a WiFi network in our labswhich is connected to Telecom Italia backbone. As3G network we used the Vodafone network andthe TIM network. As Bluetooth access networkwe used a Linux host with a Bluetooth dongle andthe open source “BlueZ” Bluetooth stack [3]. TheLinux host is configured to bridge the BluetoothPAN with the fixed Ethernet LAN, so that a cli-ent host connecting to the PAN simply gets an IPaddress valid on the fixed Ethernet LAN.

The SBC and SIP Registrar were located in ourcampus LAN and given a public IP address. AsCorrespondent Terminals we experimented both aPC in our campus LAN and a PC using an ADSLaccess.

In the Mobile Terminal, the MMC interacts withthe operating system by checking the status ofthe interfaces with the “ipconfig” command. TheMMC offers a simple Graphical User Interfacewhich shows the currently active interfaces andallows to control the handover by choosing the“selected” interface.

No handover decision criteria are implementedin the described testbed. The handover decisionis manually provided through the Graphical UserInterface of the MMC.

On the testbed we first assessed the performanceof the different access networks (in particular the3G cellular networks) in the support of VoIP appli-

cation (Sect. 4.1) and then the performance of theproposed handover procedure (Sect. 4.2). We per-formed some subjective measurements of the per-ceived VoIP quality during the HO procedure andwe found that the voice impairments are due tothe different networks delays experimented by theWLAN (or Bluetooth) and the 3G networks (asshown later in Fig. 8), while no impairment is per-ceived making the handover among two networkswith the same delay. We are currently workingon objective evaluation of voice quality using anapproach [6] based upon a reduction of the ITU-T’s E-Model [13] to transport level measurablequantities

4.1 Evaluation of access network performance

In order to evaluate the performance of differentaccess networks, we have developed a tool named“Throcalc” which is able to evaluate packet loss,Round trip time (RTT) and one-way delay jitterwith powerful NAT traversal capability. The tool iscomposed of a client side which runs on a PC (bothWindows and Linux OSs are supported) whichcan be equipped with any network interface anda server side which we run on a PC with public IPaddress on our university campus network (e.g. onthe same host where the SBC/MMS is located).Therefore we are able to evaluate the performanceof the “uplink” (from MT to SBC/MMS) and“downlink” (from SBC/MMS to MT) channels overthe different wireless network. Note that the per-formance that we will consider is not only relatedto the wireless part of the path. For example whenevaluating the performance of a 3G network, weinclude the fixed part of the radio access network,the IP backbone of the 3G operator, the Internetpath from the 3G operator up to our campus net-work and finally the path from the campus networkborder router up to the SBC/MMS. Anyway this isexactly the path that will be crossed by voice pack-ets that cross the SBC/MMS.

A more detailed report of the measurementcampaign can be found in [11], we only presenthere the main results. We measured a very good(i.e. low) loss rate using all the different access net-work. Table 1 reports a sample of our loss measure-ments over the different access network. On the


Table 1 Packet loss ratio of the different network access

BlueTooth WiFi 3G net 1 3G net 2

Average packet loss ratio 0.11% 0.06% 0.79% 0.24%Maximum packet loss ratio 0.13% 0.13% 2.89% 0.29%

other hand the RTT was not good whenusing both the 3G networks that we have tested(we recall that the measurements are related tothe whole path from MT to SBC, which does notonly include portions of 3G network, although webelieve that the loss and delays are mainly relatedto the 3G portion of the path). Fig. 7 shows thecumulative distribution of RTT for the differentaccess networks. Each distribution is evaluated withfive different tests of duration 60 s repeated with15 min interval during a working hour (e.g. 11 am).The average RTT is in the order of 400 and 800 msfor the two networks and even worse is the 95%percentile which is in the order of 600 and 1,000 ms,resulting in a degradation of voice experience.

4.2 Evaluation of handover performance

We analyzed the performance of the handover bycapturing the media and signaling packets on theMT and on the SBC, using the Ethereal passivemeasurement tool [7]. We did not consider the pathbetween the SBC and the Correspondent Termi-nal, as it does not impact the performance of thehandover. The GSM codec at 13 kb/s was used. Wehave recorded the departure and arrival times ofvoice packets at the MT and at the SBC. We ana-lyzed both the uplink flow (MT→SBC) and thedownlink flow (SBC→MT) and we considered thehandovers from WiFi to 3G and vice-versa (in totalwe have 4 scenarios).

Looking at the 4 graphs in Fig. 8, in the x-axis weput the departure time of packets from the orig-inating interface, while in the y-axis we put thearrival time of the packets at the destination inter-face. As the clocks are not synchronized, the timeis relative to the first sent or received packet onthe interface and we are not able to measure theabsolute “one-way delay”. This is not a problem,as we are interested in the differential delay amongarrived packets. For the different scenarios we will

discuss: (1) the impact of the difference in the one-way delay between the WiFi and the 3G networkduring the handover; (2) the handover completiontime, i.e. the time elapsed from when the MMCstarts the handover procedure and when the proce-dure is completed and the voice in both directionsis flowing on the target interface.

Let use define as Uup and Udn the one way delayfor the 3G network in the uplink (MT → SBC) anddownlink (SBC → MT) direction. These delay donot only cover the 3G network, but all the pathfrom MT to SBC, crossing the 3G network (seeFig. 6). Similarly we define Wup and Wdn for theWiFi network. In the performed experiments, themeasured RTT between the MT and the SBC forthe 3G access (i.e. Uup+Udn) was in the range of200 ms (as shown in Fig. 9), while for the WiFiaccess (i.e. Wup+Wdn) was in the range of 20–25 ms.

Figure. 8 reports the results for the 4 scenarios.From the diagrams related to uplink (a and b) wecan give an estimate of the difference in the “one-way delay” for the 3G access and for the WiFiaccess in the “uplink” (i.e. Uup − Wup). As thepackets are duplicated, the difference in the y-axisbetween the arrival of the same packet sent on theWiFi and on the 3G interface is the delay differ-ence. It turns out that at the time of our tests, uplinkone-way delay experienced in the 3G access is 80–110 ms higher than the one experienced in WiFi.A set of packets will arrive from the 3G interfacewhich are the copies of the already arrived packets.This packets, marked with a circle in Fig. 8a, willbe forwarded and received by the CT as duplicatedpackets. The duration of this burst of duplicatedpackets is equal to the difference of the “uplink”one way delay between WiFi and 3G (Uup − Wup).As for the handover completion time, it roughlycorresponds to the RTT on the target interface(3G in this case: Uup + Udn).

We measured 270 ms for the interval betweenthe REGISTER and the 200 OK (i.e. the handover


Fig. 7 Cumulativedistribution of RTT fordifferent access network

RTT Cumulative Distribution

0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%90,00%

100,00%

0 250 500 750 1000 1250 1500 1750 2000 2250 2500

RTT (msec)

Cu

mu

lati

ve P

erce

nta

ge

BlueTooth

WiFi

3G net 1

3G net 2

Uplink, WiFi -> 3G

12200

12300

12400

12500

12600

12700

12800

12900

13000

12200

rel.

arri

val t

ime

(ms)

rel.

arri

val t

ime

(ms)

rela

tive

arr

ival

tim

e (m

s)

relative arrival time (ms)

rel.

arri

val t

ime

(ms)

rel. depature time (ms)

rel. depature time (ms) rel. depature time (ms)

3G

WiFi

Uplink, 3G -> WIFI

7500

7600

7700

7800

7900

8000

8100

8200

3G

WiFi

Downlink, WiFi -> 3G

12000

12200

12400

12600

12800

13000

13200

3G

WiFi

Downlink, 3G -> WiFi

7300

7400

7500

7600

7700

7800

7900

8000

8100

3G

WiFi

12900 7400 7600 7800 8000 8200 8400

7800 8000 8200 8400 8600 8800

128001270012600125001240012300

12200 1300012800126001240012200

(a)

(c) (d)

(b)

Fig. 8 RTP arrival patterns during handovers in 4 scenarios

duration as perceived by the MT) in the test shownin Fig. 8a. As a confirmation, we can see that in Fig.8a the packets are duplicated from t = 12,430 msto t = 12, 700 ms. This duration is almost entirelycaused by the RTT between MT and SBC/MMS.This is confirmed in Fig. 9 which shows the RTTmeasured analyzing the traces of RTP packets cap-tured on the MT and on the SBC/MMS for 6 s fol-lowing the handover.

In case of the handover from 3G to WiFi(always in the uplink case), the MT sends the SIPREGISTER message on the “faster” WiFi networkand starts duplicating the voice packets. When theSBC receives the REGISTER it will start accept-ing packets sent on the WiFi interface and discard-ing those sent on the 3G interface (marked with a

square in Fig. 8b). The first received packets senton the WiFi interface will have an higher sequencenumber than the last one received coming fromthe 3G interface, as the packets sent on the WiFiinterface have “overcome” the ones sent on the3G interface. A number of packets will be lost, andthese packets are marked with the solid square inFig. 8b. The duration of the burst of lost packets isagain equal to the difference in the uplink one waydelay between 3G and WiFi network. As for thehandover completion time, we measured 32 ms forthe interval between the REGISTER and the 200OK in the test shown in Fig. 8b. In fact, the pack-ets are duplicated from t=7,906 ms to t=7,938 ms.Coming to the downlink flows, let us consider thehandover from WiFi to 3G (Fig. 8c). The SBC will


(e), RTT, WiFi->3G

0

100

200

300

400

500

0 1000 2000 3000 4000 5000 6000

Time from handover ending (ms)

)sm(

TT

R

Fig. 9 RTT estimation after handover procedure ending(3G network)

1 2 3 4 5

Handover completion time ≈ Uup+Udn

32 4 5 6

SIPREGISTER

SIP200 OK

MT

SBC

Fig. 10 Temporal diagram for WiFi → 3G handover

stop sending packets towards the WiFi networkand start sending them towards the 3G networkwhen the REGISTER message is received. Thefirst packet sent towards the 3G network will expe-rience an additional delay equal to the differencein the “downlink” one way delay between 3G andWiFi network (Udn-Wdn) which is in the order of200 ms in Fig. 8c. The gap shown does not repre-sent a loss of some packets, it only shows a delaybetween the reception of the last packet sent onthe WiFi interface and the reception of the firstpacket sent on the 3G interface (Fig. 10).

Finally, let us consider the handover from 3G toWiFi for the downlink flow (Fig. 8d). As soon asthe REGISTER message is received by the SBCthe packets will be sent towards the WiFi interfaceand will arrive at the MT in advance with respectto packets with lower sequence number previouslysent towards the 3G interface. The duration of theadvance is equal to the difference in one-way delay(in the order of 200 ms in Fig. 8d. Note that nopackets are lost in this handover, the gap in Fig. 8drepresents the timing advance of the first packetssent on the WiFi interface that experience lower

(a) Uplink, WiFi -> 3G

WiFi

(da Fig. 6-a)

WiFi3G (da Fig. 6-a)

3G

0500

100015002000250030003500400045005000

0 500 1000 1500 2000 2500 3000 3500

relative departure time (ms)

)sm( e

mit lavirra evitaler

Fig. 11 RTP arrival pattern without keep-alive on the unse-lected 3G interface

delay and arrive before the last packets sent on the3G interface.

Similarly to what we have done in the uplink,from the data reported in Fig. 8c and d we can eval-uate the difference in one-way delay for the down-link Udn-Wdn. In our test we measured that 3Gone-way downlink delay was from 80 ms to 110 mshigher than WiFi. The results show that the differ-ent delay between the WiFi and 3G network is acritical factor. If the differential delay is reasonablylow the voice decoder is able to hide the handoff. Inour tests, where Uup-Wup and Udn-Wdn are in theorder of 110 ms, the handovers are not perceived.

It is interesting to compare the results shown inFig. 8 with the corresponding measurements with-out using the keep-alive mechanism introduced inSect. 3.3. As we can see in Fig. 11, which reportsthe uplink measurement for the WiFi to 3G hand-over, the initial differential delay between the 3Gand WiFi is in the order of 2.8 s. Correspondingly,we have that the duration of the handover (duringwhich all packets are duplicated) is in the order of3 s. This is due to the fact that starting to transmitover a 3G interface requires a considerable amountof time. Just for comparison, we have reported thediagram of Fig. 8a in an arbitrary position in theleft part of Fig. 11.

It is possible to appreciate the difference in termsof handover duration and of the distance between3G and WiFi packet arrival time. The conclusion isthat the keep-alive mechanism is needed to supportseamless handover. The results shown in Fig. 8 con-sider the favorable case in which both interfacesremain active during the handover. It can happenthat the old interface goes down suddenly and doesnot allow to transmit packets during the handover.


In our solution, the uplink flows are not affected,as the MT starts sending packets on the new inter-face immediately. On the contrary, the downlinkflows are affected, as the SBC will start transmit-ting packets towards the new interface only afterreceiving the handover request from the MT. Wehave analyzed this case with temporal diagramssimilar to the one shown in Fig. 10 and we haverepeated the measurements of handover perfor-mance. The full results are not shown here for spaceconstraints, anyway we have found theoreticallyand measured from the testbed that on the down-link flow we have an impairment in the order ofUup + Wdn for the handover 3G → WiFi and in theorder of Wup + Uup for the handover WiFi → 3G.

Similarly to what we have done for WiFi and3G networks, we evaluated the performance of ourhandover mechanism, switching from Bluetooth to3G network and vice versa. The performances ofthe BT network are very similar to the behavior ofWiFi network as shown in Table. 1 and in Fig. 7.To support this statement, in [11] we report all theuplink and downlink measurement results for thehandover between Bluetooth and 3G In one sam-ple measurement reported, we obtained 265 ms forthe interval between the REGISTER and the 200OK (i.e. the handover duration as perceived by theMT).

The reported results show that the impairmentsin the handover procedure are due to the intrinsicRTT of the “target” network and to the differentialone way-delays between the origin and the targetnetwork.

5 Related work

A survey on the different mobility managementapproaches to support mobility in VoIP servicescan be found in [2]. Mobility mechanisms for IPnetworks can be classified in IP network layer,transport layer or on application layer mechanisms.Mobility is provided at IP layer by the MobileIP (MIP) [16]. Mobile IP is not directly relatedto VoIP applications, since it is completely trans-parent to the upper layers performing the samebehavior for all incoming/outgoing IP datagrams.It provides the MT with a single IP address that“follows” the terminal in its wandering. The maindisadvantage of MIP approach is that it needs a

support from the routers in each access network.A MIP terminal will be able to roam only over MIPenabled access network.

SIP-based solutions belong to application layermechanisms and they are usually based on SIP sig-naling for re-negotiating the media sessions whena handover occurs, as described also in [23]. In theclassical SIP based approach the handover is per-formed end-to-end, only involving the MT and theCT.

In both the approaches (MIP and SIP) there isthe need to minimize the service disruption dur-ing a handoff procedure and this issue has beenaddressed in several works (see for example [5,10].An interesting work on SIP-based mobility canbe found in [1]. The approach proposed in [1]is similar to the one exploited by our proposal,with some fundamental differences. In [1] the au-thors propose to re-negotiate the session with theremote UA (assisted by an intermediate SIP node)while we propose to use only the intermediate node(the SBC/MMS), with the main advantages of: (i)reducing the latency of the overall handover proce-dure (ii) overcoming eventual compatibility prob-lems introduced by legacy remote UAs—in fact, inour proposal the remote UA is completely unawareof the mobility procedure. Note that the latter as-pect has also some useful security implication (i.e.the remote UA can not trace the complete move-ment and the current position of the MT). Anotherimportant difference is related to the mode of oper-ation of the intermediate node that in our solutionis proxy-like instead of the B2BUA model pro-posed in [1]. We think that a proxy-style behavioris more flexible, less processor consuming, intro-duces less latency, and reduces the possibility ofsignaling incompatibility.

Other interesting works address the issue of3G/WLAN interworking/integration, both in theresearch community (see for example [4,21]) andin standardization for a like 3GPP or 3GPP2. Theunderlying idea is to include WLAN access in theset of services provided by 3G operators to theirsubscribers. Most of the work done focused on theauthentication and security aspects, while the is-sues related to handoff are still to be investigated.

In our work we assume that the terminal isable to authenticate (separately or in an integratedmanner) to the different access networks and we


focus on the problem of seamless mobility amongstheterogeneous networks and vertical handoffmanagement. Similar focus can be found in [9],which considers the classical SIP based mobility(the handoff is handled by the correspondent ter-minal) rather than our solution to enhance theSBC.

A first version of this work has appeared in [22],which has been enhanced as follows: the role ofSBC has been discussed, the details of SIP sig-nalling have been provided, the Bluetooth PANaccess network and the second 3G operator hasbeen added to the testbed, additional performanceresults are included.

6 Conclusions and future work

In this paper we have presented a solution forseamless vertical handover between heterogeneousnetworks like WiFi and 3G, based on SIP. Thenovelty of the solution is that it is strongly cou-pled with the NAT traversal features provided bythe so called SBCs. Assuming that the MTs willbe mainly roaming on networks with private IPnumbering, the mediation of an SBC is alreadyproposed to solve the NAT traversal issue, there-fore we straightforwardly propose to enhance SBCfunctionality to support the mobility. The proposedsolution can be exploited in the short term by a 3Goperator willing to extend its services to WLAN,by a VoIP provider that uses the 3G network asIP transport and by an enterprise that wants to di-rectly manage its voice services. In the long termthis kind of approach will likely need to be includedin 4G networks, which aim to support communica-tion over heterogeneous networks (including leg-acy networks) in a seamless way.

All the proposed mechanisms have been imple-mented within a test-bed that fully demonstratesthe correctness and simplicity of the solution.Moreover, significant measurement tests have alsobe run in order to provide quantitative evaluationof the roaming solution.

Ongoing work (which was not presented herefor space constraints) concerns the realization ofthe mechanisms to drive the handover decision(both collecting the signal quality information fromthe network interface cards and making IP levelmeasurements during the call active phase).

References

1. Banerjee, N., Acharya, A., & Das, S. K. (2006). SeamlessSIP-based mobility for multimedia applications. IEEENetwork, 20(2), 6–13.

2. Banerjee, N., Wu, W., & Das, S. K. (2003). Mobilitysupport in Wireless Internet. IEEE Wireless Commu-nications, 10(5), 54–61.

3. BlueZ, Official Linux Bluetooth protocol stack,http://www.bluez.org/

4. Buddhikot, M. M., Chandranmenon, G., Han, S., Lee,Y.-W., Miller, S., & Salgarelli, L. (2003). Design andimplementation of a WLAN/CDMA 2000 interworkingarchitecture. IEEE Communication Magazine, 41(11),90–100.

5. Campbell, A. et al. (2000). Design, implementation andevaluation of cellular IP. IEEE Personal Communica-tions Magazine, 7, 42–49

6. Cole, R. G., & Rosenbluth, J. H. (2001). Voice over IPperformance monitoring. ACM SIGCOMM ComputerCommunication Review,31(2), 9–24

7. Combs, G. et al. Ethereal: A network protocol analyzer.http://www.ethereal.com/

8. Cumming, J. Sip Market Overview, http://www.datacon-nection.com/ network/download/whitepapers/sipover-view.pdf

9. Dutta, A., Kim, B., Zhang, T., Baba, S., Taniuchi, K.,Ohba, Y., & Schulzrinne H. (2005). Experimental anal-ysis of multi interface mobility management with SIPand MIP. International conference on wireless networks,communications and mobile computing, 13–16 June2005, Vol. 2, pp. 1301–1306.

10. Dutta, A., Madhani, S., Chen, W., Altintas, O., & Schulz-rinne, H. (2004). Fast-handoff schemes for applicationlayer mobility management. PIMRC, Spain.

11. Fiorani, M., Labella, A., Ordine, A., Polidoro, A., Sal-sano, S., & Veltri, L. (2006). Report of architecture andmeasurements for SBC based vertical handovers. May2006, available at: http://netgroup.uniroma2.it/Stef-ano_Salsano/SIP-SBC-seam-HO/report-2006–05.pdf

12. Handley, M., & Jacobson, V. (1998). SDP: SessionDescription Protocol. IETF RFC 2327, April 1998.

13. ITU-T Recommendation G.107 (1998). The E-Model, acomputational model for use in transmission planning.

14. MediaProxy, http://mediaproxy. ag-projects.com/REA-DME

15. Mjsp open source JAVA SIP stack, http://www.mjsip.org16. Perkins, C. et al. Mobility support ofr IPv4. RFC 3344.17. Rosenberg, J. (2006). Obtaining relay addresses from

simple traversal underneath NAT (STUN). draft-ietf-behave-turn-02 (work in progress), October 2006.

18. Rosenberg, J. et al. (2002). SIP: Session Initiation Pro-tocol. IETF RFC 3261, June 2002.

19. Rosenberg, J., & Schulzrinne, H. (2003). An Extensionto the Session Initiation Protocol (SIP) for symmetricresponse routing. IETF RFC 3581, August 2003.

20. Rosenberg, J., Weinberger, J., Huitema, C., & Mahy, R.(2003). STUN-simple traversal of User Datagram Pro-tocol (UDP) Through Network Address Translators(NATs). IETF RFC 3489, March 2003


21. Ruggeri, G., Iera, A., & Polito, S. (2005). 802.11-basedwireless-LAN and UMTS interworking: Requirements,proposed solutions and open issue. Computer Networks,47(2), 151–166.

22. Salsano, S., Veltri, L., Martiniello, G., & Polidoro, A.(2006). Seamless vertical handover of VoIP calls basedon SIP Session Border Controllers. In IEEE Interna-tional Conference on Communications, ICC’06, 11–15June 2006, Istanbul, Turkey.

23. Schulzrinne, H., & Wedlund, E. (2000). Application-layer mobility using SIP. Mobile Computing and Com-munication Review, 4(3), 47–57.

24. Xlite SIP User Agent, http://www.counterpath.com/

Stefano Salsano wasborn in Rome in 1969.He received his hon-ours degree in Elec-tronic Engineeringfrom the Universityof Rome (Tor Verg-ata) in 1994. In 1998he was awarded aPhD from the Univer-sity of Rome (La Sa-pienza). Between theend of 1997 and 2000,he worked with Co-RiTeL, a telecommu-

nications research institute, where he was co-ordina-tor of IP-related research. Since November 2000 hehas been an assistant professor (“Ricercatore”) at theUniversity of Rome (Tor Vergata) where he teachesthe courses on “Telecommunications transport net-works” (“Reti di trasporto”) and on “Telecommu-nication networks”. He has participated in the EUfunded projects INSIGNIA (on the integration of theB-ISDN with Intelligent Networks), ELISA (on the inte-gration of IP and ATM networks, leading the work pack-age on Traffic Control), AQUILA (QoS support for IPnetworks, leading the work package on Traffic Control),FIFTH (on internet access via satellite on high-speedtrains), SIMPLICITY (on simplification of user accessto ICT technology, leading the work package on archi-tecture definition), E2R (on reconfigurable radio sys-tems), SMS (on service authoring platforms for mobileservices, leading the work package on system architec-ture). He has also participated in ESA founded pro-jects (ATMSAT, ROBMOD) and in national projectsfounded by the Italian Ministry of University and Research(MQOS, NEBULA, PRIMO, TWELVE). His currentresearch interests include Ubiquitous Computing and Wire-less LANs, IP telephony, Peer-to-peer networking architec-tures, QoS and Traffic Engineering in IP networks. He isco-author of more than 50 publications on internationaljournals and conferences.

Luca Veltri received hisLaurea degree in Telecom-munication Engineering andhis Ph.D. in Communica-tion and Computer Sciencefrom University of Rome“La Sapienza" in 1994 and1999, respectively. In 1999he joined CoRiTeL, a re-search consortium foundedby Ericsson Telecomunicaz-ioni, where he worked until2002. Since 2002 he is assis-tant professor at Universityof Parma (Italy), where is

currently working and where he teaches classes on Telecom-munication Networks, Multimedia Communications, andNetwork Security. His main research fields are: IP telephonyand P2P systems, mobility management in next generationnetworks, and network security. He worked in several re-search projects founded by the EU, by ESA and by theItalian Ministry of Research.

Alessandro Ordine re-ceived his “LaureaSpecialistica” Degree inTelecommunications Engi-neering (University ofRome “Tor Vergata”) inApril 2004 with a the-sis on “Controlling TCPFairness in WLAN accessnetwork”. Since Novem-ber 2004, he is a PhDstudent at University ofRome “Tor Vergata”. Hehas participated in the EUproject FIFTH (on inter-

net access via satellite on high-speed trains) and in the Ital-ian PRIN TWELVE (on the service differentiation in 802.11networks). His current research interests include analysis ofTCP and VoIP over Wireless LANs.

Andrea Polidoro re-ceived his “LaureaSpecialistica” degreein Telecommunicati-ons Engineering (Uni-versity of Rome “TorVergata”) in July 2005with a thesis on “Red-uction of signalingtraffic in MPLS-TEnetwork” (“Ingegne-ria del traffico in unarete MPLS-TE mecca-nismi per la riduzionedel carico di segnalazi-

one”). Since November 2005, he is a PhD student at Uni-versity of Rome “Tor Vergata”. Currently he is working onIP telephony and IP mobility research activities.

architecture and testbed implementation of vertical handovers

Documents