Using SIP for Seamless Handover in ... - Semantic Scholar

Using SIP for Seamless Handover in Heterogeneous Networks Elin Sundby Boysen

Joakim Flathagen

UNIK - University Graduate Center Kjeller Norwegian Defence Research Establishment (FFI) Kjeller, Norway Email: [email protected]

Norwegian Defence Research Establishment (FFI) UNIK - University Graduate Center Kjeller Kjeller, Norway Email: [email protected]

Abstract—Today’s mobile telephone users are often equipped with advanced handsets with multimode capability. Such handsets are capable of connecting to different network types such as WLAN, WiMAX and UMTS, which enables the user to utilize the preferred network type regarding cost and quality of service. A major challenge is to maintain session continuity when changing connection across heterogeneous networks. With the increased demand for mobility support in VoIP we therefore propose a proactive scheme to enable seamless handover across heterogeneous networks using SIP, the SIP Handover Extension. In contrast to other schemes, our extension omits the need for additional network entities and maintains backward compatibility with standard SIP. The SIP Handover Extension is analyzed in a network simulator and implemented in a demonstrator. The analysis and simulation results presented show that our proposal can effectively eliminate the handover period in certain scenarios. Index Terms—SIP, VoIP, Mobility, Vertical Handover, UMTS, WLAN

I. I NTRODUCTION As the wireless technologies have evolved, so have also the users’ expectations. Mobile terminals equipped with multiple radio network interfaces are becoming the standard, and the users expect to be able to use the most suitable interface considering cost or communications quality. When switching between different network types in such a heterogeneous environment, the need for better handover routines appears. In homogeneous networks such as UMTS networks, handover routines exist and decisions are based on parameters like link layer quality and signal strength. Handover information is shared between the base stations within the homogeneous domain, and the handover itself is initiated by the network. In heterogeneous networks, on the other hand, such common sharing of information does not necessarily exist, and the metrics triggering the handover will vary among the different network types. Thus, when operating in a heterogeneous environment, the terminal itself must be responsible for initiating the handover when it is needed and possible. In this paper we show how this can be achieved. A serious problem when switching between two network types while communicating voice or video, is that the handover delay becomes too long. During the handover delay, the packets sent from the correspondent node (CN) to the mobile node (MN) can be lost, and likewise for packets that should have

been sent from the MN to the CN. For real-time applications running over UDP –as is the focus of this paper– there is no use in re-sending these lost packets, and the loss will be perceived as poor communications quality by the end users, or - in the worst case, lead to collapse in voice or video codecs. Here, we define handover delay as the time needed to 1) discover that the connection to the current access point (AP) is lost or degrading 2) find a new access point, gain access and establish a new data link with a new IP address 3) inform the CN about the new address The Session Initiation Protocol (SIP) has become the de facto standard for voice over IP (VoIP) and other real-time traffic such as video. The subject of mobility in SIP has already been studied for some time. The first solution was suggested by Wedlund and Schulzrinne in 1999 [1]. This solution suffers from the handover delays presented above. Several studies have aimed at improving handover performance and propose additional schemes that can reduce the handover delay and packet loss [2]–[4]. These proposals introduce new network entities to aid handover. Another solution makes use of entities that are usually already present in a VoIP provider’s network [5]. Our contribution differs from the previous schemes by being able to provide handover functionality without the need for new entities in the access networks or subdomains. It can be used directly between two end nodes, or by using an intermediate node such as a back-to-back user agent (B2BUA). It also uses a separate SIP extension as opposed to overloading existing extensions. Our Handover Extension has been presented in [6]. In this paper we evaluate the scheme using two central target applications for SIP. The first is the use of SIP in a mobile scenario where the user is communicating over UMTS but enters a WLAN. The second scenario examines a typical office usage where a user has an ongoing session on a stationary unit and then decides to move around, still communicating but switching to WLAN. The Handover Extension makes it possible to receive media over the new interface while keeping the old, it is possible to assess the quality of the new link before the old session is terminated. The SIP Handover Extension is evaluated in these

TABLE I SIP METHODS Method ACK BYE CANCEL INVITE OPTION REGISTER

Description Confirm a successful session establishment Tear down a session Cancel a pending request Initiate a session or re-negotiate an ongoing session Request information about the capabilities of another UA or proxy server Add, remove, or query the UA’s address bindings in the location service

scenarios through simulations and implementation. Areas of interest are: First, the time needed to perform a handover; And second, how does the amount of traffic in the network influence the setup time and the difference in delay in the two RTP streams running simultaneously over the old and the new link. The remainder of this paper is organized as follows. In section II we give a brief introduction to SIP before we present the Handover Extension. In section III we present the simulation setup and discuss the two simulation scenarios with their corresponding results. This section also describes the implementation of a user agent supporting the Handover Extension. Finally we conclude the paper in section IV with a few words about the practical significance of the results obtained and points out possible future research directions. II. SIP H ANDOVER E XTENSION In this section we provide a short overview of SIP before we present our Handover Extension scheme. A. A short introduction to SIP SIP is an application-layer protocol developed by IETF. The core functionality is specified in RFC3261 [7]. It is used to set up, tear down and modify a multimedia session between one or more participants. This means that SIP establishes the context for the multimedia sessions, but does not carry any multimedia content itself. This is done using other multimedia protocols such as RTP. Table I lists the six basic methods in SIP. Other methods like REFER, NOTIFY, MESSAGE, SUBSCRIBE and INFO have been added later. A message consists of the method name and a set of header fields. Information about the session itself, such as type of content or coding schemes, is given using the Session Description Protocol (SDP) [8] in the body of the SIP message. SIP consists of different logical entities such as UAs (user agents), B2BUAs, registrars, proxies and redirect servers. These entities are logical units, and some of them can be located in the same physical unit. The B2BUA is, as the name implies two user agents back to back. It can act as a stateful proxy that forwards requests and answers with provisional responses, but in contrast to the stateful proxy, the B2BUA is the end point of the dialog and sets up a new dialog on the other side. A B2BUA can initiate and terminate calls.

Fig. 1.

Example of session setup and termination.

A session setup is depicted in Fig. 1. The SIP user agent on Alice’s phone sends an INVITE message to Bob. The request is first handled by a proxy in Alice’s domain. The proxy will perform a DNS lookup and forward the request to Bob or to a new proxy one step closer to Bob as in Fig. 1. SIP inherently supports mobility in terms of pre-call mobility and mid-call mobility. To provide pre-call mobility, each MN notifies a registrar of its’ new address. When sending an INVITE request to the SIP server in MN’s domain, a CN trying to reach the MN will receive a ’302 Moved temporarily’-response containing the MNs current address. Mid-call mobility allows the MN to change address during an ongoing session. The MN sends an INVITE request with the updated address information to the CN which re-directs the session data and subsequent signaling to the new address. But, as previously mentioned, with the possibilities of long handover delays and packet loss. SIP can be extended with additional functionality in addition to the core specification. This is done through extension headers defined in additional RFC specification documents. The SIP extensions can be viewed as building blocks that make it possible to use SIP in applications with more specific requirements. By combining different SIP extensions with the core SIP, advanced functionality can be achieved. We draw advantage of this extensibility feature in our handover scheme. B. The handover scheme Handover in heterogeneous networks usually means handover between two domains controlled by different operators. A VoIP user can have WLAN access in his home from one operator and UMTS access via another operator. As the VoIP provider can be independent of either of these, the provider does not necessarily have control over any of the access nets the user chooses to connect through. Therefore, a handover solution that can easily be implemented and deployed, and that requires only small changes in core entities and in the MN is desirable. Previous attempts to solve the problem include work by Boysen et al. [9] and Salsano et al. [5] which provide examples of such solutions. Both these solutions require that

a Back-to-back user agent (B2BUA) in the first scheme, or a Session Border Controller (SBC) in the latter, acts as an RTP proxy that forwards the media packets between MN and CN. In operator environments, the SBC is a necessary element that provides functionalities such as protection against Denial of Service (DoS)-attacks, legal interception of sessions, and NAT and firewall issues. However, making a standard handover procedure dependant on operator entities such as B2BUAs and SBCs restricts possible use of SIP and SIP mobility in non-operator environments. For example, SIP can be used for signalling in mobile communication units used in military or rescue operations. For such scenarios, the B2BUA/SBC acting as an RTP proxy can become a vulnerable hot spot. In addition, the bridging of the calls can become a bottleneck in terms of scalability. To avoid this, and also make it possible to make use of the SIP property of signalling and media taking different paths, we have proposed a new SIP extension, the Handover Extension to provide seamless handover. The main differences between our contribution and the two previously mentioned are that (i) a separate SIP extension is proposed to signal that a handover is required; and (ii) if the CN also supports the Handover Extension, media handover can be performed directly from the CN and not by the B2BUA. Thus, in a network where one can assume that all nodes support the Handover Extension, it will be possible to omit the use of a B2BUA as anchor point as all nodes will be able to support the other nodes’ mobility. When setting up a session, the MN will send an INVITE message with Handover as a parameter in the Require header. This is sent either directly to the CN or to a B2BUA in the home network of the MN’s VoIP provider. In the latter case, the B2BUA forwards the requests to the CN. One of the following situations can occur: 1) If the CN does not support handover it will answer with a 420 Bad extension response. If the INVITE was sent directly between MN and CN, this means that the MN will have no mobility support and must fall back to ordinary SIP functionality. On the other hand, if the INVITE was sent via a B2BUA, the B2BUA will transmit a new INVITE message to the CN without the Require header and it will take the responsibility as an anchor point for any handover that may occur during the session. In this case all media traffic will be bridged in the B2BUA. CN will be ignorant of any handover that occurs during the call. This is shown in Scenario A in Fig. 2. 2) If the CN does support handover it responds with a 200 OK message containing a Supported header with Handover as one of the listed supported extensions. In this case all media traffic can be sent directly between the end points. This is shown in Fig. 3. If the INVITE message was sent via a B2BUA, it can choose whether to let the rest of the signalling during this session go directly between the end points as in Fig. 5 or to keep track of the signalling as in Fig. 4.

Fig. 2. SIP handover Scenario A. CN does not support the Handover Extension. (1) and (2) depict signalling at session setup. (3) and (4) are media paths after session setup. (5) and (6) are signalling and media paths during and after handover. Data traffic though (6) is forwarded by B2BUA over (4).

Fig. 3. When receiving the INVITE with Handover, the CN sends media to both interfaces. If CN does not support handover, this would be done by the B2BUA.

A new INVITE message is sent over the new network interface when the handover is triggered. The new INVITE message has a new Call id and a new From-tag. It is consequently seen as a new dialog. In this request is also the Handover header with the Call id, From-tag and Totag belonging to the ongoing call. This makes it possible for the receiver to identify which ongoing call is about to change access point. Upon receiving the Handover-INVITE, the B2BUA (in the first case) or the CN (in the second case) will start duplicating the media packets to both the old and the new IP address. When the MN starts to receive media packets

in having a defined extension instead of overloading existing extensions with specific parameters. Second, it can be used with or without the use of additional entities such as SBCs or B2BUAs in the network and does not require any additional operations from intermediate proxies. Third, it provides the possibility to monitor the quality of a new network link before switching an ongoing session to it.

III. P ERFORMANCE EVALUATION Fig. 4. SIP handover Scenario B. CN supports the Handover Extension. All signalling via B2BUA. (1) and (2) depict signalling at session setup. (3) is media transferred directly between MN and CN after session setup. (4) and (5) are signalling paths during and after handover, while (6) is media path after handover.

Fig. 5. SIP handover Scenario C. CN supports the Handover Extension. Only initial signalling goes via B2BUA. (1), (2) and (3) depict signalling at session setup. (4) is media transferred directly between MN and CN after session setup. (5) is signalling during and after handover, and (6) is media after handover.

over both network interfaces, it will send a BYE message with the original dialog’s session parameters, and the media transfer over the old interface will stop. Thus, the new dialog has taken over the session using the new network interface. If needed, it is possible to let the old dialog still be active. In this case the media would still be sent over the old network interface, and the new dialog will be a backup dialog ready to be switched to whenever needed. By keeping the old link alive as primary link, the MN can monitor the quality of the new link before it decides to switch to it. This is useful for instance when the MN is already on a well-functioning, but expensive link and enters the coverage of a cheaper network. Assessing the quality of the new link can be done in different ways, depending on the software implementation of the SIP user agent and the possibility accessing lower-level information. However, the two easiest ways would be either measuring the SNR or measuring RTP packet loss and jitter over a certain time period. It is important to notice that in the case where a handover is initiated due to a degrading primary link, the handover is unavoidable and an available new link will be used as soon as it’s quality exceeds the primary link’s quality. Thus, the main contributions of the Handover Extension can be summarized in three main points: First, it provides clarity

Handover delay as presented in section I consists of three stages: link loss discovery, establishing new link, and address update towards the CN. When using a terminal with multiple network interfaces, the time consumed by the second stage can be reduced by gaining access into a backup network while still communicating over the main interface. This leaves us with handover delay as the time of link loss discovery and address update. However, the time it takes to inform the CN that it needs to switch the session to the address of the backup interface can be very long. This time is dependant on the distance between MN and CN. If the one-way path delay between MN and CN is 100ms, it will take 200 ms from MN sends an address-change notice (in the form of an INVITE message) to CN until MN receives the 200 OK reply from CN. In the case where handover is initiated due to the wish for a cheaper network connection, for instance changing from UMTS to WLAN, we can assume that there is no link loss prior to the handover. In this case, the delay caused by the address update need not imply that the session is discontinued during the roundtrip time between MN and CN, since the primary link is still functioning and is in use while the address update is en route. However, in this case we have no guarantee that the new network connection has the quality required to sustain the desired session quality. When using the Handover Extension for handover in a heterogeneous network, we assume that the terminal can gain access into a backup network while still communicating over the main interface. Since the Handover Extension makes it possible to receive media over the new interface while keeping the old, it is possible to assess the quality of the new link before the old session is terminated. This way, all handover signalling will take place while the session is still active over the old interface, eliminating the handover delay imposed by address updating, while maintaining the required quality of service. We have chosen two typical scenarios where the Handover Extension will be used. These will be described in section III-B. In order to evaluate the Handover Extension scheme we measure setup time of the new session, packet delay variance (jitter), and the difference between these delays when packets are received on two interfaces simultaneously. We also investigate what happens when a user communicating over UMTS enters a WLAN.

TABLE II S YSTEM PARAMETER SETTINGS

Fig. 6. Network topology for the simulation setup. An MN has three available interfaces

UMTS-Parameters UMTS-module Distance MN to UMTS-NodeB HARQ cycle period Channel WLAN-Parameters MAC RadioPropagation Bitrate Range MN speed (Scen A) MN speed (Scen B) Voice-Parameters Packet size Interval

EURANE 1.12 500m 3 HS-DSCH 802.11b DCF Shadowing 11Mbit 100m 1m/s 0m/s 200 bytes 16ms

A. Simulation setup To evaluate the proposed Handover Extension scheme, we have implemented a SIP module including our extension in ns2 [10]. The module supports standard SIP-signalling (INVITE, Trying, 200OK etc), handover (INVITE-handover), and the ability to set up and tear down RTP/UDP streams between SIP-nodes. A typical setup for a SIP terminal can include a fixed default connection through Ethernet as well as optional interfaces for mobile usage. To support this, we created a scenario consisting of a mobile node (MN) with three available interfaces: Wired Ethernet, WLAN and UMTS. The MN can use each of these interfaces to communicate with a correspondent node (CN) through the Internet, as depicted by Fig. 6. Packets traversing from CN to MN through the UMTS domain will go through the UMTS edge router, the Gateway GPRS Support Node (GGSN) and the Serving GPRS Support Node (SGSN), and finally forwarded by NodeB (the base station in the UMTS system) before it is transmitted using the HS-DSCH channel. The UMTS model is EURANE (Enhanced UMTS Radio Access Networks Extension) [11]. The second domain, the WLAN domain, consists of a simple edge router and a 802.11b access point, communicating to the MN using 802.11b Distributed Coordination Function (DCF). The third domain is constructed by a simple edge router connecting the MN using a 5Mbit Ethernet line. Finally, a 100ms delay-box represents an abstraction of the Internet. Further system parameters are outlined in Table II. For simplicity, we have only considered the case where both MN and CN supports the Handover Extension, and thus the CN can function as an anchor point for MN during a handover. B. Simulation scenarios and results As mentioned earlier we have focused on two typical usage scenarios. In the first scenario, from here on called Scenario 1, a user wishes to use the cheapest network that he has access to. When he is moving around, he has an ongoing conversation over UMTS, but as he enters his office or home he wants the phone to automatically use the WLAN access. The scenario is depicted in Fig. 7. At the beginning of the simulation, the MN is within reach of NodeB but outside reach of any WLAN.

Fig. 7. Simulation scenario 1: MN moving into WLAN coverage during a sesssion

Hence, a SIP session is initiated between MN and CN using UMTS. As the MN is moving towards a WLAN it has access to, and is within the coverage over the WLAN AP, it can set up a backup session over its WLAN interface. If necessary, it can switch the session entirely to WLAN and close the UMTS stream. In this simulation, we measure the average packet loss per second of the RTP stream as we move closer to the WLAN access point. Results from simulation using Scenario 1, where the MN moves at 1 m/s and performs a handover from UMTS to WLAN are presented in Fig. 8. In the figure we can see, as expected, that the packet loss over the WLAN link decreases as the MN moves closer to the WLAN access point. At 60 s, the MN enters into the WLAN coverage, obtains an IP address and sets up a backup session with the CN using the Handover Extension. 85 seconds into the simulation, the packet loss over WLAN is less than 5%, and the session is moved completely over to WLAN by terminating the UMTS path. The result clearly shows the need for having a scheme like the Handover Extension, where the MN can monitor the quality of the new connection before switching the entire session over to it. In this example, the MN was able to establish a new session using Handover INVITE long before the link quality was stable enough to give good-quality VoIP. Tests show that the voice codecs G.728 and µ-Law, when exposed to packet loss exceeding approximately 5% will result

Fig. 8. RTP packetloss over UMTS and WLAN. After 60s the backup channel is initiated to probe the RTP traffic over WLAN. When the packet loss is down to 5%, the MN leaves the UMTS channel and uses solely the WLAN channel.

Fig. 9. session

Simulation scenario 2: MN changing to WLAN network during a

in audio rated as poor [12]. Thus, in these cases, a premature switch will lead to degraded user experience. In the second scenario, Scenario 2, a user has an office phone connected through Ethernet. Here, MN uses the Ethernet link as its primary link to the Internet as the quality is assumed to be better regarding both delay and packet delay variance than WLAN. However, when the user is on the move, he communicates through the office WLAN network. This is depicted in Fig. 9. When the session is set up, a handover to the wireless network is initiated using the SIP Handover Extension. This way the conversation can immediately be switched to WLAN if the user disconnects from the Ethernet and starts to walk around. In this simulation, we measure the setup time of the WLAN channel with different traffic patterns in the WLAN network, from no traffic to 95% saturation. We also measure the RTP packet delay variance, and the difference in RTP packet delay between the two different paths (WLAN and Ethernet). Fig. 10 shows the session setup time for the backup session. We define the setup time as the time it takes from the MN sends a Handover-INVITE until it receives the 200OK from the CN. This graph clearly shows the need to initiate the handover before the primary connection is lost. A loss of

Fig. 10. WLAN

Setup time for the new link changing with increasing traffic in the

primary link with the following address update will take at least 208 ms due to the round trip time in our scenario (2x(2ms + 2ms + 100ms)). The setup time increases with the additional traffic load in the WLAN. If the setup of the WLAN link can be done while the MN is still connected to the primary network, the setup time has no practical significance as the media packets can continue using the old interface during this period. This can be obtained by having a backup link connected while working on the primary link or by making the user actively choose to stay connected and announce the need for a handover before abruptly disconnecting from the primary link. After the WLAN link has been set up, the MN receives two concurrent RTP streams and can choose to discard the last arriving packet from the two streams . The only delay that can influence the session now will be due to the difference in arrival time between the packets belonging to the two streams. The difference in arrival time for an RTP packet that is sent via both the WLAN and the Ethernet is shown in Fig. 11. The figure indicates that at low traffic load in the WLAN, the difference in arrival time is close to zero or low enough to be within acceptable jitter levels. The maximum acceptable jitter for the G.729 codec is in the range of 10-35 ms when operating with a round trip time of 200-300 ms [13]. At medium to high traffic load in the WLAN, packets arrive so much later than the packets received on the Ethernet interface that it will affect the quality of the session during the switch. 95% traffic load of a 11 Mbit/s WLAN leaves a bandwidth of 550 kbit/s which should be enough for VoIP codecs G.711 and G.728. However, simulations show that increasing traffic load in the WLAN AP also increases the packet delay variance (jitter) in the RTP traffic sent between MN and CN as shown in Fig. 12. Although some packet delay variance can be sorted out through a playout buffer on the receiver side, this can cause problems in the codecs as described earlier. Again we see that that low to medium load result in acceptable jitter levels.

handover was done manually by the user. Future work include testing a SIP user agent supporting the Handover Extension between other network types such as UMTS. Different trigger mechanisms will also be examined. IV. C ONCLUSION

Fig. 11. RTP packets take two different paths during handover. The graph shows the difference in arrival time with increasing traffic in the WLAN

Fig. 12.

Jitter with increasing traffic in the WLAN

C. Implementation To evaluate the functionality of SIP with the Handover Extension, it has been implemented and tested in a real setup. Our implementation is based on Peers [14], an open-source Java-based SIP soft phone. It has been modified to support all the features of the scheme described in section II-B. The most important changes required to provide handover include (i) adding support for multiple network interfaces, (ii) differentiate between primary and backup interface, (iii) duplication of RTP packets, and (iv) keeping track of which ongoing sessions have a corresponding backup session. Our experience indicates that these changes, although vital for the functionality of the handover, are quite feasible to implement in an existing SIP user agent. In our experiments we used two laptops. The modified Peers user agent was installed on each of the two laptops, and was able to support the SIP Handover Extension both as a client (on the MN) and as server (on the CN). Tests were performed according the setup described in Fig. 9. The handover were performed successfully both from the Ethernet domain to the WLAN and vice versa. For these test purposes, triggering the

In this paper we have presented the problems of long delays when performing handovers in heterogeneous networks. These delays can be perceived as poor communications quality by the end users, or even lead to collapse in voice or video codecs. We suggest the SIP Handover Extension that can be used either directly between two end points supporting the extension, or with an intermediate SBC or B2BUA acting as an anchor point during the handover. The extension provides the possibility to perform a make-before-break handover, by setting up a backup session before terminating the primary session. Through two user scenarios we evaluate the Handover Extension using ns2. We have shown that an MN is able to set up a new link in a WLAN long before the link quality is acceptable for a media stream. By using the Handover Extension’s capability of delivering two media streams at the same time, the MN can monitor the new link and wait until the quality is good enough before switching to the new network. Further, we have illustrated the need to initiate a handover before the primary link is lost. Informing the CN about the new address takes at least one roundtrip time. If this is to be done after the primary link is lost, it can lead to poor communication quality. By using the Handover Extension, this can be done before the primary link is lost. Lastly, we have discussed the effect of traffic load in WLAN during handover when using well-known audio codecs. We have demonstrated that the Handover Extension is feasible to implement by making small modifications to an existing SIP user agent. Implementation and testing has revealed that an important challenge lies in defining the trigger which initiate the handover. This trigger can be based on metrics such as relative signal strength, link quality, user preference, network conditions, application types and cost. These metrics will be specific to the platform on which the user agent is implemented. R EFERENCES [1] E. Wedlund and H. Schulzrinne, “Mobility Support using SIP,” in WOWMOM ’99: Proceedings of the 2nd ACM international workshop on Wireless mobile multimedia. New York, NY, USA: ACM Press, 1999, pp. 76–82. [2] N. Banerjee, S. K. Das, and A. Acharya, “SIP-based Mobility Architecture for Next Generation Wireless Networks,” in Pervasive Computing and Communications, 2005. PerCom 2005. Third IEEE International Conference on. IEEE Computer Society, March 2005, pp. 181–190. [3] P. Bellavista, A. Corradi, and L. Foschini, “SIP-Based Proactive Handoff Management for Session Continuity in the Wireless Internet,” in 26th IEEE International Conference on Distributed Computing Systems Workshops 2006, (ICDCSW06). IEEE Computer Society, July 2006, pp. 69–69. [4] S. Tsiakkouris and I. Wassell, “PROFITIS: Architecture for Locationbased Vertical Handovers Supporting Real-Time Applications,” in 25th IEEE International Performance, Computing, and Communications Conference, 2006 (IPCCC 2006). IEEE, April 2006, pp. 629–634.

[5] S. Salsano, L. Veltri, A. Polidoro, and A. Ordine, “Architecture and testbed implementation of vertical handovers based on SIP session border controllers,” Wireless Personal Communications, vol. 43, no. 3, pp. 1019–1034, November 2007. [6] E. S. Boysen and T. Maseng, “Seamless handover in heterogeneous networks using SIP: A proactive handover scheme with the Handover Extension,” International Journal on Advances in Internet Technology, vol. 2, no. 1, pp. 184 –193, 2009. [Online]. Available: http://www.iariajournals.org/internet\ technology/ [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261 (Proposed Standard), Jun. 2002, updated by RFCs 3265, 3853, 4320, 4916. [Online]. Available: http: //www.ietf.org/rfc/rfc3261.txt [8] M. Handley, V. Jacobson, and C. Perkins, “SDP: Session Description Protocol,” RFC 4566 (Proposed Standard), Jul. 2006. [Online]. Available: http://www.ietf.org/rfc/rfc4566.txt

[9] E. S. Boysen, H. E. Kjuus, and T. Maseng, “Proactive handover in heterogeneous networks using SIP,” in Proceedings of the Seventh International Conference on Networking 2008 (ICN 2008). IEEE, April 2008, pp. 719–724. [10] “Ns2 Network Simulator,” Visited March 2010. [Online]. Available: \url{http://www.isi.edu.nsnam/ns/} [11] “EURANE (Enhanced UMTS Radio Access Networks Extensions for ns-2),” Visited March 2010. [Online]. Available: \url{http: //eurane.ti-wmc.nl/eurane/} [12] L. Roychoudhuri, E. Al-Shaera, and G. B. Brewstera, “On the impact of loss and delay variation on internet packet audio transmission,” Computer Communications, vol. 29, no. 10, pp. 1578–1589, June 2006. [13] M. J. Karam and F. A. Tobagi, “Analysis of delay and delay jitter of voice traffic in the internet,” Computer Networks, vol. 40, no. 6, pp. 711–726, december 2002. [14] Y. Martineau, “Peers SIP soft phone,” open-source java-based SIP soft phone. [Online]. Available: http://peers.sourceforge.net/