Mobility Management in the Wireless ATM Network ... - CiteSeerX

1 downloads 6234 Views 385KB Size Report
However, as the tech- nology involved ... of BSs exchanging information with other MTs or fixed ... are exchanged through a pre-reserved VC in the BS-CSU link.
Mobility Management in the Wireless ATM Network Demonstrator Stathes Hadjiefthymiades, Alexandros Kaloxylos, Lazaros Merakos Communication Networks Laboratory, Department of Informatics, University of Athens TYPA Building, Panepistimioupolis Illision, Illisia - Athens 15784, Greece {shadj | agk | merakos}@di.uoa.gr Abstract - The introduction of ATM in wireless CPN environments (WATM) necessitates the design of mobility signalling protocols, since the existing versions of BISDN signalling do not support terminal mobility. These protocols can be deployed either as extensions to the standard signalling capabilities, or as individual solutions that have little or no impact on existing infrastructures (switches, signalling software, etc.). In this paper, we present a WATM architecture that adopts the latter approach. We briefly present several problems that emerge during the integration of wireless networking and B-ISDN ATM technologies. We discuss the design of a Mobility Management & Control protocol (MMC). Finally, we show how registration and forward handover are structured in light of the MMC protocol. 1. Introduction The introduction of the Asynchronous Transfer Mode (ATM) in Wireless CPN environments (WATM) has been a trendy research topic for some time leading to the deployment of several pilot-experimental installations and the early stages of products [1-3]. However, as the technology involved is not yet mature enough, there are many technical issues that need to be resolved. Signalling is definitely one of the troublesome areas. Apart from the conventional signalling encountered in wired networks, additional control is needed to cover terminal mobility requirements [4-9]. Wired ATM networks do not provide for such mobility of user terminal equipment. Contemp orary B-ISDN signalling lacks signals and procedures for handover, location updating, and (de)registration of mobile terminals in the network. A possible solution to this problem could be the integration of the required mobility extensions with the standard signalling protocols to satisfy the identified requirements. Such alternative could lead to rather complex signalling protocols, whose complete range of functionalities is not required in fixed ATM networks. A more realistic approach suggests the introduction of new, completely independent, protocols which handle only the mobility procedures (mobility control), while interacting with conventional signalling (call control). This distinction and the two possible approaches are also outlined in [5]. The design of mobility protocols needs to take into account the problem of switching the signalling and data connections of a terminal, as the latter moves from the coverage area of one Base Station (BS) to that of its neighbouring (handover). Mobility signalling and related procedures need to be designed appropriately to enable fixed network entities to render the signalling channels available to the mobile terminal in the new/target BS as

fast as possible. Such procedures, despite the fact that are uniformly applied in all handover cases, are mainly in tended for those in which the current connection is abruptly lost. Such cases present substantial difficulties which are mainly attributed to: • the current capabilities offered by ATM equipment (switches, software), • the limited amount of time available for the switching of control and user plane connections, and finally, • their unpredictable nature (no efficient strategy can be applied in a CPN environment). The contribution of this paper is the design of a mobility signalling protocol for a Wireless ATM network, where the BSs have minimal functionality and are not directly interconnected. The protocol handles the required connection switching in a uniform way for both data and signalling connections for all mobility procedures, complies with existing ATM signalling standards and, its implementation leaves commercially available ATM comp onents unaffected. This protocol has been implemented in the context of the Magic WAND (Wireless ATM Network Demonstrator) project [3] funded by the EU in the context of the ACTS programme. The rest of the paper is organised as follows. Section 2, proposes a network architecture based on the separation of call and mobility control. In this architecture, apart from the well-known signalling VC, one additional signalling channel is introduced at the user-network interface (UNI). Section 3 discusses the functional entities needed in the WATM architecture as well as their interrelationships in the context of the various protocol stacks. Section 4 provides a brief overview of the handover types encountered in a CPN environment and proposes a solution for the switching of the signalling and data connections. VC switching - re-routing is accomplished through the Application Programming Interfaces (API) that mo dern switches offer (or their support for GSMP [20]). In section 5 we present the Message Sequence Charts (MSCs [16]) for the cases of Registration and Forward Handover. We conclude this paper in section 6. 2. Network architecture The main components of the wireless architecture are Mobile Terminals (MT), Base Stations (BS) and a Control & Switching Unit (CSU). MTs roam in the coverage area of BSs exchanging information with other MTs or fixed terminals. BSs are attached to the CSU ports by means of high bandwidth links. Their primary role is the adaptation of ATM cells to radio packets and vice versa.

The CSU is a basic component in the overall configuration providing for mobility related signalling (e.g., registration, handover) as well as routing of ATM cells (CSU incorporates a typical, commercially available, ATM switch). Due to its strong involvement in mobility related procedures, the operation of CSU is supported by a specially designed database (DB). DB keeps track of the current location and status of MTs, and can be used for authentication and security procedures. All MT originated signalling messages related to mobility are diverted to the CSU and processed there (CSU constitutes mobility signalling end-point). Standard signalling messages (e.g., SETUP) are also diverted to the CSU (to examine their potential local scope) but subsequently forwarded towards the other terminal participating in the call.

Figure 2 illustrates the VP/VC allocation in the BS-CSU fixed link. The VC allocation scheme of the previous paragraph applies to all the BS-CSU fixed links; link number differentiates individual connections.

BSs are controlled by the CSU by means of a specialised protocol (hereinafter referred to as BSMP - Base Station Management Protocol). BS management related messages are exchanged through a pre-reserved VC in the BS-CSU link. A graphical overview of the network architecture is provided in Figure 1.

3. Functional entities and signalling stacks In this section, the functional entities needed in support of the considered WATM architecture are discussed. In the MT, a specialised entity performing mobility control is introduced. This entity is referred to as Mobility Management and Control (MMC). MMC is responsible for all mobility procedures. MMC, upon notification by the lower layers on the changes experienced over the radio channel, determines the type of handover (backward or forward) that should be requested. Conventional signalling1 is left to an ATMF UNI 3.1 [12] compatible entity, called Call Control end Signalling (CCS), which is a slight extension of standard signalling to support the information required by MMC. Both the MMC and CCS protocols rely on SAAL [14,18] for assured transfer of signalling information.

DB Base Station 1

CSU

MT Fixed ATM terminal

Base Station 2

Fixed ATM infrastructure

Wireless subsystem

VPI=w

SVC (VCI=5) M channel (VCI=31) User data VCs

M channel (VCI=31) VPI=w

VPI=z BSMP

SVC (VCI=5)

CSU

VPI=z User data VCs

VPI=x

BS2 VPI=x

BS1

Fixed Link 2

Fixed Link 1

Figure 2- BS-CSU ATM link

Figure 1 - Wireless ATM network architecture A major problem, encountered when porting signalling protocols from wired ATM systems to wireless environments, refers to the transmission of signalling information by different MTs on the same VPI/VCI combination (VPI=0, VCI=5 for ATMF UNI 3.1). Since BSs behave as traffic concentrators on the uplink and splitters on the downlink, a conflict is experienced due to the mandatory use of the same VPI/VCI values. In order to eliminate such a conflict, in the considered network architecture (limited MT population), one VP (VPI=x, x is calculated on the basis of the unique ATM address assigned to the terminal) is reserved for each MT in the MT-CSU logical interface. The mapping of VPI values is performed at the lower layers of the MT, transparently to the signalling entities which are positioned at the higher layers. Within this VP, a permanent VC is reserved for the purpose of exchanging standard signalling messages [11,12,17]. One permanent VC (PVC) is also allocated for mobility related signalling. PVCs intended for standard signalling will be referred to as ‘S-channels’, while PVCs for mobility signalling will be termed “M-channels”. This separation of signalling channels is adopted in order to minimise the impact on the existing ATM infrastructure and is one of the main objectives of this work.

Furthermore, in the MT there is a need for the introduction of a wireless MAC (WMAC) entity [15]. WMAC helps obtaining control of the shared medium, performs association or de-association with BSs, routes ATM cells to the physical layer (and vice versa) and notifies MMC on the status of the radio link. Its counterpart is located in the BS, where a Radio Resource Manager (RRM) is also needed. Such entity retrieves long and short term traffic characteristics from the WMAC entity and performs Connection Admission Control (CAC) for the wireless part of the network (Wireless CAC - WCAC). The CSU incorporates a conventional signalling entity (Q.2931 [11]), as well as a signalling entity intended for mobility management and control (MMC). The latter entity communicates with RRM by means of the BSMP. On top of the Q.2931 signalling entity there is a module called Resource Manager (RM), responsible for performing Call Admission Control (FCAC), Routing and Addressing for the fixed part of the network. In terms of entity instances, there is an one-to-one mapping between RRM and BSs (one RRM instance per BS). There is also an one-to-one relationship between active MTs and MMC instances residing within the CSU 1

MT is a signaling end-point for both conventional and mobility signaling.

(CS_MMC). The same applies for RM. In each MT only one MMC (MT_MMC) and one CCS instances are needed. Figure 3 presents the protocol stacks in the network architecture. Grey lines denote logical interfaces.

MMC

Q.2931

SAAL instances CCS UNI 3.1

U-plane

DB MT_MMC RRM

SAAL

RM

CS_MMC

Q2931

ATM

ATM WMAC

WMAC PHY

radio link

Mobile Terminal

PHY

PHY Base Station

Q.2931 NNI

SAAL ATM PHY Control Switching Unit

Backbone ATM Network

CSU U-plane

SAAL ATM PHY Wired ATM terminal

Link=02 VCI=30

Link=01

BS1 (target)

4. Dynamic switching of connections In all cellular environments one can identify two handover types: backward and forward. This distinction refers to the BSs through which the handover signalling information is exchanged. In the case of backward handover, all signalling messages for the realisation of handover, are exchanged via the old BS (the BS the MT has been attached to during the recent past). This is the case when the quality of the radio channel fades gracefully, thus allowing the MT to react promptly. As the fixed network entities receive all the signalling information prior to handover, it is easy to perform the necessary switching of signalling channels and render them available in the new BS. The switching of signalling connections will be discussed below.

In the considered network architecture there is only one data path at a time (between the MT and the CSU), through which signalling information can be exchanged (i.e. no macrodiversity is used). The signalling channels have to be re-routed, towards the new BS, very rapidly during forward handover. The existing SAAL instances should be destroyed and new SAAL instances, between the MT and the CSU, should be spawned (Figure 4). Furthermore, the state of the old SAAL instances should be transferred to the new ones.

Link=04

BS3

BS4 Current Link Target Link

Figure 4 - Switching of signalling connections In order to avoid this sort of actions the CS_MMC uses its interface with the switch API to reroute the M-channel connection in the ATM layer thus, leaving the SAAL instances unaffected. The SAAL connection between the CS and the BSs (VCC - Virtual Channel Connection) comprises two VCLs (Virtual Channel Links). A VC cross connect is deployed through the switch API. The discussed VCC is graphically depicted in Figure 5.

MMC Switch API

ATM Switching

SAAL

Xconnect

VCI=60,

Link=1,VCI=30, VPI=01

In the case of the forward handover, the link with the old base station is suddenly lost thus, forcing the MT to seek connectivity through other, neighbouring BSs. The sudden loss of the radio connection causes a disruption in all types of connections (user and control plane). As the fixed network entities have not received any previous information on this event, they are not able to a-priori switch the signalling connections. Thus, the MT is left without signalling channel through which it could notify the fixed network entities. Such combination of events is experienced very often in CPN environments and calls for solution.

Link=03

MT

Mobility related modules

Figure 3 - Protocol stacks

Link=02 VCI=05

BS2

Current Link Link=2,VCI=30, VPI=01 Target Link VCL

VCL VCC

Figure 5 - Switching of signalling connection using the switch API The inner VCL (VCL between the switching unit and the SAAL) is established once upon MT’s registration. Outer VCLs are associated to the inner VCL each time the MT moves to a new BS. CS_MMC triggers the VCL association (changes to the involved VC cross connect) according to the mechanism described below. In the case of handover, CS_MMC faces a dilemma: where to switch the M-channel to. The only network elements that store real-time information about the location of an MT, are the BSs and the MTs themselves. Thus, the information requirements of CS_MMC are satisfied by the RRM entities, located within the BSs. As the RRM entities are positioned in the forefront of the wired part of the network and have direct access to the WMAC data structures, it is relatively easy to obtain information on radio associations and de-associations of MTs. An association with the BS it can hear best is the first thing a MT pursues during a forward handover. Such association is detected by RRM which subsequently notifies CS_MMC. This sequence of events is graphically depicted in Figure 6. Initially (step 1 in the figure) the MT communicates through BS1 (with RRM-old). In step 2, the MT crosses the cell boundary but the radio link quality fades very

rapidly thus triggering a forward handover. In step 3, the MT associates with the BS2. This association is detected by RRM-new (RRM within BS2) in step 4. CS_MMC is notified in step 5 and it proceeds with the required rerouting of signalling connections. The user plane connections are re-routed after the signalling channels become operational. RRM-old

Title: MSCDIAGRAM Registration Creator: (SDT 3.0) CreationDate: (Thu Oct 09 14:39:35 1997)

MMC 5

1

Base Station 1 MT 4 RRM-new

CSU

2

Base Station 2 3

Figure 6 - Steps for forward handover with signalling channel switching The re-routing of the signalling connections is performed at the ATM level, where the VC cross-connection is modified. leaving the upper layer entities (signalling endpoints) unaffected. 5. Mobility procedures In this section, a detailed description for the Registration and Forward Handover procedures is given. Registration Whenever an MT powers-on within the network, it needs to register and then perform security and authentication procedures. The first step is to associate with the BS it can hear best. Upon successful association, resources are reserved on the wireless part by RRM. The CS_MMC is also notified on this event (NEW_ASSOCIATION). CS_MMC checks if this is the first time it receives a signal for the specific mobile. In such case, CS_MMC will check with RM, if there are enough resources on the fixed part of the network to support the M-channel (FR_STATUS). If there are sufficient resources, CS_MMC is notified (CONN_SET) and performs the necessary VC configuration, using the switch API. When the configuration of the channel is completed CS_MMC requests the establishment of a SAAL connection with MT_MMC. The MT receives notification of the SAAL connection establishment and the availability of the Mchannel (SIG_CHANNEL_READY). It then uses the Mchannel, to start the registration procedure (REGISTRATION_req). At this point no standard signalling channel is configured, since no security/authentication operations have taken place. This will happen when the DB is notified to create an entry for the specific MT (CREATE_ENTRY_req/cnf). After the security actions are completed the MT will check if there are enough re sources to support the signalling channel on the fixed part and if there are it will notify both RRM (CONN_SWITCHED) and the MT_MMC (REGISTRATION_cnf), about the result of the registration. Figure 7 illustrates the discussed procedure.

Figure 7 - MSC for the Registration procedure Forward Handover Forward handover is executed whenever the radio link of an MT with a BS is abruptly lost (fast fading effect). The MT, that didn’t have the chance to pass signalling information to the CSU, pursues association with the BS it can hear best. The RRM entities of both the old and the new BSs are aware of the current status of the MT in the wireless interface. The RRM of the new BS (RRM_new) is responsible for notifying the appropriate MMC instance of the CSU on MT’s recent radio association (NEW_ASSOCIATION). As argued in Section IV, this message is the external stimulus that triggers the switching of the signalling connections on the fixed network. Prior to the transmission of NEW_ASSOCIATION, RRM_new performs the WCAC procedure for both the M-channel and the S-channel. If no resources are available for the signalling channels, then the association fails and the MT retries handover. Upon reception of NEW_ASSOCIATION by CS_MMC, the RM entity is invoked (FR_STATUS), to check the resources on the fixed network, and to establish two VCs (M & S-channels) towards the new BS. It then triggers CS_MMC (CONN_SET) to switch the MT signalling connections to the new BS (CONN_SWITCHED).

Title: MSCDIAGRAM Forward HO Creator: (SDT 3.0) CreationDate: (Thu Oct 09 14:39:10 1997)

The separation of switching phases enables the reuse of the same algorithm for the forward and backward HO cases. The HO_REQUEST signal passes, as parameter, to the CSU, a list of all active data connections. This list is prioritised and serves in the case where not all connections can be supported by the new BS. Thus, partially successful handover can be accomplished (connections with lower priority are dropped during the handover, if the resources in the new BS prove insufficient).

Figure 8 - MSC for the Forward Handover procedure When the signalling channels’ re-routing is completed, CS_MMC informs the MT on the restoration of the signalling communication (SIG_CHANNEL_READY). Then the MT can initiate the re-routing (HO_REQUEST) of the data connections. The handshaking between CS_MMC and MT_MMC using the signal SIG_CHANNEL_READY is necessary in order to avoid potential race hazards (e.g., attempts to transmit signalling information prior to the reconfiguration of the signalling connections). CS_MMC is also responsible for checking the availability of both the fixed (FR_STATUS) and the wireless (CHECK_RR_req/cnf) resources for the u-plane connections. Should the CAC algorithm prove successful, the data channels are switched to the new BS (CONN_SET, CONN_SWITCHED). At the old BS the relative resources are released (CONN_DROP, CONN_RELEASE). When the rerouting of the channels is completed, MT is notified on the result of the handover (HO_RESPONSE), and its new location is registered (LOC_UPDATE). In Figure 8 we provide the MSC of the forward handover algorithm2 . As shown in this figure the handover procedure is broken up into two distinct phases (A & B). Phase A involves the switching of the signalling connections while Phase B the switching of the data connections. 2

All operations are assumed to be successful.

VI. Conclusions In this paper, we have identified a problem encountered when designing mobility algorithms for wireless ATM CPN environments. This problem is mainly attributed to the incompatibility of conventional signalling with the peculiarities of a WATM installation. It refers to the required switching of the signalling connections during handover. In section IV, a solution has been proposed that has no impact on the existing ATM infrastructure. The implementation of this solution is quite straightforward. Furthermore, the mobility procedures related to handovers are broken into two major phases: the switching of the signalling connections and the switching of the data connections. The same signals can be applied in both cases with a different sequence. The solution is based on the management interfaces provided by contemporary ATM switches, since the re-routing of VCs is performed at the ATM level. Higher layer entities (e.g. MMC, RM) are left unaffected. We have shown how this switching approach can be applied in registration and forward handover. The algorithm performs channel switching in a specific order (depending on the HO type), and it involves handshaking between CS_MMC and MT_MMC to avoid potential race hazards. Acknowledgements Part of the work presented in this paper has been performed in the framework of the project ACTS AC085 The Magic WAND, which is partly funded by the European Community and the Swiss BBW (Bundesamt für Bildung und Wissenschaft). The authors would like to acknowledge the contributions of their colleagues from Nokia Mobile Phones, Tampere University of Technology, Technical Research Center of Finland, Ascom Tech AG, Lucent Technologies WCND, University of Lancaster, Robert BOSCH GmbH, University of Ulm, Compagnie IBM France, IBM Zürich Research Laboratory, ETH Zürich, INTRACOM Hellenic Telecommunications and the University of Athens. References

[1] P. Agrawal, E. Hyden, P. Krzyzanowski, P. Misthra, M. Srivastava and J. Trotter, SWAN: A mobile multimedia wireless network, IEEE Personal Communications, April 1996. [2] D. Raychaudhuri and N. Wilson, ATM Based Transport Architecture for Multiservices Wireless Personal Communication Networks, IEEE JSAC, October 1994.

[3] J. Mikkonen and J. Kruys, The Magic WAND: a [4] [5] [6]

[7] [8]

[9]

[10] [11]

[12] [13] [14]

[15]

[16] [17] [18] [19] [20]

wireless ATM access system, proceedings of the ACTS Mobile Summit '96. M. Veeraraghavan, M.J. Karol and K.Y. Eng, Mobility and Connection Management in a Wireless ATM LAN, IEEE JSAC, January 1997. B. Akyol and D. Cox, Signaling Alternatives in a Wireless ATM Network, IEEE JSAC, January 1997. A.S. Acampora , M. Naghshineh, An Architecture and methodology for mobile executed cell hand-off in wireless ATM networks, IEEE JSAC, October 1994. C. Toh, The Design and implementation of a Hybrid Handover Protocol for Multimedia Wireless LANs, proceedings of Mobicom’95, November 1995. H. Hansén, S. Hadjiefthymiades, J. Immonen and A. Kaloxylos, Description of the handover algorithm for the Wireless ATM Network Demonstrator (WAND), proceedings of the ACTS Mobile Summit '96. A. Kaloxylos and S. Hadjiefthymiades, Mobility Management in the Wireless ATM Network Demonstrator, proceedings of the International Workshop on Mobile Communications 1996 (IWMC’96). ................................. ITU-T Recommendation Q.2931, B-ISDN Digital Subscriber Signaling System No 2 (DSS2) (UNI), Layer 3 Specification for Basic Call/Connection Control, 1995. ATM Forum, User-Network Interface (UNI) Specification 3.1. ............................ ITU-T Recommendation Q.2130, B-ISDN Signaling ATM Adaptation Layer - Service Specific Coordination Function for Support of Signaling at the Userto-Network Interface (SSCF at UNI), 1994. F. Bauchot, G. Marmigere, L. Merakos, N. Passas and S. Decrauzat, MASCARA, A MAC protocol for Wireless ATM, proceedings of the ACTS Mobile Summit '96. ITU-T Recommendation Z.120, Message Sequence Chart (MSC), 1993. B. Stiller, A Survey of UNI Signaling Systems and Protocols for ATM Networks, Computer Communication Review, ACM SIGCOMM, April 1995. ITU-T Recommendation Q.2110, B-ISDN - ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP), 1994. A. Kaloxylos, S. Hadjiefthymiades, The Magic WAND, CEC Deliverable 4D6, Mobility Management and Control Module, September 1996. P. Newman et al, Ipsilon's General Switch Management Protocol Specification - Version 1.1, RFC 1987, August 1996.

Suggest Documents