External Channel Change B9 PDF

All rights reserved.
Passing on and copying of this

document, use and communication of its contents
not permitted without written authorization from Evolium.
Site
EVOLIUM SAS
VELIZY
External Channel Change
Originators
B9
Didier ESCLAMADON
System
Sub-system
Document Category
:
:
:
ALCATEL GSM/BSS
SYS-TLA
PRODUCT DEFINITION
ABSTRACT
This document describes the protocol for the execution of an external channel change (external
handover or external directed retry).
Note that external pseudo-synchronous and pre-synchronous channel changes are not supported.
Name
App.
R MAUGER
Name
App.
I.SCHWARZ
SYT manager
Approvals
C. LEJEUNE
H.MA
SYT DPM
BSC DPM
BTS DPM
REVIEW
Ed. 01 Proposal 01
ED 07
<yy/mm/dd>
Updated according to review report, see MRD/TD/SYT/204088
RELEASED
External Channel Changes

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
1/120
All rights reserved. Passing on and copying of this

HISTORY
Ed. 01 Proposal 2004/02/04

01
Ed. 01 Proposal 10/03/2004
02
Ed. 1 Released
30/03/2004
Ed. 2 Proposal 01 23/04/2004
Ed. 02 Proposal 04/10/2004

02
Ed. 02 Released
13/10/2004
Ed. 03 Released
31/05/2005
Ed. 04 Released
22/06/2005
Ed. 05 Proposal 1
28/07/2005
Ed. 05 Released
Ed. 06 Released
27/10/2005
23/01/2006
Ed. 07 Released
30/10/2006
ED 07
Document based on Ed. 4 of B8 version of the document (3BK 11202

0347 DSZZA).
Takes into account following features :
Load-based 3G HO rejection
Updated according to review report, see MRD/TD/SYT/204088
Editorial clarification
Updated to take into account the impacts of the SFD Enhanced E-GSM
band handling (Ref. 3BK 11204 0612 DSZZA).
Taking into account VGCS feature according to Delta Note
MND/TD/VAL/SYT/mwu/0180.2004/Ed.3
TD/SYT/des/204486.04/ed1
3BKA20CBR158833 - ECC : Mode of first channel always included, due
to MS bug
3BKA20CBR163565 - ECC: The forced external HO mechanism is NOT
applied to the VGC talker
Introduction of 2G to 3G Handover feature - SFD 3BK 10204 0615
DTZZA
according to rereading report 205386_01
3BKA20CBR174251 - chosen_encryption_algo
modification
in
HO_REQ_ACK
3BKA20CBR174400 - HANDOVER REQUIRED can exceed SCCP
maximum length
3BKA20CBR176629 - HANDOVER REQUIRED cannot exceed 255
bytes
3BKA20CBR175842 - InterRATHandoverInfo coded with no information
if too much information
3BKA20CBR194363 - ECC : rules for sending Cipher Mode Sending I.E.
3BKA20CBR197317 - ECC : Coding of INTERSYSTEM TO UTRAN
HANDOVER COMMAND
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
2/120

TABLE OF CONTENTS
1 SCOPE ..........................................................................................................................................................6
2 FUNCTIONAL DESCRIPTION .....................................................................................................................7

2.1 General description.............................................................................................................................7
2.1.1 Handover Behaviour....................................................................................................................8
2.1.2 Channel change Behaviour on Failure........................................................................................9
2.2 ALCATEL BSS support for outgoing external channel changes .................................................10
2.3 ALCATEL BSS support for incoming channel change..................................................................10
2.3.1 Distinction between GSM to GSM handover and UMTS to GSM handover.............................10
2.3.2 Distinction between GSM to GSM handover and GSM to UMTS handover.............................11
2.3.3 External channel change Test Call Functionality ......................................................................11
2.4 ALCATEL BSS support for Phase 1 MS capabilities .....................................................................11
2.5 ALCATEL BSS support for Phase 2 MS capabilities .....................................................................11
2.6 External channel change entities ....................................................................................................12
3 DYNAMIC BEHAVIOUR.............................................................................................................................14
3.1 General Behaviour.............................................................................................................................14
3.1.1 Successful External Asynchronous channel change ................................................................15
3.1.2 Successful External Synchronous channel change ..................................................................19
3.1.3 Successful External Inter-sytem to UMTS channel change......................................................23
3.1.4 Target Cell Negotiation..............................................................................................................24
3.1.5 Unsuccessful External Handover ..............................................................................................26
3.1.6 Serving BSC Protocol Failures..................................................................................................28
3.1.7 Target BSC Protocol Failures ...................................................................................................29
3.1.8 Target BTS Protocol Failures....................................................................................................31
3.2 Detailed Behaviour ............................................................................................................................35
3.2.1 Serving BTS Protocol ................................................................................................................35
3.2.2 Serving BSC Protocol................................................................................................................35
3.2.3 MSC Handover Protocol............................................................................................................53
3.2.4 Target BSC External Handover Protocol ..................................................................................54
3.2.5 Target BTS asynchronous channel change protocol................................................................94
3.2.6 Target BTS synchronous channel change protocol ..................................................................97
3.2.7 MS Handover Protocol ..............................................................................................................99
3.3 Interaction with Other Procedures ................................................................................................103
3.3.1 External channel change & Ciphering Procedures .................................................................103
3.3.2 External channel change & Internal channel change Procedures .......................................... 103
3.3.3 External SDCCH or TCH Handover & Assignment Procedures .............................................104
3.3.4 External channel change & Trace ...........................................................................................105
3.3.5 External channel change & MS And BS Power Control..........................................................105
3.3.6 Handover algorithm & External channel change protocols.....................................................105
3.3.7 Handover management and External channel change protocols ...........................................105
4 INTERFACE DESCRIPTIONS..................................................................................................................106
4.1 GSM interfaces / Physical interfaces.............................................................................................106
4.2 Internal interfaces............................................................................................................................108
4.2.1 BSC internal entities................................................................................................................108
4.2.2 BSC internal interfaces with external channel change ...........................................................110
4.2.3 BTS internal interfaces ............................................................................................................111
4.3 Timer list...........................................................................................................................................111
4.4 Parameter list ...................................................................................................................................113
5 GLOSSARY ..............................................................................................................................................118
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
3/120

INTERNAL REFERENCED DOCUMENTS

Not applicable
REFERENCED DOCUMENTS
3GPP References
[1]
3GPP TS 44.004
[2]
3GPP TS 44.018
[3]
3GPP TS 24.008
[5]
3GPP TS 48.058
[4]
[6]
[7]
3GPP TS 48.008
3GPP TS 23.009
3GPP TS 09.94
Digital cellular telecommunications system (Phase 2+); Layer 1;

General requirements
Mobile Radio Interface Layer 3 specification; Radio Resource

Control Protocol
Mobile Radio Interface Layer 3 specification; Core Network protocols
MSC-BSS Interface Layer 3 specification
BSC to BTS Layer 3 specification
Handover Procedures
Recommended infrastructure measures to overcome specific phase

1 mobile stations faults.
Version numbers of the 3GPP Technical Specifications to be used in this release are given in ref.[19]
Alcatel References
[8]
[9]
Call Release
3BK 11202 0398 DSZZA
Internal Channel Change
3BK 11202 0399 DSZZA
[10]
Handover Preparation
3BK 11202 0400 DSZZA
[12]
Normal Assignment Procedure
3BK 11202 0412 DSZZA
[11]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
ED 07
Resource Allocation and Management

Blocking, Reset Circuit & Unequipped Circuit
Radio Measurements Data Processing
3BK 11202 0387 DSZZA

3BK 11202 0359 DSZZA
3BK 11202 0403 DSZZA
Short Message Service Point To Point
3BK 11202 0062 DSZZA
Classmark handling
3BK 11202 0409 DSZZA
Ciphering Procedure
3BK 11202 0156 DSZZA
System Information Management
3BK 11202 0389 DSZZA
DTX functional specification
3BK 11202 0296 DSZZA
Alcatel BSS application document to GSM General overview
3BK 11203 0096 DSZZA
Frequency encoding algorithm
3BK 11202 0388 DSZZA
Handover management
3BK 11202 0411 DSZZA
LAPDm functional specification
3BK 11202 0414 DSZZA
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
4/120

[24]
Layer 3 message dictionary - Abis interface
3BK 11203 0104 DSZZA
[26]
LCS Functional Specification
3BK 11202 0337 DSZZA
[25]
[27]
[28]
TFO Functional Specification
ASCI Functional Specification
Layer 3 message dictionary - Air interface
3BK 11202 0301 DSZZA

3BK 11202 0405 DSZZA
3BK 11203 0111 DSZZA
RELATED DOCUMENTS
None
PREFACE
OPEN POINTS / RESTRICTIONS
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
5/120

SCOPE
This document specifies the following External Synchronous & Asynchronous inter-cell handover and
directed retry protocols for the ALCATEL BSS:
External TCH handover;
External SDCCH handover;
External SDCCH to TCH directed retry.
The Alcatel BSS supports synchronous and asynchronous external channel changes.
The Alcatel BSS supports inter-system handover to UMTS.
Note that external pseudo-synchronous and pre-synchronous channel changes are not supported in 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.[8].
The cause values in the HANDOVER FAILURE messages are also specified in ref.[8].
The referencing of events in ref.[8] are provided by means of the reference and an event number within
ref.[8]. The event number takes the form of 1 to 4 character string followed by 4 numbers - e.g. ref.[8]
EHT0100 or ref.[8] N0200. These event numbers are to be found in ref.[8] together with the Call
Releasing or Resource releasing scenario if applicable.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
6/120

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, congestion in the serving cell, good radio conditions on
the UMTS coverage, etc...
The process of changing the channel is called Handover if the source and the target channel are the
same (SDCCH or TCH), and Directed retry if the source channel is a SDCCH and the target channel is
a TCH.
When the change is controlled by the MSC, and a RNC in case of inter-system handover to UMTS, it is
known as an external handover or external directed retry, when controlled by the same BSC it is
known as an internal handover or internal directed retry. The change can be to a channel in the same
cell or a channel in another cell.
When a channel change is required, the BSS Handover management entity decides which type of
channel change is to be performed, either handover or directed retry, and either internal or external.
When an external channel change is required, a channel change request accompanied by a cell list is
presented to the external handover or external directed retry protocol by handover management
(ref.[23]) in response to a handover alarm generated by the Handover preparation entity (ref.[10]).
Ref.[23] describes the handover decision process and how the candidate cells list is filtered.
This document describes the external handover and external directed retry protocol functions which
must be seen as elementary procedures, called by Handover management function.
Three types of external channel change are possible, two in the GSM system and one from GSM to
UMTS:
Intra MSC external channel change - a channel change performed between cells controlled by the
same MSC.
Inter MSC external channel change - a channel change performed between cells controlled by
different MSCs.
Inter-system external channel change - a channel change performed between a cell controlled by
a MSC and a cell controlled by a RNC (only one cell controled by a RNC can be selected at a
time).
There is no difference in behaviour of the Alcatel BSS for either the inter or intra MSC external channel
change, and thus there is no differentiation between these in this document. However, supervision
timers shall be set to large enough values to take into account inter-MSC transmissions.
External channel change can be synchronous (excepted for inter-system external channel) or
asynchronous:
Synchronous channel changes can be performed between synchronized cells, if allowed by an
O&M parameter.
Otherwise, asynchronous channel change is performed.
Pseudo-synchronous channel change is not implemented in the Alcatel BSS. Pre-synchronous channel
change is not implemented for external channel change.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
7/120

The channel change is performed between the serving BSC and the target BSCs or RNCs via the MSC.
The messages on the A, Abis and Radio interfaces are specified in ref.[2], [4] and [5].
This document describes both the serving and target BSCs behaviours. It doesnt describe the RNC
behaviour, which can be found in an UMTS related document.
When the external channel change 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 channel change protocol is to handover an UE/MS from one BSS, (the
serving BSS), to another BSS (the target BSS) or to a RNC (the target RNC), under control of the MSC.
This is done by providing the MSC with a list of cells which the serving BSS believes are good
candidates for the channel change procedure, based on the radio measurements made by the UE/MS.
When the handover preparation entity detects that a handover is necessary (handover alarm) or
possible to allow the assignment (directed retry alarm) (see ref.[10]), the candidate cells filter and
handover management functionality process the cell list accompanying the alarm and determines the
type of handover required (see ref.[23]).
If an external channel change is required, the list is presented to the external channel change protocol:
For any external channel change procedure, a handover is triggered by sending the MSC a
HANDOVER REQUIRED message containing the cells presented. If the procedure is an external
directed retry, then an ASSIGNMENT FAILURE message may additionally be sent to the MSC. 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 channel change
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.
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 serve the request for whatever reason.
At external channel change procedure level, a timer (T_HO_REQD_LOST) is used to guard against a nonresponse from the MSC.
Beside this timer, others timers are used at handover management procedure level to guard against
repeatedly sending to the MSC a cell to which the channel change failed (MS failure, congestion, ...), or
to avoid overloading the MSC with repeated attempts (T7). These timers are described in ref.[23] since
they are common with Internal channel changes procedure.
If the MSC cannot perform a handover to any of the cells presented by the BSC, it returns a
HANDOVER REQUIRED REJECT message to the BSC. It this case, the external channel change
elementary procedure is terminated and the handover management procedure will transfer all cells that
were sent to the MSC in the last HANDOVER REQUIRED message 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 any channel change
attempts on the same connection.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
8/120

The REJ_CELL_LIST is managed by the handover management entity and is therefore not described in
this document (see ref.[23]). In this document, external channel change procedure will just signal this
outcome to handover management entity (REJECT from MSC).
When the MSC choses one of the cells in the cell list CL with which to perform the handover, the target
BSS or the target RNC is requested to allocate and activate a suitable channel to which the handover
may occur.
The target BSS RAM entity chooses a channel type and/or a codec, according to information it receives
from the MSC (such as channel types and codecs allowed, channel type and codec used on the source
BSS, ...). See ref.[11].
Once the target BSS or RNC has successfully allocated the channel it passes back to the MSC the
message which will enable the UE/MS to make the move to the activated channel. The MSC passes this
to the serving BSS, which passes it to the UE/MS.
The serving BSS now awaits the successful completion of the procedure.
The UE/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] - 3GPP TS 44.018. Once communication is established
with the target BSS or RNC the UE/MS signals a successful handover to the target BSS or RNC and the
MSC initiates clearing of the old connections to the serving BSS. At the end of an external channel
change the appropriate SCCP connections (in MSC and BSS) and RF channels (in BSS) are released.
2.1.2
Channel change Behaviour on Failure
The channel change may be unsuccessful either because the MSC cannot perform a handover to any of
the cells presented to it or the UE/MS has difficulty in accessing the target cell.
If the UE/MS has any difficulty either synchronizing with the target BSS or RNC 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. If the serving BSC knows
the cell towards the channel change failed, this cell is put in MS_CELL_REJ_LIST by the handover
management entity.
Note: The BSC has two different means to identify the target cell: either the target cell identifier is
included in 48.008 HANDOVER COMMAND message, or N_PREF_CELLS = 1 and there is
only one possible target cell.
MS_CELL_REJ_LIST is managed by handover management entity - ref.[23]. In this document, external
channel change procedure will just signal this outcome to handover management entity (HO FAIL from
MS).
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
9/120

2.2
ALCATEL BSS support for outgoing external channel changes
Outgoing channel changes supported for this release of the ALCATEL BSS are shown in Table 2./1. All
the outgoing channel changes indicated as Supported in the table are supported between cells
belonging to the same PLMN (intra-PLMN GSM to GSM handover) and between cells belonging to
different PLMNs (inter-PLMN GSM to GMS or UMTS handover).
Serving BSS Channel type & mode
Channel type
Channel mode
TCH FR/HR (Note 1)
Signalling
TCH HR
Speech
SDCCH
TCH FR
TCH HR
Signalling (See Note 2)
Supported (See note 3)
Speech or Data
Supported
Data
Not Supported
Not 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.
Note 3: SDCCH inter-system handover to UTRAN is not supported.
2.3
ALCATEL BSS support for incoming channel change
Any incoming channel change 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 between different speech versions (Full Rate version 1, Full Rate version 2, Half Rate
version 1, AMR Full Rate, AMR Half Rate) are supported.
Directed retries from SDCCH to any traffic channel configuration (speech full rate or half rate,
data full rate) are supported.
The Alcatel BSS supports faulty phase 1 MS for directed retry, with respect to ref.[7].
The Alcatel BSS supports incoming traffic channel changes from UMTS system.
The Alcatel BSS supports incoming intra-PLMN and inter-PLMN GSM to GSM handovers.
2.3.1
Distinction between GSM to GSM handover and UMTS to GSM handover
The distinction between a GSM to GSM handover and a UMTS to GSM handover can be made through
the field Cell Identification Discriminator (CID) of the I.E. Cell Identifier Serving in the HANDOVER
REQUEST message.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
10/120

The values 0000 (The whole cell global Identification, CGI), 0001 (Location Area Code, LAC, and Cell
Identity, CI), 0010 (Cell Identity, CI) correspond to a GSM to GSM handover, while the value 1011
corresponds to a UMTS to GSM handover (Serving Area Identity, SAI, is used to identify the Serving
Area of UE in intersystem handover from UTRAN or cdma2000).
2.3.2
Distinction between GSM to GSM handover and GSM to UMTS handover
The distinction between a GSM to GSM handover and a GSM to UMTS handover can be made through
the field Cell Identification Discriminator (CID) of the I.E. Cell Identifier List (Prefered) in the HANDOVER
REQUIRED message.
The values 0000 (The whole cell global Identification, CGI), 0001 (Location Area Code, LAC, and Cell
Identity, CI), 0010 (Cell Identity, CI) correspond to a GSM to GSM handover, while the values 1000
(PLMN-ID, LAC and RNC-ID), 1010 (LAC and RNC-ID) correspond to a GSM to UMTS handover.
2.3.3
External channel change Test Call Functionality
The external channel change procedure provides a facility allowing the inhibition of incoming channel
change 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 channel changes into the cell.
It should be noted that internal intra cell channel change are not affected by this flag.
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 channel change and
internal channel change (ref.[9]).
The ALCATEL BSS never allows the stopping, starting or changing of the Ciphering algorithm during
Channel changes (ie external handover, internal handover (ref.[9]) & Assignment (ref.[12])) 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.[7]
2.5
ALCATEL BSS support for Phase 2 MS capabilities
Phase 2 MSs are able to support two additional channel change types (which are not supported for
external channel change by this release of the ALCATEL BSS) they are: pseudo-synchronous & presynchronous (external) 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.[16]).
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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
11/120

The ALCATEL BSS ensures during external channel change that the MS Ciphering capabilities, BTS
Ciphering capabilities & MSC Ciphering requirements are taken into account whilst performing the
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 channel change entities
The following entities are involved in the execution of an external channel change:
MS Downlink measurement
The UE/MS measures: the strength, quality and distance of the serving BSS and the strength of
BCCH carriers of GSM neighbour cells and the Ec/No quantity of FDD carriers of UMTS neighbour
cells. The neighbour cell list is sent to the UE/MS in SYSTEM INFORMATION TYPE 5 family
messages and MEASUREMENT INFORMATION message on the SACCH. Measurements made by
the UE/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 UE/MS. The
serving BSS indicates to the UE/MS how many FDD cells can be reported by the UE/MS. This is
described in ref.[10].
MS Handover protocol
The method of performing the handover protocol.
This protocol will be described in this document for completeness. The asynchronous and
synchronous protocols 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.[14].
Serving BSC Handover Preparation entity (HOP)
The BSS takes the measurements from the UE/MS and the BTS and analyses whether it is
necessary to perform a channel change - ref.[10].
When a channel change is required an alarm is sent to the serving BSC handover management
entity with a list of preferred cells. see ref.[23].
Serving BSC Handover management entity (HOM)
This entity receives handover and directed retry alarms from the handover preparation entity. It
decides which type of channel change is needed (external or internal, directed retry or handover)
and triggers the corresponding protocol. It also manages the failure cases, and the interactions
between these procedures. This entity also 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.
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 UE/MS and the serving BSC.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
12/120

Serving BSC External Channel Change entity (ECC)

This entity initiates the handover or directed retry attempt towards the MSC.
This document will specify the protocol to be performed.
MSC Handover and directed retry protocols
The MSC chooses the target cell and performs the protocol with both serving and target BSC.
The MSC performs the protocol with the target RNC for inter-system handover to UTRAN.
This document will describe, in general terms only, the protocol in the MSC for Intra MSC handover see Note 1.
Target BTS Handover and directed retry protocols
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 External Channel Change entity (ECC)
The target BSC performs the handover and directed retry protocol.
This document will specify the protocol to be performed.
Target BSC Resource Allocation and management entity (RAM)
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 UE/MS & MSC functions will be given so as to aid the reader. Behaviour may
deviate due to implementation choices in the UE/MS and MSC.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
13/120

3 DYNAMIC BEHAVIOUR
3.1 General Behaviour
This section contains the successful and major failure cases of an external channel change which
consist mainly of errors due to timer expiry and GSM defined messages. In this section message
protocol errors or internal system errors are not taken into account; these cases are dealt with in section
3.2 Detailed Behaviour where the checking and error handling is specified.
Only Radio, Abis and A interface messages are used in the message sequence charts within this
section.
In case of inter-system to UMTS handover the prefered cell list to be sent to the MSC shall contain only
one cell.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
14/120

3.1.1
Successful External Asynchronous channel change
The following message sequence chart shows the scenario of a successful external asynchronous
handover / directed retry for a serving BSS.
MS
Serving BTS
(1)
Serving BSC
Target BTS
Target BSC
MSC
ECC request from Handover

Management
Start T7
(2)
DT1 HO REQUIRED (CL) / ASSIGN FAIL

------------------------------------------------------------------->
(3)
CR HO RQST
<-------------------
Start T_HO_REQD_LOST
start
Trr2
CC --------------->
(4)
CHAN ACT
<-------------------CHAN ACT ACK-------------->
(5)
Start T9103
Stop T9103
DT1
ACK
HO REQ
------------->
start T9113
(6)
DT1 HO COMMAND
<-----------------------------------------------------------------------
stop
Trr2
start
T3103
stop T_HO_REQD_LOST
(7)
(8)
(9)
HO CMD
<-----------
DR (HO CMD)
<-----------------
Start
Start T8
T3124
HO
ACCESS
--------------------------------------------------------->
PHYSICAL INFO
<-------------------------------------------------------
HO DETECTION
------------------>
DT1 HO DETECT
-------------------->
start T3105
Stop T3124
(10)
SABM
or
any
correct
frame
-------------------------------------------------------->
UA
<---------------------------------------------------------
(11)
ED 07
HO
COMPLETE
RELEASED
EST
IND
(if
SABM)----------->
Stop T3105
Start T_CFI_TR
HO
CMP
DT1 HO COMP
stop

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
15/120

-------------------------------------------------------->
(12)
------------------->
Note A
-------------------->
stop T9113
T3103
Note B
Directed Retry only

(13)
CHANNEL MODE MODIFY

<----------------------------------------------------------------------------------CHANNEL
MODE
MODIFY
ACK
------------------------------------------------------------------------------------>
Fig 3/1 External Asynchronous channel change
Note A: Call release scenario (This includes the stopping of timer T8).
Note B: In some cases, the Target BSC must trigger a classmark interrogation procedure. See ref.[17]
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
16/120

3
4
Handover management decides to perform an external channel change (external handover or

external directed retry). It filters the cell list provided by HOP (removes previously rejected cells),
sends the request containing up to N_PREF_CELLS cells to EHO or EDR protocol and start T7.
T7 is started by the handover management entity (not described in this document - see ref.[23]) 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_REQD_LOST is started by
ECC to guard against no response from the MSC.
The BSC initiates an external channel change 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 and filtered by handover management entity.
If the procedure is a directed retry, the BSC may also send an ASSIGNMENT FAILURE message
before or after HANDOVER REQUIRED, depending on O&M parameters. See section 3.2.
Note: the HANDOVER REQUIRED message may contain the OIE Response Request
depending on the O&M parameter RESP_REQ.
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 external channel change entity asks the RAM entity to allocate an appropriate RF
channel. When allocated, this channel is activated. In case of TCH-call, the BSC sets up the
internal path across the switch and switches the downlink direction (see Note) taking into account
the full rate / half rate requirements of the new channel.
The target BTS starts sending dedicated system information messages on the SACCH (see
ref.[18]). The TA in the Layer 1 header shall indicate that the timing advance information is invalid.
The target BTS: starts ciphering immediately (if applied).
The target BTS starts also to synchronise with the transcoder. As long as the synchronisation is
not correct, the BTS sends every T_SYNC a CONNECTION FAILURE INDICATION cause
remote transcoder failure message to the BSC.
For Phase 2 MSs the Ciphering used on the new channel may be different from the one used on
the old channel.
6
7
8
ED 07
The target BSC: 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 MSC: stops Trr2; forwards the message to the serving BSS in a HANDOVER COMMAND
message; and starts T3103.
The serving BSC: stops T_HO_REQD_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 3.2.2 on serving BSC detailed behaviour.
The MS on reception of the HANDOVER COMMAND: disconnects the old channel; synchronizes
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 equal to 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 switches the uplink direction of
the internal path set up in (4) (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.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
17/120

10
11
12
13
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 9),
sends an ESTABLISH INDICATION (SAPI 0) to the target BSC (only if SABM SAPI 0 is received);
sends an UA to the MS, starts T_CFI_TR and starts BS and MS power control if required and
resynchronises system information messages (restarts at SYSTEM INFORMATION TYPE 5
message).
The target BTS may stop sending PHYSICAL INFORMATION and the timer T3105 when it
receives a correctly received frame - see ref.[8]. The event that stops T3105 (i.e. SABM SAPI 0 or
any correct frame) is controlled by the O&M parameter STOP HO ACC FAIL.
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 channel change is now complete.
The serving BSS RF channel and terrestrial resources are released. This is performed by the
MSC sending the CLEAR COMMAND (cause "Handover successful") - ref.[8] EHS0400, T8 and
T7 are stopped.
If this is a directed retry to a Full Rate Channel allocated for speech version 1, for a phase 1 MS
(see section 3.2.4.8.1); then CHANNEL MODE MODIFY message is sent to the MS. The
corresponding CHANNEL MODE MODIFY ACK is discarded.
Note: In case of TCH to TCH channel change, the BSC prepares in the downlink direction one leg of a
Y connection possibly made inside the MSC.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
18/120

3.1.2
Successful External Synchronous channel change
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 synchronized.
MS
Serving BTS
Target BTS
(1)
Serving & Target BSC
MSC
ECC request from Handover Management

Start T7
DT1 HO REQUIRED (CL)

/
ASSIGN
FAIL
-------------------------------->
(2)
(3)
CR
HO
RQST
<--------------------------------
Start Trr2
CC --------------------------->
(4)
CHAN
ACT
<-------------------------CHAN
ACT
ACK
--------------------------->
(5)
Start T9103
Stop T9103
DT1 HO REQ ACK

-------------------------------->
stop Trr2
DT1 HO COMMAND
<---------------------------------
start
T3103
start T9113
(6)
stop T_HO_REQD_LOST
HO
CMD
<----------(7)
(8)
DR (HO CMD)
<-------------------------------------------------
HO ACCESS 1--------------->
HO ACCESS 2--------------->
HO ACCESS 3--------------->
HO ACCESS 4--------------->
SABM or any correct frame
----------------------------------->
HO
DETECTION
------------------------->
start T3106
start T8
DT1
HO
DETECT
--------------------------------->
EST IND (if SABM)

-------------------------->
stop
start T_CFI_TR
T3106
UA
<------------------------------------(9)
ED 07
HO
COMPLETE
------------------------------------>
DI HO COMPLETE
------------------------->
RELEASED
DT1
HO
COMP
---------------------------->
stop T9113
stop
T3103

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
19/120

(10)
Note A
Note B
Directed retry only
(11)
CHANNEL MODE MODIFY

<--------------------------------------------------------------------CHANNEL
MODE
MODIFY
ACK
-------------------------------------------------------------------->
Fig 3/2 External Synchronous channel change
Note A: Call release scenario with serving BTS
Note B: In some cases, the Target BSC must trigger a classmark interrogation procedure. See ref.[17]
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
20/120

1. Handover management decides to perform an external channel change (external handover or

external directed retry). It filters the cell list (removes previously rejected cells), sends the request
containing a maximum of N_PREF_CELLS cells to EHO or EDR protocol and starts T7.
T7 is started by the handover management entity (not described in this document - see ref.[23]) 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_REQD_LOST is started to guard
against no response from the MSC.
2. The BSC initiates an external channel change 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 and filtered by handover management entity.
If the procedure is a directed retry, the BSC may also send an ASSIGNMENT FAILURE
message before or after HANDOVER REQUIRED, depending on O&M parameters.
See section 3.2.
Note: the HANDOVER REQUIRED message may contain the OIE Response Request
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.
4. The target BSC external channel change entity asks the resource allocation and management entity
to allocate an appropriate RF channel. When allocated, this channel is activated.
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: SACCH transmission of dedicated system information messages is
started immediately on each channel & any Layer 1 header sent on Radio interface 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.
The target BTS: starts ciphering immediately (if applied).
The target BTS starts also to synchronise with the transcoder. As long as the synchronisation is not
correct, the BTS sends every T_SYNC a CONNECTION FAILURE INDICATION cause remote
transcoder failure message to the BSC.
For Phase 2 MSs the Ciphering used on the new channel may be different from the one used on the
old channel.
The target BSC, in case of TCH-call, sets up the internal path across the switch and switches the
downlink direction (see Note below) taking into account the full rate / half rate requirements of the
new channel.
5. The target BSC 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 MSC: stops Trr2; forwards the message to the serving BSS in a HANDOVER COMMAND
message; and starts T3103.
6. The serving BSC: stops T_HO_REQD_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 3.2.2 on serving BSC detailed
behaviour.
7. The MS on reception of the HANDOVER COMMAND: disconnects from the old channel;
synchronizes 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).
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
21/120

The target BSC relays a HANDOVER DETECT to the MSC and switches the uplink direction of the
internal path set up in (4) (TCH only).
8. 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.
The target BTS: stops T3106, sends an ESTABLISH INDICATION (SAPI 0) to the target BSC (only
if SABM SAPI 0 is received), sends a UA to the MS, starts T_CFI_TR and starts BS and MS power
control if required and resynchronises system information messages (restarts at SYSTEM
INFORMATION TYPE 5 message).
The target BTS may stop the timer T3106 when it receives a correctly received SABM SAPI 0 or any
correct frame - see ref.[8].
9. 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 channel change is now complete.
10. The serving BSS RF channel and terrestrial resources are released. This is performed by the MSC
sending the CLEAR COMMAND (cause "Handover successful") - ref.[8] EHS0400, T8 and T7 are
stopped.
11. If this is a directed retry to a Full Rate Channel allocated for speech version 1, for a phase 1 MS
(see section 3.2.4.8.1), then CHANNEL MODE MODIFY message is sent to the MS. The
corresponding CHANNEL MODE MODIFY ACK is discarded.
Note:
ED 07
In case of TCH to TCH channel change, the BSC prepares in the downlink direction one leg
of a Y connection possibly made inside the MSC.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
22/120

3.1.3
Successful External Inter-sytem to UMTS channel change
The following message sequence chart shows the scenario of a successful external inter-system to
UMTS channel change for a serving BSS.
The target RNC behaviour is out of the scope of this document. It is here presented for information only.
UE/MS
Serving BTS
Serving BSC
Target RNC
MSC
ECC request from

Handover Management
(1)
Start T7
(2)
DT1
HO
REQUIRED
(CL)
-------------------------------------------------------------->
Prepare handover
<--------------Relocation Request
<------------------
(3)
Reloc. Request Ack

------------------>
Prep. handover resp.
--------------->
DT1 HO COMMAND
<--------------------------------------------------------------
(4)
stop T_HO_REQD_LOST
(5)
(6)
INTER
SYSTEM
TO
UTRAN
HO CMD
<-----------
DR (INTER SYSTEM
TO UTRAN HO CMD)
<-----------------------------
Relocation Detect
------------------>
Start T3121
HANDOVER
COMPLETE
------------------------------------------------------------------------->
Relocation Complete
------------------>
End Signal Request
(7)
--------------->
DT1
CLEAR
COMMAND
<--------------------------------------------------------------
(8)
DT1
CLEAR
COMPLETE
------------------------------------------------------------>
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
23/120

Stop T3121
Fig 3/3 External inter-system to UMTSchannel change

(1) Handover management decides to perform an external intersystem to UMTS channel change . It
filters the cell list provided by HOP (removes previously rejected cells), sends the request
containing the UMTS cell to EHO protocol and start T7.
T7 is started by the handover management entity (not described in this document - see
ref.[23]) 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_REQD_LOST is started by ECC to guard against no response from the MSC.
(2) The BSC initiates an intersystem to UMTS external channel change by sending a HANDOVER
REQUIRED message with the 3G cell given in the top of the cell list reported in the handover
alarm and filtered by handover management entity.
Note:
the HANDOVER REQUIRED message may contain the OIE Response Request
(3) The MSC performs the handover required procedure with the target RNC. The protocol shown in the
figure is for example only: it may deviate, as it is not in the scope of this document.
(4) The MSC indicates to the serving BSS that the handover is accepted by the UMTS, in a HANDOVER
COMMAND message. The Layer 3 INTERSYSTEM TO UTRAN HANDOVER COMMAND is
included in that HANDOVER COMMAND.
(5) The serving BSC: stops T_HO_REQD_LOST; sends the INTERSYTEM TO UTRAN HANDOVER
COMMAND to the UE/MS via the BTS adding the Air interface header for this message
(destined for the main DCCH); starts T3121 & starts to ignore error messages from the BTS see section 3.2.2 on serving BSC detailed behaviour.
(6) The UE/MS on reception of the INTERSYTEM TO UTRAN HANDOVER COMMAND: disconnects
the old channel; synchronizes to the new cell; sends a HANDOVER COMPLETE message to
the target RNC.
(7) The target RNC terminates the protocol to the MSC.
(8) The serving BSS RF channel and terrestrial resources are released. This is performed by the MSC
sending the CLEAR COMMAND (cause "Handover successful") - ref.[8] EHS0400, T3121 and
T7 are stopped.
3.1.4 Target Cell Negotiation
3.1.4.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.
This function is specified in ref.[23].
Note that T7 management and target cell selection is fully described in ref.[23]. This section describes
T7 and target cell negotiation as viewed from external channel change procedure only for
completeness.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
24/120

3.1.4.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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
25/120

At handover management level, timer T7 is fundamental to the operation of the external channel change
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 candidate cells, is sent to the MSC.
T7 is started when a external channel change is started (i.e. from the A interface point of view, just
before a HANDOVER REQUIRED message is sent to the MSC) and stopped when T_HO_REQD_LOST
expires (see section ).
T7 is restarted (i.e. 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.
3.1.4.2.1 BSC Reaction to HANDOVER REQUIRED REJECT
When the BSC receives a HANDOVER REQUIRED REJECT, the external channel change procedure is
terminated. The external channel change entity sends a message Reject by MSC to handover
management entity, which will hold these rejected cells in a list, and decide whether it re-attempts a new
external channel change. see ref.[23]
However when the BSC sends several HANDOVER REQUIRED messages to the MSC in case of radio
condition change without waiting for the MSC response, the BSC is not able to determine if the
HANDOVER REQUIRED REJECT message received from the MSC is the response to the last
HANDOVER REQUIRED message or to a previous one (in case of message crossing upon A interface).
In this case, the timer T_HO_REQD_LOST is not stopped upon HANDOVER REQUIRED REJECT receipt
from the MSC. The external channel change entity sends a message Reject by MSC to handover
management entity as above, but the external channel change is considered as terminated at
T_HO_REQD_LOST expiry. See also ref.[23].
3.1.4.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
handover management entity can decide to ask the external channel change protocol to send a new
HANDOVER REQUIRED to the MSC, based on the same target cell list (before filtering). After filtering,
the resulting target cell list sent to the MSC can however be different from the previous one, due to T7
expiry (REJ_CELL_LIST has been emptied).
This sequence is repeated until the MSC answers (HANDOVER COMMAND, HANDOVER REQUIRED
REJECT) or T_HO_REQD_LOST expires, see section .
3.1.5
Unsuccessful External Handover
This section presents two types of unsuccessful external handover where:

1. the MS is unable to perform the handover;
2. the MSC fails to respond to the handover request.
It is recalled that in both cases, external channel change procedure only reports to handover
management these attempt issues. Decisions for a new attempt, for cell rejection list management are
taken by handover management entity, see ref.[23].
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
26/120

Unsuccessful external inter-system to UMTS handover is not presented here: the serving BSS
behaviour is the same as for external handover within GMS, except for T8 timer replaced with T3121
timer.
3.1.5.1
MS Handover Failure
The MS may be unable to perform the handover for the following reasons:
1. Inability to find, or synchronize 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 (i.e. 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. The external channel change protocol will send back a message HO FAIL
from MS to handover management entity, which will put target cell into MS_CELL_REJ_LIST and start
T_MS_CELL_REJ. Other cells may also be put into REJ_CELL_LIST, see ref.[23].
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 for the HANDOVER FAILURE case.
In the case where the MS can detect that the handover cannot be performed, (e.g. 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 re-establishment of the
lower layer is unnecessary.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
27/120

The message sequence chart shown below shows the scenario for the reception of HANDOVER
FAILURE.
MS
Serving BTS
Serving BSC
(1)
Target BTS
Target BSC
MSC
DT1 HANDOVER COMMAND

<---------------------------------------------------------stop T_HO_REQD_LOST
HO CMD
<-----------------Note A
SABM-------->
(2)
<--------------UA
HO
FAIL
----------------->
DR HO CMD
<-----------------
start T8
EST IND------------->
DI
HO
FAIL
-------------------------->
DT1
HO
FAIL
---------------------------------------------------------->
stop T8
start T_MS_CELL_REJ
Note B
Fig 3/4 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.
2. When the MS receives the UA it returns a HANDOVER FAILURE message to the serving BTS. he
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". he external channel change protocol informs handover
management entity with an HO FAIL from MS message. If the target cell is known, handover
management will put it into MS_REJ_CELL_LIST. Other cells may also be put into
REJ_CELL_LIST, see ref.[23]. The MSC releases the target BSS resources by sending a CLEAR
COMMAND with cause "Radio interface failure, reversion to old channel" - ref.[8] EHT1100.
3.1.6
Serving BSC Protocol Failures
The major failures exhibited during the protocol are as follows:

expiry of T_HO_REQD_LOST
expiry of T8.
expiry of T3121.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
28/120

3.1.6.1 T_HO_REQD_LOST Expiry

This timer is used to supervise response from the MSC. It is started when sending the first HANDOVER
REQUIRED to the MSC and it is stopped in the following cases:
when HANDOVER COMMAND is received from the MSC or
when HANDOVER REQUIRED REJECT is received from the MSC only if the same number of
HANDOVER REQUIRED REJECT messages have been received from the MSC than the number of
HANDOVER REQUIRED messages sent to the MSC for this channel change procedure) (i.e. no
message crossing over A interface).
In case where more HANDOVER REQUIRED messages have been sent to the MSC, the timer
T_HO_REQD_LOST is not stopped upon HANDOVER REQUIRED REJECT receipt, as there is no way for
the BSC to know if the received HANDOVER REQUIRED REJECT is a response to the last
HANDOVER REQUIRED message or a response to a previous one (message crossing over A
interface).
On expiry, an O&M error report is raised only when no message has been received from the MSC since
the last HANDOVER REQUIRED message, and the external channel change procedure is terminated.
3.1.6.2
T8 Expiry
T8 is started in the serving BSC when sending the HANDOVER COMMAND to the MS 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. In this
case, the serving BSC sends a CLEAR REQUEST to the MSC, see ref.[8] EHT0100.
When the CLEAR REQUEST is generated by the serving BSC all cell lists are cleared.
3.1.6.3
T3121 Expiry
T3121 is started in the serving BSC when sending the INTERSYTEM TO UTRAN HANDOVER
COMMAND to the UE/MS to supervise the handover of the UE/MS to the target RNC. The expiry of the
timer indicates that the UE/MS did not return to the old channel and the MSC has not initiated a call
release scenario after a successful handover. In this case, the serving BSC sends a CLEAR REQUEST
to the MSC, see ref.[8] EHT0100.
When the CLEAR REQUEST is generated by the serving BSC all cell lists are cleared.
3.1.7
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");
no resource available.
The general system strategy for handling protocol errors after the reception of the HANDOVER
REQUEST is as follows:
1
2
ED 07
if an internal failure is detected (error in HANDOVER REQUEST message, no resource

available, ...) 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 attach to the new channel then a
CLEAR REQUEST will be sent to the MSC.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
29/120

In both cases, Radio interface resources will be released.

When releasing A interface resource, the target BSC starts T9110. If this timer expires, the BSC
performs an autonomous release, ref.[8] EHT0500.
3.1.7.1 T9103 Expiry
This timer is used during channel activation procedures.
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.[8] EHT0200 and sends a HANDOVER
FAILURE message to the MSC. These actions are carried out in parallel.
3.1.7.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.[8] EHT0300.
3.1.7.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.[8] 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.[8] and T9110
is started to supervise the response of the MSC.
3.1.7.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.[8] for more
detail). The connection is cleared - ref.[8] 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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
30/120

3.1.7.5
No radio resource available
When the incoming external channel change procedure asks to the RAM entity (ref.[11]) to find a
suitable radio resource (Select channel), it may happen that the target cell is congested or that no
suitable resource can be found. In this case external channel change procedure receives a select
channel reject message from the RAM entity and sends a HANDOVER FAILURE (cause no radio
resource available) to the MSC -see ref.[8] EHT0800.
With respect to the incoming external handover from UTRAN, the BSC shall consider the current cell
load and the UTRAN coverage to decide whether it shall reject this kind of handover with the failure
case of no radio resource available: the UTRAN coverage is supposed to be weak as soon as the
incoming handover has been triggered by an emergency cause.
One current cell load state parameters is defined in the BSC for the Load based 3G HO filtering
feature: 3G_HOReject_Load State. When an external handover request comes from UTRAN, the BSC
will check the handover cause and current cell load, this is not an emergency handover and
3G_HOReject_Load State is high in the target BSC, then the target BSC shall reject this handover and
shall send a HANDOVER FAILURE (with cause no radio resource available and with the cell load
information) to the MSC. See ref[11] for details.
If this is not an emergency external handover and 3G_HOReject_Load State is low in the target BSC, it
may also happen that the target cell is congested or that no suitable resource can be found. In this case
external channel change procedure receives a select channel reject message from the RAM entity and
sends a HANDOVER FAILURE (with cause no radio resource available and with the Cell load
information) to the MSC. See ref[11] for details].
If this is an emergency handover, it may also happen that the target cell is congested or that no suitable
resource can be found. In this case external channel change procedure receives a select channel
reject message from the RAM entity and sends a HANDOVER FAILURE (with cause no radio
resource available and with the Cell load information) to the MSC. See ref[11] for details.
The same scenario applies if the request is rejected after a queuing phase.
3.1.8
3.1.8.1
Target BTS Protocol Failures
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 (i.e. TCH frame or Layer 2 frame independent of the SAPI value). This
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
31/120

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 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.
MS
(1)
Target BTS
HO
ACCESS
1
--------------------------------------------------->
Target BSC
DI HO DETECTION
---------------------------->
start T3106
MSC
DT1 HO DETECT
------------------------->
HO
ACCESS
2
--------------------------------------------------->
HO
ACCESS
3
--------------------------------------------------->
HO
ACCESS
4
--------------------------------------------------->
(2)
start
T200
SABM
or
any
correct
frame
------------------------------------------------XX
(3)
T200 expires
T3106
expiry
CONN
FAIL
IND
---------------------------->
(4)
start
200
SABM
------------------------------------------------->
(5)
Stop
T200
DM
<---------------------------------------------------
XX : SABM lost on the Radio interface
DT1 CLR REQ

------------------------>
Start T9104
Fig 3/5 Timer T3106 Expiry
1. The MS has successfully synchronized 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. It also 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 target BSC sends a HANDOVER DETECT to the MSC.
2. The MS: connects to the channel (i.e. may start to transmit TCH frames) & sends an SABM (SAPI 0)
using the old timing advance set on the old channel; and starts T200.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
32/120

The target BTS: does not receive either the SABM or any correct frame (they are lost on the Radio
interface).
3. 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.[8] EHT0400
4. T200 expires in the MS. The MS: sends the SABM once more; and starts T200.
5. 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.[8]
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 i.e. 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 ref.[22].
3.1.8.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 (i.e. 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
required 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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
33/120

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.
The message sequence chart below shows the case where NY1 is 2.
MS
Target BTS
Target BSC
(1)
start T3124
HO
ACCESS
---------------------------------------------->
DI HO DETECTION
-------------------------->
(2)
stop T3124
PHY INFO
<-----------------------------------------------
start T3105
(3)
start T200
SABM
--------------------------------------------XX
(4)
PHY INFO
<---------------------------------------------PHY INFO
<----------------------------------------------
(5)
SABM
---------------------------------------------->
(7)
DM
<-----------------------------------------------
XX SABM lost on the Radio interface
DT1 HO DETECT
----------------------->
T3105 expiry (NY1

times)
Start
T3105
T3105 expiry
CONN FAIL IND
------------------------->
(6)
MSC
DT1 CLR REQ

---------------------->
Fig 3/6 Timer T3105 Expiry
1. The MS: has successfully synchronized 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.
2. The target BTS: calculates the timing advance; informs the timing advance algorithm of 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.
3. 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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
34/120

The target BTS: does not receive the SABM or another correct frame (they are lost on the Radio
interface).
4. The timer T3105 expires in the target BTS and the PHYSICAL INFORMATION is sent again.
5. The timer T3105 expires (NY1 times) in the target BTS: LAPDm is placed into the idle 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.[8] EHT0400.
6. T200 expires in the MS. The MS: sends the SABM once more; and starts T200.
7. The target BTS on reception of the SABM sends a DM to the MS.

The MS on reception of the DM: stops T200; and returns to the serving cell & old channel.
Warning: the target BSC starts the clearing sequence with the target BTS immediately (ref.[8]
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 i.e. 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.
3.2
3.2.1
Detailed Behaviour
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 a Radio interface failure on the old
channel.
No error detected on the Radio interface on the old channel side will cause the serving BTS to
automatically release the MS connection (it is the BSC's responsibility to release the RF resources).
The Remote transcoder alarms will be filtered as shown in the target BTS section of this document. This
filtering is performed for all active TCH RF channels.
3.2.2
Serving BSC Protocol
The serving BSC external channel change protocol has the following functions to perform:
External channel change decision
This function is described in Handover management entity, ref.[23]. Given the cell list from the BSS
handover preparation and a set of O&M flags, this function decides whether an external channel
change is to be performed.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
35/120

External handover and external directed retry protocols

Once the handover management entity indicates that an external handover or an external directed
retry is required, these protocols initiate and complete the procedure with the MSC.
3.2.2.1
Serving BSC External Handover Protocol
When an external handover is to be attempted (upon request of handover management entity), it is

initiated by the serving BSC external channel change procedure sending the HANDOVER REQUIRED
message, and starting T_HO_REQD_LOST. T7 is started in HOM, see ref.[23].
Additionally, when an external directed retry is to be attempted, the BSC may send an ASSIGNMENT
FAILURE message, depending on O&M parameters.
The figure on the following page shows the states in the serving BSC for the handover and directed
retry protocols and the major events only that cause state transitions. The full list of events is defined in
the state tables in this section.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
36/120

HO COMMAND
T_HO_REQ_LOST expiry
CLEAR CMD
HO REQ REJ
0386_07.doc
06/11/2006
Send "Exit and clear"

to HOM
Stop T8 or T3121
Send HO FAIL to MSC
Send "HO FAIL from MS" to HOM
Stop T_HO_REQ_LOST
Start T8 or T3121
Send O&M error report

Send "Exit and clear" to HOM
HO FAIL from MS
ECC
IN PROG
CLEAR CMD
"HO Successful"
T3121 or T8 expiry
Send "Exit and clear"

to HOM
3BK 11202 0386 DSZZA
37/120
Fig 3/7 Serving BSC State Diagram & Major Events (See notes overleaf)
ECC INIT
ED07 RELEASED
"Request for EDR" from HOM"

or "Request for EHO" from HOM
Send HO REQUIRED to MSC
Stop T_HO_REQ_LOST
Send "Exit and clear" to HOM
Stop T_HO_REQ_LOST
(under condition)
Send Reject from MSC
to HOM

Start T_HO_REQ_LOST
Start T_HO_REQ_LOST
Depending on O&Mparameters,
ASSIGN FAIL may also be sent.
NULL
"Request for EHO"
from HOM
T_HO_REQ_LOST expiry
Request for EDR

from HOM
Send Exit and clear to HOM

STATE DESCRIPTION
ABBREVIATION
This state represents one of the entry and exit states of the
external channel change protocol. This state can be left only
by a request coming from Handover management
procedure.
NULL
The serving BSC has initiated an external channel change

(by sending the HANDOVER REQUIRED), T_HO_REQD_LOST
is running and the serving BSC is awaiting a response from
the MSC or a change in radio conditions.
ECC INIT.
The serving BSC has received the HANDOVER COMMAND

and is awaiting either the failure or success of the procedure.
T8 is running.
ECC IN PROG.
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.
3.2.2.1.1
NULL State behaviour
The NULL state represents an entry state to the external channel change procedure, it is a logical state and
is used for representation in this document.
The serving BSC will service the events shown in table 3/2 in the NULL state.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
38/120

EVENT
Request for EHO, including up to
N_PREF_CELLS cells (CL) and the
Cause
ACTION
Send HANDOVER REQUIRED to MSC with cell list CL
Store
cells
as
CLold
Start
T_HO_REQD_LOST
Set an internal variable HO_REQD_ongoing to 1
If an LCS procecure is on-going,
Send a BSCLP PERFORM LOCATION ABORT (cause
Inter BSC Handover Ongoing) to the SMLC
See ref.[26] for more details.
Endif
Next state (ECC INIT)
Request for EDR, including up to

N_PREF_CELLS and the Cause
If
(EDR_SEND_ASSIGN_FAIL
=
TRUE
and
EDR_MSG_ORDER
=
Assign
fail/HO
reqd)
then send ASSIGNMENT FAILURE to MSC
endif
Send HANDOVER REQUIRED to MSC with cell list CL
Store
cells
as
CLold
Start
T_HO_REQD_LOST
Set an internal variable HO_REQD_ongoing to 1
If an LCS procedure is on-going,
Send a BSCLP PERFORM LOCATION ABORT (cause
Inter BSC Handover Ongoing) to the SMLC
See ref.[26] for more details.
Endif
If
(EDR_SEND_ASSIGN_FAIL
=
TRUE
and
EDR_MSG_ORDER
=
HO
reqd/Assign
Fail)
then send ASSIGNMENT FAILURE to MSC
endif
Next state (ECC INIT)
Send Exit and clear to HOM with the optional cause
set to T_HO_REQD_LOST expiry
T_HO_REQD_LOST expiry
BSCLP
PERFORM
LOCATION
RESPONSE from the SMLC
Next state (NULL)

Send an 48.008 PERFORM LOCATION RESPONSE
to the MSC.
Stop
T_Location
T_Loc_Abort
or
T_Location_Longer
or
Discard LCS Context in the BSC.

Table 3/2 NULL State events
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
39/120

3.2.2.1.2
Normal Events
STATE
ECC INIT
ECC IN PROG
EVENT
HANDOVER COMMAND
Stop T_HO_REQD_LOST
Send HO CMD (case GSM to
GSM
handover)
or
INTERSYSTEM TO UTRAN HO
CMD (case 2G to 3G handover)
to MS: see section 3.2.2.3
Discard
Note 1
the
message
Start T8 (case GSM to GSM

handover) or T3121 (case GSM
to UMTS handover)
Next state (ECC IN PROG)
HANDOVER
REJECT
REQUIRED
Note 5
Discard
Decrease the internal variable

HO_REQD_ongoing
If HO_REQD_ongoing = 0,
Then
Stop T_HO_REQD_LOST
Endif
Send Reject from MSC to
HOM
Next state (NULL)
T8 EXPIRY
Not Applicable
ref.[8] EHS0100
ED 07
Send O & M Event only if no

message has been received
from the MSC since the last
HANDOVER REQUIRED
message sent by the BSC.
with the optional cause set to
Next state (NULL)
RELEASED
Next state (NULL)

Not applicable

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
40/120

STATE
ECC INIT
ECC IN PROG
EVENT
Request for EHO or
Request for EDR with
maximum N_PREF_CELLS
cells (CL)
Note 2
Discard
Send HANDOVER REQUIRED

to MSC with new cell list CL
Store CL as CLOLD
Increase the internal variable
HO_REQD_ongoing
HANDOVER FAILURE
Not Applicable
Send HO FAIL (cause "reversion to

old channel") to MSC
Stop T8 or T3121, which one is
runing
ref.[8] EHS0200
Send HO FAIL from MS to HOM
Next State (NULL)
CLEAR
(Cause
successful)
Note 1:
Note 2
Note 3:
Note 4:
Note 5:
ED 07
COMMAND
Handover
Note 3
Note 4
Stop T_HO_REQD_LOST
Stop T8 or T3121, which one is

runing
ref.[8] N0600
ref.[8] EHS0400
Next State (NULL)
Next State (NULL)
Table 3/3 Normal Events State Table
The serving BSC is in a state where there is an external handover already in progress. The
HANDOVER COMMAND will be discarded.
An alarm is always accompanied by a cell list which is processed as defined in ref.[23].
The CLEAR COMMAND (cause "Handover successful") is only expected in the state ECC IN
PROG. As it has appeared in a state where it is unexpected a Call release will occur independent
of the cause.
The CLEAR COMMAND (cause "Handover successful") is only expected in this state, the MS is no
longer on the channel.
Upon receipt of HANDOVER REQUIRED REJECT message from the MSC the timer
T_HO_REQD_LOST is stopped only if ECC is sure that no pending HANDOVER REQUIRED
message is under process in the MSC (according to the value of the internal variable
HO_REQD_ongoing). Otherwise the timer T_HO_REQD_LOST keeps running in NULL state which
avoids a deadlock within HOM in case of external directed retry.
It is useful when several HANDOVER REQUIRED messages were sent sent to the MSC, and the
receipt of a single HANDOVER REQUIRED REJECT from the MSC may be the response to the
last or a previous HANDOVER REQUIRED message. At T11 expiry (i.e. the request is dequeued
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
41/120

in RAM), HOM is not able to decide if the MSC has ended the directed retry protocol. So HOM will
wait for the T_HO_REQD_LOST expiry before to inform NASS to send the CLEAR REQUEST
message to the MSC. No O&M report shall be raised in this specific case of T_HO_REQD_LOST
expiry.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
42/120

3.2.2.1.3
Unexpected Events on A interface & DTAP
STATE
ECC INIT
ECC IN PROG
EVENT
CLEAR
COMMAND
Note 1
Stop T_HO_REQD_LOST
Deferred
ECC
Note 3
ref.[8] N0600
until
outcome
of

Next state (NULL)
SCCP-N-DISC
Stop T_HO_REQD_LOST
Stop T8 or T3121, which one

is runing
ref.[8] N0500
ref.[8] EHS0600
Note 7
Next state (NULL)

Next state (NULL)
DTAP message
Send to MS via BTS
Queue
Note 2
message
CIPHER MODE
COMMAND
Perform Ciphering
Discard message
Remember that ciphering has

started
External channel
continues
change
CIPHER MODE
COMPLETE
If ciphering has started, then

send
HANDOVER
REQUIRED
Discard
ASSIGNMENT
REQUEST
Stop T_HO_REQD_LOST
Discard message
Next state (NULL)

Send exit and clear to HOM
Abandon handover;
Perform Assignment
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
43/120

STATE
ECC INIT
ECC IN PROG
EVENT
RESET
RESET CIRCUIT
Stop T_HO_REQD_LOST
Stop T8 or T3121, which one

is runing
ref.[8] N0900
ref.[8] N0900
Next state (NULL)
Next state (NULL)
Stop T_HO_REQD_LOST
A i/f: SCCP release immediate

Note 6

ref.[8] N1000
Radio i/f: Deferred until

outcome of ECC - Notes 4 & 5
Next state (NULL)

48.008
PERFORM
LOCATION
REQUEST from
the MSC
See Note 8.
If EN_LCS = FALSE
Send back to the MSC an 48.008 PERFORM LOCATION
RESPONSE (cause Facility not supported)
If EN_LCS = TRUE
Discard the message.
Send back to the MSC a PERFORM LOCATION
RESPONSE (Cause Inter-BSC Handover)
48.008
PERFORM
LOCATION
ABORT from the
MSC
For more details, see ref.[26].

When an LCS context exists in the BSC (LCS procedure has
been started before the channel change procedure)
Store the abort cause value received on A interface
Discard message (an abort response is already awaited
from the SMLC)
When no LCS context exists in the BSC
Sends back to the MSC a 48.008 PERFORM LOCATION
RESPONSE (cause copied from the Abort message)
Note 1:
Note 2:
ED 07
Table 3/4 Unexpected Event Handling A Interface & DTAP
All cause values with the exception of "Handover successful".
The MSC should not be sending DTAP messages whilst it has initiated a handover. However, the
BSC will queue up to five received DTAP messages. If the DTAP buffer contains more than one
SAPI 3 message only the first SAPI 3 message is successfully processed upon handover
completion, the other SAPI 3 messages are lost, see ref.[15].
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
44/120

Note 3:
ED 07
The release on A interface (i.e. 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 FAIL is sent to the MSC..
The release on Abis & Radio interface is initiated when the MS sends the HANDOVER FAILURE
on the old RF channel or when the timer T8 expires. Scenario ref.[8] - N0600 applies.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
45/120

Note 4:
Note 5:
Note 6:
Note 7:
Note 8:
ED 07
The release of the A interface A Channel is done when either the MS sends the HANDOVER
FAILURE on the old RF Channel or when the timer T8 expires.
The release on Abis & Radio interface is initiated when the MS sends the HANDOVER FAILURE
on the old RF Channel or when the timer T8 expires.
The release on A interface (i.e. 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.
The release on the Abis & Radio interface is initiated when the MS sends the HANDOVER
FAILURE on the old RF Channel or when the timer T8 expires.
The release of the SCCP connection (i.e. 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.
If the SCCP-N-DISC-IND contains a DTAP message and for this specific state, the BSC does not
forward the DTAP message to the MS as usually done, but discards it.
The MSC is aware that an external channel change is ongoing and should wait for the outcome of
this procedure before triggering an LCS procedure for this target MS.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
46/120

3.2.2.1.4
Events from BTS

ECC INIT
STATE
ECC IN PROG
EVENT
CONN FAIL INDIC
(Radio-link Fail)
Stop T_HO_REQD_LOST
Discard message
ref.[8] N0700
Next state (NULL)
CONN FAIL INDIC

(Remote
Trans
Failure)
Stop T_HO_REQD_LOST
Discard message
ref.[8] N0800
Next state (NULL)
EST INDIC SAPI 0
Don't care
Note 3
ERR REP (O&M

intervention)
Stop T_HO_REQD_LOST
Stop T8 or T3121, which

one is runing
ref.[8] N0400
ref.[8]
N0400

Next state (NULL)
ERR REP SAPI 0
(Msg seq err)
Stop T_HO_REQD_LOST
Discard message
ref.[8] N1200
Next state (NULL)
ERR INDIC SAPI 0

(Note 1)
Stop T_HO_REQD_LOST
Discard message

ref.[8] N0100
Next state (NULL)
ERR INDIC SAPI 0

(Note 2)
ED 07
Don't care
Discard message
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
47/120

ECC INIT
STATE
ECC IN PROG
EVENT
REL INDIC SAPI 0
Stop T_HO_REQD_LOST
Discard message

ref.[8] N0200
Next state (NULL)
APPLICATION
INFORMATION
Note 1
Note 2
Note 3
Discard message
Table 3/5 Handling of Events and Errors from Serving BTS.
Causes: T200 expiry (N200 + 1); Unsolicited DM response: Multi frame established state; &
Sequence error.
All other causes than those mentioned in Note 1.
No external events are generated by the BSC at this point in time, however the BSC performs
some internal actions.
3.2.2.1.5
Unexpected Events on BSCLP interface
For more details on LCS protocol, see ref.[26].
STATE
EVENT
BSCLP
PERFORM
LOCATION
RESPONSE
from the SMLC
ECC INIT
ECC IN PROG
When an LCS context exists in the BSC (LCS procedure has

been started before the channel change)
Send the 48.008 PERFORM LOCATION RESPONSE to
the MSC
Stop T_Location or T_Location_Longer or T_Loc_Abort
Clear LCS context
When no LCS context exists in the BSC
Discard message.
BSCLP COI MS
POSITION
COMMAND from
the SMLC
Discard messages
Table 3/6 Unexpected Event Handling BSCLP Interface
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
48/120

3.2.2.1.6
DTAP and BSSMAP procedures
The processing of DTAP and BSSMAP in the serving BSS during external channel change (i.e. whilst in the
ECC 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. However, if the DTAP buffer contains more than one SAPI 3 message only the first
SAPI 3 message is successfully processed upon handover completion, the other SAPI 3 messages
are lost, see ref.[15].
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.[3].
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
49/120

3.2.2.1.7
HANDOVER REQUIRED message building
To initiate an external channel change 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
MIE Message type
Set to HANDOVER REQUIRED
MIE Cause
The cause will be set depending on the cause in the alarm raised by
handover preparation entity, ref.[10]. See ref.[9] for mapping
between handover preparation causes and A interface causes.
OIE
Request
Response
MIE Cell Identifier List

(Preferred)
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.
Case GSM to GSM handover:
The cell list when built will contain no more cells than indicated by
the
N_PREF_CELLS
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 (LAC + CI is used). (Note 1)
The N_PREF_CELLS is an O&M modifiable operator parameter.
Case GSM to UMTS handover:
OIE Circuit pool list
The cell list is built with only one UMTS cell.

When the O&M flag CGI_3G_REQUIRED is set to TRUE, then the
Cell Identification Discriminator will be coded with the whole cell
identification
(MCC
+
MNC
+
LAC
+
RNC_ID)
Otherwise the cell will be identified by use of the Cell Identification
Discriminator coded as (LAC + RNC_ID). (Note 2)
Not used.
OIE Current Channel
This IE contains the mode and the channel currently used. It is only
included if O&M flag EN_SEND_OLD_CHANNEL_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.
Not used.
OIE Queuing indicator

OIE Old BSS to New
BSS Information
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
50/120

Extra info
In case of TCH better cell handover, this IE is present and contains

the Extra information field:
no pre-emption is recommended by the serving BSS to the target
BSS.
In case of TCH emergency handover and directed retry, the Extra
information field is not included by the serving BSS, as the preemption capabilities are provided by the MSC to the target BSS.
The list of better cell/emergency handover causes is defined in
ref.[10], in addition the handover cause 12 is considered as an
emergency handover for eMLPP.
Multirate configuration
info
In case of AMR call (i.e. the serving channel type is AMR HR or

AMR FR), this IE is present and contains the MultiRate
configuration field:
provide to the target BSS the set of AMR codec used, the threshold
and hysteresis sent to the MS for link adaptation and optionally, the
initial codec mode. It contains also the indication to allow or forbid
use of AMR Noise Suppressor.
Inter RAT Handover

Info
OIE Source RNC to

Target RNC
information container
This IE is present in case of external GSM to GSM handover, if it

has been previously received from the UE/MS in the UTRAN
CLASSAMRK CHANGE message (This information shall be used
later by the target BSC in case of GMS to UMTS handover).
This IE is present in case of handover to UMTS. It contains:
the Inter RAT handover information with inter RAT capabilities
RRC container composed of the InteRATHandoverInfo IE
(received from the UE/MS in the UTRAN CLASSAMRK
CHANGE message), the Classmark 3 and classamrk 2 IEs.
the target cell id, retrieved from O&M parameters RNC-id and
CI_3G
Table 3/7 HANDOVER REQUIRED Message

Note 1: Handovers towards cells belonging to a different PLMN are not possible if CGI_REQD is set to 0.
Note 2: Handovers towards UMTS cells belonging to a different PLMN are not possible if
CGI_3G_REQUIRED is set to 0.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
51/120

3.2.2.1.8
ASSIGNMENT FAILURE message construction
This message is sent in case of external directed retry, if allowed by O&M parameter. See section 3.2.
Information element
MIE Message type
Set to ASSIGNMENT FAILURE
MIE Cause
Set according to EDR_ASSIGN_FAIL_CAUSE

Not used
OIE Circuit Pool

OIE Circuit pool list
3.2.2.2
Not used
Table 3/8 ASSIGNMENT FAILURE message construction
SCCP segmentation
After the SCCP connection is established, the HANDOVER REQUIRED message may be segmented and
sent in several DT1 messages.
The Inter RAT Handover Info that is included in HANDOVER REQUIRED (either Old BSS to New BSS
Information or Source RNC to Target RNC Transparent Information) is received from the UE/MS in the
UTRAN CLASSMARK CHANGE message. This information may include up to 248 octets in length.
This requires the following to be implemented :
a)
Case external handover to UMTS. If the Inter RAT Handover Info leads to exceed 255 octets for the
whole HANDOVER REQUIRED message then Inter RAT Handover Info parameter is included in
Source RNC to Target RNC Transparent Information with no octets in the value part (only the length
identification is included and set to 0).
b)
Case external handover to GSM and the Inter RAT Handover Info is to be added to the Old BSS to
New BSS Information. If this IE leads to exceed 255 octets for the whole HANDOVER REQUIRED
message then Inter RAT Handover Info is not included in the Old BSS to New BSS Information.
After step a) or b) has been processed it may happened that the whole HANDOVER REQUIRED message
contents exceeds the maximum length allowed in one SCCP DT1 message. In such a case the HANDOVER
REQUIRED message shall be segmented in as many DT1 as necessary. The first DT1 with 255 octets in
length and bit M indicating that more data will be sent. The last DT1 with remaining data and bit M indicating
that no more data will be sent.
3.2.2.3
Forwarding of A interface HANDOVER COMMAND to the MS
The HANDOVER COMMAND message received from the MSC is either transparently forwarded to the MS
in case of a GSM to GSM handover, or forwarded as an INTERSYSTEM TO UTRAN HANDOVER
COMMAND message with adding the Air interface header in case of GSM to UMTS handover.
The following defines the check to be performed by the serving BSC to identify which kind of handover is
ongoing when receiving the HANDOVER COMMAND from the MSC, thus correctly forwarding the right
message to the MS:
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
52/120

If the CellIdentifier OIE is present in the HANDOVER COMMAND received from the MSC and if its value
identifies a GSM to GSM handover then the BSC forwards it transparently to the MS.
If the CellIdentifier OIE is present in the HANDOVER COMMAND received from the MSC and if its value
identifies a GSM to UMTS handover then the BSC build the INTER SYSTEM TO UTRAN HANDOVER
COMMAND message as specified in document ref. [28].
If the CellIdentifier OIE is absent in the HANDOVER COMMAND received from the MSC, then the BSC
checks for the last HANDOVER REQUIRED sent to the MSC on the current connection:
If the CellIdentifierListPreferred in that HANDOVER REQUIRED message identified a GSM to GSM
handover then the BSC forwards the HANDOVER COMMAND received, transparently to the MS.
If the CellIdentifierListPreferred in that HANDOVER REQUIRED message identified a GSM to UMTS
handover then the BSC build the INTER SYSTEM TO UTRAN HANDOVER COMMAND message as
specified in document ref. [28].
If the CellIdentifier OIE is present in the HANDOVER COMMAND received from the MSC but not in the
range to decide which type of handover is ongoing, then the BSC acts as if this OIE were absent.
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 intra-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 a HANDOVER REQUEST message is sent to the target BSS - see ref.[16] for the
MSC's 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 reenables 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. If RESPONSE
REQUEST was TRUE in HANDOVER REQUIRED, the MSC sends a HANDOVER REQUIRED REJECT
to the source BSS.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
53/120

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
signaled 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. Since the target BSC set up the internal path and switched the downlink
direction after reception of the CHANNEL ACTIVATION ACK message, the advantage provided by this
last kind of MSCs is kept (i.e. information possibly sent in the downlink direction from the network to the
mobile can reach it even before the HANDOVER DETECT is performed.
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 channel
change protocol.
For more details on the processing of the HANDOVER REQUEST message and the SCCP connection
establishment for external handovers / directed retries refer to the relevant sections in this chapter.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
54/120

STATE DESCRIPTION
ABBREVIATION
The Target BSC received a HANDOVER REQUEST and asked for a

resource to RAM. The response from RAM is awaited.
INCOMING ECC INIT
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, set up the internal
path (TCH only) and switched the downlink direction, 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 switched the uplink direction of the internal path previously
set up after activation of the channel (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
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
55/120

STATE
NULL
EVENT
Request for incoming
ECC
Process HANDOVER REQUEST message, see section 3.2.4.8.

If OK:
The BSC re-orders the preferred speech version(s) received in
HANDOVER REQUEST in decreasing order (e.g. speech version 3 first,
then speech version 2, then speech version 1), for FR and HR speech
versions, so that in the final list, FR and HR codecs keep the same order
as in the original list (see Table 11). This choice has been taken in order
to try to keep the spirit of the list sent by the MSC, while privileging the
AMR codecs.
The BSC stores channel rate, channel type, indication of emergency call,
AMR parameters if any, priority level and pre-emption capabilities (pci and
pvi bits from OIE Priority, or pci=pvi=0 when OIE Priority is not present),
received in HANDOVER REQUEST and the previously re-ordered list of
preferred speech version(s).
Send Select channel to RAM, including queuing authorization, priority
level and pre-emption indicator. See Note 27 & 29.
Next state (INCOMING ECC INIT)
Table 3/10 State table for expected events (NULL state)
Example
1
Original list
FR SV3 (AMR FR)
FR SV1 (classical FR)
FR SV1 (classical
FR)
HR SV3 (AMR HR)
HR SV1 (classical
HR)
Example
2
FR ordered list
FR SV2 (EFR)
FR SV3 (AMR FR)
FR SV2 (EFR)
FR SV2 (EFR)
FR SV3 (AMR FR)
HR SV1 (classical
HR)
FR SV1 (classical
FR)

FR SV3 (AMR FR)
FR SV2 (EFR)
HR ordered list
Reordered list
HR SV3 (AMR HR)
HR SV1 (classical
HR)
FR SV3 (AMR FR)
HR SV3 (AMR HR)

FR SV2 (EFR)
HR SV1 (classical
HR)
HR SV3 (AMR HR)
HR SV1 (classical
HR)
FR SV3 (AMR FR)

FR SV2 EFR)
HR SV3 (AMR HR)

HR SV1 (classical
HR)
HR SV3 (AMR HR)
Comments
The order of the

original list (FR, HR,
FR, HR, FR) is
preserved in the
reordered list (FR,
HR, FR, HR, FR).
The order of the
original list (FR, FR,
HR, FR, HR) is
preserved in the
reordered list (FR,
FR, HR, FR, HR).
Note: The lists are ordered from highest to lowest priority.
Table 11 Example of reordering of speech version preference list.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
56/120

STATE
INCOMING ECC INIT
EVENT
Channel selected from RAM
Send CHANNEL ACTIVATION to target BTS

Start T9103
Next state (AWAIT CHN ACT ACK)
Select channel queued from

RAM (T_qho is started in
RAM)
Send QUEUING INDICATION to MSC
Select channel reject from

RAM (congestion, queuing
not allowed, queuing timer
expiry, no suitable resource
available, pre-empted...)
If a CIC is allocated then CIC state is made FREE
Next state (INCOMING ECC INIT)
Send HANDOVER FAILURE to MSC ref.[8] EHT0800

Start T9110
Next state (AWAIT MSC RESP)
CLEAR
MSC
COMMAND
from
If the request is queued, send dequeue request to

RAM T_qho is stopped in RAM.
The release of A interface is initiated immediately.
Table 3/12 State table for expected events (INCOMING ECC INIT state)
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
57/120

STATE
AWAIT CHN ACT ACK
EVENT
CHANNEL
ACTIVATION
ACKNOWLEDGE
CHN
ACT
NACK
(Request transcoding
rate unavailable)
Stop T9103
Set up the internal path across the switch (TCH only) and
switch the downlink direction taking into account the full
rate / half rate requirements of the new channel
Send
HANDOVER
REQUEST
ACK
Start
T9113
Next state (AWAIT HO DETECTION)
Stop T9103
Send HANDOVER FAILURE to MSC
for "data" connection, use ref.[8] EHT0101
for "speech" connection, use ref.[8] EHT0106
Start T9110
CHN
ACT
NACK
(Encryption algorithm
not implemented)
Stop T9103
Send HANDOVER FAILURE to MSC -ref.[8] EHT0102
Start T9110
CHN ACT NACK (All

other causes)
Stop T9103
Send HANDOVER FAILURE to MSC - ref.[8] EHT0103
Start T9110
T9103 EXPIRY
Send HANDOVER FAILURE to MSC -ref.[8] EHT0200

Start T9110
Table 3/13 State Table for Expected Events During Channel Activation
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
58/120

STATE
AWAIT HO DETECTION
AWAIT ESTAB IND
AWAIT HO CMPLT
EVENT
HANDOVER
DETECTION
Switch the uplink direction

on a per call basis
depending on the full
rate/half rate requirements
of the connection. (TCH
only)
Don't care
Don't care
BSC starts MS & BS Pwr

Ctrl as required;
Next
state(AWAIT
HO
CMPLT)
Don't care
Send HO DETECT
Next state(AWAIT ESTAB
IND)
ESTABLISH
INDICATION
SAPI 0
Note 2
on a per call basis
of the connection (TCH
only)
Note 8
Ctrl as required;
Next
state(AWAIT
HO
CMPLT)
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
59/120

STATE
AWAIT HO DETECTION
AWAIT ESTAB IND
AWAIT HO CMPLT
EVENT
HANDOVER
COMPLETE
Note 3
Note 4
Stop T9113
Stop T9113
Stop T9113
Send HO CMPLT

on a per call basis
of the connection(TCH
only)
Send HO CMPLT
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
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

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

Ctrl as required;
Enable DTAP
Enable DTAP
Note 25
Next state(NULL)
Note 25
Next state(NULL)
Enable DTAP
Note 25
Next state(NULL)
Table 3/14 State Table for Expected Events During Channel Change
The reception of these events in other states (i.e. 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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
60/120

STATE
EVENT
AWAIT HO
DETECTION
AWAIT ESTAB IND
AWAIT HO CMPLT
WAIT MSC
RESP
T9113 EXPIRY
ref.[8] EHT0300
ref.[8] EHT0300
ref.[8] EHT0300
Not
Applicable
CONN FAIL IND

(Handover access
failure)
Note 2;
ref.[8] EHT0400
Not Applicable
Not
Applicable
CLEAR COMMAND
Note 17
Stop T9113
Stop T9113
Stop T9113
Stop T9113
ref.[8] EHT1100
ref.[8] EHT1100
ref.[8] EHT1100
ref.[8]
EHT1100
T9110 expiry
Not Applicable
Not Applicable
Not Applicable
ref.[8]
EHT0500
HANDOVER
REQUEST
Not Applicable
Not Applicable
Not Applicable
Note 5
ref.[8] EHT0400
Stop T9110
Table 3/15 State Table for Expected Events During Channel Change
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
61/120

STATE
INCOMING
ECC INIT
AWAIT CHN
ACT ACK
AWAIT
HO
DETECT
ION
CLEAR
COMMAND
Note 18
A Int Note 15
A Int Note 15
NC Note 13
NC Note 19
A Int & NC
Note 24
SCCP-N-DISC
Note 20
A Int Note 15
A Int Note 15
NC Note 13
NC Note 19
EVENT
RESET
AWAIT
ESTAB
IND
AWAIT
HO
CMPLT
A Int & NC
Note 24
A Int & NC
Note 24
WAIT
MSC
RESP
Stop
T9110
ref.[8]
EHT0900
Stop
T9113
Stop
T9113
Stop
T9113
Stop
T9110
A Int & NC
ref.[8]
EHT1001
A Int & NC
ref.[8]
EHT1001
A Int & NC
ref.[8]
EHT1001
ref.[8]
EHT1000
Note 28
Note 28
Stop
T9113
Stop
T9113
Stop
T9113
Stop
T9110
A Int & NC
ref.[8]
N0900
A Int & NC
ref.[8]
N0900
A Int & NC
ref.[8]
N0900
A Int is
released
locally
A Int & NC
Note 14
A Int & NC
Note 14
A Int & NC
Note 14
Stop
T9110
A Int Note 15
A Int Note 15
NC Note 13
NC Note 19
A Int Note 15
A Int Note 15
NC Note 13
NC Note 19
Discard
or
reject
message
Note 23
Discard
or
reject
message
Note 23
Queue
message
Note 12
CIPHER
MODE
COMMAND
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
ASSIGNMENT
REQUEST
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
Note 12
Discard
message
RESET
CIRCUIT
DTAP
message
ED 07
A Int is
released
locally
Queue
message
Note 12
Queue
message
Note 12
Discard
or reject
message
Note 23
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
62/120

PERFORM
LOCATION
REQUEST
from the MSC
PERFORM
LOCATION
ABORT from
the MSC
See Note 30.

Discard message
Send an 08.08 PERFORM LOCATION RESPONSE (Cause Protocol Error) to
the MSC
Discard message
Send an 08.08 PERFORM LOCATION RESPONSE (cause value copied from the
Abort message ) to the MSC
Table 3/16 Unexpected Event Handling - A Interface & DTAP
STATE
AWAIT CHN
ACT ACK
CONN
FAIL
IND (Note 9)
Not Applicable
EVENT
AWAIT HO
DETECTION
Don't care
AWAIT ESTAB
IND
Don't care
AWAIT HO
CMPLT
Don't care
AWAIT
MSC
RESP
Not
Applicable
Note 11
CONN
FAIL
IND (Radio-link
fail)
Not Applicable
ERR
REP
(O&M
intervention)
ref.[8]
EHT1200
ERR
REP
SAPI 0 (Msg
seq err)
Don't care
ERR
SAPI 0
(Note 6)
IND
Not Applicable
ERR
SAPI 0
(Note 7)
IND
ED 07
Don't care
Don't care
Don't care
Not
Applicable
Note 11
ref.[8] N0400
ref.[8] N0400
ref.[8] N0400
Not
Applicable
Note 11
Don't' care
Don't care
Don't care
Not
Applicable
Note 11
Don't care
Don't care
Don't care
Not
Applicable
Note 11
Not Applicable
Don't care
Don't care
Don't care
Not
Applicable
Note 11
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
63/120

REL
SAPI 0
IND
Not Applicable
Don't care
Don't care
Don't care
Not
Applicable
Note 11
MEASURE
RESULT
Not Applicable
Note 21
Note 21
Note 22
Table 3/17 Handling of Errors from Target BTS
Note 2:
the HANDOVER DETECTION message was lost on Abis.
Note 4:
the ESTABLISH INDICATION message was lost on Abis.
Note 3:
Note 5:
Note 6:
Note 7:
Note 8:
Note 9:
Not
Applicable
the HANDOVER DETECTION and ESTABLISH INDICATION message were lost on Abis.
The HANDOVER REQUEST message processing is entered once more.
Causes: T200 expiry (N200 + 1); Unsolicited DM response: Multiframe established state; &
sequence error.
All other causes other than those in Note 6.
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.
CONNECTION FAILURE INDICATION (cause "Transcoder failure") is valid for TCH connections
only.
Note 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.
Note 12: The MSC should not be sending any of these messages at this time in the protocol - see ref.[3].
Note 13: The request in the queue is de-queued and the waiting timer (T_qho) is stopped.
Note 14: The release on the A (A interface Circuit), Abis & Radio interfaces are deferred until either T9113
expires or the BSC receives the HANDOVER COMPLETE from the MS.
Note 15: The release of the A interface is initiated immediately.
Note 17: The CLEAR COMMAND contains the cause "Radio interface failure, reversion to old channel".
Note 18: All other causes other than "Radio interface failure, reversion to old channel".
Note 19: The Channel activation procedure continues. The Channel will be released with the appropriate
Resource release scenario.
Note 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.
Note 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.
Note 22: The messages are processed by Power control & handover Algorithms.
Note 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".
Note 24 The release of the A interface is initiated immediately and the release of the Abis and Radio
interfaces is initiated with release scenario ref.[8] EHT1101.
Note 25 In some cases, the Target BSC must trigger a classmark interrogation procedure. See ref.[17].
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
64/120

Note 26 To recognise an incoming directed retry, see section 3.2.4.8.1.

The CHANNEL MODE MODIFY message is sent without starting any timer. When CHANNEL
MODE MODIFY ACK is received, it is discarded. See ref.[7].
Note 27 In the case of incoming external handover or external directed retry, queuing authorization is set
according to MSC requirement in HANDOVER REQUEST message.
In case of incoming external handover and according to the handover cause value in HANDOVER
REQUEST message, ECC precises in Select Channel message towards RAM if it has to be
considered as an emergency EHO or as a better cell EHO and if the EHO comes from the UTRAN
(see section 3.2.4.8.2).
Note 28 If the SCCP-N-DISC-IND contains a DTAP message and for this specific state, the BSC does not
forward the DTAP message to the MS as usually done, but discards it, because the MS may not be
on the new channel yet.
Note 29 In the case of incoming TCH external handover or external directed retry, ECC provides in Select
Channel message towards RAM the pre-emption indicator. It is set according to MSC requirement
(OIE Priority) and serving BSC recommendation (OIE Old BSS to New BSS Information including
Extra information field) from the HANDOVER REQUEST message (see section 3.2.4.8.3).
Note 30 The MSC is aware that an external channel change is ongoing and should wait for the outcome of
this procedure before triggering an LCS procedure for this target MS.
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.
Target BSC
(1)
(2)
(3)
MSC
SCCP CON REQ
<------------------------------------------------------------
Start T9110
SCCP
CON
CONF
------------------------------------------------------------>
Stop T9110
HANDOVER REQUEST
<------------------------------------------------------------
Fig 3/8 HO Request after SCCP Establishment
1. The MSC sends an SCCP CONN REQUEST to the target BSC without any message contained.
2. The target BSC: returns the SCCP CONN CONFIRMATION to the MSC.
3. Once the SCCP connection is established the MSC now sends the HANDOVER REQUEST message.
Target BSC
ED 07
MSC
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
65/120

SCCP CON REQ (HANDOVER REQUEST)

<-----------------------------------------------------------SCCP
CON
CONF
------------------------------------------------------------>
1
2
Fig 3/9 HO Request during SCCP Establishment
The MSC sends an SCCP CONN REQUEST to the target BSC with a HANDOVER REQUEST
message contained within it.
The target BSC: returns the SCCP CONN CONFIRMATION to the MSC.
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.
Target BSC
(1)
(2)
(3)
MSC
SCCP CON REQ (UNKNOWN/INCORRECT MESSAGE)

<-----------------------------------------------------------Start T9110
Stop T9110
SCCP
CON
------------------------------------------------------------>
CONF
DT1(HANDOVER REQUEST)
<--------------------------------------------------------------------------
Fig 3/10 HO Request after SCCP Establishment with Unknown L3 Message

1
2
ED 07
The SCCP CON REQ is sent with a message. This message is either unknown or incorrect (e.g.
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.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
66/120

3.2.4.2
SCCP Connection Failure
The SCCP connection may fail in the BSC as shown below in figure 3./10.
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.
Target BSC
MSC
SCCP CON REQ (HANDOVER REQUEST)

<-----------------------------------------------------------SCCP
CON
REF
------------------------------------------------------------>
Fig 3/11 HO Request during SCCP Connection - SCCP Failure
1
2
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 signaled by the expiry of
T9110. In this case an SCCP RELEASED is sent to the MSC.
Target BSC
(1)

<-----------------------------------------------------------------------
(2)
(3)
MSC
Start T9110
T9110 expiry
SCCP
CON
CONF
---------------------------------------------------------------------->
SCCP
RELEASED
----------------------------------------------------------------------->
SCCP RLC
<--------------------------------------------------------------------------
1
2
3
ED 07
Fig 3/12 SCCP Establishment with T9110 Expiry
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.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
67/120

3.2.4.3
SCCP Reassembly
After the SCCP connection is established, the HANDOVER REQUEST may be segmented and sent in
several DT1 messages, as shown in the message sequence chart below.
Target BSC
ECC
(1)
MSC
SCCP
<------------------------------------------------------------
<-------------Start T9110
-------------->
SCCP CON CONF
------------------------------------------------------------>
(2)
Start
Treassembly
(3)
DT1(HANDOVER REQUEST part 1)

<------------------------------------------------------------DT1(HANDOVER REQUEST part 2)
<------------------------------------------------------------:
(4)
Stop
Treassembly
Stop T9110
1
2
3
DT1(HANDOVER REQUEST part n)

<--------------
Fig 3/13 HO Request after SCCP Establishment with Unknown L3 Message

The SCCP CONN REQUEST can be sent with a message or can be empty. This message can be
unknown or incorrect. The timer T9110 is started to supervise the reception of the HANDOVER
REQUEST. The SCCP CON REQ has no error, thus the connection is confirmed.
The DT1 message is sent with the first segment of the HANDOVER REQUEST. Treassembly is
started on receipt of DT1 message. The segmenting/reassembling parameter which contains the bit M
indicates that there is more data to be received.
The DT1 message is sent with the second segment of the HANDOVER REQUEST. The
segmenting/reassembling parameter which contains the bit M indicates that there is more data to be
received. The DT1 messages containing second and subsequent segments of HANDOVER
REQUEST message is ignored by SCCP.
The DT1 message is sent with the last segment of the HANDOVER REQUEST. The
segmenting/reassembling parameter which contains the bit M indicates that there is no more data to
be received. Treassembly is stopped. The first DT1 message containing the mandatory parts and
GSM optional parts of the HANDOVER REQUEST is passed to the higher layer (i.e. BSSAP). No extra
data of the HANDOVER REQUEST is stored by the BSC. The timer T9110 is stopped.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
68/120

The HANDOVER REQUEST received from an UMTS network may be longer than 255 octets and may
require segmentation. The maximum size of the message is 2000 octets, in this version of the BSS.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
69/120

Note:
3.2.4.4
The current release of the BSC implements only a reduced version of SCCP reassembly. Only the
first part of segmented message is taken into account. The MSC should normally send all mandatory
IEs of HANDOVER REQUEST message within this first part, and the BSC will get all necessary
information for the handover. Otherwise, it means that the MSC did not send the IEs in the proper
order, and the BSC is then allowed to reject the HANDOVER REQUEST message.
SCCP Reassembly Failure
After receipt of a segmenting/reassembling parameter which contains the bit M indicates that there is more
data to be received, if T9110 expires, the SCCP connection is released.
Target BSC
ECC
MSC
SCCP
<------------------------------------------------------------
<-------------Start T9110
------------->
SCCP CON CONF
------------------------------------------------------------>
Start
Treassembly
DT1(HANDOVER REQUEST part 1)

<-------------------------------------------------------------
(1)
Treassambly
expiry
(2)
T9110 expiry
:
------------->
SCCP RELEASED
------------------------------------------------------------->
SCCP RLC
<-------------------------------------------------------------<--------------
1
2
Fig 3/14 SCCP Release after T9110 expiry

The timer Treassembly expires. The DT1 message containing the first part of the HANDOVER
REQUEST is ignored by SCCP.
ED 07
The timer T9110 expires and the SCCP is released.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
70/120

3.2.4.5
Target BSS errors
The section 3.2.4.8 "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.
The current 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.
Target BSC
(1)
MSC
SCCP CON REQ
<------------------------------------------------------------
SCCP
CON
CONF
------------------------------------------------------------>
(2)
(3)
1
2
3
HANDOVER REQUEST
<-----------------------------------------------------------Start T9110
HANDOVER
FAILURE
---------------------------------------------------------------->
Fig 3/15 HO Request Error Behaviour

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 3.2.4.8.
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.6
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 3.2.4.8).
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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
71/120

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.[13].
Target BSC
(1)
MSC
SCCP CON REQ
<------------------------------------------------------------
SCCP
CON
CONF
------------------------------------------------------------>
(2)
(3)
HANDOVER REQUEST
<-----------------------------------------------------------Start T9110
(4)
HANDOVER
FAILURE
---------------------------------------------------------------->
BLOCK
------------------------------------------------------------>
BLOCK ACK
<---------------------------------------------------------------
1
2
3
Fig 3/16 HO Request on Unavailable Circuit

The HANDOVER REQUEST is sent by the MSC.

The target BSS detects that the A interface circuit is not usable in the target BSS, so an
HANDOVER FAILURE message is sent (for cause values see section 3.2.4.8).
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.[13] for more information.
3.2.4.7
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 3.2.4.8).
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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
72/120

The following message sequence chart shows the procedure when the target BSS is operating in GSM
Phase 2 mode on A interface and UNEQUIPPED CIRCUIT message is allowed to be sent by the target
BSS.
Target BSC
(1)
MSC
SCCP CON REQ
<------------------------------------------------------------
SCCP
CON
CONF
------------------------------------------------------------>
(2)
(3)
HANDOVER REQUEST
<-----------------------------------------------------------Start T9110
(4)
1
2
3
4
HANDOVER
FAILURE
---------------------------------------------------------------->
UNEQUIPPED
CIRCUIT
---------------------------------------------------------------->
Fig 3/17 HO Request on Unequipped Circuit

The HANDOVER REQUEST is sent by the MSC. 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 signaling; in the target BSS, so an HANDOVER FAILURE message
is sent (for cause values see section 3.2.4.8).
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.[13] for more detail.
3.2.4.8
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.[17].
Event
Actions
OIE CIC is present
Send HANDOVER FAILURE (cause "Protocol error between

MSC and BSC") - ref.[8] EHT0600
Start T9110
Next state (WAIT MSC RESP).
Table 3/18 Specific checking for ECC towards SDCCH
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
73/120

OIE CIC is not present

Start T9110
OIE CIC is present but indicates

timeslot 0
Send HANDOVER FAILURE (cause Requested terrestrial

resource unavailable) ref.[8] EHT0705
Start T9110
OIE CIC is present but is

unavailable
due
to
O&M
intervention
Send HANDOVER FAILURE (cause "Requested terrestrial

resource unavailable") - ref.[8] EHT0603
Initiate a Blocking procedure, if there is not a procedure in
progress for the indicated CIC
Start T9110
Next state (WAIT MSC RESP)
OIE CIC is present but is

unavailable due to its use in
another connection
Send HANDOVER FAILURE (cause "Terrestrial resource

already allocated") - ref.[8] EHT0604
Start T9110
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
Send HANDOVER FAILURE (cause "BSS not equipped") ref.[8] EHT0605

Send UNEQUIPPED CIRCUIT message - See Note 1
Start T9110
MIE Channel Type octet 3

indicates data & octet 4 indicates
half rate or a non supported data
rate
Send HANDOVER FAILURE (cause "Requested transcoding/

rate adaptation unavailable") - ref.[8] EHT0602
Start T9110
The BSC recognizes no code point

for a codec, amongst all proposed
in MIE Channel Type octet 5.
Send HANDOVER FAILURE (cause "Requested speech

version unavailable") - ref.[8] EHT0620
Start T9110
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
74/120

Requested codecs in MIE Channel

Type octet 5 do not match any
codec allowed in the cell
Send HANDOVER FAILURE (cause "Requested speech

version unavailable") - ref.[8] EHT0620
Start T9110
Note 1:
Table 3/19 Specific checking for ECC towards TCH

The UNEQUIPPED CIRCUIT message is sent only if enabled by O&M parameter
(EN_UNEQUIPPED_CIRCUIT) - see ref.[13] for more detail.
MIE 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.[8]

EHT0601
Start T9110
Note 1:
Table 3/20 Specific checking for Single Cell BSS

If this IE is not present for a Single cell BSS then it is accepted.
MIE Cell Identifier (Target) is not

present

Start T9110
MIE Cell Identifier (Target) is

present but does not match one
known to the BSS
Send HANDOVER FAILURE (cause "Invalid cell") - ref.[8]

EHT0601
Start T9110
Table 3/21 Specific checking for Multi-Cell BSS
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
75/120

MIE Channel Type combination

not supported - See Note 2

MSC and BSC") - ref.[8] EHT0600;
Start T9110
MIEs
Encryption
Info
or
Classmark Info or Cell Identifier
(serving) is missing - See Note 3
Send HANDOVER FAILURE(cause "Protocol error between

Start T9110
OIE Radio Channel Identity is

present
Ignore IE
OIE Interference Band is present
Ignore IE
MIE Encryption Information field

Permitted algorithms is coded
"00000000" - see Note 1

Start T9110
MIE
Encryption
Information
Length field value is more than 9
(key length is more than 8 octets)
Send HANDOVER FAILURE (cause "Incorrect value") ref.[8] EHT0607

Start T9110
If at least one encryption algorithm

is allowed and cipher key is not
present (MIE Encryption Info has
a length of 1)
Send HANDOVER FAILURE (cause "IE or field missing") ref.[8] EHT0608

Start T9110
One
of
OIEs
Group
Call
Reference and Talker Flag is
present while the other one is not
absent.
Send HANDOVER FAILURE (cause "IE or field missing") ref.[8] EHT0600 (see Error! Reference source not found.)
Start T9110
Note 1:
Note 2:
Note 3:
ED 07
Table 3/22 General Message Checking

This coding is not allowed by 3GPP. Note "00000001" is used to indicate No encryption.
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.
In intersystem handover from UTRAN or cdma2000, the Serving Area Identity, SAI, is the cell
identifier which is used to identify the Serving Area of UE.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
76/120

OIE Classmark 3 is missing (1)

MSC
and
BSC")
ref
[8]
EHT0600;
start T9110
next state (WAIT MSC RESP)
The support of BCCH band of

target cell is not indicated in
Classmark 3 (2)

MSC and BSC") - ref [8] EHT0600
Start T9110
next state (WAIT MSC RESP)
Table 3/23 Specific checking for UMTS to GSM HO

Note 1: In case of UMTS to GSM handover, the Classmark 3 IE is mandatory to decode the power
capabilities of the MS.
Note 2: See ref. [Classmark Handling].
The
OIE
Chosen
Encryption Algorithm
(Serving) is present
but
indicates
an
encryption
algorithm
not permitted in MIE
Encryption Info.
if current encryption
algorithm (found in
OIE
Chosen
Encryption Algorithm
(Serving))
is
not
permitted in the cell

Start T9110
(The BSC does not allow this handover to occur as
Phase 1 MS cannot change its encryption algorithm
during a handover)
Start T9110
(The BSC does not allow this handover to occur as
Phase 1 MS cannot change of encryption algorithm)
Table 3/24 Ciphering Checks - GSM Phase 1 MSs and phase 1 extended
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
77/120

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.[16])
Send HANDOVER FAILURE (cause "Ciphering algorithm not

supported") - ref.[8] EHT0606
Start T9110
Table 3/25 Ciphering Checks - MS & BTS Capabilities & MSC Requirements
(With exceptions as shown in Table 3/24)
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
unsuccessful
allocation
an
CIC
Send HANDOVER FAILURE (cause "Requested terrestrial

resource unavailable") - ref.[8] EHT0701
Start T9110
Table 3/26 Unsuccessful CIC allocation

if the CIC allocation is successful (TCH only) a request is made to allocate an RF resource ref.[11].
if there is an internal
BSC
problem
allocating
the
RF
channel
If a CIC has been allocated then CIC state is made FREE

send HANDOVER FAILURE (cause "No radio resource
available") - ref.[8] EHT0702
Start T9110
Next state(WAIT MSC RESP)
If
the
cell
unavailable due
O&M
is
to

send HANDOVER FAILURE (cause "O&M intervention") ref.[8] EHT0704
Start T9110
if incoming handover is
inhibited in the cell
(EN_IC_HO is set to
FALSE) and this is an
intercell handover

send HANDOVER FAILURE (cause "O&M intervention") ref.[8] EHT0704
Start T9110
Table 3/27 Other error cases
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
78/120

3.2.4.8.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 an incoming external directed retry to
a full rate channel for speech version 1, for a phase 1 MS:
OIE Cause (if present) is "directed retry" AND Channel Type is "full rate speech version 1" (*) AND MS
revision level is "Phase 1"
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"
(*) : 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 is received, it
is discarded.
3.2.4.8.2
Distinction between emergency or better cell handover
When the incoming request is an external handover, according to the OIE Cause value in the HANDOVER
REQUEST message, ECC decides if it has to be treated as an emergency handover or a better cell
handover within RAM (see ref.[11] for more details). ECC sends a Select Channel message to RAM
requesting for an emergency EHO or a better cell EHO (see section 4.2.2).
In the Handover Request, the typical cause values are:
uplink quality;
uplink strength;
downlink quality;
downlink strength;
distance;
better cell;
response to MSC invocation;
O and M intervention;
directed retry;
switch circuit pool;
traffic;
preemption;
reduce load in serving cell.
If the OIE Cause in HANDOVER REQUEST message contains the following cause value, an emergency
external handover is processed:
Uplink quality
Uplink strength
Downlink quality
Downlink strength
Distance
The other possible cause values on A interface are considered by ECC as better cell external handover.
If the external handover comes from UTRAN and if the OIE Cause in HANDOVER REQUEST message
contains one of the following causes:
Uplink quality
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
79/120

Uplink strength
Downlink quality
Downlink strength
Distance
then the handover is regarded as an emergency handover.
The other causes are considered as better cell external handover by ECC.If the OIE Cause is not present in
the HANDOVER REQUEST message, ECC requests to RAM a better cell EHO.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
80/120

3.2.4.8.3
Distinction of pre-emption requirement
The HANDOVER REQUEST may contain:
the priority IE, including 2 different pre-emption indicators, set by the MSC:
pvi (pre-emption vulnerability indicator, GSM Phase 2; previously called pe, pre-emption
allowed indicator in GSM Phase 1), which is stored in the call context and used by RAM to
find a resource to be released when pre-emption procedure is triggered (see ref.[10] for more
details).
pci (pre-emption capability indicator, GSM Phase 2), which indicates if the new incoming
request is allowed to trigger the resource pre-emption of an on-going call when no TCH is
available.
the Old BSS to New BSS Information IE, including in the Extra information field a pre-emption
recommendation set by the serving BSC:
prec (pre-emption recommendation, GSM Phase 2)
When the incoming request is an external TCH handover or an external directed retry, according to the OIE
Priority and the OIE Old BSS to New BSS Information in the HANDOVER REQUEST message, ECC
decides if pre-emption procedure shall be triggered within RAM. ECC sends a Select Channel message to
RAM with pre-emption indicator set to 1 (i.e. pre-emption of an on-going call is allowed if no TCH is
available) in the following cases:
when EN_TCH_PREEMPT flag is set to enable, and pci = 1, and Extra information field (i.e. prec bit) is
not present
when EN_TCH_PREEMPT flag is set to enable, and pci = 1, and prec = 1
Otherwise (e.g. EN_TCH_PREEMPT is set to disable, or Priority IE is missing, or pci = 0, ), ECC sends a
Select Channel message to RAM with pre-emption indicator set to 0 (i.e. pre-emption is not allowed).
Note:
3.2.4.9
ECC provides also in Select Channel message sent to RAM the queuing authorization and the
queuing timer T_qho value if queuing is allowed by the MSC. If pre-emption is not possible in RAM
(e.g. no lower priority pre-emptable call), the request remains in the queue or not according to the
queuing authorisation provided by ECC to RAM.
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

O&M PARAMETERS and FLAGS:
DTX-INDICATOR, DTX-INDICATOR_SACCH, DTX_INDICATOR_SACCH_AMR
BS_TXPWR_MAX
MS_TXPWR_MAX
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
81/120

DOWNLINK_DTX_ENABLE_FR, DOWNLINK_DTX_ENABLE_HR,
DOWNLINK_DTX_ENABLE_AMR_FR, DOWNLINK_DTX_ENABLE_AMR_HR,
EN_AMR_FR, EN_AMR_HR
AMR FR speech call: AMR_FR_SUBSET, AMR_START_MODE_FR, AMR_FR_THR_i (i = 1, 2, 3),

AMR_FR_HYST, FORBID_AMR_NS
AMR HR speech call: AMR_HR_SUBSET, AMR_START_MODE_HR, AMR_HR_THR_i (i = 1, 2, 3),

AMR_HR_HYST, FORBID_AMR_NS
EN_TFO, EN_TFO_MATCH, EN_TFO_OPT, FORCE_TFO_VS_AMR and T_TFO
Information Element
Info field
MIE Channel number

MIE Activation Type
Main channel
Indicates the RF Channel allocated by the resource
allocation manager - see ref.[11]
R
A3, A2
A1
Set to Initial activation

Set to Activation related to
inter-cell channel change
Asynchronous ECC :
Set
to
Related
to
asynchronous
handover
procedure
Synchronous ECC :
MIE Channel Mode
DTXd
Set
to
Related
to
synchronous
handover
procedure
If FORBID_DTXD_NH_BCCH_F is set to TRUE and the
allocated TCH is non-hopping and belongs to the BCCH
TRX, DTXd shall be set to 0 (i.e. DTXd is not applied)
Otherwise see ref.[20].
DTXu
Speech or
data indicator
ED 07
See ref.[20].
Set equal to octet 3 of the MIE Channel Type in the
HANDOVER REQUEST message.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
82/120

Information Element
Info field
Channel rate
and type
Main channel
If speech or data indicator indicates "signaling" :
set to SDCCH
Else
set to "Full rate TCH channel Bm" or "Half rate TCH
channel Lm", depending on the radio resource allocation
procedure (see ref.[11])
Speech coding
algo / data rate
+ transp. ind.
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.
MIE Channel
Identification
The Channel Identification IE contains the 04.18 Channel

Description & 04.18 Mobile allocation for the activated
channel.
Only the training sequence code (TSC) of the Channel
Description field is computed by the BTS. The BTS does not
use the Mobile Allocation field (see Note 3).
The Channel Description field use in this message may be
used in the building of the HANDOVER COMMAND
message
OIE Encryption
Information
ED 07
Always sent.
The setting is as specified in ref.[11 & 16]
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
83/120

Information Element
CIE Handover
Reference
Info field
Main channel
This
IE
is
included
for
this
procedure
It is calculated by the target BSC and should be randomly
generated.
The BTS uses this value to compare with the value in the
HANDOVER ACCESS when the MS performs the handover
access procedure
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.
Not used
CIE Timing Advance
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.
OIE BS Power
Parameters
Not used.
OIE MS Power
Parameters
Not used.
OIE Physical Context
Not used.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
84/120

Information Element
OIE SACCH
Information
Info field
Main channel
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.
If present, it updates the system information previously
intended to be transmitted. see ref.[17]
Extended measurement order message is included for a

TCH channel activation
if MAFA is supported in the BSS (EN_EXT_MEAS_REP)
and if the MS is GSM phase2
OIE main channel

reference
OIE Multirate
Configuration
OIE MultiRate
Control
ED 07
and if a RMS job is running (see ref.[14]).

Not used.
Included in case of the target channel type is AMR FR or

AMR HR (EN_AMR_FR, resp. EN_AMR_HR, = TRUE on
target cell).
Contains the initial codec mode, the codec subset and, if
more than one codec is defined, thresholds and hysteresis
used by the BTS for the uplink codec adaptation. It contains
also the indication to allow or forbid use of AMR Noise
Suppressor.
Not used.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
85/120

Information Element
OIE TFO Command
Info field
Main channel
Alcatel proprietary IE.
Included if the target channel is TCH for a speech call, when
EN_TFO=Enabled.
Field EN_TFO is either set to EN_TFO flag when the

active codec type (i.e. chosen channel rate and speech
version in Channel selected message received from
RAM) is HR, FR, EFR or set to FORCE_TFO_VS_AMR
flag when the active codec type is AMR, or set to 0 if the
codec list is empty (see note 2).
Field TFO_MATCH is set to EN_TFO_MATCH flag.
Field TFO_OPT is set to EN_TFO_OPT flag.
Field T_TFO contains the value of the timer T_TFO.
Field TFO Codec contains the TFO codec type received
in Channel selected message from RAM.
It is set to 0xFF when EN_TFO field is set to FALSE.
For the coding of this IE see ref.[24].
OIE Supported
Codec Types
Included for speech calls, and when the field EN_TFO in OIE
TFO Command is set to TRUE.
Field Codec List indicates, as received from RAM in

Channel Selected message, a list of codecs:
- supported by the target cell
and - allowed by the operator (via O&M)
and - allowed by the MSC (in the HANDOVER
REQUEST)
Field Preferred Codec is not used (set to 0xFF).
Note 1:
Note 2:
Note 3:
ED 07
Table 3/28 Channel Activation Message

For this release the Alcatel BSS only supports data calls on full rate channels with 12Kbit/s rate
adaptation
In some rare cases, the codec list may be empty (e.g.: request DR_P_NCA, AMR FR, AMR HR,
FR as possible codecs, FORCE_TFO_VS_AMR = 1, chosen codec is AMR HR)
In the case of resource allocation in the inner zone of a multiband cell or in the EGSM band (and
not in the PGSM band), the Mobile Allocation field is not correctly filled by the BSC.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
86/120

3.2.4.10 HANDOVER REQUEST ACK message construction

Once the channel has been successfully activated (i.e. 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 section 3.2.4.11 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
algorithm
Encryption
OIE Speech Version (chosen)

OIE Circuit pool
This IE is sent with the value of the ciphering algorithm used by

the BSC.
This IE is included when the target BSS made the choice of the
codec to use, among more than one given by the MSC.
Not used
Not used
OIE Circuit Identity Code
Not included.
OIE LSA Identifier
Table 3/29 HANDOVER REQUEST ACK Message:
3.2.4.11 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 P-GSM range.
Information element
MIE Cell description
Set NCC, BCC & BCCH ARFCN (High & Low part) to the
values allocated to the target BTS.
MIE Description of 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
Access type
ED 07
command
and
Set
to
MIN(P,
MS_TXPWR_MAX
target
cell)
Field Access type is set to "sending of HANDOVER ACCESS
is mandatory"
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
87/120

Information element
OIE Synch info
Phase 1 MS: This IE is always included as required in GSM

ETR 09.94 (see ref.[7]).
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
Phase 2 biband (supporting GSM900) MS:

Used when the target channel is hopping (i.e. more than 1
frequency), and if it is the shortest way of coding the
frequencies: see note 1.
CIE Frequency list, after time
Phase 2 biband (supporting GSM900) MS:

CIE Cell Channel Description
Phase 1 monoband P-GSM MS or Phase 2 monoband PGSM or E-GSM MS:

Used when CIE Frequency Channel Sequence, after time
can not code all the frequencies used.
Used with CIE Mobile Allocation, after time to describe
frequency hopping sequence.
CIE Description of the multislot

configuration
Not used (used only in multislot configurations)
OIE Mode of the first channel

(channel set 1)
Always used. See note 3.

Not used
Mode of channel set 2

Not used
Not used
Not used
Not used
Not used

OIE Channel description of the
second channel
ED 07
Not used
Not used - relevant to Lm + Lm.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
88/120

Information element
OIE Mode
channel
of
the
CIE
Frequency
sequence, after time
second
channel
Not used - relevant to Lm + Lm.
Phase 1 monoband P-GSM MS or Phase 2 monoband PGSM or E-GSM MS:

frequency) and if this IE can code all the frequencies.
Phase 2 biband (supporting GSM900) MS :
Used when the target channel is a P-GSM channel and is
hopping (i.e. on more than 1 frequency), and if it is the
shortest way of coding the frequencies: see note 1.
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
Phase 1 monoband P-GSM MS or Phase 2 monoband PGSM or E-GSM MS :

Used only if CIE Cell Channel Description is used.
Not used (used during Frequency redefinition).
OIE Starting time

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

CIE Frequency short list, before
time
Not used (Used for Pre-synchronous handover)

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).
CIE
Frequency
sequence, before time
channel

to Phase 2 MSs).
CIE Mobile allocation, before

time

to Phase 2 MSs).
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
89/120

Information element
OIE Cipher mode setting
Never sent to Phase 1 MSs.

GSM Phase 2 MSs :
Case of a 3G to 2G handover : always sent
Case of a 2G to 2G handover : See table xxx below.
See ref.[16].
OIE
VGCS
Indication
target
mode
OIE Multirate Configuration
Not used
Included in case of target channel type is AMR FR or AMR

HR (EN_AMR_FR or EN_AMR_HR = TRUE) except if the
AMR parameters are identical to the ones used on the
serving BSC. See Note 4.

used by the MS for the downlink codec adaptation on the
target cell. It contains also the indication to allow or forbid
Note 1:
Table 3/30 Handover Command Message towards a P-GSM channel

For phase 2 biband (supporting GSM900 band) MSs and when the target channel is hopping (i.e.
on more than 1 frequency), the shortest frequency encoding IE will always be used. See ref.[21] for
the frequency encoding algorithms.
When the target channel is in the P-GSM band, the choice will be made between the following
CIEs:
- Frequency Channel Sequence, after time,
- "Frequency Short List, after time"
- "Frequency List, after time".
HANDOVER COMMAND (Inter-cell Synchronous & Asynchronous) towards a EGSM (not in PGSM),
GSM850, DCS1800 or DCS1900 channel.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
90/120

Information element
MIE Cell description
Set NCC, BCC & BCCH ARFCN (High & Low part) to the
values allocated to the target BTS
MIE Description of the First

Channel, 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
Access type
command
and
OIE Synch info
Set
to
MIN(P,
MS_TXPWR_MAX
target
cell)
Field Access type is set to "sending of HANDOVER ACCESS
is mandatory"
Phase 1 MS: This IE is always included as required in 3GPP
ETR 09.94 (see ref.[7]).
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

CIE Frequency list, after time

Not used.
CIE Cell channel description

CIE Description of the multislot
configuration
OIE Mode of the first channel
(channel set 1)
Not used (used only in multislot configurations)
Always used. See note 3.

Not used

Not used
Not used
Not used
Not used
Not used
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
91/120

Information element
Not used
OIE Description of the second

channel
Not used - relevant to Lm + Lm
OIE Mode
channel
second
Not used.- relevant to Lm + Lm
channel
Not used.
of
the
CIE
Frequency
sequence, after time
CIE Mobile Allocation, after time

OIE Starting time
CIE Real time difference
Not used.
Not used (used during Frequency redefinition).
Not used (Used for Pseudo synchronous handover)
CIE Timing advance
Not used (Used for Pre-synchronous handover)
CIE Frequency short list, before

time
CIE Frequency list, before time

to Phase 2 MSs).
to Phase 2 MSs).

first channel, before time

to Phase 2 MSs).

second channel, before time
channel

to Phase 2 MSs).
to Phase 2 MSs).
CIE Mobile allocation, before

time

to Phase 2 MSs).
CIE
Frequency
sequence, before time
OIE Cipher mode setting
Never sent to Phase 1 MSs.

GSM Phase 2 MSs :
Case of a 3G to 2G handover : always sent
Case of a 2G to 2G handover : See table xxx below.
See ref.[16].
OIE
VGCS
Indication
ED 07
target
mode
RELEASED
Not used

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
92/120

Information element
OIE Multirate Configuration
Included in case of target channel type is AMR FR or AMR

HR (EN_AMR_FR or EN_AMR_HR = TRUE) except if the
AMR parameters are identical to the ones used on the
serving BSC. See Note 4.
used by the MS for the downlink codec adaptation on the
target cell. It contains also the indication to allow or forbid
Table 3/31 Handover Command Message towards an EGSM (not PGSM)GSM850, DCS1800 or DCS1900
channel
Note 2:
Note 4:
When the target channel is in the EGSM band (and not in the PGSM band), the GSM850 band, the
DCS1800 band or in the DCS1900 band, the choice will be made between the following CIEs:
- "Frequency Short List, after time"
- "Frequency List, after time".
Note 3: Although according to 3GPP, OIE Mode of the First Channel (Channel Set 1) is
mandatory only when the channel mode is changed, it is always sent by the Alcatel BSS,
because some MSs do not behave correctly when it is missing (in particular during handovers
from AMR FR to AMR HR and vice-versa).
The target BSC may be aware of the AMR parameters on the serving cell by analysing OIE Old
BSS to New BSS information received in the HANDOVER REQUEST message.
If the OIE Old BSS to New BSS information was not received in the HANDOVER REQUEST
message, the OIE Multirate Configuration is included in HANDOVER COMMAND message.
In the building of the HANDOVER COMMAND message the synchronization indication tells the mobile which
type of protocol is to be performed on the Radio interface. In the case where the Synchronization 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.
Cipher
mode
algorithms
proposed
by the MSC
Ciphering
algorithm
used in the serving cell
Ciphering
algorithm
chosen in the target
cell
Decision
on
OIE
Cipher Mode Setting
No choice
Any value
Any value
Not sent
Several choices
Unknown
Any value
Sent (possibly with

Start
ciphering
+
chosen algorithm)
Several Choices
Known
Equal to Ciphering
algorithm used in the
serving cell
Not sent
Several Choices
Known
Different
Ciphering
Sent
(with
ciphering
+
ED 07
RELEASED
from
algorithm
start
new

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
93/120

used in the serving cell
chosen algorithm)
Table 3/32 Rules for sending Cipher Mode Setting IE in case of a 2G-2G handover
3.2.4.12 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.
3.2.4.13 DTAP & BSSMAP 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 (i.e. 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.
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.4.14 Filtering of Connection Failure Indication message
By the BTS:
Before the transcoder is synchronised with the BTS, transcoder alarms will be detected in the BTS. While
T_CFI_TR is running in the BTS, these alarms will be filtered out by the BTS.
If T_CFI_TR is not running in the BTS, the BTS sends to the BSC a CONNECTION FAILURE
INDICATION (cause remote transcoder failure) message every T_SYNC.
By the BSC:
Before receiving the HANDOVER COMPLETE message, the BSC discards all received CONNECTION
FAILURE INDICATION (cause remote transcoder failure).
3.2.5
Target BTS asynchronous channel change protocol
Once the channel is activated the target BTS immediately starts the ciphering (if applied) of any frames sent
to the Radio interface.
The target BTS can only decode access bursts coming in from the Radio interface whilst it is awaiting the
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
94/120

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 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/33 BTS States - Asynch HO
STATE
AWAIT HO ACC
AWAIT SABM or
ANY CORRECT
FRAME
T_CFI_TR
RUNNING
ACTIVE
Don't care
N/A
N/A
EVENT
HANDOVER
ACCESS
Note 3
Decipher (if applied)

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/34 Target BTS State Table - Asynch HO
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
95/120

STATE
AWAIT
HO ACC
AWAIT SABM or ANY

CORRECT FRAME
N/A
Stop T3105
T_CFI_TR
RUNNING
ACTIVE
EVENT
DL ESTAB IND
Start
alg
BTS Layer 2 ->

BTS Layer 3 or
any
correct
frame
Radio-link
fail
Send EST INDIC
Stop T_CFI_TR
Start T_CFI_TR
Start T_CFI_TR
Next
state
(T_CFI_TR_RUNNI
NG)
Note 1
Note 1
Start T_CFI_TR
Note 4
T3105 EXPIRY
N/A
Next
state
(T_CFI_TR_RUNNIN
G)
When X == NY1
N/A
N/A
Send CONN FAIL

IND (cause "HO acc
fail")
Send DL REFUSE
REQ, see Note 5
Next state (ACTIVE)
When X < NY1
X=X+1
Send PHYS INFO in
unack mode
Start T3105
T_CFI_TR
N/A
N/A
Next
state
(ACTIVE)
EXPIRY
Remote
transcoder
alarm
N/A
N/A
Note 1
Note 1
Send CONN FAIL IND
(Remote transcoder
failure)
Discard
Note 1
Send CONN FAIL

IND
(Remote
transcoder failure )
Note 1
Note 1:
Note 2:
ED 07
Table 3/35 Target BTS State Table - Asynch HO (Cont)

These states and actions are also in the serving BTS.
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.[10] for BS Power control inhibition.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
96/120

Note 3:
Note 4:
Note 5:
3.2.6
Only a correct HANDOVER ACCESS will be accepted. Any incorrect HANDOVER ACCESS will be
discarded.
The event which will be accepted at this point will depend on the T3105_D_STOP or
T3105_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 T3105 to be stopped. In both cases, only SABM
SAPI 0 will cause the sending of ESTABLISH INDICATION.
The Layer 2 LAPDm Refuse option is set at this point. Note this feature is an ALCATEL BTS
feature and is not specified in 3GPP.
Target BTS synchronous channel change protocol
Once the channel is activated the target BTS immediately starts the ciphering (if applied) of any frames sent
to the Radio 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 Radio interface whilst it is awaiting the
The target BTS should exhibit the following behaviour during a synchronous external or synchronous internal
handover procedure.
A list of logical BTS states is shown below.
STATE DESCRIPTION
ABBREVIATION
The Channel is activated and the BTS is awaiting the

HANDOVER ACCESS from the MS
INTRA AWAIT HO ACC
The BTS is awaiting for either the SABM SAPI 0 or any

correct frame from the MS. The timer T3106 is running.
INTRA AWAIT SABM or

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 for the procedure,

after the end of a successful access by the MS
ACTIVE
Table 3/36 BTS States - Synch HO
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
97/120

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
Don't care
N/A
N/A
EVENT
HANDOVER
ACCESS
Send
DETECTION
HANDOVER
Calculate TA
Set TA in Layer 1 header &
TA Algorithm
Start T3106
Next state (INTRA AWAIT
SABM or ANY CORRECT
FRAME)
INCORRECT
HANDOVER
ACCESS
Don't care
DL
ESTAB
IND
BTS Layer 2 ->
BTS Layer 3 or any
correct frame - see
Note 1
Don't 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)
N/A
N/A
Start T_CFI_TR
Next
(ACTIVE)
T3106 EXPIRY
N/A
state
Send DL-REFUSEREQ
Send CONN FAIL
IND (HO acc fail)
next state(ACTIVE)
T_CFI_TR EXPIRY
N/A
N/A
Next state
(ACTIVE)
N/A
Remote transcoder
alarm(TCH only)
N/A
Send CONN FAIL

IND
(Remote
transcoder alarm)
Don't care
Send CONN
FAIL
IND
(Remote
transcoder
alarm)
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
98/120

Note 1:
3.2.6.1
Table 3/37 Target BTS State Table - Synch HO

The event which will be accepted at this point will depend on 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.
BTS CHANNEL ACTIVATION message checking
See ref.[9]
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 GSM 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 PLMN colour code matches with
the coding in the NCC Permitted IE transmitted to the MS in the SYSTEM INFORMATION TYPE 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 3GPP does not allow inter PLMN handovers.
If the MS also received MEASUREMENT INFORMATION message, it may report less than 6 GSM cells.
For UMTS neighbour cells the MS reports (up to 3 UMTS cells but may measure more of the UMTS
neighbour cells found in the MEASUREMENT INFORMATION message):
the Scrambling code & the UMTS ARFCN;
the Ec/No quantity (according to MEASUREMENT INFORMATION FDD REPORTING QUANTITY

IE).
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 synchronization and TDMA timing
of all the cells which it is measuring. These measurements are used to ensure quick synchronization with the
target cell when required.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
99/120

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 or INTERSYTEM TO UTRAN
HANDOVER COMMAND message.
Attaching to the target cell
This process provides the synchronization to the new cells TDMA frame synchronization, 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-synchronization 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 or
INTERSYTEM TO UTRAN 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
synchronization, timing and the SYSTEM INFORMATION 5 & 6 for use if the procedure fails.
3.2.7.4
Attaching To The Target Cell
This section does not apply to a UMTS target cell.

The attaching procedure to the target cell, involves the synchronization 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
synchronization to the target cell to be made quicker.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
100/120

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 provide the
tuning to the carrier frequency. This process may take up to 460 ms to find the first FCCH burst and
there after the time will depend on the MS's phase lock loop performance.
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
synchronize 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 synchronization 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 synthesizer 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 synchronized.
When the MS has no information as to the synchronization of the target cell, the procedure is likely to be
slow.
Once the MS has synchronized 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
This section does not apply to a UMTS target cell.

The attaching procedure for asynchronous handover to the new channel (indicated by the Channel
Description IE in the HANDOVER COMMAND) consists of:
1
ED 07
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
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
101/120

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
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 the handover procedure is
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
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 the handover procedure is
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 synchronization and TDMA frame numbering.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
102/120

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;
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 with Other Procedures
3.3.1
External channel change & Ciphering Procedures
The MSC is responsible for the synchronization of the Ciphering and external channel change procedures.
In cases where a Ciphering procedure is in progress the MSC will ensure that this procedure finishes before
the initiation of the external channel change 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.[16] 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
3.3.2.1
External channel change & Internal channel change Procedures

Serving BSC
If the BSC is in the process of performing an internal channel change procedure and a HANDOVER
COMMAND is received from the MSC. The BSC will respond by sending a HANDOVER FAILURE with the
cause "radio interface failure, reversion to old channel".
An external channel change procedure may be triggered following the failure of an internal channel change
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.[23].
Note that for the case of queuing MSCs, all inter-cell internal channel change must be forced to be external,
except for VGC talker handover, for a good interworking.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
103/120

3.3.2.1.1
Internal channel change after External channel change
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 (i.e. internal or
external) and only external handovers will be performed until the BSS is sure that the handover procedure is
terminated in the MSC, i.e.:
If the MSC has not sent a HANDOVER REQUIRED REJECT message - the expiry of
T_HO_REQD_LOST.
HANDOVER COMMAND has been received from the MSC.
3.3.2.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.2.2.1
Subsequent Internal handover after successful External channel change 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 channel changes.
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.2.2.2 Subsequent Internal handover after successful External channel change 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.
Permitted Algorithm
Setting
Internal handover behaviour
No Encryption
Only non ciphered handovers will be performed
A5/X, Y
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.
A5/X,
Y
encryption
&
No
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.
Table 3/38 Permitted Algorithm Options
3.3.3
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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
104/120

3.3.4
External channel change & 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.5 External channel change & MS And BS Power Control
During external channel change the BSS is required to trigger the starting of MS & BS power control
algorithms as described in ref.[10].
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.[10].
3.3.5.1 Serving BSC during External channel change
The serving BSC does not inhibit the MS or BS Power control algorithm during external channel changes.
During the period where the MS is not on the serving cell the Algorithms operate as described in ref.[10].
3.3.5.2
Target BSC during External channel change
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.6
Handover algorithm & External channel change protocols
Handover preparation and external channel change entity are link by handover management entity, ref.[23].
There is no direct interaction between handover preparation and external channel change.
3.3.7
Handover management and External channel change protocols
External channel change procedure is triggered by handover management entity, which decides to trigger an
external handover or an external directed retry following one of these events:
Receipt of an alarm from handover preparation with new cells
Outcome of any channel change procedure,
Modification of cell list (with respect to rejected cells)

Expiry of T7
Handover management provides external channel change procedure with a filtered list of up to
N_PREF_CELLS candidate cells. If the candidate cell list is changed (new alarm), handover management
will immediately ask external channel change protocol to send a new HANDOVER REQUIRED to the MSC.
If the cell list does not change, handover management will ask to external channel change protocol to send a
new HANDOVER REQUIRED to the MSC each T7 expiry.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
105/120

4
4.1
INTERFACE DESCRIPTIONS
GSM interfaces / Physical interfaces
The following interface descriptions describe the messages specific to the external handover procedure.
Radio interface
CHANNEL MODE MODIFY
Target BSC -> MS
sent on FACCH for compliance with ref.[7].
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.
INTERSYTEM TO UTRAN HANDOVER COMMAND

Serving BSC -> MS (transparent to the BTS)
sent on main DCCH, initiates handover with the MS.
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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
106/120

CHANNEL ACTIVATION ACK

BTS -> BSC
Acknowledges successful activation of an RF channel.
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. The
target BSC sends it 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 (Radio)
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.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
107/120

HANDOVER REQUEST ACK

Target BSC -> MSC
Acknowledges the reservation and successful activation of an RF channel for the handover.
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
4.2.1
BSC internal entities
BSC
HOP
ICC
HOM
"Requestfor EHO"
"Request for EDR"
ED 07
ECC
RAM
"Select channel"
"Dequeue request"
Fig 4./1: BSC handover internal entities
Entities:
HOP:
"Channel selected"
"Select channel reject"
"Select channel queued"
"Exit and clear"

"HO FAIL from MS"
"Reject from MSC"
Handover Preparation
This entity is responsible of triggering handover alarms by checking continuously the radio
environment of the mobile (radio level, radio quality, possible target cells, traffic load, mullet-layer
network, etc.). The HOP behaviour is described in ref.[10].
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
108/120

HOM:
ICC:
ECC:
RAM:
ED 07
Handover Management
This entity is responsible of managing the channel changes depending on handover alarms sent by
the HOP entity, the O&M configuration of the BSS, the events arriving from the protocol entities,
etc. The HOM behaviour is described in ref.[23].
Internal Channel Changes

This entity is responsible of running the internal channel change protocol when the HOM asks for it.
ICC behaviour is described in Ref.[9]
This entity is responsible of running the external channel change protocol, either for an outgoing
external channel change when the HOM asks for it (serving BSC) or autonomously for an incoming
channel change (target BSC). The ECC behaviour is described in this document.
Resource Allocation and Management

This entity is responsible of managing the radio resources of the BSS. The RAM behaviour is
described in ref.[11].
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
109/120

4.2.2
BSC internal interfaces with external channel change

Direction
HOM-->ECC
Message
Request for EHO
Parameter or information
up to N_PREF_CELLS cells
HO cause associated to each cell
Request for EDR
up to N_PREF_CELLS cells
HO cause associated to each cell
ECC-->HOM
Reject from MSC

HO FAIL from MS
Target cell
Exit and clear

ECC--> RAM
Select channel
1) Reason for request (emergency EHO,

better cell EHO or EDR)
2) List of speech versions
3) TCH channel request type (DR FR P
CA, ... - ref.[7])
4) Queuing authorisation and the queuing
timer to be applied.
5) A interface Priority level and preemption
indicator
(see section 3.2.4.8.3)
6) MS
band
ability:
E-GSM
Not_Applicable (see Note)
or
Dequeue request
RAM-->ECC
Channel selected
Chosen channel type

Chosen speech version
If TFO is enabled, in case of speech calls
(except
if
FORCE_TFO_VS_AMR=FALSE
and
chosen codec type is AMR FR or AMR
HR):
TFO codec type
List of supported codec types
Select channel reject
Cause
If the cause is set to no radio resource
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
110/120

available and if the HO comes from

UTRAN:
Cell Load
Select channel queued
Table 4./1 : BSC internal interfaces with External channel changes

If the MS supports the G1 band, then the MS band ability is set to the value E-GSM. Otherwise
the MS band ability is set to the value Not_Applicable.
Note:
4.2.3
BTS internal interfaces
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
4.3
Internally detected alarm indicating that the transcoder is not attached, from
Layer 1 to BTS Layer 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.
T3105_F_FR
(FACCH)

the MS for FACCH connections on Full Rate channels.
T3105_F_HR
(FACCH)

the MS for FACCH connections on Half Rate channels.
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
Used to filter the internally detected transcoder alarm after RL ESTABLISH

INDICATION from the 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
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
111/120

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.
T_TFO
BTS & Transcoder timer. This timer is used in both entities to control the
acknowledgement of TFO messages between BTS and TRAU. Its value is provided by
the BSC to the BTS in CHANNEL ACTIVATION message.
BSC TIMERS
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. See ref.[23]
T8
Serving BSC timer. Supervises the handover with the MS, in case of GSM to GSM
handover.
T3121
Serving BSC timer. Supervises the handover with the UE/MS, in case of GSM to
UMTS handover.
T_HO_REQD_LOST
Serving BSC timer. This timer serves to guard against no response from the MSC
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. see
ref.[23]
Treassembly
Target BSC timer, at SCCP level. Controls the receipt of subsequent segments after
the receipt of the first segment of a segmented layer 3 message.
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 (started upon receipt of CONN_IND(SCCP_CON_REQ) not
carrying a HANDOVER REQUEST and stopped when a HANDOVER REQUEST is
received on the same SCCP connection as the SCCP_CON_REQ message). Guards
also the response of the MSC when a HANDOVER FAILURE has been sent (stopped
when a HANDOVER REQUEST or CLEAR COMMAND is received)
T9113
Target BSC timer. Supervises the handover with the MS.
T_qho
Target BSC timer. Determines the length of time the handover request is queued for.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
112/120

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
4.4
MS timer. Supervises the establishment of LAPDm on the target cell after reception of the
PHYSICAL INFORMATION.
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
AMR_FR_HYST
Hysteresis for AMR FR codec mode adaptation
AMR_FR_SUBSET
Bitmap (8 bits) defining the codec subset that shall be used for AMR FR (1 to
4 codecs)
AMR_FR_THR_i (i = 1, 2, 3)
Thresholds for AMR FR codec mode adaptation
AMR_HR_HYST
Hysteresis for AMR HR codec mode adaptation
AMR_HR_SUBSET
Bitmap (6 bits) defining the codec subset that shall be used for AMR HR (1
to 4 codecs)
AMR_HR_THR_i (i = 1, 2, 3)
Thresholds for AMR HR codec mode adaptation
AMR_START_MODE_FR
For AMR FR calls, indicates if the start mode is implicit or explicit and gives
the start mode when it is explicit.
AMR_START_MODE_HR
For AMR HR calls, indicates if the start mode is implicit or explicit and gives
the start mode when it is explicit.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
113/120

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.
CGI_3G_REQUIRED
When set TRUE, dictates that the encoding of 3G cell identifiers will use the
MCC and MNC encoding rules.
DOWNLINK_DTX_ENABLE
_FR
When set TRUE, the operator requires that downlink DTX be enabled for
TCH/FR channel with FR or EFR codec type.
DOWNLINK_DTX_ENABLE
_HR
TCH/HR channel.
DOWNLINK_DTX_AMR_EN
ABLE_FR
TCH/FR channel with AMR FR codec type.
DOWNLINK_DTX_AMR_EN
ABLE_HR
TCH/HR channel with AMR HR codec type.
DTX_INDICATOR
Indicates if DTX is to be used in the Uplink direction for GSM Phase 1 MS.
DTX_INDICATOR_SACCH
Indicates if DTX is to be used in the Uplink direction (AMR codec type

excluded) for GSM Phase 2 MS.
DTX_INDICATOR_SACCH_
AMR
Indicates if DTX is to be used in the Uplink direction with AMR codec type,
for GSM Phase 2 MS.
EDR_ASSIGN_FAIL_CAUS
E
Cause to be used ASSIGNMENT FAILURE message for outgoing external

directed retry
EDR_MSG_ORDER
Set the order of ASSIGNMENT FAILURE and HANDOVER REQUIRED sent

to the MSC for outgoing external directed retry.
EDR_SEND_ASSIGN_FAIL
Allow/forbid the sending of ASSIGNMENT FAILURE message for outgoing

external directed retry.
EFR_ENABLED
Enable/Disable EFR operation.
EN_AMR_FR
Enable / Disable Adaptive MultiRate speech codec (AMR) Full Rate calls.
EN_AMR_HR
Enable / Disable Adaptive MultiRate speech codec (AMR) Half Rate calls.
EN_EXT_MEAS_REP
Enable / Disable Extended Measurement Reports (MAFA).
EN_IC_HO
Enabled (= True): Intercell synchronous and asynchronous handovers may

be made into the cell.
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
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
114/120

Version in HANDOVER REQUIRED message.

EN_TCH_PREEMPT
When set ENABLED, the pre-emption procedure may be used to statisfy

incoming calls in congested cells.
EN_TFO
When set to true, the basic functions of TFO are possible in the cell for GSM
FR, EFR and HR codecs.
EN_TFO_MATCH
When set to true, the codec mismatch resolution procedure is possible in the
cell. This flag is relevant only if EN_TFO is set to true.
EN_TFO_OPT
When set to true, the codec optimisation procedure is possible in the cell.
This flag is relevant only if EN_TFO and EN_TFO_MATCH are both set to
true.
EN_UNEQUIPPED_CIRCUI
T
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, except for VGC talker handover.
FORBID_AMR_NS
O&M flag to forbid / allow AMR noise suppressor in the MS.
FORBID_DTXD_NH_BCCH
_F
O&M parameter which forbids or not the downlink DTX on the non-hopping
TCH of the BCCH TRX.
FORCE_TFO_VS_AMR
When set to true, it forces TFO negociation while AMR is used. This flag is
relevant only if EN_TFO and (EN_AMR_FR and/or EN_AMR_HR) are set to
true.
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. see ref.[23].
HO_INTERCELL_ALLOWE
D
When set FALSE, all Inter-cell handovers are inhibited. see ref.[23].
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
Synchronization IE in the HANDOVER COMMAND message.
This
parameter is settable on a BSC basis and is changeable on-line. When set
TRUE the MS is commanded to trigger a Handover Failure for an out of
range timing advance.
N_PREF_CELLS
The value of this counter dictates the maximum number of cells that may be
contained in the HANDOVER REQUIRED message sent to the MSC.
PLMN_FREQUENCY_BAN
DS
Frequency bands used in the whole PLMN.
RESP_REQ
When set TRUE, the Response Request OIE in the HANDOVER

REQUIRED message will be included.
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
115/120

ROT
O & M Parameter which controls the setting of the ROT field in the
Synchronization IE in the HANDOVER COMMAND message.
This
parameter is settable on a BSC basis and is changeable on-line. When set
FALSE the MS is commanded not to include the Time Difference IE in 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. see ref.[23].
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 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-synchronized-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.
see ref.[23].
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.
HO_REQD_ongoing
This variable counts the HANDOVER REQUIRED message sent to the MSC which
are waiting for a response from the MSC.
T7
This variable is set to either RUNNING or NOT RUNNING depending on the state
of the timer T7
T_HO_REQD_LOST
of the timer T_HO_REQD_LOST
T_MS_CELL_REJ
of the timer T_MS_CELL_REJ. See ref.[23].
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 handover management entity by excluding
cells present in the MS_CELL_REJ_LIST and REJ_CELL_LIST from the list of
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
116/120

cells received in the handover alarm.

CLOLD
ED 07
The list of cells that was sent to the MSC in the previous HANDOVER REQUIRED
message.
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
117/120

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 synchronized 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.
Biband MS
In Alcatel implementation, an MS is defined as biband if it supports at least the

bands given by the parameter PLMN_FREQUENCY_BANDS, i.e.:
it
supports
at
least
PGSM
AND
DCS1800,
PLMN_FREQUENCY_BANDS = GSM900 and DCS1800 bands
and
it
supports
at
least
DCS
1800
AND
GSM
850,
and
it
supports
at
least
DCS
1900
AND
GSM
850,
and
DCS
This generic term is used to designate either DCS 1800 or DCS 1900.
DCS 1800 band
The frequency band 1710.2 - 1784.8 MHz / 1805.2 - 1879.8 MHz
DCS 1900 band
The frequency band 1850.2 - 1919.8 MHz / 1930.2 - 1989.8 MHz
Don't care
This is used in State transition tables to indicate that when an event 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)
Multiband MS
An MS is defined as multiband if it supports at least two different frequency

bands. These bands may not be compatible (e.g. GSM850 GSM900, DCS1800
DCS1900)
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
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
118/120

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, e.g. 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
AMR
ASSGN
BCCH
BSC
BSCLP
BSIC
BSS
BTS
CGI
CIE
CL
CLOLD
CMD
CMP
CR
CC
CRef
DCCH
DI
DM
DR
DT1
DTX
EDR
EHO
EFR
eMLPP
EST IND
FCCH
FDD
GSM
HO
HR
IE
LCS
MAFA
MEAS
MIE
MS
MSC
O&M
OIE
PHY INFO
ED 07
ACTivation
Adaptative MultiRate speech codec
Assignment
Broadcast Control CHannel
Base Station Controller
BSC-MFS LCS Protocol
Base Station Identification Code
Base Station System
Base Transceiver Station
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.
Candidate cell list sent to the MSC in the last HANDOVER REQUIRED message,
CoMmanD
CoMPlete
Connection Request (SCCP)
Connection Confirm (SCCP)
Connection Refused (SCCP)
Dedicated Control Channel
Data INDication (Abis)
Disconnect Mode
Data REQuest (Abis)
DaTa form 1 (SCCP)
Discontinuous Transmission
External Directed Retry
External HandOver
Enhanced Full Rate
Enhanced Multi-Level Precedence and Pre-emption
ESTablish INDication
Frequency Correction Channel
Frequency Division Duplex
Global System for Mobile communications
HandOver
Half Rate
Information Element
LoCation Services
Mobile Assisted Frequency Allocation
MEASurements
Mandatory Information Element
Mobile Station
Mobile Switching Centre
Operations & Maintenance
Optional Information Element
PHYsical INFOrmation
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
119/120

PLMN
REF
REP
REQ
RES
RESP
RMS
RNC
RR
SABM
SACCH
SAPI
SCCP
SCH
SDCCH
SMLC
TCH
TDMA
TFO
UA
UE
UI
UDI
Public Land Mobile Network

REFUSE
REPort
REQuest
RESults
RESPonse
Radio Measurements Statistics
Radio Network Controller
Radio Resource
Set Asynchronous Balanced Mode
Slow Associated Control CHannel
Signalling Access Point Identifier
Signalling Connection Control Part
Synchronisation Channel
Standalone Dedicated Control Channel
Serving Mobile Location Centre
Traffic Channel
Time Division Multiple Access
Tandem Free Operation
Unnumbered Acknowledge
User Equipement
Unnumbered Information
Unit Data Indication (Abis)
END OF DOCUMENT
ED 07
RELEASED

0386_07.doc
06/11/2006
3BK 11202 0386 DSZZA
120/120

External Channel Change B9 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

External Channel Change B9 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

All rights reserved.

Passing on and copying of this

External Channel Change

Updated according to review report, see MRD/TD/SYT/204088

External Channel Changes

3BK 11202 0386 DSZZA

All rights reserved. Passing on and copying of this

Ed. 01 Proposal 2004/02/04

Ed. 02 Proposal 04/10/2004

Document based on Ed. 4 of B8 version of the document (3BK 11202

External Channel Changes

3BK 11202 0386 DSZZA

All rights reserved. Passing on and copying of this

2 FUNCTIONAL DESCRIPTION .....................................................................................................................7

External Channel Changes

3BK 11202 0386 DSZZA

All rights reserved. Passing on and copying of this

INTERNAL REFERENCED DOCUMENTS

Digital cellular telecommunications system (Phase 2+); Layer 1;

Mobile Radio Interface Layer 3 specification; Radio Resource

Recommended infrastructure measures to overcome specific phase

3BK 11202 0398 DSZZA

Internal Channel Change

3BK 11202 0399 DSZZA

3BK 11202 0400 DSZZA

Normal Assignment Procedure

3BK 11202 0412 DSZZA

Resource Allocation and Management

3BK 11202 0387 DSZZA

3BK 11202 0403 DSZZA

Short Message Service Point To Point

3BK 11202 0062 DSZZA

3BK 11202 0409 DSZZA

3BK 11202 0156 DSZZA

System Information Management

3BK 11202 0389 DSZZA

DTX functional specification

3BK 11202 0296 DSZZA

Alcatel BSS application document to GSM General overview

3BK 11203 0096 DSZZA

Frequency encoding algorithm

3BK 11202 0388 DSZZA

3BK 11202 0411 DSZZA

LAPDm functional specification

3BK 11202 0414 DSZZA

External Channel Changes

3BK 11202 0386 DSZZA

All rights reserved. Passing on and copying of this

Layer 3 message dictionary - Abis interface

3BK 11203 0104 DSZZA

LCS Functional Specification

3BK 11202 0337 DSZZA

TFO Functional Specification

ASCI Functional Specification

Layer 3 message dictionary - Air interface

3BK 11202 0301 DSZZA

OPEN POINTS / RESTRICTIONS

External Channel Changes

3BK 11202 0386 DSZZA

All rights reserved. Passing on and copying of this

External SDCCH handover;

External SDCCH to TCH directed retry.

External Channel Changes