2G1325_VoIP-Paper
-
Upload
hamid-shahzad -
Category
Documents
-
view
17 -
download
0
Transcript of 2G1325_VoIP-Paper
N. Jain & H. Shahzad 1 May 2006
Abstract Future generation wireless networks have been envisioned as the integration of various wireless access networks, including both wireless wide area networks and wireless local area networks. In such a heterogeneous network environment, seamless mobility is the basis of providing uninterrupted wireless service to mobile users roaming between wireless access networks. Because of transparency to lower layer characteristics, ease of deployment, and greater scalability, the applicationlayer based Session Initiation Protocol (SIP) has been considered the right candidate for handling mobility in heterogeneous wireless networks. However, SIP entails applicationlayer transport and processing of messages, which may introduce considerable delay. In this review paper, we brief the current technology status of the performance of mobility management protocols in the heterogeneous wireless networks and summarize research challenges of VoIP over wireless networks. 1. Introduction Wireless networks beyond 2G aim at supporting real‐time applications such as VoIP. Signaling protocols such as session initiation protocol (SIP) are used to set up VoIP calls. SIP is evolving as the dominant protocol for voice call control in IP networks and is expected to be widely deployed in the near future. Using SIP for supporting mobility in SIP based networks appears as a very attractive option, taking advantage of existing SIP infrastructure and signaling. The integration of cellular and voice over WLAN (VoWLAN) systems recently has attracted considerable interest from both academia and industry. A cellular/VoWLAN dual mode system helps mobile users to access a low cost voice over IP (VoIP) service in a WLAN area and switch to a wide‐coverage cellular system without WLANs. Figure X
VoWLAN is a new communication technology by combining two popular technologies ‐ VoIP and WiFi. In other words, it is to achieving VoIP communication in the WiFi network environment. The VoWLAN will enable enterprise to facilitate the use of existing WiFi infrastructure to provide voice
service to increases productivity and save costs. Due to the low coverage of WiFi, it is then necessarily to design a handoff between VoWLAN and cellular in order to take advantages of wide coverage of the cellular network. This paper demonstrates the handoff mechanism specifically designed for roaming between VoWLAN and cellular networks. It includes a comprehensive technical review of the current handoff technologies used in VoWLAN and cellular network.
The explosive growth of mobile phone users worldwide, along with the increasing Internet penetration in human populations, has led to the users’ need for accessing high speed Internet data applications via their mobile terminal, while still being able to make high quality voice calls. There have also been efforts [12, 14] for supporting IP mobility at the application layer using the Session Initiation Protocol (SIP), as an alternative to network‐layer mobility.
This poses an opportunity as well as a challenge for the wireless operators. With 3G networks on the one hand and WLAN technologies on the other, wireless operators can integrate these complementary technologies to their advantage [10, 19] while providing the end user with a seamless experience. Users can connect through a WLAN when they are in a hotspot, like their workplace or their home, but their calls can be handed over to cellular networks as they roam out of the hotspot. This is valuable to users because it combines the freedom of mobility with the low‐cost access of WLAN while using a single end‐user mobile station. It is also attractive to 3G service providers because it extends the reach of their networks.
However, the challenge here is the problem of seamlessly handing over a call from one air interface to another. Real‐time applications, such as conversational voice or multimedia over IP, are especially intolerant of service interruption during handover. Mobile IP, a layer 3 protocol,
SIP Based VoIP over Converged Wireless Access Networks Jain, Nishant & Shahzad, Hamid
School of Information & Communication Technology Royal Institute of Technology
Stockholm, Sweden
N. Jain & H. Shahzad 2 May 2006
maintains a data session across heterogeneous air interfaces. Maintaining the same IP address enables applications to be ignorant to changes in the physical layer. Although mobile IP maintains seamless session management across distinct networks, it does not ensure that the switchover from one physical interface to another is performed in a “make‐before‐break” fashion to prevent packet loss during the transition.
Session initiation protocol (SIP) has been proposed as a layer 5 alternative for mobile IP [14], but SIP cannot support persistent transmission control protocol (TCP) connections, and it is suitable neither for micro‐mobility (mobility within a domain) nor for macro‐mobility (mobility across domains). Furthermore, the delay in obtaining a new IP address and performing the authentication process is excessive. For long‐lived TCP connections, [12] suggests using mobile IP as a more desirable protocol.
We begin the paper by providing an overview of the SIP protocol and the various types of mobility that have been defined in this context in the literature. We follow it by briefly describing the mobile IP architecture and its components. We then describe the central idea of the paper by addressing the issue of seamless data session handover between 3G and WLAN technologies. The paper also discusses about the cellular/VoWLAN service scenario which involves a user with a dual mode mobile being able to access VoWLAN in enterprise or hot spot WLANs, and switch to a cellular system without WLAN coverage; thus reducing the cost of mobile telecommunication services, while also achieving high mobility and wide coverage [16]. 2. SIPBased VoIP Mobility management protocols are in general responsible for supporting services seamlessly across heterogeneous access networks that require connection migration from one network to another. This is known
as the vertical handoff. Thus, in addition to providing location transparency, the mobility management protocols in this case also need to provide network transparency. A number of research works has been directed towards solving the vertical handoff problem for IP based networks [19, 20, 24]. Most of these works are based on Mobile IP [7]. However, Mobile IP suffers from the problem of triangular routing which is detrimental to real‐time traffic like streaming multimedia, where the important issues are fast handoff, low latency and minimal packet loss. Mobile IP route optimization [6] has been proposed to solve the problem particularly, but route optimization again suffers from the following drawbacks: the IP stack needs change to implement route optimization and the home agent can only initiate the route optimization which introduces additional delay. Several mobility protocols have been proposed as a remedy to these problems [2, 4, 6, 9, 17, 27, 28]. Based on the layer of their operation, these protocols can be broadly classified as those operating in the network layer [6], transport layer [2] and application layer [17]. The dependency of these mobility protocols on the access networks reduces progressively as we move up on the protocol stack [22]. Among them, Session Initiation Protocol (SIP) [17] has been standardized by the Internet Engineering Task Force (IETF) [29] as a signaling protocol for multimedia session setup in IP based networks. In addition, SIP is capable of supporting not only personal mobility but also terminal, session and service mobility at the application layer. Application layer protocols, however, are transparent to the network (or lower layer) characteristics.
SIP has been accepted by the third Generation Partnership Project (3GPP) as an application layer signaling protocol for setting up real‐time multimedia sessions. Thus, SIP based mobility management could potentially use a readily available operational infrastructure, which would facilitate its fast deployment. Therefore, SIP seems to be an attractive candidate as an application layer
N. Jain & H. Shahzad 3 May 2006
mobility management protocol for vertical handoff [22]. Although SIP based mobility management solves the problem posed by Mobile IP route optimization, for some cases it introduces unacceptable handoff delays [21] for multimedia applications with stringent QoS requirements. Moreover, SIP entails application layer processing of the messages which may introduce additional delay.
Industry‐wide, SIP is being accepted as the framework of choice for VoIP. In the next few sections, we describe SIP protocol along with the basic call flow that is used to establish an end‐to‐end VoIP call. We also describe the concept of mobility as used in SIP. 2.1 SIP Overview SIP [19] creates a flexible framework for enabling IP endpoints, or user agents (UAs), to create, modify, and terminate multimedia sessions. It can be used for point‐to‐point calls or multicast calls. It enables the creation of proxy servers and SIP registrars to allow endpoints to find each other and provides other services as well. It may be used over reliable networks (e.g., TCP) or unreliable networks (e.g., user datagram protocol [UDP]). SIP supports multiple IP media streams that can include VoIP and other UDP or TCP streaming applications.
SIP is access independent, so it is equally applicable to wireless and wireline networks. Designed with unreliable networks in mind, it incorporates a scheme of retransmissions to ensure delivery of SIP messages, making it suitable for wireless networks that incur over‐the‐air errors. The SIP suite of protocols has been adopted by 3rd Generation Partnership Project (3GPP) [33, 34, 35] and 3rd Generation Partnership Project 2 (3GPP2) [5] as part of the all‐IP core network architecture and the IP multimedia subsystems. SIP is not a standalone protocol for performing all aspects of call control; rather, it leverages other protocols to provide a complete solution. For example, in a typical VoIP application, session description protocol
(SDP) is embedded in SIP messages for negotiating bearer path attributes, such as the media types that are supported, the IP address and port for each media type, and the protocol for delivering the media. Once the parameters of the session are agreed upon, the endpoints can start exchanging packets over the bearer path. Real‐time protocol (RTP) is typically used for VoIP. Once the parameters of the session are negotiated by the endpoints, the media session is established. SIP does not play a role in the media session itself, but it is used for terminating or changing the parameters of the session. Common telephony services, like call waiting, call forwarding, and call hold, as well as more advanced services, like picture caller ID and multimedia conference calling, can all be accomplished with SIP. SIP is based on a request/response transaction model. The UA that invokes the request is called the UA client (UAC), and the UA that responds to the request is the UA server (UAS). Each request by the UAC invokes a function, or method, in the UAS. SIP supports six basic methods: ⟩ REGISTER, used by endpoints to identify
themselves to SIP registrars; ⟩ INVITE, used for establishing calls or
modifying the parameters of an established call;
⟩ ACK, used to acknowledge final responses to INVITES;
⟩ BYE, used for tearing down established calls;
⟩ CANCEL, used for terminating call setups before they are fully established; and
⟩ OPTIONS, used for querying endpoints or proxy servers as to their capabilities without “ringing” them.
As shown in Figure 1, a SIP infrastructure consists of ⟩ user agents, ⟩ registration servers, ⟩ location servers and ⟩ SIP proxies deployed across a network. A user agent is a SIP endpoint that controls session setup and media transfer. User agents are identified by SIP URIs, which is a unique
N. Jain & H. Shahzad 4 May 2006
HTTP‐like URI of the form sip:user@domain. All user agents REGISTER with a SIP registrar server (which can be co‐located with a SIP proxy) with their IP address (Figure 1). The mapping of a URI to the IP address of a device registered by the user is done using intermediate SIP proxies, location and redirect servers as part of the session setup process. SIP defines a set of messages, such as INVITE, REFER etc., as shown in Figure 2, to setup sessions between user agents. These messages are routed through SIP proxies that are deployed in the network. DNS SRV records help in finding SIP proxies responsible for the destination domain. 2.2 Basic Call Flow Figure 3 illustrates a typical SIP call flow through SIP proxies. It depicts the request and response transactions of SIP for establishing a call. Prior to the call establishment, each user is registered with his/her corresponding SIP registrar. This permits a user to be reached by his/her own unique network access identifier (NAI)—e.g., <[email protected]>—regardless of his/her location and point of attachment.
All requests from an originating user agent such as an INVITE are routed by the proxy to an appropriate destination user agent based on the destination SIP URI included in the INVITE message. The proxy servers respond with a Trying response so that originating user agent knows his/her message was received and that further retransmissions of the INVITE request are unnecessary. Proxies may query location and redirect servers to determine the current bindings of the SIP URI. Signaling messages are exchanged between user agents, proxies and redirect/location servers to locate the appropriate endpoints for media exchange. For reasons of scalability, multiple proxies are used to distribute the signaling load [31]. A session is setup between two user agents through SIP signaling messages comprising of an INVITE, an OK response and an ACK to the response [17]. This is shown in Figure 2 where the call setup is followed by media exchange using RTP. The
session is torn down through an exchange of BYE and OK messages.
SIP distinguishes between the process of session establishment and the actual session. A basic principle of SIP is the separation of signaling (control) from media. Signaling messages are usually routed through the proxies while the media path is end‐to‐end. The session setup messages like INVITE contain user parameters using Session Description Protocol (SDP) [15] in the message body. SDP provides information about the session such as parameters for media type, transport protocol, IP addresses and port numbers of endpoints. The IP address and port numbers exchanged through SDP is used for the actual data transmission (media path) for the session. Any of these parameters can be changed during an ongoing session through a RE‐INVITE message, which is identical to the INVITE message except that it can occur within an existing session. In addition, a user agent can transfer an existing session by using a REFER message. This message instructs the other endpoint of an existing session to initiate an INVITE/OK/ACK exchange with a third user agent and terminate the existing session (with the sender of the REFER message). 2.3 Mobility: The Issue Mobility is the most important feature of wireless networks that makes continuous service possible in pervasive/ubiquitous environments. Seamless service is usually achieved by supporting handoff. Handoff is the process of changing parameters (e.g., endpoint address, channel etc.) associated with the current connection. For UDP based connections the major parameters are the source and destination IP addresses, which can be changed by the movement of a mobile host (MH), either within a network or across different networks. The former scenario initiates horizontal handoff, whereas the latter initiates vertical handoff. Handoff is again divided into two broad categories: hard and soft handoffs. They are also characterized
N. Jain & H. Shahzad 5 May 2006
by “break before make” and “make before break.” In hard handoffs, current resources are released before new resources are used and in soft handoffs, both existing and new resources are used during the handoff process. For soft handoff the MH should be capable of communicating through multiple network interfaces. Usually, a mobility management protocol, operating at the control plane independent of the data plane supports handoff.
As described earlier, SIP provides vertical handoff support in IP centric networks for multimedia applications. Although the data plane protocols provide Quality of Service (QoS) to the applications, it is the responsibility of the mobility management protocol to maintain the QoS during the handoff period. For multimedia streaming applications, the most important QoS parameters are (i) end‐to‐end delay, (ii) delay jitter or variation of end‐to‐end
delay between the packets, and (iii) packet loss. Of these three parameters, the first two depend on the network condition in the path of the data traffic. Generally, the issues related to these parameters can be resolved by providing a playout and jitter buffer. The handoff delay causes only a glitch as far as these two parameters are concerned and has no long‐term effect. However, large handoff delays cause considerable packet loss which seriously affects the quality of the multimedia streaming applications. Despite the advantages of SIP in providing mobility support in IP based heterogeneous networks, there are some issues that need to be resolved for proper QoS provisioning to multimedia applications. The handoff delay in SIP based mobility is essentially the time required by the re‐INVITE message to reach the correspondent host (CH) from the mobile host (MH), but several different operations need to be completed before the INVITE message could be transported. These are:
(i) Detection of the new network by the MH. This depends on the networking technology (e.g., periodic beacons from the access points are used in WLANs to intimate a mobile device about the presence of the network) as well as on the operating system in the MH.
(ii) The MH needs to acquire an IP address by a procedure specific to the access network. This may be DHCP address configuration for WLAN or Attach and PDP Context Activation for 3G networks.
Analytical study [21] reveals that the handoff delay can be more than 1 sec for low bandwidth access network, for which hard handoff has considerable effect on the application quality. So, the mobility management protocol needs to employ some mechanism to counter the harmful effect of the handoff delay. 2.4 Mobility Support Using SIP Mobility is characterized as personal, terminal, session, and service mobility where a persistent IP address is not assumed.[14] ⟩ Personal mobility is described as allowing a
single user located at different terminals and to be addressed at each location by a unique personal identity.
⟩ Terminal mobility is described as allowing a device to move between IP subnets. Terminal mobility could affect SIP at three different stages: at pre-call, at mid-call, and upon recovery from movement across network partitions. Except for mobility before a call is placed, none of the other stages of terminal mobility provide the seamless experience to a user without any packet loss.
⟩ Session mobility is described as allowing a user to maintain a SIP session while changing devices, and
⟩ Service mobility is described as allowing a user to maintain access to his/her personal services while changing devices and networks.
N. Jain & H. Shahzad 6 May 2006
Personal mobility is embedded in SIP by having a UA regularly update its registration information to reflect the user’s current location. The updates may occur prior to or during a call on any IP network, independent of the device being used to access the network. The elements included in the SIP architecture that support mobility are UAs, redirect servers, proxy servers, location servers, and registrar servers. The SIP servers facilitate user mobility, as they track the user movement through new registrations. The UA resides in the mobile node (MN), also referred to as mobile host (MH), and in the corresponding remote node, sometimes referred to as a corresponding host (CH).
When a proxy server or redirect server receives an INVITE message, it may consult the location server for a route through which to redirect the INVITE message (Figure 4). A redirect server provides the calling party with an alternate address for the callee, whereas a proxy server will forward the call to the alternate address on behalf of the caller. A user al-ways belongs to a home network that maintains its home SIP servers. The user re-registers with his/her home network when changing his/her point of attachment. A permanent or persistent IP address is not assumed when the user relocates to a new network. When the MN is moving between locations, it is expected that long delays will be introduced while the UA is obtaining a new IP address and authenticating with the local authentication, authorization, and accounting (AAA) servers.
Session mobility enables the user to maintain a session while changing terminals located on the same or a different subnet. This mobility can be achieved by involving a third-party call control [8] where the third party is the original participant that redirects the call to the new device and stays engaged in the call until its termination. Another approach for terminal mobility without the involvement of a third party can be achieved with the use of the SIP REFER message [25]. The REFER message simply directs the session to the new terminal location
where a new INVITE message will be forwarded. To minimize delay, the device needs to be authenticated prior to receipt of the INVITE message.
Service mobility is described in [14] as one of SIP’s attributes. It provides user with access to his/her unique services even while he/she is changing locations or devices. These user services include speed dial lists, address books, preference lists, and incoming call instructions, to name a few.
Maintaining a unique IP address throughout the session is facilitated through inclusion of the mobile IP transport elements. The section below introduces the mobile IP protocols and the shortcomings of these existing protocols for make-before-break handover.
This is followed by a discussion for intelligent mobile IP to provide seamless handover and an uninterrupted VoIP session across disparate wireless networks.
3. Mobile IP Architecture Mobile IP defines three network entities: ⟩ the foreign agent (FA), ⟩ the home agent (HA), and ⟩ the mobile node (MN), which contains the mobile IP client software.
The FA is a router supporting the mobile IP protocol located in the foreign (visited) network. The FA function is located in the packet data service node (PDSN) for code division multiple access (CDMA), in the gateway GPRS support node (GGSN) for the Universal Mobile Telecommunications System (UMTS) [11], and in an edge router or WLAN gateway for WLAN. The FA provides a care‐of address (CoA) for the MN.
The HA is a router supporting mobile IP located in the user’s “home” network. Similarly, if the wireless service provider (WSP) is the home network, the HA function may be co‐located in the PDSN or adjacent to it for CDMA or co‐located with the GGSN or adjacent to it for UMTS. If the home network is a third‐party data center, the HA may be located behind the firewall and next to an
N. Jain & H. Shahzad 7 May 2006
edge router. The HA maintains the MN’s current CoA location information and tunnels data‐grams to the MN’s CoA (i.e., the FA) when the MN is away from home, as illustrated in Figure 5. [5]
For mobility support between incongruent networks, mobile IP client software resides in the user’s end terminal, typically a laptop or PDA. The client is a key element of the layer 3 integration. For terminals that support a single air interface, where a mobile IP client may not be present, mobile IP‐based architecture may be achieved with proxy mobile IP functionality embedded within the network elements.
An MN can be in one of three possible operating environments: its home network, a foreign network that supports mobile IP, or a foreign network that does not support mobile IP. In all three of these scenarios, the MN uses a previously assigned identification, either its own static home IP address or its own network access identifier (NAI), such as <[email protected]>.
In the first operating environment, the MN is in its home network. The MN determines it is in its home network by monitoring the mobility router advertisements, also known as agent advertisements. While at home, network operation is the same as if mobile IP were not running—i.e., packets are routed in a normal fashion.
In the second operating environment, the MN attaches to a foreign network that contains an FA supporting mobile IP. The MN first connects to the available access technology. It determines that there is an FA when it receives a mobile IP mobility advertisement from it. The MN sends a Registration Request message to the FA, which forwards it onto the AAA infrastructure and HA, where it is authenticated and authorized.
In the third operating environment, the MN attaches to a foreign network that does not have an FA and does not support mobile IP. The MN will nevertheless be able to
use mobile IP as long as it can acquire an IP address (via domain host control protocol [DHCP] or point‐to‐point protocol [PPP]) from the foreign network. The MN will use the assigned IP address as its “mobile IP co‐located CoA” and act as its own tunnel endpoint. It will register directly with its HA using the co‐located CoA and the registration procedure previously described. The MN sends packets out directly to their destination (with the MN home ad‐dress as the source address). All returning packets go to the MN’s home address and are intercepted by the HA, which tunnels the packets to the MN. When reverse tunneling is established, all packets destined to the CH are directed via the HA, as illustrated in Figure 5. [5] 3.1 Schemes for Handover Current mobile IP mechanisms, which detect mobile movement from one network to the other, are based on agent advertisement lifetime and network prefixes [8]. Other proposed mechanisms are based on end‐user client criteria, such as signal presence/strength of the available radio interfaces. 3.1.1 Agent advertisement lifetime in mobile IP An inter‐net control message protocol (ICMP) router advertisement in mobile IP contains mobile IP agent advertisement that specifies a lifetime for which the advertisement is valid. If for some reason a mobile does not receive another agent advertisement within this time frame, it is assumed that the mobile has moved out of the range of the current agent and hence is a candidate for handover to another agent from which it may have already received an advertisement. This implies that a mobile would not activate a handover procedure to the new agent from which it had received an advertisement earlier until the advertisement lifetime of its current agent expires. Typically, the advertisement life‐time is on the order of tens of seconds. For any VoIP application, such a long delay for
N. Jain & H. Shahzad 8 May 2006
handing over to another agent, being over two orders of magnitude more than the desired delay bounds, is unacceptable.
In CDMA2000, the delay in handover could be even longer. As an implementation‐dependent optimization in CDMA2000, the number of advertisements transmitted over the air interface is restricted—i.e., the agents only respond to solicitations from the mobile. The consequence is that the MN does not have advertisements from new FAs prior to the expiration of the old advertisement. This creates additional delay in initiating a handover to CDMA2000 networks, as a mobile node must first wait until the advertisement lifetime of the current agent expires before it will solicit new advertisements so that it can proceed with the mobile IP registration through the new agent. . [5] 3.1.2 Network prefixes in mobile IP There is an extension to mobile IP that provides a mechanism for detecting handovers to a new FA. The mechanism, based on network prefixes, assumes that an agent uses an extension called network prefix extension within the agent advertisement. This extension specifies the subnet prefix for the network where the agent is located. Any difference in the network prefix between the currently stored value and the one received in a new agent advertisement would indicate a handover condition. Since network prefixes, which are more frequent than the advertisement lifetime, are specified in the agent advertisement, this mechanism would be better suited as a handover trigger. However, this extension is not mandatory and therefore cannot be relied upon unless both the current agent and the new agent are using it.
The above discussion makes it clear that the current schemes for fast handover at best leave a lot to be desired and at worst are completely inadequate. . [5]
3.1.3 Signal strength.
Mobility management and movement detection are inherent to the CDMA cellular network. The proximity to a CDMA base station can be characterized by the radio link conditions and received signal strength indication (RSSI) readings. Similarly, movement detection from an associated WLAN access point (AP) can be characterized by signal strength readings indicated through the WLAN card interface. Fast movement detection across these disparate RF technologies can be achieved by monitoring these radio signal conditions on a regular interval. When accessing a WLAN network, priority is given to the WLAN signal reading, and its diminishing value can be used as a movement indication. Similarly, when accessing a CDMA net‐work, priority is given to the RSSI information. . [5] 3.1.4 Layer 3 Handover Between Homogeneous vs. Heterogeneous Interfaces When a mobile IP client attempts a handover between homogeneous air interfaces (such as a handover from one WLAN AP to another), it may need to tune to another radio frequency. This may force the client to hold off communication with its current point of attachment or AP until it has been authenticated using the new point of attachment. On the other hand, in the case of a handover between heterogeneous air interfaces, the assumption is that MNs (such as laptops and PDAs) are multimode—i.e., the end‐points are capable of transmitting and receiving net‐work and data link messages simultaneously through the multiple air interfaces. [5]
4. Intelligent “MakeBeforeBreak” Handover Real‐time applications have very stringent delay constraints on the delivery of packets to the remote end. A seamless mobility protocol such as mobile IP ensures that there is
N. Jain & H. Shahzad 9 May 2006
continuity of the session management in terms of both layer 3 (IP layer) and layer 4 (transport layer) between end points. It does not, however, ensure that packets will not be dropped as the mo‐bile performs a handover from one network to another.
There exists a proposal for an intelligent agent along with an MN client that can simultaneously monitor wireless signal strengths of multiple access technologies and automatically perform access technology handovers [5]. Assuming that the coverage of the two disparate networks overlaps, service disruption and packet loss are minimized as the MN client either has both network interfaces active or, based on the algorithm described in the following sections, would activate another interface so that it can use that link in the background to set up the call prior to handover.
The industry at large has also recognized the importance of seamless handover for real‐time applications between heterogeneous networks. Toward this goal, the IEEE standards body completed a task within a study group—the P802 Handoff Executive Committee Study Group (ECSG)—to understand and define the problem of handover between both wireless and wireline heterogeneous networks. A new group is currently being formed to address this problem and facilitate appropriate information flow in a timely manner for individual interfaces between layer 1 and layer 2 (PHY and MAC, respectively) and higher layers (IP layer and beyond). This would in effect help an entity such as an intelligent agent to make fast handover decisions.
Figure 6 depicts switching scenarios for overlapped and non‐overlapped coverage. Figure 6 (a) depicts a make‐before‐break scenario where the client observes the WLAN signal overtime. At time t1, when the signal strength exceeds the threshold H, the client attempts to use the WLAN interface. Similarly, at time t2, when the signal strength drops below the threshold L, the client reverts to the
3Gairlink. If the client sets up the call and creates short‐lived simultaneous bindings (dual mobile IP tunnels with both FAs) at the HA [8] before losing the signal on the current interface, the delays Δ1 and Δ2 are masked off and handover appears instantaneous to the client application. While the simultaneous bindings are maintained, packets in transit arrive at both the old and new interfaces and are not lost. Outgoing packets are routed to the new airlink immediately after switching, minimizing packet loss.
In the absence of overlapped coverage, service interruption is unavoidable because one link is lost before the new link is available. However, even in situations where coverage is overlapped, a “break‐before‐make” handover scenario may still occur due to a sudden drop in signal strength, as illustrated in Figure 6 (b). Here, WLAN is the preferred interface; however, because its signal drops so abruptly, there is no time to connect the 3G call before the WLAN connection is lost. Consequently, coverage disruption occurs between t2 and t3 due to the typical long 3G call set‐up processes (a few seconds) followed by the t3 to t4 mobile IP authentication delay.
If, on the other hand, the 3G call were kept up continuously while connected to the WLAN, then the switching time would be determined by the performance of only the network latency (t3 to t4) between the FA, HA, and AAA network elements. Maintaining dual connection is feasible only when volume‐based charging is applied to the 3G connections. In such cases (e.g., GPRS), switching time is reduced and extra charges are not incurred as a result of the prolonged 3G connectivity.
However, in a general case, keeping two or more interfaces up simultaneously may not be a practical approach from a user cost or network utilization point of view. Moreover, such an approach imposes a drain on the battery life of a mobile terminal. All of this again underscores the need for an intelligent
N. Jain & H. Shahzad 10 May 2006
agent, which can bring up a suitable interface at an appropriate time. When make‐before‐break handover is possible, the decision to hand over the session is based on a pre‐defined criteria matrix that weighs conditions, such as available bandwidth, signal quality, access cost, and service‐level agreements (SLAs) between its mobile operator and the visited network. The subsection below describes this aspect of our handover proposal in more detail.
4.1 Handover Decision Criteria A scheme is discussed that would ensure a smooth handover between heterogeneous networks where an overlap in radio coverage is available for the systems that are participating in the handover. The following are the main components of the System Selection algorithm (SSA) for deciding when the MN should hand over a call. 4.1.1 Continuous or periodic monitoring of all the individual wireless interfaces The intelligent MN monitors each wireless interface in order to proactively maintain its handover options. The following is a list of conditions that may be monitored in order to determine if handover is appropriate. ⟩ Activity status of an interface. Although
the monitoring of an activity status (active or inactive) may be applied to wireless interfaces, it is more relevant to handover possibility between a wireless interface and a wireline interface such as digital subscriber line, or Ethernet‐based LAN. Specifically, a possible scenario is a laptop or a PDA equipped with both wireless and wireline interfaces and being carried from a wireless environment to a home or office environment (or vice versa) such that a wireline interface is activated.
⟩ Viability of an interface in terms of radio link conditions and RSSI. Note that to obtain such information from the PHY and MAC layers requires that there be some fast coordination between these
layers and the client for exchange of this information in a timely fashion.
⟩ Network loading conditions. This particular criterion is important from a service provider point of view. A service provider may determine that, under certain circumstances (such as the number of voice users vs. data users), more voice users need to be on the cellular network as compared to data users when overlapping heterogeneous networks are available. Under these conditions, the operator could broadcast information to all mobiles registered through a particular cell such that mobiles could take an intelligent decision on handover to an alternate network. Such network loading conditions could be a function of the time of the day or the day of the week.
⟩ Cost of an interface. This could be set statically at the time of an interface becoming active, or, alternatively, it could be broadcast dynamically to the mobiles.
⟩ Service quality. Data bit rates available at any given point in time determine the type of service that can be sustained by a particular air interface.
4.1.2 Threshold management for each interface Each interface maintains low watermark and high watermark values. A handover is initiated using an interface only if system conditions satisfy a value above the high watermark for that interface and precedence rules allow handover (Tables I and II). Similarly, the current interface is terminated and handed off to another available interface if the current system is below a low watermark and precedence rules allow a handover to another interface. 4.1.3 SLAs between different service providers An SLA can be a very important part of the seamless interoperability between heterogeneous networks, especially if there is
N. Jain & H. Shahzad 11 May 2006
a 3G service provider requirement to authenticate their subscribers in a foreign network only through its back office AAA infrastructure. The intelligent client may require to periodically download an up‐to‐date SLA list. 4.1.4 Preference management of user and service provider priorities The service providers would typically want to set certain preferences that determine which interface a user should use to transmit packets for a given set of circumstances. The circumstances may include whether the service provider has SLAs with other service providers to satisfy some basic AAA requirements or other considerations such as cost of an interface and network loading. At the same time, under certain circumstances, where a user may have access to the Internet independent of the current 3G service provider, he/she may have preferences of how the packets should flow to its correspondent node if seamless mobility is provided. A service provider can communicate these preferences as a set of rules whereas a user could indicate or add additional preferences through a graphical user interface (GUI) that is part of the MN client.
Two examples (Table I & II) are given herewith to illustrate, how a set of such rules along with preferences entered through a GUI could be converted into a decision matrix used by the client software during handover. The intelligent handover algorithm relies on the decision matrix that is constructed by a set of rules that are related to normalized thresholds. Such thresholds can be derived from such indices as signal strength reading, loading conditions, available bit rate, and cost of link.
Note that each of the examples in (Table I & II) is shown with a two‐dimensional decision matrix. Similarly, a multi‐dimensional decision matrix would have to be constructed if there were more than two
disparate interfaces simultaneously available at the MN.
5. Cellular/VoWLAN DualMode System Architecture and Design Figure 7 shows the system architecture of an enterprise cellular/VoWLAN dual mode service. A cellular/VoWLAN dual mode mobile equipped with two radio interfaces, i.e. a cellular interface and a WLAN interface, has an MSISDN (Mobile Subscriber ISDN) number for its cellular interface and a SIP (session initiation protocol) URI (Uniform Resource Identifier) for its WLAN interface. This study uses SIP as the call initiation protocol for VoIP services. A user with a dual mode mobile can choose the network interface for making calls based on their personal preferences, network connectivity and so on. The proposed design routes the incoming calls to the dual mode mobile to either the cellular interface or the WLAN interface, depending on the network connectivity of the mobile. To provide service continuity between cellular and VoWLAN systems without the involvement of a cellular operator, an enterprise and a dual mode service provider are two possible implementation examples.
An enterprise can reserve a range of PSTN numbers or enterprise extension numbers, and install a PSTN/VoIP gateway between PSTN/cellular networks and an enterprise IP network. These PSTN numbers or extension numbers are assigned to dual mode mobiles as their new dual mode service numbers. For implementation using enterprise extension numbers, the dual mode service requires two step dialing, which means callers must dial an enterprise number first followed by dialing other extension numbers. New dual mode SIP URIs that are generated from these numbers are further allocated to these dual mode mobiles. Consequently, dual mode mobiles have new dual mode numbers and new dual mode SIP URIs that are used for dial‐in. Incoming calls to the dual mode numbers or SIP URIs are processed using the proposed procedures.
N. Jain & H. Shahzad 12 May 2006
Two solutions, “parallel fork” and “wake‐up and register”, are proposed for handling incoming calls to a dual mode mobile. [26] 5.1 Incoming calls to the dual mode number parallel fork approach First, the parallel fork approach is described. Figure 8 illustrates the detailed procedures for processing the incoming calls from a PSTN or a cellular network to the dual mode number. Since the dual mode number range or the extension numbers are held by an enterprise or a dual mode service provider, the incoming calls are routed to the PSTN/VoIP gateway using the standard call routing procedure. Once the incoming call to the dual mode number is received by the PSTN/VoIP gateway, this gateway uses the dual mode number as the key for querying the database. If the dual mode mobile does not register its WLAN account, the database can only reply the cellular number of the dual mode mobile. The PSTN/VoIP gateway then dials the cellular number of the dual mode mobile only. If the database replies both a cellular number and a dual mode SIP URI to the gateway, the gateway dials the cellular number and also sends a SIP INVITE message to the dual mode mobile in parallel. The dual mode mobile receives incoming calls from its cellular interface, but holds the phone ringing for a short period. The mobile activates its WLAN interface, obtains WLAN/IP connectivity and tries to receive the SIP INVITE message from its WLAN interface. If the mobile does receive the SIP message, it responds to the SIP proxy server using its WLAN interface. Finally the dual mode mobile rings and the user answer the incoming calls via WLANs. If the dual mode mobile can not receive the SIP INVITE message within a pre‐configured time‐out value for any abnormal cases, it rings the users to pick up the call via a cellular interface. The cellular call to a dual mode mobile is designed to wake up the WLAN interface only, but it is actually not
picked up when VoWLAN services are available.
This design facilitates the dual mode user to be always reached by a single dual mode number. Notably, the WLAN interface of the dual mode mobile is completely off during idle, and the design significantly reduces WLAN power consumption in the idle mode. One problem with this approach is that a SIP proxy sends a SIP INVITE message to a SIP user agent without getting a response, and the SIP proxy will activate exponential backoffs on SIP message retransmissions [4]. The exponential backoff retransmission mechanism of SIP messages is originally designed for fixed networks to avoid network congestion, but it introduces extra call establishment delays. One approach could be to just disable the exponential backoff retransmission in the SIP proxy, or apply the next proposed wake‐up and register method to avoid the delay. [26] 5.2 Incoming calls to the dual mode number wakeup and register approach The wake‐up and register method is proposed to avoid delays associated with the exponential backoff retransmission of SIP messages. The idea of the wake‐up and register method is that a cellular call is still used to activate the WLAN interface, but the dual mode mobile communicates with the SIP proxy directly to poll SIP INVITE messages instead of waiting for incoming packets. That is, following WLAN is attached; the dual mode mobile sends SIP REGISTER to the SIP proxy to forward the incoming calls to its current location. Unlike the parallel fork approach, the wake up and register approach avoids the loss and the exponential backoff retransmission of the SIP INVITE message, but it requires additional time for registering with the server.
To model the initial call setup latency of the proposed methods, Figure 9 presents a timing diagram for all possible conditions, and illustrates a dual mode mobile that moves between three different access points (APs). The first two APs belong to the same
N. Jain & H. Shahzad 13 May 2006
subnetwork, but the third one belongs to another subnetwork domain. The upper part of the figure shows all of possible delays introduced by the parallel fork approach, while the lower part shows the delays associated with the wake up and register case.
Three different situations can occur if there is an incoming call to the mobile. One is that the WLAN interface activates and finds it can still access the same AP. This situation is called a layer one update case. After the mobile receives the cellular paging message from a cellular network, it takes DL1 time to activate WLAN interface and sense the original channel using the WLAN Probe Request and Probe Response messages. The WLAN interface then can receive incoming packets from WLANs. As noted above, since the parallel fork approach sends SIP INVITE messages and calls the dual mobile cellular number in parallel, the first one or several SIP INVITE messages may be dropped if the WLAN interface has not yet switched on. The SIP proxy server may trigger the exponential backoff retransmission mechanism for resending the next SIP INVITE. It is assumed that the dual mode mobile finally receives the ith SIP INVITE message from a SIP proxy. [26]
To avoid call loss, the parallel fork and wake up and register approaches both set a maximum waiting time. If a dual mode mobile can not receive a SIP INVITE message from the WLAN interface within the maximum waiting time, the mobile rings and the user can answer the cellular call. The maximal waiting time is a manageable parameter for users.
Another situation is that the WLAN interface wakes up but cannot sense the original channel. This situation is called the layer two update case. The worse case is that the WLAN interfaces wakes up, finds a new AP, but this new AP is not in the same network domain. 5.3 Periodical location update The above approaches, although efficient in reducing the power consumption of a WLAN
interface, they increase call setup delays, particularly while a mobile activates and situates in a new network. To reduce average call setup latencies, periodic location update procedures in idle mode are proposed. The idea is that the WLAN must wake up periodically to check whether it is still in the same AP. If the user moves to a new AP, the mobile performs either the layer two or layer three updates. This updates reduce the average call initial delay, but increase the power consumption. The location update period is a design parameter and the selection of the value depends on network environment and user mobility models. 6. WLANUMTS Interworking Architecture With the wide deployment of hotspots using WLAN wireless access technologies and the emergence of IP‐based data services provided by mobile cellular networks, the integration between wireless wide area networks (WWANs ex. UMTS) and WLANs has received a great deal of attention recently. The proposed integration architectures can be classified into two types: loosely coupled and tightly coupled interworking. In the former architecture, WWANs and WLANs are connected through the Internet, and each is an independent IP wireless access domain; in the latter architecture, WLANs are incorporated into WWANs as part of its radio access subsystem. Although either approach has its own merits and demerits, the loosely coupled architecture is assumed in this study because of its broader application. Figure 10 shows a logical view of the WLAN‐UMTS interworking architecture considered in this study. The architecture is primarily focused on wireless mobile multimedia networking and is constructed around an IP core network (the Internet) with two different types of access networks: UMTS and WLANs. The UMTS Release 5 (R5) multimedia architecture [26] has been proposed to provide multimedia‐based services in an all‐IP environment. However, complete migration to UMTS
N. Jain & H. Shahzad 14 May 2006
networks may not be possible in the near future, and a heterogeneous environment could evolve with several existing access technologies like IEEE 802.11‐based broadband WLANs operating with emerging core networks. This observation forms the basis of our selection criteria for the architecture to be studied. The UMTS R5 defines GPRS/Enhanced Data
Rates for GSM Evolution (EDGE) radio access network (GERAN) as its access technology. It is assumed that only GPRS access network due to its wider acceptance. GPRS networks are built on existing GSM (Global System for Mobile Communications) networks by adding a new class of network nodes called the GPRS support nodes (GSN). A serving GPRS support node (SGSN) is responsible for mobility and link management and delivering packets to a mobile host (MH) under its service area. A gateway GPRS support node (GGSN) acts as an interface between the GPRS network and the external packet data networks. Home Location Register (HLR) and Visited Location Register (VLR) are two databases used to keep user location information for mobility management. These databases are derived from the legacy GSM architecture. A location register in the SGSN keeps track of the current VLR for a user. [26]
A salient feature of UMTS R5 is a new subsystem, known as the IP multimedia subsystem (IMS), which works in conjunction with the packet switched core network (PS‐CN) to support legacy telephony services as well as new multimedia services.
SIP is the signaling protocol used between the mobile handset (MH) or user equipment (UE) and the IMS as well as with its internal components. As far as SIP signaling is concerned, the main component of the IMS involved is the call session control function (CSCF), which functions as a SIP server. The CSCF plays three roles: the proxy CSCF (P‐CSCF), interrogating CSCF (I‐CSCF), and serving CSCF (S‐CSCF). PCSCF is the mobile’s first point of contact with the IMS
network; I‐CSCF is responsible for selecting the appropriate S‐CSCF based on load or capability; and S‐CSCF is responsible for a mobile’s session management. The other access network technology considered is IEEE 802.11‐based WLANs. A WLAN access network consists of several access points (APs) providing radio access to the MH. The APs are connected to the backbone IP network with an Ethernet switch. A Dynamic Host Configuration Protocol (DHCP) server is used to assign an IP address to a visiting MH. We assume that an MH moving between UMTS networks and WLANs has separate network interfaces to connect to these networks. The MH, after moving to a UMTS network or WLAN, switches to the respective interface in order to attach to the corresponding access network infrastructures. The switchover instant is identified by the reception of the GPRS pilot signal in a UMTS network and the characteristics beacon in a WLAN. . [26] 6.1 Vertical Handoff in a WLANUMTS Internetwork As an application‐layer protocol, SIP relies on the protocols and mechanisms in the lower layers to handle the physical network connection. As far as SIP mid‐call mobility is concerned, additional procedures are needed to get the MHs attached to the wireless access network infrastructure before the SIP re‐INVITE message is sent. For example, an MH attaches to the GPRS radio access network of a UMTS network using the GPRS Attach and Packet Data Protocol (PDP) Context Activation procedures, while it uses DHCP to attach to a WLAN. Therefore, the vertical handoff delay mainly consists of the delay of network attachment as well as that of SIP location update. In the following sections we describe the procedures of vertical handoff and analyze the associated delays. In particular, two cases of vertical handoff are of interest: handoff from a WLAN to a UMTS network, and vice versa. . [26]
N. Jain & H. Shahzad 15 May 2006
6.1.1 WLANtoUMTS Vertical Handoff When an MH moves from a WLAN to a UMTS network, it performs two key functions to initiate a handoff. a.) Data connection setup, including the GPRS Attach and the PDP Context Activation: This establishes the data path required to carry the SIP‐related messages to the Proxy‐CSCF through the GGSN, which acts as the gateway for the Proxy‐CSCF. The messages involved in the GPRS Attach and PDP Context Activation procedures are shown in Figure 11. As part of the GPRS Attach procedure, the MH sends an Attach message (1) to the SGSN (responsible for mobility management, logical link management, and authentication and charging functions in a UMTS network) with the MH’s international subscriber identifier (IMSI). The SGSN uses the IMSI to authenticate (messages 2, 3, 4, and 5) the MH with its HLR. Successful authentication is followed by the SGSN sending a location update to the HLR (messages 6 and 7). The SGSN finally completes the Attach procedure by sending an Attach Complete message (8) to the MH. Thus, a logical association is established between the MH and the SGSN. Once an MH is attached to an SGSN, it must activate a PDP address (or IP address) to begin packet data communication. Activation of a PDP address creates an association between the MH’s current SGSN and the GGSN (acting as the interface between the GPRS/UMTS backbone network and the Internet) that anchors the PDP address. A record of such an association is known as the PDP context. PDP context transfer is initiated by the MH by sending a PDP Context Activation message (9) to the SGSN. The SGSN, after receiving this Activation message, discovers the appropriate GGSN (messages 10 and 11). It selects a GGSN capable of performing the functions required for SIP‐related activities. The SGSN and GGSN create special paths for the transfer of SIP messages
to the P‐CSCF, which is identified by the GGSN. The corresponding IP address of the P‐CSCF is sent along with the activation accept message (messages 12–16). [26] b.) SIP message exchange that reestablishes the connection: As shown in Fig. 2. the MH re‐invites the CH to its new temporary address by sending a SIP INVITE message (17) through the P‐CSCF, S‐CSCF, and I‐CSCF servers. The INVITE message uses the same call identifier as in the original call setup and contains the IP address at the new location in updated SDP parameters. Once the CH gets the updated information about the MH, it sends an OK message (18) while starting to send data. . [26] 6.1.2 UMTStoWLAN Vertical Handoff When an MH moves from a UMTS network to a WLAN it goes through the following major steps to update its location with the CH. a.) DHCP registration procedure: Assigns a new IP address for MH’s new location. The message exchanged in the registration procedure is shown in Figure 12. When the MH identifies the presence of a WLAN after receiving the characteristics beacons, it broadcasts a DHCP DISCOVER message (1) to discover the DHCP server willing to lend it registration service. The appropriate DHCP server sends out a DHCP OFFER message (2) to offer service to the requesting MH. The MH on receiving this OFFER message sends a DHCP REQUEST message (3) to the DHCP server to confirm the offer made. The DHCP server then sends the MH a DHCP ACK message (4) with such information as the new IP address to be assigned to the MH. . [26] b.) SIP message exchange: Re‐establishes the connection similar to how it’s done in UMTS networks, where the MH re‐invites the CH to its new address by sending a
N. Jain & H. Shahzad 16 May 2006
SIP INVITE message (messages 5 and 6, Fig. 3) after acquiring the new IP address. [26] 6.2. Effective VoIP Call Routing In UMTS‐WLAN integration, a dual‐mode mobile station (MS) typically disables the WLAN module for power saving. A major problem is that for an incoming VoIP call (or data session), the MS will not be able to receive this call from the WLAN. It turns out that the call is directed to the cellular network. This section discusses a simple push solution where an MS can accurately detect a VoIP call from paging signaling of the cellular network. Then the WLAN module of the MS is turned on and the VoIP call is connected to the MS through the relatively inexpensive WLAN.
Figure 13 illustrates a WLAN and cellular integration environment where the MS typically attempts to access the WLAN first for lower costs and higher bandwidth connection. If the WLAN is not available, the MS then tries to access the cellular network. Due to large power consumption of the WLAN module, the MS typically turns on the cellular module and turns off the WLAN module. The WLAN module is turned on only when the user attempts to access the WLAN. A major problem of this usage style is that, for example, the MS cannot receive the incoming Voice over IP (VoIP) calls from the WLAN when the WLAN module is off.
In [18, 13], a push mechanism is discussed for VoIP incoming calls to WLAN‐UMTS dual mode MSs. This approach utilizes Short Message Service (SMS) to alert the MS. In [4], the SMS mechanism is replaced by the normal cellular paging. Whenever the MS receives an incoming cellular call, it always attempts to connect to the WLAN first. If successes, the call is connected through the WLAN as a VoIP call. If fails, the MS accepts the cellular call. One problem about this approach is that the MS cannot distinguish a normal cellular call (path (5) in Fig. 1) from a VoIP call that is setup from the IP network (path (1)→ (2) → (3)). Therefore, for a
normal cellular call, the call setup is delayed because the MS always attempts to connect to the WLAN first. The MS always experiences the WLAN connection failure before connecting to the cellular network.
To resolve this problem, a simple approach is discussed where the MS can detect the “originating network” of the calling party. In a typical Internet and Public Switched Telephone Network (PSTN) interworking example illustrated in Figure 13, a Session Initiation Protocol (SIP) User Agent (UA) is connected to a SIP Call Server. The Call Server then sets up the call to the PSTN through a PSTN Gateway [1]. In a typical PSTN exercise, a PSTN Gateway is assigned an SS7 number (say, 46735xxx), or a group of leased lines whose telephone numbers have the same prefix (e.g., 46735). The push mechanism is implemented in the Call Server as described in [2], [3]. The resulting network node is called Call Server with Push (CSP). The CSP maintains a Dualmode MS (DM) Table. This table is used to track the call setup status of dual‐mode MSs. The MS maintains a PSTN Gateway Table. For every PSTN Gateway connected to the CSP, the SS7 number of the PSTN Gateway (e.g., 46735xxx) and the corresponding fully qualified domain name of the CSP (e.g., kth.se) are stored in an entry of the table. The next section illustrates how the DM table and the PSTN Gateway table can be used to correctly activate an MS with turn‐off WLAN module to receive an incoming VoIP call. [32] 6.2.1 The Call Server with Push (CSP) Approach Consider the SIP call setup procedure from an IP host (a UA) in the external data network (e.g., Internet) to an MS. The UMTS phone number of the MS is +46736776474 and the fully qualified domain name of the CSP is kth.se. Figure 14 illustrates the message flow and is described as follows. [32] Step 1. To set up a call to the MS, the UA sends an INVITE message to the CSP (Fig. 1 (1)). The INVITE message contains the SIP
N. Jain & H. Shahzad 17 May 2006
Universal Resource Identifier (URI) of the MS, i.e., [email protected] and the Session Description Protocol (SDP) that describes the RealTime Transport Protocol (RTP) information of the MS. The RTP information includes the IP address and port number of the UA. Step 2. To resolve the SIP URI in the INVITE message, the proxy function of the CSP identifies the contact information of the MS. (i) If the MS has registered to the CSP, the
CSP forwards the INVITE message to the MS directly, and follows the normal SIP call setup procedure to connect the call.
(ii) If not, the CSP routes the call to the PSTN according to the phone number +46736776474. Specifically, the CSP forwards the INVITE message to the PSTN Gateway (Fig. 1 (2)). The CSP also creates a record (i.e., a DM record) in its DM table for the MS to indicate that the call is set up to the PSTN.
Step 3. The PSTN Gateway generates an SS7 Initial Address Message (IAM) containing the caller ID 46735xxx (the SS7 number of the PSTN Gateway). Since the destination number +46736776474 is a UMTS MS Integrated Services Digital Network (ISDN) number, the IAM is sent to the UMTS network (Fig. 1 (3)). Step 4. Finally, the UMTS Base Station (BS) pages the MS. The message carries the caller ID 46735xxx. Step 5. The MS checks its PSTN Gateway table to see if 46735xxx is found. (i) If so, the corresponding fully qualified
domain name of the CSP (i.e., kth.se) is retrieved. Step 6 is executed.
(ii) If not, the MS answers the paging signal from the UMTS BS, and follows the normal UMTS procedure to connect the call.
At Step 5, through the caller ID, the MS accurately detects if the incoming call signaling comes from path (5) (Step 5 (b)) or from path (1)→ (2) → (3) (Step 5 (a)). Step 6. The MS attempts to access the nearby WLAN network. If successes, Step 7 is
executed. If no WLAN access is available, Step 5 (b) is executed. Step 7. The MS registers its contact address to the CSP (the registrar function) through a SIP REGISTER message (Figure 13 (4)). The registrar function updates the MS’s contact address information, and returns a 200 OK message to the MS. Since the DM record indicates that the call is being set up for the MS (see Step 2 (b)), the CSP determines that the call should be re‐connected to the MS through the WLAN. Step 8. The CSP (the proxy function) forwards the INVITE message to the MS. Step 9. Upon receipt of the INVITE message, the MS replies a 100 Trying message to indicate that the call is in progress. Step 10. The MS plays an audio ringing tone to alarm the called user and sends a 180 Ringing message to the UA through the CSP. Upon receipt of the 180 Ringing message, the UA plays an audio ringback tone to the calling user. Step 11. When the called user picks up the handset, the MS sends the final 200 OK message to the UA. The 200 OK message includes the SDP that describes the RTP information of the MS. Step 12. Upon receipt of the 200 OK message, the UA sends an ACK message to acknowledge the MS. The call is connected. Step 13. After Step 12, the CSP cancels the call setup procedure to the PSTN Gateway by sending a CANCEL message. The PSTN Gateway sends an SS7 Release message to the UMTS network. Step 14. The UMTS replies an SS7 Release Complete message to the PSTN Gateway. The PSTN Gateway replies a 200 OK message to the CSP to indicate that the call is successfully canceled. At this point, the voice path is (1)↔(4). One can note the following: ⟩ If any one of Steps 7‐12 fails, the MS will
execute Step 5 (b) to accept the cellular call (not shown in the call flow).
⟩ For a non‐VoIP incoming call from UMTS, the MS accepts the call immediately (Step
N. Jain & H. Shahzad 18 May 2006
5 (b)). Therefore the extra delay in [4] is avoided.
⟩ If the MS has already registered at the CSP, then the call is set up through the WLAN directly at Step 2 (a).
⟩ If the MS cannot connect to any WLAN access point, it accepts the cellular call at Step 6.
⟩ There may be several CSP‐PSTN Gateway pairs in the MS’s PSTN Gateway table, and the MS can detect the VoIP calls from various PSTN Gateways.
7. Conclusion Future‐generation wireless networks have been envisioned as the integration of various wireless access networks. Data and voice services will be simultaneously available through the same terminal. In such environments today, multiple issues in multiple layers still have to be resolved to ensure acceptable voice quality through VoIP in disparate wireless networks
Seamless mobility support is the basis to provide uninterrupted wireless services to mobile users in such a heterogeneous network environment. This paper presented also the mobility management issues regarding VoIP services in wireless access technologies convergence. Mobile IP (network layer solution) and SIP (application layer solution) were described in terms of mobility management. Over the years, several schemes have been proposed for mobility management in IP networks. For delay‐intolerant applications such as VoIP, mobile IP still falls short in terms of providing a means of fast handover with minimal or no packet loss; although, as a layer 3 protocol for seamless mobility across heterogeneous networks, it has gained momentum in the recent years. Through this paper we discussed some layer 2 enhancements at the MN that work in con‐junction with the mobile IP client software to enable make‐before‐break handover between heterogeneous networks.
On the other side, SIP, a widely accepted signaling protocol, is capable of
providing mobility support at the application layer, where there is the least amount of dependence on the lower layers. In this paper, we also discussed the scenarios of vertical handoff delay in a WLAN‐UMTS inter‐network using SIP as the terminal mobility management protocol. Studies have shown that the WLAN‐to‐UMTS handoff due to error‐prone and bandwidth‐limited wireless links incurs much larger delay than the UMTS‐to‐WLAN handoff. In order to comply with the maximum limit of the handoff delay for supporting delay‐sensitive applications, soft handoff techniques need to be applied for SIP‐based terminal mobility management in heterogeneous wireless IP networks. One of the significant issues besides mobility management in a WLAN and cellular integrated network is that a dual‐mode MS typically disables the WLAN module to reduce the power consumption. Therefore, the incoming VoIP calls to the MS cannot be connected through the WLAN. To address this issue, this paper also discussed a Caller Server with Push (CSP) mechanism where the MS can accurately detect the VoIP calls through cellular paging, and then the CSP can re‐route the call through the WLAN.
There are some successful stories for VoIP in converged wireless access networks but to enable large deployment of services in public networks suffers from a number of technical challenges. Research and technologies development at both terminals and networks are required urgently, and more detail analysis and from different perspectives will be very helpful. Besides that the protocol between terminals and networks should be standardized, opens issues such as how terminals decide the always best connected issues, always on issue, and power consumption issues needs to be further studied.
N. Jain & H. Shahzad 19 May 2006
References 1. A. Acharya, S. Berger and C.
Narayanaswami, “Unleashing the Power of Wearable Devices in a SIP Infrastructure”, Proceedings of the 3rd IEEE Int’l Conf. on Pervasive Computing and Communications (PerCom 2005), 2005
2. A. C. Snoeren and H. Balakrishnan,
“An End‐to‐End Approach to Host Mobility”, Proceedings of the ACM Mobicom, August 2000.
3. A. Dutta, F. Vakil, J.‐C. Chen, M. Tauil,
S. Baba, N. Nakajima, and H. Schulzrinne, "Application layer mobility management scheme for wireless Internet", In Proc. of IEEE International Conference on Third Generation Wireless and Beyond (3Gwireless'01), May 2001.
4. A. Grilo, P. Estrela, and M. Nunes,
“Terminal Independent Mobility for IP (TIMIP)”, IEEE Communication Magazine, 2001.
5. A. Rajkumar, P. Feder, S. Benno and T.
Janiszewski, “Seamless SIP‐Based VoIP in Disparate Wireless Systems and Networks”, Bell Labs Technical Journal 9(1), Lucent Technologies Inc., 2004
6. C. Perkins and D. Johnson, “Route
Optimization in Mobile IP”, IETF Draft, September 2001, <http://www.ietf.org/internet‐drafts/draft‐ietf‐mobileip‐optim‐11.txt>
7. C. E. Perkins, IP Mobility Support for
IPv4, RFC 3220, Jan. 2002.
8. C. Perkins (ed.), “IP Mobility Support for IPv4,” IETF RFC 3344, August 2002, <http://www.ietf.org/rfc/rfc3344.txt?number=3344>.
9. C‐Y. Wan, A. T. Campbell, and A. G.
Valko, “Design, implementation and Evaluation of Cellular IP”, IEEE Personal Communications, Vol. 7, No. 4, August 2000.
10. D. Benenati, P. Feder, N. Lee, S.
Martin‐Leon, and R. Shapira, “A Seamless Mobile IP VPN Data Solution for CDMA, UMTS, and WLAN Users,” Bell Labs Tech. J., 7:2, 2002
11. D. Vali and A. Greece, “An Efficient
Micro‐Mobility Solution for SIP Networks”, IEEE Globecom, 2003
12. E. Wedlund, H. Schulzrinne, “Mobility
support using SIP”, 2nd ACM/IEEE International Conference on Wireless and Mobile Multimedia, August 1999
13. Feng, V. W.‐S., Wu., L.‐Y., Lin, Y.‐B.,
and Chen, W.‐E., “WGSN: WLAN based GPRS Environment Support Node with Push Mechanism”, The Computer Journal, 47(4), 2004.
14. H. Schulzrinne, E. Wedlund,
“Application layer mobility using SIP”, Mobile Computing and Communications Review, Volume 4, Number 3, 2001
15. Handley, M. and V. Jacobson, SDP:
Session Description Protocol, RFC 2327, IETF April 1998.
16. J. Ala‐Laurila and et al., “Wireless LAN
access network architecture for mobile operators,” IEEE Communications Magazine, Nov. 2001.
N. Jain & H. Shahzad 20 May 2006
17. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: Session Initiation Protocol”, IETF RFC 3261, June 2002.
18. Lin, Y.‐B., Lo, Y.‐C., and Rao, C.‐H. A
Push Mechanism for GPRS Supporting Private IP Addresses. IEEE Communications Letters, 5(1), 2003.
19. M. Buddhikot, G. Chandranmenon, S.
Han, Y. Lee, S. Miller, and L. Salgarelli, “Integration of 802.11 and Third‐Generation Wireless Data Networks,” Proceedings of the IEEE Infocom, Vol. 1, 2003
20. M. Stemm and R. Katz, “Vertical
handoffs in wireless overlay networks”, ACM Mobile Networks and Applications (MONET), Vol. 3(4), 1998.
21. N. Banerjee, W. Wu, K. Basu, and S. K.
Das, “SIP Based Mobility Management in 4G Wireless Networks”, Journal of Computer Communications, special issue on Research Directions in 4th Generation Wireless Networks, Vol. 27/8, 2003.
22. N. Banerjee,W.Wu, S. K. Das, and S.
Dawkins, and J. Pathak, “Mobility Support in Wireless Internet”, IEEE Wireless Communications Magazine, Vol. 10, No. 5, 2003.
23. N. Banerjee and S. K. Das, “SIP‐based
Mobility Architecture for Next Generation Wireless Networks”, Proceedings of the 3rd IEEE Int’l Conf. on Pervasive Computing and Communications (PerCom 2005), 2005
24. Q. Zhang, C. Guo, Z. Guo and W. Zhu, “Efficient mobility management for vertical handoff between WWAN and WLAN”, IEEE Communications Magazine, Vol. 41, No. 11, 2003.
25. R. Sparks, “The Session Initiation
Protocol (SIP) Refer Method,” IETF RFC 3515, 2003, <http://www.ietf.org/rfc/rfc3515.txt?number=3515>.
26. Shiao‐Li Tsao and E‐Cheng Cheng,
“Reducing Idle Mode Power Consumption of Cellular/VoWLAN Dual Mode Mobiles”, IEEE Globecom 2005
27. S. Das, A. McCauley, A. Dutta, A. Misra,
K. Chakraborty and S. K. Das, “IDMP: An Intra‐Domain Mobility Management Protocol for Next‐Generation Wireless Networks”, IEEE Wireless Communications, Vol. 9, No. 3, June 2002.
28. T. La. Porta, R. Ramjee, L. Lee, L.
Salgerelli, and S. Thuel, “IP‐based access network infrastructure for next‐generation wireless data networks” IEEE Personal Communications, Vol. 7, No. 4, August 2000.
29. The Internet Engineering Task Force,
http://www.itef.org
30. W. Wu, N. Banerjee, K. Basu and S.K. Das, ” SIP‐Based Vertical Handoff Between WWANs and WLANs”, IEEE Wireless Communications Magazine, June 2005
31. W. Jiang, J. Lennox, H. Schulzrinne
and K. Singh. Towards Junking the PBX: Deploying IP Telephony. NOSSDAV, 2001
N. Jain & H. Shahzad 21 May 2006
32. Yi‐Bing Lin, Whai‐En Chen and Chai‐Hien Gan, “Effective VoIP Call Routing in WLAN and Cellular Integration”, IEEE Communications Letters, Vol. 9, No. 10, October 2005
33. 3rd Generation Partnership Project,
“Technical Specification Group Services and Systems Aspects; Network Architecture,” TS 23.002, <http://www.3gpp.org/ftp/Specs/html‐info/23002.htm>.
34. 3rd Generation Partnership Project,
“Technical Specification Group Service and Systems Aspects; IP Multimedia Subsystem (IMS); Stage 2,” TS 23.228, <http://www.3gpp.org/ftp/Specs/html‐info/23228.htm>.
35. 3rd Generation Partnership Project,
“Technical Specification Group Core Network; IP Multimedia Call Control Protocol based on Session Initiation Protocol (SI) and Session Description Protocol (SDP); Stage 3,” TS 24.229, <http://www.3gpp.org/ftp/Specs/html‐info/24228.htm>
Figure 6. ”Makebeforebreak” switching for overlapped coverage and “breakbeforemake”
switching for nonoverlapped coverage
Figure 8. Routing of incoming calls to a duel mode mobile using parallel fork approach
Figure 9. Timing diagram of parallel fork, wakeup and register approaches