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 application­layer  based  Session  Initiation Protocol  (SIP)  has  been  considered  the  right candidate  for  handling  mobility  in heterogeneous wireless networks. However, SIP entails  application­layer  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. SIP­Based 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.,  <userA@kth.se>—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 <enduserA@kth.se>.  

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  “Make­Before­Break” 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  Dual­Mode 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 ­ wake­up 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.  WLAN­UMTS  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  WLAN­UMTS 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 WLAN­to­UMTS 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  re­establishes 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 UMTS­to­WLAN 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 Dual­mode 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.,  +46736776474@kth.se  and  the  Session Description Protocol (SDP)  that describes  the Real­Time  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> 

                   

   

Figures and Tables 

 Figure 1. SIP Architecture 

  

 Figure 2. SIP Call Setup & Media Path 

  

Figure 3. Basic Call Flow  

 Figure 4. Basic SIP Exchange 

 

 Figure 5. Mobile IP with Foreign Agent 

 Figure 6. ”Make­before­break” switching for overlapped coverage and “break­before­make” 

switching for non­overlapped coverage 

  

  

Figure 7. Design example of integrated VoWLAN/Celluar Service 

 Figure 8. Routing of incoming calls to a duel mode mobile using parallel fork approach 

 

 Figure 9. Timing diagram of parallel fork, wake­up and register approaches 

 Figure 10. WLAN­UMTS Interworking Architecture 

 

 Figure 11. Signaling for WLAN­to­UMTS Handoff 

 Figure 12. Signaling for UMTS­to­WLAN Handoff 

  

Figure 13. WLAN and Cellular integration environment 

  

Figure 14. Message Flow for an incoming call to the dual­mode mobile MS  

 Figure X. Illustration of future voice over converged wireless networks