Title: Wireless ATM Handover Requirements and Issues


Source:John Porter, Damian Gilmurray, Alistair Massarella, John Naylon

Olivetti Research Limited

24a Trumpington Street

Cambridge CB2 1QA

United Kingdom

 

Phone: +44 1223 343000 Fax: +44 1223 313542

Email: {jporter,dgilmurray,amassarella,jnaylon}@orl.co.uk


Date: February 9-14, 1997

San Diego, California


Distribution: WATM


Notice: This contribution has been prepared to assist the ATM Forum. It is offered for discussion and is not a binding proposal on Olivetti Research Limited. Specifically Olivetti Research Limited reserves the right to add, amend or withdraw any or all statements contained herein.


Abstract: This contribution expands the handover requirements detailed in ATM Forum/96-989. These requirements are then used to address several issues involved with the handover procedure.


1. Introduction

The aim of the handover protocol is to enable a wireless terminal (WT) or wireless network (WN) to seamlessly move between access points (AP) while maintaining the negotiated Quality of Service (QoS) of its active connections. This can be achieved by the efficient rerouting and switching of the WTs virtual connections (VCs) to the appropriate AP in the wired network. A set of requirements must be defined for the handover process in order to analyse currently proposed handover procedures.

This contribution expands the requirements outlined in the ATM Forum/96-989. These requirements are then used to compare and contrast the performance of a number of different handover strategies outlined in contributions [2,3,4].

 

2. Handover Requirements

The requirements for the handover procedure are listed in ATM Forum/96-989. The following sections expand and detail further the original handover requirements list.

 

 2.1 Handover Latency

 

 2.2 Scalability

 

2.3 Quality of Service (QoS)

 

2.4 Signalling Traffic

 

2.5 Buffer Tradeoff

 

2.6 Data Integrity

 

2.7 Group Handover

 

2.8 Registration and Authentication

 

3. Handover Issues

The above requirements can now be used to determine the suitability of the different approaches used to support a connection orientated WT or WN handover [2,3,4].

 

3.1 Path Extension vs Path Rerouting

Path extension involves extending the route of a connection from the old AP to the new AP on handover. This makes it easier to implement connection handover without affecting data integrity (Req 2.6). As the endpoints of the extension are known a priori, no endpoint determination process is required and the only delay is in the actual setup of the extension. This will reduce the overall handover delay (Req 2.1).

However, after a number of handovers, possibly among a small set of APs, connection looping will occur. To counter this, some form of route optimisation will be required. This optimisation could be lazy, but dynamically rerouting connections, which are subject to handover, is at least as complex as path rerouting. Each connection will also require some form of global connection identifier, together with support for the optimisation process in intervening switches.

Path rerouting involves changing the route of some portion of a connection from a suitable switch termed a Crossover Switch (COS) to the new AP. The new route of the connection can be close to optimal depending on the COS selection. However, in rerouting the path of a connection, it is more difficult to prevent cell loss or reordering (Req 2.6).

The selection of the COS in the path rerouting scenario can be either static or dynamic. The advantages and disadvantages of each method are discussed below.

 

3.2 Static vs Dynamic COS Selection

To choose an optimal route it is necessary to dynamically select a (possibly different) COS for each connection to the WT or WN. This selection process must start from the calling party end of the connection. This will require the evaluation of a COS selection algorithm at every switch on the path of the connection until the optimal COS is located for each connection (implications for Req 2.1, 2.4 and 2.7). In practice, therefore, every switch in the network will have to support this COS selection procedure (infringing Req 2.2).

The further the COS is from the old AP, the more cells will be in transit on the path between the COS and the AP - this implies either the delay will be longer or more cells will be lost when switching connection paths, affecting the requirements in 2.3, 2.5 and 2.6.

An alternative approach is to semi-statically allocate a COS to a WT within the network at which it is currently registered. All connections to the WT are routed through this switch. On handover, no COS selection strategy is required reducing the signalling and management overhead (Req 2.1, 2.4). By statically allocating a COS, all connections to the WT can be bundled and managed collectively (Req 2.7). This significantly reduces the number of handover state machines required thus simplifying the overall procedure.

The routing of WT connections may not be optimal but this is traded off against the reduction in handover overhead and latency. To reduce the impact of this sub-optimal routing, the COS could be migrated after the handover to a switch that is better suited to the WTs current AP.

 

3.3 Control Plane vs User Plane Handover Signalling

The current WATM reference model [5] proposes a modification to standard control plane signalling to include support for handover signalling. A different approach could be to use user plane virtual connections for handover signalling [6]. These user plane handover signalling channels could be provisioned or switched and would provide signalling between mobile software entities such as those at a WTs COS switch and at a WTs current AP.

The advantages of using user plane signalling are twofold:

  1. The signalling would be significantly faster as the overhead and delay of control plane signalling processing at each hop would be avoided - this is very important to reduce overall handover latency (Req 2.1).
  2. Modifications to UNI/PNNI are not required in intermediate switches thereby allowing the protocol to operate with current and future signalling releases.

 User plane handover signalling does need to have assured delivery and therefore reliability can be built into the handover state machines taking into account the characteristics of the physical layer during handoff.

 

3.4 Backward and Forward Handover

A backward handover uses the current AP to signal the request to handover to the new AP. This allows the rerouting or extension of the current path to be established using call setup signalling while the WT still has connectivity. Once this duplication or extension has been completed, the current AP indicates to the WT that it can now handover. To handover, the WT has simply to switch physical channels to the new AP and connectivity is restored.

Backward handover thereby allows the relatively large signalling delays associated with extending or rerouting VCs to be separated from the physical handover delay (Req 2.1, 2.3, 2.6). It does however assume that the WT will normally be able to predict the requirement for handover.

Forward handover will be necessary when the WT has lost connectivity with the current AP. In this case a seamless handover will be difficult to achieve as connectivity will be interrupted for the time it takes to switch physical channel plus the time it takes to perform the path rerouting or extension.

 

4. Summary

This contribution has expanded and provided further details to the handover requirements given in ATM Forum/96-989.

The above handover requirements were then used to examine the performance of several aspects of the handover procedure proposed in previous contributions.

We suggest that in order to achieve an efficient handover of a WT or WN with multiple active VCs, then the handover algorithm must use path rerouting with a semi-static COS, support backward and forward handover and use a user plane handover signalling protocol. This handover strategy will be the subject of a future contribution to the ATM Forum WATM WG.

 

5. References  

[1] Rauhala, K. ATM Forum/96-989 "Requirements for Mobile ATM Handover"

[2] Veeraraghavan, M. ATM Forum/96-1700 "A Combined Handoff Scheme for Mobile ATM Networks"

[3] Acharya, A. et al. ATM Forum/96-1121 "Primitives for Location Management and Handoff in Mobile ATM Networks"

[4] Porter, J. et al., "The ORL Radio ATM System, Architecture and Implementation", Olivetti Research Technical Report 96.5, January, 1996.

[5] Dellaverson, L. ATM Forum/96-0712 "Proposed Charter, Work Plan and Schedule for a Wireless ATM Working Group"

[6] Cheng, M. ATM Forum/96-1715 " Mobility Management Signalling for PCS-to-ATM Interworking"