Call Release B9

Site
EVOLIUM SAS
VELIZY
Originators
Didier ESCLAMADON
CALL RELEASE
RELEASE B9
System
ALCATEL 900/BSS
Sub-system
SYS-TLA
Document Category
PRODUCT DEFINITION
ABSTRACT
This document describes the call releasing procedure for the Alcatel BSS.
This edition of the document includes the GPRS feature.
Name
App.
R. MAUGER
SYT Manager
Name
App.
ED
EVOLIUM
03
Approvals
H.MA
BSC DPM
I.SCHWARZ
BTS DPM
C. LEJEUNE
SYT DPM
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
1/75
REVIEW
Ed 01 Proposal 01
08/03/2004
MRD/TD/SYT/rma/0070.2004
HISTORY
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
2/75
Release B8: 3BK 11202 0348 DSZZA

Version
date
11-02-04
Include the impact of Load Based 3G HO filtering features.
Ed. 01 Released
08/03/2004
Ed.02 Released
27/10/2004
Updated according to approved review report

MRD/TD/SYT/rma/0070.2004
Ed.03 Released
30/10/2006
Ed. 01 Proposal
01
ED
EVOLIUM
03
Reason for update
3BKA20CBR142270, according to file 142270_01
3BKA20CBR150634, according to file 150634_01
3BKA20CBR195973 - CREL : no SCCP RELEASED sent by BSC in

case of T9101 expiry
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
3/75
TABLE OF CONTENTS
TABLE OF CONTENTS......................................................................................................................... 4
INTERNAL REFERENCED DOCUMENTS ........................................................................................... 5
1 FUNCTIONAL DESCRIPTION ......................................................................................................... 7

1.1
General Description..................................................................................................... 7
1.2
BSS ENTITIES .............................................................................................................. 8
2 DYNAMIC BEHAVIOUR................................................................................................................... 9
2.1
GENERAL BEHAVIOUR .............................................................................................. 9
2.1.1 MS channel release procedure ....................................................................................... 9
2.1.2 BTS channel release procedure ................................................................................... 10
2.1.3 A interface call release procedure ................................................................................ 11
2.1.4 GPRS Resume procedure ............................................................................................ 13
2.2
DETAILED BEHAVIOUR WITHIN BSS ENTITIES .................................................... 16
2.2.1 MSC initiated release protocols towards the BSS ........................................................ 16
2.2.2 BSC initiated call release protocols .............................................................................. 20
2.2.3 BSC release towards the MS/BTS function .................................................................. 26
2.2.4 BTS call release function .............................................................................................. 33
2.2.5 MS Call release function ............................................................................................... 34
2.2.6 Call release trigger upon BSC detected events ............................................................ 36
2.2.7 Standard release scenarios .......................................................................................... 41
2.2.8 Scenarios during immediate assignment ...................................................................... 43
2.2.9 Scenarios during normal assignment............................................................................ 45
2.2.10 Scenarios during internal channel changes .................................................................. 48
2.2.11 Miscellaneous scenarios during normal assignment and internal channel changes.... 50
2.2.12 Scenarios during external channel changes ................................................................. 51
2.2.13 Scenarios during channel modification ......................................................................... 55
2.2.14 Unexpected event during channel change procedures ................................................ 56
2.2.15 Multiple event handling ................................................................................................. 57
2.2.16 The effect of O&M intervention on stable calls ............................................................. 57
2.2.17 The effect of BSC O&M intervention on channel change procedures .......................... 59
2.2.18 The effect of ERROR REPORT (O&M intervention) during channel change procedures
59
2.2.19 Unexpected event during the call release protocol....................................................... 60
2.3
INTERACTION WITH OTHER PROCEDURES.......................................................... 60
2.3.1 Interaction of DTAP and call release ............................................................................ 60
2.3.2 Interaction of MS & BS power control and call release................................................. 61
2.3.3 Interaction of O&M disable and call release ................................................................. 61
2.3.4 Interaction of BTS transcoder alarm detection mechanism and call release ............... 62
3 INTERFACE DESCRIPTIONS........................................................................................................ 63
3.1
BSS External INTERFACES ...................................................................................... 63
3.1.1 Radio interface .............................................................................................................. 63
3.1.2 A interface ..................................................................................................................... 64
3.2
BSS internal interfaces ............................................................................................. 65
3.2.1 A-bis interface ............................................................................................................... 65
3.2.2 GSL interface ................................................................................................................ 65
3.2.3 BSC internal interfaces ................................................................................................. 65
3.3
TIMERS LIST............................................................................................................... 67
3.4
PARAMETERS LIST................................................................................................... 68
4 GLOSSARY .................................................................................................................................... 69
5 ANNEX A ........................................................................................................................................ 70
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
4/75
INTERNAL REFERENCED DOCUMENTS

Not applicable
REFERENCED DOCUMENTS
Doctree references
[1]
3BK 11202 0413 DSZZA
Radio and Link Establishment
[3]
3BK 11202 0287 DSZZA
Channel Modification
[2]
[4]
[5]
[6]
[7]
[8]
[9]
3BK 11202 0412 DSZZA

3BK 11202 0173 DSZZA
Normal Assignment Procedure

Protocol Error Handling
3BK 11202 0396 DSZZA
BSS Initialisation of the Telecom Part
3BK 11202 0399 DSZZA
Reset Circuit, Blocking and Unequipped Circuit
3BK 11202 0416 DSZZA

3BK 11202 0414 DSZZA
3BK 11202 0389 DSZZA
BSS Global Reset
LapDm functional specification
System information management
[10]
3BK 11202 0404 DSZZA
TC/BTS interface
[12]
3BK 11202 0386 DSZZA
External channel change
3BK 11202 0395 DSZZA
GPRS MFS-BSC interface - BSCGP layer
[11]
[13]
[14]
[15]
[16]
[17]
3BK 11202 0335 DSZZA

3BK 11202 0399 DSZZA
3BK 11203 0096 DSZZA
3BK 11202 0387 DSZZA
3BK 11202 0405 DSZZA
LapD Management
Internal channel change
Alcatel BSS Application Document to GSM - General Overview

Resource Allocation and Management
ASCI Functional Specification
GSM References
[18]
3GPP TS 44.018 Mobile radio interface layer 3 specification; Radio Resource Control Protocol
Note the versions of the 3GPP Technical Specifications to which this Alcatel BSS release is compliant
are given in reference [15].
RELATED DOCUMENTS
Not applicable
PREFACE
Not applicable
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
5/75
SCOPE
This document specifies:

1)
The call release procedure for this release of the Alcatel BSS.
3)
The cause values contained in CLEAR REQUEST, HANDOVER FAILURE and

ASSIGNMENT FAILURE messages.
2)
The relationship between the call release procedure, the physical context procedure and
O&M performance management.
The event numbering used in this document correspond to triggering events for either : a call release,
connection release, or the release of a resource. These events can be found in the corresponding
procedure specification (ref.[6], [2], [1], [3], [12] & [13]).
Note :
ED
EVOLIUM
The SDL's in the appendix are a help to implementation and integration. In case of
inconsistency, the text is the definitive description.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
6/75
1
1.1
FUNCTIONAL DESCRIPTION
General Description
During an MS connection, Radio interface and A interface channels are allocated or reserved. These
resources require to be released for reuse when the call is terminated and upon events whilst the
transaction is on going.
The releasing or freeing of resources is initiated on internal or external events that the BSS detects or
receives.
The BSS call release function is responsible for:
the release protocol with the MS,
the release of radio and terrestrial resources in the BSS (this includes performing the
release protocol with the BTS),
the gathering of LapDm performance management data for O&M,
the release protocol with the MSC.
the GPRS resume procedure in case of GPRS service suspension requested by Class B
GPRS mobile. (See also ref.[1] for the GPRS suspend procedure description)
Call and resource releasing strategies
The strategies taken, with respect to the call release & resource release scenarios are as follows:
1)
2)
3)
4)
ED
EVOLIUM
The release towards the Radio interface (the BTS and MS) and the release towards the A
interface (the MSC) - when initiated together - will run in parallel without any synchronisation
between them.
This means that the radio and A interface resources will be released at different times. As a
result there is an interaction between the BTS transcoder alarm detection mechanism and
call release - see section 2.3.4 Interaction of BTS transcoder alarm detection mechanism
and call release".
When a channel change procedure runs and it appears that the MS is lost, a release
protocol to the MS will always be initiated. This ensures that MS is always released and
caters for the case of message loss on A-bis or message discard by the MS.
Note : An exception exists to this rule at the end of the immediate assignment procedure see section 2.2.8 Scenarios during immediate assignment".
When a failure occurs in the release of the radio channel in the BTS, the BSC will attempt
the protocol again. If the second attempt fails, the resource is released locally in the BSC
and an O&M error report (cause "RF channel release failure") is generated.
In a call release scenario, the physical context procedure (for the gathering of LapDm
performance management data) will always be performed unless a physical context
procedure has been performed prior to the initiation of the call release procedure.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
7/75
1.2
BSS ENTITIES
The following entities are involved in the execution of the call release procedure:
MS RR release :
This function is responsible for:
When it receives the CHANNEL RELEASE message, releasing the MM and RR

connections in the MS, and initiating the LapDm release using the RL-REL-REQ
(confirmed).
Carrying out the radio link failure detection algorithm. In the event that the radio link fails,
it will initiate the LapDm release RL-REL-REQ (local).
MS, MSC MM entities :
These functions perform the protocol for MM procedures between the MS and the MSC
(location update, IMSI attach and IMSI detach).
It is mentioned here for completeness, since at the end of these procedures the MSC may
perform a call release.
MS, MSC CC and SMS entities :
These functions perform the protocol for CC & SMS procedures between the MS and MSC
(Incoming and Outgoing calls).
It is mentioned here for completeness, since at the end of these procedures the MSC may
perform a call release.
BTS call release function :
This function performs the following:
Failure event reporting for radio link failure, transcoder failure and LapDm errors.
Internal channel release in case of transcoder failure.
Call release to the MS in the event of A-bis failure.
Event reporting and call release for FU : reconfiguration, reset events, etc.
BSC call release function :
This function is responsible for releasing of both Radio and A interface resources.
MSC call release function :
This function is responsible for performing the release of the call.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
8/75
DYNAMIC BEHAVIOUR
2.1
GENERAL BEHAVIOUR
2.1.1
MS channel release procedure
When it is necessary to release the radio channel allocated to an MS, the release is performed by
using two methods:
1)
2)
by sending a CHANNEL RELEASE message to the MS,

by forcing a radio link failure event in the MS.
2.1.1.1
CHANNEL RELEASE method
GSM allows sending of optional BA Range IE in CHANNEL RELEASE message, indicating several
ARFCN ranges (GSM and DCS) which can be used in the cell selection procedure. Doing so will
reduce cell reselection times in the MS.
The Alcatel BSS will send the optional IE in case of Location Updating procedure for mobiles phase 2.
It is up to the BSC to include this IE in the CHANNEL RELEASE message, but these ranges shall be
received from the OMC-R. Every range_i is defined by the RANGEi_LOWER and RANGEi_HIGHER
values coded by 10 bits (ARFCN coding).
This new IE shall not be sent to a GSM phase 1 MS.
When the MS receives a CHANNEL RELEASE message, the MS instructs the LapDm function to
perform a confirmed disconnection of LapDm and starts the timer T3110.
The timer T3110 is used to hold off the releasing of the radio channel so that the DISC frames sent by
the MS at SAPI 0 can be properly received by the BSS. The value of T3110 is such that at least two
DISC frames may be sent by the MS to the BSS (recommended by GSM ref.[18]), this gives a good
probability of the BSS detecting the disconnection of SAPI 0 by the MS. If T3110 expires, the MS
instructs the LapDm function to perform a local disconnection (non confirmed) of LapDm and returns
to performing idle mode procedures.
On the reception of the DISC frame, the BTS sends a UA (in response) and reports the disconnection
to the BSC via the RELEASE INDICATION message.
The BSC (on reception of this message) must wait a short period (T3111), this allows the DISC and
UA to be exchanged on the Radio interface, before the BSC performs the RF channel release
procedure.
If the BSC does not wait a period of T3111 before performing RF channel release procedure, the UA
(which is in the process of being sent by the LapDm entity) may never be sent since the release of
radio channel is made before the point in time the BTS LapDm can send the UA message on the
Radio interface. This is most likely to occur for SDCCH connections where the transmission to the MS
may only occur at specific points within the Radio interface multi-frame. For TCH connections the
message may be sent immediately.
2.1.1.2
Radio link failure detection method
The radio link failure detection algorithm in the MS is triggered by the BSS when it stops the sending
of SACCH frames to the MS on the main SACCH. SACCH frames should be stopped for a period of
T3109 for the algorithm in the MS to detect radio link failure condition. This is initiated by the BSC by
sending to the BTS the DEACTIVATE SACCH message on the main channel.
Note :
On reception of the DEACTIVATE SACCH, the BTS will disable the remote transcoder alarm
detection mechanism, this is needed due to the adopted strategy, i.e. the initiation of a
parallel release of A and A-bis/Radio interfaces - see section 2.3.4 Interaction of BTS
transcoder alarm detection mechanism and call release.
Whilst the MS is connected, it runs an algorithm which detects the lack of SACCH frames on the main
SACCH for a period of time (set by the BSS).
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
9/75
Once this time-limit is reached, a radio link failure is supposed to exist. Upon this supposition, the MS
instructs the LapDm entity to perform a "local end release" of the LapDm connection and a release of
the physical layers, that is to say that the LapDm and RR connection are released without any
exchange of messages on the Radio interface.
Then, depending on the state of the call, the MS performs a cell re-selection process. If one of the
cells can be "camped on" and supports the re-establishment procedure (see note *), the MS may
attempt the re-establishment procedure and re-establishes the previously lost connection if allowed in
the MSC.
The time-limit used in the MS radio link failure algorithm is controlled by the BSS by use of the field
RADIO-LINK-TIMEOUT, which is contained in the Cell Options IE, sent in the SYSTEM
INFORMATION TYPE 6 message. It is important that the BSS timer T3109 is set to be greater than
the RADIO-LINK-TIMEOUT field for correct operation of this procedure.
Note * : If the operator wishes to enable the re-establishment procedure in the network, then the
"RE" information field in the RACH Control Parameters IE in SYSTEM INFORMATION TYPE
1, 2, 3 & 4 messages broadcasted on the BCCH, have to be set appropriately.
2.1.2
BTS channel release procedure
The BTS channel release procedure may be initiated by itself or by the BSC.
2.1.2.1
BSC initiated
The BSC initiates a BTS channel release procedure by sending a RF CHANNEL RELEASE message
to the BTS.
On reception of this message the BTS will release the channel and return an RF CHANNEL
RELEASE ACKNOWLEDGE to the BSC.
When the BSC receives the acknowledgement, the channel is then released (within the BSC) for use
in other connections.
The BSC starts the timer T_RCR_ACK to supervise the response of the BTS. In the event that the
timer expires, the BSC will attempt the procedure again. In the event that this procedure also fails, the
BSC will free the channel for reuse and send an O&M error report.
2.1.2.2
BTS initiated
The BTS may initiate a release of its own RF channels (the reasons for initiation and the method of
releasing is described in detail further on in this document). This releasing is performed on a FU basis.
At the end of the release, the TRX sends to the BSC an ERROR REPORT (cause "O&M intervention")
to inform the BSC that the FU has released all active connections.
The BSC, on reception of the ERROR REPORT (cause "O&M intervention"), will release any RF
resource locally and perform a call release towards the MSC on A interface if required. In addition the
BSC will perform the FU re-initialisation procedure - see ref.[5].
2.1.2.2.1
Mismatch between the BTS and BSC
BTS assumes a channel is busy but BSC treats it as free.
When the BTS receives a CHANNEL ACTIVATION for a channel that it considers to be already
activated, the BTS will release the channel internally (stop immediately sending SACCH frames
and does not start T3109) and then activate the requested channel. The BSC is then informed of
the (un)successful completion.
Several possibilities exist when an activation request arrives for an already activated channel:
1)
2)
ED
EVOLIUM
a full-rate TCH channel is requested but the channel is currently busy as TCH (the channel
is currently being used by at least one call);
a full-rate TCH channel is requested but the channel is currently busy as SDCCH (at least
one of its logical SDCCH sub-channels is currently being used to carry the signalling);
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
10/75
3)
4)
5)
a half-rate TCH channel is requested but the channel is currently being used by a FR call or
the requested TCH sub-channel is currently being used by an another HR call;
a half-rate TCH channel is requested but the channel is currently busy as SDCCH (at least
one of its logical SDCCH sub-channels is currently being used to carry the signalling);
a SDCCH channel is requested but channel is currently being used by at least one call or all
of its logical SDCCH sub-channels are currently being used to carry the signalling.
In all above cases, the "busy" channel will be released (see scenario N1500).
BTS assumes a channel is free but BSC treats it as busy. There are two cases:
Case 1: BTS considers a channel is free but BSC considers that the channel is currently
being used by a FR call or by two HR calls. A cross over of messages could be the
reason of this mismatch.
Case 2: BTS considers a channel is free but BSC considers that the channel is currently busy
as SDCCH. The reason of this mismatch may be a cross over of messages or the
timeslot is on hold in the BSC (this is unknown by the BTS).
In above two cases no error is reported to O&M. This busy channel is marked as suspect within
the BSC. If on receipt of the subsequent RF RESOURCE INDICATION message indicating that
the channel is idle, a mismatch is assumed and the resources of each busy TCH channel or
busy SDCCH sub-channel are released internally within the BSC by using the call release
scenario N1400. The mechanisms detecting the above two mismatch cases are detailed in
reference [16].
NOTE: In order to enable this capability of checking for mismatch of resources between the BTS and
BSC it is necessary that the RF RESOURCE INDICATION message is always sent from the BTS
to the BSC i.e. the BTS flag BTS_EN_RF_RESOURCE_IND is always set to enable the sending
of RF RESOURCE INDICATION message.
2.1.3
A interface call release procedure
The A interface call release procedure may be initiated by the:
BSC,
MSC.
The MSC may initiate a call release in the BSS using the following methods:
1)
2)
3)
4)
by sending CLEAR COMMAND to the BSC,

by initiating an SCCP release by sending the SCCP RELEASED message to the BSC,
by sending the RESET message,
by sending the RESET CIRCUIT message.
1)
2)
3)
4)
by sending the CLEAR REQUEST message to the MSC,

by initiating an SCCP release by sending the SCCP RELEASED message to the MSC,
by sending a RESET message,
by sending a RESET CIRCUIT message.
2.1.3.1
MSC initiated (CLEAR COMMAND to the BSC)
The BSC may initiate a call release in the MSC using the following methods:
The MSC sends the CLEAR COMMAND as a result of a normal clearing sequence of either a CC,
MM, SMS or SS connection - see section 2.2.1.1 MscRel : MSC initiated normal release towards
the BSS.
2.1.3.2
MSC initiated (release of SCCP)
The MSC may disconnect the SCCP directly by the sending of the SCCP RELEASED message to the
BSC - see section 2.2.1.4 MSC initiated SCCP release towards the BSS.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
11/75
2.1.3.3
MSC initiated (RESET to BSC)
The MSC sends to the BSC a RESET message when it requires to initiate a release for all
connections associated to the BSS.
For behaviour see ref.[6] and section 2.2.1.2 MSC initiated calls reset towards the BSS".
2.1.3.4
MSC initiated (RESET CIRCUIT to BSC)
The MSC may initiate a call release towards the BSC by sending the RESET CIRCUIT message. This
message indicates to the BSC that the MSC wishes to initiate a release for a single connection which
has an association with the specified A interface channel (CIC).
For behaviour see ref.[7] and section 2.2.1.3 MSC initiated reset circuit towards the BSS".
2.1.3.5
BSC initiated (CLEAR REQUEST to the MSC)
The BSC sends to the MSC a CLEAR REQUEST message with a cause value indicating the reason
for the release. The MSC should react to this message with a CLEAR COMMAND, upon which the
BSC replies with a CLEAR COMPLETE.
The SCCP connection should then be released by the MSC by the sending of SCCP RELEASED to
the BSC, upon which SCCP RELEASE COMPLETE is sent back to the MSC.
This method is normally used by the BSC to clear a transaction when there are allocated resources
reserved for the connection (on both Radio and A interface) - see section 2.2.2.1 CrRel : BSC
initiated normal call release towards the MSC".
No CLEAR COMMAND from MSC :

To ensure that the connection will eventually clear (in the event that the MSC has failed or for some
other reason is not responding), the BSC supervises the reception of the CLEAR COMMAND by use
of the timer T9104 and the O&M parameter "N_CLR_REQ".
If no CLEAR COMMAND is received within T9104, then the BSC re-sends the CLEAR REQUEST,
this may be repeated as many times as indicated by "N_CLR_REQ" - see section 2.2.2.1.1
Compelled CLEAR REQUEST (T9104 expiry)".
If the procedure is repeated "N_CLR_REQ" times (without success) then the SCCP connection is
released immediately by using the primitive SCCP-N-DISC-REQ to the SCCP entity. A RESET
CIRCUIT procedure may be run if a CIC was associated to the connection - see ref.[6], this is deemed
to be one of the abnormal release cases.
Note :
In the case where the clearing was triggered by O&M, T9104 is only allowed to expire once.
Upon T9104 expiry, the SCCP is forced release.
The primitive SCCP-N-DISC-REQ sent to the SCCP entity triggers the sending of SCCP RELEASED
message from the BSC to the MSC, upon which the MSC should respond with an SCCP RELEASE
COMPLETE.
No SCCP RELEASED from MSC :
To ensure that the SCCP connection is cleared at the end of the clearing sequence, the BSC runs the
timer T9101 after having sent the CLEAR COMPLETE to the MSC. This timer is stopped on reception
of the SCCP RELEASED - see section 2.2.2.1.2 Awaiting SCCP release (T9101 expiry)".
If T9101 expires then the BSC will release the SCCP locally.
2.1.3.6
BSC initiated (release of SCCP)
The BSC may initiate a direct release of the SCCP connection. This is done on events such as :
reception or transmission of RESET and RESET CIRCUIT, failure of the MSC to react on the CLEAR
REQUEST, but is also initiated when there are no resources associated with the connection after
timer expiry.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
12/75
It is initiated by use of the primitive SCCP-N-DISC-REQ to the SCCP entity which may cause the
SCCP RELEASED message to be sent to the MSC - see section 2.2.2.4 SccpRel : BSC initiated
SCCP release towards the MSC".
2.1.3.7
BSC initiated (RESET to the MSC)
The BSC may initiate a call release towards the MSC by sending the RESET message. This message
indicates to the MSC that the BSC wishes to initiate a release for all active connections in the MSC
associated to the BSS that sent the message.
For behaviour see ref.[6] and section 2.2.2.1.4 MSC initiated calls reset towards the BSS".
2.1.3.8
BSC initiated (RESET CIRCUIT to the MSC)
The BSC may initiate a call release towards the MSC by sending the RESET CIRCUIT message. This
message indicates to the MSC that the BSC wishes to initiate a release for a single connection which
has an association with an A interface channel (CIC).
For behaviour - see ref.[7] and section 2.2.2.3 BSC initiated reset circuit towards the MSC".
The reset circuit procedure may be triggered by the detection of the following events, unless the A
channel is "Blocked" or "Camped on Blocked" in the BSC ref.[7]:
1)
Abnormal release of a connection with an associated A interface channel (CIC) due to
T9104 expiry N_CLR_REQ times.
2)
Release of a connection with an associated A interface channel (CIC) due to reception
from the SCCP entity of an SCCP-N-DISC-IND cause "SCCP inactivity timer expiry"
(corresponding to the reception of a SCCP RELEASED message - with cause expiration
of receive inactivity timer - from the MSC or the expiry of the BSC SCCP inactivity timer).
2.1.4
GPRS Resume procedure
When a GPRS Class B MS has suspended the GPRS service during its CS connection (see ref.[1]),
the BSC is in charge to resume the GPRS service at CS call completion.
More precisely, before releasing the RR connection with the MS and in case that the MS has
previously resquested to suspend the GPRS service, the BSC shall request the SGSN (via the MFS)
to resume the GPRS traffic.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
13/75
(1)
MS
BTS
BSC
(1)
MS RESUME
(1)
start T_GPRS
_Resume
(2)
(2)
(2)
stop T_GPRS
(3)
(3)
---------------------------------->
MS RESUME ACK
<----------------------------------
_Resume
(3)
(3)
MFS
DR (CHANNEL RELEASE)
RR CHANNEL RELEASE
<----------------------------------------------
<-------------------------------
Figure: GPRS Resume scenario
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
14/75
Before releasing the RR connection towards the MS (sending the RR CHANNEL RELEASE
message), the BSC checks if it contains a suspend/resume context related to the MS.
If such context exists, containing the informations TLLI, RAI and SRN (Suspend Reference
Number), the BSC shall first resume the GPRS service, sending the MS RESUME message to
the MFS via the GSL link including the TLLI, RAI and SRN informations (see ref.[14]), and
start the T_GPRS_Resume timer (remark: the T_GPRS_Resume timer shall be as short as
possible in order to be compatible with the usual RR connection release duration).
2&3
The MFS forwards the Resume command to the SGSN, which acknowledges it and resumes
the GPRS traffic towards the MS.
Upon receipt of MS RESUME ACK, the BSC stops the T_GPRS_Resume timer, sends the RR
CHANNEL RELEASE message to the MS (via the BTS) with the GPRS Resumption IE and
deletes the MS suspend/resume context.
If the MS RESUME ACK message does not contain the OIE Resume failure cause, the
GPRS Resumption IE is set to the value successful resumption.
If the MS RESUME ACK message contains the OIE Resume failure cause, the GPRS
Resumption IE is set to the value unsuccessful resumption.
Note: In case of unsuccessful GPRS service resumption indicated by the BSC, the GPRS MS shall
send a RA update message to the SGSN in order to request itself the GPRS traffic resumption.
Error cases:
If the BSC contains a MS supend/resume context without the SRN information (i.e. the MFS
didnt acknowledge the Suspend request towards the BSC), no MS RESUME message is
sent to the MFS.
The BSC sends immediately the RR CHANNEL RELEASE message to the MS with OIE GPRS
Resumption set to the value unsuccessful resumption and delete the MS suspend/resume
context.
ED
EVOLIUM
If T_GPRS_Resume timer expires, the BSC sends also immediately the RR CHANNEL
RELEASE message to the MS with OIE GPRS Resumption set to the value unsuccessful
resumption and delete the MS suspend/resume context.
If there is no MS suspend/resume context in the BSC at the receipt of MS RESUME ACK
message from the MFS (e.g. the CS call ends before), the message is discarded.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
15/75
2.2
DETAILED BEHAVIOUR WITHIN BSS ENTITIES
This section contains a description of the BSC's & BTS's systems behaviour when a call release is
required to be initiated.
The protocols are split into protocols on A, A-bis and Radio interfaces. Each protocol on each
interface is described completely. The protocols on Radio and A-bis are not synchronised to the
release on A interface and run in parallel to each other.
The section 2.2.6 "Call release trigger upon BSC detected events" gives a notation which references
the protocols (and cause values used) described in this section which are to be performed on Radio,
A-bis and A interfaces
2.2.1
2.2.1.1
MSC initiated release protocols towards the BSS

MscRel : MSC initiated normal release towards the BSS
The MSC's normal method of releasing a connection on the A interface is by sending the CLEAR
COMMAND message to the BSC. It is generally sent by the MSC in the following cases:
-
At the end of a CC, MM or SMS connection.
When the MSC has received a CLEAR REQUEST from the BSS - see section 2.2.2.1
CrRel : BSC initiated normal call release towards the MSC".
Some exceptions exist - see section 2.2.1.4 MSC initiated SCCP release towards the BSS".
The MSC performs the call release by sending the CLEAR COMMAND message. The BSC returns a
CLEAR COMPLETE and the timer T9101 is started, the BSC awaits the release of the SCCP
connection.
The message sequence chart below shows the MSC initiated release scenario.
BSC
MSC
CLEAR COMMAND
(1)
(2)
(3) Start T9101
CLEAR COMPLETE
SCCP RELEASED
(4)
Stop T9101
SCCP RELEASE COMPLETE
Figure 3-1
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
16/75
(1)
(2)
The MSC initiates the release by sending the CLEAR COMMAND.
The BSC releases any A Channel resources, switches off the traffic path in the BSC and
returns immediately the CLEAR COMPLETE message to the MSC. Note that the BSC will
accept any CLEAR COMMAND message even if the MIE is not present or the cause is
unknown.
In the case where the BSC still has resources allocated in the BTS (A-bis) or a connection to
the MS (Radio) the appropriate release scenario will be triggered to release the MS
connection and free the RF resources.
In the case where there is a channel change procedure in progress, the whereabouts of the
MS is awaited before the release is initiated on Radio and A-bis - see ref.[2], [12] & [13] for
the behaviour of the BSS on A interface.
(3)
(4)
The MSC upon reception of the CLEAR COMPLETE releases any A Channel resources
associated to the connection and should initiate the release of the SCCP resource.
The BSC starts the timer T9101 to supervise the release of the SCCP resource - see section
2.2.2.1.2 on "Awaiting SCCP release (T9101 expiry).
The MSC releases the SCCP resource by sending the SCCP RELEASED message to the
BSC.
The BSC stops T9101 and returns the SCCP RELEASE COMPLETE message and the
SCCP resources are now considered released.
2.2.1.2
MSC initiated calls reset towards the BSS
The MSC will initiate a reset procedure towards a BSS when the MSC finds it is necessary to release
all connections pertaining to a BSS. The reset protocol is described in ref.[6].
The scenario below shows the call release protocol performed on the A interface.
BSC
(1)
MSC
RESET
SCCP RELEASED
SCCP RELEASED
(2)

SCCP RELEASED
Figure 3-2
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
17/75
(1)
(2)
The MSC initiates a reset procedure by sending the RESET message to the BSC. For more
details of the reset protocol, see ref.[6].
The BSC receives the RESET message and immediately releases the SCCP connections of
all active transactions.
If an A channel is associated with the SCCP connection, then the A channel will be released
immediately and the BSC will switch off the traffic path.
Note: The SCCP RELEASED and SCCP RELEASE COMPLETE messages may not
appear on the A interface as this release method may be initiated due to SCCP
problems.
In the case where there is an MS connected, a call release will be performed on Radio and
A-bis so as to release the MS and then release the resources associated to the connection.
For those MSs which are in the process of initiating channel change procedures, the release
on Radio and A-bis and the release of any A interface resource associated to the connection
may be delayed until the whereabouts of the MS is known - see ref.[2], [12] & [13].
2.2.1.3
MSC initiated reset circuit towards the BSS
The MSC will initiate a reset circuit procedure when it requires to release a possible connection in the
BSC which is associated to an A channel. It initiates this by sending a RESET CIRCUIT message
which indicates the concerned A channel - see ref.[4] for more detail on the reset circuit protocol.
The scenario below shows the behaviour where there is a connection associated with the A channel
contained in the RESET CIRCUIT.
BSC
(1)
MSC
RESET CIRCUIT
SCCP RELEASED
(2)
Figure 3-3
(1)
(2)
The MSC initiates a reset circuit procedure by sending a RESET CIRCUIT message.
The BSC behaviour for the reset circuit protocol is specified in ref.[7], the call release for
active connections is performed as follows :
On A interface: If the A channel has an active call, then the A channel, the traffic path and
SCCP connection will be released immediately, in the case of a connection undergoing a
channel change, the release of the A interface circuit may be delayed.
On Radio and A-bis interfaces: The MS is released after which the Radio interface RF
resources are released.
Notes:
ED
EVOLIUM
During channel change procedures the release on the Radio/A-bis interfaces and the A
interface circuit may be delayed until the whereabouts of the MS is known.
The SCCP RELEASED and SCCP RELEASE COMPLETE messages may not appear on
the A interface if the SCCP connection is lost in either the BSC or MSC.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
18/75
There is no call release scenario when there is no connection associated to the A channel
indicated in the RESET CIRCUIT message.
2.2.1.4
MSC initiated SCCP release towards the BSS
The reception of a SCCP RELEASED message from the MSC signals the termination of an SCCP
connection used for carrying signalling messages for the connection, there are no methods of reestablishment of the connection possible at the SCCP layer or possible within GSM between the BSS
and MSC.
This type of release has been used by an MSC to indicate a normal release of the MS transaction.
This type of behaviour is not specified by GSM but may be acceptable in the cases where it has been
used, that is at the end of a MM procedures (Location update, etc.) where there are no A interface
resources (i.e. an A channel) associated with the connection or at the end of an unsuccessful external
handover due to "Handover resource allocation failure".
The Alcatel BSS, on reception of the SCCP RELEASED message, accepts this release irrespective of
the resources allocated to the connection.
The BSC SCCP entity, on reception of the SCCP RELEASED message, returns immediately an
SCCP RELEASE COMPLETE message and conveys the event to the BSC GSM protocol entity by
sending to it an SCCP-N-DISC-IND (cause SCCP inactivity timer expiry - if the release cause set by
the MSC is expiration of receive inactivity timer - or cause "SCCP released by MSC" - in any other
case).
Upon reception of the primitive SCCP-N-DISC-IND (cause "SCCP released by MSC"), the BSC GSM
protocol entity releases any associated A interface resources (A channel) and associated traffic path
and initiates a release on the Radio interface of the MS and Radio interface resources. Even during
channel change procedures, the release is initiated immediately - see ref.[2], [12] & [13].
The reset circuit procedure may be triggered if the reason for the SCCP N-DISC-IND is SCCP
inactivity timer expiry - see section 2.2.2.3 BSC initiated reset circuit towards the MSC.
BSC
BSSAP
BSC
BSC
SCCP
(1)
SCCP-N-DISC-IND
(2)
MSC
SCCP RELEASED
Figure 3-4
(1)
(2)
The MSC has sent the SCCP RELEASED message.
The BSC SCCP replies with the SCCP RELEASE COMPLETE and passes to the BSC
BSSAP entity an indication that the signalling link no longer exists.
The BSC releases any associated A channel and initiates the release towards the MS if
applicable.
In case where the SCCP RELEASED message contains an embedded BSSAP message, the BSC
proceeds as follows:
If the BSSAP message is a BSSMAP message, it is ignored.
If the BSSAP message is a DTAP message for SAPI 0, it is transmitted towards the MS prior to
any possible CHANNEL RELEASE, except in the middle of a channel change when the BSC does
not know on which channel the MS is. In such case, the DTAP message is discarded by the BSC.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
19/75
If the BSSAP message is a DTAP message for SAPI 3 and a SAPI 3 connection is established, it is
transmitted towards the MS prior to any possible CHANNEL RELEASE, except in the middle of a
channel change when the BSC does not know on which channel the MS is. In such case, the
DTAP message is discarded by the BSC. If no SAPI 3 connection is established, the DTAP
message is discarded.
2.2.2
2.2.2.1
BSC initiated call release protocols

CrRel : BSC initiated normal call release towards the MSC
This is the normal method by which the BSS initiates the release of a connection due to events
detected internally to the BSS, and due to events detected whilst performing the GSM protocols.
In most cases, when the BSS is initiating the call release in this way, the MS release is already in
progress or may even have been completed, however there are a few cases where the MS is still
connected on the Radio interface whilst the release is occurring on the A interface. In these cases the
MS remains connected until the MSC sends a CLEAR COMMAND upon which the BSC will initiate
the call release scenario towards the MS.
The BSC initiates this scenario by sending to the MSC a CLEAR REQUEST message. The BSC runs
the timer T9104 to supervise the procedure - see section 2.2.2.1.1 Compelled CLEAR REQUEST
(T9104 expiry)".
The MSC on receipt of the message should return a CLEAR COMMAND, where upon the BSC will
return a CLEAR COMPLETE, release any associated A channel, and then await the release of the
SCCP connection. The release of the SCCP connection by the MSC is supervised by the BSC using
the timer T9101 - see message sequence chart below.
BSC
(1)
(2)
(3)
Start T9104
MSC
CLEAR REQUEST
CLEAR COMMAND
Stop T9104
Start T9101
CLEAR COMPLETE
SCCP RELEASED
(4) Stop T9101
Figure 3-5
Note A : the BSC detects an event which causes a call release to occur, initiated by the BSC.
(1)
ED
EVOLIUM
The BSC detects an event, and signals the requirement to release the connection by
sending the CLEAR REQUEST to the MSC, and starts the timer T9104 to supervise the
procedure.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
20/75
(2)
The MSC responds by sending a CLEAR COMMAND.
(3)
The BSC releases any associated A channel and any associated traffic path, and sends the
CLEAR COMPLETE. The release of the SCCP connection is awaited. The timer T9101 is
started to guard the release of the SCCP connection by the MSC.
The BSC stops the timer T9104, if the MS is still connected the BSC will initiate a call
release scenario towards the MS and then release the resources in the BTS.
(4)
The MSC, on reception of the CLEAR COMPLETE, should release any associated A
channel resource and release the SCCP connection by sending the SCCP RELEASED
message to the BSC. The BSC should respond with the SCCP RELEASE COMPLETE and
stop T9101.
2.2.2.1.1
Compelled CLEAR REQUEST (T9104 expiry)
The timer T9104 is started during the BSC initiated normal call release towards the MSC, to ensure
that in the case where the MSC does not respond, the connection will be eventually released.
When the timer T9104 expires:
If the event is an O&M initiated event to disable a DTC, A trunk or A channel, the SCCP connection is
immediately released - see section 2.2.2.1.3 BSC initiated call release due to O&M disable".
If N_CLR_REQ is set to 0 or 1, then the connection is also immediately released.
In any other case, the CLEAR REQUEST is sent again, the BSC starts T9104 and awaits the CLEAR
COMMAND message. A maximum of "N_CLR_REQ" CLEAR REQUEST message is sent to the MSC
(except when N_CLR_REQ is set to 0: in this case still one CLEAR REQUEST is sent to the MSC).
In the event that the CLEAR COMMAND message is never received, the SCCP connection is force
released by sending an SCCP-N-DISC-REQ primitive to the SCCP entity.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
21/75
The message sequence chart below shows the compelled CLEAR REQUEST scenario where the
MSC does not respond, where there is a CIC allocated to the transaction and where N_CLR_REQ, is
set to be equal to 3.
BSC
Start T9104
T9104 expiry
Start T9104
T9104 expiry
Start T9104
(1)
MSC
CLEAR REQUEST
CLEAR REQUEST
CLEAR REQUEST
T9104 expiry
Initiate reset circuit procedure for CIC

SCCP RELEASED
Figure 3-6
(1)
This action is only initiated if a CIC is allocated to the connection which is undergoing the
release - see ref.[7]
2.2.2.1.2
Awaiting SCCP release (T9101 expiry)
When the BSC has sent the CLEAR COMPLETE to the MSC it runs the timer T9101 so as to ensure
that the MSC releases the SCCP connection. This ensures that there are no hanging resources in the
SCCP entity.
If the MSC does not release the SCCP resource, the BSC will locally release it.
The SCCP entity sends a SCCP RELEASED to the MSC. Whether the MSC responds with the SCCP
RELEASE COMPLETE is of no importance to the scenario as the SCCP connection is deemed
released in the SCCP layer.
It must be noted that the SCCP RELEASED message is only specified in GSM to be sent from the
MSC to the BSC, so this behaviour is a specificity of the Alcatel BSS.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
22/75
The message sequence chart below shows the MSC initiated release scenario when the timer T9101
expires.
BSC
Start T9101
T9101 expiry
MSC
CLEAR COMMAND
CLEAR COMPLETE
SCCP RELEASED
Figure 3-7
2.2.2.1.3
BSC initiated call release due to O&M disable
The scenario below shows the special case of BSC initiated normal call release towards the MSC due
to an O&M event commanding the disable of a DTC, A trunk or A channel (CIC).
This special behaviour is needed so that the Telecom can give to the O&M entity an
acknowledgement that the call(s) have been released - see section 2.3.3 Interaction of O&M disable
and call release".
BSC
(1)
(2)
MSC
BLOCK
Start T9104
T9104 expiry
(3)
CLEAR REQUEST
SCCP RELEASED
Figure 3-8
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
23/75
(1)
Telecom has received an internal O&M event to disable a DTC, A trunk or A channel.
(2)
The BSC initiated normal release is triggered (this may occur later in the sequence if the
O&M disable has a non zero wait traffic clear period). During this point in time the blocking
procedure may be still running as specified in ref.[7].
The Telecom triggers blocking procedures (the timers are not shown) - see ref.[4] for
protocol behaviour.
The BSC initiates the release of the MS connection, this may be delayed if channel change
procedures are in progress - see ref.[2], [12] & [13].
The BSC initiates the normal release by sending CLEAR REQUEST and starting the timer
T9104.
(3)
There is no response from the MSC and T9104 expires, the A channel, the traffic path and
the SCCP connections are released immediately.
For A trunk and A channel disable the blocking procedures will continue - if the MSC has not
already acknowledged them.
In the case of DTC disable the blocking procedures will stop as the processor will be
disabled and the Telecom entity will be stopped.
2.2.2.1.4
BSC internal resource reset procedure
The BSC internal resource reset procedure slightly differ, depending on the current state of the
concerned channel :
If no release scenario is ongoing, then BSC shall trigger release scenario N0300.
If a release scenario is already ongoing for this channel :
2.2.2.2
If the BSC has sent CLEAR REQUEST before, and T9104 is running (waiting for CLEAR
COMMAND from MSC), then the BSC shall stop T9104, release all resources and send
SCCP-RLSD to the MSC.
If the BSC has already received CLEAR COMMAND message from MSC, then it shall finish
the release procedure and send CLEAR COMPLETE to the MSC. It shall then start T9101 to
wait for SCCP-RLSD from MSC.
BSC initiated calls reset towards the MSC
The reset procedure is initiated by the BSC as described in ref.[6].
The call release function in the BSS releases all A interface resources locally (A channels and SCCP
connections) and switches off any associated traffic path in the BSC.
The release towards the Radio and A-bis is made immediately. In the case of channel change
procedures the call release may be delayed - see ref.[2], [12] & [13].
BSC
MSC
RESET
(1)
Figure 3-9
(1)
ED
EVOLIUM
The BSC detects the need to perform the reset procedure, the SCCP connections and A
interface resources (A channels) on A interface are released locally (i.e. no message
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
24/75
exchange), any associated traffic path is switched off and the RESET message is sent to the
MSC.
Note :
depending on BSS configuration, the RESET message may not be sent - see ref.[6].
2.2.2.3
BSC initiated reset circuit towards the MSC
The reset circuit procedure is initiated by the BSC as described in ref.[7].
The reset circuit procedure may also be triggered by O&M, to release quickly and selectively several
calls. This procedure is used, for example, with BSS outage reduction feature.
The call release function in the BSS releases the SCCP connection, this release may or may not
cause messages to appear on the A interface depending on the state of the SCCP entity and the
SCCP connection associated to the A channel concerned. Any associated traffic path is also switched
off in the BSC.
The release towards the Radio and A-bis (if any is required) is made immediately. In the general case
there is no Air or A-bis call release as this may have been done previously - see ref.[7].
BSC
(1)
MSC
RESET CIRCUIT
SCCP RELEASED
(2)
(3)

RESET CIRCUIT ACKNOWLEDGE
Figure 3-10
(1)
(2)
(3)
2.2.2.4
The BSC detects the need to perform the reset circuit procedure and sends the RESET
CIRCUIT message (timers are not shown) - see ref.[7].
The SCCP connection is released immediately.
The A channel and the traffic path are released on the reception of the RESET CIRCUIT
ACKNOWLEDGE (timers not shown) - see ref.[7].
SccpRel : BSC initiated SCCP release towards the MSC
This A interface releasing method is not specified by GSM but is used by the BSC when it has
attempted to use the normal methods of release, specified by GSM, and has eventually failed (see
section 2.2.2.1 CrRel : BSC initiated normal call release towards the MSC"), and when there are no
resources allocated to a transaction (see section 2.2.6 Call release trigger upon BSC detected
events").
The call release is initiated by the BSC GSM Layer 3 issuing an SCCP command (SCCP-N-DISCREQ) to the SCCP entity.
The following message sequence chart shows the expected message exchange on A interface.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
25/75
BSC
BSSAP
(1)
BSC
SCCP-N-DISC-REQ
BSC
SCCP
MSC
SCCP RELEASED
(2)
Figure 3-11
(1)
The BSC BSSAP issues the SCCP-N-DISC-REQ to the SCCP entity.
The SCCP entity (if it can) will send an SCCP RELEASED message to the MSC.
There may be no exchange of SCCP RELEASED and SCCP RELEASE COMPLETE

messages on the A interface at the SCCP level due to a possible loss of the SCCP
transaction identifier.
(2)
The MSC replies with the SCCP RELEASE COMPLETE, and should perform releasing if
there is an active transaction for the SCCP connection.
2.2.2.5
BSC initiated call release due to SCCP inactivity
The SCCP entity in the BSC performs an inactivity protocol for each active SCCP connection. Upon
detection of the SCCP inactivity reported to the layer 3 by means of SCCP N-DISC-IND (cause
SCCP inactivity timer expiry), the BSC assumes that the SCCP connection and its associated
transaction are no longer active, and performs a call release on both the Radio/A-bis interfaces (if
required) and on A interface.
The call release on A interface is performed by initiating a release of the SCCP connection (see
section 2.2.2.4 SccpRel : BSC initiated SCCP release towards the MSC").
If the transaction has (at that point in time) an A channel associated with it, the BSC will initiate a
RESET CIRCUIT procedure to release the A channel in the MSC (see section 2.2.2.3 BSC initiated
reset circuit towards the MSC" and ref.[7]).
2.2.3
BSC release towards the MS/BTS function
This function specifies the following types of release scenarios:
RF channel release :
This specifies the release protocol of a BTS RF channel.
Channel release :
This specifies the release protocol of the MS RR connection followed by the RF channel.
SAPI 0 disconnection release :

This specifies the release protocol used by the BSC when the MS has disconnected the
LapDm SAPI 0 connection on Radio interface between it and the BTS.
In addition to these functions the physical context procedure may be carried out.
Appendix shows in SDL form the dynamic behaviour of the BSC release towards the MS/BTS
function.
This section shows (by means of message sequence charts) the message flow for each scenario.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
26/75
2.2.3.1
RfRel : BSC initiated RF channel release towards the BTS
The "BSC initiated RF channel release towards the BTS" is the exchange of RF CHANNEL RELEASE
(BSC -> BTS) and RF CHANNEL RELEASE ACKNOWLEDGE (BTS -> BSC) messages. The
resource is released in the BSC when the RF CHANNEL RELEASE ACKNOWLEDGE is received.
This type of release is used under the following circumstances:
After a channel change procedure, when it is sure that the MS has successfully moved to the
new channel.
Note that a physical context procedure is performed and if the procedure has not already
been performed prior to the channel change taking place.
After the failure of the immediate assignment procedure (SDCCH channels).
The reason for using this scenario is to ensure that SDCCH channels are released quickly
during the immediate assignment procedure as the BSC has no means to distinguish the
repetition of a RANDOM ACCESS by the MS and may therefore allocate more than one
SDCCH for the same MS whilst only one SDCCH channel is going to be used.
The message sequence chart below depicts the procedure where it is preceded by a physical context
procedure.
MS
(1) (note A)
(2)
BTS
BSC
MSC
Start T9108
PHYSICAL CONTEXT REQUEST
PHYSICAL CONTEXT CONFIRM
(3)
Stop T9108
Start T_RCR_ACK
RF CHANNEL RELEASE
(4)
RF CHANNEL RELEASE ACK

Stop T_RCR_ACK
Figure 3-12
Note A : In most cases the MS should not be present on the Radio interface.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
27/75
(1)
(2)
The MS should not be present on the Radio interface whilst this scenario is in progress, as
this is the quickest method of releasing the channel and may cause the channel to be
reassigned to another mobile.
The Alcatel BSS uses this release procedure and risks the reassignment of the channel to
another MS in the case of an SDCCH channel on the failure of an immediate assignment
procedure - reference event IA0300.
BSC detects the need for a channel release and sends a PHYSICAL CONTEXT REQUEST
message to the BTS (so as to collect LapDm performance measurements) and starts T9108.
Note : (TCH only) it is possible at this point that the BTS may detect the loss of the
transcoder, this will be due to the fact that the A and A-bis/Radio interface call release is
made in parallel, as a result a CONNECTION FAILURE INDICATION (cause "Remote
transcoder failure") message may be sent by the BTS to the BSC after the timer T_SYNC
has expired in the BTS.
If this message is sent by the BTS, the BSC will ignore the message.
(3)
BTS reports within the PHYSICAL CONTEXT CONFIRM message the : Timing Advance ;
MS Power value (last transmitted to the MS) ; BS Power value (last commanded by the BTS)
; and the LapDm performance counters.
(4)
The BSC starts the RF channel release procedure by sending the RF CHANNEL RELEASE
message to the BTS, and starts the timer T_RCR_ACK to supervise the acknowledgement.
The BTS disconnects the Layer 1 & 2, frees the channel for reuse and returns the RF
CHANNEL RELEASE ACKNOWLEDGE.
The BSC stops the timer T_RCR_ACK and frees the resource for reuse.
2.2.3.2
Failure of PHYSICAL CONTEXT procedure during call release procedure (T9108

expiry)
The BTS may not respond to the PHYSICAL CONTEXT REQUEST either due to non reception of the
message (i.e. loss on A-bis), load in the BTS (causing a response problem), or whilst the BTS is
resetting or initialising or has suffered a failure.
In these cases, the timer T9108 will expire in the BSC, there is no other course of action other than to
continue with the RF channel release procedure as depicted in the scenario shown below.
The BSC should always attempt to release the RF channel in the BTS so as to keep the resources in
the BTS and BSC in step with each other.
MS
BTS
BSC
MSC
Start T9108
T9108 expiry
Note A
Start T_RCR_ACK
RF CHANNEL RELEASE
Figure 3-13
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
28/75
Note A : This behaviour is only valid for the expiry of the T9108 for a physical context procedure
which has been initiated as part of the call release procedure for the collection of LapDm
performance management data.
The system behaviour when T9108 expires during the physical context procedure for TCH
assignment and internal handover procedures may be found in ref.[2] & [13].
2.2.3.3
Failure of RF channel release procedure (T_RCR_ACK expiry)
The BSC runs the timer T_RCR_ACK during the RF channel release procedure, in case of non
response of the BTS (as specified in the preceding section).
If the timer expires the BSC will attempt to perform the RF channel release procedure again. If it fails
the second time (which is possible when the BTS is restarting) the BSC will deem the resource as
free, terminate the release and send an O&M error report with cause "RF channel release failure".
MS
BTS
BSC
MSC
Start T9108
T9108 expiry
Start T_RCR_ACK
RF CHANNEL RELEASE
(1)
(2)
(3)
T_RCR_ACK expiry
Start T_RCR_ACK
RF CHANNEL RELEASE
(4)
(5)
T_RCR_ACK expiry
Figure 3-14
(1)
The physical context procedure failed with the expiry of T9108.
(2)
The BSC attempts to release the RF channel in the BTS.
(4)
The BSC attempts to release again.
(3)
(5)
Note the given scenario is valid only for physical context procedures performed during call
release scenarios.
The RF channel release procedure failed, with the expiry of T_RCR_ACK.

The second attempt fails, so the BSC releases the resources locally and sends an O&M
error report (cause "RF channel release failure").
Note if the BTS RF channel is still allocated in the BTS, the situation will be rectified by a
local release in the BTS before the new channel activation.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
29/75
2.2.3.4
MsRel : BSC initiated channel release towards the MS/BTS
The "BSC initiated channel release towards the MS/BTS" attempts to remove the MS RR connection
using two methods. Firstly by sending the CHANNEL RELEASE message and secondly by causing (in
the MS) a radio link failure event by de-activating the sending of SACCH messages, after this
procedure the "BSC initiated RF channel release towards the BTS" is initiated.
The following message sequence chart shows the procedure where the physical context procedure is
required to be performed.
MS
(1)
BTS
CHANNEL RELEASE
(2)
DISC
UA
(3)
BSC
MSC
DATA REQ (CHANNEL RELEASE)

DEACTIVATE SACCH
Start T3109
RELEASE INDICATION
Stop T3109
Start T3111
T3111 expiry
Start T9108
(4)
RF CHANNEL RELEASE
Stop T9108
Start T_RCR_ACK
Stop T_RCR_ACK
Figure 3-15
(1)
(2)
(3)
(4)
ED
EVOLIUM
The release in the MS is initiated by the sending of the CHANNEL RELEASE message to
the MS. To reduce the cell reselection times in the mobile, there shall be a BA-range IE in
the CHANNEL RELEASE, only in Location Updating procedure (except when the message
is sent to a phase 1 MS). See section 2.1.1.1 for details.
In case of GPRS traffic suspension requested by a GPRS Class B mobile, the BSC shall first
request the GPRS traffic resumption before to send the RR CHANNEL RELEASE message
to the MS. See section 2.1.4 for details.
The DEACTIVATE SACCH message is sent to the BTS on the main SACCH and the timer
T3109 is started.
The BTS on reception of the DEACTIVATE SACCH will maintain the transcoder alarm
detection mechanism for each channel involved in this connection - see section 2.3.4
Interaction of BTS transcoder alarm detection mechanism and call release".
See section 2.2.3.5 SapiRel : BSC initiated release towards the MS/BTS due to MS
initiated SAPI 0 disconnection".
The BSC initiates the RF channel release procedures - See section 2.2.3.1 "RfRel : BSC
initiated RF channel release towards the BTS.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
30/75
2.2.3.4.1
No RELEASE INDICATION received during channel release procedure (T3109

EXPIRY)
This situation may occur when:
the MS has not received the CHANNEL RELEASE message,
the MS is not present on the Radio interface,
the LapDm entities in the MS and BTS are in such a state such that they can not pass
acknowledged data.
On T3109 expiry, the MS should have detected the radio link failure condition (due to the lack of
SACCH frames on the main SACCH), in which case the MS will perform a local release of the LapDm
and deem the connection terminated.
When T3109 expires the RF channel release procedure is initiated by the BSC. This procedure may
be preceded by a physical context procedure. The running of T3111 is not required in this case.
The following message sequence chart shows the normal release with no RELEASE INDICATION
(i.e. T3109 expiry).
MS
(1)
BTS
CHANNEL RELEASE
MSC
DATA REQ (CHANNEL RELEASE)

DEACTIVATE SACCH
(2)
(3)
BSC
Start T3109
Note A
(4)
T3109 expiry
Start T9108
(5)
RF CHANNEL RELEASE
Stop T9108
Start T_RCR_ACK
Stop T_RCR_ACK
Figure 3-16
Note A
MS detects radio link failure and performs local end release of LapDm.
(1)
BSS sends CHANNEL RELEASE message but the MS either does not receive it or the
LapDm in the MS can not accept it.
(2)
(3)
ED
EVOLIUM
BSC commands the stopping of the SACCH messages and ignores the transcoder alarms.
MS starts to detect the radio link failure condition.
MS has detected the radio link failure condition (before expiry of T3109) and performs the
local release.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
31/75
(4)
T3109 expires in the BSC (any ERROR INDICATION message received from the BTS with
cause value set to "Timer T200 expired N200+1 times" - and due to the repetition of the
CHANNEL RELEASE message on the Radio Interface - is ignored whilst T3109 is running).
(5)
The BSC initiates the RF channel release procedures - see section 2.2.3.1 "RfRel : BSC
2.2.3.5
SapiRel : BSC initiated release towards the MS/BTS due to MS initiated SAPI 0
disconnection
The MS can, as part of its release procedures, send an DISC (SAPI 0) to the BTS. The BTS LapDm
entity will respond with a UA (SAPI 0) and inform the BSC that the SAPI 0 connection has been
released by the MS by sending to the BSC a RELEASE INDICATION (SAPI 0) message.
The MS may send the DISC (SAPI 0) as part of the normal release on Radio interface (i.e. after it has
received the CHANNEL RELEASE message) or of its own accord (when disconnecting off the RR
connection).
The BSC on reception of the RELEASE INDICATION (SAPI 0) starts the timer T3111 and awaits the
expiry of this timer before initiating the release of the RF channel (see section 2.2.3.1 RfRel : BSC
initiated RF channel release towards the BTS"). The BSC sets the T3111 timer so that the BTS can
send the UA to the MS before the BSC releases the RF resources.
The message sequence chart below shows the behaviour of the BSC when it receives the RELEASE
INDICATION (SAPI 0) when initiated by the MS.
See the section 2.2.3.4 "MsRel : BSC initiated channel release towards the MS/BTS for the
message sequence chart where this procedure is initiated as part of the BSC initiated release of the
MS connection.
MS
(1)
BTS
DISC
UA
(2)
BSC
MSC
RELEASE INDICATION
Start T3111
T3111 expiry
(3)
RF CHANNEL RELEASE
Start T9108
Stop T9108
Start T_RCR_ACK
Stop T_RCR_ACK
Figure 3-17
(1)
The MS initiates a release of the SAPI 0 connection by sending a DISC (SAPI 0).
The BTS informs the BSC of the release by sending the RELEASE INDICATION (SAPI 0)
and sends a UA to the MS to confirm the release of the SAPI 0 connection.
It must be noted that the UA may not be sent immediately at this point in time, it may be
awaiting transmission in the BTS due to the timing of the TDMA frame.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
32/75
(2)
The BSC upon reception of the RELEASE INDICATION (SAPI 0) starts the timer T3111 and
awaits for its expiry.
The UA in the BTS should have been transmitted whilst T3111 is running.
(3)
The BSC initiates the RF channel release procedures - see section 2.2.3.1 "RfRel : BSC
2.2.4
BTS call release function
The BTS takes no autonomous release actions during the release of an MS RR connection (with the
exception of LapD failure, remote transcoder alarm and O&M reasons). The primary functions are:
to relay the CHANNEL RELEASE message from the BSC to the MS,
to deactivate the SACCH when commanded to do so by the BSC (by means of the
DEACTIVATE SACCH or RF CHANNEL RELEASE message),
and to inform of the release of LapDm SAPI 0 (by sending to the BSC the RELEASE
INDICATION (SAPI 0) when a DISC (SAPI 0) is received from the MS).
The release of the RF channel is performed locally in the BTS when the RF CHANNEL RELEASE
message is received. The BTS sends a RF CHANNEL RELEASE ACKNOWLEDGE message to the
BSC and frees the channel. The SDL diagrams in Appendix show the precise order in which these
actions take place.
2.2.4.1
BTS initiated call release due to LapD failure
When the BTS detects a failure of the LapD connection at layer 2 (ref.[11]), the BTS will:
1) put the LapDm in null state (see ref.[8]); no more SACCH are sent on the radio,
2) Start T3109.
All the mobiles connected will detect a radiolink failure and perform a local release.
The BTS will wait T3109 before authorising LapD reestablishment.
MS"
MS'
BTS
BSC
note A
start T3109
T3109 expiry
MSC
----------SABME--------->
<------------UA-------------
ERROR REPORT
------------------------------>
note B
6
6
figure 3-18
----CLEAR REQUEST'---->
----CLEAR REQUEST"--->
Note A : Detection of LapD link failure - see ref.[11] for details.

Note B : The TRX which sent the ERROR REPORT is re-initialised by the BSC - see ref.[5].
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
33/75
TRX detects that the A-bis link has failed.
T3109 expires and the BTS attempts to re-establish the LapD connection.
4
5
6
2.2.4.2
SACCH frames sent to all MSs are stopped, LapDm is pu into NULL state and T3109 is
started.
The TRX ensures that the LapD link can not be re-established.
The ERROR REPORT (cause "O&M intervention") is sent to the BSC.
The TRX awaits completion of the re-initialisation sequence performed by the BSC (ref.[5]).
The BSC releases the RF resources for the connections on the associated TRX locally and
performs the call release sequence towards the MSC.
BTS initiated call release due to O&M intervention
When the O&M entity in the BTS requests a restart of the BTS, the affected TRXs will immediately
stop the sending of all Radio interface frames.
It is necessary to stop the sending of SACCH frames for a period of T3109 so that any MSs which are
still connected to the BTS will detect a radio link failure condition and therefore perform a local end
release.
The sequence of events is as follows:
1)
2)
3)
4)
When the O&M event is received, the sending of all Radio interface frames are disabled for
all active connections.
The BTS will start the timer T3109 as soon as possible within its reset sequence.
The point within the reset sequence at which it is started is implementation dependant,
however it should be as close as possible to the O&M event, so as to minimise the period of
time which the channel is out of use.
If the BTS has performed the reset sequence before the timer T3109 expires. The BTS will
wait until the timer expires before carrying out action 4).
Whilst the BTS is in this state the LapD RSL link is not allowed to be re-established.
Once the timer T3109 expires, the re-establishment of the LapD RSL link will be attempted,
only then will the ERROR REPORT (with cause "O&M intervention") be sent to the BSC. The
TRX then awaits for BSC to perform the (re) initialisation of the TRX - see ref.[5].
The BSC will release the RF resources on the associated TRX locally and initiate "BSC
initiated normal call release towards the MSC" protocol.
If this procedure runs for a TRX controlling a BCCH, one may find that the MSs camped on the cell
may perform the cell re-selection procedure, as during this procedure no BCCH messages will be sent
until the (re) initialisation of the TRX is completed.
2.2.5
MS Call release function
The MS may release the RR connection using two methods:

1)
by initiating a radio link failure event in the BSS (at layer 1),
2)
by disconnecting the LapDm SAPI 0 connection by the sending of a DISC frame (SAPI 0) to
the BSS (layer 2).
2.2.5.1
MS initiated radio link failure release
The radio link failure mechanism may be affected by the MS stopping the transmission of SACCH
frames on the main DCCH. This may simply mean that the MS just disappears (i.e. switches off,
catastrophic failure, etc.). In this case the BTS will start to detect that the MS has disappeared. Once
the BTS counts a certain number of missing SACCH frames the radio link failure algorithm sends to
the BSC the CONNECTION FAILURE INDICATION (cause "Radio link failure"). The BSC then
initiates the "BSC initiated normal call release towards the MSC" and initiated the "BSC initiated RF
channel release towards the BTS" procedures towards all the channels involved in this connection.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
34/75
The scenario below shows the BSS behaviour on detection of the radio link failure - see also event
N0700 in this document.
MS
(1)
BTS
BSC
MSC
Note A
Note A
(2)
Note A
CONNECTION FAILURE INDICATION
(3)
RF CHANNEL RELEASE
(4)
Start T_RCR_ACK
CLEAR REQUEST
Start T9104
Figure 3-19
Note A : The BTS counts the number of missing SACCH frames.
(1)
The MS disappears.
(3)
The BTS detects the radio link failure condition and sends the CONNECTION FAILURE
INDICATION (cause "Radio link failure") to the BSC.
(2)
(4)
The BTS starts to detect the radio link failure condition.
The BSC on reception initiates a call release to the MSC - see section 2.2.2.1 CrRel : BSC
initiated normal call release towards the MSC - and a release towards the BTS for the
channel involved in this connection - see section 2.2.3.1 RfRel : BSC initiated RF channel
release towards the BTS.
Note in the case of channel change procedures, the BSC will ignore the CONNECTION
FAILURE INDICATION (cause "Radio link failure") message. For more details, see ref.[2],
[12] & [13].
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
35/75
2.2.5.2
MS initiated SAPI 0 LapDm disconnection
The MS sends the DISC frame on SAPI 0 as part of the "BSC initiated channel release towards the
MS/BTS" (i.e. when it receives the CHANNEL RELEASE message). The MS may also initiate this
procedure when the call is disconnected abnormally (i.e. due to events in the MS).
The scenario below shows the BSS behaviour on A, A-bis and Radio interfaces upon detection of the
release of LapDm SAPI 0.
MS
BTS
DISC
(1)
(2)
UA
(3)
BSC
RELEASE INDICATION
(SAPI 0)
Start T3111
MSC
CLEAR REQUEST
Start T9104
T3111 expiry
RF CHANNEL RELEASE
(4)
Figure 3-20
(1)
(2)
MS releases the LapDm by sending DISC at SAPI 0.
The BTS relays the event to the BSC by sending a RELEASE INDICATION (SAPI 0) to the
BSC.
The BSC releases immediately towards the MSC see section 2.2.2.1 CrRel : BSC initiated
normal call release towards the MSC.
Note during channel change procedures the RELEASE INDICATION (SAPI 0) may be
ignored - see ref.[2], [12] & [13].
(3)
(4)
2.2.6
The BSC starts T3111 so that the UA, which is to be sent to the MS by the BTS, can be sent
before releasing the RF Channel.
The UA is sent by the BTS to the MS at LapDm layer 2.
The timer T3111 expires and the BSC initiates a release towards the BTS for the channel
involved in this connection - see section 2.2.3.1 RfRel : BSC initiated RF channel release
towards the BTS.
Call release trigger upon BSC detected events
This section contains a set of tables. Each table belongs to a specific L3 function (procedure) and
defines the messages (and therefore the protocol required) sent to each of the call release functions
upon the reception of each event in the procedure. See SDL for behaviour - APPENDIX.
2.2.6.1
Notation
This section defines the notation used to specify the call release and resource release scenarios.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
36/75
The following table contains some abbreviations used in the notation.

Abbr
Description
A physical context procedure is to be performed on the main channel before

the RF channel release procedure.
The absence of a P means that no physical context procedure will be

performed on the main channel.
Aint
Abbreviation for "A interface".
OC
Abbreviation for "Old RF Channel(s)"
NC
RFC
NA
Used in notation during channel change procedure to represent the channel

to which the MS was connected.
Abbreviation for "New RF Channel(s)".
Used in notation during channel change procedure to represent the channel

to which the MS is to be connected to.
Abbreviation for the currently in use "RF Channel".
Used in notation when no channel change is in progress or when there is

only one channel allocated to the transaction.
Abbreviation for "Not Applicable".
Table 3-1 : Abbreviations
The following scenarios control the release towards the MS/BTS.

Scenario Name
Description
MsRel
This release scenario is specified in section 2.2.3.4 "MsRel : BSC

initiated channel release towards the MS/BTS on page 30.
A release of both the MS and the BTS is to be performed. This

scenario is always specified with a cause value contained in Table
3-3. This cause value will be sent in the CHANNEL RELEASE
message.
SapiRel
This release scenario is specified in section 2.2.3.5 "SapiRel :

BSC initiated release towards the MS/BTS due to MS initiated
SAPI 0 disconnection on page 32.
T3111 is started and allowed to expire before performing the RF
channel release procedure.
RfRel
The release scenario specified in section 2.2.3.1 "RfRel : BSC

initiated RF channel release towards the BTS on page 27 will be
triggered for the given channel.
LocRel
This scenario causes in the BTS a local release (i.e. no message

exchange appears on A-bis interface) of all the radio channels
involved in this connection.
The release (if any) that is presently being performed towards the
MS/BTS is to be cancelled and the RF channels concerned are to
be released locally (i.e. without exchange of messages).
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
37/75
BscRel
This scenario causes in the BSC a local release of all the radio
channels involved in this connection.
The RF channels are considered to be already released in the BTS.
ActRel
This scenario causes the release of the new channel due to the
failure of a channel activation procedure.
For the channel involved in the activation procedure :
- If CHAN ACT NACK has been received : LocRel is performedIf nothing has been received : RfRel is performed
This means that NO action is to be taken.

Table 3-2 : Scenarios towards the MS/BTS
The following table contains the cause value names and their abbreviations.
Cause value
abbreviation
nr
CHANNEL RELEASE GSM Cause values names

Normal event
ar_un
Abnormal release, unspecified
ar_te
Abnormal release, timer expired
ar_na
Abnormal release, no activity on the radio path
prempt
Pre-emptive release
Table 3-3 : Cause values in CHANNEL RELEASE message
To control the release and actions towards the MSC the scenarios shown in table 3-4 are used.
Message
abbreviation
Description
MscRel
This message causes the scenario specified in section 2.2.1.1

"MscRel : MSC initiated normal release towards the BSS on page
16.
Release caused by MSC (i.e. reception of CLEAR COMMAND).
CrRel

"CrRel : BSC initiated normal call release towards the MSC on
page 20.
Release initiated from BSC by sending CLEAR REQUEST with a

cause specified in table 3-5.
SccpRel

"SccpRel : BSC initiated SCCP release towards the MSC on
page 25.
Release the SCCP connection.
ED
EVOLIUM
03
HOF
Send HANDOVER FAILURE message to the MSC with a cause

specified in table 3-5.
AF
Send ASSIGNMENT FAILURE message with a cause specified in

table 3-5.
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
38/75
AFcic
X
Send ASSIGNMENT FAILURE message with a cause specified in

table 3-5 and put the associated circuit in idle state. No explicit
clearing sequence is performed to free the circuit.
This means that No release is performed to the MSC.
Table 3-4 : Scenarios towards the MSC
The following table lists all the combined cause values that appear in the CLEAR REQUEST,
HANDOVER FAILURE and ASSIGNMENT FAILURE messages.
Cause value
abbreviation
Cause
CAUSE VALUES
value (hex)
rimf
00
Radio interface message failure
rif
01
Radio interface failure
o&m
07
O&M intervention
revoc
0A
Radio interface failure - reversion to old channel
eqfl
20
Equipment failure (note 1)
nrra
21
No radio resource available
cicun
22
Requested terrestrial resource unavailable
bsne
25
BSS not equipped
incel
27
Invalid cell
pre-empt
29
Pre-emption
raun
30
Requested transcoding/rate adaptation unavailable
spun
33
Requested speech version unavailable
cans
40
Ciphering algorithm not supported
cicaa
50
Terrestrial circuit already allocated
iemis
52
IE or field missing
inval
53
Incorrect value
perr
60
Protocol error between MSC and BSC
Table 3-5 : Cause values on A interface

Note 1 : This cause on the A interface can be due to an O&M intervention on the transcoder. The
BTS will detect the loss of synchronisation with the TC: see N0800.
The following table provides a list of call/resource release notation and their corresponding
descriptions. The notation is used to simplify what would be a long tedious description.
For each call release, resource release or action (handover failure or assignment failure) scenario
there is an event number allocated.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
39/75
The event number is made up of 1 to 3 letters followed by a four digit number. An event number is
allocated in this document to events specified in ref.[6], [2], [1], [3], [12] & [13]. For each event number
a scenario is specified using the notation as shown in the table of examples below.
Example
Description
Example during channel change where there are two RF channels
allocated to the connection.
Aint CrRel o&m

OC MsRel ar_un P
On A interface perform a BSC initiated call release by sending a CLEAR

REQUEST message with the cause "O&M Intervention".
On the old RF channel perform a release of the MS and BTS by sending a

CHANNEL RELEASE message with the cause "Abnormal release,
unspecified", a physical context procedure is required to be performed.
On the new channel perform an RF channel release procedure, no
physical context procedure is required.
NC RfRel
Aint HOF revoc
Channel change example.
On the A interface send a HANDOVER FAILURE message to the MSC

with cause "Radio interface failure - reversion to old channel".
On the old channel no release is required.
OC X
On the new channel an RF channel release procedure is to be initiated

preceded by a physical context procedure.
NC RfRel P
Aint SccpRel
No channel change is in progress in this example.
RFC MsRel ar_un P
Aint CrRel rif

RFC LocRel
The A interface SCCP connection is released.
On the RF channel perform a release of the MS and BTS by sending a

CHANNEL RELEASE message with the cause "Abnormal release,
unspecified", a physical context procedure is required to be performed.
No channel change is in progress in this example.
On A interface perform a BSC initiated call release by sending a CLEAR

REQUEST message with the cause "Radio interface failure"
Release the RF channel locally.
Table 3-6 : Examples
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
40/75
2.2.7
Standard release scenarios
The following events and call release scenarios deal with cases where the MS is connected and a
call/resource release scenario has not been started.
EVENT
NO
EVENT DESCRIPTION
N0100
Reception of ERROR INDICATION with cause values: Timer

T200 expired (N200+1) times ; Unsolicited DM response,
Multiple frame established state ; and Sequence error.
Aint CrRel rif

RFC MsRel ar_na P
Note 3
N0200
Reception of RELEASE INDICATION (SAPI 0).
Aint CrRel rif

RFC SapiRel P
Note 3
N0300
Reception of O&M initiated release.
Aint CrRel o&m

RFC MsRel ar_un P
Note 3
N0400
Reception of ERROR REPORT cause "O&M intervention".
Aint CrRel rif

RFC LocRel
N0500
Primitive SCCP-N-DISC-IND - see Note 2- being sent by the

SCCP entity.
Aint SccpRel
RFC MsRel ar_un P
Note 3
N0600
Reception of CLEAR COMMAND.
Aint MscRel
RFC MsRel nr P
Note 3
N0700
Reception of CONNECTION FAILURE INDICATION (cause

Radio link failure).
Aint CrRel rif

RFC RfRel P
Note 3
N0800
Reception of CONNECTION FAILURE INDICATION (cause

Remote transcoder failure).
Aint CrRel eqfl

RFC MsRel ar_un P
Note 3
N0900
Reception of RESET or internally detected Reset - see

ref.[6].
Aint SccpRel
RFC MsRel ar_un P
Note 3
N1000
Reception of RESET CIRCUIT - see ref.[7].
Aint SccpRel
RFC MsRel ar_un P
Note 3
N1100
Reception of LapD failure.
Aint CrRel rif

RFC LocRel
N1200
Reception of ERROR REPORT (SAPI 0, cause "Message

sequence error") for an activated channel in the BSC.
Aint CrRel rif

RFC MsRel ar_un P
Notes 1 & 3
N1400
Mismatch between BTS (idle resource) and BSC (busy

resource) concerning Interference measurement reporting.
Aint CrRel rif

RFC BscRel
N1500
Mismatch between BTS (busy resource) and BSC (idle

resource) concerning channel activation.
Aint NA
ED
EVOLIUM
03
RELEASED
BEHAVIOUR
RFC LocRel
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
41/75
N1600
Loss of the MS associated to the SDCCH/TCH channel (BTS

and BSC with busy resources) - see ref.[16]: autocleaning
procedure.
Aint CrRel rif
N1700
Pre-emption of an on-going call due to higher priority

connection request see ref.[16]: pre-emption procedure
Aint
RFC RfRel P
Note 3
RFC
CrRel pre-empt
MsRel prempt P
Table 3-7
Note 1 : The sending of the CHANNEL RELEASE message in this case will cause the BTS to send
another ERROR REPORT (SAPI 0, cause "Message sequence error"). This is not a misbehaviour as it is foreseen that the BTS will send this message in the future for other
reasons which would require the CHANNEL RELEASE message to be sent to the MS.
Note 2 : If there is a DTAP message in the corresponding internal SCCP-N-DISC-IND message, it
will be sent to the MS before the release is performed.
The exchange of SCCP RELEASED and SCCP RELEASE COMPLETE messages on the A
interface may or may not occur (see section 2.2.2.4 SccpRel : BSC initiated SCCP release
towards the MSC). If the reason for the SCCP-N-DISC-IND is "SCCP inactivity timer expiry"
(see sections 2.2.1.4 MSC initiated SCCP release towards the BSS and 2.2.2.5 BSC
initiated call release due to SCCP inactivity), then a reset circuit procedure may be initiated
- see ref.[7].
Note 3 : The physical context procedure is not initiated if it has already been performed prior to the
initiation of the call release procedure.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
42/75
2.2.8
Scenarios during immediate assignment
The reception of CLEAR COMMAND, CONNECTION FAILURE INDICICATION (cause Remote

transcoder failure), RESET CIRCUIT, and SCCP-N-DISC-IND (cause "SCCP inactivity timer expiry"),
are impossible events during this procedure.
For message ignoring and the handling of unexpected messages during this procedure, see ref.[1].
EVENT
NO
EVENT DESCRIPTION
BEHAVIOUR
IA0101
CHAN ACT NACK all causes.
Aint NA
RFC LocRel
IA0200
Expiry of T9103. I.e. non reaction of BTS during channel

activation procedure.
Aint NA
RFC RfRel
IA0300
Expiry of T3101. No establishment of channel after having

sent the IMMEDIATE ASSIGNMENT message to the MS.
Aint NA
RFC RfRel P
Note 1
IA0301
ESTABLISH INDICATION without a layer 3 message or

with a L3 message containing a protocol discriminator
different of RR, CC, MM, or a L3 message with skip
indicator (RR) different of zero..
Aint NA
RFC MsRel ar_un P
IA0400
Expiry of T9105 after the sending of the SCCP-NCONNECT- REQ.
Aint SccpRel
Note 5
RFC MsRel ar_te P
IA0500
Reception of an SCCP-N-DISC-IND.
Aint NA
RFC MsRel nr P
IA0600
Whilst the SCCP connection establishment phase of the

immediate assignment procedure a releasing event
occurred on the Radio/A-bis interface.
Aint SccpRel
Note 4
RFC see Note 3
IA0700
CHANNEL ACTIVATION ACKNOWLEDGE after IA0900.
Aint NA
RFC RfRel P
IA0702
CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE

all causes after IA0900.
Aint NA
RFC LocRel
IA0703
T9103 expiry after IA0900.
Aint NA
RFC RfRel
IA0800
ESTABLISH INDICATION with or without layer 3

message after IA0901.
Aint NA
RFC MsRel ar_un P
IA0801
T3101 expiry after IA0901.
Aint NA
RFC RfRel P
Note 1
IA0900
Reception of RESET or internally detected reset during

RF channel activation (T9103 is running). The outcome of
the activation is awaited.
Aint NA
RFC await IA070X
I.e. no response has been received from the MSC.
ED
EVOLIUM
03
See Note 2.
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
43/75
IA0901
Reception of RESET or internally detected reset during

MS establishment procedure (T3101 is running). The
outcome of the establishment is awaited.
Aint NA
RFC await IA080X
Table 3-8
Note 1 : Due to performance problems with the availability of SDCCH channels, the RF channel
release protocol is chosen instead of the normal release protocol.
Note 2 : If the SCCP RELEASED message contains a layer 3 DTAP message, the BSC proceeds as
follows:
-
if the DTAP is for SAPI 0, it is transmitted towards the MS prior to any possible
CHANNEL RELEASE, (Note the message could be a CM SERVICE REJECT or
LOCATION UPDATING REJECT),
if the DTAP is for SAPI 3 and SAPI 3 connection is established, it is transmitted
towards the MS prior to any possible CHANNEL RELEASE,
if the DTAP is for SAPI 3 and SAPI 3 connection is not established, it is discarded.
If the message is not a DTAP message, it is discarded.
Note 3 : The release that is to be performed between the BSC, BTS and MS is made immediately
after the event on the Radio/A-bis was detected, and is dependant on the event which was
detected during the period when the SCCP connection establishment was awaited. See
release scenarios in the section 2.2.7 Standard release scenarios" for the required scenario
on the Radio & A-bis interface.
Note 4 : The release on the A interface is made when the SCCP is established.
Note 5 : The SCCP entity (if it can) will send a SCCP RELEASED message to the MSC.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
44/75
2.2.9
Scenarios during normal assignment
The reception of CONNECTION FAILURE INDICATION (cause Remote transcoder failure), is

impossible on the Old (SDCCH) channel during this procedure.
For message ignoring and unexpected message handling during this procedure refer to ref.[2].
In-call modification is specified in the section 2.2.13 Scenarios during channel modification".
In the TCH assignment procedure (SDCCH -> TCH), no TCH channel or CIC has been allocated yet
to the connection.
In the SDCCH assignment procedure (TCH -> SDCCH), a TCH and a CIC are already allocated.
The reception of RESET CIRCUIT will cause the connection to be released.
EVENT
NO
EVENT DESCRIPTION
BEHAVIOUR
A0100
(Old channel) ASSIGNMENT FAILURE from MS.
Aint AF revoc
Note 1
OC X
NC RfRel P
A0201
(New channel) CHAN ACT NACK cause "Requested

transcoding / rate adaptation not available" for a Data call
Aint AF raun
OC X
NC ActRel
A0202
CHAN ACT NACK cause "Radio resource not available" or

"Protocol error".
Aint AF rif
OC X
NC ActRel
A0203
CHAN ACT NACK cause "O&M Intervention".
Aint AF rif
OC X
NC ActRel
A0204
CHAN ACT NACK cause

implemented" - Note 5.
A0205
CHAN ACT NACK received with an unexpected cause value.
Aint AF rif
OC X
NC ActRel
A0206
(New channel) CHAN ACT NACK cause "Requested

transcoding / rate adaptation not available" for a Speech call
Aint AF spun
"Encryption
algorithm
not
Aint AF cans
OC X
NC ActRel
OC X
NC ActRel
A0300
(New channel) Expiry of T9103. I.e. non reaction of BTS

during Channel activation procedure.
Aint AF rif
OC X
NC ActRel
A0400
(New channel) Reception of ASSIGNMENT COMPLETE

from the MS.
Aint X
OC RfRel
Expiry of T3107. Failure to receive ASSIGNMENT

COMPLETE or ASSIGNMENT FAILURE (T9110 is running).
Aint AFcic rimf

OC RfRel
NC RfRel P
A0500
ED
EVOLIUM
03
RELEASED
Note 6
NC X
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
45/75
A0600
Expiry of T9110 after event A0500. In this case the BSC has
sent an ASSIGNMENT FAILURE to the MSC.
Aint SccpRel
Note 2
A0700
ASSIGNMENT REQUEST message error :
Aint AF perr
OC X
- Channel type combination is not supported (signalling on

TCH),
- invalid data rate (see event A0707),
- reserved values,
- CIC is missing, for a TCH Assignment procedure,
- CIC present for an SDCCH Assignment procedure.
- IE identifier is inconsistent (i.e. missing mandatory field,

Encryption Information, Classmark Information 1 or 2, or
Cell Identifier (Serving cell)),
- erroneous IE contents (Encryption Information).
A0703
Aint AF bsne
OC X
CIC unknown to BSS.
Note : an UNEQUIPPED CIRCUIT message may have been

sent to the MSC (if allowed by O&M parameter).
A0705
Assignment error condition :
Aint AF cicun
OC X
A0706
Aint AF cicaa
OC X
CIC is Blocked by O&M.
CIC is in use on another connection.
Note 7
Assignment message error condition :
A0707
Aint AF raun
OC X
Half rate data requested,
or 1.2/0.075 kbit/s T data rate requested on full rate channel,

or 6 kbit/s NT data rate on a full rate channel.
A0709
Aint AF spun
OC X
A0710
CIC indicates timeslot 0
Aint AF cicun
A0800
The assignment can not be performed due to lack of radio

resources.
Aint AF nrra
OC X
A0801
Queuing abnormal condition :
Aint CrRel nrra

OC X
Note 4
A0802
Queuing abnormal condition :
Aint AF nrra
OC X
A0803
SDCCH congestion condition :
Aint AF nrra
OC X
ED
EVOLIUM
"Requested speech version unavailable" (none of the codepoints is supported in the cell).
OC X
Timer T11/T11_FORCED expiry, or T11/T11_FORCED

already expired when removing Hold State.
ASSIGNMENT REQUEST is removed due to a higher priority
ASSIGNMENT REQUEST or HANDOVER REQUEST
message.
No RF channel is available for SDCCH assignment.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
46/75
Reception of another ASSIGNMENT REQUEST, after a

previous refusal where the ASSIGNMENT FAILURE ("cause
Radio interface message failure") was sent (A0500).
Aint AF rimf
A1000
Reception of CLEAR COMMAND whilst T9110 is running.
Aint MscRel
Note 2
A1001
Reception of SCCP-N-DISC-IND during T9110 is running see Note 3.
Aint SccpRel
Note 2
A1002
Reception of SCCP-N-DISC-IND during T3107 is running.
Aint SccpRel
A0900
Note 2
OC MsRel ar_un P
NC MsRel ar_un P
Table 3-9
Note 1 : The ASSIGNMENT FAILURE will contain the OIE RR cause, contained in the received
ASSIGNMENT FAILURE from the MS.
Note 2 : The Old and New channel have already been released - see event A0500.
Note 3 : If the reason for the SCCP-N-DISC-IND is SCCP inactivity timer expiry (see sections
2.2.1.4 MSC initiated SCCP release towards the BSS and 2.2.2.5 BSC initiated call
release due to SCCP inactivity), then a reset circuit procedure may be performed - see
ref.[7].
The exchange of SCCP RELEASED and SCCP RELEASE COMPLETE messages on the A
towards the MSC).
Note 4 : The MS is not released at this point, it is released on either the reception of the CLEAR
COMMAND or at the end of the A interface releasing scenario.
Note 5 : The BSC has detected a database error between the BTS & BSC. In this case performance
counters are incremented and an O&M error report is generated.
Note 6 : In the case of a TCH to SDCCH assignment, the CIC is considered released at this point in
the BSC. It can then be reallocated by the MSC.
Note 7 : In the case of a TCH assignment only, the BSC detects a CIC resource mismatch between
the BSC and the MSC: the MSC considers the CIC as idle while the BSC considers it as
busy (error case). As the BSC is not responsible for the CIC resource allocation on A
interface, the BSC triggers an internal resource reset procedure related to this CIC (see
section 2.2.2.1.4). The CIC is then considered as idle in the BSC.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
47/75
2.2.10 Scenarios during internal channel changes

The reception of RESET CIRCUIT and CONNECTION FAILURE INDICATION (cause Remote
transcoder failure) is impossible on an SDCCH channel during this procedure.
For message ignoring and unexpected message handling during this procedure, refer to ref.[13].
2.2.10.1 Scenarios during internal handover
EVENT
NO
EVENT DESCRIPTION
BEHAVIOUR
IH0100
HANDOVER FAILURE on old channel.
Aint X
OC X
NC RfRel P
IH0200
CONNECTION FAILURE INDICATION cause Handover

access failure.
Aint X
OC X
NC RfRel P
IH0300
ASSIGNMENT FAILURE from MS on old channel.
Aint X
OC X
NC RfRel P
IH0400
Expiry of T3107 (intra-cell handover) or T3103 (inter-cell

handover).
Aint CrRel rimf

OC RfRel P
Note 1
NC RfRel P
IH0501
Same as ICC0100
IH0600
Same as ICC0100
IH0700
HANDOVER COMPLETE or ASSIGNMENT COMPLETE

from MS on new channel and the sending of HANDOVER
PERFORMED to the MSC
Aint X
OC RfRel P
Note 1
IH0800
T3103 expiry after reception of CONNECTION FAILURE

INDICATION on the new channel side (cause Handover
access failure) - see IH0200.
Aint CrRel rimf

OC MsRel ar_te P
Note 1
IH0900
Reception of SCCP-N-DISC-IND whilst T3107 or T3103 is

running.
Aint SccpRel
NC X
OC
MsRel ar_un P
Note 1
NC MsRel ar_un P
Table 3-10
Note 1 : The physical context procedure is only performed if it has not been performed prior to the
internal channel change.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
48/75
2.2.10.2 Scenarios during directed retry

EVENT NO
EVENT DESCRIPTION
BEHAVIOUR
DR0101
Same as IH0100
DR0206
Same as ICC0100
DR0207
Same as ICC0100
DR0208
Same as ICC0100
DR0209
Same as ICC0100
DR0300
Same as IH0200
DR0401
Same as ICC0100
DR0500
Same as IH0700
DR0600
Expiry of T3103. Failure to receive HANDOVER

COMPLETE or HANDOVER FAILURE. T9110 is running.
Aint AFcic rimf

OC RfRel P
Note 3
NC RfRel P
DR0601
In this case T3103 has expired after reception on the New

channel of the CONNECTION FAILURE INDICATION
(cause "Handover access failure") message. The New
channel has already been released - see event DR0300.
Aint AFcic rimf

OC RfRel P
Note 3
DR0700
Reception of SCCP-N-DISC-IND or expiry of T9110 after

event DR0600. In this case the BSC has previously sent an
ASSIGNMENT FAILURE to the MSC - see note 2.
Aint SccpRel
Note 1
DR0701
Reception of CLEAR COMMAND after event DR0600. In

this case the BSC has previously sent an ASSIGNMENT
FAILURE to the MSC.
Aint MscRel
Note 1
DR0801
Aint AF nrra
OC X
DR0900
Same as IH0900
Internal seizure failure of RF channel.
Table 3-11
Note 1 : The Old and New channel have already been released - see event DR0600.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
49/75
Note 2 : The exchange of SCCP RELEASED and SCCP RELEASE COMPLETE messages on the A
towards the MSC).
Note 3 : The physical context procedure is only performed if it has not been performed prior to the
internal channel change.
2.2.11 Miscellaneous scenarios during normal assignment and internal channel changes
The following call release scenarios cater for New Channel (NC) and Old Channel (OC) call release or
resource release scenarios as a result of unexpected events received during internal BSS channel
changes (this covers the normal assignment and internal handover procedures).
New Channel call release scenarios
EVENT
NO
EVENT DESCRIPTION
BEHAVIOUR
NC0100
The reception of an A interface event leading to the

aborting of the physical context procedure on the Old
channel
NC LocRel
NC0200
The reception of CHAN ACT ACK whilst the call has been
already cleared on the Old channel.
NC RfRel P
NC0202
Same as ICC0100.
NC0203
Same as ICC0100.
NC0300
The reception of an ERROR REPORT cause O&M

intervention from the TRX handling the New channel
NC LocRel
Table 3-12
EVENT
NO
EVENT DESCRIPTION
BEHAVIOUR
ICC0100
CHAN ACT NACK (all causes) or T9103 expiry during

activation of (one of) the new channel(s)
Aint X
OC X
NC ActRel
Table 3-13
Old Channel call release scenarios
EVENT
NO
EVENT DESCRIPTION
BEHAVIOUR
OC0100
Reception of ERROR REPORT (cause O&M

intervention) during the channel change procedure on the
Old Channel
OC LocRel
Table 3-14
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
50/75
2.2.12 Scenarios during external channel changes

The reception of RESET CIRCUIT, CONNECTION FAILURE INDICATION (Remote transcoder
failure) is impossible on SDCCH connections.
For message ignoring and unexpected message handling during this procedure see ref.[12].
2.2.12.1 Target BSC scenarios
EVENT
NO
EVENT DESCRIPTION
BEHAVIOUR
EHT0101
CHAN ACT NACK cause Requested transcoding / rate

adaptation not available for data call.
Aint HOF raun

Note 5
NC ActRel
EHT0102
CHAN ACT NACK cause Encryption algorithm not

implemented.
Aint HOF cans

Note 5
NC ActRel
EHT0103
CHAN ACT NACK all other causes than EHT0101,

EHT0102, EHT0106..
Aint HOF rif

Note 5
NC ActRel
EHT0104
CHAN ACT ACK is received after the reception from the

MSC of a CLEAR COMMAND message
Aint X
NC RfRel P
EHT0106
CHAN ACT NACK cause Requested transcoding / rate

adaptation not available for speech call.
Aint HOF spun
EHT0200
Expiry of T9103. Channel activation failure (New

channel).
Aint HOF rif

Note 5
NC ActRel
EHT0300
Expiry of T9113. Awaiting HANDOVER COMPLETE.
Aint CrRel rimf

NC MsRel ar_te P
EHT0400
CONNECTION FAILURE INDICATION cause Handover

access failure.
Aint CrRel rif

NC RfRel P
EHT0500
Expiry of T9110. - see Note 4.
Aint SccpRel
Note 2
EHT0600
HANDOVER REQUEST message protocol errors :
Aint HOF perr

Note 2
Channel type combination not supported or invalid data

rate (see event EHT0602);
NC ActRel
or CIC is present for SDCCH connection;

or CIC is missing for a TCH connection;
or Cell identifier for target cell is not present for a Multicell BSS;
or IE identifier is inconsistent (i.e. missing mandatory

field, Encryption Information, Classmark Information 1 or
2, or Cell Identifier (Serving cell));
or erroneous IE contents (Encryption Information);
or only one among OIEs Group Call Reference and

Talker Flag ist present.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
51/75
EHT0601
HANDOVER REQUEST protocol error :
Aint HOF incel

Note 2
EHT0602
HANDOVER REQUEST message errors :
Aint HOF raun

Note 2
Cell identifier for target cell is not controlled by the BSS.

Half rate data request,
or 1.2/0.075 kbit/s T data rate requested on full rate,

or 6 kbit/s NT data rate on full rate channel.
EHT0603
Aint HOF cicun

Note 2
EHT0604
Aint HOF cicaa

Note 2
EHT0605
HANDOVER REQUEST :
Aint HOF bsne

Note 2
CIC indicates a circuit which is in a BLOCKED state.

CIC is already allocated to another connection.
CIC is unknown to the BSS.
In this case the BSS may send an UNEQUIPPED

CIRCUIT message to the MSC.
EHT0606
HANDOVER REQUEST :
Aint HOF cans

Note 2
EHT0607
HANDOVER REQUEST :
Aint HOF inval

Note 2
EHT0608
HANDOVER REQUEST :
Aint HOF iemis

Note 2
EHT0620
The BSC does not recognise or does not support any

codec amongst all proposed by the MSC.
Aint HOF spun

Note 2
EHT0701
BSS has detected an error during the allocation of the A

interface CIC (TCH only).
Aint HOF cicun

Note 1
EHT0702
BSS has detected an error during the allocation of the RF

channel.
Aint HOF nrra

Note 1 & 5
EHT0703
Handover failure error condition :
Aint HOF nrra

Note 5
EHT0704
Cell is disabled due to O&M intervention, or incoming

handover is inhibited in the cell.
Aint HOF o&m
EHT0705
CIC indicates timeslot 0
Aint HOF cicun
EHT0800
Queuing abnormal error :
Aint HOF nrra

Notes 2, 5 & 6
MS ciphering capabilities do not match with BTS ones or

with the MSC request.
The length field value of Encryption Information IE is not
between 1 and 9.
At least one encryption algorithm is allowed in Encryption
Information IE, but no key is present.
Internal seizure failure of RF channel.
Tqho expires;
or HANDOVER REQUEST cannot be queued;
or HANDOVER REQUEST is de-queued by a higher

priority handover or assignment request
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
52/75
EHT0900
Reception of CLEAR COMMAND with a cause different

from Radio interface failure, reversion to old channel
whilst T9110 is running
Aint MscRel
Note 2
EHT1000
Reception of SCCP-N-DISC-IND whilst T9110 is running Note 3.
Aint SccpRel
Note 2
EHT1001
Reception of SCCP-N-DISC-IND whilst T9113 is running
Aint SccpRel
EHT1100
Reception of CLEAR COMMAND (cause is "Radio

interface failure, reversion to old channel") whilst T9113
or T9110 is running.
Aint MscRel
NC RfRel P
EHT1101
Reception of CLEAR COMMAND (cause is not "Radio

interface failure, reversion to old channel") whilst T9113 is
running.
Aint MscRel
NC MsRel nr P
EHT1200
Reception of ERROR REPORT (O&M intervention)

before the activation of the new channel.
Aint HOF rif
NC MsRel ar_un P
NC LocRel
Table 3-15
Note 1 : The status of the CIC or the RF channel is free in the BSC.
Note 2 : There are no RF resources allocated and therefore there is no release towards the MS/BTS.
Note 3 : If the SCCP-N-DISC-IND contains the cause "SCCP inactivity timer expiry" (see sections
2.2.1.4 MSC initiated SCCP release towards the BSS and 2.2.2.5 BSC initiated call
release due to SCCP inactivity), no reset circuit procedure will be initiated.
Note 4 : No reset circuit procedure will be initiated since the terrestrial channel has already been
released.
Note 5 : The HANDOVER FAILURE message is not sent on the A interface if the target BSC has
previously received from the MSC a CLEAR COMMAND message.
Note 6 : In case of a HANDOVER REQUEST coming from UTRAN, the I.E. Inter-System Information
may be included in the HANDOVER FAILURE message, see 3.1.2.
2.2.12.2 Serving BSC scenarios
EVENT DESCRIPTION
EVENT
BEHAVIOUR
EHS0100
Expiry of T8.
Aint CrRel rimf

OC RfRel P
EHS0200
HANDOVER FAILURE from the MS.
Aint HOF revoc

OC X
Note 1
EHS0400
CLEAR COMMAND cause "Handover successful" whilst

T8 is running.
Aint MscRel
OC RfRel P
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
53/75
EHS0500
CLEAR COMMAND any other cause than "Handover

successful" whilst T8 is running.
Aint X
OC X
Note 2
EHS0600
Reception of SCCP-N-DISC-IND whilst T8 is running.
Aint X
OC MsRel ar_un P
Table 3-16
Note 1 : The HANDOVER FAILURE will contain the RR cause in the HANDOVER FAILURE
message sent by the MS.
Note 2 : The call release is deferred until it is known where the MS is (i.e. HANDOVER FAILURE) or
the timer T8 expires.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
54/75
2.2.13 Scenarios during channel modification

EVENT DESCRIPTION
EVENT NO
ICM0100
BEHAVIOUR
ASSIGNMENT REQUEST message protocol error :
Aint AF perr
full rate data to half rate data change is requested,
or half rate speech to full rate speech change (and vice

versa) is requested,
or half rate speech to full rate data change (and vice

versa) is requested.
ICM0200
ASSIGNMENT REQUEST message protocol error :
Aint AF raun
requesting 1.2/0.075 kbit/s NT or 6 kbit/s T data call,

or requesting half rate data channel,
or requesting half rate speech when not enabled.

ICM0205
Aint AF spun
ICM0300
MODE MODIFY NACK any cause.
Aint AF revoc
ICM0400
Successful return to Old channel mode after T9112

expiry.
Aint AF revoc
ICM0401
MS acknowledges using a CHANNEL MODE MODIFY

ACK containing the old mode, successful return to the old
channel mode.
Aint AF revoc
ICM0402

ACK containing the old mode, unsuccessful attempt to
revert to old mode in the BTS (i.e. reception of MODE
MODIFY NACK) - Note T9110 is running.
Aint AFcic rimf

RC MsRel ar_un P
ICM0403

ACK containing the old mode, unsuccessful attempt to
revert to old mode in the BTS (i.e. due to T9103 expiry) Note T9110 is running.
Aint AFcic rimf

RC MsRel ar_te P
ICM0500
The unsuccessful reversion to the old mode failed after

T9112 expiry due to T9103 expiry - Note T9110 is
running.
Aint AFcic rimf

RC MsRel ar_te P
ICM0501
The unsuccessful attempt to revert to the old mode due to

time-out of T9112 (the same as ICM0500 but due to
MODE MODIFY NACK reception) - Note T9110 is
running.
Aint AFcic rimf

RC MsRel ar_un P
ICM0502
Whilst changing to the new mode T9103 expired - Note

T9110 is running.
Aint AFcic rimf

RC MsRel ar_te P
ICM0600
The ASSIGNMENT REQUEST message indicates a

different CIC to the one presently in use for the
connection
Aint AF revoc
ICM0700
Reception of SCCP-N-DISC-IND whilst T9110 is running

or T9110 expiry - see Note 2.
Aint SccpRel
Note 1
ED
EVOLIUM
03
None of the speech version(s) indicated in the

ASSIGNMENT REQUEST is supported by the currently
allocated resources.
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
55/75
ICM0701
Reception of CLEAR COMMAND whilst T9110 is running.
Aint MscRel
Note 1
Table 3-17
Note 1 : The RF channel has already been released see events ICM0402, ICM0403, ICM0500,
ICM0501 & ICM0502.
Note 2 : A reset circuit procedure may be initiated on this event if a CIC is associated with the
connection upon T9110 expiry or when the SCCP-N-DISC-IND is received with the cause
set to "SCCP inactivity timer expiry".
2.2.14 Unexpected event during channel change procedures
Due to the nature of channel change procedures there are points in time during which communication
with the MS is impossible (due to the fact that the MS is moving from one channel to another). During
these points in time, events may be received which require the connection to be release. This section
specifies the method of handling these unexpected events during channel change procedures.
MESSAGE/EVENT NAME
HANDLING
METHOD on
Radio
HANDLING
METHOD on A
IMMEDIATE
DEFERRED
CONNECTION FAILURE INDICATION (Radio link

failure)
STABLE
STABLE
CONNECTION FAILURE
transcoder failure)
STABLE
STABLE
CLEAR COMMAND any cause except during external

handover
DEFERRED
DEFERRED
CLEAR COMMAND during External handover Serving BSS - any cause with the exception of
"handover successful" (see ref.[12]).
DEFERRED
DEFERRED
CLEAR COMMAND during External handover - Target

BSS - any cause with the exception of "radio interface
failure, reversion to old channel" (see ref.[12]).
IMMEDIATE
IMMEDIATE
ERROR INDICATION SAPI 0, "Timer T200 expired

(N200+1) times", "Unsolicited DM response: Multiple
frame established state", and "Sequence error").
STABLE
STABLE
ERROR REPORT ("O&M intervention") Note 1.
IMMEDIATE
DEFERRED
O&M intervention on A interface.
IMMEDIATE
IMMEDIATE
O&M intervention on Radio & A-bis.
DEFERRED
DEFERRED
STABLE
STABLE
RESET from MSC or internal detected BSC reset.
IMMEDIATE
IMMEDIATE
RESET CIRCUIT from MSC or BSC initiated reset

circuit.
DEFERRED
DEFERRED
Note 2
SCCP-N-DISC-IND.
IMMEDIATE
IMMEDIATE
LapD Failure detected at the BSC - see Note 1.
INDICATION
(Remote
RELEASE INDICATION (SAPI 0).
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
56/75
ERROR REPORT (SAPI 0 cause "Message sequence

error").
STABLE
STABLE
Table 3-18
DEFERRED : The handling of the message is deferred until the procedure is completed and the BSS
knows which channel the MS is on.
STABLE :
The message is ignored and discarded during channel change procedures. It is only
taken into account if received for the effected channels when the call is in a stable
phase.
IMMEDIATE : The handling of the message is immediate.
Note 1 : This message or event relates to the release of all connections associated with an TRX.
Note 2 : The SCCP connection is released immediately on the A interface by sending the SCCP
RELEASED message, however the A interface circuit associated with the connection is not
released in case where channel change procedures are on going until the whereabouts of
the MS is known. The reply to the reset circuit procedure (i.e. sending RESET CIRCUIT
ACK) is deferred.
2.2.15 Multiple event handling
When one or more deferred events occur during a channel change procedure, they are to be
remembered until the end of the procedure.
At the end of the procedure, the type of scenario which has to be activated is specified in the two
following sections.
2.2.15.1 Releasing towards the MS and BTS
The scenario used to perform the release on the old or new RF channel is dependent on the events
that have occurred during the channel change procedure.
The following list provides a list of events in descending priority order, the scenario to use will be that
indicated by the highest priority event which occurred.
1)
2)
LapD link failure,
or ERROR REPORT (cause "O&M intervention"),

O&M intervention on Radio or A-bis interfaces.
2.2.15.2 Releasing towards the MSC
The scenario used to perform the release towards the MSC is dependent on the events that have
occurred during the channel change procedure.
The following list provides a list of events in descending priority order, the scenario to use will be that
indicated by the highest priority event which occurred.
1)
RESET from MSC or internally detected,
3)
O&M intervention on A interface.
2)
RESET CIRCUIT or SCCP-N-DISC-IND,
2.2.16 The effect of O&M intervention on stable calls

The list of logical resources shown below, exist for stable calls:
1)
RF channel resources,
3)
SCCP.
2)
ED
EVOLIUM
A interface CIC (TCH only),

Note the SCCP entity may reside on a different DTC than the CIC.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
57/75
If an O&M intervention event occurs which will affect the resource (for example loss of SCCP, reset of
hardware affecting the CIC or radio interface resources) the call release scenario will be initiated as
specified in N0300.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
58/75
2.2.17 The effect of BSC O&M intervention on channel change procedures

The following table gives the expected system call release scenarios given the O&M intervention
events on Radio and A interface resources and the position after the channel change procedure has
terminated.
MS state
O&M event
MS back on Old Channel
MS on New Channel
MS is lost
O&M event on
Old RF Channel
Aint CrRel o&m

OC MsRel ar_un P
Note 3
NC RfRel P
Note 2
Note 1
Note 1
O&M event on
New RF
Channel
Note 1
Aint CrRel o&m

OC RfRel P
Note 3
NC MsRel ar_un P
Note 1
O&M event on
DTC or A
channel (if
allocated)
Note 4
Note 4
Note 4
Table 3-19
Note 1 : The O&M intervention event does not affect the call release scenario (if any) that is to be
taken.
Note 2 : In this case, the use of the physical context procedure on the main channel is to obtain the
error count as the MS attempted to connect to the new main channel.
Note 3 : The physical context procedure is only necessary on the main channel, if it has not been
performed prior to the channel change.
Note 4 : An O&M event on the A interface is handled immediately during channel change procedures
on Radio, A-bis & A interface.
2.2.18 The effect of ERROR REPORT (O&M intervention) during channel change procedures
The ERROR REPORT (O&M intervention) is sent by a TRX which has released the calls that it was
handling.
Therefore the ERROR REPORT message may affect some of the calls and procedures that the BSC
was handling on the TRX which sent the message.
During channel change procedures, the following modification of the scenarios, that are shown in the
following table, are required.
ERR REP
MS back on Old
Channel
MS State
MS on New Channel
MS is lost
From TRX on Old RF

Channel
Not applicable
Note 1
OC LocRel
Note 1
OC LocRel
From TRX on New RF

Channel
Note 1
Not applicable
Note 1
From both TRXs

controlling both New
and Old RF Channels
Not applicable
NC LocRel
NC
Not applicable
LocRel
Aint CrRel rif

OC LocRel
NC LocRel
Table 3-20
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
59/75
Note 1 : The scenarios for the A interface channel and the RF channel which did not have the
ERROR REPORT are unaffected.
2.2.19 Unexpected event during the call release protocol
The following events will cause a change in the system behaviour of the call release procedure when
received whilst the call release is in progress.
All other events (not mentioned in this section) will be ignored.
On A-bis interface:
A-bis failure detected by the BSC,
ERROR REPORT (cause O&M intervention).
On the reception of these events on the A-bis interface the BSC will:
release the RF resource locally,
stop the call release protocol towards the BTS,
any release towards the MSC will continue (if it is still in progress).
On A interface :
RESET CIRCUIT,
RESET (for all connections),

SCCP-N-DISC-IND.
On the reception of these events on the A interface the BSC will:

release any associated CIC,
release the associated SCCP connection locally,
stop the release protocol towards the MSC,
any release towards the BTS will continue if it is still in progress,
in the case where there is an SCCP-N-DISC-IND (with cause "SCCP inactivity timer
expiry") received for a connection with an allocated CIC, a reset circuit procedure may be
initiated - see ref.[7].
Note :
In the case of an O&M intervention on A channel (if allocated) or DTC during a normal call
release sequence, the CLEAR REQUEST repetition towards the MSC is stopped
immediately and the SCCP is released, in this case the CLEAR COMMAND from the MSC is
not awaited.
In the case where it is the first time the BSC has sent the CLEAR REQUEST the CLEAR
COMMAND is awaited before the release towards the MSC is forced as described above.
2.3
2.3.1
INTERACTION WITH OTHER PROCEDURES

Interaction of DTAP and call release
DTAP messages are discarded after the sending of the CHANNEL RELEASE message to the MS.
Any DTAP messages which are queued during channel change procedures are forwarded to the MS if
a call release event is received on A interface, except upon the receipt of an unexpected SCCP-NDISC-IND message. In such case, and when the BSC does not know on which channel the MS is, the
DTAP messages are discarded.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
60/75
2.3.2
Interaction of MS & BS power control and call release
BS & MS power control is stopped when the BSC either:

sends the CHANNEL RELEASE to the MS,
or sends the RF CHANNEL RELEASE to the BTS,
or when performing a local release of the RF channel (i.e. when ERROR REPORT (O&M
Intervention) is received or a LapD failure is detected).
2.3.3
Interaction of O&M disable and call release
When O&M commands a disabling of A interface resources, the telecom performs following scenario.
O&M
(1)
(2)
TELECOM
DISABLE (WTC) (DTC)
Start WTC
(3)
BSC
SCCP
LAYER 1
MSC
BLOCK
WTC expiry
CLEAR REQUEST
(4)
CLEAR COMMAND
(5)
RELEASE LAYER 1
(5)
ACK
(5')
DISABLE ACK
(6)
AIS
Note A
Figure 3-21
Note A : The time between the expiry of the WTC timer and the reception of the DISABLE ACK is
about 6 seconds. It is not sure during this point in time that all transactions will be released
or that all blocking procedures will be initiated or acknowledged.
(1)
(2)
(3)
(4)
(5)
(6)
ED
EVOLIUM
O&M commands a disable of an A interface resource(s) with a Wait Traffic Clear period.
The resource(s) is (are) immediately blocked by the triggering of the blocking procedure(s).
They are no longer available for allocation at this point in time.
Note for No 7 disable no blocking is carried out.
A timer (WTC) is started to allow the calls to clear in the normal way.
The timer expires and the calls are released see section 2.2.2.1.3 BSC initiated call release
due to O&M disable".
Note T9104 can only expire once during this scenario.
This part of the scenario is only done in the case of A trunk or No 7 signalling disable.
Once all calls are released SCCP entity is informed that the Layer 1 is to be disabled.
In the case of A trunk disable, AIS is applied (5').
In the case of No 7 signalling disable, the MTP changeover is initiated.
The acknowledgement is sent to O&M.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
61/75
2.3.4
Interaction of BTS transcoder alarm detection mechanism and call release
The call release strategy of the Alcatel BSS ensures that release towards MS/BTS and MSC are
carried out in parallel, as a result the BTS may detect a transcoder alarm during the call release
procedure for TCH calls.
The following table shows the release methods used on Radio/A-bis interface, for each an indication is
given as to whether a transcoder alarm may be sent from the BTS to the BSC - note for the purposes
of this section it assumed that the call was supported on a TCH connection and the A interface has
been released in parallel with the Radio/A-bis interface.
Radio/A-bis scenario
Interaction with transcoder alarm
Release using CHANNEL RELEASE

and DEACTIVATE SACCH messages
(MsRel)
The release on Radio/A-bis has a DEACTIVATE SACCH

message sent to the BTS by the BSC.
On reception of this message the BTS maintains the
transcoder detection mechanism.
Once the BTS has sent 120 CONNECTION FAILURE

INDICATION (cause "Remote transcoder failure")
messages, if the release procedure has still not be carried
out on BSC side, the BTS will internally release the
channel.
Detection and correction of the mismatch state between
BTS and BSC will be done in the BSC through the RF
RESOURCE INDICATION procedure.
Release on reception of RELEASE
INDICATION message (SapiRel)
The Release on Radio/A-bis is delayed for a period of

T3111.
Release on reception of RELEASE

INDICATION message followed by a
physical context procedure (SapiRel P)
In this case (see previous case) the BSC will run a

physical context procedure before performing the RF
channel release procedure with the BTS, and therefore
the chances of obtaining a CONNECTION FAILURE
message are increased.
Release using RF CHANNEL RELEASE

(RfRel)
The release on Radio/A-bis is immediate and as a result

there is no chance of receiving the message.
Release using RF CHANNEL RELEASE

preceded by a physical context
procedure (RfRel P)
The release on Radio/A-bis is not immediate (due to the

physical context procedure being run before the RF
channel release procedure), and as a result there is a
chance of receiving the CONNECTION FAILURE
INDICATION (cause "Remote transcoder failure") whilst
the physical context procedure is running.
Release where the radio channel is

released locally (i.e. no message
exchange - LocRel)
The chances of receiving a CONNECTION FAILURE

message is dependent on the type of failure between the
BSC and BTS.
If T3111 is greater than T_SYNC then the CONNECTION

FAILURE INDICATION (cause "Remote transcoder
failure") will be received by the BSC.
Table 3-22
Note :
ED
EVOLIUM
The BSC will ignore CONNECTION FAILURE INDICATION (cause "Remote transcoder
failure") whilst a call release is in progress.
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
62/75
INTERFACE DESCRIPTIONS
3.1
3.1.1
BSS External INTERFACES

Radio interface
CHANNEL RELEASE message construction:
Information element
Setting or Algorithm
MIE RR Cause
indicates the reason for the release
OIE BA Range
This IE provides the MS with ARFCN range information which can

be used in the cell for the selection procedure.
This IE is included in case of Location update procedure and for
MS phase 2.
See ref.[18] for more details on this IE.
OIE Group Channel

Description
Not used.
OIE Group Cipher

Key Number
Not used.
OIE GPRS
Resumption
This IE indicates whether the network has successfully resumed

the GPRS service or not.
This IE is included if it exists a MS suspend/resume context in the

BSC.
It is set to sucessfully when a MS RESUME ACK has been

received from the MFS without OIE Resume Failure Cause.
It is set to not successfully otherwise (i.e. MS SUSPEND ACK not

received, MS RESUME ACK received with OIE Resume Failure
Cause or T_GPRS_Resume expiry).
(See section 2.1.4)
OIE BA List Pref
Not used.
OIE UMTS Freq List
Not used.
Table 4-1 : CHANNEL RELEASE message construction
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
63/75
3.1.2
A interface
ASSIGNMENT FAILURE message construction:
Information element
MIE Cause
Given in table 3-5.
OIE RR Cause
Used if an ASSIGNMENT FAILURE has been received from the

MS, with the cause value given in this ASSIGNMENT FAILURE
message.
OIE Circuit pool
Not used.
OIE Circuit pool list
Not used.
Table 4-2 : ASSIGNMENT FAILURE message construction
CLEAR COMMAND
CLEAR COMPLETE
CLEAR REQUEST
HANDOVER FAILURE message construction:

Information element
MIE Cause
Given in table 3-5.
OIE RR Cause
Used if an HANDOVER FAILURE has been received from the MS,

with the cause value given in this HANDOVER FAILURE message.
OIE Circuit pool
Not used.
OIE Circuit pool list
Not used.
OIE Inter-System
Information
In the case of an inter-system handover from UTRAN or cdma2000

to GSM, this information element may be included by the target BSS
when traffic load information of the target cell is to be sent to the
source system. See Note.
Table 4-3 : HANDOVER FAILURE message construction
Note:
The Inter-System Information IE is optional. It is included in following conditions :
the Load Based 3G HO Filtering feature is activated by setting THR_CELL_LOAD_3G_REJECT
not equal to 100%, AND
the external incoming handover request comes from UTRAN, AND
the cause set in Handover Failure is no radio resource available.
For other cases, the normal procedure applies
RESET
RESET CIRCUIT
RESET ACK
RESET CIRCUIT ACKNOWLEDGE

SCCP RELEASED
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
64/75
3.2
3.2.1
BSS internal interfaces

A-bis interface
CONNECTION FAILURE INDICATION
Causes :
DEACTIVATE SACCH
ERROR INDICATION
Causes (SAPI 0 causes) :
ERROR REPORT (SAPI 0)

Cause :
Radio link failure,
Remote transcoder failure.
Timer T200 expired (N200+1) times,
Unsolicited DM response, Multiple frame established

state,
Sequence error.
Sequence error.

RELEASE INDICATION (SAPI 0)
RF CHANNEL RELEASE
RF CHANNEL RELEASE ACKNOWLEDGE

3.2.2
GSL interface
MS RESUME
MS RESUME ACK
3.2.3
BSC internal interfaces
The internal interfaces are logical interfaces and do not have to reflect the implementation.
The internal interface section of this document specifies the internal messages used between the BSC
call release control function, the BSC release towards the MS/BTS function and BSC release towards
the MSC function in the SDL section of this document.
Internal messages which control the execution of the BSC release towards the MS/BTS function:
MsRel (CHANNEL RELEASE cause value)

Internal message used for obtaining an MS RR connection release and then a RF channel
release. The CHANNEL RELEASE cause value is passed as a parameter in this interface.
SapiRel
Internal message used to obtain a delay of the RR connection so as to allow the exchange of
SABM & UA on radio interface before performing the RF channel release procedure with the
BTS.
RfRel
Internal message used when only the RF channel release is required.
LocRel
This internal message is used when the release is to be cancelled due to exceptional events
such as A-bis failure.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
65/75
Internal messages used to control the MSC call release function:
MscRel
Internal message used when the MSC has initiated the release.
CrRel (CLEAR REQUEST cause value)

Internal message used when the BSS has decided to clear the call.
HOF (HANDOVER FAILURE cause value) & AF (ASSIGNMENT FAILURE cause value)
Internal messages used to instruct the sending of the HANDOVER FAILURE and
ASSIGNMENT FAILURE message respectively.
These messages have been added so as specify of cause values in channel change
procedures.
SccpRel
Internal message used during exceptional conditions.
Internal message used to initiate a reset circuit procedure:
INITIATE RESET CIRCUIT

This internal message shall initiate a reset circuit procedure as long as there is no outstanding
reset circuit procedure in operation for the CIC involved.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
66/75
3.3
TIMERS LIST
BTS TIMERS :
T3109
BTS timer used during BTS initiated call release due to O&M intervention (there is one
timer per TRX in this case) or during BTS initiated call release due to LapD failure
(there is one timer per RF channel in this case).
BSC TIMERS (pertinent to Call release procedure) :

T9101
Timer used to supervise the reception of the SCCP-N-DISC-IND (cause "SCCP
released by MSC) after the sending of the CLEAR COMPLETE.
T9104
Timer used in the BSC to supervise the reception of the CLEAR COMMAND (from the
MSC) after the sending of the CLEAR REQUEST.
T3109
Timer used to supervise the release of the LapDm i.e. the reception of the RELEASE
INDICATION (SAPI 0). This timer must be greater than RADIO-LINK-TIMEOUT.
T3111
T_RCR_ACK
Timer used in the BSC to delay the release of the channel so as to allow the
exchange of DISC and UA on the Radio interface after the reception of the RELEASE
INDICATION (SAPI 0).
Timer used to supervise the reception of the RF CHANNEL RELEASE
ACKNOWLEDGE message.
BSS TIMERS (All others that are referenced in this document) :

T8
This is a BSC timer, it is used to supervise an external handover in the serving BSC.
The expiry of this timer indicates that the HANDOVER FAILURE message has not
been received by the serving BSC.
T3105
This is a BTS timer, it is used to supervise the reception of the establishment of layer
2, or the reception of any correct layer 2 frame, (depending on an O&M parameter),
during asynchronous handovers. There are two variants of this timer, they are
T3105_F and T3105_D. The timer used is dependant on the type of channel that the
asynchronous handover is controlling, these are FACCH and SDCCH respectively.
T3106
This is a BTS timer, it is used to supervise the reception of the establishment of layer
2, or the reception of any correct layer 2 frame, (depending on an O&M parameter),
during synchronous handovers. There are two variants of this timer, they are T3106_F
and T3106_D. The timer used is dependant on the type of channel that the
synchronous handover is controlling, these are FACCH and SDCCH respectively.
T3107
This timer is a BSC timer, it is used to supervise the assignment procedure. The
expiry of this timer indicates that the MS has failed to establish or send the
ASSIGNMENT COMPLETE message to the BSC.
T9108
This timer is a BSC timer, it is used to supervise the physical context procedure. The
expiry of this timer indicates that the BTS has not responded to the PHYSICAL
CONTEXT REQUEST message sent by the BSC.
T3101
ED
EVOLIUM
This timer is a BSC timer, it is used to supervise the immediate assignment

03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
67/75
procedure. The expiry of this timer indicates that MS has failed to establish the
SDCCH channel allocated in the IMMEDIATE ASSIGNMENT message.
T9103
This timer is a BSC timer, it is used to supervise the channel activation procedure in
the BSC. The expiry of this timer indicates that the BTS has not responded to the
CHANNEL ACTIVATION message.
T9105
This timer is a BSC timer, it is used to supervise the SCCP connection request
procedure. The expiry of this timer indicates that the MSC has not responded to a
SCCP CONNECTION REQUEST message.
T9110
This is a BSC timer, it is used to guard against inactivity of the MSC after the sending
of either a HANDOVER FAILURE or an ASSIGNMENT FAILURE message.
T9113
This is a BSC timer, it is used in external handover in the target BSC. The expiry of
this timer indicates that the HANDOVER COMPLETE has not been received by the
target BSC.
T_GPRS_Resume
Timer used in the BSC to supervise the reception of MS RESUME ACK from the MFS
in case of GPRS resume procedure.
3.4
PARAMETERS LIST
BSS PARAMETER :
N_CLR_REQ
BSC O&M parameter, controlling the number of CLEAR REQUESTs sent to the MSC
before the BSC decides to clear the connection.
RANGEi_LOWER
BSC O&M parameter, controlling the lower ARFCN of range i of BCCH frequencies
used for cell reselection.
RANGEi_HIGHER
BSC O&M parameter, controlling the higher ARFCN of range i of BCCH frequencies
used for cell reselection.
BTS_EN_RF_RES_IND
BTS O&M parameter, enabling the generation and sending of the RF_RES_IND
message by the BTS.
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
68/75
AF
GLOSSARY
BSC
Assignment Failure
Base Station Controller
BSCGP
BSC GPRS Protocol
BSS
Base Station Subsystem
Call Release
Action taken to release a connection
BTS
Base Transceiver Station
CIC
Circuit Identity Code - the method by which an A interface circuit is identified

on A interface
DISC
LAPDm frame indicating disconnection at Layer 2
EMLPP
Enhanced Multi-Level Precedence and Pre-emption
GPRS
General Packet Radio Service
LAPDm
Link Access Procedure on Dm Channel - the Layer 2 protocol on Radio

interface
FU
Frame Unit (GSM TRX equivalent)
HOF
Handover Failure
MFS
Multi Function Server
MS
Mobile Station
NC
New Channel
MSC
Mobile Switching Centre
O&M
Operations & Maintenance
OC
Old Channel
RAI
Routing Area Identity
Resource Release
Action taken to release a resource
SAPI
Service Access Point Identifier

2 SAPIs are used on LapDm : SAPI 0 for call handling and SAPI 3 for Short
Message Service Point to Point - this document only covers SAPI 0
RFC
SCCP
Signalling Connection Control Part
SGSN
Serving GPRS Support Node
TLLI
Temporary Logical Link Identity
TRX
ED
EVOLIUM
Radio Frequency Channel
Transceiver equipment located in the BTS
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
69/75
ANNEX A
This appendix contains the SDL diagrams for the BSC release towards the MS/BTS function, and the
BSC release towards the MSC function.
The SDLs represent the behaviour of the system and are a guide to the development department.
CALLREL
BSS
BSC CALL
REL
BTS CALL
REL
Figure A-1 : System CALLREL
null
rf chan
rel
channel
activation
rf chan
rel ack
activ
activate
L1 & L2
null
MS or BS
pwr ctrl
send
err_rep
rel req
sapi 0,3
send
err_rep
est req
sapi 0,3
send
err_rep
channel activ
ack to BSC
active
Figure A-2a : Process CALLREL/BSS/BTS CALL REL
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
70/75
null
data req
sapi 0,3
encrypt
cmd
send
err_rep
send
err_rep
error report
"msg seq err"
sapi 0 to BSC
null
Figure A-2b : Process CALLREL/BSS/BTS CALL REL
active
LAPDM
error
error indication to BSC
dl rel ind
release indication to BSC
active
active
A-bis
failure
rf channel
release
deactiv
SACCH
stop SACCH
frames
stop SACCH
frames & RLF
stop SACCH
frames & RLF
stop RL failure
detection
stop MS & BS
pwr ctrl
stop MS & BS
pwr ctrl
dl rel req
SAPI 0 to
LAPDM
start
T3109
wait rel ind
rf channel
release ack
to BSC
active
rel
rsrc
free RF
resource
null
Figure A-3a : Process CALLREL/BSS/BTS CALL REL
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
71/75
active
channel
activation
stop SACCH
frames & RLF
stop RL failure
detection
free RF
resource
activ
Figure A-3b : Process CALLREL/BSS/BTS CALL REL
wait rel ind
dl rel ind
(unsuccesful)
wait rel ind
dl rel ind
(succesful)
stop
T3109
T3109
expiry
rel
rsrc
rel
rsrc
Figure A-4 : Process CALLREL/BSS/BTS CALL REL
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
72/75
MS BTS REL
setup
MS BTS REL
& MSC REL
release
indication
start
T3111
MS BTS REL
& MSC REL
local
MS rel
cancel
MS rel
rel
BTS
send rf
chan rel
rel MS &
BTS
wait proc
finish
channel
release to MS
via BTS
wait T3111
deactiv
SACCH to BTS
start
T3109
wait rel ind
Figure A-5 : Process CALLREL/BSS/BSC CALL REL
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
73/75
wait rel ind
release
indication
start
T3111
local
MS rel
cancel
MS rel
wait T3111
T3109
expiry
local
MS rel
send rf
chan rel
cancel
MS rel
T3111
expiry
send rf
chan rel
inc RFCR
cnt
wait T3111
rf channel
release to
BTS
start T_RCR
ACK
wait rf chan
rel ack
wait rf chan
rel ack
local
MS rel
stop T_RCR
ACK
cancel
MS rel
rf channel
rel ack
T_RCR_ACK
expiry
stop T_RCR
ACK
cancel
MS rel
free RF
resource
RFCR cnt
2
else
cancel
MS rel
send rf
chan rel
MS BTS REL
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
74/75
wait sccp n
disconnect
MSC REL
local
MSC rel
cancel
MSC clr
rel MSC
with CLEAR
REQUEST
COUNT
equal 0
snd clr
req
clear request
to MSC
start
T9104
clear
command
sccp n
disconnect
ind
snd clr
cmplt
T9101
expiry
stop
T9101
clear complete
to MSC
cancel
MSC clr
stop
T9101
cancel
MSC clr
cancel
MSC clr
start
T9101
local
MSC rel
sccp n disc
req to MSC
wait sccp n
disconnect
MSC REL
wait clr cmd
wait clr cmd
local
MSC rel
clear
command
stop
T9104
stop
T9104
cancel
MSC clr
snd clr
cmplt
T9104
expiry
O&M
true
false
cancel
MSC clr
COUNT
N
else
cancel
MSC clr
increment
COUNT
snd clr
req

END OF DOCUMENT
ED
EVOLIUM
03
RELEASED
CALL RELEASE
0398_03.doc
06/11/2006
3BK 11202 0398 DSZZA
75/75

Call Release B9

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Call Release B9

Încărcat de

Drepturi de autor:

Formate disponibile

Site

3BK 11202 0398 DSZZA

3BK 11202 0398 DSZZA

Release B8: 3BK 11202 0348 DSZZA

Include the impact of Load Based 3G HO filtering features.

Updated according to approved review report

Reason for update

3BKA20CBR142270, according to file 142270_01

3BKA20CBR150634, according to file 150634_01

3BKA20CBR195973 - CREL : no SCCP RELEASED sent by BSC in

3BK 11202 0398 DSZZA

INTERNAL REFERENCED DOCUMENTS ........................................................................................... 5

1 FUNCTIONAL DESCRIPTION ......................................................................................................... 7

3BK 11202 0398 DSZZA

INTERNAL REFERENCED DOCUMENTS

3BK 11202 0413 DSZZA

Radio and Link Establishment

3BK 11202 0287 DSZZA

3BK 11202 0412 DSZZA

Normal Assignment Procedure

3BK 11202 0396 DSZZA

BSS Initialisation of the Telecom Part

3BK 11202 0399 DSZZA

Reset Circuit, Blocking and Unequipped Circuit

3BK 11202 0416 DSZZA

BSS Global Reset

LapDm functional specification

System information management

3BK 11202 0404 DSZZA

3BK 11202 0386 DSZZA

External channel change

3BK 11202 0395 DSZZA

GPRS MFS-BSC interface - BSCGP layer

3BK 11202 0335 DSZZA

Internal channel change

Alcatel BSS Application Document to GSM - General Overview

3BK 11202 0398 DSZZA

This document specifies:

The cause values contained in CLEAR REQUEST, HANDOVER FAILURE and

3BK 11202 0398 DSZZA

the release protocol with the MS,

Call and resource releasing strategies

3BK 11202 0398 DSZZA

This function is responsible for:

When it receives the CHANNEL RELEASE message, releasing the MM and RR

MS, MSC MM entities :

MS, MSC CC and SMS entities :

BTS call release function :

This function performs the following:

BSC call release function :

MSC call release function :

This function is responsible for performing the release of the call.

3BK 11202 0398 DSZZA

MS channel release procedure

by sending a CHANNEL RELEASE message to the MS,

CHANNEL RELEASE method

Radio link failure detection method

3BK 11202 0398 DSZZA

BTS channel release procedure

Mismatch between the BTS and BSC

BTS assumes a channel is busy but BSC treats it as free.

3BK 11202 0398 DSZZA

A interface call release procedure

The A interface call release procedure may be initiated by the: