external ho b5

EXTERNAL HANDOVERED 02 RELEASED

MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 1/4

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Site

VELIZY MOBILE COMMUNICATION DIVISION

Originator(s)

S. SAADA

EXTERNAL HANDOVER

RELEASE 5

Domain : ALCATEL 900/BSSDivision : PRODUCT DEFINITIONRubric : SYS-TLAType : SYSTEM FUNCTIONAL BLOCKSDistribution Codes Internal : External :

PREDISTRIBUTION:

MCD VELIZY MCD KONTICHM. Roberts TD/SAS M. Delprat TD/BTS G. Van Dijck (ffd)E. Desorbay TD/SAS M. Dobrosielski TD/BTSL. Cruchant TD/SAS JL. Lekmouli TD/IIVP. Fouilland TD/SAS A. Pech TD/IIVJJ. Roy TD/SAS SSD VELIZYA. Barnel (ffd) TD/SAS J. MessietJF. Mailllard TD/SASM. Tuchendler (fpo) SSD STUTTGARTD. Berthoumieux(fpo)

P. Hupperich

J.P. Georges (fpo) W. Allerborn

PREDISTRIBUTION: DOC. CENTRES

MCD VELIZY MCD ANTWERP MCD STUTTGARTB. Marliac L. Van Eyck I. Lentzsch

ABSTRACT

This document describes the protocol for the execution of the External Handover procedure asperformed by the BSS.Note the following handover types are not implemented in this release of the ALCATEL BSS:

External Pseudo-synchronousExternal Pre-synchronous

ApprovalsName

App.

D. BERTHOUMIEUXAM

M. ROELANDTSSSAM BSC

M. DELPRATSSAM BTS/SW


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 2/4

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

REVIEW

Not applicable

HISTORY

Release 1 :

Version Date Author Reason for update

1.1.0.0 29/04/91 K. Wong RSG approved version for Phase 1

Release 2 : S/P2/3.4.1.2.2


2.0.0.0 15/03/92 M. Roberts Initial issue for Phase 2

2.0.0.1 22/06/92 M. Roberts Reviewed & corrected see Minutes TLA/132

2.0.1.0 28/12/92 M. Roberts Reviewed & corrected see Minutes TLA/141

2.1.0.0 15/03/93 M. Roberts Reviewed & corrected see Minutes RSG/157SG approved version

Release 3 : 3BK 11202 0006 DSZZA


3.0.0.0 17/12/93 M. Roberts Initial draft of Release 3. Contains CRQ/287 & CRQ/292

3.0.0.1 24/02/94 M. Roberts Updated inaccordance with the minutes TLA/171

3.0.0.2 06/04/94 M. Roberts Updated in accordance to SYS/022

3.1.0.0 18/05/94 M. Roberts Updated in accordance to SYS/051



4.0.0.0 07/11/94 B. Szelazek First draft for release 4

4.0.0.1 15/12/94 B. SZELAZEK Updated after TLA review#4. See SYS/011




4.1.0.0 03/02/95 B. SZELAZEK Updated after TLA review#9bis. SeeSDEF/95/ReportTLA44#9bis.Includes R3 CRQs 803 & 1127

4.1.0.1 03/04/94 B. SZELAZEK Inclusion of minimal support for half rate

4.2.0.0 22/05/95 B. SZELAZEK Updated after mail review. Includes R3 CRQs 940 & 1269 &R4 CRQ 895.

4.3.0.0 16/11/95 S. SAADA Include CRQ 1604




MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 3/4

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Ed 1 In Preparation 1 21/03/96 S. SAADA First draft for release 5.Includes R4 CRQs 1425, 1543, 1789, 2141

Ed 1 Proposal P1 26/04/96 S. SAADA Updated afted internal review TLAr5#9. -TD/SAS/LC/746.96Includes R4 CRQ 1750.

Ed 1 Proposal R1 24/05/96 S. SAADA Updated after TLAr5#11. -TD/SAS/LCR/966.96

Ed 1 Released 19/07/96 S.SAADA Updated according to TLAr5#14 andTLAr5#15. - TD/SAS/lcr/1284.96 -TD/SAS/lcr/1377.96

Ed 2 released 13/02/98 S. SAADA Includes CRs 15196, 15198, 15200, 19689,19696, 27692, 29115.Document checked by moderator E.Desorbay. No review report.

INTERNAL REFERENCED DOCUMENTS

Not applicable

FOR INTERNAL USE ONLY

Not applicable

OPEN POINTS

Not applicable

FUTURE IMPROVEMENTS

Internal Handover, External Handover BSSMAP & DTAP Messages

This section details improvements between the internal and external handover procedures when aninternal handover has failed, the next cell in the list is external and there are queued BSSMAP/DTAPmessages. The following BSSMAP messages are considered :

1. CIPHER MODE COMMAND

2. ASSIGNMENT REQUEST

The actions that should be performed by the serving BSC before sending the HANDOVERREQUIRED message to the MSC for the external handover are shown in the following table.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 4/4

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Queued Message Action

CIPHER MODE COMMAND See note

ASSIGNMENT REQUEST (SDCCH->TCHor TCH->SDCCH)

Send ASSIGNMENT FAILURE cause = No radioresource available

ASSIGNMENT REQUEST (In callmodification)

Send ASSIGNMENT FAILURE, cause = Reversionto old channel

DTAP Messages Send DTAP messages to MS

Interactions IHO-EHO-BSSMAP & DTAP

Note :

There are two possibilities for improvements between the internal and external handover procedureswhen an internal handover has failed, the next cell in the list is external and there is a queuedCIPHER MODE COMMAND - see below.

Queued Message Action 1 Action 2

CIPHER MODE COMMAND Allow Cipher command tocomplete before triggeringexternal handover.

Send CIPHER MODEREJECT

Possible Actions of Queued CIPHER MODE COMMAND

Use of N_PREF_CELL/CLOLD in MS Failed Handovers

This release does not implement the new optional information element "Cell Identifier" sent to theserving BSC in the HANDOVER COMMAND message, informing it of the target cell selected by theMSC, (see GSM 08.08 AR A002r2). This method of identifying the target cell is preferable to usingthe only cell in CLOLD when N_PREF_CELL = 1 since it allows the filtering of cells in theMS_CELL_REJ_LIST to be used when N_PREF_CELL >1.

END OF DOCUMENT


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 1/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

SYSTEM FUNCTIONAL BLOCKS

TABLE OF CONTENTS

HISTORY ..................................................................................................................................................4

REFERENCED DOCUMENTS ..................................................................................................................4GSM References .......................................................................................................................................4Alcatel References.....................................................................................................................................4Other References ......................................................................................................................................5

RELATED DOCUMENTS..........................................................................................................................5

PREFACE .................................................................................................................................................5

1. - Scope .................................................................................................................................................6

2. - FUNCTIONAL DESCRIPTION ............................................................................................................72.1. - General description...........................................................................................................................72.1.1. - Handover Behaviour ......................................................................................................................72.1.2. - Handover Behaviour on Failure .....................................................................................................82.2. - ALCATEL BSS support for outgoing external handovers...................................................................92.3. - ALCATEL BSS support for incoming handovers ...............................................................................92.3.1. - External Handover Test Call Functionality .....................................................................................92.4. - ALCATEL BSS support for Phase 1 MS capabilities .........................................................................102.5. - ALCATEL BSS support for Phase 2 MS capabilities .........................................................................102.6. - External Handover Entities ...............................................................................................................10

3. - DYNAMIC BEHAVIOUR......................................................................................................................123.1. - General Behaviour............................................................................................................................123.1.1. - Successful External Asynchronous Handover ................................................................................123.1.2. - Successful External Synchronous Handover..................................................................................163.1.3.Target Cell Negotiation .....................................................................................................................183.1.3.1. - Repeated Handover Attempts .....................................................................................................183.1.3.2. - MSC Rejection of Cell List ..........................................................................................................193.1.3.2.1. - BSC Reaction to HANDOVER REQUIRED REJECT................................................................193.1.3.2.2. - MSC Does Not Send HANDOVER REQUIRED REJECT.........................................................213.1.4. - Unsuccessful External Handover ...................................................................................................213.1.4.1. - MS Handover Failure ..................................................................................................................223.1.5. - Serving BSC Protocol Failures.......................................................................................................25


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 2/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.1.5.1. - T_HO_REQ_LOST Expiry ..........................................................................................................253.1.5.2. - T8 Expiry ....................................................................................................................................273.1.6. - Target BSC Protocol Failures ........................................................................................................273.1.6.1. - T9103 Expiry ..............................................................................................................................283.1.6.2. - T9113 Expiry ..............................................................................................................................283.1.6.3. - Channel Activation Nack .............................................................................................................293.1.6.4. - Connection Failure Indication (Cause "Handover Access Failure")..............................................303.1.7. - Target BTS Protocol Failures.........................................................................................................303.1.7.1. - T3106 Expiry & Connection Failure Indication (Cause "Handover Access Failure")Synchronous Handover..............................................................................................................................303.1.7.2. - T3105 Expiry & Connection Failure Indication (Cause "Handover Access Failure")Asynchronous Handover............................................................................................................................323.2. - Detailed Behaviour ...........................................................................................................................353.2.1. - Serving BTS Protocol ....................................................................................................................353.2.2. - Serving BSC Protocol ....................................................................................................................353.2.2.1. - External Handover Decision........................................................................................................353.2.2.1.1. - General Rules..........................................................................................................................353.2.2.1.2. - External Handover Decision For SDCCH Transactions ............................................................353.2.2.1.3. - SDCCH External Handover Decision After Immediate Assignment ..........................................353.2.2.1.4. - SDCCH External Handover Decision ( After Normal Assignment) ............................................363.2.2.1.5. - External Handover Decision For TCH Transactions .................................................................363.2.2.2. - Serving BSC External Handover Protocol ...................................................................................373.2.2.2.1. - NULL State behaviour..............................................................................................................403.2.2.2.2. - Normal Events .........................................................................................................................413.2.2.2.3. - Unexpected Events..................................................................................................................443.2.2.2.4. - Events from BTS .....................................................................................................................473.2.2.2.5. - DTAP and BSSMAP procedures ..............................................................................................503.2.2.2.6. - HANDOVER REQUIRED message building.............................................................................503.2.3. - MSC Handover Protocol ................................................................................................. ...............513.2.4. - Target BSC External Handover Protocol ........................................................................................513.2.4.1. - SCCP Connection Establishment................................................................................................583.2.4.2. - SCCP Connection Failure ...........................................................................................................603.2.4.3. - Target BSS errors.......................................................................................................................613.2.4.4. - Target BSS error BLOCK message is sent..................................................................................623.2.4.5. - Target BSS error UNEQUIPPED CIRCUIT message is sent .......................................................633.2.4.6. - HANDOVER REQUEST message processing.............................................................................643.2.4.6.1. - Detection of incoming external directed retry ...........................................................................683.2.4.7. - CHANNEL ACTIVATION message construction..........................................................................693.2.4.8. - HANDOVER REQUEST ACK message construction ..................................................................713.2.4.9. - Layer 3 IE HANDOVER COMMAND message construction........................................................723.2.4.10. - CHANNEL MODE MODIFY message construction....................................................................753.2.4.11. - DTAP & BSMAP procedures in the Target BSS ........................................................................763.2.5. - Target BTS Asynchronous Handover Protocol ...............................................................................763.2.6. - Target BTS Synchronous Handover Protocol.................................................................................793.2.6.1. BTS CHANNEL ACTIVATION message checking.........................................................................81


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 3/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.2.7. - MS Handover Protocol...................................................................................................................813.2.7.1. - Measurement Reporting..............................................................................................................813.2.7.2. - Synchronous & Asynchronous Handover Procedure....................................................................823.2.7.3. - Releasing From The Old Channel & Serving Cell........................................................................823.2.7.4. - Attaching To The Target Cell ......................................................................................................823.2.7.5. - Attaching To The New Channel...................................................................................................833.2.7.6. - Reattaching to the Serving Cell...................................................................................................843.2.7.7. - Reattaching to the Old Channel ..................................................................................................843.3. - Interaction Between Other Procedures..............................................................................................853.3.1.- External Handover & Ciphering Procedures....................................................................................853.3.2. - Internal Handover, External Handover BSSMAP & DTAP Messages .............................................853.3.3. - External Handover & Internal Handover Procedures ......................................................................863.3.3.1. - Serving BSC ...............................................................................................................................863.3.3.1.1. - Internal Handover after External Handover ..............................................................................863.3.3.2. - Target BSC.................................................................................................................................893.3.3.2.1. - Subsequent Internal handover after successful External Handover for Phase 1 MSs ...............893.3.3.2.2. - Subsequent Internal handover after successful External Handover for Phase 2 MSs ...............893.3.4. - External SDCCH Or TCH Handover & Assignment Procedures .....................................................903.3.5. - External Handover & Trace............................................................................................................903.3.6. - External Handover & MS And BS Power Control ...........................................................................903.3.6.1. - Serving BSC during External Handover ......................................................................................903.3.6.2. - Target BSC during External Handover ........................................................................................903.3.7. - Handover algorithm & External Handover protocol ........................................................................90

4. - INTERFACE DESCRIPTIONS ............................................................................................................944.1. - GSM interfaces / Physical interfaces.................................................................................................944.2. - Internal interfaces .............................................................................................................................964.3. - Timer list ..........................................................................................................................................964.4.- Parameter list ....................................................................................................................................98

5. - Release 2, 3 & 4, 5Changes...............................................................................................................101

6. - FEATURES.........................................................................................................................................103

Glossary...................................................................................................................................................105

02 13/02/98 MCD/TD/ MCD/TD/SAS

01 19/07/96 MCD/TD/ MCD/TD/SAS

ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 4/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

HISTORY

Ed. 01 19/07/96

Ed 02 13/02/98

REFERENCED DOCUMENTS

GSM References

[1] GSM TS 04.04

[2] GSM TS 04.08 - Mobile Radio Interface Layer 3 specification

[3] GSM TS 08.08 - MSC-BSS Interface Layer 3 specification

[4] GSM TS 08.58 - BSC to BTS Layer 3 specification

[5] GSM TS 03.09 - Handover Procedures

[18] GSM TS 09.94 - Recommended infrastructure measures to overcome specific phase 1 mobilestations faults.

Version numbers of the GSM Technical Specifications to be used in this release are given in ref [19]

Alcatel References

[6] Call Release 3BK 11202 0102 DSZZA

[7] Internal Handover 3BK 11202 0103 DSZZA

[8] Handover Preparation 3BK 11202 0111 DSZZA

[9] Dedicated Radio Resource Control 3BK 11202 0112 DSZZA

[10] Normal Assignment Procedure 3BK 11202 0100 DSZZA

[11] Blocking, Reset Circuit & Unequipped Circuit 3BK 11202 0072 DSZZA

[12] Radio Measurements 3BK 11202 0063 DSZZA

[13] Short Message Service Point To Point 3BK 11202 0062 DSZZA

[14] Ciphering Procedure 3BK 11202 0101 DSZZA

[15] Application Document 08.08 3BK 11202 0125 DSZZA

[16] Classmark handling 3BK 11202 0106 DSZZA

[17] System Information Management 3BK 11202 0130 DSZZA

[19] Alcatel BSS application document to GSM -General overview 3BK 11203 0012 DSZZA

[20] DTX functional specification 3BK 11202 0109 DSZZA

[21] Frequency encoding algorithm 3BK 11202 0115 DSZZA

[22] LAPDm functional specification 3BK 11202 0128 DSZZA

EX

TE

RN

AL

HA

ND

OV

ER

ED

02 R

EL

EA

SE

D

MC

D41.D

OC

16/02/98 10:12

3BK

11202 0104 DS

ZZ

A5/108

All rights reserved. Passing on and copying of this document, use and communication of its contents

not permitted without written authorization from AlcatelT

EL

EC

OM

Oth

er Referen

ces

None

RE

LA

TE

D D

OC

UM

EN

TS

None

PR

EF

AC

E

Not applicable


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 6/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

1. - Scope

This document specifies the following External Synchronous & Asynchronous inter-cell handoverprotocol for the ALCATEL BSS.

ˆ External TCH handover;

ˆ External SDCCH handover

Note External Pseudo-synchronous & External Pre-synchronised handovers are not a featurefor this release of the ALCATEL BSS.

The Call release & Resource release scenarios which occur as a result of failures in the protocol arespecified in ref [6].

The cause values in the HANDOVER FAILURE messages are also specified in ref [6].

The referencing of events in ref [6] are provided by means of the reference and an event numberwithin ref [6]. The event number takes the form of 1 to 4 character string followed by 4 numbers - egref [6] EHT0100 or ref [6] N0200. These event numbers are to be found in ref [6] together with theCall Releasing or Resource releasing scenario if applicable.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 7/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

2. - FUNCTIONAL DESCRIPTION

2.1. - General description

To maintain the quality of service on a radio connection it may become necessary to change thechannel in the same cell, or to another cell. There are many reasons that a change of cell or channelis needed, interference, distance, signal strength etc. The process of changing the channel is calledHandover. When the change is controlled by the MSC it is known as an External Handover, whencontrolled by the same BSC it is known as Internal Handover. The change can be to a channel in thesame cell or a channel in another cell.

When a handover is required the BSS decides which type of handover is to be performed, eitherinternal or external. When an external handover is required a handover alarm accompanied by a celllist is presented to the external handover protocol by Dedicated Radio Resource in response to ahandover alarm generated by the Power Control and Handover Algorithm (ref [8]). Ref [9] describesthe handover decision process and how the candidate cells list is filtered.

The external handover protocol function is specified in this document.

Two types of external handover are possible in a GSM system, they are:

• Intra MSC external handover - a handover performed between cells controlled by the sameMSC.

• Inter MSC external handover - a handover performed between cells controlled by differentMSC’s.

There is no difference in behaviour of the Alcatel BSS for either the inter or intra MSC externalhandover, and thus there is no differentiation between these in this document.

It is possible to obtain an external synchronous handover as the target BSS checks to see if theserving and target cell are synchronised. If the serving cell is not controlled by the target BSC thenan asynchronous handover is performed.

The handover is performed between the serving and target BSCs via the MSC. The messages on theA, Abis and air interfaces are specified in Refs [2] , [3], and [4].

When the external handover is triggered the BSC regularly reports new candidate cells to the MSC inorder to provide it with accurate cells for the handover attempt.

2.1.1. - Handover Behaviour

The function of the external handover protocol is to handover an MS from one BSS, (the servingBSS), to another BSS (the target BSS), under control of the MSC. This is done by providing the MSCa list of cells which the serving BSS believes are good candidates for the handover procedure basedon the radio measurements made by the MS.

When the handover algorithm signals that a handover is necessary (handover alarm), the candidatecells filter and handover decision functionality in the dedicated radio resource control procedureprocesses the cell list accompanying the handover alarm and determines the type of handoverrequired, (see ref [9]).

If an external handover is required the list is presented to the handover protocol and a handover istriggered by sending the MSC a HANDOVER REQUIRED message containing the cells presented.The list of cells is remembered by the BSC as CLOLD. If a further handover alarm is received beforethe MSC responds to the HANDOVER REQUIRED message the list presented to the externalhandover protocol is checked to ascertain whether a new cell is in the list or an old cell is no longer inthe list. If either of these occurs then another HANDOVER REQUIRED message is sent to the MSC,keeping it up to date with the best cells for the handover. The new list replaces CLOLD. If, however,only the order of the cells in the list is different, no further HANDOVER REQUIRED message is sent.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 8/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

As an operator option the HANDOVER REQUIRED message may be sent with the OIE RESPONSEREQUEST. The presence of this OIE requests the MSC to respond to the serving BSS with aHANDOVER REQUIRED REJECT message if the MSC cannot service the request for whateverreason.

Timers are used to supervise the handover procedure by :

• Guarding against a non-response from the MSC, (T_HO_REQ_LOST)

• Guarding against overloading the MSC with repeated handovers (T7).

• Guarding against repeatedly sending a cell to which the MS has failed to handover to(T_MS_CELL_REJ)

The external handover protocol supports two additional lists that are used by the candidate cells filter,the REJ_CELL_LIST and the MS_CELL_REJ_LIST. The details are described below.

If the MSC cannot perform a handover to any of the cells presented by the BSC and returns aHANDOVER REQUIRED REJECT message, all cells that were sent to the MSC in the lastHANDOVER REQUIRED message are transferred from the CLOLD list to the REJ_CELL_LIST. Whensubsequent handover alarms are received, any cells in the cell list accompanying the handover alarmwhich are also in the REJ_CELL_LIST cannot be used as candidate cells in external handoverattempts on the same connection. The REJ_CELL_LIST is emptied only on the expiry of timer T7 orat the end of the external handover procedure.

If the MSC does not send a HANDOVER REQUIRED REJECT message no further HANDOVERREQUIRED messages are allowed to be sent to the MSC until timer T7 expires or radio conditionschange. In the case where HANDOVER REQUIRED messages are sent at the rate of T7, thisprevents the MSC being overloaded.

When the MSC chooses one of the cells in the cell list CL with which to perform the handover, thetarget BSS is requested to allocate and activate a suitable channel to which the handover may occur.

For channel allocations where the MSC has in the initial ASSIGNMENT REQUEST specified a codepoint forbidding channel rate change for the channel, it is the MSC’s responsibility to ensure that thechannel specified in the HANDOVER REQUEST towards the target BSC is the same as allocated bythe initial BSC in the Chosen Channel OIE in the ASSIGNMENT COMPLETE message. Once thehandover has been performed it is the new BSC’s responsibility to ensure that no changes areallowed for subsequent internal handovers (see ref [9]).

Once the target BSS has successfully allocated the channel it passes back to the MSC the messagewhich will enable the MS to make the move to the activated channel. The MSC passes this to theserving BSS, which passes it to the MS.

The serving BSS now awaits the successful completion of the procedure.

The MS on reception of the handover message disconnects from the serving BSS (at Layer 1 & 2)switches to the assigned channels and initiates establishment of lower layer connections. The precisemethod of performing this is specified in ref [2] - GSM 04.08. Once communication is established withthe target BSS the MS signals a successful handover to the target BSS and the MSC initiates clearingof the old connections to the serving BSS. At the end of an external handover the appropriate SCCPconnections (in MSC and BSS) and RF channels (in BSS) are released.

2.1.2. - Handover Behaviour on Failure

The handover may be unsuccessful either because the MSC cannot perform a handover to any of thecells presented to it or the MS has difficulty in accessing the target cell.

If the MS has any difficulty either synchronising with the target BSS or accessing the new channel itcan return to the old channel of the serving cell and any call in progress will continue until the needfor another handover is detected whereupon the procedure is repeated. For the case whereN_PREF_CELL = 1, when this handover failure occurs, the serving BSC remembers the only cell in


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 9/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

list CLOLD in MS_CELL_REJ_LIST. When subsequent handover alarms are received, any cell in thecell list accompanying the handover alarm which is also in the MS_CELL_REJ_LIST cannot be usedas a candidate cell in external handover attempts on the same connection. The MS_CELL_REJ_LISTis emptied only on the expiry of timer T_MS_CELL_REJ or at the end of the external handoverprocedure.

Summary note: For this release MS_CELL_REJ_LIST is used only when N_PREF_CELL = 1 and thecell remembered is the best cell, ie the first in the list sent to the MSC in the HANDOVER REQUIREDmessage.

2.2. - ALCATEL BSS support for outgoing external handovers

External handovers are not triggered during the Assignment procedure or during the Queuing phase.

Outgoing handovers supported for this release of the ALCATEL BSS are shown in Table 2./1.

Serving BSS Channel type & modeChannel type Channel mode

SDCCHNote 2

Signalling Supported

TCH FR/HRNote 1

Signalling Not supported

TCH FR Speech or Data SupportedTCH HR Speech Supported

Table 2./1 Outgoing Handover Support

Note 1: The ALCATEL BSS does not support the allocation of TCH channels for signallingtransactions.

Note 2: SDCCH with Speech or Data is not specified in GSM.

2.3. - ALCATEL BSS support for incoming handovers

Any incoming handover for any channel configuration, speech, data or signalling can be handed overto a full rate speech or data channel.

Signalling on any traffic channel is not supported.

Handovers from SDCCH to SDCCH are supported.

Handovers from full rate to half rate traffic channels and vice versa are supported for speech calls.Handovers to half rate channels for data calls are not supported.

Handovers to traffic channels in the E-GSM band are supported for mobiles that support the E-GSMband.

Handovers between different speech versions (Full Rate version 1, Full Rate version 2, Half Rateversion 1) are supported.

2.3.1. - External Handover Test Call Functionality

The external handover procedure provides a facility allowing the inhibition of incoming handovers intoa cell. A flag EN_IC_HO, is provided on a per cell basis which when set true will allow all incomingintercell synchronous or asynchronous handovers into the cell.

It should be noted that internal intra cell handovers are not affected by this flag. Furthermore, whenEXT_HO_FORCED is set to true, (ie O & M is forcing external handovers), external handovers withthe same serving and target cell are allowed irrespective of the setting of the flag EN_IC_HO.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 10/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

2.4. - ALCATEL BSS support for Phase 1 MS capabilities

It is generally agreed in GSM (but not actually stated) that the SDCCH -> SDCCH asynchronoushandover for Phase 1 MSs is not guaranteed. This results from the setting of the MS timer (T3124)being made too short to ensure at least more than one reception of the PHYSICAL INFORMATIONmessage.

GSM Phase 1 MSs may support more than one Ciphering algorithm (A5/1 or/and A5/2) however aPhase 1 MS can not change Ciphering algorithm during channel changes or turn off ciphering. TheALCATEL BSS takes this behaviour into consideration when performing external handover andinternal handover (ref [7]).

The ALCATEL BSS never allows the stopping, starting or changing of the Ciphering algorithm duringChannel changes (ie external handover, internal handover (ref [7]) & Assignment (ref [10])) for Phase1 MSs. In this case the ALCATEL BSS will always activate Ciphering for a Phase 1 MS as indicatedby the MSC.

The ALCATEL BSS supports faulty phase 1 MS for directed retry, with respect to ref [18]

2.5. - ALCATEL BSS support for Phase 2 MS capabilities

Phase 2 MSs are able to support two handover types (which are not supported by this releaseALCATEL BSS) they are: pseudo-synchronous & pre-synchronous handovers.

A Phase 2 MS may support more than one Ciphering algorithm and may stop or start Ciphering ascommanded by the Ciphering procedure (ref [14]).

A Phase 2 MS can be commanded to stop, start or change the Ciphering algorithm during channelchanges once ciphering has been initiated by the MSC. This type of behaviour in the MS allows theMS to be supported in a mixed Ciphering network.

The ALCATEL BSS ensures during external handover that the MS Ciphering capabilities, BTSCiphering capabilities & MSC Ciphering requirements are taken into account whilst performing theexternal handover procedure.

The ALCATEL BSS may command Phase 2 MSs to stop, start or change the Ciphering algorithmduring an external handover procedure depending on the MS Ciphering capabilities, BTS Cipheringcapabilities & MSC Ciphering requirements.

2.6. - External Handover Entities

The following entities are involved in the execution of an external handover:

MS Downlink measurement

The MS measures: the strength, quality and distance of the serving BSS and the strength of BCCHcarriers of neighbour cells. The neighbour cell list is sent to the MS in SYSTEM INFORMATIONTYPE 5 family messages on the SACCH. Measurements made by the MS are then transmitted to theserving BSS by use of MEASUREMENT REPORT messages sent on the SACCH - See Note 1. Onlysix neighbour cells can be reported by the MS

MS Handover protocol

The method of performing the handover protocol.

This protocol will be described in this document for completeness. The asynchronous andsynchronous protocol will be shown - See Note 1.

Serving BTS Uplink measurement

The BTS makes measurements on the strength and quality of the Uplink signal from the MS andreports it to the BSC handover algorithm together with the MS measurements - see ref [12].


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 11/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Serving BSC Handover algorithm

The BSS takes the measurements from the MS and the BTS and analyses whether it is necessary toperform a handover - ref [8].

When a handover is required a handover alarm is sent to the serving BSC handover protocol with alist of preferred cells.

The BSS handover algorithm controls the rate at which internal handover alarms are generated by theuse of the timer T_FILTER - See section "Interaction of handover algorithm & external handoverprotocol".

Serving BTS Handover protocol

The Serving BTS plays no active role in the handover protocol. Its main function is to relay messagesand events between the MS and the serving BSC (see section

5. - Release 2, 3 & 4, 5Changes).

Serving BSC Dedicated radio resource

This entity performs the first level filtering of cells for the handover process by removing cells fromthe candidate list that the MSC has previously rejected or that the MS has failed to handover to. Italso determines what type of handover is required.

Serving BSC Handover protocol

This entity initiates the handover attempt towards the MSC and also performs second level filtering ofcandidate cells for the handover process by removing cells from the candidate list that have alreadybeen sent to the MSC and rejected for this handover attempt. This document will specify the servingBSC external handover protocol.

MSC Handover protocol

The MSC chooses the target cell and performs the protocol with both serving and target BSC.

This document will describe, in general terms only, the protocol in the MSC for Intra MSC handover -See Note 1.

Target BTS Handover protocol

The target BTS controls the access of the MS to the new channel of the target BSC.

This document will specify the protocol to be performed. The asynchronous & synchronous protocolwill be specified.

Target BSC Handover protocol

The target BSC performs the handover protocol.

This document will specify the protocol to be performed.

Target BSC Dedicated radio resource

This entity verifies that the target cell can support the MS Ciphering capabilities, BTS Cipheringcapabilities, MSC Ciphering requirements and channel allocation in accordance with MSCrequirements.

Note 1An overview of MS & MSC functions will be given so as to aid the reader. Behaviour may deviate dueto implementation choices in the MS and MSC.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 12/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3. - DYNAMIC BEHAVIOUR

3.1. - General Behaviour

This section contains the successful and major failure cases of an external handover which consistmainly of errors due to timer expiry and GSM defined messages. No account is taken in this sectionof message protocol errors or internal system errors, these cases are dealt with in section 3.2. -Detailed Behaviour, where the checking and error handling is specified.

Only Air, Abis and A interface messages are used in the message sequence charts within this section.

When the BSS handover algorithm detects that a handover is required a list of cells is presented tothe handover protocol, all or some of which are sent to the MSC in a HANDOVER REQUIREDmessage. The maximum number of cells sent is determined by the rules defined in section 3.2.2.1. -External Handover Decision and the O & M parameter N_PREF_CELL.

3.1.1. - Successful External Asynchronous Handover

The following message sequence chart shows the scenario of a successful external asynchronoushandover for a serving BSS.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 13/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Fig 3./1 External Asynchronous Handover

Note A: Handover alarm

Note B: Call release scenario (This includes the stopping of timer T8).

Note C: In some cases, the Target BSC must trigger a classmark interrogation procedure. See ref[16]

1 The BSC handover algorithm raises an alarm to the BSC handover protocol and provides alist of candidate cells.

2 The BSC initiates an external handover by sending a HANDOVER REQUIRED message withcell list CL containing a maximum of N_PREF_CELLs obtained from the cell list reported in


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 14/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

the handover alarm.T7 is started to prevent the BSC from offering the same cell list CL to the MSC again tooquickly when the MSC does not send a HANDOVER REQUIRED REJECT message.T_HO_REQ_LOST is started to guard against no response from the MSC.

Note the HANDOVER REQUIRED message may contain the OIE RESPONSE REQUESTdepending on the O&M parameter RESP_REQ.

3 The MSC chooses one of the cells from cell list CL and identifies the target BSS. It thensends a HANDOVER REQUEST message to the target BSS and starts Trr2.

4 The target BSC activates an appropriate RF channel (4a & 4b), builds the HANDOVERCOMMAND message destined for the MS, sends it to the MSC in the HANDOVERREQUEST ACK and starts T9113 to supervise the handover.The target BTS starts sending dedicated system information messages on the SACCH (seeref [17]). The TA in the Layer 1 header shall indicate that the timing advance information isinvalid.

4a The target BTS: starts ciphering immediately (if applied).

4b For Phase 2 MSs the Ciphering used on the new channel may be different from the one usedon the old channel.

5 The MSC: stops Trr2; forwards the message to the serving BSS in a HANDOVERCOMMAND message; and starts T3103.

6 The serving BSC: stops T7 and T_HO_REQ_LOST, sends the HANDOVER COMMAND tothe MS via the BTS using the transparent message service (destined for the main DCCH),starts T8 & starts to ignore error messages from the BTS - see section on serving BSCdetailed behaviour.

7 The MS on reception of the HANDOVER COMMAND: disconnects off the old channel;synchronises to the new cell; sends continuously a HANDOVER ACCESS to the BTS (on themain DCCH of the RF channel indicated in the HANDOVER COMMAND message with a TAof 0); and starts T3124.The target BTS checks the handover reference and calculates the timing advance from thereception of the HANDOVER ACCESS, relays a HANDOVER DETECTION to the targetBSC and starts deciphering (if applied).The target BSC: relays a HANDOVER DETECT to the MSC and makes the switch path (TCHonly).

8 The target BTS: sends the PHYSICAL INFORMATION message to the MS with thecalculated timing advance. The timing advance algorithm is informed of the timing advance,the Layer 1 header in SACCH messages is updated with the timing advance value and timerT3105 is started.The MS stops T3124 and connects to the channel..

9 The MS establishes SAPI 0 with an SABM.The target BTS on reception of the SABM SAPI 0 or any correct frame stops T3105, (seeNote 9a ), sends an ESTABLISH INDICATION (SAPI 0) to the target BSC (only if SABMSAPI 0 is received), starts T_CFI_tr; sends a UA to the MS and starts BS and MS powercontrol if required and resynchronises system information messages (restarts at SYSTEMINFORMATION TYPE 5 message).

9a The target BTS may stop sending PHYSICAL INFORMATION and the timer T3105 when itreceives a correctly received frame - see ref [7]. The event that stops T3105 (ie SABM SAPI0 or any correct frame) is controlled by the O&M parameter STOP HO ACC FAIL.

10 The MS sends a HANDOVER COMPLETE message to the target BTS.The target BTS sends the message to the target BSC (it is a transparent message to theBTS).


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 15/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

The target BSC stops timer T9113 and forwards a HANDOVER COMPLETE message to theMSC.The MSC stops T3103. The external handover is now complete.If this is a directed retry to a Full Rate Channel allocated for speech version 1, for a phase 1MS (see 3.2.6.4.1); then CHANNEL MODE MODIFY message is sent to the MS. Thecorresponding CHANNEL MODE MODIFY ACK or CHANNEL MODE MODIFY NACK isdiscarded.

11 The serving BSS RF channel and terrestrial resources are released. This is performed by theMSC sending the CLEAR COMMAND (cause "Handover successful") - ref [6] EHS0400, T8 isstopped.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 16/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.1.2. - Successful External Synchronous Handover

The following message sequence chart shows the scenario of a successful external synchronoushandover for a BSS which controls both serving & target cells (BTSs) where the target & serving cellsare synchronised.

Fig 3./2 External Synchronous Handover

Note B: Handover alarm detected by BSC

Note C: Call release scenario with serving BTS

Note D: In some cases, the Target BSC must trigger a classmark interrogation procedure. See ref[16]


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 17/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM


2 The external handover is initiated by sending a HANDOVER REQUIRED message with celllist CL containing a maximum of N_PREF_CELLs obtained from the cell list reported in thehandover alarm.T7 is started to prevent the BSC from offering the same cell list CL to the MSC again tooquickly when the MSC does not send a HANDOVER REQUIRED REJECT message.T_HO_REQ_LOST is started to guard against no response from the MSC.

Note the HANDOVER REQUIRED message may contain the OIE RESPONSE REQUEST(this depends on the O&M parameter RESP_REQ).

3 The MSC chooses one of the cells within the cell list and identifies the target BSS. It thensends a HANDOVER REQUEST message to the BSS and starts Trr2.

4 The target BSC: checks the serving cell and target cell and finds that they are synchronised;activates an appropriate RF channel (see 4a & 4b); builds the HANDOVER COMMANDmessage (indicating synchronised handover) destined for the MS; sends it to the MSC in theHANDOVER REQUEST ACK; and starts T9113 to supervise the handover.

4a The Channel activation in this case has no timing advance information, as the information isnot available in the HANDOVER REQUEST message, therefore the target BTS: startsciphering immediately (if applied); SACCH transmission of dedicated system informationmessages is started immediately & any Layer 1 header sent to Air will indicate that the timingadvance information is invalid.In this case the MS uses the timing advance that was set on the old channel. until timingadvance is available on the new channel.

4b For Phase 2 MSs the Ciphering used on the new channel may be different from the one usedon the old channel.

5 The MSC: stops Trr2; forwards the message to the serving BSS in a HANDOVERCOMMAND message; and starts T3103.

6 The serving BSC: stops T7 and T_HO_REQ_LOST; sends the HANDOVER COMMAND tothe MS via the BTS using the transparent message service (destined for the main DCCH);starts T8; & starts to ignore error messages coming from the serving BTS - see section onserving BSC detailed behaviour.

7 The MS on reception of the HANDOVER COMMAND: disconnects from the old channel;synchronises to the new cell and sends four HANDOVER ACCESS (Timing advance 0) to theBTS (on the main DCCH of the RF channel indicated in the HANDOVER COMMANDmessage).The target BTS checks the handover reference and relays a HANDOVER DETECTION tothe target BSC and starts deciphering (if applied).The target BSC relays a HANDOVER DETECT to the MSC and makes the switch path (TCHonly).

8 The target BTS calculates the timing advance, the timing advance algorithm is informed ofthe new timing advance, the Layer 1 header is set accordingly and timer T3106 is started.

9 The MS establishes SAPI 0 with an SABM


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 18/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

The target BTS: stops T3106 - see Note 9a, sends an ESTABLISH INDICATION (SAPI 0) tothe target BSC (only if SABM SAPI 0 is received), starts T_CFI_tr, sends a UA to the MS andstarts BS and MS power control if required and resynchronises system information messages(restarts at SYSTEM INFORMATION TYPE 5 message)..

9a The target BTS may stop the timer T3106 when it receives a correctly received SABM SAPI 0or any correct frame - see ref [7].

10 The MS sends a HANDOVER COMPLETE message to the target BTS.The target BTS sends the message to the target BSC (it is a transparent message to theBTS).The target BSC stops timer T9113 and forwards a HANDOVER COMPLETE message to theMSC.The MSC stops T3103. The external handover is now complete.If this is a directed retry to a Full Rate Channel allocated for speech version 1, for a phase 1MS (see 3.2.6.4.1), then CHANNEL MODE MODIFY message is sent to the MS. Thecorresponding CHANNEL MODE MODIFY ACK or CHANNEL MODE MODIFY NACK isdiscarded.

11 The serving BSS RF channel and terrestrial resources are released. This is performed by theMSC sending the CLEAR COMMAND (cause "Handover successful") - ref [6] EHS0400.

3.1.3.Target Cell Negotiation

3.1.3.1. - Repeated Handover Attempts

In an environment where the handover alarm is reporting new cells as candidates for the handover (orcells that were reported in the last handover alarm are no longer present) the BSC has to update theMSC with the new cell list in order that the MSC is kept up to date and best cell is chosen for thehandover. If the cells do not change then there is no need for the BSC to repeat the handoverattempt until timer T7 expires, (see section 3.1.3.2. - MSC Rejection of Cell List and section 3.2.2.1.1.- General Rules. The following message sequence chart shows the BSC sending repeatedHANDOVER REQUIRED messages to the MSC, each with a new cell list.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 19/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM


2 The cell list presented with the handover alarm is processed and a cell list CL1 (maximum ofN_PREF_CELLs) is sent with the HANDOVER REQUIRED message. The cell list isremembered as CLOLD. Timers T7 and T_HO_REQ_LOST are started.

3 Before the MSC has responded to this handover attempt another handover alarm is receivedat the BSC with different cell information. The BSC sends a further HANDOVER REQUIREDmessage to the MSC with cell list CL2 (maximum of N_PREF_CELLs). CLOLD is replaced bythe contents of CL2 and T7 is restarted.

3.1.3.2. - MSC Rejection of Cell List

If the MSC cannot perform a handover to any of the cells given in the HANDOVER REQUIREDmessage it may :

• Explicitly reject the cell list by sending a HANDOVER REQUIRED REJECT message

• Implicitly reject the cell list by not sending a HANDOVER REQUIRED REJECT message

The sending of this message may be requested by the serving BSC including the OIE RESPONSEREQUEST in the HANDOVER REQUIRED message. The inclusion of this OIE is an operator optioncontrolled by the O & M parameter RESP_REQ. The presence of the OIE requests the MSC torespond to the serving BSS with the HANDOVER REQUIRED REJECT message if the MSC cannotservice the request for whatever reason. The inclusion of this OIE is described in the sectionHANDOVER REQUIRED message construction.

Timer T7 is fundamental to the operation of the external handover procedure when the MSC cannotperform a handover to any of the cells offered in the HANDOVER REQUIRED message and thebehaviour of the BSC in offering alternative cells depends on whether the MSC sends theHANDOVER REQUIRED REJECT message or not.

T7 controls the rate at which a HANDOVER REQUIRED message, containing the same sentcandidate cell, is sent to the MSC. When HANDOVER REQUIRED REJECT is received it alsodetermines when internal handovers may be enabled.

T7 is started after a HANDOVER REQUIRED message is sent to the MSC and stopped when :

• A HANDOVER COMMAND is received from the MSC (see section 3.1.2. - Successful ExternalSynchronous Handover)

• T_HO_REQ_LOST expires (see section 3.1.5.1. - T_HO_REQ_LOST Expiry).

T7 is restarted (ie stopped and then started again), when a new cell list, CL, has been built and sent tothe MSC in a new HANDOVER REQUIRED message

The following scenarios illustrate T7 functionality both when a HANDOVER REQUIRED REJECT isreceived and when it is not. The interactions between the internal and external handover proceduresare shown in section 3.3.3.1.1. - Internal Handover after External Handover.

3.1.3.2.1. - BSC Reaction to HANDOVER REQUIRED REJECT

This message is accepted independently of the presence of the response request IE in theHANDOVER REQUIRED message.

When the HANDOVER REQUIRED REJECT message is received the BSS cannot offer any cells inthe REJ_CELL_LIST in subsequent HANDOVER REQUIRED messages until T7 expires. Afterreceiving any further handover alarm, it may offer alternative cells, if any are available after the celllist received has been filtered. If none is available then no HANDOVER REQUIRED message can besent. The cell list that was sent to the MSC and rejected is held in a circular buffer REJ_CELL_LIST.The size of this buffer is 2*N_PREF_CELL max.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 20/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Fig 3./3 HANDOVER REQUIRED REJECT Sent by MSC

Note A: Initial handover alarm that starts the external handover, cell list 1

Note B: Subsequent handover alarm that causes no handover,

Note C: subsequent handover alarm that continues the external handover, cell list 2

1 The serving BSC detects the need for an external handover and sends a HANDOVERREQUIRED message (in this example with OIE RESPONSE REQUEST) and a list of cells(CL1), obtained from the handover alarm. T7 and T_HO_REQ_LOST are started. Internalhandovers are now disabled. The maximum number of cells sent in the message iscontrolled by the O & M parameter N_PREF_CELL. The cell list CL1 is remembered by theBSC as CLOLD.

2 A further handover alarm is received but the cell information has not changed (eg the MS hasnot moved location). Consequently no HANDOVER REQUIRED message is sent to theMSC.

3 The MSC cannot service the handover request and sends a HANDOVER REQUIREDREJECT message. On reception of the HANDOVER REQUIRED REJECT the BSC stopsT_HO_REQ_LOST. The cells sent in the last HANDOVER REQUIRED message, (CLOLD),are added to the REJ_CELL_LIST and cannot be used in subsequent external handoverrequests until timer T7 expires, see section 3.3.3.1.1. - Internal Handover after ExternalHandover. CLOLD is now forgotten.

4 Another handover alarm is reported and any cells in this handover alarm which are in theREJ_CELL_LIST or MS_CELL_REJ_LIST are not used in the next handover attempt. Thecell list CL2, to be used is built (see section 3.2.2.1. - External Handover Decision).

5 A further HANDOVER REQUIRED message with OIE RESPONSE REQUEST and containingcell list CL2 is sent to the MSC. T_HO_REQ_LOST is started and T7 restarted. .The cell listCL2 is now remembered by the BSC as CLOLD. This sequence of events is repeated untilthe handover succeeds, T7 or T_HO_REQ_LOST expires - see sections 3.3.3.1.1. - InternalHandover after External Handover, and 3.1.5.1. - T_HO_REQ_LOST Expiry.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 21/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.1.3.2.2. - MSC Does Not Send HANDOVER REQUIRED REJECT

If the MSC does not send a HANDOVER REQUIRED REJECT message within the time period T7,the cells are not remembered by the BSC but may be used again, (if they are presented in thehandover alarm).

Fig 3./4 HANDOVER REQUIRED REJECT Not Sent by MSC

Note A: Handover alarms that cause an external handover

1 The serving BSC detects the need for an external handover and sends a HANDOVERREQUIRED message with a list of cells (CL1), obtained from the handover alarm. T7 andT_HO_REQ_LOST are started. The maximum number of cells sent in the message iscontrolled by the O & M parameter N_PREF_CELL. The cell list CL1 is remembered by theBSC as CLOLD.

2 The MSC cannot perform a handover to any of the cells in CL1 and does not send aHANDOVER REQUIRED REJECT message to the BSC. T7 and T_HO_REQ_LOSTcontinue to run.

3 Subsequent handover alarms are received but the cells have not changed (eg the MS has notmoved location). Consequently no HANDOVER REQUIRED messages are sent to the MSC.

4 Timer T7 expires. Internal handovers will only be enabled in this case whenT_HO_REQ_LOST expires (see section 3.1.5.1. - T_HO_REQ_LOST Expiry).

5 A handover alarm occurs with the same cells as before. A HANDOVER REQUIREDmessage containing cell list CL2 is sent to the MSC. T7 is started and the cell list CL2 is nowremembered by the BSC as CLOLD. This sequence of events is repeated until the handoversucceeds or T_HO_REQ_LOST expires - see section 3.1.5.1. - T_HO_REQ_LOST Expiry.

3.1.4. - Unsuccessful External Handover

This section presents two types of unsuccessful external handover where :

1. the MS is unable to perform the handover


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 22/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

2. the MSC fails to respond to the handover request.

3.1.4.1. - MS Handover Failure

The MS may be unable to perform the handover for the following reasons:

1. Inability to find, or synchronise to the new cell (asynchronous handover);

2. Detection that the Timing advance on the new channel is out of range, (phase 2 MS only)

3. T3124 expiry (asynchronous handover, due to non reception of the PHYSICAL INFORMATIONmessage after sending the HANDOVER ACCESS);

4. Failure to receive the UA when attempting to establish the channel, or any layer 2 or layer 1failure.

5. Layer 3 failure (ie protocol error).

In the first four cases the MS returns to the serving cell re-establishes the Layer 2 connection andsends the HANDOVER FAILURE. If N_PREF_CELL = 1 the BSC adds the only cell in CLOLD toMS_CELL_REJ_LIST when the HANDOVER FAILURE is received and starts timerT_MS_CELL_REJ.

In the case 5 it has been found in the field that the MS may choose to do a combination of thefollowing:

• Send an RR STATUS message

• Send a HANDOVER FAILURE message without establishing Layer 2 LAPDm beforehand.

In the first case the ALCATEL BSS ignores the RR STATUS message and the call will be cleared.

In the second case the ALCATEL BSS sends HANDOVER FAILURE cause "Radio interface failure,reversion to old channel" the cause sent by the MS will be included in the HANDOVER FAILUREmessage.

If the MS sends both RR STATUS and HANDOVER FAILURE then the behaviour of the ALCATELBSS is as per the HANDOVER FAILURE case.

In the case where the MS can detect that the handover cannot be performed, (eg timing advance outof range or channel mode unacceptable), then it can send a HANDOVER FAILURE on the oldchannel without attempting the handover access to the target BSS. In these cases prior re-establishment of the lower layer is unnecessary.

The message sequence chart shown below shows the scenario for the reception of HANDOVERFAILURE.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 23/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Fig 3./5 MS Handover Failure

Note A: MS detects a problem with the new cell or RF channel

Note B: Call release scenario of the target BSS

1 The MS having detected a problem sends SABM on the old channel. The serving BTSreturns UA and sends an ESTABLISH INDICATION SAPI 0 to the BSC. The serving BSChas no external reaction to the ESTABLISH INDICATION of SAPI 0. A phase 2 MS maysend HANDOVER FAILURE without detaching. This results in no EST IND being sent beforethe HANDOVER FAILURE.

2 When the MS receives the UA it returns a HANDOVER FAILURE message to the servingBTS.The serving BTS relays the HANDOVER FAILURE transparently to the serving BSC.The serving BSC stops T8 and sends a HANDOVER FAILURE message to the MSC withcause "Radio interface failure -reversion to old channel". The only cell in CLOLD is added tothe MS_CELL_REJ_LIST and timer T_MS_CELL_REJ is started (provided N_PREF_CELL isnot greater than 1). Any cell in MS_CELL_REJ_LIST cannot be used in subsequenthandover attempts until it is removed from the list.The MSC stops T3103 makes the switch path back to the old channel (TCH only), and the callcontinues on the old channel.

3 The MSC releases the target BSS resources by sending a CLEAR COMMAND with cause"Radio interface failure, reversion to old channel" - ref [6] EHT1100.

4 T_MS_CELL_REJ expires and MS_CELL_REJ_LIST is emptied. The cells which were in thelist may again be used in handover attempts.

The following scenario illustrates the management of the MS_CELL_REJECT LIST for subsequentfailures to complete a handover to the target cell.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 24/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Fig 3./6 Multiple MS Handover Failure

Note A: MS detects a problem with the new cell or RF channel

Note B: Call release scenario of the target BSS

1 The MS having detected a problem sends SABM on the old channel. The serving BTSreturns UA and sends an ESTABLISH INDICATION SAPI 0 to the BSC. The serving BSChas no external reaction to the ESTABLISH INDICATION of SAPI 0. A phase 2 MS maysend HANDOVER FAILURE without detaching. This results in no EST IND being sent beforethe HANDOVER FAILURE.

2 When the MS receives the UA it returns a HANDOVER FAILURE message to the servingBTS.The serving BTS relays the HANDOVER FAILURE transparently to the serving BSC.The serving BSC stops T8 and sends a HANDOVER FAILURE message to the MSC withcause "Radio interface failure -reversion to old channel". The only cell in CLOLD is added to


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 25/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

the MS_CELL_REJ_LIST and timer T_MS_CELL_REJ is started (provided N_PREF_CELL isnot greater than 1). Any cell in MS_CELL_REJ_LIST cannot be used in subsequenthandover attempts until it is removed from the list.The MSC stops T3103 makes the switch path back to the old channel (TCH only), and the callcontinues on the old channel.

3 The MSC releases the target BSS resources by sending a CLEAR COMMAND with cause"Radio interface failure, reversion to old channel" - ref [6] EHT1100.

4 Another handover alarm is generated by the handover algorithm and a HANDOVERREQUIRED message is sent to the MSC. The cell in MS_CELL_REJ_LIST is excluded fromthe cell list sent to the MSC (if present in the handover alarm). CLOLD is overwritten with thecell list sent . For clarity the HANDOVER REQUEST protocol to the target BSC is not shown.

5 A HANDOVER COMMAND is returned by the MSC to the serving BSS and forwarded to theMS.

6 The MS fails to attach to this cell also and sends a HANDOVER FAILURE message to theserving BTS. The RR cause value contained in the message is not defined.The serving BTS relays the HANDOVER FAILURE transparently to the serving BSC.The serving BSC stops T8 and sends a HANDOVER FAILURE message to the MSC withcause "Radio interface failure -reversion to old channel". The only cell in CLOLD is added tothe MS_CELL_REJ_LIST and timer T_MS_CELL_REJ is restarted. MS_CELL_REJ_LISTnow contains the latest cell and the previous cell to which the handovers were attempted.

7 T_MS_CELL_REJ expires and MS_CELL_REJ_LIST is emptied. Both cell list may again beused in handover attempts.

3.1.5. - Serving BSC Protocol Failures

The major failures exhibited during the protocol are as follows:

ˆ expiry of T_HO_REQ_LOST

ˆ expiry of T8.

3.1.5.1. - T_HO_REQ_LOST Expiry

This timer is used to supervise responses from the MSC and is one of the conditions that determineswhen the external handover procedure has finished. On expiry an O & M error report is raised. Thescenario below shows several handover attempts culminating in T_HO_REQ_LOST expiring.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 26/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Note A: Serviced handover alarms

Note B : the cell list is the same, thus no HANDOVER REQUIRED is sent.

1 Measurements from MS and BTS are relayed to serving BSC.Serving BSC: detects the need to perform an external handover; sends a HANDOVERREQUIRED to the MSC with a cell list CL1. T7 and T_HO_REQ_LOST are started.

2 A further handover alarm is received with different cell information. A further HANDOVERREQUIRED message is sent with an updated cell list, T7 is restarted. This may occur severaltimes.

3 Further handover alarms are received but there is no different cell information to send to theMSC, no HANDOVER COMMANDS are sent. Eventually T7 will expire and HANDOVERREQUIRED messages may be sent again with the same cell information, (see section3.1.3.2.2. - MSC Does Not Send HANDOVER REQUIRED REJECT)

4 There is no response from the MSC and T HO_REQ_LOST expires. If T7 is running at thistime it is stopped and an O & M error report is raised.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 27/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.1.5.2. - T8 Expiry

T8 is started in the serving BSC to supervise the handover of the MS to the target BSS. The expiry ofthe timer indicates that the MS did not return to the old channel and the MSC has not initiated a callrelease scenario after a successful handover.

When the clear request is generated by the serving BSC all cell lists are cleared.

Fig 3./7 Timer T8 Expiry

Note A: Call release serving BSS

Note B: Call release target BSS

1 T8 has expired in the serving BSC.

2 The serving BSC initiates a Call release - ref [6] EHS0100.

3 The MSC may choose to initiate a Call release scenario. This will depend on the eventsreceived from the target BSC.

3.1.6. - Target BSC Protocol Failures

The major failure events exhibited during the protocol with the target BSC are as follows.

ˆ T9103 expiry;

ˆ T9113 expiry;

ˆ reception of CHANNEL ACTIVATION NACK;

ˆ reception of CONNECTION FAILURE INDICATION (cause "Handover access failure").

The general system strategy for handling protocol errors after the reception of the HANDOVERREQUEST is as follows:

1 if an internal failure is detected a HANDOVER FAILURE is sent to the MSC, this allows theMSC to retry;

2 if a failure is detected indicating that the MS has failed to attach to the new channel then aCLEAR REQUEST will be sent to the MSC.

In both cases, Air interface resources and CIC (TCH only) will be released.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 28/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.1.6.1. - T9103 Expiry

This timer is used during the Channel activation procedure.

In the event of problems or events in the BTS, loss of CHANNEL ACTIVATION, CHANNELACTIVATION ACK, or CHANNEL ACTIVATION NACK messages on Abis the timer expires and thetarget BSC attempts to release the resource in the BTS - ref [6] EHT0200 and sends a HANDOVERFAILURE message to the MSC. These actions are carried out in parallel.

The scenario shown below gives the message sequences.


Note A: Channel release with target BTS

1 The target BSC: allocates the channel; starts to activate it by sending CHANNELACTIVATION message to the target BTS; and starts T9103.

2 The target BSC detects that there is no response from the BTS by the expiry of timer T9103.

3 The target BSC sends a HANDOVER FAILURE message to the MSC - ref [6] EHT0200.

4 The target BSC starts T9110 to guard the response of the MSC and attempts to release thetarget RF channel. If T9110 expires the BSC performs a release on the A interface, see ref[6] EHT0500.

3.1.6.2. - T9113 Expiry

Once the channel has been successfully activated and the HANDOVER REQUEST ACK has beensent to the MSC. The target BSC starts timer T9113 to supervise the external handover.

The timer is stopped when the HANDOVER COMPLETE is received from the MS (via the targetBTS).

When the timer expires, the target BSC releases towards the MS, the target BTS resources and theBSC internally reserved RF resources, at the same time the connection is cleared towards the MSC.

The scenario for the Call release sequence is described in ref [6] EHT0300.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 29/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM


Note A: Target BSC performs Call release ref [6] EHT0300

3.1.6.3. - Channel Activation Nack

The CHANNEL ACTIVATION NACK is sent by the target BTS to the target BSC to inform it of anerror during the Channel activation procedure.

The reception of the CHANNEL ACTIVATION NACK will cause the allocated RF resource to bereleased locally within the target BSC - see ref [6] EHT0101, EHT0102 & EHT0103, and an O&Merror report will be sent to O&M.

When the CHANNEL ACTIVATION NACK message is received with the cause "Encryption algorithmnot implemented " the BSC sends to O&M an O&M error report - it is left to O&M procedures to clearthe database inconsistency.

A HANDOVER FAILURE message will be sent to the MSC with the causes defined in ref [6] andT9110 is started to supervise the response of the MSC.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 30/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Fig 3./10 Channel Activation NACK

Note A: Channel release with target BTS when cause in the CHAN ACT NACK is "Channel alreadyactivated".

3.1.6.4. - Connection Failure Indication (Cause "Handover Access Failure")

The CONNECTION FAILURE INDICATION (cause "Handover access failure") is sent to the targetBSC by the target BTS. The reception of this message during the external handover procedure, is anindication that the MS has been able to send a correct HANDOVER ACCESS to the target BSS buthas not been able to establish the Layer 2 connection or send a TCH or Layer 2 frame (see ref [7] formore detail). The connection is cleared - ref [6] EHT0400.

For the System behaviour for all other cause values in the CONNECTION FAILURE INDICATIONrefer to the section on serving and target BSC detailed behaviour.

3.1.7. - Target BTS Protocol Failures

3.1.7.1. - T3106 Expiry & Connection Failure Indication (Cause "HandoverAccess Failure") Synchronous Handover

Once the target BTS has received on the main DCCH a HANDOVER ACCESS message with thecorrect handover reference it calculates the timing advance for the MS, places it in the Layer 1header of SACCH messages starts deciphering and starts timer T3106. Note: SYSTEMINFORMATION 5 & 6 messages are presently being sent ciphered to the MS.

The target BTS has two behaviour modes controllable by the O&M parameter STOP_HO_ACC_FAIL.

This parameter dictates the events that the BTS needs to receive before it stops the timer T3106(Synchronous handover) or T3105 (asynchronous handover) - see next section.

When STOP_HO_ACC_FAIL is set to SABM_SAPI0_ONLY the timer T3106 is stopped only when theBTS has received from the MS a correctly received SABM (SAPI 0).

When STOP_HO_ACC_FAIL is set to ANY_FRAME the timer T3106 will be stopped when the BTShas received any correct frame (ie TCH frame or Layer 2 frame independent of the SAPI value). This


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 31/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

behaviour means that the target BTS does not ensure that the SAPI 0 connection is establishedduring handover.

Note that the STOP HO ACC FAIL flag is implemented per a BSC. Due to testing requirements theBTS has implemented four flags: T3105_D_STOP, T3105_F_STOP, T3106_D_STOP &T3106_F_STOP.

Once T3106 expires, the LAPDm will reject any attempt from an MS to establish a Layer 2 connectionby sending a DM frame. It is impossible for an MS to connect to this channel, after this event hasbeen detected.


1 The MS has successfully synchronised to the target cell and sends the correct HANDOVERACCESS on 4 consecutive slots on the main DCCH (Timing advance 0).

The target BTS checks the handover reference, starts deciphering (if applied) and sends aHANDOVER DETECTION message to the target BSC.

The target BSC sends a HANDOVER DETECT to the MSC.

2 The target BTS: calculates the timing advance, informs the timing advance algorithm; setsthe timing advance in the Layer 1 header on SACCH messages; and starts T3106.

3 The MS: connects to the channel (ie may start to transmit TCH frames) & sends an SABM(SAPI 0) using the old timing advance set on the old channel; and starts T200.

The target BTS: does not receive either the SABM or any correct frame (they are lost on theAir interface).


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 32/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

4 The timer T3106 expires in the target BTS: LAPDm is placed into the idle state with therefuse option set - see Note A; and a CONNECTION FAILURE INDICATION (cause"Handover access failure") is sent to the target BSC.

The target BSC starts the clearing sequence -ref [6] EHT0400

5 T200 expires in the MS. The MS: sends the SABM once more; and starts T200.

6 The target BTS on reception of the SABM sends a DM to the MS.

The MS on reception of the DM: stops T200; and returns to the Serving cell & old channel.

WarningThe target BSC starts the clearing sequence immediately towards the target BTS (ref [6]EHT0400) an incorrect setting of T3106 will mean that the target RF channel may be releasedwhilst the MS is still there.

Note A: The refuse option is a speciality of the ALCATEL BTS. When this option is set all attempts bythe MS to establish a LAPDm connection will be refused by the BTS LAPDm entity. This isachieved by the sending of a DM frame to the MS when an SABM is received.In the case of message crossing (between L3 & L2 LAPDm in the BTS ie the DL-EST-IND isbeing sent to L3 whilst L3 is initiating the refuse option) the Layer 2 LAPDm will not acceptthe refuse option and allow the LAPDm to be established. see reference [22]

3.1.7.2. - T3105 Expiry & Connection Failure Indication (Cause "HandoverAccess Failure") Asynchronous Handover

Once the MS has sent on the main DCCH a HANDOVER ACCESS message with the correcthandover reference. The target BTS: calculates the timing advance for the MS sends on the mainDCCH the PHYSICAL INFORMATION message; starts deciphering (if applied); and starts the timerT3105.

The target BTS has two behaviour modes controllable by the O&M parameter STOP_HO_ACC_FAIL.

This parameter dictates the events that the BTS needs to receive before it stops the timer T3106(Synchronous handover - see previous section) or T3105 (asynchronous handover).

When STOP_HO_ACC_FAIL is set to SABM_SAPI0_ONLY the timer T3105 is stopped only when theBTS has received from the MS a correctly received SABM (SAPI 0).

When STOP_HO_ACC_FAIL is set to ANY_FRAME the timer T3105 will be stopped when the BTShas received any correct frame (ie TCH frame or Layer 2 frame independent of the SAPI value). Thisbehaviour means that the target BTS does not ensure that the SAPI 0 connection is establishedduring handover.

Note that the STOP_HO_ACC_FAIL flag is implemented on a per BSC basis. Due to testingrequirements the BTS has implemented four flags: T3105_D_STOP, T3105_F_STOP,T3106_D_STOP, & T3106_F_STOP.

The target BTS starts sending the PHYSICAL INFORMATION message at a rate of T3105 until it hasreceived (from the MS) either an SABM SAPI 0 (when STOP_HO_ACC_FAIL ==SABM_SAPI0_ONLY) or any correct frame (when STOP_HO_ACC_FAIL == ANY_FRAME).

If the target BTS sends NY1 repetitions of PHYSICAL INFORMATION message without receiving therequire response from the MS, then the target BTS will: send a CONNECTION FAILUREINDICATION message (cause "Handover access failure"); and place LAPDm into the "idle" state withthe refuse option set - see Note A.

The LAPDm, whilst in this state, will reject any attempt from an MS to establish a Layer 2 connectionby sending a DM frame.

It is impossible for an MS to connect to this channel, after this event has been detected.

EX

TE

RN

AL

HA

ND

OV

ER

ED

02 R

EL

EA

SE

D

MC

D41.D

OC

16/02/98 10:12

3BK

11202 0104 DS

ZZ

A33/108



EL

EC

OM

The m

essage sequence chart below show

s the case where N

Y1 is 2.

Fig 3./12 T

imer T

3105 Expiry


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 34/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

1 The MS has: successfully synchronised to the target cell; starts to send the correctHANDOVER ACCESS on the main DCCH (Timing advance 0); and starts the timer T3124.

The target BTS: sends a HANDOVER DETECTION message to the target BSC.

The target BSC sends a HANDOVER DETECT to the MSC.

2 The target BTS: calculates the timing advance; informs the timing advance algorithm o f thecalculated timing advance; sets the timing advance field in the Layer 1 header of the SACCHmessages; sends the PHYSICAL INFORMATION message with the calculated timingadvance to the MS on the main DCCH; and starts T3105.

3 The MS: stops T3124; stops sending the HANDOVER ACCESS; adjusts its timing to the dataheld in the PHYSICAL INFORMATION message; connects to the TCH channel; sends anSABM (SAPI 0); and starts T200.

The target BTS: does not receive the SABM or another correct frame (they are lost on the Airinterface).

4 The timer T3105 expires in the target BTS and the PHYSICAL INFORMATION is sent again.

5 The timer T3105 expires (NY1 times) in the target BTS: LAPDm is placed into the idle statewith the refuse option set - see Note A; and a CONNECTION FAILURE INDICATION (cause"Handover access failure") is sent to the target BSC.

The target BSC starts the clearing sequence - ref [6] EHT0400.

6 T200 expires in the MS. The MS: sends the SABM once more; and starts T200.

7 The target BTS on reception of the SABM sends a DM to the MS.

The MS on reception of the DM: stops T200; and returns to the serving cell & old channel.

Warning:The target BSC starts the clearing sequence with the target BTS immediately (ref [6]EHT0400) if the value of T3105 * NY1 is not set correctly the MS may still be on the targetchannel.

Note A: The refuse option is a speciality of the ALCATEL BTS. When this option is set all attempts bythe MS to establish a LAPDm connection will be refused by the BTS LAPDm entity. This isachieved by the sending of a DM frame to the MS when an SABM is received.In the case of message crossing (between L3 & L2 LAPDm in the BTS ie the DL-EST-IND isbeing sent to L3 whilst L3 is initiating the refuse option) the Layer 2 LAPDm will not acceptthe refuse option and allow the LAPDm to be established.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 35/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.2. - Detailed Behaviour

3.2.1. - Serving BTS Protocol

The serving BTS provides: remote transcoder alarm filtering (TCH channel only); message passingservice and information regarding events in the serving BTS and events detected by the serving BTSand the MS, during the external handover protocol. The serving BTS is unaware of the externalhandover protocol taking place.

The serving BTS will not refuse access to the MS in the event of an Air interface failure on the oldchannel.

No error detected on the Air interface on the old channel side will cause the serving BTS toautomatically release the MS connection (it is the BSC’s responsibility to release the RF resources).

The Remote transcoder alarms will be filtered as shown in the target BTS section of this document.This filtering is performed for all active TCH RF channels.

3.2.2. - Serving BSC Protocol

The serving BSC external handover protocol has the following functions to perform:

External Handover decisionGiven the cell list from the BSS handover algorithm and a set of O&M flags, this function decideswhether an external handover is to be performed.

External Handover protocolOnce the external handover detection mechanism indicates that an external handover is required, thisfunction initiates and completes the external handover with the MSC.

3.2.2.1. - External Handover Decision

3.2.2.1.1. - General Rules

The candidate cells list is produced as specified in ref [9]. This is further refined in the externalhandover protocol by comparing the list against CLOLD, checking for any new cell in the list or an oldcell no longer in the list.

The O & M Parameters and other variables listed in section 4.4 are then used to determine whetheran external handover should be attempted.

3.2.2.1.2. - External Handover Decision For SDCCH Transactions

There are two types of SDCCH external handover decision algorithms. One after the Immediateassignment procedure, the other after the Normal Assignment procedure.

3.2.2.1.3. - SDCCH External Handover Decision After Immediate Assignment

External handover procedures are not allowed to be started during the assignement procedure. Forthis reason, the condition ASSGN is used.

In order to allow the MSC to initiate and complete the ciphering and identification procedures withoutinterruption from a handover, a mechanism is foreseen to hold off any potential handover alarms atthe beginning of the transaction. This mechanism uses the parameter SDCCH_COUNTER and thevariable DOT.

The rules for deciding whether an external SDCCH handover is possible after an Immediateassignment procedure are as follows:


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 36/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

if (BCE == TRUE OR (BCE == FALSE AND NOT("Intra-cell alarm")AND EXT_HO_FORCED == TRUEAND EN_IC_HO (target cell) == TRUE))

/*Best cell is really external or O&M forces ext HO*/

AND HO_INTERCELL_ALLOWED == TRUEAND HO_SDCCH_INHIBIT == FALSE /*O&M allows SDCCH HO*/AND SDCCH_COUNTER <= DOT /*Hold off time is exceeded*/AND ASSGN == FALSE /*No Assignment in progress*/

then initiate external SDCCH HO

elseif BCE == FALSEthen see Internal handover - ref[7].

3.2.2.1.4. - SDCCH External Handover Decision ( After Normal Assignment)

External handover procedures are not allowed to be started during the assignement procedure. Forthis reason, the condition ASSGN is used.

The rule for deciding whether an external SDCCH handover is initiated as follows:



AND HO_INTERCELL_ALLOWED == TRUEAND HO_SDCCH_INHIBIT == FALSE /*O&M allows SDCCH HO*/AND ASSGN == FALSE /*No Assignment in progress*/

then initiate external SDCCH HO

elseif BCE == FALSEthen see Internal handover - ref[7].

3.2.2.1.5. - External Handover Decision For TCH Transactions

External handover procedures are not allowed to be started during the assignement procedure, orduring in-call modification procedure. For this reason, the condition ASSGN is used.

The rule for deciding whether an external handover is possible is as follows:



AND HO_INTERCELL_ALLOWED == TRUEAND ASSGN == FALSE /*No Assignment in progress*/


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 37/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

theninitiate external TCH HO

elseif BCE == FALSEthen see Internal handover - ref[7]

3.2.2.2. - Serving BSC External Handover Protocol

When an external handover is to be attempted, (see section 3.2.2.1. - External Handover Decision) itis initiated by the serving BSC sending the HANDOVER REQUIRED message (see section 3.2.2.2.6.- HANDOVER REQUIRED message building), starting T7 and T_HO_REQ_LOST.

The figure on the following page shows the states in the serving BSC for the handover protocol andthe major events only that cause state transitions. The full list of events is defined in the state tablesin this section.

The expiry of T_MS_CELL_REJ causes no state change and is handled in every state. The onlyaction on expiry is the emptying of the list MS_CELL_REJ_LIST.

EX

TE

RN

AL

HA

ND

OV

ER

ED

02 R

EL

EA

SE

D

MC

D41.D

OC

16/02/98 10:12

3BK

11202 0104 DS

ZZ

A38/108



EL

EC

OM

Fig 3./13 S

erving BS

C S

tate Diagram

& M

ajor Events (S

ee notes overleaf)

7��([S

18//

+2�&RPPDQG

+2�)DLO

6WDUW�7�S

end HO

RE

QU

IRE

D

+2�$ODUP

6WRS�7B+2B5(4B/2676WDUW�7�

7��([S

(+2�,Q3URJ

6WRS�7�6WRS�7B+2B5(4B/267

6WDUW�7�

7��([S

(PSW\�5(-B&(//B/,67

T7 E

xp

+2�5(4�5(-6WRS�7B+2B5(4B/267

&/2/'��!�5(-B&(//B/,67

+2�$ODUP��%&� �([WHUQDO�

5HVWDUW�7�S

end HO

RE

QU

IRE

D

+2�$ODUP��&/�GLIIHUHQW�

6WDUW�7B+2B5(4B/2676WDUW�7�

Send H

O R

EQ

UIR

ED

6WDUW�7B+2B5(4B/2676WDUW�7�

Send H

O R

EQ

UIR

ED

+2�$ODUP&/�GLIIHUHQW

(+2�,QLW+2�&RPPDQG

&OHDU7B+2B5(4B/267�([S

6HQG�+2�)$,/6WRS�7�

�VW�FHOO�LQ�&/2/'�!�06B&(//B5(-B/,67

+2�5HT5HM

7B+2B5(4B/267�([S

+2�5(4�5(-

6WRS�7B+2B5(4B/267

+2�$ODUP��%&�� ([WHUQDO�

,QWHUQDO�+DQGRYHU�3URFHGXUH

6WRS�7�

6HQG�2��0�(UURU�5HS

6HQG�2��0�(UURU�5HS

6WDUW�7B06B&(//B5(-

7R�6WDWH�(+2�,Q�3URJ

6WRS�7�6WDUW�7�

+2�&RPPDQG


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 39/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Notes :

1. CLOLD is only cleared when entering the NULL state; when updated in any other state it is alwaysoverwritten with new information.

2 Any entry to the NULL state will clear CLOLD and REJ_CELL_LIST but notMS_CELL_REJ_LIST.

STATE DESCRIPTION ABBREVIATION

This state represents one of the entry and exit states of theexternal handover protocol. (note an external handover maybe initiated during an internal handover, when the next cell inthe preferred cell list is external to the serving BSS)

NULL

The serving BSC has initiated an external handover (bysending the HANDOVER REQUIRED), T7 andT_HO_REQ_LOST are running and the serving BSC isawaiting a response from the MSC or a change in radioconditions.

EXT HO INIT.

The serving BSC has received the HANDOVER COMMANDand is awaiting either the failure or success of the procedure.T8 is running.

EXT HO IN PROG

The serving BSC has sent a HANDOVER REQUIRED towhich the MSC has replied with a HANDOVER REQUIREDREJECT. All cells in CLOLD have been added toREJ_CELL_LIST. T7 is running.

HO REQ REJ

The serving BSC has sent a HANDOVER REQUIRED andT7 has expired. T_HO_REQ_LOST is running.

T7 EXP

Table 3./1 Serving BSC Logical States

In following tables, when next state is not specified, it implicitly means that there is no state transition.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 40/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

3.2.2.2.1. - NULL State behaviour

The NULL state represents an entry state to the external handover procedure, it is a logical state andis used for representation in this document. In fact an external handover may be triggered fromwithin an internal handover procedure where the next best cell in the preferred cell list is external tothe serving BSC.

The serving BSC will service the events shown in table 3./2 in the NULL state.

EVENT ACTION

Handover Alarm (Best cell external) Send HANDOVER REQUIRED toMSC with cell list CLStore CL as CLOLD

Start T7Start T_HO_REQ_LOST

Next state (EXT HO INIT)

Handover Alarm (Best cell notexternal)

Internal handover attempted, see ref15.

Table 3./2 NULL State events


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 41/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.2.2.2.2. - Normal Events

STATEEVENT

EXT HO INIT EXT HOIN PROG

T7 EXP HO REQ REJ

HANDOVERCOMMAND

stop T7

stop T_HO_REQ_LOST

send HO CMD to MS

start T8

next state (EXT HO IN PROG)

Discard the messageNote 1

stop T_HO_REQ_LOST

send HO CMD to MS

start T8

next state (EXT HO INPROG)

stop T7

send HO CMD to MS

start T8

next state (EXT HO IN PROG)

HANDOVERREQUIREDREJECT

stop T_HO_REQ_LOST

Add CLOLD to REJ_CELL_LISTNext state (HO REQ REJ)

Discard stop T_HO_REQ_LOST

next state (NULL)

Discard (note 2)

T7 EXPIRY Empty REJ_CELL_LIST

Next State (T7 EXP)

Not Applicable Not applicable Empty REJ_CELL_LIST

Next State (NULL)

T8 EXPIRY Not Applicable Queued DTAP messages arediscarded(see section3.2.2.2.5)

ref [6] EHS0100Next state (NULL)

Not applicable Not Applicable

T_HO_REQ_LOST

expiryStop T7

Send O & M Event

Empty REJ_CELL_LIST

Empty MS_CELL_REJ_LIST

Next state (NULL)

Not applicable Send O & M Event

Next state (NULL)

Not Applicable


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 42/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Handover Alarm See Note 3

Send HANDOVER REQUIREDto MSC with cell list CLStore CL as CLOLD

restart T7

Discard See Note 3

Send HANDOVERREQUIRED to MSC with celllist CLStore CL as CLOLD

restart T7Next State (EXT HO INIT)

See note 3

Send HANDOVERREQUIRED to MSC with celllist CLStore CL as CLOLD

restart T7start T_HO_REQ_LOST

Next State (EXT HO INIT)

HANDOVERFAILURE

Not Applicable Send HO FAIL (cause"reversion to old channel")

Stop T8

If N_PREF_CELL = 1Add 1st cell of CLOLD to-MS_CELL_REJ_LISTStart T_MS_CELL_REJ_LIST (note7)endif

Queued DTAP messages arediscarded (see section3.2.2.2.5)

Ref [6] EHS0200Next State (NULL)

Not Applicable Not Applicable


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 43/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

CLEARCOMMAND(CauseHandoversuccessful)

Note 4

stop T7

stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0600

Next State (NULL)

Note 5

stop T_MS_CELL_REJ

Empty REJ_CELL LISTEmpty MS_CELL_REJ_LISTstop T8

Queued DTAP messages arediscarded (see section3.2.2.2.5)

ref [6] EHS0400

Next State (NULL)

Note 4

Stop T_MS_CELL_REJ


stop T_HO_REQ_LOST

ref [6] N0600

Next State (NULL)

Note 4

Stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0600

Next State (NULL)

Table 3./3 Normal Events State Table

Note 1: The serving BSC is in a state where there is an external handover already in progress. The HANDOVER COMMAND will be discarded.

Note 2 In this state a HANDOVER REQUIRED REJECT has already been received for the handover attempt.

Note 3 An alarm is always accompanied by a cell list which is processed as defined in section 3.2.2.1. - External Handover Decision. If the cell list CL is notempty then there are new cells to send to the MSC for this handover attempt.

Note 4: The CLEAR COMMAND (cause "Handover successful") is only expected in the state EXT HO IN PROG. As it has appeared in a state where it isunexpected a Call release will occur independent of the cause.

Note 5: The CLEAR COMMAND (cause "Handover successful") is only expected in this state, the MS is no longer on the channel.

Note 7 While this timer runs the cell cannot be used in subsequent handover attempts on this connection. The MS_CELL_REJ_LIST will be emptied whenthe timer expires.

Note 8 T_HO_REQ_LOST is not running at this point, (HANDOVER REQUIRED REJECT previously received). When T7 expires, (for example if no new cellsare reported in the handover alarms), if T_MS_CELL_REJ is not running then internal handovers may be performed since the external handoverprocedure has terminated..


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 44/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.2.2.2.3. - Unexpected Events

STATEEVENT

EXT HOINIT

EXT HOIN PROG

T7 EXP HO REQ REJ

CLEARCOMMANDNote 1

stop T_HO_REQ_LOST

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N0600

Deferred until outcome ofExt HONote 3

stop T_HO_REQ_LOST

stop T_MS_CELL_REJ


Next state (NULL)

ref [6] N0600

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N0600

SCCP-N-DISC stop T_HO_REQ_LOST

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N0500

Deferred until outcome of ExtHONote 6

stop T_HO_REQ_LOST

stop T_MS_CELL_REJ


ref [6] N0500

Next state (NULL)

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0500

Next state (NULL)

DTAP message Send to MS via BTS Queue message (see section3.2.2.2.5)

Send to MS via BTS Send to MS via BTS

CIPHER MODECOMMAND

Perform Ciphering

External Handover continues

Discard message Perform Ciphering

External Handover continues

Perform Ciphering


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 45/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

ASSIGNMENTREQUEST

stop T_HO_REQ_LOST

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL_LIST


Next state (NULL)

Abandon handover;

Perform Assignment

Discard message stop T_HO_REQ_LOST

stop T_MS_CELL_REJ


Next state (NULL)

Perform Assignment

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

Perform Assignment

RESET stop T_HO_REQ_LOST

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N0900

A i/f: SCCP releaseimmediate Note 7

Air: Deferred until outcome ofExt HO Note 4

stop T_HO_REQ_LOST

stop T_MS_CELL_REJ


Next state (NULL)

ref [6] N0900

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N0900

RESET CIRCUIT stop T_HO_REQ_LOST

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N1000

A i/f: SCCP releaseimmediate Note 7

Air: Deferred until outcome ofExt HO Note 4 & 5

stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N1000

stop T7

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


Next state (NULL)

ref [6] N1000

Table 3./4 Unexpected Event Handling A Interface & DTAP


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 46/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

Note 1: All cause values with the exception of "Handover successful".

Note 3: The release on A interface (ie sending CLEAR COMPLETE) will be initiated when either the MS sends the HANDOVER FAILURE on the old RFchannel or when the timer T8 expires no HANDOVER FAILURE is sent to the MSC..The release on Abis & Air interface is initiated when the MS sends the HANDOVER FAILURE on the old RF channel (in this case, the DTAPmessages queued during the procedure are sent to the MS before the release, see section 3.2.2.2.5) or when the timer T8 expires (in this case, theDTAP messages queued during the procedure are discarded). Scenario ref [6] - N0600 applies.

Note 4: The release of the A interface A Channel is done when either the MS sends the HANDOVER FAILURE on the old RF Channel (in this case, theDTAP messages queued during the procedure are sent to the MS before the release, see section 3.2.2.2.5) or when the timer T8 expires (in thiscase, the DTAP messages queued during the procedure are discarded).The release on Abis & Air interface is initiated when the MS sends the HANDOVER FAILURE on the old RF Channel or when the timer T8 expires.

Note 5: The release on A interface (ie sending RESET CIRCUIT ACK) will be initiated when either the MS sends the HANDOVER FAILURE on the old RFChannel or when the timer T8 expires.

Note 6: Any DTAP message received from the MSC in a SCCP RELEASED message and reported in the SCCP N DISC IND is queued (if free space in thequeue).

The release on the Abis & Air interface is initiated when the MS sends the HANDOVER FAILURE on the old RF Channel (in this case, the DTAPmessages queued during the procedure are sent to the MS before the release, see section 3.2.2.2.5) or when the timer T8 expires (in this case, theDTAP messages queued during the procedure are discarded)..

Note 7: The release of the SCCP connection (ie the sending of the SCCP RELEASE message at the SCCP level) is immediately performed. However theCircuit associated to the connection (if any) will not be released in the BSC until the whereabouts of the MS is known. Only at this point in time willthe release of the A interface circuit be initiated.During this period of time the A interface circuit will be unavailable for use by the MSC.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 47/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

3.2.2.2.4. - Events from BTS

STATEEVENT

EXT HO INIT EXT HO IN PROG T7 EXP HO REQ REJ

CONN FAIL INDIC(Radio-link Fail)

Stop T7Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0700

Next state (NULL)

Discard message Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ


ref [6] N0700Next state (NULL)

Stop T7stop T_MS_CELL_REJ

Empty REJ_CELL LIST



CONN FAIL INDIC(Remote TransFailure)

Stop T7Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0800

Next state (NULL)


stop T_MS_CELL_REJ




Empty REJ_CELL LIST



EST INDIC SAPI 0 Don’t care Note 5 Don’t care Don’t care


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 48/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

ERR REP (O&Mintervention)

Stop T7

Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0400

Next state (NULL)

stop T8

Queued DTAP messagesare discarded

ref [6] N0400

Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ




Empty REJ_CELL LIST



ERR REP SAPI 0(Msg seq err)

Stop T7

Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N1200

Next state (NULL)


stop T_MS_CELL_REJ




Empty REJ_CELL LIST



ERR INDIC SAPI0 (Note 2)

stop T7

Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0100

Next state (NULL)


stop T_MS_CELL_REJ




Empty REJ_CELL LIST



ERR INDIC SAPI0 (Note 3)

Don’t care Discard message Don’t care Don’t care


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 49/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

TELECOM

REL INDIC SAPI 0 stop T7

Stop T_HO_REQ_LOST

stop T_MS_CELL_REJ

Empty REJ_CELL LIST


ref [6] N0200

Next state (NULL)


stop T_MS_CELL_REJ




Empty REJ_CELL LIST



Table 3./5 Handling of Events and Errors from Serving BTS.

Note 2 Causes: T200 expiry (N200 + 1); Unsolicited DM response: Multi frame established state; & Sequence error.

Note 3 All other causes, other than those mentioned in Note 2.

Note 5 No external events are generated by the BSC at this point in time, however the BSC performs some internal actions.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 50/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

3.2.2.2.5. - DTAP and BSSMAP procedures

The processing of DTAP and BSSMAP in the serving BSS during external handover (ie whilst in theEXT HO IN PROG, state) are as follows:

• Up to 5 DTAP messages will be buffered by the BSC. DTAP messages received when thebuffer is full will be discarded. During dequeuing,when the channel change procedurecompletes, only the first SAPI 3 message is sent to the MS if the SAPI 3 connection isalready established or the establishment of a SAPI 3 connection has been initiated (in whichcase, the first SAPI 3 message is forwarded to the MS as soon as the connection isestablished).

If the SAPI 3 connection isn’t already established or initiated, then no SAPI 3 messages areforwarded to the mobile during dequeuing..

• ASSIGNMENT REQUEST, HANDOVER COMMAND & CIPHER MODE COMMANDmessages for the connection will be discarded.

The MSC is not meant to send DTAP messages whilst an external handover is in progress, see Ref[15].

3.2.2.2.6. - HANDOVER REQUIRED message building

To initiate an external handover the serving BSC sends a HANDOVER REQUIRED message to theMSC containing cell information for the MSC to act upon.

Information element Setting or Algorithm

Message type Set to HANDOVER REQUIRED

Cause The cause will be set to either: Uplink quality; Uplink strength;Downlink quality; Downlink strength; Distance; or Better cell. Thiswill depend on the reason in the handover alarm - see Refs [8].

OIE RESPONSEREQUEST

The response request information element will be included onlywhen the parameter RESP REQ is set to TRUE.The RESP REQ is an O&M modifiable operator parameter.

MIE CELLIDENTIFIER LIST(Preferred)

The cell list when built will contain no more cells than indicated bythe N PREF CELL parameter.When the O&M flag CGI REQD is set to TRUE, then the OIE CELLIDENTIFIER LIST PREFERRED will contain cells identified by useof the whole Cell Global Identification (CGI) coding.Otherwise the cells will be identified by use of the Cell IdentificationDiscriminator coding (CELL DISC = 1, LAC + CI is used).The N PREF CELL is an O&M modifiable operator parameter.

OIE Current Channel This IE contains the mode and the channel currently used. It is onlyincluded if O&M flag EN_SEND_OLD_CHAN_MODE is set toTRUE.

OIE Speech Version(used)

Always included if channel mode is "speech" AND if flagEN_SEND_SPEECH_VER is set to TRUE.

Table 3./6 HANDOVER REQUIRED Message

The handover cause is mapped to the Cause information element as defined in Ref [15]


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 51/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

3.2.3. - MSC Handover Protocol

The ALCATEL BSS has to interface to many MSCs. This section gives the reader an insight into theMSC behaviour so as to grasp a better knowledge of the protocol whilst testing, only the inter-MSCprotocol is described.

The MSC when it receives a HANDOVER REQUIRED from a BSS initiates an external handoverprotocol.

The MSC external handover protocol may consist of the following functions:

• an evaluation of the CELL IDENTIFIER LIST PREFERRED may be performed, so as to select acell which is not heavily loaded.

• A cell is selected and the target BSS is sent a HANDOVER REQUEST message - see ref [14] forthe MSC’s requirement for the setting of the PERMITTED ALGORITHM setting. The timer Trr2 isstarted to supervise the activation of the channel for the handover.If the OIE RESPONSE REQUEST is present in the HANDOVER REQUIRED message and Trr2expires the MSC may send a HANDOVER REQUIRED REJECT to the serving BSC. When thisoccurs the BSC will consider all cells sent in the HANDOVER REQUIRED message as rejected.

• When the MSC receives the HANDOVER REQUEST ACK message it stops Trr2, sends aHANDOVER COMMAND to the serving BSS and starts the timer T3103 to supervise thehandover with the MS.At this point in time the MSC should disable the DTAP transparent message passing function andprevent or queue any RR or MM procedure (for example ciphering, identify etc).

• The MSC is now awaiting the outcome of the handover.

• In the successful case the MSC will receive a HANDOVER DETECT followed by a HANDOVERCOMPLETE from the target BSS. In this case the MSC, stops the timer T3103, performs theswitch through (TCH only), releases the serving BSS by using a CLEAR COMMAND (cause"Handover successful"), where upon the handover is deemed to have finished. At this point intime the MSC re-enables the DTAP function and allows RR, MM and other procedures to run.

• In the unsuccessful case the MSC will receive a HANDOVER FAILURE message (cause"Reversion to old channel") from the serving BSS. The MSC will, stop the timer T3103, performthe switch back (if necessary TCH only), release the target BSS by sending a CLEAR COMMAND(cause "Radio interface failure, reversion to old channel"), where upon the handover is deemed tohave finished.The MSC can only wait for the next HANDOVER REQUIRED message for a new handoverprocedure to occur.

• If T3103 expires the MSC may decide to clear the call or let the connection continue until a failureis signalled to the MSC from the serving BSS.

• For TCH calls the MSC may choose to make the switch path at two different points in the protocoleither when it receives the HANDOVER DETECT message or the HANDOVER COMPLETE isreceived from the target BSS. In fact some MSCs may perform the switch through before thereception of the HANDOVER DETECT message.

3.2.4. - Target BSC External Handover Protocol

This section deals with the handling of the Layer 3 message of the target BSC during the externalhandover protocol.

For more detail on the processing of the HANDOVER REQUEST message and the SCCP connectionestablishment for external handovers refer to the relevant sections in this chapter.

The following table gives the actions carried out (when congestion is present) by the BSC for TCHtransactions depending on, the MSC queuing requirements, and the internal BSC queue status,before the state tables are entered.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 52/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

MSCQueuing

requested

Internal BSCqueue status

Actions

QueuingRequested

Can queue Start T_qhoSend QUEUING INDICnext state (AWAIT TCH RESOURCE- QUEUING)

QueuingRequested

Can notqueue

ref [6] EHT0800start T9110next state (AWAIT MSC RESPONSE)

Queuing isNot

Requested

Can queue Send HANDOVER FAILURE (cause "No radioresource available")start T9110next state (AWAIT MSC RESPONSE)

Queuing isNot

Requested

Can notqueue

Send HANDOVER FAILURE (cause "No radioresource available")start T9110next state (AWAIT MSC RESPONSE)

Table 3./7 TCH Transactions and Queuing During Congestion

The following table gives the actions carried out by the BSC for SDCCH transactions depending onthe SDCCH Congestion of the target cell before the state tables are entered.

Target cell SDCCH Congestionstatus

Actions

No SDCCH Congestion Start T9103Send CHANNEL ACTIVATIONnext state (AWAIT CHAN ACT ACK)

SDCCH Congested Send HANDOVER FAILURE (cause "No radioresource available")start T9110next state (AWAIT MSC RESPONSE)

Table 3./8 SDCCH Transactions During Congestion


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 53/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel


There is a congestion situation and the request is queued(TCH calls only)

AWAIT TCHRESOURCE (QUEUING)

The Target BSC has allocated and is attempting toactivate a channel to which the handover may occur

AWAIT CHN ACT ACK

The target BSC has successfully activated the channel,has sent the HANDOVER REQUEST ACK to the MSC,and is awaiting the successful completion of theprocedure

AWAIT HO DETECTION

The target BSC has received the HANDOVERDETECTION from the target BTS. It has made the switchpath (TCH only) and is awaiting the ESTABLISHINDICATION message

AWAIT ESTAB IND

The target BSC has received the ESTABLISHINDICATION and is now awaiting the HANDOVERCOMPLETE message from the MS

AWAIT HO CMPLT

The target BSC has detected a failure in either theHANDOVER REQUEST or the activation of the targetBTS channel and has sent a HANDOVER FAILURE tothe MSC. The target BSC is awaiting either anotherHANDOVER REQUEST or a CLEAR COMMAND. TimerT9110 is running to supervise the MSC response.

AWAIT MSC RESP

This state represents the entry and exit state of theexternal handover protocol.

NULL

Table 3./9 Target BSC Logical States

STATEEVENT

AWAIT TCH RESOURCE (QUEUING)

TCH available Stop T_qhoStart T9103Send CHAN ACT to target BTSnext state (AWAIT CHN ACT ACK)

T_qho expiry Send HANDOVER FAILURE ref [6] EHT0800start T9110Next state (AWAIT MSC RESP)

Pre-emption byanother request(Handover orAssignment)

Stop T_qhoSend HANDOVER FAILURE ref [6] EHT0800Start T9110Next state (AWAIT MSC RESP)

Table 3./10 State Table for Expected Events (During Queuing - TCH Only)


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 54/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

STATEEVENT

AWAIT CHN ACT ACK

CHANNELACTIVATIONACKNOWLEDGE

stop T9103send HO REQ ACKstart T9113next state(AWAIT HO DETECTION)

CHN ACT NACK(Request transcodingrate unavailable)

stop T9103send HO FAILUREfor "data" connection, use ref [6] EHT0101for "speech" connection, use ref [6] EHT0106start T9110next state(AWAIT MSC RESP)

CHN ACT NACK(Encryption algorithmnot implemented)

stop T9103Send HO FAILURE ref [6] EHT0102

start T9110next state (AWAIT MSC RESP)

CHN ACT NACK (Allother causes)

stop T9103send HO FAILUREref [6] EHT0103start T9110next state(AWAIT MSC RESP)

T9103 EXPIRY send HO FAILUREref [6] EHT0200start T9110next state(AWAIT MSC RESP)

Table 3./11 State Table for Expected Events During Channel Activation


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 55/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

STATEEVENT

AWAIT HO DETECTION AWAIT ESTAB IND AWAIT HO CMPLT

HANDOVERDETECTION

Switch through connectionpath on a per call basisdepending on the fullrate/half rate requirementsof the connection. (TCHonly)

send HO DETECTnext state(AWAIT ESTAB

IND)

Don’t care Don’t care

ESTABLISHINDICATIONSAPI 0

Note 2;Switch through connection

path on a per call basisdepending on the fullrate/half rate requirementsof the connection (TCHonly)Note 8

BSC starts MS & BS PwrCtrl as required;

next state(AWAIT HOCMPLT)

: BSC starts MS & BS PwrCtrl as required;

next state(AWAIT HOCMPLT)

Don’t care

HANDOVERCOMPLETE

Note 3;stop T9113Switch through connection

path on a per call basisdepending on the fullrate/half rate requirementsof the connection(TCHonly)

send HO CMPLT


if this is a directed retry tofull rate speech version 1TCH with a phase 1 MSsend CHANNEL MODEMODIFY. see note 26

Enable DTAPnote 25next state(NULL)

Note 4;stop T9113send HO CMPLT


if this is a directed retry tofull rate speech version 1TCH with a phase 1 MSsend CHANNEL MODEMODIFY. see note 26


stop T9113send HO CMPLTif this is a directed

retry to full ratespeech version 1TCH with a phase 1MS, send CHANNELMODE MODIFY.see note 26


Table 3./12 State Table for Expected Events During Channel Change

The reception of these events in other states (ie during AWAIT TCH RESOURCE or WAIT MSCRESP) are either not applicable or ignored. There is only one exception to this which is the receptionof the HANDOVER REQUEST message during the WAIT MSC RESP state.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 56/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

STATEEVENT

AWAIT HODETECTION

AWAIT ESTAB IND AWAIT HOCMPLT

WAIT MSCRESP

T9113 EXPIRY ref [6] EHT0300 ref [6] EHT0300 ref [6] EHT0300 NotApplicable

CONN FAIL IND(Handover accessfailure)

Note 2;ref [6] EHT0400

ref [6] EHT0400 Not Applicable NotApplicable

CLEAR COMMANDNote 17

Stop T9113ref [6] EHT1100



Stop T9113ref [6]

EHT1100HANDOVERREQUEST

Not Applicable Not Applicable Not Applicable Note 5stop T9110

T9110 expiry Not Applicable Not Applicable Not Applicable ref [6]EHT0500

Table 3./13 State Table for Expected Events During Channel Change

STATEEVENT

AWAIT TCHRESOURC

E

AWAIT CHNACT ACK

AWAITHO

DETECTION

AWAITESTAB

IND

AWAITHO

CMPLT

WAITMSCRESP

CLEARCOMMANDNote 18

A Int Note 15NC Note 13


A Int & NCNote 24

A Int & NCNote 24

A Int & NCNote 24

StopT9110

ref [6]EHT0900

SCCP-N-DISCNote 20



A Int & NCNote 14

A Int & NCNote 14

A Int & NCNote 14

StopT9110ref [6]EHT1000

RESET A Int Note 15NC Note 13


A Int & NCNote 14

A Int & NCNote 14

A Int & NCNote 14

StopT9110A Int isreleasedlocally

RESETCIRCUIT



A Int & NCNote 14

A Int & NCNote 14

A Int & NCNote 14

StopT9110A Int isreleasedlocally

DTAPmessage

Discard orrejectmessageNote 23

Discard orrejectmessageNote 23

QueuemessageNote 12

QueuemessageNote 12

QueuemessageNote 12

Discardor rejectmessageNote 23

CIPHERMODECOMMAND

DiscardmessageNote 12





Discardmessage

ASSIGNMENTREQUEST






Discardmessage

Table 3./14 Unexpected Event Handling - A Interface & DTAP


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 57/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

STATEEVENT

AWAIT CHNACT ACK

AWAIT HODETECTION

AWAIT ESTABIND

AWAIT HOCMPLT

AWAITMSCRESP

CONN FAILIND Note 9

Not Applicable Don’t care Don’t care Don’t care NotApplicableNote 11

CONN FAILIND (Radio-linkfail)


ERR REP(O&Mintervention)

ref [6] EHT1200

ref [6] N0400 ref [6] N0400 ref [6] N0400 NotApplicableNote 11

ERR REPSAPI 0 (Msgseq err)

Don’t care Don’t’ care Don’t care Don’t care NotApplicableNote 11

ERR IND SAPI0 (Note 6)


ERR IND SAPI0 (Note 7)


REL IND SAPI0


MEASURERESULT

Not Applicable Note 21 Note 21 Note 22 NotApplicable

Table 3./15 Handling of Errors from Target BTS

Notes :

2: the HANDOVER DETECTION message was lost on Abis.

3: the HANDOVER DETECTION and ESTABLISH INDICATION message were lost on Abis.

4: the ESTABLISH INDICATION message was lost on Abis.

5: The HANDOVER REQUEST message processing is entered once more.

6: Causes: T200 expiry (N200 + 1); Unsolicited DM response: Multiframe established state; &sequence error.

7: All other causes other than those in Note 6.

8: In cases where a message is missing and the missing message causes an event on the Ainterface as for example the HANDOVER DETECTION is lost then no HANDOVER DETECTwill be sent to the MSC.

9: CONNECTION FAILURE INDICATION (cause "Transcoder failure") is valid for TCHconnections only.

11: In this state there should be no resources allocated in the BTS, therefore there should benone of these events coming from the BTS.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 58/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

12: The MSC should not be sending any of these messages at this time in the protocol - see ref[15].

13: The request in the queue is de-queued and the waiting timer (T_qho) is stopped.

14: The release on the A (A interface Circuit), Abis & Air interfaces are deferred until eitherT9113 expires or the BSC receives the HANDOVER COMPLETE from the MS.

15: The release of the A interface is initiated immediately.

17: The CLEAR COMMAND contains the cause "Radio interface failure, reversion to oldchannel".

18: All other causes other than "Radio interface failure, reversion to old channel".

19: The Channel activation procedure continues. The Channel will be released with theappropriate Resource release scenario.

20: If the cause is "SCCP inactivity timer expiry" then a Reset circuit procedure will be initiatedfor TCH connections so as to Clear the connection.In the case where it is the reception of SCCP RELEASED any A interface channel associatedto the connection is released.

21: The Power control and handover algorithms are started when the MS is connected after thereception of the ESTABLISH INDICATION & therefore these messages are ignored.

22: The messages are processed by Power control & handover Algorithms.

23 For SAPI 0 the message is discarded.For SAPI 3 the message is rejected with a SAPI "N" REJECT message, cause = "ProtocolError between BSC and MSC".

24 The release of the A interface is initiated immediately and the release of the Abis and Airinterfaces is initiated with release scenario Ref [6] EHT1101.

25 In some cases, the Target BSC must trigger a classmark interrogation procedure. See ref [16]

26 To recognise an incoming directed retry, see section 3.2.4.6.1.

The CHANNEL MODE MODIFY message is sent without starting any timer. When CHANNELMODE MODIFY ACK or CHANNEL MODE MODIFY NACK is received, it is discarded. seeref [18].

3.2.4.1. - SCCP Connection Establishment

The SCCP connection may be established in the following ways as shown in the message sequencecharts below.

The first shows the establishment of the SCCP connection without any exchange of Layer 3messages. The HANDOVER REQUEST is sent after the SCCP connection has been established. Thesecond shows the establishment of the SCCP connection where the initial SCCP CONN REQ haswithin it a HANDOVER REQUEST message.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 59/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Fig 3./14 HO Request after SCCP Establishment

1 The MSC sends an SCCP CONN REQUEST to the target BSC without any messagecontained.

2 The target BSC: returns the SCCP CONN CONFIRMATION to the MSC.

3 Once the SCCP connection is established the MSC now sends the HANDOVER REQUESTmessage.

Fig 3./15 HO Request during SCCP Establishment

1 The MSC sends an SCCP CONN REQUEST to the target BSC with a HANDOVERREQUEST message contained within it.

2 The target BSC: returns the SCCP CONN CONFIRMATION to the MSC.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 60/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

The third shows an SCCP CON REQ where the message contained is unknown. In this case theSCCP connection is confirmed and the timer T9110 runs to supervise the reception of theHANDOVER REQUEST message.

It must be noted that the SCCP connection is always confirmed before either, the HANDOVERREQUEST ACK, or HANDOVER FAILURE, or CLEAR REQUEST messages are sent.

Fig 3./16 HO Request after SCCP Establishment with Unknown L3 Message

1 The SCCP CON REQ is sent with a message. This message is either unknown or incorrect(eg CIPHER MODE COMMAND). The SCCP CON REQ has no error, thus the connection isconfirmed.

2 The timer T9110 is started to supervise the reception of the HANDOVER REQUEST.

3 The MSC sends the HANDOVER REQUEST and the timer is stopped.

3.2.4.2. - SCCP Connection Failure

The SCCP connection may fail in the MSC as shown below in figure 18.

The first is a failure of the SCCP protocol either due to unknown addresses of the SCCP or someformat error. In this case the SCCP CONN REQ is explicitly refused by an SCCP CONN REFUSE.

Fig 3./17 HO Request during SCCP Connection - SCCP Failure

1 The SCCP CONN REQ with a format error or addressing error

2 The target BSC responds with an SCCP CONN REFUSE message.

The second is a failure of the MSC to send a HANDOVER REQUEST. This is signalled by the expiryof T9110. In this case an SCCP RELEASED is sent to the MSC.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 61/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Fig 3./18 SCCP Establishment with T9110 Expiry

1 The SCCP connection is established but no HANDOVER REQUEST is received or anunknown message or incorrect message is received.

2 The timer T9110 is started so as to ensure that the SCCP connection is not left hangingwithout a transaction associated with it.

3 The timer expires and the SCCP is released.

3.2.4.3. - Target BSS errors

The section "HANDOVER REQUEST message processing" shows in short form the behaviour of thetarget BSS when it has detected that there is a problem with the received HANDOVER REQUESTmessage.

This section shows the general behaviour of the target BSS when these errors are detected, with theexception of the unknown A interface circuit or Blocked circuit cases which are shown in the followingsections.

When an error is detected the target BSS immediately fails the external handover attempt by sendinga HANDOVER FAILURE message and starts the timer T9110.

This timer allows the MSC to either Clear the SCCP connection normally or (in cases where there areerror in the A Interface circuit selected) to try another external handover attempt for the same MSconnection - see following sections.

The message sequence diagram below shows the Target BSS behaviour.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 62/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Fig 3./19 HO Request Error Behaviour

1 The SCCP connection is initiated by the MSC for the external handover to take place.The target BSS confirms the SCCP connection request.

2 The HANDOVER REQUEST is sent by the MSC.The target BSS detects an error in the Request and refuses the external handover by sendinga HANDOVER FAILURE message - for cases and error causes see section in this document"HANDOVER REQUEST message checking".

3 The target BSS starts the timer T9110.The timer T9110 allows the MSC to either:

1) release the SCCP connection;2) or to send another HANDOVER REQUEST.

For case 2 the MSC can initiate another attempt to perform an external handover.

3.2.4.4. - Target BSS error BLOCK message is sent

If in the HANDOVER REQUEST message the MSC has selected an A interface Circuit which isunable to be used by the target BSS the target BSS refuses the Request, by sending a HANDOVERFAILURE (for causes see section "HANDOVER REQUEST message checking").

In addition the target BSS sends a single BLOCK message to the MSC. This message is sent inconnectionless mode. Unlike the Blocking procedure there is no timer started for this procedure.

On reception of the BLOCK message the MSC should remove the indicated circuit from the free Ainterface circuit list maintained by the MSC and mark it as Blocked.

When the A interface circuit is once more available for use in carrying traffic the BSS will triggerUnblocking procedure so that the A Interface circuit is once more available for traffic in the MSC - seeref [11].


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 63/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Fig 3./20 HO Request on Unavailable Circuit


2 The HANDOVER REQUEST is sent by the MSC.The target BSS detects that the A interface circuit is not usable in the target BSS, so anHANDOVER FAILURE message is sent (for cause values see section "HANDOVERREQUEST message checking").

3 The target BSS starts the timer T9110 in this case the target BSS is awaiting the MSC topossibly reselect the A Interface circuit and initiate another external handover procedure.

4 The target BSS also sends a BLOCK message in connectionless mode for the A interfacecircuit contained in the original HANDOVER REQUEST.One BLOCK message is sent by the target BSS in this case, there is no timer started by thetarget BSS to supervise the response from the MSC - see ref [11] for more information.

3.2.4.5. - Target BSS error UNEQUIPPED CIRCUIT message is sent

The UNEQUIPPED CIRCUIT message is only sent when the BSS is operating in the GSM Phase 2mode (ie GSM PHASE == PHASE 2). In addition the message may be disabled from being sent byuse of the O&M Parameter (UNEQUIP_CIR_EN).

If in the HANDOVER REQUEST message the MSC has selected an A interface Circuit which iseither: Unknown; Known but not equipped or configured (this does not include X25 or SPL circuits); orin use for CCITT No 7; by the target BSS the target BSS refuses the Request, by sending aHANDOVER FAILURE (for causes see section "HANDOVER REQUEST message checking").

In addition the target BSS sends a single UNEQUIPPED CIRCUIT message to the MSC. Thismessage is sent in Connectionless mode.

On reception of the UNEQUIPPED CIRCUIT message the MSC should remove the indicated circuitfrom the free A interface circuit list maintained by the MSC. It is up to O&M procedures in the MSC totrigger Maintenance or Configuration actions to align MSC & BSS A interface circuit configurationsand states.

The following message sequence chart shows the procedure when the target BSS is operating inGSM Phase 2 mode on A interface and the UNEQUIPPED CIRCUIT is allowed to be sent by thetarget BSS.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 64/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Fig 3./21 HO Request on Unequipped Circuit


2 The HANDOVER REQUEST is sent by the MSC.The target BSS detects that the A interface circuit is either: not known; known but notequipped or configured (this does not include X25 or SPL circuits); or in use for CCITT No 7signalling; in the target BSS, so an HANDOVER FAILURE message is sent (for cause valuessee section "HANDOVER REQUEST message checking").

3 The target BSS starts the timer T9110 in this case the target BSS is awaiting the MSC topossibly reselect the A Interface circuit and initiate another external handover procedure.

4 The target BSS also sends an UNEQUIPPED CIRCUIT message in connectionless mode forthe A interface circuit contained in the original HANDOVER REQUEST - see ref [11] for moredetail.

3.2.4.6. - HANDOVER REQUEST message processing

Before the target BSC enters the handover protocol the following checks and actions are taken on theHANDOVER REQUEST message before proceeding with the handover.

For processing of classmark IEs, see ref [16]

Event ActionsOptional informationelement CIC is present

Send HANDOVER FAILURE (cause "Protocol error betweenMSC and BSC") - ref [6] EHT0600

Start T9110next state (WAIT MSC RESP).

Table 3./16 Specific checking for EHO towards SDCCH


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 65/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

OIE CIC is not present Send HANDOVER FAILURE (cause "Protocol error betweenMSC and BSC") - ref [6] EHT0600

Start T9110next state (WAIT MSC RESP).

OIE CIC is present butindicates timeslot 0

Send HANDOVER FAILURE (cause “Requested terrestrialresource unavailable”) -ref[6] EHT0705

OIE CIC is present butis unavailable due toO&M intervention

Send HANDOVER FAILURE (cause "Requested terrestrialresource unavailable") - ref [6] EHT0603

Send a single BLOCK message ref[11]Start T9110next state (WAIT MSC RESP)

OIE CIC is present butis unavailable due toits use in anotherconnection

Send HANDOVER FAILURE (cause "Terrestrial resourcealready allocated") - ref [6] EHT0604

Start T9110next state (WAIT MSC RESP)

OIE CIC is unknown oris known but notequipped or configured(this does not includeX25 or SPL circuits) oris in use for CCITT No7

Send HANDOVER FAILURE (cause "BSS not equipped") - ref[6] EHT0605

send UNEQUIPPED CIRCUIT message - See Note 1Start T9110next state (WAIT MSC RESP).

MIE Channel Typeoctet 3 indicates data& octet 4 indicates halfrate or a nonsupported data rate

Send HANDOVER FAILURE (cause "Requested transcoding/rate adaption unavailable") - ref [6] EHT0602Start T9110next state (WAIT MSC RESP)

The BSC recognisesno code point for acodec, amongst allproposed in MIEChannel Type octet 5.

Send HANDOVER FAILURE (cause "Requested speechversion unavailable") - ref [6] EHT0620Start T9110next state (WAIT MSC RESP)

Requested codecs inMIE Channel Typeoctet 5 do not matchany codec allowed inthe cell

Send HANDOVER FAILURE (cause "Requested speechversion unavailable") - ref [6] EHT0620Start T9110next state (WAIT MSC RESP)

Table 3./17 Specific checking for EHO towards TCH

Note 1: The UNEQUIPPED CIRCUIT message is sent only if the GSM_PHASE == PHASE 2 andenabled by O&M parameter (EN_UNEQUIPPED_CIRCUIT) - see ref [11] for more detail.

OIE Cell Identifier(Target) is present anddoes not match to theone held in the BSS -See Note 1

Send HANDOVER FAILURE (cause "Invalid cell") - ref [6]EHT0601


Table 3./18 Specific checking for Single Cell BSS

Note 1: If this IE is not present for a Single cell BSS then it is accepted, this behaviour is independentof the GSM PHASE flag.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 66/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

OIE Cell Identifier(Target) is not present

Send HANDOVER FAILURE (cause "Protocol error betweenMSC and BSC") - ref [6] EHT0600


OIE Cell Identifier(Target) is present butdoes not match oneknown to the BSS

Send HANDOVER FAILURE (cause "Invalid cell") - ref [6]EHT0601


Table 3./19 Specific checking for Multi-Cell BSS

MIE Channel Typecombination notsupported - See Note2

Send HANDOVER FAILURE (cause "Protocol error betweenMSC and BSC") - ref [6] EHT0600;start T9110

next state (WAIT MSC RESP)MIE’s Encryption Infoor Classmark Info orCell Identifier (serving)is missing

Send HANDOVER FAILURE(cause "Protocol error betweenMSC and BSC") - ref [6] EHT0600


OIE Radio ChannelIdentity is present

Ignore IE

OIE Interference Bandis present

Ignore IE

MIE EncryptionInformation fieldPermitted algorithmsis coded "00000000" -see Note 1



MIE EncryptionInformation Lengthfield value is morethan 9 (key length ismore than 8 octets)

Send HANDOVER FAILURE (cause "Incorrect value") ref[6]EHT0607Start T9110next state (WAIT MSC RESP)

If at least oneencryption algorithm isallowed and cipher keyis not present (MIEENCRYPTIONINFORMATION has alength of 1)

Send HANDOVER FAILURE (cause "IE or field missing")ref[1] EHT0608Start T9110next state (WAIT MSC RESP)

Table 3./20 General Message Checking

Note 1: This coding is not allowed by GSM. Note "00000001" is used to indicate No encryption.

Note 2: Signalling on: full rate or half rate channels is not supported.

Note that the BSC will handle the coding of the Channel type field independent of the GSMPHASE mode.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 67/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

If the MIE EncryptionInformation fieldPermitted algorithmhas more than one bitset


Start T9110next state (WAIT MSC RESP)(The BSC does not allow this handover to occur as itdoes not know what Ciphering algorithm is in use onthe old channel)

Table 3./21 Ciphering Checks - GSM Phase 1 MSs

If the MS Cipheringcapabilities do notmatch with the BTSciphering capabilitiesor the allowed MSCciphering requirements(as specified in theMIE Encryption Infofield Permittedalgorithms - see ref[14])

Send HANDOVER FAILURE (cause "Ciphering algorithm notsupported") - ref [6] EHT0606Start T9110next state (WAIT MSC RESP)

Table 3./22 Ciphering Checks - MS & BTS Capabilities & MSC Requirements(With exceptions as shown in Table 3./21)

After all the above checks are successfully made, the target BSC performs the following:

• For TCH calls, the associated CIC is allocated to the SCCP transaction - this is required in caseof an abnormal SCCP release where upon a Reset circuit procedure would have to be carried out;

if it was anunsuccessful CICallocation

Send HANDOVER FAILURE (cause "Requested terrestrialresource unavailable") - ref [6] EHT0701Start T9110next state (WAIT MSC RESP)

Table 3./23 Unsuccessful CIC allocation

• if the CIC allocation is successful (TCH only) a request is made to allocate an RF resource - ref[9].


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 68/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

if it was a successfulresource allocation

Send a CHANNEL ACTIVATION message to the BTS - seesection on CHANNEL ACTIVATION message building

Start T9103next state is AWAIT CHN ACT ACK.

if the queue is full If a CIC is allocated then CIC state is made FREEsend HANDOVER FAILURE (cause "No radio resourceavailable")start T9110next state (WAIT MSC RESP)

if the timer T_qhoexpired in the queuingalgorithm. ie therequest was in thequeue too long

If CIC is allocated then CIC state is made FREEsend HANDOVER FAILURE (cause "No radio resourceavailable") - ref [6] EHT0800start T9110next state (WAIT MSC RESP)

if the queuing requestwas pre-empted by ahigher priority request

If a CIC is allocated then CIC state is made FREE -send HANDOVER FAILURE (cause "No radio resourceavailable") - ref [6] EHT0800start T9110next state (WAIT MSC RESP)

if there is an internalBSC problemallocating the RFchannel

If a CIC is allocated then CIC state is made FREEsend HANDOVER FAILURE (cause "No radio resourceavailable") - ref [6] EHT0702start T9110next state(WAIT MSC RESP)

If the cell isunavailable due toO&M

If a CIC is allocated then CIC state is made FREEsend HANDOVER FAILURE (cause "O&M intervention") -ref [6] EHT0704start T9110next state(WAIT MSC RESP)

if incoming handoveris inhibited in the cell(EN_IC_HO is set toFALSE

If a CIC is allocated then CIC state is made FREEsend HANDOVER FAILURE (cause "O&M intervention") -ref [6] EHT0704start T9110next state(WAIT MSC RESP)

Table 3./24 Actions after Resource Request Returns

3.2.4.6.1. - Detection of incoming external directed retry

The incoming request may be an external directed retry. Since some special procedures must beperformed in this case, the target BSC should recognise that the HANDOVER REQUEST messageconcerns an external directed retry to a full rate channel for speech version 1, for a phase 1 MS.There are several means, depending of the MSC construction of the HANDOVER REQUESTmessage.

If one of the following condition is fulfilled, then the incoming request is assumed to be an incomingexternal directed retry to a full rate channel for speech version 1, for a phase 1 MS :

If OIE Current Channel is present in HANDOVER REQUEST message:

CARSPECIAUX• Channel Mode field in OIE Current Channel (if present) is "signalling only" ANDChannel Type is "full rate speech version 1" (*) AND MS revision level is "Phase 1"

If OIE Current Channel is not present in HANDOVER REQUEST message :


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 69/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

• Channel Type is "full rate speech version 1" (*) AND MS revision level is "Phase 1. The cause isnot checked.

(*) : this means : speech/data indicator field is "speech" AND channel rate and type field is "full rateTCH Bm" AND permitted speech version is only "GSM speech full rate version 1".

In this case, at the end of the external directed retry protocol, the BSC shall send to the MS aCHANNEL MODE MODIFY message, without starting any timer. When CHANNEL MODE MODIFYACK or CHANNEL MODE MODIFY NACK is received, it is discarded.

3.2.4.7. - CHANNEL ACTIVATION message construction

Once an RF channel has been allocated the target BSC builds a CHANNEL ACTIVATION message.This message is sent to the target BTS to activate the channel.

The BSC uses the following information in the HANDOVER REQUEST message and O&M flags andparameters in the building of this message:

MIE Channel Type

MIE Encryption Info

MIE Classmark Info

OIE Downlink Dtx Flag (used in TCH speech calls only)

O&M PARAMETERS and FLAGS

DTX-INDICATOR

DTX-INDICATOR_SACCH

BS_TXPWR_MAX

MS_TXPWR_MAX

DOWNLINK_DTX_ENABLE


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 70/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Informationelement

Info field Setting or Algorithm

MIE Channelnumber

Indicates the RF Channel allocated by the Dedicated radio resourcemanager - see ref [9]

MIE Activationtype

If serving cell is not controlled or unknown by the target BSC thenasynchronous handover is indicated

If the serving cell & target cell are synchronised the synchronoushandover is indicated, else asynchronous handover is indicated.

MIE Channelmode

DTXd see reference [20]

DTXu see reference [20]

Speech orData Ind(octet 4)

Set equal to octet 3 of the MIE Channel Type in the HANDOVERREQUEST message.

Chan rateand Type(octet 5)

Set to "SDCCH" if Speech or Data Ind indicates "Signalling".else its value ("Full rate TCH channel Bm or half rate channel Lm")depends on the radio resource allocation procedure (see ref [9].

Speechencodingalgorithm(octet 6)

If Speech or Data Ind indicates "Signalling" - set to "no resourcerequired"

If Speech or Data Ind indicates "Speech" - set to "GSM speech codingalgorithm version 1" or to "GSM speech coding algorithm version 2"

If Speech or Data Ind indicates "Data"

if T/NT of octet 5 of the MIE Channel Type in the HANDOVERREQUEST message indicates "Transparent Service" - set equal tooctet 5 of the MIE Channel Type in the HANDOVER REQUESTmessage.

if T/NT of octet 5 of the MIE Channel Type in the HANDOVERREQUEST message indicates "Non Transparent Service" - and Rateof octet 5 indicates 6Kbit/s or 12Kbit/s - set equal to "12 Kbit/s", seeNote 1.

OIE ChannelIdent

The Channel Identification IE contains the 04.08 Channel Description &04.08 Mobile allocation for the activated channel.

The Channel Description field use in this message may be used in thebuilding of the HANDOVER COMMAND message

OIE EncryptionInfo element

This IE is always sent.

The setting is as specified in ref [3 & 9]

CIE Handoverreference

This IE is included for this procedureIt is calculated by the target BSC and should be randomly generated.

The BTS uses this value to compare with the value in the HANDOVERACCESS when the MS performs the handover access procedure.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 71/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

OIE BS Power set to BS_TXPWR_MAX - the maximum allowed power is used at thestart so as to ensure a high success rate of handover.

OIE MS Power Is set to min(MAX_PWR_MOBILE, MS_TXPWR_MAX)where MAX_PWR_MOBILE is obtained from the CLASSMARK INFO inthe HANDOVER REQUEST.The MS should start transmitting at the maximum allowed power in thecell or at the maximum that it can transmit, this will ensure a highsuccess rate of handover.

CIE Timingadvance

Not used

This is never used in an asynchronous handover as the timing advanceis calculated when the MS performs the handover access procedure.In synchronous handover the timing advance can not be included as theinformation is not held in any of the messages sent in the externalhandover protocol. The timing advance is calculated when the MS sendsthe HANDOVER ACCESS message.

OIE BS Powerparameters

Not used

OIE MS Powerparameters

Not used

OIE Physicalcontext

Not used

OIE SACCHInformation

This element contains the setting of system information filling on SACCHfor THIS channel. It is included only if there are additional or modifiedsystem information messages to be transmitted.

If present, it updates the system information previously intended to betransmitted. see ref [17]

Table 3./25 Channel Activation Message

Note 1 : For this release the Alcatel BSS only supports data calls on full rate channels with 12Kbit/srate adaption

3.2.4.8. - HANDOVER REQUEST ACK message construction

Once the channel has been successfully activated (ie reception of CHANNEL ACTIVATION ACK) theHANDOVER REQUEST ACK message is built and sent back to the MSC.


MIE Message type Set to HANDOVER REQUEST ACK

MIE Layer 3 Information See the next section on HANDOVER COMMAND messageconstruction for the building of this IE.

OIE Chosen channel This IE is sent only when the BSS was given a choice by theMSC.

OIE Chosen Encryptionalgorithm

This IE is sent when the MSC allows the BSC to choose frommore than one ciphering algorithm.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 72/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

OIE Speech Version (chosen) This IE is included when the target BSS made the choice of thecodec to use, among more than one given by the MSC.

Table 3./26 Handover Request Ack Message:

3.2.4.9. - Layer 3 IE HANDOVER COMMAND message construction

The Layer 3 Information element in the HANDOVER REQUEST ACK contains the HANDOVERCOMMAND message which is to be passed to the MS. The following table shows the construction ofthe HANDOVER COMMAND message towards a channel which is fully supported by the E-GSMband (G1 range and/or P-GSM range).


MIE Cell description For P-GSM, set NCC, BCC & BCCH ARFCN (High & Lowpart <1..124>) to the values allocated to the target BTS.

MIE First Channel description,after time

Set to the same coding given in the Channel Descriptionfield, in the Channel Identification MIE of the CHANNELACTIVATION message.

MIE Handover reference Set as sent to the BTS in the CHANNEL ACTIVATIONmessage.

MIE Power command andAccess type

Set to MIN(P, MS_TXPWR_MAX target cell)Field Access type is set to "sending of HANDOVERACCESS is mandatory"

OIE Synch info Phase 1 MS : This IE is always included as required in GSMETR 09.94 (see reference [18]).

Phase 2 MS : This IE is only included for synchronousHandover.

ROT bit is settable depending on customer request

NCI bit is settable depending on customer request

CIE Frequency short list, aftertime

This IE is used when a G1 band TCH is allocated by thededicated radio resource entity and frequency hopping is tobe applied on the TCH. For the format to use, see ref [21].This IE is sent only if "CIE Frequency list, after time" is notsent. See note 1.

CIE Frequency list, after time This IE is used when a G1 band TCH is allocated by thededicated radio resource entity and frequency hopping is tobe applied on the TCH. For the format to use, see ref [21].This IE is sent only if "CIE Frequency short list, after time" isnot sent. See note 1.

CIE Cell chan description This IE is used when a P-GSM band TCH or SDCCH isallocated by the dedicated radio resource entity andfrequency hopping with more than one frequency is to beapplied on the channel and when CIE “Frequency ChannelSequence, after time” cannot code all the frequencies used.Bitmap 0 format is used.

Used together with CIE “Mobile Allocation, after time” todescribe frequency hopping sequence


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 73/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

OIE Mode of the first channel Sent only if the channel mode is changed. See note 3.

OIE Channel description of thesecond channel

Not used - relevant to Lm + Lm.

OIE Mode of the secondchannel

Not used - relevant to Lm + Lm.

CIE Frequency channelsequence, after time

This IE is used when a P-GSM band TCH or SDCCH isallocated by the dedicated radio resource entity andfrequency hopping with more than one frequency is to beapplied on the channel, and if this IE can code allfrequencies.

In the non hopping case the MS receiving this message withthis information element included should be aware that thechannel is non hopping from the CHANNEL DESCRIPTIONMIE therefore this IE should be ignored.

CIE Mobile allocation, after time Used only if CIE “Cell channel description” is used.

OIE Starting time Not used (used during Frequency redefinition).

CIE Real time difference Not used (Used for Pseudo synchronous handover)

CIE Timing advance Not used (Used for Pre-synchronous handover)

CIE Frequency short list, beforetime

Not used (used during Frequency redefinition and only sentto Phase 2 MSs).

CIE Frequency list, before time Not used (used during Frequency redefinition and only sentto Phase 2 MSs).

OIE Channel description of thefirst channel, before time


OIE Channel description of thesecond channel, before time

Not used (used during Frequency redefinition, for Lm + Lm,and only sent to Phase 2 MSs).

CIE Frequency channelsequence, before time


CIE Mobile allocation, beforetime


OIE Cipher mode setting Never sent to Phase 1 MSs.

GSM Phase 2 MSs - Always sent indicating the Cipheringalgorithm chosen - see ref [14].

Table 3./27 Handover Command Message towards a GSM900 channel

Note 1 : The sending of the "Frequency short list, after time" or the "Frequency list, after time" isdependant on the range of the frequencies. See ref [21]


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 74/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

HANDOVER COMMAND (Inter-cell Synchronous & Asynchronous) for Phase 1 or 2 MSs towards aDCS channel.


MIE Cell description Set NCC, BCC & BCCH ARFCN (High & Low part<0..1023>) to the values allocated to the target BTS

MIE First Channel description,after time

Set to the same coding given in the Channel Descriptionfield, in the Channel Identification MIE of the CHANNELACTIVATION message.

MIE Handover reference Set as sent to the BTS in the CHANNEL ACTIVATIONmessage.

MIE Power command andAccess type

Set to MIN(P, MS_TXPWR_MAX target cell)Field Access type is set to "sending of HANDOVERACCESS is mandatory"

OIE Synch info Phase 1 MS : This IE is always included as required in GSMETR 09.94 (see reference [18]).

Phase 2 MS : This IE is only included for synchronousHandover.

ROT bit is settable depending on customer request

NCI bit is settable depending on customer request

CIE Frequency short list, aftertime

This IE is sent if hopping is applied and if the "Frequency list,after time" is not used - see Note 1

CIE Frequency list, after time This IE is sent if hopping is applied and if the "Frequencyshort list, after time" is not used - see Note 1 & 2

CIE Cell chan description Not used.

OIE Mode of the first channel Sent only if the channel mode is changed. See note 3.

OIE Channel description of thesecond channel

Not used - relevant to Lm + Lm

OIE Mode of the secondchannel

Not used.- relevant to Lm + Lm

CIE Frequency channelsequence, after time

Not used..

CIE Mobile allocation of thesecond channel

Not used - relevant to Lm + Lm

OIE Starting time Not used (used during Frequency redefinition).

CIE Real time difference Not used (Used for Pseudo synchronous handover)

CIE Timing advance Not used (Used for Pre-synchronous handover)

CIE Frequency short list, beforetime


CIE Frequency list, before time Not used (used during Frequency redefinition and only sentto Phase 2 MSs).

OIE Channel description of thefirst channel, before time



MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 75/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

OIE Channel description of thesecond channel, before time


CIE Frequency channelsequence, before time


CIE Mobile allocation, beforetime


OIE Cipher mode setting Never sent to Phase 1 MSs.

GSM Phase 2 MSs - Always sent indicating the Cipheringalgorithm chosen - see ref [14].

Table 3./28 Handover Command Message towards a DCS cell

Note 1 : The sending of the "Frequency short list, after time" or the "Frequency list, after time" isdependant on the range of the frequencies. See ref [21]

Note 2 : It is possible (by BSS parameter) to choose between the inclusion of the "Frequency list,after time" or "Frequency short list, after time".

Note 3 : If one of the following conditions is fulfilled, the OIE Mode of the first channel must not beincluded in HANDOVER COMMAND message :

• In HANDOVER REQUEST message, Current Channel IE and Channel Type IE indicate both"signalling".

• In HANDOVER REQUEST message, Current Channel IE and Channel Type IE indicate thesame radio interface data rate.

• In HANDOVER REQUEST message, Current Channel IE and Channel Type IE indicate both"speech" AND the chosen speech version is the same as in Speech Version IE.

In the building of the HANDOVER COMMAND message the synchronisation indication tells themobile which type of protocol is to be performed on the Air interface. In the case where theSynchronisation indicates synchronous, the MS knows that the timing advance that it is presentlyusing will be used in the target cell, this matches the setting given in the CHANNEL ACTIVATIONmessage given to the target BTS.

The power used by the MS is set to the maximum capable (or allowable if smaller) for the MS on thenew channel, this ensures a high probability of success. The reason for not using the MS powerobtained from the PHYSICAL CONTEXT CNF message, is due to the fact that there is no relationshipbetween the power used on the serving cell to the reception of the MS on the new target.

3.2.4.10. - CHANNEL MODE MODIFY message construction

The CHANNEL MODE MODIFY message is sent in some cases defined in note 26, p. 62.

Information element Setting

MIE Channel Description same as in HANDOVER COMMAND

MIE Channel mode set to "speech full rate version 1" since themessage is only sent in this context.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 76/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

3.2.4.11. - DTAP & BSMAP procedures in the Target BSS

The handling of DTAP and BSMAP in the target BSS during an external handover are as follows:

From the sending of the HANDOVER REQUEST ACK), to either: the reception of the HANDOVERCOMPLETE message; or the expiry of T9113 (ie during the AWAIT HO DETECT, AWAIT ESTABIND & AWAIT HO CMPLT states):

• DTAP messages will buffered (up to 5 messages will be buffered);

• ASSIGNMENT REQUEST messages will be discarded;

• HANDOVER COMMAND messages will be discarded;

• CIPHER MODE COMMAND message will be discarded.

All previously received messages will be discarded on failure, when the A interface connection isreleased (this also includes the case of a DTAP message received from the MSC in a SCCPRELEASED message).

The queued DTAP messages are sent on the reception of the HANDOVER COMPLETE from the MS.During dequeuing, only the first SAPI 3 message is sent to the MS if the SAPI 3 connection is alreadyestablished or the establishment of a SAPI 3 connection has been initiated (in which case, the firstSAPI 3 message is forwarded to the MS as soon as the connection is established), subsequent SAPI3 messages in the queue are discarded.

All connection oriented messages received before the sending of the HANDOVER REQUEST ACKwill be discarded (with the exception of the TRACE message).

3.2.5. - Target BTS Asynchronous Handover Protocol

Once the channel is activated the target BTS immediately starts the ciphering (if applied) of anyframes sent to the air interface.

The target BTS can only decode access bursts coming in from the air interface whilst it is awaiting theHANDOVER ACCESS message.

The target BTS should exhibit the following behaviour during an asynchronous handover procedure(internal or external).

A list of logical BTS states is shown below.


The BTS is awaiting the HANDOVER ACCESS messagefrom the MS and Enciphering is applied

AWAIT HO ACC

The BTS is awaiting the SABM from the MS, the PHYSICALINFO message is being sent and the timer T3105 is running

AWAIT SABM or AWAITANY CORRECT FRAME

The LAPDm is established and the timer T_CFI_Tr isrunning. During this state all transcoder alarms are ignored.

T_CFI_Tr RUNNING

This state is introduced as the exit state ACTIVE

Table 3./29 BTS States - Asynch HO


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 77/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

STATE

EVENT

AWAIT HO ACC AWAITSABM or ANY

CORRECTFRAME

T_CFI_TrRUNNIN

G

ACTIVE

HANDOVERACCESSNote 4

Decipher (if applied)

Set connection with TR (TCH) Note 2

Send HANDOVER DETECTION

Decode normal bursts

Calculate TA

Set TA in L1 header of SACCH msgs and TAalgorithm

Send PHYS INFO with TA in unack mode

X = 0

Start T3105

next state(AWAIT SABM or ANY CORRECTFRAME

Don’t care N/A N/A

Table 3./30 Target BTS State Table - Asynch HO


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 78/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

STATEEVENT

AWAITHO ACC

AWAIT SABM or ANYCORRECT FRAME

T_CFI_TrRUNNING

ACTIVE

DL ESTAB IND

BTS Layer 2 ->BTS Layer 3 orany correctframe

Note 5

N/A Stop T3105

Start Radio-link failalg

Send EST INDIC

Start T_CFI_Tr

next state(T_CFI_TrRUNNING)

Stop T_CFI_Tr

Start T_CFI_Tr

Note 1

Start T_CFI_Tr


Note 1

T3105 EXPIRY N/A X == NY1

Send CONN FAIL IND(cause "HO acc fail")

Send DL REFUSEREQ Note 6

next state (ACTIVE)

X < NY1

X = X + 1

Send PHYS INFO inunack mode

Start T3105

N/A N/A

T_CFI_TrEXPIRY

N/A N/A next state(ACTIVE)

Note 1

Not Applicable

Note 1

Remotetranscoderalarm

N/A Send CONN FAIL IND(Remote transcoderfailure)

Discard

Note 1

Send CONN FAILIND (Remotetranscoder failure )

Note 1

Table 3./31 Target BTS State Table - Asynch HO (Cont)

Note 1: These states and actions are also in the serving BTS.

Note 2: When the transcoder connection is set (for TCH only connections) the BTS awaits thereception of TRAU frames from the BSC. It is at this point in the protocol that the detection ofTranscoder failure in the BTS starts. When the BSC receives the HANDOVER DETECTmessage it is meant to perform the switch through in which case the BTS will start to receivethese TRAU frames

Note 3: MS & BS Power control is started when the Layer 2 LAPDm SAPI 0 connection is established.However BS Power control may be inhibited for certain channels on a FU which is carryingthe BCCH frequency see ref [8] for BS Power control inhibition.

Note 4: Only a correct HANDOVER ACCESS will be accepted. Any incorrect HANDOVER ACCESSwill be discarded.

Note 5: The event which will be accepted at this point will depend of the T3105_D_STOP orT3105_F_STOP parameter. If the parameter(s) is set to ONLY SABM, then only the


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 79/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

reception of an SABM for SAPI 0 will stop the timer. If the parameter(s) is set to ANYFRAME, then any correctly received TCH or Layer 2 frame will cause T3105 to be stopped. Inboth cases, only SABM SAPI 0 will cause the sending of ESTABLISH INDICATION.

Note 6: The Layer 2 LAPDm Refuse option is set at this point. Note this feature is an ALCATEL BTSfeature and is not specified in GSM.

3.2.6. - Target BTS Synchronous Handover Protocol

Once the channel is activated the target BTS immediately starts the ciphering (if applied) of anyframes sent to the air interface. The dedicated SYSTEM INFORMATION messages are immediatelysent.

In the case of external synchronous handover the Layer 1 header will indicate that the Timingadvance information is invalid.

In the case of internal synchronous handover the Layer 1 header will indicate the timing advancegiven in the CHANNEL ACTIVATION message. If the timing advance information is not present thenthe Layer 1 header will indicate that the Timing advance information is invalid.

The target BTS can only decode access bursts coming in from the air interface whilst it is awaiting theHANDOVER ACCESS message.

The target BTS should exhibit the following behaviour during a synchronous external or synchronousinternal handover procedure.

A list of logical BTS states are shown below.

STATE DESCRIPTION ABBREVIATIONThe Channel is activated and the BTS is awaiting theHANDOVER ACCESS from the MS

INTRA AWAIT HO ACC

The BTS is awaiting for either the SABM SAPI 0 or anycorrect frame from the MS. The timer T3106 is running.

INTRA AWAIT SABM orANY CORRECT FRAME

The LAPDm is established and the timer T_CFI_Tr isrunning. During this state all transcoder alarms are ignored.

T_CFI_Tr RUNNING

This State is introduced as the exit state for the procedure,after the end of a successful access by the MS

ACTIVE

Table 3./32 BTS States - Synch HO


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 80/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

STATE

EVENT

INTRA AWAIT HO ACC INTRA AWAITSABM or ANY

CORRECTFRAME

T_CFI_TrRUNNING

ACTIVE

HANDOVERACCESS

Start Deciphering (if applied)

Send HANDOVERDETECTION

Sets the Transcoder (TCHonly) Note 1

Calculate TA

Set TA in Layer 1 header &TA Algorithm

Start T3106

next state (INTRA AWAITSABM or ANY CORRECTFRAME)

N/A N/A N/A

INCORRECTHANDOVERACCESS

Don’t care Don’t care N/A N/A

DL ESTAB INDBTS Layer 2 ->BTS Layer 3 or anycorrect frame - seeNote 2

Don’t care Stop T3106

Send ESTABLISHINDICATION

Start Radio linkfailure algorithm

Start T_CFI_Tr


StopT_CFI_Tr

StartT_CFI_Tr

StartT_CFI_Tr


T3106 EXPIRY N/A Send DL-REFUSE-REQ

Send CONN FAILIND (HO acc fail)

next state(ACTIVE)

N/A N/A

T_CFI_Tr EXPIRY N/A N/A next state(ACTIVE)

N/A

Remote transcoderalarm(TCH only)

N/A Send CONN FAILIND (Remotetranscoder alarm)

Don’t care SendCONNFAIL IND(Remotetranscoderalarm)

Table 3./33 Target BTS State Table - Synch HO


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 81/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Note 1: When the transcoder is set (TCH only). The target BTS expects to receive the TRAU framesfrom the Transcoder. It is at this point that the target BTS will start to detect transcoder failureas the BSC has not yet made the switch path. When the BSC receives the HANDOVERDETECTION message it is meant to perform the switch through in which case the BTS willstart to receive these TRAU frames. In the event that the HANDOVER DETECTIONmessage is lost (on Abis) the BSC will make the switch through either on the reception of theESTABLISH INDICATION SAPI 0 or upon the HANDOVER COMPLETE (in the case wherethe ESTABLISH INDICATION SAPI 0 is lost as well).

Note 2: The event which will be accepted at this point will depend of the T3106_D_STOP orT3106_F_STOP parameter. If the parameter(s) is set to ONLY SABM, then only thereception of an SABM for SAPI 0 will stop the timer. If the parameter(s) is set to ANYFRAME, then any correctly received TCH or Layer 2 frame will cause T3106 to be stopped. Inboth cases, only SABM SAPI 0 will cause the sending of ESTABLISH INDICATION.

3.2.6.1. BTS CHANNEL ACTIVATION message checking

see reference [7]

3.2.7. - MS Handover Protocol

This section describes in general terms the functions and procedures which the MS performs so as tomake the handover algorithm possible.

3.2.7.1. - Measurement Reporting

The MS carries out the following measurements and reports them to the serving BSS in theMEASUREMENT REPORT message on the uplink SACCH.

For the serving cell the MS reports:

ˆ Downlink level measurements;

ˆ Downlink quality measurements;

ˆ & Distance between the serving BSS and MS.

For Neighbour cells the MS reports (only 6 but may measure more of the Neighbours cells found inthe SYSTEM INFORMATION 5 message):

ˆ the BSIC & BCCH frequency number;

ˆ & Downlink level.

The MS will only measure those Neighbour cells which have a BSIC whose PLM colour code IEmatches with the coding in the PLMN PERMITTED IE transmitted to the MS in the SYSTEMINFORMATION 6. This rule allows the MS to provide measurements for neighbour cells of differentPLMN and therefore makes a handover between two PLMNs is possible. However GSM does notallow inter PLMN handovers.

Obviously an internal handover can never occur between two PLMNs, this would be performed usingan external handover, where the MSC would make the decision to handover to a different PLMN andallow charging to be applied as appropriate.

Whilst performing these measurements the MS keeps information on the synchronisation and TDMAtiming of all the cells which it is measuring. These measurement are used to ensure quicksynchronisation with the target cell when required.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 82/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

3.2.7.2. - Synchronous & Asynchronous Handover Procedure

The MS synchronous & asynchronous handover procedure consists of the following procedures:

ˆ Releasing of the old channel and serving cell

This process starts after the reception of the HANDOVER COMMAND message.

ˆ Attaching to the target cell

This process provides the synchronisation to the new cells TDMA frame synchronisation, so as toallow access to the new channel.

ˆ Attaching to the new channel

This process provides the method by which the MS may gain access to the slot on the TDMA frame.

ˆ Re-attaching to the serving cell

In case of failure, this procedure allows the re-synchronisation to the old cells TDMA frame.

ˆ Re-attaching to the old channel

In case of failure, this procedure allows the MS to gain access to the old channel.

3.2.7.3. - Releasing From The Old Channel & Serving Cell

The release from the old channel is initiated when the MS receives the HANDOVER COMMANDmessage. It is performed by:

ˆ suspending the sending of all signalling messages except for RR management messages;

ˆ releasing the LAPDm connection using a local end release;

ˆ and then disconnecting the Physical layer.

Note at this point in time, GSM seems to imply that RR procedures running (for example Ciphering)may still send messages to the LAPDm entity, it is a assumed that these are queued like all the othermessages coming from other sub-layers in the MS.

The releasing of LAPDm before the disconnection of the Physical layer may cause anomalies tooccur at Layer 2. The serving BSC at this point in time should be ignoring these errors.

The MS RR function may (as an option) store the context of the serving cell. This would include thesynchronisation, timing and the SYSTEM INFORMATION 5 & 6 for use if the procedure fails.

3.2.7.4. - Attaching To The Target Cell

The attaching procedure to the target cell, involves the synchronisation to the cell. This involves theaccessing of the FCCH and SCH.

The MS uses information gathered during the handover measurement procedures for use in thehandover procedure. The MS can only use this information if it can recognise the target cell in theHANDOVER COMMAND with a Neighbour cell which it has previously measured. This informationshould enable the synchronisation to the target cell to be made quicker.

If the target cell cannot be identified by the MS from previous information obtained in the handovermeasurement procedures it (this is possible since the MS only keeps measurements on neighbourcells for a certain length of time):

1 tunes to the BCCH frequency and detects the burst on the FCCH channel this is used toprovided the tuning to the carrier frequency.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 83/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

This process may take up to 460 ms to find the first FCCH burst and there after the time will dependon the MS’s phase lock loop performance.

2 and then accesses the bursts on the SCH channel which contain the SYNCHRONISATIONCHANNEL INFORMATION. This message contains the BSIC of the target cell and the current TDMAframe number. If the BSIC found in these burst does not match to the BSIC passed in theHANDOVER COMMAND message the MS will abort the handover and return to the old channel - seere-attaching to the serving cell and old channel. The TDMA frame number in this message allows theMS to synchronise itself to the TDMA frame.

The SCH burst is always placed after the FCCH burst thus allowing an easy access to the channelduring the synchronisation phase.

If the target cell can be identified from previous information measured by the MS. The MS will

1 tune to the BCCH frequency and program the internal synthesiser to the setting previouslymeasured.

2 the TDMA frame number is set accordingly.

The MS, during the handover measurements, ensures that the TDMA frame numbers are alsosynchronised.

When the MS has no information as to the synchronisation of the target cell, the procedure is likely tobe slow.

Once the MS has synchronised to the carrier and then to the TDMA frame it may proceed to attach tothe new channel

3.2.7.5. - Attaching To The New Channel

The attaching procedure for asynchronous handover to the new channel (indicated by the CHANNELDESCRIPTION IE in the HANDOVER COMMAND) consists of:

1 the sending (continuously) on the main DCCH, (or SACCH for phase 2 MSs) a HANDOVERACCESS message and starting the timer T3124.

The burst requires:

• to be formatted as a random access burst

• should contain the BSIC value passed to the MS in the CELL DESCRIPTION IE inthe HANDOVER COMMAND message

• sent with the power specified in the POWER COMMAND IE sent in the HANDOVERCOMMAND message;the burst is sent un-ciphered with a timing advance set to 0.

The message requires the HANDOVER REFERENCE value found in the HANDOVERREFERENCE IE in the HANDOVER COMMAND message.

2 When the MS receives a PHYSICAL INFORMATION message, the MS:

• stops the timer T3124;

• uses the timing advance in the PHYSICAL INFORMATION for the sending of bursts

• activates the Physical channels in sending and receiving mode

• starts ciphering

• starts sending MEASUREMENT REPORTS on the Uplink SACCH

• and attempts to establish a LAPDm connection by sending an SABM SAPI 0


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 84/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

At this point the TSC sent to the MS in the CHANNEL DESCRIPTION IE in the HANDOVERCOMMAND message is used in the coding of the bursts.

3 When the MS receives the UA SAPI 0, the MS sends in acknowledge mode a HANDOVERCOMPLETE message to the BSS.

Only when the HANDOVER COMPLETE is acknowledged at Layer 2 will the handoverprocedure be deemed to have finished in the MS.

The attaching procedure for synchronous handover to the new channel (indicated by the CHANNELDESCRIPTION IE in the HANDOVER COMMAND) consists of:

1 the sending on the main DCCH, (or SACCH for phase 2 MSs) four consecutive HANDOVERACCESS messages.

The burst requires:

• to be formatted as a random access burst;

• should contain the BSIC value passed to the MS in the CELL DESCRIPTION IE inthe HANDOVER COMMAND message;

• it is sent with the power specified in the POWER COMMAND IE sent in theHANDOVER COMMAND message;

• the burst is sent un-ciphered with a timing advance set to 0.

The message requires the HANDOVER REFERENCE value found in the HANDOVERREFERENCE IE in the HANDOVER COMMAND message.

2 The Physical channels are connected immediately for receiving and transmission,Deciphering is started immediately using the ciphering key that was used on the old channel,the timing advance previously used on the old channel is now used on the new channel andthe MS attempts to establish a LAPDm connection by sending an SABM SAPI 0. At this pointthe TSC sent to the MS in the CHANNEL DESCRIPTION IE in the HANDOVER COMMANDmessage is used in the coding of the bursts.

3 When the MS receives the UA SAPI 0, the MS sends in acknowledge mode a HANDOVERCOMPLETE message to the BSS.

Only when the HANDOVER COMPLETE is acknowledged at Layer 2 will the handoverprocedure be deemed to have finished in the MS.

In the successful case (after HANDOVER COMMAND is acknowledged) the MS does notautomatically establish signalling connections that were in existence on the old channel (for exampleSAPI 3 SMS). This action needs to be commanded by upper layers in the MS. These layers wouldhave been informed of the handover taking place and are aware that the SAPIs which were in useneed to be re-established.

3.2.7.6. - Reattaching to the Serving Cell

The MS, on failure of the handover procedure to the target cell/channel, retrieves the context of theserving cell. This will consist of frequency synchronisation and TDMA frame numbering.

3.2.7.7. - Reattaching to the Old Channel

Attaching back to the old channel consists of:

• retrieving the context of the previous connection;

• retrieving the old timing advance and TSC for use in the burst transmission and coding;

• connecting and enabling the sending and transmission of frames starting ciphering andDeciphering immediately;


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 85/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

• establishing SAPI 0;

• and then sending the HANDOVER FAILURE message.

After the HANDOVER FAILURE has been sent on the old channel, the MS will establish automaticallyall signalling connections which where in existence before the reception of the HANDOVERCOMMAND message. The state of the individual SAPIs upon the reception of theHANDOVER COMMAND message may cause a message to be sent to the upper layers(SMS, CC, MM) in the MS to inform them of message loss on these connections. The upperlayers may then use this signal to resend messages or (for SMS) to ask for re-establishmentof SAPI 3.

The object is to attempt to establish the connection as if nothing had happened. Obviously if therewas message loss due to the handover then the upper layers will be informed and then may retry.

3.3. - Interaction Between Other Procedures

3.3.1.- External Handover & Ciphering Procedures

The MSC is responsible for the synchronisation of the Ciphering and external handover procedures.

In cases where a Ciphering procedure is in progress the MSC will ensure that this procedure finishesbefore the initiation of the external handover procedure or any other procedure.

The BSS takes no notice of the result of the Ciphering procedure.

On reception of the HANDOVER REQUEST the BSS checks the MS capabilities, MSC requirements& BSS capabilities as specified in ref [14] and in this document. Note some special support for Phase2 MSs (not supporting A5/1) operating in Phase 1 networks is specified.

3.3.2. - Internal Handover, External Handover BSSMAP & DTAP Messages

This section details the interaction between the internal and external handover procedures when aninternal handover has failed, the next cell in the list is external and there are queued BSSMAP orDTAP messages. The following BSSMAP messages are considered :

CIPHER MODE COMMAND

ASSIGNMENT REQUEST

ASSIGNMENT REQUEST followed by CIPHER MODE COMMAND

CIPHER MODE COMMAND followed by ASSIGNMENT REQUEST

The actions performed by the serving BSC before sending the HANDOVER REQUIRED message tothe MSC for the external handover are shown in the following table.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 86/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Queued Message Action

DTAP messages Proceed DTAP messages as indicated in section3.2.2.2.5 before BSSMAP messages handling

CIPHER MODE COMMAND Proceed with ciphering

ASSIGNMENT REQUEST Proceed with assignment

ASSIGNMENT REQUEST followed byCIPHER MODE COMMAND

MSC should not send CIPHER MODE COMMANDbefore the outcome of the assignment. DiscardCIPHER MODE COMMAND.

CIPHER MODE COMMAND followed byASSIGNMENT REQUEST

The MSC should await the outcome of the cipheringprocedure before proceeding with the assignment.Process ASSIGNMENT REQUEST after CIPHERMODE COMMAND.

Table 3./34 Interactions Internal Handover - External Handover - BSSMAP

If any of these BSSMAP messages are received after the HANDOVER COMMAND is received by theBSC they are discarded.

3.3.3. - External Handover & Internal Handover Procedures

3.3.3.1. - Serving BSC

If the BSC is in the process of performing an internal handover procedure and a HANDOVERCOMMAND is received from the MSC. The BSC will respond by sending a HANDOVER FAILUREwith the cause "reversion to old channel".

An external handover procedure may be triggered following the failure of an internal handoverprocedure when one of the subsequent preferred cells in the preferred cell list of the internalhandover alarm indicates a cell which is not controlled by the BSC - see ref [7].

Note that for the case of queuing MSCs, all inter-cell internal handovers must be forced to be externalfor a good interworking.

3.3.3.1.1. - Internal Handover after External Handover

When a handover alarm is received, if after processing the cell list, the best cell is external then allthe cells in the cell list CL are considered to be external irrespective of the actual status of the cell (ieinternal or external) and only external handovers will be performed until :

If the MSC has sent a HANDOVER REQUIRED REJECT message - the expiry of T7.

If the MSC has not sent a HANDOVER REQUIRED REJECT message - the expiry ofT_HO_REQ_LOST.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 87/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Fig 3./22 Interactions between Internal & External Handover - MSC sends HANDOVER REQUIREDREJECT

Note A Handover alarms serviced by external handover

Note B Non serviced handover alarms

Note C Handover alarms serviced by internal handover

1 Measurements from MS and BTS are relayed to the serving BSC.The Serving BSC detects the need to perform an external handover and sends aHANDOVER REQUIRED to the MSC with cell list CL1. The best cell is an external cell, allothers are internal. T7 and T_HO_REQ_LOST are started.

2 The MSC rejects the handover request. On reception of the HANDOVER REQUIREDREJECT message the BSC stops T_HO_REQ_LOST and adds CLOLD to theREJ_CELL_LIST.

3 A further handover alarm is received with all internal cells. After processing the cellinformation the BSC sends a HANDOVER REQUIRED message to the MSC with cell listCL2, T7 is restarted and T_HO_REQ_LOST started.

4 The MSC rejects this second cell list. On reception of the HANDOVER REQUIRED REJECTmessage the BSC stops T_HO_REQ_LOST and adds the cells sent in the HANDOVERREQUIRED message to the REJ_CELL_LIST. T7 is left running.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 88/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

5 A further handover alarm is received before T7 expires with the same cell information (ie allinternal cells). No handover is attempted as after processing, the cell list CL is not differentfrom that sent in the previous handover attempt.

6 T7 expires and the REJ_CELL_LIST is emptied.

7. A further handover alarm occurs :

• If the best cell is internal the BSC will attempt an internal handover and the externalhandover procedure is terminated.

• If the best cell is external the above procedure is repeated.

The following scenario illustrates the interaction between the external and internal handover when theMSC does not send a HANDOVER REQUIRED REJECT message.

Fig 3./23 Interactions between Internal & External Handover - MSC does not send HANDOVERREQUIRED REJECT

Note A Handover alarms serviced by external handover

Note B Non serviced handover alarms

Note C Handover alarms serviced by internal handover

1 Measurements from MS and BTS are relayed to the serving BSC.The Serving BSC detects the need to perform an external handover and sends aHANDOVER REQUIRED to the MSC with cell list CL1. The best cell is an external cell, allothers are internal. T7 and T_HO_REQ_LOST are started. The MSC does not reject thehandover request with a HANDOVER REQUIRED REJECT message. T7 andT_HO_REQ_LOST are left running.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 89/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

2 A further handover alarm is received with all internal cells. After processing the cellinformation the BSC sends a HANDOVER REQUIRED message to the MSC with cell listCL2, T7 is restarted.

3 The MSC does not reject the handover request with a HANDOVER REQUIRED REJECTmessage. T7 and T_HO_REQ_LOST are left running.

4 A further handover alarm is received before T7 expires with the same cell information (ie allinternal cells). No handover is attempted as after processing, the cell list CL is not differentfrom that sent in the previous handover attempt.

5 T7 expires, T_HO_REQ_LOST is still running.

6 No handover alarms occur before T_HO_REQ_LOST expires.

7. Another handover alarm occurs with the same internal cells that sent in (3). The BSC nowattempts an internal handover since the best cell is internal and there are no externalhandover procedure timers running. The external handover procedure is terminated.

3.3.3.2. - Target BSC

On successful completion of the procedure the internal handover behaviour with respect to Cipheringwill be governed by the revision level of the MS (GSM Phase 1 or 2) and its Ciphering capabilities thetarget cell Ciphering capabilities and the Permitted algorithms.

3.3.3.2.1. - Subsequent Internal handover after successful External Handoverfor Phase 1 MSs

The permitted algorithm will only have ever one option allowed, this will dictate what ciphering (if any)will be used in subsequent internal handovers.

In the case where Ciphering has been initiated successfully by the MSC the internal handoveralgorithm will only ever perform handovers to cells which can support the ciphering in use by thePhase 1 MS.

3.3.3.2.2. - Subsequent Internal handover after successful External Handoverfor Phase 2 MSs

The permitted algorithm may have a multitude of options available as shown in the table below.

Note it is necessary to remember in the special case (GSM PHASE == PHASE 1) where the MSC hasasked for A5/X when the MS does not support the ciphering algorithm the permitted algorithmdefaults to No encryption.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 90/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Permitted AlgorithmSetting

Internal handover behaviour

No Encryption Only non ciphered handovers will be performedA5/X, Y Only Ciphered handovers will be performed which match the set

of algorithms given by the MSC which match both MS Cipheringcapabilities and Cell capabilities.

A5/X, Y & Noencryption

Ciphered and Unciphered handovers will be performed.Unciphered handovers will be performed to Cells which have nosupport for the Algorithms indicated in the permitted algorithms orthe MS Ciphering capability.Ciphered handovers will be performed which match the set ofalgorithms given by the MSC which match both MS Cipheringcapabilities and Cell capabilities.

Table 3./35 Permitted Algorithm Options

3.3.4. - External SDCCH Or TCH Handover & Assignment Procedures

During an external handover procedure the MSC should not initiate an Assignment procedure. If anASSIGNMENT REQUEST is received after the HANDOVER COMMAND has been received by theBSC it will be discarded.

3.3.5. - External Handover & Trace

The MSC can command a Trace at any point the SCCP is established on the new channel evenbefore the target BSS has successfully allocated or activated an RF channel.

3.3.6. - External Handover & MS And BS Power Control

During external handover the BSS is required to trigger the starting of MS & BS power controlalgorithms as described in ref [8].

This section specifies the requirements of the BSC and BTS. It should be noted that BS Powercontrol is inhibited in certain cases as specified in ref [8].

3.3.6.1. - Serving BSC during External Handover

The serving BSC does not inhibit the MS or BS Power control algorithm during handovers.

During the period where the MS is not on the serving cell the Algorithms operate as described in ref[8].

3.3.6.2. - Target BSC during External Handover

The target BSC will start MS & BS Power control algorithms when the ESTABLISH INDICATIONSAPI 0 is received.

If the HANDOVER COMPLETE message is received which is not preceded by an ESTABLISHINDICATION SAPI 0 then the BSC will start MS and BS Power control algorithms on this event.

3.3.7. - Handover algorithm & External Handover protocol

This section of the document specifies the behaviour of the handover algorithm & external handoverprotocol, and defines the maximum repetition rate of the HANDOVER REQUIRED message.

Timer T_FILTER is a timer running in the handover algorithm, (see ref [8]), and ensures that internalalarm messages are filtered. If different cells are presented in the internal handover alarm sent fromthe handover algorithm the maximum repetition rate of HANDOVER REQUIRED will be T_FILTER as


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 91/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

shown in the following message sequence chart. Note that this is independent of whether the MSCsends the HANDOVER REQUIRED REJECT message.

Fig 3./24 T_FILTER & Maximum HANDOVER REQUEST RATE

1 The BTS sends the MEASUREMENT RESULT regularly to the BSC handover algorithm - seeref [8].Note the messages are not shown in the message sequence chart for simplification.

2 The BSC handover algorithm has detected the need to perform a handover, an internal alarmis sent to the BSC handover protocol and T_FILTER is started.

3 If the best cell is external and the rules in section 3.2.2.1. - External Handover Decision aresatisfied, the BSC handover protocol initiates an external handover to the MSC by sending aHANDOVER REQUIRED message, starting T7 and T_HO_REQ_LOST.

4 T_FILTER expires and the need for a handover is detected by the BSC handover algorithmwhich sends another internal alarm to the BSC handover protocol. Another HANDOVERREQUIRED will be sent if there are different cells in the internal alarm irrespective as towhether these cells are internal or external (see section 3.3.3.1.1. - Internal Handover afterExternal Handover), in which case the maximum repetition rate of the HANDOVERREQUIRED message is T_FILTER..


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 92/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

If different cells are not presented in the internal handover alarm sent from the handover algorithmthe maximum repetition rate of HANDOVER REQUIRED will be T7 as shown in the followingmessage sequence chart. This is also independent of whether the MSC sends the HANDOVERREQUIRED REJECT message.

Fig 3./25 T_FILTER & Maximum HANDOVER REQUEST RATE

1 The BTS sends the MEASUREMENT RESULT regularly to the BSC handover algorithm - seeref [8].Note the messages are not shown in the message sequence chart for simplification.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 93/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

2 The BSC handover algorithm has detected the need to perform a handover, an internal alarmis sent to the BSC handover protocol and T_FILTER is started.

3 If the best cell is external and the rules in section 3.2.2.1. - External Handover Decision aresatisfied, the BSC handover protocol initiates an external handover to the MSC by sending aHANDOVER REQUIRED message, starting T7 and T_HO_REQ_LOST.

4 T_FILTER expires and the need for a handover is detected by the BSC handover algorithmwhich sends another internal alarm to the BSC handover protocol.After processing the cell list the BSC the cell list is no different from that previously sent, sono new HANDOVER REQUIRED messages is sent. This is repeated for each internal alarmthat arrives.

5 T7 expires and the cell list sent to the MSC in the previous HANDOVER REQUIRED isdiscarded, any cells in the REJ_CELL_LIST are also discarded.

6. T_FILTER expires and the need for a handover is detected by the BSC handover algorithmwhich sends another internal alarm to the BSC handover protocol. Since T7 has expired thecell list although no different from that previously sent may be sent again in a HANDOVERREQUIRED message. The maximum repetition rate of the HANDOVER REQUIREDmessage is thus T7.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 94/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

4. - INTERFACE DESCRIPTIONS

4.1. - GSM interfaces / Physical interfaces

The following interface descriptions describe the messages specific to the external handoverprocedure.

AIR interface

CHANNEL MODE MODIFYTarget BSC -> MSsent on FACCH for compliancy with ref [18].

HANDOVER ACCESSMS -> target BTSsent continuously on main DCCH of target cell.

HANDOVER COMMANDServing BSC -> MS (transparent to the BTS)sent on main DCCH, initiates handover with the MS.

HANDOVER COMPLETEMS -> Target BSC (transparent to target BTS)sent on main DCCH, initiates completion of the procedure

HANDOVER FAILUREMS -> Serving BSC (transparent to serving BTS)Sent on main DCCH, initiates failure of handover.

MEASUREMENT REPORTMS -> BTSsent on the Uplink SACCH, conveying measurements of the Downlink serving cell and Neighbourcells.

PHYSICAL INFORMATIONTarget BTS -> MSsent ciphered on the main DCCH.

SABM SAPI 0Layer 2 LAPDmMS -> BTS

UA SAPI 0Layer 2 LAPDmBTS -> MSConfirms reception of SABM

ABIS interface

BS POWER CONTROLBSC -> BTSPower control by BSC .

CHANNEL ACTIVATIONBSC -> BTSCommands the activation of an RF channel.

CHANNEL ACTIVATION ACKBTS -> BSCAcknowledges successful activation of an RF channel.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 95/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

CHANNEL ACTIVATION NACKBTS -> BSCIndicates the unsuccessful activation of an RF channel.

ESTABLISH INDICATION SAPI 0BTS -> BSCSent from the BTS to the BSC. During Channel change procedures it is sent without the Layer 3information IE.

HANDOVER DETECTIONBTS -> BSCSent by the BTS when the BTS detects a correct HANDOVER ACCESS message sent by the MS.

MEASUREMENT RESULTBTS -> BSC ()Conveys Uplink measurements and Downlink measurements.

MS POWER CONTROLBSC -> BTS ()Power control message by BSC

A interface

HANDOVER COMMANDMSC -> Serving BSCInitiates handover towards the MS.

HANDOVER DETECTTarget BSC -> MSCIndicates that the target BSS has received a correct HANDOVER ACCESS from the MS. It is sent bythe target BSC when the HANDOVER DETECTION message is received from the target BTS.

HANDOVER COMPLETETarget BSC -> MSCInitiates end of successful procedure

HANDOVER FAILURETarget or serving BSC -> MSCTarget BSC sends this message on either unsuccessful allocation or unsuccessful activation of an RFchannelServing BSC sends this message when it receives the HANDOVER FAILURE message (air) from theMS.Initiates end of unsuccessful procedure.

HANDOVER REQUIREDServing BSC -> MSCInitiates external handover, conveys preferred cell list for MSC.

HANDOVER REQUIRED REJECTMSC -> Serving BSCSent by the MSC (normally only if the OIE RESPONSE REQUEST is set in the HANDOVERREQUIRED message) when it can not perform the external handover.

HANDOVER REQUESTMSC -> Target BSCInitiates external handover with target BSS.

HANDOVER REQUEST ACKTarget BSC -> MSCAcknowledges the reservation and successful activation of an RF channel for the handover.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 96/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

UNEQUIPPED CIRCUITTarget BSC -> MSCSent by the target BSC (if GSM PHASE == PHASE 2 & enabled by O&M Parameter(EN_UNEQUIPPED_CIRCUIT)) to the MSC when the Circuit indicated in the HANDOVER REQUESTis unknown to the Target BSC.

SCCP MESSAGES

SCCP CONN REQMSC -> Target BSC for external handoverRequest an SCCP connection.

SCCP CONN CNFTarget BSC -> MSC for external handoverConfirms the request.

SCCP CONN REFTarget BSC -> MSC for external handoverRefuses a connection request.

4.2. - Internal interfaces

HANDOVER ALARMsent by handover algorithm (ref [8]) -> serving BSC.Contains:handover alarm cause;Preferred cell list.

RESOURCE ALLOCATIONsent by Dedicated resource management (ref [9]) -> Target BSC.Contains:Result of allocation;& optionally allocated RF channel or CIC.

DL EST INDsent by LAPDm -> BTS.Contains:SAPI;& optionally L3 information.

LAPDM REFUSE ESTABTarget BTS -> LAPDmchanges state of LAPDm so as to refuse establishment at Layer 2.

TRANSCODER ALARMSInternally detected alarm indicating that the transcoder is not attached, from Layer 1 to BTS Layer 3.

4.3. - Timer list

The following list of timers describes the use of the timers specific to the external handover protocol.

BTS TIMERS

T200MS, BTS timer. Supervises the repetition of Layer 2 frames on LAPDm.

T3105_D (DCCH)Target BTS. Supervises the rate of sending PHYSICAL INFORMATION messages to the MS forDCCH connections.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 97/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

T3105_F (FACCH)Target BTS. Supervises the rate of sending PHYSICAL INFORMATION messages to the MS forFACCH connections.

T3106_D (DCCH)Target BTS. Supervises the time which the MS should establish the LAPDm SAPI 0 connection fromreception of the correct HANDOVER ACCESS. Used in synchronous handovers for DCCHconnections.

T3106_F (FACCH)Target BTS. Supervises the time which the MS should establish the LAPDm SAPI 0 connection fromreception of the correct HANDOVER ACCESS. Used in synchronous handovers for FACCHconnections.

T_CFI_TrBTS timer. Used to filter the internally detected transcoder alarm after DL EST IND from LAPDm.

THO_minBTS timer. In the event that a handover condition is detected in the BTS, it controls the rate at whichthe PREPROCESSING MEASUREMENT RESULT message (indicating handover conditions) aresent to the BSC whilst a handover condition exists.

T_SYNCBTS & Transcoder timer. This timer is used in both entities to guard the consistency of the Speechpath between both BTS & TC.

BSC TIMERS

T_HO_REQ_LOSTServing BSC timer. This timer serves to guard against no response from the MSC

T7Serving BSC - MSC load timer. Prevents the BSC from offering the same cell(s) too quickly in theevent that the MSC does not use the HANDOVER REQUIRED REJECT message to reject candidatecells.

T8Serving BSC timer. Supervises the handover with the MS.

T_MS_CELL_REJServing BSC timer. Guards against target cells which the MS has failed to hand over to beingpresented in subsequent handover request for a specific time period.

T9103Target BSC timer. Supervises activation of an RF channel in the serving & target BTS.

T9104target BSC timer. Supervises the response of the MSC after sending the CLEAR REQUEST due toreception of CONNECTION FAILURE INDICATION (cause "Handover access failure").

T9110Target BSC timer. Guards the response of the MSC when no resources are allocated to the SCCPconnection. Guards also the response of the MSC when a HANDOVER FAILURE has been sent(HANDOVER REQUEST or CLEAR COMMAND awaited)

T9113Target BSC timer. Supervises the handover with the MS.

T_FILTERThis timer runs in the BSC handover algorithm in both Modes A or B. It controls the rate of BSCinternal handover alarms in the BSC.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 98/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

T_qhoTarget BSC timer. Determines the length of time the handover request is queued for.

MSC TIMERS

The following list is given for information only.

T3101MSC timer. Supervises the handover with the MS, target and serving BSS.

Trr2MSC timer. Guards the activation of the target cell.

MS TIMERS

T200MS, BTS timer. Supervises the repetition of Layer 2 frames on LAPDm.

T3124MS timer. Supervises the establishment of LapDM on the target cell after reception of the PHYSICALINFORMATION.

4.4.- Parameter list

The following parameter list is specific to the external handover procedure.

BTS PARAMETERS

NY1The number of repetitions of PHYSICAL INFORMATION messages that can be sent from the targetBTS to the MS during a handover.

T3105_D_STOPThis parameter is used in the BTS to control which event will stop the timer

T3105_F_STOPThis parameter is used in the BTS to control which event will stop the timer

T3106_D_STOPThis parameter is used in the BTS to control which event will stop the timer

T3106_F_STOPThis parameter is used in the BTS to control which event will stop the timer

BSC PARAMETERS

BS_TXPWR_MAXMaximum power that the BTS can transmit with.

CGI_REQDWhen set TRUE, dictates that the encoding of cell identifiers will use the CGI encoding rules.

DOWNLINK_DTX_ENABLEWhen set TRUE, The operator requires that downlink DTX be enabled (else disabled).

Note : This flag only specifies the requirement for the operator - see section on Channel activationfor details on the control of downlink DTX by this flag and the control by the MSC.

DTX_INDICATORIndicates if DTX is to be used in the Uplink direction.

EFR_ENABLEDEnable/Disable EFR operation.

EN_IC_HOEnabled (= True): Intercell synchronous and asynchronous handovers may be made into the cell.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 99/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Disabled (= False): Intercell synchronous and asynchronous handovers may not be made into thecell.

EN_SEND_OLD_CHANNEL_MODEWhen set ENABLED, allows the serving BSS to include OIE Current Channel in HANDOVERREQUIRED message.

EN_SEND_SPEECH_VERWhen set ENABLED, allows the serving BSS to include OIE Speech Version in HANDOVERREQUIRED message.

EN_UNEQUIPPED_CIRCUITO & M parameter which enables the UNEQUIPPED CIRCUIT message to be sent by the BSC.

EXT_HO_FORCEDWhen set TRUE, all internal intercell handovers are forced to be handled as external.

GSM_PHASEThis flag indicates the mode of operation/behaviour that the BSS needs to adopt on A interface. It isset to either PHASE 1 or PHASE 2.

HO_SDCCH_INHIBITWhen set TRUE, all handovers for SDCCH are ignored.

HO_INTERCELL_ALLOWEDWhen set FALSE, all Inter-cell handovers are inhibited.

HR_ENABLEDEnable/Disable Half-Rate Operation.

MS_TXPWR_MAXMaximum power that the MS can transmit with.

NCIO & M Parameter which controls the setting of the NCI field in the Synchronisation IE in theHANDOVER COMMAND message. This parameter is settable on a BSC basis and is changeable on-line. When set TRUE the MS is commanded to trigger a Handover Failure for an out of range timingadvance.

N_PREF_CELLThe value of this counter dictates the maximum number of cells that may be contained in theHANDOVER REQUIRED message sent to the MSC.

RESP_REQWhen set TRUE, the RESPONSE REQUEST OIE in the HANDOVER REQUIRED message will beincluded.

ROTO & M Parameter which controls the setting of the ROT field in the Synchronisation IE in theHANDOVER COMMAND message. This parameter is settable on a BSC basis and is changeable on-line. When set FALSE the MS is commanded not to include the Time Difference IE in theHANDOVER COMPLETE message.

SDCCH_COUNTERThe value of this counter delays the handling of handover alarms for SDCCH connections after theestablishment of an SDCCH during the immediate assignment procedure.

STOP_HO_ACC_FAILThis flag is a generic name associated to the flags (T3105_D_STOP, T3105_F_STOP,T3106_D_STOP & T3106_F_STOP) and controls on a per BTS basis the behaviour of the BTSswhich it controls during the handover access procedure.

Due to testing requirements in the BTS, the BTS has implemented four flags on to which this single


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 100/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

BSC flag maps.These flags appear in the BTS CONF DATA message and are named: T3105_D_STOP,T3105_F_STOP, T3106_D_STOP & T3106_F_STOP, (see above).

with-synchronised-handoverFlag readable at the OMC-R, allowing synchronous handover.

BSC INTERNAL VARIABLES

SDCCH_COUNTERThis is a parameter which delays the handover of an SDCCH after an Immediate assignmentprocedure. It is coded in terms of the number of SACCH multiframes.

DOTThis variable contains the Duration Of the Transaction in SACCH multiframe periods.That is to say the length of time from the start of the transaction (reception of the first SABMfrom the MS) after the Immediate assignment procedure.

BCEThis stands for Best Cell is External.The condition where the first cell in the cell list CL is external.

ASSGNThis stands for Assignment.When this condition is TRUE the connection has received an ASSIGNMENT REQUESTmessage for an Assignment procedure and the procedure is either: delayed due to queuing(TCH assignment only); or is in progress (ie ASSIGNMENT COMMAND has been sent to theMS and the ASSIGNMENT COMPLETE or ASSIGNMENT FAILURE is awaited).

T7This variable is set to either RUNNING or NOT RUNNING depending on the state of the timerT7

T_HO_REQ_LOSTThis variable is set to either RUNNING or NOT RUNNING depending on the state of thetimerT_HO_REQ_LOST

T_MS_CELL_REJThis variable is set to either RUNNING or NOT RUNNING depending on the state of the timerT_MS_CELL_REJ

MS_CELL_REJ_LISTThe list of cells that the MS has failed to handover to. The size of the list is 4.

REJ_CELL_LISTThe list of cells that the MSC has rejected as being candidate cells for the handover. Thesize of the list is 2*N_PREF_CELLmax

CLThe cell list that has been produced by excluding cells present in the MS_CELL_REJ_LIST

and REJ_CELL_LIST from the list of cells received in the handover alarm.

CLOLD

The list of cells that was sent to the MSC in the previous HANDOVER REQUIREDmessage.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 101/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

5. - Release 2, 3 & 4, 5Changes

BTS Release 2

1 The BTS stops send PHYSICAL INFORMATION on reception of an SABM

BTS release 3

1 The BTS may stop sending PHYSICAL INFORMATION on reception on either a correctlyreceived TCH frame or Layer 2 frameOr only on the reception of an SABM frame. See Parameter section.

BSC Release 2

1 supports a single algorithm A5/1 and only Phase 1 MSs.

2 Ciphering algorithm can not change during any Channel change procedure.

BSC release 3

1 The BSC supports both Phase 1 & 2 MSs in GSM Phase 1 & 2 Networks. That is to say thatETR 09.90 is supported for the Phase 1 Network.

2 Ciphering algorithm may be changed between external handovers as part of the support forMultiple algorithms.

3 The causes "Invalid cell & Encryption algorithm not supported" are sent on the A interface.

4 The UNEQUIPPED CIRCUIT may be sent to the MSC.Note Only when allowed and when GSM PHASE == PHASE 2.

5 External handover may be performed successfully if the old Channel Mode and new ChannelMode are different.

BSC release 4

1 Timer T7 no longer guards the handover procedure. Its function is to :a) provide a time period before which cells rejected by the MSC in a HANDOVER REQUESTREJECT message cannot be offered again in subsequent HANDOVER REQUESTS.b)provide a time period for cells that were offered to the MSC but which have not beenexplicitly rejected in the HANDOVER REQUIRED REJECT message from being offeredagain to the MSC.These cells are remembered in the list REJ_CELL_LIST in the BSC.

2 Timer T_HO_REQ_LOST now guards the handover procedure. On expiry an O & M errorreport is raised.

3 A cell to which the MS fails to handover to is remembered for a time periodT_MS_CELL_REJ and cannot be offered to the MSC in that time.

4 Incoming handovers may be inhibited by an O&M flag (EN_IC_HO) on a per cell basis.

5 Introduction of half rate feature. An incoming handover may be performed to a half or fullrate channel (half rate - speech only) if commanded by the MSC.

6 Introduction of E-GSM support. An incoming handover may be performed for an E-GSMmobile (TCH only).

BSC release 5

1. BSC can now support multiband handovers. The IE SACCH Info has been added to allowdynamic management of System Information on a per call basis.

2. The Target BSC can optimize the length of HANDOVER COMMAND message by removingthe OIE Mode of the first channel.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 102/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

3. The BSC supports incoming External Directed Retry.

4. Support of EFR

5. New cause "speech version unavailable" is used.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 103/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

6. - FEATURES

Release 5 feature list

FD/3.13Multiband Operation in one BSC

FD/11.25Support of Enhanced Full Rate mobiles.


FD/10.2Minimal E-GSM Support

FD/4/10.1cMinimum support of half rate mobiles

FD/11.6Handover Protocol Improvements

FD/4/0.31.54Disabling of external handover due to return to old channel by MS


FD/3/6.1A interface compatibility

FD/3/6.2Air interface compatibility

FD/3/5.1A5/2 version for A900/A1800


B2314Use of CGI over A interface

B288408.08 Handover required reject

B288608.08 Handover detection

B4010BSC control of down-link DTX

Release 1 & 0 feature list

B221708.58 Handover detection

B222904.08 MS handover access

B234508.08 HO resource allocation (HO request)

B2837Handover from TCH/F to TCH/F

B2843Handover from SDCCH to SDCCH


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 104/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

B2861MSC controlled external handover: intra-BSC, inter-BTS

B2862MSC controlled external handover: inter-BSC

B285608.58 Channel activation: for asynchronous handover

B286908.58 Channel activation: for synchronous handover

B288108.08 Handover required with cell-list

B288508.08 Handover execution

B288708.08 Handover detection (internal)

B288904.08 RR Handover: asynchronous

B289004.08 Handover: synchronous


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 105/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

Glossary

DefinitionsAfter time This notation is used in GSM phase 2 to indicate during Channel change

procedures with or without Frequency redefinition procedure what theChannel configuration is after the Starting time on the indicated channelhas been passed.In the case where there is no Frequency redefinition there is no Startingtime included.

Asynchronous handoverA handover where the serving and target cells are not synchronised orsynchronous handover is not allowed.

Before time This notation is used in GSM Phase 2 to indicate during the Frequencyredefinition procedure the Channel configuration before the Starting timeon the indicated channel has been passed.

DCS This generic term is used to designate either DCS 1800 or DCS 1900.

DCS 1800 band The frequency band 1710.2 - 1784.8 MHz / 1805.2 - 1879.8 MHz

DCS 1900 band The frequency band 1850.2 - 1919.8 MHz / 1930.2 - 1989.8 MHz

Don’t care This is used in State transition tables to indicate that when an event isreceived it will be ignored.

E-GSM band This refers to the extended frequency band used by GSM (P-GSM range+ G1 range)

G1 range This is a frequency range added to the initial GSM frequency allocation(880.2 - 890.0 MHz / 925.2 - 935.0 MHz)

Handover alarm BSS Internal signal indicating that a handover is required

NA Not applicableThis is used to indicate in State transition tables that an event should notbe received in a specific state. If the event is received then it is ignored

P-GSM range This refers to the primary frequency range used by GSM (890.2 - 915.0MHz / 935.2 - 960.0 MHz)

Restart When used in the context of timers, eg restart T7, this is equivalent to :stop T7, start T7.

Serving BSS/BTS/BSCThe BSS/BTS/BSC which is presently handling the MS connection.

Target BSS/BTS/BSCThe BSS/BTS/BSC which is going to handle the connection.

AbbreviationsACT ACTivationASSGN AssignmentBCCH Broadcast Control CHannelBSC Base Station ControllerBSIC Base Station Identification CodeBSS Base Station SystemBTS Base Transceiver Station

CGI Cell Global IdentifierCIE Conditional Information ElementCL Candidate cell List - A list of cells derived from the cell list accompanying

the handover alarm and which may be sent to the MSC in a HANDOVERREQUIRED message.


MCD 41.DOC

16/02/98 10:12

3BK 11202 0104 DSZZA 106/108

All

right

s re

serv

ed. P

assi

ng o

n an

d co

pyin

g of

this

do

cum

ent,

use

and

com

mun

icat

ion

of it

s co

nten

ts

notp

erm

itted

with

outw

ritte

nau

thor

izat

ion

from

Alc

atel

CLOLD Candidate cell list sent to the MSC in the last HANDOVER REQUIREDmessage,

CMD CoMmanDCMP CoMPleteCR Connection Request (SCCP)CC Connection Confirm (SCCP)CRef Connection Refused (SCCP)

DCCH Dedicated Control ChannelDI Data INDication (Abis)DM Disconnect ModeDR Data REQuest (Abis)DT1 DaTa form 1 (SCCP)DTX Discontinuous Transmission

EFR Enhanced Full Rate.EST IND ESTablish INDication

FCCH Frequency Correction CHannel

GSM Global System for Mobile communicationsHO HandOverHR Half RateIE Information Element

MEAS MEASurementsMIE Mandatory Information ElementMS Mobile StationMSC Mobile Switching Centre

O&M Operations & MaintenanceOIE Optional Information Element

PHY INFO PHYsical INFOrmationPLMN Public Land Mobile Network

REF REFUSEREP REPortREQ REQuestRES RESultsRESP RESPonseRR Radio Resource

SABM Set Asynchronous Balanced ModeSACCH Slow Associated Control CHannelSAPI Signalling Access Point IdentifierSCCP Signalling Connection Control PartSCH Synchronisation CHannelSDCCH Standalone Dedicated Control CHannelTCH Traffic CHannelTDMA Time Division Multiple Access

UA Unnumbered AcknowledgeUI Unnumbered InformationUDI Unit Data Indication (Abis)

EX

TE

RN

AL

HA

ND

OV

ER

ED

02 R

EL

EA

SE

D

MC

D41.D

OC

16/02/98 10:12

3BK

11202 0104 DS

ZZ

A107/108


not permitted without written authorization from Alcatel

SE

Q1

EX

TE

RN

AL

HA

ND

OV

ER

ED

02 R

EL

EA

SE

D

MC

D41.D

OC

16/02/98 10:12

3BK

11202 0104 DS

ZZ

A108/108


not permitted without written authorization from Alcatel

SE

Q2

EN

D O

F D

OC

UM

EN

T

external ho b5

Documents

classmark

handover failure

physical information

subsequent

radio interface

external handover

handover failure

handover request