'Docslide Net External Ho b5

TELECOM
All rights reserved. Passing on and copying of this

document, use and communication of its contents
not permitted without written authorization from Alcatel
Site
VELIZY
MOBILE COMMUNICATION DIVISION
Originator(s)
EXTERNAL HANDOVER
S. SAADA
RELEASE 5
Domain
Division
Rubric
Type
Distribution Codes
:
:
:
:
ALCATEL 900/BSS
PRODUCT DEFINITION
SYS-TLA
SYSTEM FUNCTIONAL BLOCKS
Internal :
External :
PREDISTRIBUTION:
MCD VELIZY
M. Roberts
E. Desorbay
L. Cruchant
P. Fouilland
JJ. Roy
A. Barnel (ffd)
JF. Mailllard
M. Tuchendler (fpo)
D. Berthoumieux
(fpo)
J.P. Georges (fpo)
TD/SAS
TD/SAS
TD/SAS
TD/SAS
TD/SAS
TD/SAS
TD/SAS
M. Delprat
M. Dobrosielski
JL. Lekmouli
A. Pech
TD/BTS
TD/BTS
TD/IIV
TD/IIV
MCD KONTICH
G. Van Dijck (ffd)
SSD VELIZY
J. Messiet
SSD STUTTGART
P. Hupperich
W. Allerborn
PREDISTRIBUTION: DOC. CENTRES

MCD VELIZY
B. Marliac
MCD ANTWERP
L. Van Eyck
MCD STUTTGART
I. Lentzsch
ABSTRACT
This document describes the protocol for the execution of the External Handover procedure as
performed by the BSS.
Note the following handover types are not implemented in this release of the ALCATEL BSS:
External Pseudo-synchronous
External Pre-synchronous
Name
D. BERTHOUMIEUX
AM
Approvals
M. ROELANDTS
SSAM BSC
M. DELPRAT
SSAM BTS/SW
App.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
1/4
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
Version
Date
Author
Reason for update
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/157

SG approved version
Release 3 : 3BK 11202 0006 DSZZA

Version
Date
Author
Reason for update
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

Version Date
Author
Reason for update
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.0.0.2
05/01/95
4.0.1.0
03/02/95
4.0.1.0
23/03/95
4.1.0.0
03/02/95
B. SZELAZEK Updated after TLA review#9bis. See

SDEF/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
4.3.0.0
16/11/95
S. SAADA
Updated after mail review. Includes R3 CRQs 940 & 1269 &
R4 CRQ 895.
Include CRQ 1604

Version
Date
Author
Reason for update

EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
2/4

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.96

Includes 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 and

TLAr5#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 an
internal handover has failed, the next cell in the list is external and there are queued BSSMAP/DTAP
messages. 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 HANDOVER
REQUIRED message to the MSC for the external handover are shown in the following table.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
3/4
TELECOM

Queued Message
Action
CIPHER MODE COMMAND
See note
ASSIGNMENT REQUEST (SDCCH->TCH

or TCH->SDCCH)
Send ASSIGNMENT FAILURE cause = No radio

resource available
ASSIGNMENT REQUEST (In call

modification)
Send ASSIGNMENT FAILURE, cause = Reversion

to 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 procedures
when an internal handover has failed, the next cell in the list is external and there is a queued
CIPHER MODE COMMAND - see below.
Queued Message
CIPHER MODE COMMAND
Action 1
Action 2
Allow Cipher command to

complete before triggering
external handover.
Send CIPHER MODE

REJECT
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 the
serving BSC in the HANDOVER COMMAND message, informing it of the target cell selected by the
MSC, (see GSM 08.08 AR A002r2). This method of identifying the target cell is preferable to using
the only cell in CL OLD when N_PREF_CELL = 1 since it allows the filtering of cells in the
MS_CELL_REJ_LIST to be used when N_PREF_CELL >1.
END OF DOCUMENT
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
4/4
TELECOM

SYSTEM FUNCTIONAL BLOCKS
TABLE OF CONTENTS
HISTORY ..................................................................................................................................................4
REFERENCED DOCUMENTS ..................................................................................................................4
GSM References .......................................................................................................................................4
Alcatel References.....................................................................................................................................4
Other References ......................................................................................................................................5
RELATED DOCUMENTS..........................................................................................................................5
PREFACE .................................................................................................................................................5
1. - Scope .................................................................................................................................................6
2. - FUNCTIONAL DESCRIPTION ............................................................................................................7
2.1. - General description...........................................................................................................................7
2.1.1. - Handover Behaviour ......................................................................................................................7
2.1.2. - Handover Behaviour on Failure .....................................................................................................8
2.2. - ALCATEL BSS support for outgoing external handovers...................................................................9
2.3. - ALCATEL BSS support for incoming handovers ...............................................................................9
2.3.1. - External Handover Test Call Functionality .....................................................................................9
2.4. - ALCATEL BSS support for Phase 1 MS capabilities .........................................................................10
2.5. - ALCATEL BSS support for Phase 2 MS capabilities .........................................................................10
2.6. - External Handover Entities ...............................................................................................................10
3. - DYNAMIC BEHAVIOUR......................................................................................................................12
3.1. - General Behaviour............................................................................................................................12
3.1.1. - Successful External Asynchronous Handover ................................................................................12
3.1.2. - Successful External Synchronous Handover..................................................................................16
3.1.3.Target Cell Negotiation .....................................................................................................................18
3.1.3.1. - Repeated Handover Attempts .....................................................................................................18
3.1.3.2. - MSC Rejection of Cell List ..........................................................................................................19
3.1.3.2.1. - BSC Reaction to HANDOVER REQUIRED REJECT................................................................19
3.1.3.2.2. - MSC Does Not Send HANDOVER REQUIRED REJECT.........................................................21
3.1.4. - Unsuccessful External Handover ...................................................................................................21
3.1.4.1. - MS Handover Failure ..................................................................................................................22
3.1.5. - Serving BSC Protocol Failures.......................................................................................................25
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
1/108

TELECOM
3.1.5.1. - T_HO_REQ_LOST Expiry ..........................................................................................................25

3.1.5.2. - T8 Expiry ....................................................................................................................................27
3.1.6. - Target BSC Protocol Failures ........................................................................................................27
3.1.6.1. - T9103 Expiry ..............................................................................................................................28
3.1.6.2. - T9113 Expiry ..............................................................................................................................28
3.1.6.3. - Channel Activation Nack .............................................................................................................29
3.1.6.4. - Connection Failure Indication (Cause "Handover Access Failure")..............................................30
3.1.7. - Target BTS Protocol Failures.........................................................................................................30
3.1.7.1. - T3106 Expiry & Connection Failure Indication (Cause "Handover Access Failure")
Synchronous Handover..............................................................................................................................30
3.1.7.2. - T3105 Expiry & Connection Failure Indication (Cause "Handover Access Failure")
Asynchronous Handover............................................................................................................................32
3.2. - Detailed Behaviour ...........................................................................................................................35
3.2.1. - Serving BTS Protocol ....................................................................................................................35
3.2.2. - Serving BSC Protocol ....................................................................................................................35
3.2.2.1. - External Handover Decision........................................................................................................35
3.2.2.1.1. - General Rules..........................................................................................................................35
3.2.2.1.2. - External Handover Decision For SDCCH Transactions ............................................................35
3.2.2.1.3. - SDCCH External Handover Decision After Immediate Assignment ..........................................35
3.2.2.1.4. - SDCCH External Handover Decision ( After Normal Assignment) ............................................36
3.2.2.1.5. - External Handover Decision For TCH Transactions .................................................................36
3.2.2.2. - Serving BSC External Handover Protocol ...................................................................................37
3.2.2.2.1. - NULL State behaviour..............................................................................................................40
3.2.2.2.2. - Normal Events .........................................................................................................................41
3.2.2.2.3. - Unexpected Events..................................................................................................................44
3.2.2.2.4. - Events from BTS .....................................................................................................................47
3.2.2.2.5. - DTAP and BSSMAP procedures ..............................................................................................50
3.2.2.2.6. - HANDOVER REQUIRED message building.............................................................................50
3.2.3. - MSC Handover Protocol ................................................................................................. ...............51
3.2.4. - Target BSC External Handover Protocol ........................................................................................51
3.2.4.1. - SCCP Connection Establishment................................................................................................58
3.2.4.2. - SCCP Connection Failure ...........................................................................................................60
3.2.4.3. - Target BSS errors.......................................................................................................................61
3.2.4.4. - Target BSS error BLOCK message is sent..................................................................................62
3.2.4.5. - Target BSS error UNEQUIPPED CIRCUIT message is sent .......................................................63
3.2.4.6. - HANDOVER REQUEST message processing.............................................................................64
3.2.4.6.1. - Detection of incoming external directed retry ...........................................................................68
3.2.4.7. - CHANNEL ACTIVATION message construction..........................................................................69
3.2.4.8. - HANDOVER REQUEST ACK message construction ..................................................................71
3.2.4.9. - Layer 3 IE HANDOVER COMMAND message construction........................................................72
3.2.4.10. - CHANNEL MODE MODIFY message construction....................................................................75
3.2.4.11. - DTAP & BSMAP procedures in the Target BSS ........................................................................76
3.2.5. - Target BTS Asynchronous Handover Protocol ...............................................................................76
3.2.6. - Target BTS Synchronous Handover Protocol.................................................................................79
3.2.6.1. BTS CHANNEL ACTIVATION message checking.........................................................................81
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
2/108
TELECOM

3.2.7. - MS Handover Protocol...................................................................................................................81

3.2.7.1. - Measurement Reporting..............................................................................................................81
3.2.7.2. - Synchronous & Asynchronous Handover Procedure....................................................................82
3.2.7.3. - Releasing From The Old Channel & Serving Cell........................................................................82
3.2.7.4. - Attaching To The Target Cell ......................................................................................................82
3.2.7.5. - Attaching To The New Channel...................................................................................................83
3.2.7.6. - Reattaching to the Serving Cell...................................................................................................84
3.2.7.7. - Reattaching to the Old Channel ..................................................................................................84
3.3. - Interaction Between Other Procedures..............................................................................................85
3.3.1.- External Handover & Ciphering Procedures....................................................................................85
3.3.2. - Internal Handover, External Handover BSSMAP & DTAP Messages .............................................85
3.3.3. - External Handover & Internal Handover Procedures ...................................................................... 86
3.3.3.1. - Serving BSC ...............................................................................................................................86
3.3.3.1.1. - Internal Handover after External Handover ..............................................................................86
3.3.3.2. - Target BSC.................................................................................................................................89
3.3.3.2.1. - Subsequent Internal handover after successful External Handover for Phase 1 MSs ...............89
3.3.3.2.2. - Subsequent Internal handover after successful External Handover for Phase 2 MSs ...............89
3.3.4. - External SDCCH Or TCH Handover & Assignment Procedures .....................................................90
3.3.5. - External Handover & Trace............................................................................................................90
3.3.6. - External Handover & MS And BS Power Control ...........................................................................90
3.3.6.1. - Serving BSC during External Handover ......................................................................................90
3.3.6.2. - Target BSC during External Handover ........................................................................................90
3.3.7. - Handover algorithm & External Handover protocol ........................................................................90
4. - INTERFACE DESCRIPTIONS ............................................................................................................94
4.1. - GSM interfaces / Physical interfaces.................................................................................................94
4.2. - Internal interfaces .............................................................................................................................96
4.3. - Timer list ..........................................................................................................................................96
4.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
APPRAISAL AUTHORITY
ORIGINATOR
CHANGE NOTE
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
3/108
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 mobile
stations 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
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
4/108

Other References
None
RELATED DOCUMENTS
None
41.DOC
16/02/98 10:12
RELEASED
PREFACE
02
Not applicable
ED
MCD
TELECOM
5/108
EXTERNAL HANDOVER
3BK 11202 0104 DSZZA
TELECOM

1. - Scope
This document specifies the following External Synchronous & Asynchronous inter-cell handover
protocol for the ALCATEL BSS.
External TCH handover;
External SDCCH handover
Note External Pseudo-synchronous & External Pre-synchronised handovers are not a feature
for this release of the ALCATEL BSS.
The Call release & Resource release scenarios which occur as a result of failures in the protocol are
specified 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 number
within ref [6]. The event number takes the form of 1 to 4 character string followed by 4 numbers - eg
ref [6] EHT0100 or ref [6] N0200. These event numbers are to be found in ref [6] together with the
Call Releasing or Resource releasing scenario if applicable.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
6/108
TELECOM

2. - FUNCTIONAL DESCRIPTION
2.1. - General description
To maintain the quality of service on a radio connection it may become necessary to change the
channel in the same cell, or to another cell. There are many reasons that a change of cell or channel
is needed, interference, distance, signal strength etc. The process of changing the channel is called
Handover. When the change is controlled by the MSC it is known as an External Handover, when
controlled by the same BSC it is known as Internal Handover. The change can be to a channel in the
same cell or a channel in another cell.
When a handover is required the BSS decides which type of handover is to be performed, either
internal or external. When an external handover is required a handover alarm accompanied by a cell
list is presented to the external handover protocol by Dedicated Radio Resource in response to a
handover alarm generated by the Power Control and Handover Algorithm (ref [8]). Ref [9] describes
the 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:
MSC.
Intra MSC external handover - a handover performed between cells controlled by the same
Inter MSC external handover - a handover performed between cells controlled by different
MSCs.
There is no difference in behaviour of the Alcatel BSS for either the inter or intra MSC external
handover, 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 the
serving and target cell are synchronised. If the serving cell is not controlled by the target BSC then
an asynchronous handover is performed.
The handover is performed between the serving and target BSCs via the MSC. The messages on the
A, 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 in
order 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 serving
BSS), to another BSS (the target BSS), under control of the MSC. This is done by providing the MSC
a list of cells which the serving BSS believes are good candidates for the handover procedure based
on the radio measurements made by the MS.
When the handover algorithm signals that a handover is necessary (handover alarm), the candidate
cells filter and handover decision functionality in the dedicated radio resource control procedure
processes the cell list accompanying the handover alarm and determines the type of handover
required, (see ref [9]).
If an external handover is required the list is presented to the handover protocol and a handover is
triggered 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 before
the MSC responds to the HANDOVER REQUIRED message the list presented to the external
handover protocol is checked to ascertain whether a new cell is in the list or an old cell is no longer in
the 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.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
7/108

TELECOM
As an operator option the HANDOVER REQUIRED message may be sent with the OIE RESPONSE
REQUEST. The presence of this OIE requests the MSC to respond to the serving BSS with a
HANDOVER REQUIRED REJECT message if the MSC cannot service the request for whatever
reason.
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 a
HANDOVER REQUIRED REJECT message, all cells that were sent to the MSC in the last
HANDOVER REQUIRED message are transferred from the CLOLD list to the REJ_CELL_LIST. When
subsequent handover alarms are received, any cells in the cell list accompanying the handover alarm
which are also in the REJ_CELL_LIST cannot be used as candidate cells in external handover
attempts on the same connection. The REJ_CELL_LIST is emptied only on the expiry of timer T7 or
at the end of the external handover procedure.
If the MSC does not send a HANDOVER REQUIRED REJECT message no further HANDOVER
REQUIRED messages are allowed to be sent to the MSC until timer T7 expires or radio conditions
change. In the case where HANDOVER REQUIRED messages are sent at the rate of T7, this
prevents the MSC being overloaded.
When the MSC chooses one of the cells in the cell list CL with which to perform the handover, the
target 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 code
point forbidding channel rate change for the channel, it is the MSCs responsibility to ensure that the
channel specified in the HANDOVER REQUEST towards the target BSC is the same as allocated by
the initial BSC in the Chosen Channel OIE in the ASSIGNMENT COMPLETE message. Once the
handover has been performed it is the new BSCs responsibility to ensure that no changes are
allowed for subsequent internal handovers (see ref [9]).
Once the target BSS has successfully allocated the channel it passes back to the MSC the message
which will enable the MS to make the move to the activated channel. The MSC passes this to the
serving 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 precise
method of performing this is specified in ref [2] - GSM 04.08. Once communication is established with
the target BSS the MS signals a successful handover to the target BSS and the MSC initiates clearing
of the old connections to the serving BSS. At the end of an external handover the appropriate SCCP
connections (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 the
cells 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 it
can return to the old channel of the serving cell and any call in progress will continue until the need
for another handover is detected whereupon the procedure is repeated. For the case where
N_PREF_CELL = 1, when this handover failure occurs, the serving BSC remembers the only cell in
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
8/108

TELECOM
list CLOLD in MS_CELL_REJ_LIST. When subsequent handover alarms are received, any cell in the
cell list accompanying the handover alarm which is also in the MS_CELL_REJ_LIST cannot be used
as a candidate cell in external handover attempts on the same connection. The MS_CELL_REJ_LIST
is emptied only on the expiry of timer T_MS_CELL_REJ or at the end of the external handover
procedure.
Summary note: For this release MS_CELL_REJ_LIST is used only when N_PREF_CELL = 1 and the
cell remembered is the best cell, ie the first in the list sent to the MSC in the HANDOVER REQUIRED
message.
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 & mode
Channel type
Channel mode
SDCCH
Signalling
Note 2
TCH FR/HR
Signalling
Note 1
TCH FR
Speech or Data
TCH HR
Speech
Supported
Not supported
Supported
Supported
Table 2./1 Outgoing Handover Support

Note 1: The ALCATEL BSS does not support the allocation of TCH channels for signalling
transactions.
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 over
to 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-GSM
band.
Handovers between different speech versions (Full Rate version 1, Full Rate version 2, Half Rate
version 1) are supported.
2.3.1. - External Handover Test Call Functionality

The external handover procedure provides a facility allowing the inhibition of incoming handovers into
a cell. A flag EN_IC_HO, is provided on a per cell basis which when set true will allow all incoming
intercell synchronous or asynchronous handovers into the cell.
It should be noted that internal intra cell handovers are not affected by this flag. Furthermore, when
EXT_HO_FORCED is set to true, (ie O & M is forcing external handovers), external handovers with
the same serving and target cell are allowed irrespective of the setting of the flag EN_IC_HO.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
9/108
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 asynchronous
handover 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 INFORMATION
message.
GSM Phase 1 MSs may support more than one Ciphering algorithm (A5/1 or/and A5/2) however a
Phase 1 MS can not change Ciphering algorithm during channel changes or turn off ciphering. The
ALCATEL BSS takes this behaviour into consideration when performing external handover and
internal handover (ref [7]).
The ALCATEL BSS never allows the stopping, starting or changing of the Ciphering algorithm during
Channel changes (ie external handover, internal handover (ref [7]) & Assignment (ref [10])) for Phase
1 MSs. In this case the ALCATEL BSS will always activate Ciphering for a Phase 1 MS as indicated
by 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 release
ALCATEL 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 as
commanded by the Ciphering procedure (ref [14]).
A Phase 2 MS can be commanded to stop, start or change the Ciphering algorithm during channel
changes once ciphering has been initiated by the MSC. This type of behaviour in the MS allows the
MS to be supported in a mixed Ciphering network.
The ALCATEL BSS ensures during external handover that the MS Ciphering capabilities, BTS
Ciphering capabilities & MSC Ciphering requirements are taken into account whilst performing the
external handover procedure.
The ALCATEL BSS may command Phase 2 MSs to stop, start or change the Ciphering algorithm
during an external handover procedure depending on the MS Ciphering capabilities, BTS Ciphering
capabilities & 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 BCCH
carriers of neighbour cells. The neighbour cell list is sent to the MS in SYSTEM INFORMATION
TYPE 5 family messages on the SACCH. Measurements made by the MS are then transmitted to the
serving BSS by use of MEASUREMENT REPORT messages sent on the SACCH - See Note 1. Only
six 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 and
synchronous 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 and
reports it to the BSC handover algorithm together with the MS measurements - see ref [12].
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
10/108
TELECOM

Serving BSC Handover algorithm

The BSS takes the measurements from the MS and the BTS and analyses whether it is necessary to
perform a handover - ref [8].
When a handover is required a handover alarm is sent to the serving BSC handover protocol with a
list of preferred cells.
The BSS handover algorithm controls the rate at which internal handover alarms are generated by the
use of the timer T_FILTER - See section "Interaction of handover algorithm & external handover
protocol".
Serving BTS Handover protocol
The Serving BTS plays no active role in the handover protocol. Its main function is to relay messages
and 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 from
the candidate list that the MSC has previously rejected or that the MS has failed to handover to. It
also 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 of
candidate cells for the handover process by removing cells from the candidate list that have already
been sent to the MSC and rejected for this handover attempt. This document will specify the serving
BSC 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 protocol
will 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 Ciphering
capabilities, MSC Ciphering requirements and channel allocation in accordance with MSC
requirements.
Note 1
An overview of MS & MSC functions will be given so as to aid the reader. Behaviour may deviate due
to implementation choices in the MS and MSC.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
11/108
TELECOM

3. - DYNAMIC BEHAVIOUR
3.1. - General Behaviour
This section contains the successful and major failure cases of an external handover which consist
mainly of errors due to timer expiry and GSM defined messages. No account is taken in this section
of 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 to
the handover protocol, all or some of which are sent to the MSC in a HANDOVER REQUIRED
message. 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 asynchronous
handover for a serving BSS.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
12/108

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 a
list of candidate cells.
The BSC initiates an external handover by sending a HANDOVER REQUIRED message with
cell list CL containing a maximum of N_PREF_CELLs obtained from the cell list reported in
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
13/108

TELECOM
the handover alarm.

T7 is started to prevent the BSC from offering the same cell list CL to the MSC again too
quickly 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
depending 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 then
sends a HANDOVER REQUEST message to the target BSS and starts Trr2.
The target BSC activates an appropriate RF channel (4a & 4b), builds the HANDOVER
COMMAND message destined for the MS, sends it to the MSC in the HANDOVER
REQUEST ACK and starts T9113 to supervise the handover.
The target BTS starts sending dedicated system information messages on the SACCH (see
ref [17]). The TA in the Layer 1 header shall indicate that the timing advance information is
invalid.
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 used
on the old channel.
The MSC: stops Trr2; forwards the message to the serving BSS in a HANDOVER
COMMAND message; and starts T3103.
The serving BSC: stops T7 and T_HO_REQ_LOST, sends the HANDOVER COMMAND to
the 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 BSC
detailed behaviour.
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 the
main DCCH of the RF channel indicated in the HANDOVER COMMAND message with a TA
of 0); and starts T3124.
The target BTS checks the handover reference and calculates the timing advance from the
reception of the HANDOVER ACCESS, relays a HANDOVER DETECTION to the target
BSC and starts deciphering (if applied).
The target BSC: relays a HANDOVER DETECT to the MSC and makes the switch path (TCH
only).
The target BTS: sends the PHYSICAL INFORMATION message to the MS with the
calculated 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 timer
T3105 is started.
The MS stops T3124 and connects to the channel..
The MS establishes SAPI 0 with an SABM.

The target BTS on reception of the SABM SAPI 0 or any correct frame stops T3105, (see
Note 9a ), sends an ESTABLISH INDICATION (SAPI 0) to the target BSC (only if SABM
SAPI 0 is received), starts T_CFI_tr; sends a UA to the MS and starts 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 sending PHYSICAL INFORMATION and the timer T3105 when it
receives a correctly received frame - see ref [7]. The event that stops T3105 (ie SABM SAPI
0 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 the
BTS).
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
14/108

TELECOM
The target BSC stops timer T9113 and forwards a HANDOVER COMPLETE message to the
MSC.
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 1
MS (see 3.2.6.4.1); then CHANNEL MODE MODIFY message is sent to the MS. The
corresponding CHANNEL MODE MODIFY ACK or CHANNEL MODE MODIFY NACK is
discarded.
11
The serving BSS RF channel and terrestrial resources are released. This is performed by the
MSC sending the CLEAR COMMAND (cause "Handover successful") - ref [6] EHS0400, T8 is
stopped.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
15/108
TELECOM

3.1.2. - Successful External Synchronous Handover

The following message sequence chart shows the scenario of a successful external synchronous
handover for a BSS which controls both serving & target cells (BTSs) where the target & serving cells
are 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]
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
16/108

TELECOM
The external handover is initiated by sending a HANDOVER REQUIRED message with cell
list CL containing a maximum of N_PREF_CELLs obtained from the cell list reported in the
handover alarm.
T7 is started to prevent the BSC from offering the same cell list CL to the MSC again too
quickly 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).
The MSC chooses one of the cells within the cell list and identifies the target BSS. It then
sends a HANDOVER REQUEST message to the BSS and starts Trr2.
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 COMMAND
message (indicating synchronised handover) destined for the MS; sends it to the MSC in the
HANDOVER REQUEST ACK; and starts T9113 to supervise the handover.
4a
The Channel activation in this case has no timing advance information, as the information is
not available in the HANDOVER REQUEST message, therefore the target BTS: starts
ciphering immediately (if applied); SACCH transmission of dedicated system information
messages is started immediately & any Layer 1 header sent to Air will indicate that the timing
advance information is invalid.
In this case the MS uses the timing advance that was set on the old channel. until timing
advance is available on the new channel.
4b
For Phase 2 MSs the Ciphering used on the new channel may be different from the one used
on the old channel.
The MSC: stops Trr2; forwards the message to the serving BSS in a HANDOVER
COMMAND message; and starts T3103.
The serving BSC: stops T7 and T_HO_REQ_LOST; sends the HANDOVER COMMAND to
the 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 on
serving BSC detailed behaviour.
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 the
BTS (on the main DCCH of the RF channel indicated in the HANDOVER COMMAND
message).
The target BTS checks the handover reference and relays a HANDOVER DETECTION to
the target BSC and starts deciphering (if applied).
The target BSC relays a HANDOVER DETECT to the MSC and makes the switch path (TCH
only).
The target BTS calculates the timing advance, the timing advance algorithm is informed of
the new timing advance, the Layer 1 header is set accordingly and timer T3106 is started.
The MS establishes SAPI 0 with an SABM
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
17/108

TELECOM
The target BTS: stops T3106 - see Note 9a, sends an ESTABLISH INDICATION (SAPI 0) to
the target BSC (only if SABM SAPI 0 is received), starts T_CFI_tr, sends a UA to the MS and
starts 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 0
or 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 the
BTS).
The target BSC stops timer T9113 and forwards a HANDOVER COMPLETE message to the
MSC.
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 1
MS (see 3.2.6.4.1), then CHANNEL MODE MODIFY message is sent to the MS. The
corresponding CHANNEL MODE MODIFY ACK or CHANNEL MODE MODIFY NACK is
discarded.
11
The serving BSS RF channel and terrestrial resources are released. This is performed by the
MSC 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 (or
cells that were reported in the last handover alarm are no longer present) the BSC has to update the
MSC with the new cell list in order that the MSC is kept up to date and best cell is chosen for the
handover. If the cells do not change then there is no need for the BSC to repeat the handover
attempt 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 repeated
HANDOVER REQUIRED messages to the MSC, each with a new cell list.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
18/108

TELECOM
The cell list presented with the handover alarm is processed and a cell list CL1 (maximum of
N_PREF_CELLs) is sent with the HANDOVER REQUIRED message. The cell list is
remembered as CLOLD. Timers T7 and T_HO_REQ_LOST are started.
Before the MSC has responded to this handover attempt another handover alarm is received
at the BSC with different cell information. The BSC sends a further HANDOVER REQUIRED
message to the MSC with cell list CL2 (maximum of N_PREF_CELLs). CL OLD is replaced by
the 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 REQUIRED
message 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 RESPONSE
REQUEST in the HANDOVER REQUIRED message. The inclusion of this OIE is an operator option
controlled by the O & M parameter RESP_REQ. The presence of the OIE requests the MSC to
respond to the serving BSS with the HANDOVER REQUIRED REJECT message if the MSC cannot
service the request for whatever reason. The inclusion of this OIE is described in the section
HANDOVER REQUIRED message construction.
Timer T7 is fundamental to the operation of the external handover procedure when the MSC cannot
perform a handover to any of the cells offered in the HANDOVER REQUIRED message and the
behaviour of the BSC in offering alternative cells depends on whether the MSC sends the
HANDOVER REQUIRED REJECT message or not.
T7 controls the rate at which a HANDOVER REQUIRED message, containing the same sent
candidate cell, is sent to the MSC. When HANDOVER REQUIRED REJECT is received it also
determines 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 External
Synchronous 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 to
the MSC in a new HANDOVER REQUIRED message
The following scenarios illustrate T7 functionality both when a HANDOVER REQUIRED REJECT is
received and when it is not. The interactions between the internal and external handover procedures
are 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 the
HANDOVER REQUIRED message.
When the HANDOVER REQUIRED REJECT message is received the BSS cannot offer any cells in
the REJ_CELL_LIST in subsequent HANDOVER REQUIRED messages until T7 expires. After
receiving any further handover alarm, it may offer alternative cells, if any are available after the cell
list received has been filtered. If none is available then no HANDOVER REQUIRED message can be
sent. 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.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
19/108

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 HANDOVER
REQUIRED 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. Internal
handovers are now disabled. The maximum number of cells sent in the message is
controlled by the O & M parameter N_PREF_CELL. The cell list CL1 is remembered by the
BSC as CLOLD.
A further handover alarm is received but the cell information has not changed (eg the MS has
not moved location). Consequently no HANDOVER REQUIRED message is sent to the
MSC.
The MSC cannot service the handover request and sends a HANDOVER REQUIRED
REJECT message. On reception of the HANDOVER REQUIRED REJECT the BSC stops
T_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 handover
requests until timer T7 expires, see section 3.3.3.1.1. - Internal Handover after External
Handover. CLOLD is now forgotten.
Another handover alarm is reported and any cells in this handover alarm which are in the
REJ_CELL_LIST or MS_CELL_REJ_LIST are not used in the next handover attempt. The
cell list CL2, to be used is built (see section 3.2.2.1. - External Handover Decision).
A further HANDOVER REQUIRED message with OIE RESPONSE REQUEST and containing
cell list CL2 is sent to the MSC. T_HO_REQ_LOST is started and T7 restarted. .The cell list
CL2 is now remembered by the BSC as CLOLD. This sequence of events is repeated until
the handover succeeds, T7 or T_HO_REQ_LOST expires - see sections 3.3.3.1.1. - Internal
Handover after External Handover, and 3.1.5.1. - T_HO_REQ_LOST Expiry.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
20/108
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 the
handover 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 HANDOVER
REQUIRED message with a list of cells (CL1), obtained from the handover alarm. T7 and
T_HO_REQ_LOST are started. The maximum number of cells sent in the message is
controlled by the O & M parameter N_PREF_CELL. The cell list CL1 is remembered by the
BSC as CLOLD.
The MSC cannot perform a handover to any of the cells in CL1 and does not send a
HANDOVER REQUIRED REJECT message to the BSC. T7 and T_HO_REQ_LOST
continue to run.
Subsequent handover alarms are received but the cells have not changed (eg the MS has not
moved location). Consequently no HANDOVER REQUIRED messages are sent to the MSC.
Timer T7 expires. Internal handovers will only be enabled in this case when
T_HO_REQ_LOST expires (see section 3.1.5.1. - T_HO_REQ_LOST Expiry).
A handover alarm occurs with the same cells as before. A HANDOVER REQUIRED
message containing cell list CL2 is sent to the MSC. T7 is started and the cell list CL2 is now
remembered by the BSC as CLOLD. This sequence of events is repeated until the handover
succeeds 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
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
21/108
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 INFORMATION
message after sending the HANDOVER ACCESS);
4. Failure to receive the UA when attempting to establish the channel, or any layer 2 or layer 1
failure.
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 and
sends the HANDOVER FAILURE. If N_PREF_CELL = 1 the BSC adds the only cell in CLOLD to
MS_CELL_REJ_LIST when the HANDOVER FAILURE is received and starts timer
T_MS_CELL_REJ.
In the case 5 it has been found in the field that the MS may choose to do a combination of the
following:
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 FAILURE
message.
If the MS sends both RR STATUS and HANDOVER FAILURE then the behaviour of the ALCATEL
BSS is as per the HANDOVER FAILURE case.
In the case where the MS can detect that the handover cannot be performed, (eg timing advance out
of range or channel mode unacceptable), then it can send a HANDOVER FAILURE on the old
channel without attempting the handover access to the target BSS. In these cases prior reestablishment of the lower layer is unnecessary.
The message sequence chart shown below shows the scenario for the reception of HANDOVER
FAILURE.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
22/108

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 BTS
returns UA and sends an ESTABLISH INDICATION SAPI 0 to the BSC. The serving BSC
has no external reaction to the ESTABLISH INDICATION of SAPI 0. A phase 2 MS may
send HANDOVER FAILURE without detaching. This results in no EST IND being sent before
the HANDOVER FAILURE.
When the MS receives the UA it returns a HANDOVER FAILURE message to the serving
BTS.
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 with
cause "Radio interface failure -reversion to old channel". The only cell in CL OLD is added to
the MS_CELL_REJ_LIST and timer T_MS_CELL_REJ is started (provided N_PREF_CELL is
not greater than 1). Any cell in MS_CELL_REJ_LIST cannot be used in subsequent
handover 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 call
continues on the old channel.
The MSC releases the target BSS resources by sending a CLEAR COMMAND with cause
"Radio interface failure, reversion to old channel" - ref [6] EHT1100.
T_MS_CELL_REJ expires and MS_CELL_REJ_LIST is emptied. The cells which were in the
list may again be used in handover attempts.
The following scenario illustrates the management of the MS_CELL_REJECT LIST for subsequent
failures to complete a handover to the target cell.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
23/108

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 BTS
returns UA and sends an ESTABLISH INDICATION SAPI 0 to the BSC. The serving BSC
has no external reaction to the ESTABLISH INDICATION of SAPI 0. A phase 2 MS may
send HANDOVER FAILURE without detaching. This results in no EST IND being sent before
the HANDOVER FAILURE.
When the MS receives the UA it returns a HANDOVER FAILURE message to the serving
BTS.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
24/108

TELECOM
the MS_CELL_REJ_LIST and timer T_MS_CELL_REJ is started (provided N_PREF_CELL is

not greater than 1). Any cell in MS_CELL_REJ_LIST cannot be used in subsequent
handover 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 call
continues 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.
Another handover alarm is generated by the handover algorithm and a HANDOVER

REQUIRED message is sent to the MSC. The cell in MS_CELL_REJ_LIST is excluded from
the cell list sent to the MSC (if present in the handover alarm). CL OLD is overwritten with the
cell list sent . For clarity the HANDOVER REQUEST protocol to the target BSC is not shown.
A HANDOVER COMMAND is returned by the MSC to the serving BSS and forwarded to the
MS.
The MS fails to attach to this cell also and sends a HANDOVER FAILURE message to the
serving BTS. The RR cause value contained in the message is not defined.
the MS_CELL_REJ_LIST and timer T_MS_CELL_REJ is restarted. MS_CELL_REJ_LIST
now contains the latest cell and the previous cell to which the handovers were attempted.
T_MS_CELL_REJ expires and MS_CELL_REJ_LIST is emptied. Both cell list may again be
used 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 determines
when the external handover procedure has finished. On expiry an O & M error report is raised. The
scenario below shows several handover attempts culminating in T_HO_REQ_LOST expiring.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
25/108

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 HANDOVER
REQUIRED to the MSC with a cell list CL1. T7 and T_HO_REQ_LOST are started.
A further handover alarm is received with different cell information. A further HANDOVER
REQUIRED message is sent with an updated cell list, T7 is restarted. This may occur several
times.
Further handover alarms are received but there is no different cell information to send to the
MSC, no HANDOVER COMMANDS are sent. Eventually T7 will expire and HANDOVER
REQUIRED messages may be sent again with the same cell information, (see section
3.1.3.2.2. - MSC Does Not Send HANDOVER REQUIRED REJECT)
There is no response from the MSC and T HO_REQ_LOST expires. If T7 is running at this
time it is stopped and an O & M error report is raised.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
26/108
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 of
the timer indicates that the MS did not return to the old channel and the MSC has not initiated a call
release 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.
The serving BSC initiates a Call release - ref [6] EHS0100.
The MSC may choose to initiate a Call release scenario. This will depend on the events
received 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 HANDOVER
REQUEST is as follows:
1
if an internal failure is detected a HANDOVER FAILURE is sent to the MSC, this allows the
MSC to retry;
if a failure is detected indicating that the MS has failed to atta ch to the new channel then a
CLEAR REQUEST will be sent to the MSC.
In both cases, Air interface resources and CIC (TCH only) will be released.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
27/108
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, CHANNEL
ACTIVATION ACK, or CHANNEL ACTIVATION NACK messages on Abis the timer expires and the
target BSC attempts to release the resource in the BTS - ref [6] EHT0200 and sends a HANDOVER
FAILURE 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 CHANNEL
ACTIVATION message to the target BTS; and starts T9103.
The target BSC detects that there is no response from the BTS by the expiry of timer T9103.
The target BSC sends a HANDOVER FAILURE message to the MSC - ref [6] EHT0200.
The target BSC starts T9110 to guard the response of the MSC and attempts to release the
target 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 been
sent 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 target
BTS).
When the timer expires, the target BSC releases towards the MS, the target BTS resources and the
BSC 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.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
28/108

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 an
error during the Channel activation procedure.
The reception of the CHANNEL ACTIVATION NACK will cause the allocated RF resource to be
released locally within the target BSC - see ref [6] EHT0101, EHT0102 & EHT0103, and an O&M
error report will be sent to O&M.
When the CHANNEL ACTIVATION NACK message is received with the cause "Encryption algorithm
not implemented " the BSC sends to O&M an O&M error report - it is left to O&M procedures to clear
the database inconsistency.
A HANDOVER FAILURE message will be sent to the MSC with the causes defined in ref [6] and
T9110 is started to supervise the response of the MSC.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
29/108

TELECOM
Fig 3./10 Channel Activation NACK

Note A: Channel release with target BTS when cause in the CHAN ACT NACK is "Channel already
activated".
3.1.6.4. - Connection Failure Indication (Cause "Handover Access Failure")

The CONNECTION FAILURE INDICATION (cause "Handover access failure") is sent to the target
BSC by the target BTS. The reception of this message during the external handover procedure, is an
indication that the MS has been able to send a correct HANDOVER ACCESS to the target BSS but
has not been able to establish the Layer 2 connection or send a TCH or Layer 2 frame (see ref [7] for
more detail). The connection is cleared - ref [6] EHT0400.
For the System behaviour for all other cause values in the CONNECTION FAILURE INDICATION
refer 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 "Handover
Access Failure") Synchronous Handover
Once the target BTS has received on the main DCCH a HANDOVER ACCESS message with the
correct handover reference it calculates the timing advance for the MS, places it in the Layer 1
header of SACCH messages starts deciphering and starts timer T3106. Note: SYSTEM
INFORMATION 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 the
BTS 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 BTS
has received any correct frame (ie TCH frame or Layer 2 frame independent of the SAPI value). This
EXTERNAL HANDOVER
ED
02 RELEASED
MCD
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
30/108
TELECOM

behaviour means that the target BTS does not ensure that the SAPI 0 connection is established
during handover.
Note that the STOP HO ACC FAIL flag is implemented per a BSC. Due to testing requirements the
BTS 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 connection
by sending a DM frame. It is impossible for an MS to connect to this channel, after this event has
been detected.
The MS has successfully synchronised to the target cell and sends the correct HANDOVER
ACCESS on 4 consecutive slots on the main DCCH (Timing advance 0).
The target BTS checks the handover reference, starts deciphering (if applied) and sends a
HANDOVER DETECTION message to the target BSC.
The target BSC sends a HANDOVER DETECT to the MSC.
The target BTS: calculates the timing advance, informs the timing advance algorithm; sets
the timing advance in the Layer 1 header on SACCH messages; and starts T3106.
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 the
Air interface).
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
31/108
TELECOM

The timer T3106 expires in the target BTS: LAPDm is placed into the idle state with 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
T200 expires in the MS. The MS: sends the SABM once more; and starts T200.
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 immediately towards the target BTS (ref [6]
EHT0400) an incorrect setting of T3106 will mean that the target RF channel may be released
whilst the MS is still there.
Note A: The refuse option is a speciality of the ALCATEL BTS. When this option is set all attempts by
the MS to establish a LAPDm connection will be refused by the BTS LAPDm entity. This is
achieved 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 is
being sent to L3 whilst L3 is initiating the refuse option) the Layer 2 LAPDm will not accept
the refuse option and allow the LAPDm to be established. see reference [22]
3.1.7.2. - T3105 Expiry & Connection Failure Indication (Cause "Handover

Access Failure") Asynchronous Handover
Once the MS has sent on the main DCCH a HANDOVER ACCESS message with the correct
handover reference. The target BTS: calculates the timing advance for the MS sends on the main
DCCH the PHYSICAL INFORMATION message; starts deciphering (if applied); and starts the timer
T3105.
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 the
BTS 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 BTS
has received any correct frame (ie TCH frame or Layer 2 frame independent of the SAPI value). This
behaviour means that the target BTS does not ensure that the SAPI 0 connection is established
during handover.
Note that the STOP_HO_ACC_FAIL flag is implemented on a per BSC basis. Due to testing
requirements 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 has
received (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 the
require response from the MS, then the target BTS will: send a CONNECTION FAILURE
INDICATION message (cause "Handover access failure"); and place LAPDm into the "idle" state with
the refuse option set - see Note A.
The LAPDm, whilst in this state, will reject any attempt from an MS to establish a Layer 2 connection
by sending a DM frame.
It is impossible for an MS to connect to this channel, after this event has been detected.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
32/108

02
16/02/98 10:12
41.DOC
RELEASED
TELECOM
33/108
EXTERNAL HANDOVER
3BK 11202 0104 DSZZA
The message sequence chart below shows the case where NY1 is 2.
ED
MCD
TELECOM

The MS has: successfully synchronised to the target cell; starts to send the correct
HANDOVER 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.
The target BTS: calculates the timing advance; informs the timing advance algorithm o f the
calculated timing advance; sets the timing advance field in the Layer 1 header of the SACCH
messages; sends the PHYSICAL INFORMATION message with the calculated timing
advance to the MS on the main DCCH; and starts T3105.
The MS: stops T3124; stops sending the HANDOVER ACCESS; adjusts its timing to the data
held in the PHYSICAL INFORMATION message; connects to the TCH channel; sends an
SABM (SAPI 0); and starts T200.
The target BTS: does not receive the SABM or another correct frame (they are lost on the Air
interface).
The timer T3105 expires in the target BTS and the PHYSICAL INFORMATION is sent again.
The timer T3105 expires (NY1 times) in the target BTS: LAPDm is placed into the idle state
with 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.
T200 expires in the MS. The MS: sends the SABM once more; and starts T200.
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 target
channel.
Note A: The refuse option is a speciality of the ALCATEL BTS. When this option is set all attempts by
the MS to establish a LAPDm connection will be refused by the BTS LAPDm entity. This is
achieved 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 is
being sent to L3 whilst L3 is initiating the refuse option) the Layer 2 LAPDm will not accept
the refuse option and allow the LAPDm to be established.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
34/108
TELECOM

3.2. - Detailed Behaviour

3.2.1. - Serving BTS Protocol
The serving BTS provides: remote transcoder alarm filtering (TCH channel only); message passing
service and information regarding events in the serving BTS and events detected by the serving BTS
and the MS, during the external handover protocol. The serving BTS is unaware of the external
handover protocol taking place.
The serving BTS will not refuse access to the MS in the event of an Air interface failure on the old
channel.
No error detected on the Air interface on the old channel side will cause the serving BTS to
automatically release the MS connection (it is the BSCs 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 decision
Given the cell list from the BSS handover algorithm and a set of O&M flags, this function decides
whether an external handover is to be performed.
External Handover protocol
Once the external handover detection mechanism indicates that an external handover is required, this
function 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 external
handover protocol by comparing the list against CLOLD, checking for any new cell in the list or an old
cell no longer in the list.
The O & M Parameters and other variables listed in section 4.4 are then used to determine whether
an 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 Immediate
assignment 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. For
this reason, the condition ASSGN is used.
In order to allow the MSC to initiate and complete the ciphering and identification procedures without
interruption from a handover, a mechanism is foreseen to hold off any potential handover alarms at
the beginning of the transaction. This mechanism uses the parameter SDCCH_COUNTER and the
variable DOT.
The rules for deciding whether an external SDCCH handover is possible after an Immediate
assignment procedure are as follows:
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
35/108
TELECOM

if (BCE == TRUE OR
(BCE == FALSE
AND NOT("Intra-cell alarm")

AND EXT_HO_FORCED == TRUE
AND EN_IC_HO (target cell) == TRUE))
/*Best cell is really external or O&M forces ext HO*/

AND HO_INTERCELL_ALLOWED == TRUE
AND 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
else
if BCE == FALSE
then 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. For
this reason, the condition ASSGN is used.
The rule for deciding whether an external SDCCH handover is initiated as follows:
if (BCE == TRUE OR
(BCE == FALSE


AND HO_SDCCH_INHIBIT == FALSE
/*O&M allows SDCCH HO*/
AND ASSGN == FALSE
then initiate external SDCCH HO
else
if BCE == FALSE
then 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, or
during 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:
if (BCE == TRUE OR
(BCE == FALSE


AND ASSGN == FALSE
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
36/108
TELECOM

then
initiate external TCH HO
else
if BCE == FALSE
then 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) it
is 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 and
the major events only that cause state transitions. The full list of events is defined in the state tables
in this section.
The expiry of T_MS_CELL_REJ causes no state change and is handled in every state. The only
action on expiry is the emptying of the list MS_CELL_REJ_LIST.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
37/108

ED
MCD
7([S
+25HT
5HM
6WRS7B+2B5(4B/267
5HVWDUW7
Send HO REQUIRED
+25(45(-
([WHUQDO
18//
([WHUQDO
TELECOM
6WDUW7
3URJ
(+2,Q
7([S
6WRS7B+2B5(4B/267
6HQG2 0(UURU5HS
6WRS7
,QWHUQDO+DQGRYHU3URFHGXUH
&OHDU
+25(45(-
+2&RPPDQG
6WDUW7
6WRS7B+2B5(4B/267
6WRS7
+2&RPPDQG
7B+2B5(4B/267([S
7([S
T7 Exp
(PSW\5(-B&(//B/,67
(+2,QLW
6WDUW7B+2B5(4B/267
6WDUW7
Send HO REQUIRED
+2$ODUP%&
+2$ODUP%&
+2$ODUP
&/GLIIHUHQW
6WDUW7
Send HO REQUIRED
+2$ODUP
7B+2B5(4B/267([S
+2)DLO
6WDUW7B06B&(//B5(-
VWFHOOLQ&/2/'
6WRS7
6HQG+2)$,/
!06B&(//B5(-B/,67
6WRS7B+2B5(4B/267
6HQG2 0(UURU5HS
38/108
EXTERNAL HANDOVER
3BK 11202 0104 DSZZA
Fig 3./13 Serving BSC State Diagram & Major Events (See notes overleaf)
6WDUW7B+2B5(4B/267
6WDUW7
Send HO REQUIRED
&/2/'!5(-B&(//B/,67
+2$ODUP&/GLIIHUHQW
6WDUW7
6WRS7
7R6WDWH(+2,Q3URJ
RELEASED
+2&RPPDQG
02
41.DOC
16/02/98 10:12

Notes :
1. CLOLD is only cleared when entering the NULL state; when updated in any other state it is always
overwritten with new information.
2
Any entry to the NULL state will clear CLOLD and REJ_CELL_LIST but not
MS_CELL_REJ_LIST.
STATE DESCRIPTION
ABBREVIATION
This state represents one of the entry and exit states of the
external handover protocol. (note an external handover may
be initiated during an internal handover, when the next cell in
the preferred cell list is external to the serving BSS)
NULL
The serving BSC has initiated an external handover (by

sending the HANDOVER REQUIRED), T7 and
T_HO_REQ_LOST are running and the serving BSC is
awaiting a response from the MSC or a change in radio
conditions.
EXT HO INIT.
The serving BSC has received the HANDOVER COMMAND

and 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 to

which the MSC has replied with a HANDOVER REQUIRED
REJECT. All cells in CL OLD have been added to
REJ_CELL_LIST. T7 is running.
HO REQ REJ
The serving BSC has sent a HANDOVER REQUIRED and

T7 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.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
39/108

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 and
is used for representation in this document. In fact an external handover may be triggered from
within an internal handover procedure where the next best cell in the preferred cell list is external to
the 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 to

MSC with cell list CL
Store CL as CLOLD
Start T7
Start T_HO_REQ_LOST
Next state (EXT HO INIT)
Handover Alarm (Best cell not

external)
Internal handover attempted, see ref

15.
Table 3./2 NULL State events
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
40/108
TELECOM

3.2.2.2.2. - Normal Events

STATE
EVENT
HANDOVER
COMMAND
EXT HO INIT
EXT HO
IN PROG
Discard the message
Note 1
T7 EXPIRY
HO REQ REJ
stop T_HO_REQ_LOST
stop T7
send HO CMD to MS
send HO CMD to MS
send HO CMD to MS
start T8
start T8
start T8
next state (EXT HO IN

PROG)
next state (EXT HO IN PROG)
stop T_HO_REQ_LOST
Discard (note 2)
stop T7
stop T_HO_REQ_LOST
next state (EXT HO IN PROG)

HANDOVER
REQUIRED
REJECT
T7 EXP
stop T_HO_REQ_LOST
Discard
Add CLOLD to REJ_CELL_LIST

Next state (HO REQ REJ)
Empty REJ_CELL_LIST
next state (NULL)
Not Applicable
Not applicable
Next State (T7 EXP)

T8 EXPIRY
Not Applicable
T_HO_REQ_LOST
expiry
Stop T7
Send O & M Event
Empty REJ_CELL_LIST
Next State (NULL)
Queued DTAP messages are

discarded(see section
3.2.2.2.5)
ref [6] EHS0100
Next state (NULL)
Not applicable
Not applicable
Not Applicable
Send O & M Event
Not Applicable
Next state (NULL)
Empty REJ_CELL_LIST
Empty MS_CELL_REJ_LIST
Next state (NULL)
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
41/108
TELECOM

Handover Alarm
See Note 3
Discard
Send HANDOVER REQUIRED

to MSC with cell list CL
Store CL as CLOLD
restart T7
HANDOVER
FAILURE
Not Applicable
Send HO FAIL (cause

"reversion to old channel")
See Note 3
See note 3
Send HANDOVER
REQUIRED to MSC with cell
list CL
Store CL as CLOLD
restart T7
Next State (EXT HO INIT)
Send HANDOVER
REQUIRED to MSC with cell
list CL
Store CL as CLOLD
restart T7
start T_HO_REQ_LOST
Next State (EXT HO INIT)
Not Applicable
Not Applicable
Stop T8
If N_PREF_CELL = 1
Add 1st cell of CLOLD toMS_CELL_REJ_LIST
Start T_MS_CELL_REJ_LIST (note
7)
endif
discarded (see section
3.2.2.2.5)
Ref [6] EHS0200
Next State (NULL)
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
42/108

TELECOM
CLEAR
COMMAND
(Cause
Handover
successful)
Note 4
Note 5
Note 4
Note 4
stop T7
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
stop T8
Stop T_MS_CELL_REJ
Stop T7
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
ref [6] N0600
ref [6] N0600

discarded (see section
3.2.2.2.5)
ref [6] EHS0400
Next State (NULL)
Next State (NULL)
stop T_HO_REQ_LOST
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
stop T_HO_REQ_LOST
Next State (NULL)
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 not
empty 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 is
unexpected 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 when
the 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 cells
are reported in the handover alarms), if T _MS_CELL_REJ is not running then internal handovers may be performed since the external handover
procedure has terminated..
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
43/108
TELECOM

3.2.2.2.3. - Unexpected Events

STATE
EVENT
CLEAR
COMMAND
Note 1
EXT HO
INIT
stop T_HO_REQ_LOST
stop T7
EXT HO
IN PROG
Deferred until outcome of
Ext HO
Note 3
T7 EXP
HO REQ REJ
stop T_HO_REQ_LOST
stop T7
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
Next state (NULL)
ref [6] N0600
Empty REJ_CELL LIST

Next state (NULL)
Next state (NULL)
ref [6] N0600
ref [6] N0600

SCCP-N-DISC
Deferred until outcome of Ext

HO
Note 6
stop T_HO_REQ_LOST
stop T7
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
Empty REJ_CELL LIST
ref [6] N0500
Next state (NULL)
ref [6] N0500
stop T_HO_REQ_LOST
stop T7
Next state (NULL)
Next state (NULL)
ref [6] N0500

DTAP message
Send to MS via BTS
Queue message (see section

3.2.2.2.5)
Send to MS via BTS
Send to MS via BTS
CIPHER MODE
COMMAND
Perform Ciphering
Discard message
Perform Ciphering
Perform Ciphering
External Handover continues
External Handover continues
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
44/108
TELECOM

ASSIGNMENT
REQUEST
Discard message
stop T_HO_REQ_LOST
stop T7
stop T7
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
Empty REJ_CELL_LIST
Next state (NULL)
stop T_HO_REQ_LOST
Next state (NULL)
Next state (NULL)
Perform Assignment
Perform Assignment
stop T_HO_REQ_LOST
stop T7
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Abandon handover;
Perform Assignment
RESET
A i/f: SCCP release

immediate Note 7
stop T_HO_REQ_LOST
stop T7
Air: Deferred until outcome of

Ext HO Note 4
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
Empty REJ_CELL LIST
Next state (NULL)
Next state (NULL)
Next state (NULL)
ref [6] N0900
ref [6] N0900
stop T_HO_REQ_LOST
stop T7
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
Empty REJ_CELL LIST
Empty REJ_CELL LIST
Next state (NULL)
Next state (NULL)
Next state (NULL)
ref [6] N1000
ref [6] N1000
ref [6] N0900

RESET CIRCUIT
A i/f: SCCP release

immediate Note 7
stop T_HO_REQ_LOST
stop T7
Air: Deferred until outcome of

Ext HO Note 4 & 5
stop T_MS_CELL_REJ
ref [6] N1000

Table 3./4 Unexpected Event Handling A Interface & DTAP
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
45/108
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 RF
channel 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 DTAP
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 this case, the
DTAP 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, the
DTAP 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 this
case, 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 RF
Channel 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 the
queue).
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 DTAP
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 this case, the
DTAP 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 the
Circuit 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 will
the 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.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
46/108
TELECOM

3.2.2.2.4. - Events from BTS

STATE
EVENT
CONN FAIL INDIC
(Radio-link Fail)
EXT HO INIT
EXT HO IN PROG
Stop T7
Stop T_HO_REQ_LOST
Discard message
T7 EXP
HO REQ REJ
Stop T_HO_REQ_LOST
Stop T7
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
ref [6] N0700

Next state (NULL)
Empty REJ_CELL LIST
ref [6] N0700

Next state (NULL)
ref [6] N0700

Next state (NULL)
CONN FAIL INDIC
(Remote Trans
Failure)
Stop T7
Stop T_HO_REQ_LOST
Discard message
Stop T_HO_REQ_LOST
Stop T7
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
ref [6] N0800

Next state (NULL)
ref [6] N0800
Empty REJ_CELL LIST

ref [6] N0800
Next state (NULL)
Next state (NULL)

EST INDIC SAPI 0
Dont care
Note 5
Dont care
Dont care
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
47/108
TELECOM
ERR REP (O&M

intervention)
Stop T7
stop T8
Stop T_HO_REQ_LOST
Stop T_HO_REQ_LOST
Queued DTAP messages

are discarded
stop T_MS_CELL_REJ

stop T_MS_CELL_REJ
Empty REJ_CELL LIST
ref [6] N0400
Stop T7
stop T_MS_CELL_REJ
Empty REJ_CELL LIST

ref [6] N0400

Next state (NULL)
ref [6] N0400

Next state (NULL)
ref [6] N0400

Next state (NULL)
ERR REP SAPI 0
(Msg seq err)
Stop T7
Discard message
Stop T_HO_REQ_LOST
Stop T7
stop T_MS_CELL_REJ
Stop T_HO_REQ_LOST
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
ref [6] N1200

Next state (NULL)
Empty REJ_CELL LIST

ref [6] N1200
Next state (NULL)
ref [6] N1200

Next state (NULL)
ERR INDIC SAPI
0 (Note 2)
stop T7
Discard message
Stop T_HO_REQ_LOST
Stop T7
stop T_MS_CELL_REJ
Stop T_HO_REQ_LOST
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
ref [6] N0100

Next state (NULL)
Empty REJ_CELL LIST

ref [6] N0100
Next state (NULL)
ref [6] N0100

Next state (NULL)
ERR INDIC SAPI
0 (Note 3)
Dont care
Discard message
Dont care
Dont care
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
48/108
TELECOM

REL INDIC SAPI 0
Discard message
stop T7
Stop T_HO_REQ_LOST
Stop T7
stop T_MS_CELL_REJ
Stop T_HO_REQ_LOST
stop T_MS_CELL_REJ
stop T_MS_CELL_REJ
Empty REJ_CELL LIST
ref [6] N0200

Next state (NULL)
Empty REJ_CELL LIST

ref [6] N0200
Next state (NULL)
ref [6] N0200

Next state (NULL)
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.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
49/108

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 the
EXT HO IN PROG, state) are as follows:
Up to 5 DTAP messages will be buffered by the BSC. DTAP messages received when the
buffer is full will be discarded. During dequeuing,when the channel change procedure
completes, only the first SAPI 3 message is sent to the MS if the SAPI 3 connection is
already established or the establishment of a SAPI 3 connection has been initiated (in which
case, the first SAPI 3 message is forwarded to the MS as soon as the connection is
established).
If the SAPI 3 connection isnt already established or initiated, then no SAPI 3 messages are
forwarded to the mobile during dequeuing..
ASSIGNMENT REQUEST, HANDOVER COMMAND & CIPHER MODE COMMAND

messages 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 the
MSC 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. This
will depend on the reason in the handover alarm - see Refs [8].
OIE RESPONSE
REQUEST
The response request information element will be included only

when the parameter RESP REQ is set to TRUE.
The RESP REQ is an O&M modifiable operator parameter.
MIE CELL
IDENTIFIER LIST
(Preferred)
The cell list when built will contain no more cells than indicated by
the N PREF CELL parameter.
When the O&M flag CGI REQD is set to TRUE, then the OIE CELL
IDENTIFIER LIST PREFERRED will contain cells identified by use
of the whole Cell Global Identification (CGI) coding.
Otherwise the cells will be identified by use of the Cell Identification
Discriminator 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 only
included if O&M flag EN_SEND_OLD_CHAN_MODE is set to
TRUE.
OIE Speech Version

(used)
Always included if channel mode is "speech" AND if flag

EN_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]
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
50/108

3.2.3. - MSC Handover Protocol

The ALCATEL BSS has to interface to many MSCs. This section gives the reader an insight into the
MSC behaviour so as to grasp a better knowledge of the protocol whilst testing, only the inter-MSC
protocol is described.
The MSC when it receives a HANDOVER REQUIRED from a BSS initiates an external handover
protocol.
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 a

cell which is not heavily loaded.
A cell is selected and the target BSS is sent a HANDOVER REQUEST message - see ref [14] for
the MSCs requirement for the setting of the PERMITTED ALGORITHM setting. The timer Trr2 is
started to supervise the activation of the channel for the handover.
If the OIE RESPONSE REQUEST is present in the HANDOVER REQUIRED message and Trr2
expires the MSC may send a HANDOVER REQUIRED REJECT to the serving BSC. When this
occurs 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 a
HANDOVER COMMAND to the serving BSS and starts the timer T3103 to supervise the
handover with the MS.
At this point in time the MSC should disable the DTAP transparent message passing function and
prevent 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 HANDOVER
COMPLETE from the target BSS. In this case the MSC, stops the timer T3103, performs the
switch 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 in
time 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, perform
the 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 to
have finished.
The MSC can only wait for the next HANDOVER REQUIRED message for a new handover
procedure to occur.
If T3103 expires the MSC may decide to clear the call or let the connection continue until a failure
is 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 protocol
either when it receives the HANDOVER DETECT message or the HANDOVER COMPLETE is
received from the target BSS. In fact some MSCs may perform the switch through before the
reception 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 external
handover protocol.
For more detail on the processing of the HANDOVER REQUEST message and the SCCP connection
establishment 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 TCH
transactions depending on, the MSC queuing requirements, and the internal BSC queue status,
before the state tables are entered.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
51/108

MSC
Queuing
requested
Queuing
Requested
Internal BSC
queue status
Queuing
Requested
Can not
queue
Queuing is
Not
Requested
Can queue
Queuing is
Not
Requested
Can not
queue
Can queue
Actions
Start T_qho
Send QUEUING INDIC
next state (AWAIT TCH RESOURCE- QUEUING)
ref [6] EHT0800
start T9110
next state (AWAIT MSC RESPONSE)
Send HANDOVER FAILURE (cause "No radio
resource available")
start T9110
start T9110
Table 3./7 TCH Transactions and Queuing During Congestion

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

status
No SDCCH Congestion
SDCCH Congested
Actions
Start T9103
Send CHANNEL ACTIVATION
next state (AWAIT CHAN ACT ACK)
start T9110
Table 3./8 SDCCH Transactions During Congestion
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
52/108

STATE DESCRIPTION
ABBREVIATION
There is a congestion situation and the request is queued

(TCH calls only)
AWAIT TCH
RESOURCE (QUEUING)
The Target BSC has allocated and is attempting to

activate 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 the
procedure
AWAIT HO DETECTION
The target BSC has received the HANDOVER

DETECTION from the target BTS. It has made the switch
path (TCH only) and is awaiting the ESTABLISH
INDICATION message
AWAIT ESTAB IND
The target BSC has received the ESTABLISH

INDICATION and is now awaiting the HANDOVER
COMPLETE message from the MS
AWAIT HO CMPLT
The target BSC has detected a failure in either the

HANDOVER REQUEST or the activation of the target
BTS channel and has sent a HANDOVER FAILURE to
the MSC. The target BSC is awaiting either another
HANDOVER REQUEST or a CLEAR COMMAND. Timer
T9110 is running to supervise the MSC response.
AWAIT MSC RESP
This state represents the entry and exit state of the

external handover protocol.
NULL
Table 3./9 Target BSC Logical States
STATE
EVENT
TCH available
T_qho expiry
Pre-emption by
another request
(Handover or
Assignment)
AWAIT TCH RESOURCE (QUEUING)

Stop T_qho
Start T9103
Send CHAN ACT to target BTS
next state (AWAIT CHN ACT ACK)
Send HANDOVER FAILURE ref [6] EHT0800
start T9110
Next state (AWAIT MSC RESP)
Stop T_qho
Send HANDOVER FAILURE ref [6] EHT0800
Start T9110
Next state (AWAIT MSC RESP)
Table 3./10 State Table for Expected Events (During Queuing - TCH Only)
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
53/108

STATE
EVENT
CHANNEL
ACTIVATION
ACKNOWLEDGE
CHN ACT NACK
(Request transcoding
rate unavailable)
CHN ACT NACK

(Encryption algorithm
not implemented)
CHN ACT NACK (All
other causes)
T9103 EXPIRY
AWAIT CHN ACT ACK

stop T9103
send HO REQ ACK
start T9113
next state(AWAIT HO DETECTION)
stop T9103
send HO FAILURE
for "data" connection, use ref [6] EHT0101
for "speech" connection, use ref [6] EHT0106
start T9110
next state(AWAIT MSC RESP)
stop T9103
Send HO FAILURE ref [6] EHT0102
start T9110
next state (AWAIT MSC RESP)
stop T9103
send HO FAILURE
ref [6] EHT0103
start T9110
send HO FAILURE
ref [6] EHT0200
start T9110
Table 3./11 State Table for Expected Events During Channel Activation
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
54/108

STATE
EVENT
HANDOVER
DETECTION
ESTABLISH
INDICATION
SAPI 0
HANDOVER
COMPLETE
AWAIT HO DETECTION
Switch through connection
path on a per call basis
depending on the full
rate/half rate requirements
of the connection. (TCH
only)
send HO DETECT
next state(AWAIT ESTAB
IND)
Note 2;
of the connection (TCH
only)
Note 8
BSC starts MS & BS Pwr
Ctrl as required;
next state(AWAIT HO
CMPLT)
Note 3;
stop T9113
of the connection(TCH
only)
send HO CMPLT
: BSC starts MS & BS Pwr
Ctrl as required;
if this is a directed retry to
full rate speech version 1
TCH with a phase 1 MS
send CHANNEL MODE
MODIFY. see note 26
Enable DTAP
note 25
next state(NULL)
AWAIT ESTAB IND
AWAIT HO CMPLT
Dont care
Dont care
Dont care
Ctrl as required;
next state(AWAIT HO
CMPLT)
Note 4;
stop T9113
send HO CMPLT
Ctrl as required;
if this is a directed retry to
full rate speech version 1
TCH with a phase 1 MS
send CHANNEL MODE
MODIFY. see note 26
Enable DTAP
note 25
next state(NULL)
stop T9113
send HO CMPLT
if this is a directed
retry to full rate
speech version 1
TCH with a phase 1
MS, send CHANNEL
MODE MODIFY.
see note 26
Enable DTAP
note 25
next state(NULL)
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 MSC
RESP) are either not applicable or ignored. There is only one exception to this which is the reception
of the HANDOVER REQUEST message during the WAIT MSC RESP state.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
55/108

STATE
EVENT
T9113 EXPIRY
AWAIT HO
DETECTION
ref [6] EHT0300
CONN FAIL IND

(Handover access
failure)
CLEAR COMMAND
Note 17
HANDOVER
REQUEST
T9110 expiry
AWAIT ESTAB IND

ref [6] EHT0300
AWAIT HO
CMPLT
ref [6] EHT0300
Note 2;
ref [6] EHT0400
ref [6] EHT0400
Not Applicable
Stop T9113
ref [6] EHT1100
Stop T9113
ref [6] EHT1100
Stop T9113
ref [6] EHT1100
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
Not Applicable
WAIT MSC
RESP
Not
Applicable
Not
Applicable
Stop T9113
ref [6]
EHT1100
Note 5
stop T9110
ref [6]
EHT0500
Table 3./13 State Table for Expected Events During Channel Change
STATE
AWAIT TCH
RESOURC
E
AWAIT CHN
ACT ACK
CLEAR
COMMAND
Note 18
A Int Note 15
NC Note 13
SCCP-N-DISC
Note 20
AWAIT
ESTAB
IND
AWAIT
HO
CMPLT
WAIT
MSC
RESP
A Int Note 15
NC Note 19
AWAIT
HO
DETECT
ION
A Int & NC
Note 24
A Int & NC
Note 24
A Int & NC
Note 24
A Int Note 15
NC Note 13
A Int Note 15
NC Note 19
A Int & NC
Note 14
A Int & NC
Note 14
A Int & NC
Note 14
RESET
A Int Note 15
NC Note 13
A Int Note 15
NC Note 19
A Int & NC
Note 14
A Int & NC
Note 14
A Int & NC
Note 14
RESET
CIRCUIT
A Int Note 15
NC Note 13
A Int Note 15
NC Note 19
A Int & NC
Note 14
A Int & NC
Note 14
A Int & NC
Note 14
DTAP
message
Discard or
reject
message
Note 23
Discard
message
Note 12
Discard
message
Note 12
Discard or
reject
message
Note 23
Discard
message
Note 12
Discard
message
Note 12
Queue
message
Note 12
Queue
message
Note 12
Queue
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Stop
T9110
ref [6]
EHT09
00
Stop
T9110
ref [6]
EHT1000
Stop
T9110
A Int is
released
locally
Stop
T9110
A Int is
released
locally
Discard
or reject
message
Note 23
Discard
message
EVENT
CIPHER
MODE
COMMAND
ASSIGNMENT
REQUEST
Discard
message
Table 3./14 Unexpected Event Handling - A Interface & DTAP
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
56/108
STATE
EVENT
AWAIT CHN
ACT ACK
AWAIT HO
DETECTION
AWAIT ESTAB
IND
AWAIT HO
CMPLT
CONN FAIL
IND Note 9
Not Applicable
Dont care
Dont care
Dont care
CONN FAIL
IND (Radio-link
fail)
Not Applicable
Dont care
Dont care
Dont care
ERR REP
(O&M
intervention)
ref [6] EHT

1200
ref [6] N0400
ref [6] N0400
ref [6] N0400
ERR REP
SAPI 0 (Msg
seq err)
Dont care
Dont care
Dont care
Dont care
ERR IND SAPI

0 (Note 6)
Not Applicable
Dont care
Dont care
Dont care
ERR IND SAPI

0 (Note 7)
Not Applicable
Dont care
Dont care
Dont care
REL IND SAPI

0
Not Applicable
Dont care
Dont care
Dont care
MEASURE
RESULT
Not Applicable
Note 21
Note 21
Note 22
AWAIT
MSC
RESP
Not
Applicabl
e
Note 11
Not
Applicabl
e
Note 11
Not
Applicabl
e
Note 11
Not
Applicabl
e
Note 11
Not
Applicable
Note 11
Not
Applicable
Note 11
Not
Applicable
Note 11
Not
Applicable
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 A
interface as for example the HANDOVER DETECTION is lost then no HANDOVER DETECT
will be sent to the MSC.
9:
CONNECTION FAILURE INDICATION (cause "Transcoder failure") is valid for TCH

connections only.
11:
In this state there should be no resources allocated in the BTS, therefore there should be
none of these events coming from the BTS.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
57/108

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 either
T9113 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 old
channel".
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 the
appropriate Resource release scenario.
20:
If the cause is "SCCP inactivity timer expiry" then a Reset circuit procedure will be initiated
for TCH connections so as to Clear the connection.
In the case where it is the reception of SCCP RELEASED any A interface channel associated
to the connection is released.
21:
The Power control and handover algorithms are started when the MS is connected after the
reception 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 = "Protocol
Error between BSC and MSC".
24
The release of the A interface is initiated immediately and the release of the Abis and Air
interfaces 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 CHANNEL
MODE MODIFY ACK or CHANNEL MODE MODIFY NACK is received, it is discarded. see
ref [18].
3.2.4.1. - SCCP Connection Establishment

The SCCP connection may be established in the following ways as shown in the message sequence
charts below.
The first shows the establishment of the SCCP connection without any exchange of Layer 3
messages. The HANDOVER REQUEST is sent after the SCCP connection has been established. The
second shows the establishment of the SCCP connection where the initial SCCP CONN REQ has
within it a HANDOVER REQUEST message.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
58/108

Fig 3./14 HO Request after SCCP Establishment

1
The MSC sends an SCCP CONN REQUEST to the target BSC without any message
contained.
The target BSC: returns the SCCP CONN CONFIRMATION to the MSC.
Once the SCCP connection is established the MSC now sends the HANDOVER REQUEST
message.
Fig 3./15 HO Request during SCCP Establishment

1
The MSC sends an SCCP CONN REQUEST to the target BSC with a HANDOVER
REQUEST message contained within it.
2
The target BSC: returns the SCCP CONN CONFIRMATION to the MSC.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
59/108

The third shows an SCCP CON REQ where the message contained is unknown. In this case the
SCCP connection is confirmed and the timer T9110 runs to supervise the reception of the
HANDOVER REQUEST message.
It must be noted that the SCCP connection is always confirmed before either, the HANDOVER
REQUEST 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 is
confirmed.
The timer T9110 is started to supervise the reception of the HANDOVER REQUEST.
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 some
format 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
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 expiry
of T9110. In this case an SCCP RELEASED is sent to the MSC.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
60/108

Fig 3./18 SCCP Establishment with T9110 Expiry

1
The SCCP connection is established but no HANDOVER REQUEST is received or an

unknown message or incorrect message is received.
The timer T9110 is started so as to ensure that the SCCP connection is not left hanging
without a transaction associated with it.
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 the
target BSS when it has detected that there is a problem with the received HANDOVER REQUEST
message.
This section shows the general behaviour of the target BSS when these errors are detected, with the
exception of the unknown A interface circuit or Blocked circuit cases which are shown in the following
sections.
When an error is detected the target BSS immediately fails the external handover attempt by sending
a 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 are
error in the A Interface circuit selected) to try another external handover attempt for the same MS
connection - see following sections.
The message sequence diagram below shows the Target BSS behaviour.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
61/108

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.
The HANDOVER REQUEST is sent by the MSC.

The target BSS detects an error in the Request and refuses the external handover by sending
a HANDOVER FAILURE message - for cases and error causes see section in this document
"HANDOVER REQUEST message checking".
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 is
unable to be used by the target BSS the target BSS refuses the Request, by sending a HANDOVER
FAILURE (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 in
connectionless 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 A
interface 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 trigger
Unblocking procedure so that the A Interface circuit is once more available for traffic in the MSC - see
ref [11].
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
62/108

Fig 3./20 HO Request on Unavailable Circuit

1

The target BSS detects that the A interface circuit is not usable in the target BSS, so an
HANDOVER FAILURE message is sent (for cause values see section "HANDOVER
REQUEST message checking").
The target BSS starts the timer T9110 in this case the target BSS is awaiting the MSC to
possibly reselect the A Interface circuit and initiate another external handover procedure.
The target BSS also sends a BLOCK message in connectionless mode for the A interface
circuit contained in the original HANDOVER REQUEST.
One BLOCK message is sent by the target BSS in this case, there is no timer started by the
target 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 2
mode (ie GSM PHASE == PHASE 2). In addition the message may be disabled from being sent by
use of the O&M Parameter (UNEQUIP_CIR_EN).
If in the HANDOVER REQUEST message the MSC has selected an A interface Circuit which is
either: Unknown; Known but not equipped or configured (this does not include X25 or SPL circuits); or
in use for CCITT No 7; by the target BSS the target BSS refuses the Request, by sending a
HANDOVER FAILURE (for causes see section "HANDOVER REQUEST message checking").
In addition the target BSS sends a single UNEQUIPPED CIRCUIT message to the MSC. This
message is sent in Connectionless mode.
On reception of the UNEQUIPPED CIRCUIT message the MSC should remove the indicated circuit
from the free A interface circuit list maintained by the MSC. It is up to O&M procedures in the MSC to
trigger Maintenance or Configuration actions to align MSC & BSS A interface circuit configurations
and states.
The following message sequence chart shows the procedure when the target BSS is operating in
GSM Phase 2 mode on A interface and the UNEQUIPPED CIRCUIT is allowed to be sent by the
target BSS.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
63/108

Fig 3./21 HO Request on Unequipped Circuit

1

The target BSS detects that the A interface circuit is either: not known; known but not
equipped or configured (this does not include X25 or SPL circuits); or in use for CCITT No 7
signalling; in the target BSS, so an HANDOVER FAILURE message is sent (for cause values
see section "HANDOVER REQUEST message checking").
The target BSS starts the timer T9110 in this case the target BSS is awaiting the MSC to
possibly reselect the A Interface circuit and initiate another external handover procedure.
The target BSS also sends an UNEQUIPPED CIRCUIT message in connectionless mode for
the A interface circuit contained in the original HANDOVER REQUEST - see ref [11] for more
detail.
3.2.4.6. - HANDOVER REQUEST message processing

Before the target BSC enters the handover protocol the following checks and actions are taken on the
HANDOVER REQUEST message before proceeding with the handover.
For processing of classmark IEs, see ref [16]
Event
Optional information
element CIC is present
Actions
Send HANDOVER FAILURE (cause "Protocol error between
MSC and BSC") - ref [6] EHT0600
Start T9110
next state (WAIT MSC RESP).
Table 3./16 Specific checking for EHO towards SDCCH
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
64/108

OIE CIC is not present
OIE CIC is present but

indicates timeslot 0
is unavailable due to
O&M intervention

is unavailable due to
its use in another
connection
OIE CIC is unknown or
is known but not
equipped or configured
(this does not include
X25 or SPL circuits) or
is in use for CCITT No
7
MIE Channel Type
octet 3 indicates data
& octet 4 indicates half
rate or a non
supported data rate
The BSC recognises
no code point for a
codec, amongst all
proposed in MIE
Channel Type octet 5.
Requested codecs in
MIE Channel Type
octet 5 do not match
any codec allowed in
the cell

Start T9110
Send HANDOVER FAILURE (cause Requested terrestrial
resource unavailable) -ref[6] EHT0705
Send HANDOVER FAILURE (cause "Requested terrestrial
resource unavailable") - ref [6] EHT0603
Send a single BLOCK message ref[11]
Start T9110
next state (WAIT MSC RESP)
Send HANDOVER FAILURE (cause "Terrestrial resource
already allocated") - ref [6] EHT0604
Start T9110
Send HANDOVER FAILURE (cause "BSS not equipped") - ref
[6] EHT0605
send UNEQUIPPED CIRCUIT message - See Note 1
Start T9110
Send HANDOVER FAILURE (cause "Requested transcoding/

rate adaption unavailable") - ref [6] EHT0602
Start T9110
Send HANDOVER FAILURE (cause "Requested speech
version unavailable") - ref [6] EHT0620
Start T9110
Send HANDOVER FAILURE (cause "Requested speech
version unavailable") - ref [6] EHT0620
Start T9110
Table 3./17 Specific checking for EHO towards TCH
Note 1: The UNEQUIPPED CIRCUIT message is sent only if the GSM_PHASE == PHASE 2 and
enabled by O&M parameter (EN_UNEQUIPPED_CIRCUIT) - see ref [11] for more detail.
OIE Cell Identifier

(Target) is present and
does not match to the
one held in the BSS See Note 1
Send HANDOVER FAILURE (cause "Invalid cell") - ref [6]

EHT0601
Start T9110
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 independent
of the GSM PHASE flag.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
65/108

OIE Cell Identifier

(Target) is not present
OIE Cell Identifier

(Target) is present but
does not match one
known to the BSS

Start T9110
Send HANDOVER FAILURE (cause "Invalid cell") - ref [6]
EHT0601
Start T9110
Table 3./19 Specific checking for Multi-Cell BSS
MIE Channel Type

combination not
supported - See Note
2
MIEs Encryption Info
or Classmark Info or
Cell Identifier (serving)
is missing
OIE Radio Channel
Identity is present
OIE Interference Band
is present
MIE Encryption
Information field
Permitted algorithms
is coded "00000000" see Note 1
MIE Encryption
Information Length
field value is more
than 9 (key length is
more than 8 octets)

MSC and BSC") - ref [6] EHT0600;
start T9110
Send HANDOVER FAILURE(cause "Protocol error between
Start T9110
Ignore IE
If at least one
encryption algorithm is
allowed and cipher key
is not present (MIE
ENCRYPTION
INFORMATION has a
length of 1)
Send HANDOVER FAILURE (cause "IE or field missing")

ref[1] EHT0608
Start T9110
Ignore IE
Start T9110
Send HANDOVER FAILURE (cause "Incorrect value") ref[6]
EHT0607
Start T9110
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 GSM
PHASE mode.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
66/108

If the MIE Encryption

Information field
Permitted algorithm
has more than one bit
set

Start T9110
(The BSC does not allow this handover to occur as it
does not know what Ciphering algorithm is in use on
the old channel)
Table 3./21 Ciphering Checks - GSM Phase 1 MSs
If the MS Ciphering
capabilities do not
match with the BTS
ciphering capabilities
or the allowed MSC
ciphering requirements
(as specified in the
MIE Encryption Info
field Permitted
algorithms - see ref
[14])
Send HANDOVER FAILURE (cause "Ciphering algorithm not

supported") - ref [6] EHT0606
Start T9110
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 case
of an abnormal SCCP release where upon a Reset circuit procedure would have to be carried out;
if it was an
unsuccessful CIC
allocation
Send HANDOVER FAILURE (cause "Requested terrestrial

resource unavailable") - ref [6] EHT0701
Start T9110
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].
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
67/108

if it was a successful
resource allocation
if the queue is full
if the timer T_qho

expired in the queuing
algorithm. ie the
request was in the
queue too long
if the queuing request
was pre-empted by a
higher priority request
if there is an internal
BSC problem
allocating the RF
channel
If the cell is
unavailable due to
O&M
if incoming handover
is inhibited in the cell
(EN_IC_HO is set to
FALSE
Send a CHANNEL ACTIVATION message to the BTS - see

section on CHANNEL ACTIVATION message building
Start T9103
next state is AWAIT CHN ACT ACK.
If a CIC is allocated then CIC state is made FREE
send HANDOVER FAILURE (cause "No radio resource
available")
start T9110
If CIC is allocated then CIC state is made FREE
available") - ref [6] EHT0800
start T9110
If a CIC is allocated then CIC state is made FREE send HANDOVER FAILURE (cause "No radio resource
start T9110
start T9110
next state(WAIT MSC RESP)
send HANDOVER FAILURE (cause "O&M intervention") ref [6] EHT0704
start T9110
send HANDOVER FAILURE (cause "O&M intervention") ref [6] EHT0704
start T9110
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 be
performed in this case, the target BSC should recognise that the HANDOVER REQUEST message
concerns 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 REQUEST
message.
If one of the following condition is fulfilled, then the incoming request is assumed to be an incoming
external 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" AND
Channel 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 :
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
68/108

Channel Type is "full rate speech version 1" (*) AND MS revision level is "Phase 1. The cause is
not checked.
(*) : this means : speech/data indicator field is "speech" AND channel rate and type field is "full rate
TCH 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 a
CHANNEL MODE MODIFY message, without starting any timer. When CHANNEL MODE MODIFY
ACK 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 and
parameters 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
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
69/108

Information
element
Info field
MIE Channel
number
Indicates the RF Channel allocated by the Dedicated radio resource

manager - see ref [9]
MIE Activation
type
If serving cell is not controlled or unknown by the target BSC then

asynchronous handover is indicated
If the serving cell & target cell are synchronised the synchronous
handover is indicated, else asynchronous handover is indicated.
MIE Channel
mode
DTXd
DTXu
see reference [20]

see reference [20]
Speech or
Data Ind
(octet 4)
Set equal to octet 3 of the MIE Channel Type in the HANDOVER

REQUEST message.
Chan rate
and 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].
Speech
encoding
algorithm
(octet 6)
If Speech or Data Ind indicates "Signalling" - set to "no resource

required"
If Speech or Data Ind indicates "Speech" - set to "GSM speech coding
algorithm 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 HANDOVER
REQUEST message indicates "Transparent Service" - set equal to
octet 5 of the MIE Channel Type in the HANDOVER REQUEST
message.
if T/NT of octet 5 of the MIE Channel Type in the HANDOVER
REQUEST message indicates "Non Transparent Service" - and Rate
of octet 5 indicates 6Kbit/s or 12Kbit/s - set equal to "12 Kbit/s", see
Note 1.
OIE Channel
Ident
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 the
building of the HANDOVER COMMAND message
OIE Encryption
Info element
This IE is always sent.
CIE Handover
reference
This IE is included for this procedure

It is calculated by the target BSC and should be randomly generated.
The setting is as specified in ref [3 & 9]
The BTS uses this value to compare with the value in the HANDOVER
ACCESS when the MS performs the handover access procedure.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
70/108

OIE BS Power
set to BS_TXPWR_MAX - the maximum allowed power is used at the

start 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 in
the HANDOVER REQUEST.
The MS should start transmitting at the maximum allowed power in the
cell or at the maximum that it can transmit, this will ensure a high
success rate of handover.
CIE Timing
advance
Not used
OIE BS Power
parameters
Not used
OIE MS Power
parameters
Not used
OIE Physical
context
Not used
OIE SACCH
Information
This element contains the setting of system information filling on SACCH

for THIS channel. It is included only if there are additional or modified
system information messages to be transmitted.
This is never used in an asynchronous handover as the timing advance

is calculated when the MS performs the handover access procedure.
In synchronous handover the timing advance can not be included as the
information is not held in any of the messages sent in the external
handover protocol. The timing advance is calculated when the MS sends
the HANDOVER ACCESS message.
If present, it updates the system information previously intended to be

transmitted. 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/s
rate adaption
3.2.4.8. - HANDOVER REQUEST ACK message construction

Once the channel has been successfully activated (ie reception of CHANNEL ACTIVATION ACK) the
HANDOVER REQUEST ACK message is built and sent back to the MSC.
Information element
MIE Message type
Set to HANDOVER REQUEST ACK
MIE Layer 3 Information
See the next section on HANDOVER COMMAND message

construction for the building of this IE.
OIE Chosen channel
This IE is sent only when the BSS was given a choice by the
MSC.
OIE Chosen Encryption

algorithm
This IE is sent when the MSC allows the BSC to choose from
more than one ciphering algorithm.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
71/108

OIE Speech Version (chosen)
This IE is included when the target BSS made the choice of the
codec 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 HANDOVER
COMMAND message which is to be passed to the MS. The following table shows the construction of
the HANDOVER COMMAND message towards a channel which is fully supported by the E-GSM
band (G1 range and/or P-GSM range).
Information element
MIE Cell description
For P-GSM, set NCC, BCC & BCCH ARFCN (High & Low
part <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 Description

field, in the Channel Identification MIE of the CHANNEL
ACTIVATION message.
MIE Handover reference
Set as sent to the BTS in the CHANNEL ACTIVATION

message.
MIE Power command and

Access type
Set to MIN(P, MS_TXPWR_MAX target cell)

Field Access type is set to "sending of HANDOVER
ACCESS is mandatory"
OIE Synch info
Phase 1 MS : This IE is always included as required in GSM

ETR 09.94 (see reference [18]).
Phase 2 MS : This IE is only included for synchronous
Handover.
ROT bit is settable depending on customer request
NCI bit is settable depending on customer request
CIE Frequency short list, after

time
This IE is used when a G1 band TCH is allocated by the

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

dedicated radio resource entity and frequency hopping is to
be applied on the TCH. For the format to use, see ref [21].
This IE is sent only if "CIE Frequency short list, after time" is
not sent. See note 1.
CIE Cell chan description
This IE is used when a P-GSM band TCH or SDCCH is

allocated by the dedicated radio resource entity and
frequency hopping with more than one frequency is to be
applied on the channel and when CIE Frequency Channel
Sequence, after time cannot code all the frequencies used.
Bitmap 0 format is used.
Used together with CIE Mobile Allocation, after time to
describe frequency hopping sequence
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
72/108

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

second channel
Not used - relevant to Lm + Lm.
OIE Mode of the second

channel
Not used - relevant to Lm + Lm.
CIE Frequency channel

sequence, after time
This IE is used when a P-GSM band TCH or SDCCH is

allocated by the dedicated radio resource entity and
frequency hopping with more than one frequency is to be
applied on the channel, and if this IE can code all
frequencies.
In the non hopping case the MS receiving this message with

this information element included should be aware that the
channel is non hopping from the CHANNEL DESCRIPTION
MIE 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, before

time
Not used (used during Frequency redefinition and only sent

to Phase 2 MSs).
CIE Frequency list, before time

to Phase 2 MSs).

first channel, before time

to Phase 2 MSs).

second channel, before time
Not used (used during Frequency redefinition, for Lm + Lm,

and only sent to Phase 2 MSs).

sequence, before time

to Phase 2 MSs).
CIE Mobile allocation, before

time

to Phase 2 MSs).
OIE Cipher mode setting
Never sent to Phase 1 MSs.

GSM Phase 2 MSs - Always sent indicating the Ciphering
algorithm 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" is
dependant on the range of the frequencies. See ref [21]
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
73/108

HANDOVER COMMAND (Inter-cell Synchronous & Asynchronous) for Phase 1 or 2 MSs towards a
DCS channel.
Information element
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 Description

field, in the Channel Identification MIE of the CHANNEL
ACTIVATION message.
MIE Handover reference
Set as sent to the BTS in the CHANNEL ACTIVATION

message.
MIE Power command and

Access type
Set to MIN(P, MS_TXPWR_MAX target cell)

Field Access type is set to "sending of HANDOVER
ACCESS is mandatory"
OIE Synch info
Phase 1 MS : This IE is always included as required in GSM

ETR 09.94 (see reference [18]).
Phase 2 MS : This IE is only included for synchronous
Handover.
ROT bit is settable depending on customer request
NCI bit is settable depending on customer request
CIE Frequency short list, after

time
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 "Frequency

short 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.

second channel
Not used - relevant to Lm + Lm
OIE Mode of the second

channel
Not used.- relevant to Lm + Lm

sequence, after time
Not used..
CIE Mobile allocation of the

second 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, before

time

to Phase 2 MSs).
CIE Frequency list, before time

to Phase 2 MSs).

first channel, before time

to Phase 2 MSs).
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
74/108


second channel, before time

to Phase 2 MSs).

sequence, before time

to Phase 2 MSs).
CIE Mobile allocation, before

time

to Phase 2 MSs).
OIE Cipher mode setting
Never sent to Phase 1 MSs.

GSM Phase 2 MSs - Always sent indicating the Ciphering
algorithm 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" is
dependant 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 be
included 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 the
same 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 the
mobile which type of protocol is to be performed on the Air interface. In the case where the
Synchronisation indicates synchronous, the MS knows that the timing advance that it is presently
using will be used in the target cell, this matches the setting given in the CHANNEL ACTIVATION
message 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 the
new channel, this ensures a high probability of success. The reason for not using the MS power
obtained from the PHYSICAL CONTEXT CNF message, is due to the fact that there is no relationship
between 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 the

message is only sent in this context.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
75/108
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 HANDOVER
COMPLETE message; or the expiry of T9113 (ie during the AWAIT HO DETECT, AWAIT ESTAB
IND & 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 is
released (this also includes the case of a DTAP message received from the MSC in a SCCP
RELEASED 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 already
established or the establishment of a SAPI 3 connection has been initiated (in which case, the first
SAPI 3 message is forwarded to the MS as soon as the connection is established), subsequent SAPI
3 messages in the queue are discarded.
All connection oriented messages received before the sending of the HANDOVER REQUEST ACK
will 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 any
frames sent to the air interface.
The target BTS can only decode access bursts coming in from the air interface whilst it is awaiting the
HANDOVER 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.
STATE DESCRIPTION
ABBREVIATION
The BTS is awaiting the HANDOVER ACCESS message

from the MS and Enciphering is applied
AWAIT HO ACC
The BTS is awaiting the SABM from the MS, the PHYSICAL
INFO message is being sent and the timer T3105 is running
AWAIT SABM or AWAIT

ANY CORRECT FRAME
The LAPDm is established and the timer T_CFI_Tr is

running. 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
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
76/108
STATE
AWAIT HO ACC

EVENT
HANDOVER
ACCESS
Note 4
Decipher (if applied)
AWAIT
SABM or ANY
CORRECT
FRAME
T_CFI_Tr
RUNNIN
G
ACTIVE
Dont care
N/A
N/A
Set connection with TR (TCH) Note 2

Send HANDOVER DETECTION
Decode normal bursts
Calculate TA
Set TA in L1 header of SACCH msgs and TA
algorithm
Send PHYS INFO with TA in unack mode
X=0
Start T3105
next state(AWAIT SABM or ANY CORRECT
FRAME
Table 3./30 Target BTS State Table - Asynch HO
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
77/108
STATE
AWAIT
HO ACC
AWAIT SABM or ANY

CORRECT FRAME
T_CFI_Tr
RUNNING
ACTIVE
EVENT
DL ESTAB IND
N/A
Stop T3105
Stop T_CFI_Tr
Start T_CFI_Tr
Start Radio-link fail

alg
Start T_CFI_Tr
next state
(T_CFI_Tr
RUNNING)
BTS Layer 2 ->

BTS Layer 3 or
any correct
frame
Note 1
Send EST INDIC
Note 1
Start T_CFI_Tr
Note 5
next state(T_CFI_Tr
RUNNING)
T3105 EXPIRY
N/A
X == NY1
N/A
N/A
next state
(ACTIVE)
Not Applicable
Send CONN FAIL IND

(cause "HO acc fail")
Send DL REFUSE
REQ Note 6
next state (ACTIVE)
X < NY1
X=X+1
Send PHYS INFO in
unack mode
Start T3105
T_CFI_Tr
EXPIRY
N/A
N/A
Note 1
Note 1
Remote
transcoder
alarm
N/A
Send CONN FAIL IND

(Remote transcoder
failure)
Discard
Note 1
Send CONN FAIL

IND (Remote
transcoder 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 the
reception of TRAU frames from the BSC. It is at this point in the protocol that the detection of
Transcoder failure in the BTS starts. When the BSC receives the HANDOVER DETECT
message it is meant to perform the switch through in which case the BTS will start to receive
these 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 carrying
the BCCH frequency see ref [8] for BS Power control inhibition.
Note 4: Only a correct HANDOVER ACCESS will be accepted. Any incorrect HANDOVER ACCESS
will be discarded.
Note 5: The event which will be accepted at this point will depend of the T3105_D_STOP or
T3105_F_STOP parameter. If the parameter(s) is set to ONLY SABM, then only the
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
78/108

reception of an SABM for SAPI 0 will stop the timer. If the parameter(s) is set to ANY
FRAME, then any correctly received TCH or Layer 2 frame will cause T3105 to be stopped. In
both 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 BTS
feature 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 any
frames sent to the air interface. The dedicated SYSTEM INFORMATION messages are immediately
sent.
In the case of external synchronous handover the Layer 1 header will indicate that the Timing
advance information is invalid.
In the case of internal synchronous handover the Layer 1 header will indicate the timing advance
given in the CHANNEL ACTIVATION message. If the timing advance information is not present then
the 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 the
HANDOVER ACCESS message.
The target BTS should exhibit the following behaviour during a synchronous external or synchronous
internal handover procedure.
A list of logical BTS states are shown below.
STATE DESCRIPTION
The Channel is activated and the BTS is awaiting the
HANDOVER ACCESS from the MS
The BTS is awaiting for either the SABM SAPI 0 or any
correct frame from the MS. The timer T3106 is running.
The LAPDm is established and the timer T_CFI_Tr is
running. During this state all transcoder alarms are ignored.
This State is introduced as the exit state for the procedure,
after the end of a successful access by the MS
ABBREVIATION
INTRA AWAIT HO ACC
INTRA AWAIT SABM or
ANY CORRECT FRAME
T_CFI_Tr RUNNING
ACTIVE
Table 3./32 BTS States - Synch HO
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
79/108

STATE
INTRA AWAIT HO ACC
INTRA AWAIT
SABM or ANY
CORRECT
FRAME
T_CFI_Tr
RUNNING
ACTIVE
Start Deciphering (if applied)
N/A
N/A
N/A
Dont care
N/A
N/A
EVENT
HANDOVER
ACCESS
Send HANDOVER
DETECTION
Sets the Transcoder (TCH
only) Note 1
Calculate TA
Set TA in Layer 1 header &
TA Algorithm
Start T3106
next state (INTRA AWAIT
SABM or ANY CORRECT
FRAME)
INCORRECT
HANDOVER
ACCESS
Dont care
DL ESTAB IND
BTS Layer 2 ->
BTS Layer 3 or any
correct frame - see
Note 2
Dont care
Stop T3106
Send ESTABLISH
INDICATION
Start Radio link
failure algorithm
Stop
T_CFI_Tr
Start
T_CFI_Tr
Start
T_CFI_Tr
next state
(T_CFI_Tr
RUNNING)
Start T_CFI_Tr
next state
(T_CFI_Tr
RUNNING)
T3106 EXPIRY
N/A
Send DL-REFUSEREQ
N/A
N/A
next state
(ACTIVE)
N/A
Dont care
Send
CONN
FAIL IND
(Remote
transcoder
alarm)
Send CONN FAIL

IND (HO acc fail)
next state(ACTIVE)
T_CFI_Tr EXPIRY
N/A
Remote transcoder
alarm(TCH only)
N/A
N/A
Send CONN FAIL
IND (Remote
transcoder alarm)
Table 3./33 Target BTS State Table - Synch HO

EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
80/108

Note 1: When the transcoder is set (TCH only). The target BTS expects to receive the TRAU frames
from the Transcoder. It is at this point that the target BTS will start to detect transcoder failure
as the BSC has not yet made the switch path. When the BSC receives the HANDOVER
DETECTION message it is meant to perform the switch through in which case the BTS will
start to receive these TRAU frames. In the event that the HANDOVER DETECTION
message is lost (on Abis) the BSC will make the switch through either on the reception of the
ESTABLISH INDICATION SAPI 0 or upon the HANDOVER COMPLETE (in the case where
the 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 or
T3106_F_STOP parameter. If the parameter(s) is set to ONLY SABM, then only the
reception of an SABM for SAPI 0 will stop the timer. If the parameter(s) is set to ANY
FRAME, then any correctly received TCH or Layer 2 frame will cause T3106 to be stopped. In
both 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 to
make 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 the
MEASUREMENT 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 in
the 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 IE
matches with the coding in the PLMN PERMITTED IE transmitted to the MS in the SYSTEM
INFORMATION 6. This rule allows the MS to provide measurements for neighbour cells of different
PLMN and therefore makes a handover between two PLMNs is possible. However GSM does not
allow inter PLMN handovers.
Obviously an internal handover can never occur between two PLMNs, this would be performed using
an external handover, where the MSC would make the decision to handover to a different PLMN and
allow charging to be applied as appropriate.
Whilst performing these measurements the MS keeps information on the synchronisation and TDMA
timing of all the cells which it is measuring. These measurement are used to ensure quick
synchronisation with the target cell when required.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
81/108
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 to
allow 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 COMMAND
message. 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 other
messages coming from other sub-layers in the MS.
The releasing of LAPDm before the disconnection of the Physical layer may cause anomalies to
occur 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 the
synchronisation, 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 the
accessing of the FCCH and SCH.
The MS uses information gathered during the handover measurement procedures for use in the
handover procedure. The MS can only use this information if it can recognise the target cell in the
HANDOVER COMMAND with a Neighbour cell which it has previously measured. This information
should 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 handover
measurement procedures it (this is possible since the MS only keeps measurements on neighbour
cells for a certain length of time):
1
tunes to the BCCH frequency and detects the burst on the FCCH channel this is used to
provided the tuning to the carrier frequency.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
82/108

This process may take up to 460 ms to find the first FCCH burst and there after the time will depend
on the MSs phase lock loop performance.
2
and then accesses the bursts on the SCH channel which contain the SYNCHRONISATION
CHANNEL INFORMATION. This message contains the BSIC of the target cell and the current TDMA
frame number. If the BSIC found in these burst does not match to the BSIC passed in the
HANDOVER COMMAND message the MS will abort the handover and return to the old channel - see
re-attaching to the serving cell and old channel. The TDMA frame number in this message allows the
MS to synchronise itself to the TDMA frame.
The SCH burst is always placed after the FCCH burst thus allowing an easy access to the channel
during 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 previously
measured.
2
the TDMA frame number is set accordingly.
The MS, during the handover measurements, ensures that the TDMA frame numbers are also
synchronised.
When the MS has no information as to the synchronisation of the target cell, the procedure is likely to
be slow.
Once the MS has synchronised to the carrier and then to the TDMA frame it may proceed to attach to
the new channel
3.2.7.5. - Attaching To The New Channel

The attaching procedure for asynchronous handover to the new channel (indicated by the CHANNEL
DESCRIPTION IE in the HANDOVER COMMAND) consists of:
1
the sending (continuously) on the main DCCH, (or SACCH for phase 2 MSs) a HANDOVER
ACCESS 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 in
the HANDOVER COMMAND message
sent with the power specified in the POWER COMMAND IE sent in the HANDOVER
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 HANDOVER
REFERENCE IE in the HANDOVER COMMAND message.
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

EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
83/108

At this point the TSC sent to the MS in the CHANNEL DESCRIPTION IE in the HANDOVER
COMMAND 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 HANDOVER
COMPLETE message to the BSS.
Only when the HANDOVER COMPLETE is acknowledged at Layer 2 will the handover
procedure be deemed to have finished in the MS.
The attaching procedure for synchronous handover to the new channel (indicated by the CHANNEL
DESCRIPTION IE in the HANDOVER COMMAND) consists of:
1
the sending on the main DCCH, (or SACCH for phase 2 MSs) four consecutive HANDOVER
ACCESS 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 in
the HANDOVER COMMAND message;
it is sent with the power specified in the POWER COMMAND IE sent in the
HANDOVER 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 HANDOVER
REFERENCE 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 and
the MS attempts to establish a LAPDm connection by sending an SABM SAPI 0. At this point
the TSC sent to the MS in the CHANNEL DESCRIPTION IE in the HANDOVER COMMAND
message is used in the coding of the bursts.
When the MS receives the UA SAPI 0, the MS sends in acknowledge mode a HANDOVER
COMPLETE message to the BSS.
Only when the HANDOVER COMPLETE is acknowledged at Layer 2 will the handover
procedure be deemed to have finished in the MS.
In the successful case (after HANDOVER COMMAND is acknowledged) the MS does not
automatically establish signalling connections that were in existence on the old channel (for example
SAPI 3 SMS). This action needs to be commanded by upper layers in the MS. These layers would
have been informed of the handover taking place and are aware that the SAPIs which were in use
need 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 the
serving 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 and
Deciphering immediately;
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
84/108

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 automatically
all signalling connections which where in existence before the reception of the HANDOVER
COMMAND message. The state of the individual SAPIs upon the reception of the
HANDOVER 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 upper
layers may then use this signal to resend messages or (for SMS) to ask for re-establishment
of SAPI 3.
The object is to attempt to establish the connection as if nothing had happened. Obviously if there
was 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 finishes
before 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 Phase
2 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 an
internal handover has failed, the next cell in the list is external and there are queued BSSMAP or
DTAP 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 to
the MSC for the external handover are shown in the following table.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
85/108

Queued Message
Action
DTAP messages
Proceed DTAP messages as indicated in section

3.2.2.2.5 before BSSMAP messages handling
CIPHER MODE COMMAND
Proceed with ciphering
ASSIGNMENT REQUEST
Proceed with assignment
ASSIGNMENT REQUEST followed by

CIPHER MODE COMMAND
MSC should not send CIPHER MODE COMMAND

before the outcome of the assignment. Discard
CIPHER MODE COMMAND.
CIPHER MODE COMMAND followed by

ASSIGNMENT REQUEST
The MSC should await the outcome of the ciphering

procedure before proceeding with the assignment.
Process ASSIGNMENT REQUEST after CIPHER
MODE 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 the
BSC 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 HANDOVER
COMMAND is received from the MSC. The BSC will respond by sending a HANDOVER FAILURE
with the cause "reversion to old channel".
An external handover procedure may be triggered following the failure of an internal handover
procedure when one of the subsequent preferred cells in the preferred cell list of the internal
handover 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 external
for 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 all
the cells in the cell list CL are considered to be external irrespective of the actual status of the cell (ie
internal 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 of
T_HO_REQ_LOST.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
86/108

Fig 3./22 Interactions between Internal & External Handover - MSC sends HANDOVER REQUIRED
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 a
HANDOVER REQUIRED to the MSC with cell list CL1. The best cell is an external cell, all
others are internal. T7 and T_HO_REQ_LOST are started.
The MSC rejects the handover request. On reception of the HANDOVER REQUIRED
REJECT message the BSC stops T_HO_REQ_LOST and adds CLOLD to the
REJ_CELL_LIST.
A further handover alarm is received with all internal cells. After processing the cell
information the BSC sends a HANDOVER REQUIRED message to the MSC with cell list
CL2, T7 is restarted and T_HO_REQ_LOST started.
The MSC rejects this second cell list. On reception of the HANDOVER REQUIRED REJECT
message the BSC stops T_HO_REQ_LOST and adds the cells sent in the HANDOVER
REQUIRED message to the REJ_CELL_LIST. T7 is left running.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
87/108

A further handover alarm is received before T7 expires with the same cell information (ie all
internal cells). No handover is attempted as after processing, the cell list CL is not different
from that sent in the previous handover attempt.
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 external
handover 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 the
MSC does not send a HANDOVER REQUIRED REJECT message.
Fig 3./23 Interactions between Internal & External Handover - MSC does not send HANDOVER
REQUIRED REJECT
Note A Handover alarms serviced by external handover
Note B Non serviced handover alarms
Note C Handover alarms serviced by internal handover
Measurements from MS and BTS are relayed to the serving BSC.

The Serving BSC detects the need to perform an external handover and sends a
HANDOVER REQUIRED to the MSC with cell list CL1. The best cell is an external cell, all
others are internal. T7 and T_HO_REQ_LOST are started. The MSC does not reject the
handover request with a HANDOVER REQUIRED REJECT message. T7 and
T_HO_REQ_LOST are left running.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
88/108

A further handover alarm is received with all internal cells. After processing the cell
information the BSC sends a HANDOVER REQUIRED message to the MSC with cell list
CL2, T7 is restarted.
The MSC does not reject the handover request with a HANDOVER REQUIRED REJECT
message. T7 and T_HO_REQ_LOST are left running.
A further handover alarm is received before T7 expires with the same cell information (ie all
internal cells). No handover is attempted as after processing, the cell list CL is not different
from that sent in the previous handover attempt.
T7 expires, T_HO_REQ_LOST is still running.
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 now
attempts an internal handover since the best cell is internal and there are no external
handover 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 Ciphering
will be governed by the revision level of the MS (GSM Phase 1 or 2) and its Ciphering capabilities the
target cell Ciphering capabilities and the Permitted algorithms.
3.3.3.2.1. - Subsequent Internal handover after successful External Handover

for 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 handover
algorithm will only ever perform handovers to cells which can support the ciphering in use by the
Phase 1 MS.
3.3.3.2.2. - Subsequent Internal handover after successful External Handover

for 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 has
asked for A5/X when the MS does not support the ciphering algorithm the permitted algorithm
defaults to No encryption.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
89/108

Permitted Algorithm
Setting
No Encryption
A5/X, Y
Internal handover behaviour

Only non ciphered handovers will be performed
Only Ciphered handovers will be performed which match the set
of algorithms given by the MSC which match both MS Ciphering
capabilities and Cell capabilities.
Ciphered and Unciphered handovers will be performed.
Unciphered handovers will be performed to Cells which have no
support for the Algorithms indicated in the permitted algorithms or
the MS Ciphering capability.
Ciphered handovers will be performed which match the set of
algorithms given by the MSC which match both MS Ciphering
capabilities and Cell capabilities.
A5/X, Y & No
encryption
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 an
ASSIGNMENT REQUEST is received after the HANDOVER COMMAND has been received by the
BSC 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 even
before 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 control
algorithms as described in ref [8].
This section specifies the requirements of the BSC and BTS. It should be noted that BS Power
control 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 INDICATION
SAPI 0 is received.
If the HANDOVER COMPLETE message is received which is not preceded by an ESTABLISH
INDICATION 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 handover
protocol, 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 internal
alarm messages are filtered. If different cells are presented in the internal handover alarm sent from
the handover algorithm the maximum repetition rate of HANDOVER REQUIRED will be T_FILTER as
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
90/108

shown in the following message sequence chart. Note that this is independent of whether the MSC
sends the HANDOVER REQUIRED REJECT message.
Fig 3./24 T_FILTER & Maximum HANDOVER REQUEST RATE
The BTS sends the MEASUREMENT RESULT regularly to the BSC handover algorithm - see
ref [8].
Note the messages are not shown in the message sequence chart for simplification.
The BSC handover algorithm has detected the need to perform a handover, an internal alarm
is sent to the BSC handover protocol and T_FILTER is started.
If the best cell is external and the rules in section 3.2.2.1. - External Handover Decision are
satisfied, the BSC handover protocol initiates an external handover to the MSC by sending a
HANDOVER REQUIRED message, starting T7 and T_HO_REQ_LOST.
T_FILTER expires and the need for a handover is detected by the BSC handover algorithm
which sends another internal alarm to the BSC handover protocol. Another HANDOVER
REQUIRED will be sent if there are different cells in the internal alarm irrespective as to
whether these cells are internal or external (see section 3.3.3.1.1. - Internal Handover after
External Handover), in which case the maximum repetition rate of the HANDOVER
REQUIRED message is T_FILTER..
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
91/108

If different cells are not presented in the internal handover alarm sent from the handover algorithm
the maximum repetition rate of HANDOVER REQUIRED will be T7 as shown in the following
message sequence chart. This is also independent of whether the MSC sends the HANDOVER
REQUIRED REJECT message.
Fig 3./25 T_FILTER & Maximum HANDOVER REQUEST RATE
The BTS sends the MEASUREMENT RESULT regularly to the BSC handover algorithm - see
ref [8].
Note the messages are not shown in the message sequence chart for simplification.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
92/108

The BSC handover algorithm has detected the need to perform a handover, an internal alarm
is sent to the BSC handover protocol and T_FILTER is started.
If the best cell is external and the rules in section 3.2.2.1. - External Handover Decision are
satisfied, the BSC handover protocol initiates an external handover to the MSC by sending a
HANDOVER REQUIRED message, starting T7 and T_HO_REQ_LOST.
which 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, so
no new HANDOVER REQUIRED messages is sent. This is repeated for each internal alarm
that arrives.
T7 expires and the cell list sent to the MSC in the previous HANDOVER REQUIRED is
discarded, any cells in the REJ_CELL_LIST are also discarded.
6.
which sends another internal alarm to the BSC handover protocol. Since T7 has expired the
cell list although no different from that previously sent may be sent again in a HANDOVER
REQUIRED message. The maximum repetition rate of the HANDOVER REQUIRED
message is thus T7.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
93/108

4. - INTERFACE DESCRIPTIONS
4.1. - GSM interfaces / Physical interfaces
The following interface descriptions describe the messages specific to the external handover
procedure.
AIR interface
CHANNEL MODE MODIFY
Target BSC -> MS
sent on FACCH for compliancy with ref [18].
HANDOVER ACCESS
MS -> target BTS
sent continuously on main DCCH of target cell.
HANDOVER COMMAND
Serving BSC -> MS (transparent to the BTS)
sent on main DCCH, initiates handover with the MS.
HANDOVER COMPLETE
MS -> Target BSC (transparent to target BTS)
sent on main DCCH, initiates completion of the procedure
HANDOVER FAILURE
MS -> Serving BSC (transparent to serving BTS)
Sent on main DCCH, initiates failure of handover.
MEASUREMENT REPORT
MS -> BTS
sent on the Uplink SACCH, conveying measurements of the Downlink serving cell and Neighbour
cells.
PHYSICAL INFORMATION
Target BTS -> MS
sent ciphered on the main DCCH.
SABM SAPI 0
Layer 2 LAPDm
MS -> BTS
UA SAPI 0
Layer 2 LAPDm
BTS -> MS
Confirms reception of SABM
ABIS interface
BS POWER CONTROL
BSC -> BTS
Power control by BSC .
CHANNEL ACTIVATION
BSC -> BTS
Commands the activation of an RF channel.
CHANNEL ACTIVATION ACK
BTS -> BSC
Acknowledges successful activation of an RF channel.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
94/108

CHANNEL ACTIVATION NACK

BTS -> BSC
Indicates the unsuccessful activation of an RF channel.
ESTABLISH INDICATION SAPI 0
BTS -> BSC
Sent from the BTS to the BSC. During Channel change procedures it is sent without the Layer 3
information IE.
HANDOVER DETECTION
BTS -> BSC
Sent by the BTS when the BTS detects a correct HANDOVER ACCESS message sent by the MS.
MEASUREMENT RESULT
BTS -> BSC ()
Conveys Uplink measurements and Downlink measurements.
MS POWER CONTROL
BSC -> BTS ()
Power control message by BSC
A interface
HANDOVER COMMAND
MSC -> Serving BSC
Initiates handover towards the MS.
HANDOVER DETECT
Target BSC -> MSC
Indicates that the target BSS has received a correct HANDOVER ACCESS from the MS. It is sent by
the target BSC when the HANDOVER DETECTION message is received from the target BTS.
HANDOVER COMPLETE
Target BSC -> MSC
Initiates end of successful procedure
HANDOVER FAILURE
Target or serving BSC -> MSC
Target BSC sends this message on either unsuccessful allocation or unsuccessful activation of an RF
channel
Serving BSC sends this message when it receives the HANDOVER FAILURE message (air) from the
MS.
Initiates end of unsuccessful procedure.
HANDOVER REQUIRED
Serving BSC -> MSC
Initiates external handover, conveys preferred cell list for MSC.
HANDOVER REQUIRED REJECT
MSC -> Serving BSC
Sent by the MSC (normally only if the OIE RESPONSE REQUEST is set in the HANDOVER
REQUIRED message) when it can not perform the external handover.
HANDOVER REQUEST
MSC -> Target BSC
Initiates external handover with target BSS.
HANDOVER REQUEST ACK
Target BSC -> MSC
Acknowledges the reservation and successful activation of an RF channel for the handover.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
95/108

UNEQUIPPED CIRCUIT
Target BSC -> MSC
Sent 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 REQUEST
is unknown to the Target BSC.
SCCP MESSAGES
SCCP CONN REQ
MSC -> Target BSC for external handover
Request an SCCP connection.
SCCP CONN CNF
Target BSC -> MSC for external handover
Confirms the request.
SCCP CONN REF
Target BSC -> MSC for external handover
Refuses a connection request.
4.2. - Internal interfaces

HANDOVER ALARM
sent by handover algorithm (ref [8]) -> serving BSC.
Contains:
handover alarm cause;
Preferred cell list.
RESOURCE ALLOCATION
sent by Dedicated resource management (ref [9]) -> Target BSC.
Contains:
Result of allocation;
& optionally allocated RF channel or CIC.
DL EST IND
sent by LAPDm -> BTS.
Contains:
SAPI;
& optionally L3 information.
LAPDM REFUSE ESTAB
Target BTS -> LAPDm
changes state of LAPDm so as to refuse establishment at Layer 2.
TRANSCODER ALARMS
Internally 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
T200
MS, 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 for
DCCH connections.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
96/108

T3105_F (FACCH)
Target BTS. Supervises the rate of sending PHYSICAL INFORMATION messages to the MS for
FACCH connections.
T3106_D (DCCH)
Target BTS. Supervises the time which the MS should establish the LAPDm SAPI 0 connection from
reception of the correct HANDOVER ACCESS. Used in synchronous handovers for DCCH
connections.
T3106_F (FACCH)
Target BTS. Supervises the time which the MS should establish the LAPDm SAPI 0 connection from
reception of the correct HANDOVER ACCESS. Used in synchronous handovers for FACCH
connections.
T_CFI_Tr
BTS timer. Used to filter the internally detected transcoder alarm after DL EST IND from LAPDm.
THO_min
BTS timer. In the event that a handover condition is detected in the BTS, it controls the rate at which
the PREPROCESSING MEASUREMENT RESULT message (indicating handover conditions) are
sent to the BSC whilst a handover condition exists.
T_SYNC
BTS & Transcoder timer. This timer is used in both entities to guard the consistency of the Speech
path between both BTS & TC.
BSC TIMERS
T_HO_REQ_LOST
Serving BSC timer. This timer serves to guard against no response from the MSC
T7
Serving BSC - MSC load timer. Prevents the BSC from offering the same cell(s) too quickly in the
event that the MSC does not use the HANDOVER REQUIRED REJECT message to reject candidate
cells.
T8
Serving BSC timer. Supervises the handover with the MS.
T_MS_CELL_REJ
Serving BSC timer. Guards against target cells which the MS has failed to hand over to being
presented in subsequent handover request for a specific time period.
T9103
Target BSC timer. Supervises activation of an RF channel in the serving & target BTS.
T9104
target BSC timer. Supervises the response of the MSC after sending the CLEAR REQUEST due to
reception of CONNECTION FAILURE INDICATION (cause "Handover access failure").
T9110
Target BSC timer. Guards the response of the MSC when no resources are allocated to the SCCP
connection. Guards also the response of the MSC when a HANDOVER FAILURE has been sent
(HANDOVER REQUEST or CLEAR COMMAND awaited)
T9113
Target BSC timer. Supervises the handover with the MS.
T_FILTER
This timer runs in the BSC handover algorithm in both Modes A or B. It controls the rate of BSC
internal handover alarms in the BSC.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
97/108

T_qho
Target BSC timer. Determines the length of time the handover request is queued for.
MSC TIMERS
The following list is given for information only.
T3101
MSC timer. Supervises the handover with the MS, target and serving BSS.
Trr2
MSC timer. Guards the activation of the target cell.
MS TIMERS
T200
MS, BTS timer. Supervises the repetition of Layer 2 frames on LAPDm.
T3124
MS timer. Supervises the establishment of LapDM on the target cell after reception of the PHYSICAL
INFORMATION.
4.4.- Parameter list

The following parameter list is specific to the external handover procedure.
BTS PARAMETERS
NY1
The number of repetitions of PHYSICAL INFORMATION messages that can be sent from the target
BTS to the MS during a handover.
T3105_D_STOP
This parameter is used in the BTS to control which event will stop the timer
T3105_F_STOP
T3106_D_STOP
T3106_F_STOP
BSC PARAMETERS
BS_TXPWR_MAX
Maximum power that the BTS can transmit with.
CGI_REQD
When set TRUE, dictates that the encoding of cell identifiers will use the CGI encoding rules.
DOWNLINK_DTX_ENABLE
When 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 activation
for details on the control of downlink DTX by this flag and the control by the MSC.
DTX_INDICATOR
Indicates if DTX is to be used in the Uplink direction.
EFR_ENABLED
Enable/Disable EFR operation.
EN_IC_HO
Enabled (= True): Intercell synchronous and asynchronous handovers may be made into the cell.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
98/108

Disabled (= False): Intercell synchronous and asynchronous handovers may not be made into the
cell.
EN_SEND_OLD_CHANNEL_MODE
When set ENABLED, allows the serving BSS to include OIE Current Channel in HANDOVER
REQUIRED message.
EN_SEND_SPEECH_VER
When set ENABLED, allows the serving BSS to include OIE Speech Version in HANDOVER
REQUIRED message.
EN_UNEQUIPPED_CIRCUIT
O & M parameter which enables the UNEQUIPPED CIRCUIT message to be sent by the BSC.
EXT_HO_FORCED
When set TRUE, all internal intercell handovers are forced to be handled as external.
GSM_PHASE
This flag indicates the mode of operation/behaviour that the BSS needs to adopt on A interface. It is
set to either PHASE 1 or PHASE 2.
HO_SDCCH_INHIBIT
When set TRUE, all handovers for SDCCH are ignored.
HO_INTERCELL_ALLOWED
When set FALSE, all Inter-cell handovers are inhibited.
HR_ENABLED
Enable/Disable Half-Rate Operation.
MS_TXPWR_MAX
Maximum power that the MS can transmit with.
NCI
O & M Parameter which controls the setting of the NCI field in the Synchronisation IE in the
HANDOVER COMMAND message. This parameter is settable on a BSC basis and is changeable online. When set TRUE the MS is commanded to trigger a Handover Failure for an out of range timing
advance.
N_PREF_CELL
The value of this counter dictates the maximum number of cells that may be contained in the
HANDOVER REQUIRED message sent to the MSC.
RESP_REQ
When set TRUE, the RESPONSE REQUEST OIE in the HANDOVER REQUIRED message will be
included.
ROT
O & M Parameter which controls the setting of the ROT field in the Synchronisation IE in the
HANDOVER COMMAND message. This parameter is settable on a BSC basis and is changeable online. When set FALSE the MS is commanded not to include the Time Difference IE in the
HANDOVER COMPLETE message.
SDCCH_COUNTER
The value of this counter delays the handling of handover alarms for SDCCH connections after the
establishment of an SDCCH during the immediate assignment procedure.
STOP_HO_ACC_FAIL
This 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 BTSs
which 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
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
99/108

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-handover
Flag readable at the OMC-R, allowing synchronous handover.
BSC INTERNAL VARIABLES
SDCCH_COUNTER
This is a parameter which delays the handover of an SDCCH after an Immediate assignment
procedure. It is coded in terms of the number of SACCH multiframes.
DOT
This 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 SABM
from the MS) after the Immediate assignment procedure.
BCE
This stands for Best Cell is External.
The condition where the first cell in the cell list CL is external.
ASSGN
This stands for Assignment.
When this condition is TRUE the connection has received an ASSIGNMENT REQUEST
message 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 the
MS and the ASSIGNMENT COMPLETE or ASSIGNMENT FAILURE is awaited).
T7
This variable is set to either RUNNING or NOT RUNNING depending on the state of the timer
T7
T_HO_REQ_LOST
This variable is set to either RUNNING or NOT RUNNING depending on the state of the
timerT_HO_REQ_LOST
T_MS_CELL_REJ
This variable is set to either RUNNING or NOT RUNNING depending on the state of the timer
T_MS_CELL_REJ
MS_CELL_REJ_LIST
The list of cells that the MS has failed to handover to. The size of the list is 4.
REJ_CELL_LIST
The list of cells that the MSC has rejected as being candidate cells for the handover. The
size of the list is 2*N_PREF_CELLmax
CL
The 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 REQUIRED
message.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
100/108
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 correctly
received TCH frame or Layer 2 frame
Or 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.
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 that
ETR 09.90 is supported for the Phase 1 Network.
Ciphering algorithm may be changed between external handovers as part of the support for
Multiple algorithms.
The causes "Invalid cell & Encryption algorithm not supported" are sent on the A interface.
The UNEQUIPPED CIRCUIT may be sent to the MSC.

Note Only when allowed and when GSM PHASE == PHASE 2.
External handover may be performed successfully if the old Channel Mode and new Channel
Mode 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 REQUEST
REJECT 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 been
explicitly rejected in the HANDOVER REQUIRED REJECT message from being offered
again to the MSC.
These cells are remembered in the list REJ_CELL_LIST in the BSC.
Timer T_HO_REQ_LOST now guards the handover procedure. On expiry an O & M error
report is raised.
A cell to which the MS fails to handover to is remembered for a time period

T_MS_CELL_REJ and cannot be offered to the MSC in that time.
Incoming handovers may be inhibited by an O&M flag (EN_IC_HO) on a per cell basis.
Introduction of half rate feature. An incoming handover may be performed to a half or full
rate channel (half rate - speech only) if commanded by the MSC.
Introduction of E-GSM support. An incoming handover may be performed for an E-GSM

mobile (TCH only).
BSC release 5
1.
2.
ED
MCD
BSC can now support multiband handovers. The IE SACCH Info has been added to allow
dynamic management of System Information on a per call basis.
The Target BSC can optimize the length of HANDOVER COMMAND message by removing
the OIE Mode of the first channel.
EXTERNAL HANDOVER
02 RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
101/108

3.
The BSC supports incoming External Directed Retry.
4.
Support of EFR
5.
New cause "speech version unavailable" is used.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
102/108
6. - FEATURES
Release 5 feature list

FD/3.13
Multiband Operation in one BSC
FD/11.25
Support of Enhanced Full Rate mobiles.
FD/10.2
Minimal E-GSM Support
FD/4/10.1c
Minimum support of half rate mobiles
FD/11.6
Handover Protocol Improvements
FD/4/0.31.54
Disabling of external handover due to return to old channel by MS
FD/3/6.1
A interface compatibility
FD/3/6.2
Air interface compatibility
FD/3/5.1
A5/2 version for A900/A1800
B2314
Use of CGI over A interface
B2884
08.08 Handover required reject
B2886
08.08 Handover detection
B4010
BSC control of down-link DTX
Release 1 & 0 feature list
B2217
08.58 Handover detection
B2229
04.08 MS handover access
B2345
08.08 HO resource allocation (HO request)
B2837
Handover from TCH/F to TCH/F
B2843
Handover from SDCCH to SDCCH
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
103/108

B2861
MSC controlled external handover: intra-BSC, inter-BTS
B2862
MSC controlled external handover: inter-BSC
B2856
08.58 Channel activation: for asynchronous handover
B2869
08.58 Channel activation: for synchronous handover
B2881
08.08 Handover required with cell-list
B2885
08.08 Handover execution
B2887
08.08 Handover detection (internal)
B2889
04.08 RR Handover: asynchronous
B2890
04.08 Handover: synchronous
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
104/108
Glossary
Definitions
After time

This notation is used in GSM phase 2 to indicate during Channel change

procedures with or without Frequency redefinition procedure what the
Channel configuration is after the Starting time on the indicated channel
has been passed.
In the case where there is no Frequency redefinition there is no Starting
time included.
Asynchronous handover
A handover where the serving and target cells are not synchronised or
synchronous handover is not allowed.
Before time
This notation is used in GSM Phase 2 to indicate during the Frequency

redefinition procedure the Channel configuration before the Starting time
on 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
Dont care
This is used in State transition tables to indicate that when an event is

received 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 applicable
This is used to indicate in State transition tables that an event should not
be 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.0
MHz / 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/BSC
The BSS/BTS/BSC which is presently handling the MS connection.
Target BSS/BTS/BSC
The BSS/BTS/BSC which is going to handle the connection.
Abbreviations
ACT
ASSGN
BCCH
BSC
BSIC
BSS
BTS
ACTivation
Assignment
Broadcast Control CHannel
Base Station Controller
Base Station Identification Code
Base Station System
Base Transceiver Station
CGI
CIE
CL
Cell Global Identifier

Conditional Information Element
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 HANDOVER
REQUIRED message.
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
105/108

CLOLD
CMD
CMP
CR
CC
CRef
Candidate cell list sent to the MSC in the last HANDOVER REQUIRED
message,
CoMmanD
CoMPlete
Connection Request (SCCP)
Connection Confirm (SCCP)
Connection Refused (SCCP)
DCCH
DI
DM
DR
DT1
DTX
Dedicated Control Channel

Data INDication (Abis)
Disconnect Mode
Data REQuest (Abis)
DaTa form 1 (SCCP)
Discontinuous Transmission
EFR
EST IND
Enhanced Full Rate.

ESTablish INDication
FCCH
Frequency Correction CHannel
GSM
HO
HR
IE
Global System for Mobile communications

HandOver
Half Rate
Information Element
MEAS
MIE
MS
MSC
MEASurements
Mandatory Information Element
Mobile Station
Mobile Switching Centre
O&M
OIE
Operations & Maintenance

Optional Information Element
PHY INFO
PLMN
PHYsical INFOrmation
Public Land Mobile Network
REF
REP
REQ
RES
RESP
RR
REFUSE
REPort
REQuest
RESults
RESPonse
Radio Resource
SABM
SACCH
SAPI
SCCP
SCH
SDCCH
TCH
TDMA
Set Asynchronous Balanced Mode

Slow Associated Control CHannel
Signalling Access Point Identifier
Signalling Connection Control Part
Synchronisation CHannel
Standalone Dedicated Control CHannel
Traffic CHannel
Time Divi sion Multiple Access
UA
UI
UDI
Unnumbered Acknowledge
Unnumbered Information
Unit Data Indication (Abis)
EXTERNAL HANDOVER
ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
3BK 11202 0104 DSZZA
106/108

ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
SEQ1
107/108
EXTERNAL HANDOVER
3BK 11202 0104 DSZZA

ED
MCD
02
RELEASED
41.DOC
16/02/98 10:12
SEQ2
END OF DOCUMENT
108/108
EXTERNAL HANDOVER
3BK 11202 0104 DSZZA

&#39;Docslide Net External Ho b5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

&#39;Docslide Net External Ho b5

Uploaded by

Copyright:

Available Formats

TELECOM

All rights reserved. Passing on and copying of this

MOBILE COMMUNICATION DIVISION

PREDISTRIBUTION: DOC. CENTRES

3BK 11202 0104 DSZZA

All rights reserved. Passing on and copying of this

Reason for update

RSG approved version for Phase 1

Reason for update

Initial issue for Phase 2

Reviewed & corrected see Minutes TLA/132

Reviewed & corrected see Minutes TLA/141

Reviewed & corrected see Minutes RSG/157

Release 3 : 3BK 11202 0006 DSZZA

Reason for update

Initial draft of Release 3. Contains CRQ/287 & CRQ/292

Updated inaccordance with the minutes TLA/171

Updated in accordance to SYS/022

Updated in accordance to SYS/051

Release 4 : 3BK 11202 0057 DSZZA

Reason for update

First draft for release 4

B. SZELAZEK Updated after TLA review#4. See SYS/011

B. SZELAZEK Updated after TLA review#6. See SYS/127

B. SZELAZEK Updated after TLA review#6. See SYS/133

B. SZELAZEK Updated after TLA review#7. See SYS/133

B. SZELAZEK Updated after TLA review#9bis. See

B. SZELAZEK Inclusion of minimal support for half rate

Release 5 : 3BK 11202 0104 DSZZA

Reason for update

3BK 11202 0104 DSZZA

All rights reserved. Passing on and copying of this

First draft for release 5.

Updated afted internal review TLAr5#9. TD/SAS/LC/746.96

Updated after TLAr5#11. TD/SAS/LCR/966.96

Updated according to TLAr5#14 and

Includes CRs 15196, 15198, 15200, 19689,

INTERNAL REFERENCED DOCUMENTS

FOR INTERNAL USE ONLY

3BK 11202 0104 DSZZA

All rights reserved. Passing on and copying of this

CIPHER MODE COMMAND

ASSIGNMENT REQUEST (SDCCH->TCH

Send ASSIGNMENT FAILURE cause = No radio

ASSIGNMENT REQUEST (In call

Send ASSIGNMENT FAILURE, cause = Reversion

Send DTAP messages to MS

Allow Cipher command to

Send CIPHER MODE

Possible Actions of Queued CIPHER MODE COMMAND

Use of N_PREF_CELL/CLOLD in MS Failed Handovers

3BK 11202 0104 DSZZA

All rights reserved. Passing on and copying of this

SYSTEM FUNCTIONAL BLOCKS

3BK 11202 0104 DSZZA

All rights reserved. Passing on and copying of this

3.1.5.1. - T_HO_REQ_LOST Expiry ..........................................................................................................25

3BK 11202 0104 DSZZA

All rights reserved. Passing on and copying of this

3.2.7. - MS Handover Protocol...................................................................................................................81

3BK 11202 0104 DSZZA

All rights reserved. Passing on and copying of this

3BK 11202 0102 DSZZA

3BK 11202 0103 DSZZA

'Docslide Net External Ho b5

'Docslide Net External Ho b5