Call Release B9

8/10/2019 Call Release B9

1/75

ED 03 RELEASED CALL RELEASE

EVOLIUM0398_03.doc06/11/2006 3BK 11202 0398 DSZZA 1/75

Site

VELIZYEVOLIUM SAS

OriginatorsDidier ESCLAMADON

CALL RELEASERELEASE 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.

Approvals

NameApp.

R. MAUGERSYT Manager

H.MABSC DPM

I.SCHWARZBTS DPM

NameApp.

C. LEJEUNESYT DPM


2/75



REVIEW

Ed 01 Proposal 01 08/03/2004 MRD/TD/SYT/rma/0070.2004

HISTORY


3/75



Release B8: 3BK 11202 0348 DSZZA

Version date Reason for update

Ed. 01 Proposal01

11-02-04 Include the impact of Load Based 3G HO filtering features.

Ed. 01 Released 08/03/2004 Updated according to approved review report

MRD/TD/SYT/rma/0070.2004Ed.02 Released 27/10/2004 3BKA20CBR142270, according to file 142270_01

3BKA20CBR150634, according to file 150634_01

Ed.03 Released 30/10/2006 3BKA20CBR195973 - CREL : no SCCP RELEASED sent by BSC incase of T9101 expiry


4/75


5/75



INTERNAL REFERENCED DOCUMENTS

Not applicable

REFERENCED DOCUMENTS

Doctree references

[1] 3BK 11202 0413 DSZZA Radio and Link Establishment

[2] 3BK 11202 0412 DSZZA Normal Assignment Procedure

[3] 3BK 11202 0287 DSZZA Channel Modification

[4] 3BK 11202 0173 DSZZA Protocol Error Handling

[5] 3BK 11202 0396 DSZZA BSS Initialisation of the Telecom Part

[6] 3BK 11202 0416 DSZZA BSS Global Reset

[7] 3BK 11202 0399 DSZZA Reset Circuit, Blocking and Unequipped Circuit

[8] 3BK 11202 0414 DSZZA LapDm functional specification

[9] 3BK 11202 0389 DSZZA System information management

[10] 3BK 11202 0404 DSZZA TC/BTS interface

[11] 3BK 11202 0335 DSZZA LapD Management

[12] 3BK 11202 0386 DSZZA External channel change

[13] 3BK 11202 0399 DSZZA Internal channel change

[14] 3BK 11202 0395 DSZZA GPRS MFS-BSC interface - BSCGP layer

[15] 3BK 11203 0096 DSZZA Alcatel BSS Application Document to GSM - General Overview

[16] 3BK 11202 0387 DSZZA Resource Allocation and Management

[17] 3BK 11202 0405 DSZZA 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 compliantare given in reference [15].

RELATED DOCUMENTS

Not applicable

PREFACE

Not applicable


6/75



SCOPE

This document specifies:

1) The call release procedure for this release of the Alcatel BSS.

2) The relationship between the call release procedure, the physical context procedure andO&M performance management.

3) The cause values contained in CLEAR REQUEST, HANDOVER FAILURE andASSIGNMENT FAILURE messages.

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 correspondingprocedure specification (ref.[6], [2], [1], [3], [12] & [13]).

Note : The SDL's in the appendix are a help to implementation and integration. In case ofinconsistency, the text is the definitive description.


7/75



1 FUNCTIONAL DESCRIPTION

1.1 General Description

During an MS connection, Radio interface and A interface channels are allocated or reserved. Theseresources require to be released for reuse when the call is terminated and upon events whilst thetransaction is on going.

The releasing or freeing of resources is initiated on internal or external events that the BSS detects orreceives.

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 therelease 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) The release towards the Radio interface (the BTS and MS) and the release towards the Ainterface (the MSC) - when initiated together - will run in parallel without any synchronisationbetween them.

This means that the radio and A interface resources will be released at different times. As aresult there is an interaction between the BTS transcoder alarm detection mechanism andcall release - see section 2.3.4 Interaction of BTS transcoder alarm detection mechanismand call release".

2) When a channel change procedure runs and it appears that the MS is lost, a releaseprotocol to the MS will always be initiated. This ensures that MS is always released andcaters 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".

3) When a failure occurs in the release of the radio channel in the BTS, the BSC will attemptthe protocol again. If the second attempt fails, the resource is released locally in the BSCand an O&M error report (cause "RF channel release failure") is generated.

4) In a call release scenario, the physical context procedure (for the gathering of LapDmperformance management data) will always be performed unless a physical contextprocedure has been performed prior to the initiation of the call release procedure.


8/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 RRconnections 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 mayperform 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 mayperform 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.


9/75



2 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 byusing two methods:

1) by sending a CHANNEL RELEASE message to the MS,

2) 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 severalARFCN ranges (GSM and DCS) which can be used in the cell selection procedure. Doing so willreduce 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 bereceived from the OMC-R. Every range_i is defined by the RANGEi_LOWER and RANGEi_HIGHERvalues 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 toperform 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 bythe MS at SAPI 0 can be properly received by the BSS. The value of T3110 is such that at least twoDISC frames may be sent by the MS to the BSS (recommended by GSM ref.[18]), this gives a goodprobability of the BSS detecting the disconnection of SAPI 0 by the MS. If T3110 expires, the MSinstructs 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 disconnectionto the BSC via the RELEASE INDICATION message.

The BSC (on reception of this message) must wait a short period (T3111), this allows the DISC andUA to be exchanged on the Radio interface, before the BSC performs the RF channel releaseprocedure.

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 ofradio channel is made before the point in time the BTS LapDm can send the UA message on theRadio interface. This is most likely to occur for SDCCH connections where the transmission to the MSmay only occur at specific points within the Radio interface multi-frame. For TCH connections themessage 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 sendingof SACCH frames to the MS on the main SACCH. SACCH frames should be stopped for a period ofT3109 for the algorithm in the MS to detect radio link failure condition. This is initiated by the BSC bysending 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 alarmdetection mechanism, this is needed due to the adopted strategy, i.e. the initiation of aparallel release of A and A-bis/Radio interfaces - see section 2.3.4 Interaction of BTStranscoder alarm detection mechanism and call release.

Whilst the MS is connected, it runs an algorithm which detects the lack of SACCH frames on the mainSACCH for a period of time (set by the BSS).


10/75



Once this time-limit is reached, a radio link failure is supposed to exist. Upon this supposition, the MSinstructs the LapDm entity to perform a "local end release" of the LapDm connection and a release ofthe physical layers, that is to say that the LapDm and RR connection are released without anyexchange 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 thecells can be "camped on" and supports the re-establishment procedure (see note *), the MS mayattempt 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 fieldRADIO-LINK-TIMEOUT, which is contained in the Cell Options IE, sent in the SYSTEMINFORMATION TYPE 6 message. It is important that the BSS timer T3109 is set to be greater thanthe 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 TYPE1, 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 messageto the BTS.

On reception of this message the BTS will release the channel and return an RF CHANNELRELEASE ACKNOWLEDGE to the BSC.

When the BSC receives the acknowledgement, the channel is then released (within the BSC) for usein other connections.

The BSC starts the timer T_RCR_ACK to supervise the response of the BTS. In the event that thetimer 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 ofreleasing 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 RFresource locally and perform a call release towards the MSC on A interface if required. In addition theBSC 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 alreadyactivated, the BTS will release the channel internally (stop immediately sending SACCH framesand does not start T3109) and then activate the requested channel. The BSC is then informed ofthe (un)successful completion.

Several possibilities exist when an activation request arrives for an already activated channel:

1) a full-rate TCH channel is requested but the channel is currently busy as TCH (the channelis currently being used by at least one call);

2) a full-rate TCH channel is requested but the channel is currently busy as SDCCH (at leastone of its logical SDCCH sub-channels is currently being used to carry the signalling);


11/75



3) a half-rate TCH channel is requested but the channel is currently being used by a FR call orthe requested TCH sub-channel is currently being used by an another HR call;

4) a half-rate TCH channel is requested but the channel is currently busy as SDCCH (at leastone of its logical SDCCH sub-channels is currently being used to carry the signalling);

5) a SDCCH channel is requested but channel is currently being used by at least one call or allof 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 currentlybeing used by a FR call or by two HR calls. A cross over of messages could be thereason of this mismatch.

Case 2: BTS considers a channel is free but BSC considers that the channel is currently busyas SDCCH. The reason of this mismatch may be a cross over of messages or thetimeslot 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 withinthe BSC. If on receipt of the subsequent RF RESOURCE INDICATION message indicating thatthe channel is idle, a mismatch is assumed and the resources of each busy TCH channel orbusy SDCCH sub-channel are released internally within the BSC by using the call releasescenario N1400. The mechanisms detecting the above two mismatch cases are detailed inreference [16].

NOTE: In order to enable this capability of checking for mismatch of resources between the BTS andBSC it is necessary that the RF RESOURCE INDICATION message is always sent from the BTSto the BSC i.e. the BTS flag BTS_EN_RF_RESOURCE_IND is always set to enable the sendingof 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) by sending CLEAR COMMAND to the BSC,2) by initiating an SCCP release by sending the SCCP RELEASED message to the BSC,3) by sending the RESET message,4) by sending the RESET CIRCUIT message.

The BSC may initiate a call release in the MSC using the following methods:

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

2.1.3.1 MSC initiated (CLEAR COMMAND to the BSC)

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 towardsthe 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 theBSC - see section 2.2.1.4 MSC initiated SCCP release towards the BSS.


12/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 allconnections 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. Thismessage indicates to the BSC that the MSC wishes to initiate a release for a single connection whichhas 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 reasonfor the release. The MSC should react to this message with a CLEAR COMMAND, upon which theBSC replies with a CLEAR COMPLETE.

The SCCP connection should then be released by the MSC by the sending of SCCP RELEASED tothe 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 resourcesreserved for the connection (on both Radio and A interface) - see section 2.2.2.1 CrRel : BSCinitiated 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 someother reason is not responding), the BSC supervises the reception of the CLEAR COMMAND by useof 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.1Compelled CLEAR REQUEST (T9104 expiry)".

If the procedure is repeated "N_CLR_REQ" times (without success) then the SCCP connection isreleased immediately by using the primitive SCCP-N-DISC-REQ to the SCCP entity. A RESETCIRCUIT procedure may be run if a CIC was associated to the connection - see ref.[6], this is deemedto 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 RELEASEDmessage from the BSC to the MSC, upon which the MSC should respond with an SCCP RELEASECOMPLETE.

No SCCP RELEASED from MSC :To ensure that the SCCP connection is cleared at the end of the clearing sequence, the BSC runs thetimer T9101 after having sent the CLEAR COMPLETE to the MSC. This timer is stopped on receptionof 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 CLEARREQUEST, but is also initiated when there are no resources associated with the connection aftertimer expiry.


13/75



It is initiated by use of the primitive SCCP-N-DISC-REQ to the SCCP entity which may cause theSCCP RELEASED message to be sent to the MSC - see section 2.2.2.4 SccpRel : BSC initiatedSCCP 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 MSCassociated 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. Thismessage indicates to the MSC that the BSC wishes to initiate a release for a single connection whichhas 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 Achannel 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 toT9104 expiry N_CLR_REQ times.

2) Release of a connection with an associated A interface channel (CIC) due to receptionfrom 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 expirationof 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.


14/75



MS BTS BSC MFS

(1)

(1) MS RESUME

(1) ---------------------------------->

start T_GPRS

_Resume

(2) MS RESUME ACK

(2)


15/75



1 Before releasing the RR connection towards the MS (sending the RR CHANNEL RELEASEmessage), 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 ReferenceNumber), 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]), andstart the T_GPRS_Resume timer (remark: the T_GPRS_Resume timer shall be as short aspossible in order to be compatible with the usual RR connection release duration).

The MFS forwards the Resume command to the SGSN, which acknowledges it and resumesthe GPRS traffic towards the MS.

2&3 Upon receipt of MS RESUME ACK, the BSC stops the T_GPRS_Resume timer, sends the RRCHANNEL RELEASE message to the MS (via the BTS) with the GPRS Resumption IE anddeletes the MS suspend/resume context.

If the MS RESUME ACK message does not contain the OIE Resume failure cause, theGPRS Resumption IE is set to the value successful resumption.

If the MS RESUME ACK message contains the OIE Resume failure cause, the GPRSResumption 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 MFSdidnt acknowledge the Suspend request towards the BSC), no MS RESUME message issent to the MFS.

The BSC sends immediately the RR CHANNEL RELEASE message to the MS with OIE GPRSResumption set to the value unsuccessful resumption and delete the MS suspend/resumecontext.

If T_GPRS_Resume timer expires, the BSC sends also immediately the RR CHANNELRELEASE message to the MS with OIE GPRS Resumption set to the value unsuccessfulresumption and delete the MS suspend/resume context.

If there is no MS suspend/resume context in the BSC at the receipt of MS RESUME ACKmessage from the MFS (e.g. the CS call ends before), the message is discarded.


16/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 isrequired to be initiated.

The protocols are split into protocols on A, A-bis and Radio interfaces. Each protocol on eachinterface is described completely. The protocols on Radio and A-bis are not synchronised to therelease 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 referencesthe protocols (and cause values used) described in this section which are to be performed on Radio,A-bis and A interfaces

2.2.1 MSC initiated release protocols towards the BSS

2.2.1.1 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 CLEARCOMMAND 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.

Some exceptions exist - see section 2.2.1.4 MSC initiated SCCP release towards the BSS".

- When the MSC has received a CLEAR REQUEST from the BSS - see section 2.2.2.1CrRel : BSC initiated normal call release towards the MSC".

The MSC performs the call release by sending the CLEAR COMMAND message. The BSC returns aCLEAR COMPLETE and the timer T9101 is started, the BSC awaits the release of the SCCPconnection.

The message sequence chart below shows the MSC initiated release scenario.

BSC MSC

CLEAR COMMAND

CLEAR COMPLETE

Start T9101

SCCP RELEASED

SCCP RELEASE COMPLETE

Stop T9101

(1)

(2)

(3)

(4)

Figure 3-1


17/75



(1) The MSC initiates the release by sending the CLEAR COMMAND.

(2) The BSC releases any A Channel resources, switches off the traffic path in the BSC andreturns immediately the CLEAR COMPLETE message to the MSC. Note that the BSC willaccept any CLEAR COMMAND message even if the MIE is not present or the cause isunknown.

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 MSconnection and free the RF resources.

In the case where there is a channel change procedure in progress, the whereabouts of theMS is awaited before the release is initiated on Radio and A-bis - see ref.[2], [12] & [13] forthe behaviour of the BSS on A interface.

The MSC upon reception of the CLEAR COMPLETE releases any A Channel resourcesassociated to the connection and should initiate the release of the SCCP resource.

(3) The BSC starts the timer T9101 to supervise the release of the SCCP resource - see section2.2.2.1.2 on "Awaiting SCCP release (T9101 expiry).

(4) The MSC releases the SCCP resource by sending the SCCP RELEASED message to theBSC.

The BSC stops T9101 and returns the SCCP RELEASE COMPLETE message and theSCCP 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 releaseall 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 MSC

RESET

SCCP RELEASED


(1)

SCCP RELEASED


SCCP RELEASED


(2)

Figure 3-2


18/75



(1) The MSC initiates a reset procedure by sending the RESET message to the BSC. For moredetails of the reset protocol, see ref.[6].

(2) The BSC receives the RESET message and immediately releases the SCCP connections ofall active transactions.

If an A channel is associated with the SCCP connection, then the A channel will be releasedimmediately and the BSC will switch off the traffic path.

Note: The SCCP RELEASED and SCCP RELEASE COMPLETE messages may notappear on the A interface as this release method may be initiated due to SCCPproblems.

In the case where there is an MS connected, a call release will be performed on Radio andA-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 releaseon Radio and A-bis and the release of any A interface resource associated to the connectionmay 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 messagewhich 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 channelcontained in the RESET CIRCUIT.

BSC MSC

RESET CIRCUIT

SCCP RELEASED


(1)

(2)

Figure 3-3

(1) The MSC initiates a reset circuit procedure by sending a RESET CIRCUIT message.

(2) The BSC behaviour for the reset circuit protocol is specified in ref.[7], the call release foractive connections is performed as follows :

On A interface: If the A channel has an active call, then the A channel, the traffic path andSCCP connection will be released immediately, in the case of a connection undergoing achannel 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 RFresources are released.

During channel change procedures the release on the Radio/A-bis interfaces and the Ainterface circuit may be delayed until the whereabouts of the MS is known.

Notes: The SCCP RELEASED and SCCP RELEASE COMPLETE messages may not appear onthe A interface if the SCCP connection is lost in either the BSC or MSC.


19/75



There is no call release scenario when there is no connection associated to the A channelindicated 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 SCCPconnection used for carrying signalling messages for the connection, there are no methods of re-

establishment of the connection possible at the SCCP layer or possible within GSM between the BSSand 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 beenused, that is at the end of a MM procedures (Location update, etc.) where there are no A interfaceresources (i.e. an A channel) associated with the connection or at the end of an unsuccessful externalhandover due to "Handover resource allocation failure".

The Alcatel BSS, on reception of the SCCP RELEASED message, accepts this release irrespective ofthe resources allocated to the connection.

The BSC SCCP entity, on reception of the SCCP RELEASED message, returns immediately anSCCP RELEASE COMPLETE message and conveys the event to the BSC GSM protocol entity bysending 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 othercase).

Upon reception of the primitive SCCP-N-DISC-IND (cause "SCCP released by MSC"), the BSC GSMprotocol entity releases any associated A interface resources (A channel) and associated traffic pathand initiates a release on the Radio interface of the MS and Radio interface resources. Even duringchannel 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 SCCPinactivity timer expiry - see section 2.2.2.3 BSC initiated reset circuit towards the MSC.

Figure 3-4

(1) The MSC has sent the SCCP RELEASED message.

(2) The BSC SCCP replies with the SCCP RELEASE COMPLETE and passes to the BSCBSSAP entity an indication that the signalling link no longer exists.

The BSC releases any associated A channel and initiates the release towards the MS ifapplicable.

In case where the SCCP RELEASED message contains an embedded BSSAP message, the BSCproceeds 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 toany possible CHANNEL RELEASE, except in the middle of a channel change when the BSC doesnot know on which channel the MS is. In such case, the DTAP message is discarded by the BSC.

BSC

BSC

BSSAP MSC

SCCP RELEASED(1)

(2)

BSC

SCCP

SCCP-N-DISC-IND SCCP RELEASE COMPLETE


20/75



If the BSSAP message is a DTAP message for SAPI 3 and a SAPI 3 connection is established, it istransmitted towards the MS prior to any possible CHANNEL RELEASE, except in the middle of achannel change when the BSC does not know on which channel the MS is. In such case, theDTAP message is discarded by the BSC. If no SAPI 3 connection is established, the DTAPmessage is discarded.

2.2.2 BSC initiated call release protocols

2.2.2.1 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 eventsdetected 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 inprogress or may even have been completed, however there are a few cases where the MS is stillconnected on the Radio interface whilst the release is occurring on the A interface. In these cases theMS remains connected until the MSC sends a CLEAR COMMAND upon which the BSC will initiatethe call release scenario towards the MS.

The BSC initiates this scenario by sending to the MSC a CLEAR REQUEST message. The BSC runsthe 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 willreturn a CLEAR COMPLETE, release any associated A channel, and then await the release of theSCCP connection. The release of the SCCP connection by the MSC is supervised by the BSC usingthe timer T9101 - see message sequence chart below.

BSC MSC

CLEAR REQUEST

CLEAR COMMAND

Start T9104

CLEAR COMPLETE


Stop T9101(4)

Stop T9104

Start T9101

SCCP RELEASED

(1)

(2)

(3)

Figure 3-5

Note A : the BSC detects an event which causes a call release to occur, initiated by the BSC.

(1) The BSC detects an event, and signals the requirement to release the connection bysending the CLEAR REQUEST to the MSC, and starts the timer T9104 to supervise the

procedure.


21/75



(2) The MSC responds by sending a CLEAR COMMAND.

The BSC stops the timer T9104, if the MS is still connected the BSC will initiate a callrelease scenario towards the MS and then release the resources in the BTS.

(3) The BSC releases any associated A channel and any associated traffic path, and sends theCLEAR COMPLETE. The release of the SCCP connection is awaited. The timer T9101 isstarted to guard the release of the SCCP connection by the MSC.

(4) The MSC, on reception of the CLEAR COMPLETE, should release any associated Achannel resource and release the SCCP connection by sending the SCCP RELEASEDmessage to the BSC. The BSC should respond with the SCCP RELEASE COMPLETE andstop 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 ensurethat 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 isimmediately 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 CLEARCOMMAND 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 forcereleased by sending an SCCP-N-DISC-REQ primitive to the SCCP entity.


22/75



The message sequence chart below shows the compelled CLEAR REQUEST scenario where theMSC does not respond, where there is a CIC allocated to the transaction and where N_CLR_REQ, isset to be equal to 3.

BSC MSC

CLEAR REQUEST

Start T9104


T9104 expiry

SCCP RELEASED

(1)

CLEAR REQUESTStart T9104

T9104 expiry

CLEAR REQUEST

Start T9104

T9104 expiry

Initiate reset circuit procedure for CIC

Figure 3-6

(1) This action is only initiated if a CIC is allocated to the connection which is undergoing therelease - 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 ensurethat the MSC releases the SCCP connection. This ensures that there are no hanging resources in theSCCP entity.

If the MSC does not release the SCCP resource, the BSC will locallyrelease it.

The SCCP entity sends a SCCP RELEASED to the MSC. Whether the MSC responds with the SCCPRELEASE COMPLETE is of no importance to the scenario as the SCCP connection is deemedreleased in the SCCP layer.

It must be noted that the SCCP RELEASED message is only specified in GSM to be sent from theMSC to the BSC, so this behaviour is a specificity of the Alcatel BSS.


23/75



The message sequence chart below shows the MSC initiated release scenario when the timer T9101expires.

BSC MSC

CLEAR COMMAND

CLEAR COMPLETE


T9101 expiry

Start T9101

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 dueto 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 anacknowledgement that the call(s) have been released - see section 2.3.3 Interaction of O&M disableand call release".

BSC MSC

BLOCK

CLEAR REQUESTStart T9104


T9104 expirySCCP RELEASED

(1)

(2)

(3)

Figure 3-8


24/75



(1) Telecom has received an internal O&M event to disable a DTC, A trunk or A channel.

The Telecom triggers blocking procedures (the timers are not shown) - see ref.[4] forprotocol behaviour.

(2) The BSC initiated normal release is triggered (this may occur later in the sequence if theO&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 BSC initiates the release of the MS connection, this may be delayed if channel changeprocedures are in progress - see ref.[2], [12] & [13].

The BSC initiates the normal release by sending CLEAR REQUEST and starting the timerT9104.

(3) There is no response from the MSC and T9104 expires, the A channel, the traffic path andthe SCCP connections are released immediately.

For A trunk and A channel disable the blocking procedures will continue - if the MSC has notalready 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 theconcerned channel :

If no release scenario is ongoing, then BSC shall trigger release scenario N0300.

If a release scenario is already ongoing for this channel :

If the BSC has sent CLEAR REQUEST before, and T9104 is running (waiting for CLEARCOMMAND from MSC), then the BSC shall stop T9104, release all resources and sendSCCP-RLSD to the MSC.

If the BSC has already received CLEAR COMMAND message from MSC, then it shall finishthe release procedure and send CLEAR COMPLETE to the MSC. It shall then start T9101 towait for SCCP-RLSD from MSC.

2.2.2.2 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 SCCPconnections) 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 changeprocedures the call release may be delayed - see ref.[2], [12] & [13].

BSC MSC

RESET(1)

Figure 3-9

(1) The BSC detects the need to perform the reset procedure, the SCCP connections and Ainterface resources (A channels) on A interface are released locally (i.e. no message


25/75



exchange), any associated traffic path is switched off and the RESET message is sent to theMSC.

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 severalcalls. 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 notcause messages to appear on the A interface depending on the state of the SCCP entity and theSCCP connection associated to the A channel concerned. Any associated traffic path is also switchedoff in the BSC.

The release towards the Radio and A-bis (if any is required) is made immediately. In the general casethere is no Air or A-bis call release as this may have been done previously - see ref.[7].

BSC MSC

RESET CIRCUIT

SCCP RELEASED


RESET CIRCUIT ACKNOWLEDGE

(1)

(2)

(3)

Figure 3-10

(1) The BSC detects the need to perform the reset circuit procedure and sends the RESETCIRCUIT message (timers are not shown) - see ref.[7].

(2) The SCCP connection is released immediately.

(3) The A channel and the traffic path are released on the reception of the RESET CIRCUITACKNOWLEDGE (timers not shown) - see ref.[7].

2.2.2.4 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 hasattempted to use the normal methods of release, specified by GSM, and has eventually failed (seesection 2.2.2.1 CrRel : BSC initiated normal call release towards the MSC"), and when there are noresources allocated to a transaction (see section 2.2.6 Call release trigger upon BSC detectedevents").

The call release is initiated by the BSC GSM Layer 3 issuing an SCCP command (SCCP-N-DISC-REQ) to the SCCP entity.

The following message sequence chart shows the expected message exchange on A interface.


26/75



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 COMPLETEmessages 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. Upondetection of the SCCP inactivity reported to the layer 3 by means of SCCP N-DISC-IND (causeSCCP inactivity timer expiry), the BSC assumes that the SCCP connection and its associatedtransaction are no longer active, and performs a call release on both the Radio/A-bis interfaces (ifrequired) 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 aRESET CIRCUIT procedure to release the A channel in the MSC (see section 2.2.2.3 BSC initiatedreset 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 theLapDm 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/BTSfunction.

This section shows (by means of message sequence charts) the message flow for each scenario.

BSC

BSC

BSSAP MSC

SCCP RELEASED

(2)

BSC

SCCP

SCCP-N-DISC-REQ


(1)


27/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. Theresource 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 thenew channel.

Note that a physical context procedure is performed and if the procedure has not alreadybeen 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 quicklyduring the immediate assignment procedure as the BSC has no means to distinguish therepetition of a RANDOM ACCESS by the MS and may therefore allocate more than oneSDCCH 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.

MSC

PHYSICAL CONTEXT REQUEST

BSC(1)

BTSMS

PHYSICAL CONTEXT CONFIRM

Stop T9108

Start T_RCR_ACK

RF CHANNEL RELEASE

RF CHANNEL RELEASE ACK

Stop T_RCR_ACK

(note A)

Start T9108(2)

(3)

(4)

Figure 3-12

Note A : In most cases the MS should not be present on the Radio interface.


28/75



(1) The MS should not be present on the Radio interface whilst this scenario is in progress, asthis is the quickest method of releasing the channel and may cause the channel to bereassigned to another mobile.

The Alcatel BSS uses this release procedure and risks the reassignment of the channel toanother MS in the case of an SDCCH channel on the failure of an immediate assignmentprocedure - reference event IA0300.

(2) BSC detects the need for a channel release and sends a PHYSICAL CONTEXT REQUESTmessage 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 thetranscoder, this will be due to the fact that the A and A-bis/Radio interface call release ismade in parallel, as a result a CONNECTION FAILURE INDICATION (cause "Remotetranscoder failure") message may be sent by the BTS to the BSC after the timer T_SYNChas 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 RELEASEmessage 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 RFCHANNEL 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 (T9108expiry)

The BTS may not respond to the PHYSICAL CONTEXT REQUEST either due to non reception of themessage (i.e. loss on A-bis), load in the BTS (causing a response problem), or whilst the BTS isresetting 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 tocontinue 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 inthe BTS and BSC in step with each other.

MSC


BSCBTSMS

T9108 expiry

Start T_RCR_ACK

RF CHANNEL RELEASE

Start T9108

Note A

Figure 3-13


29/75



Note A : This behaviour is only valid for the expiry of the T9108 for a physical context procedurewhich has been initiated as part of the call release procedure for the collection of LapDmperformance management data.

The system behaviour when T9108 expires during the physical context procedure for TCHassignment 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 nonresponse 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 failsthe second time (which is possible when the BTS is restarting) the BSC will deem the resource asfree, terminate the release and send an O&M error report with cause "RF channel release failure".

MSC


BSCBTSMS

T9108 expiryStart T_RCR_ACK

RF CHANNEL RELEASE

Start T9108

Start T_RCR_ACKRF CHANNEL RELEASE

T_RCR_ACK expiry

T_RCR_ACK expiry

(1)

(2)

(4)

(5)

(3)

Figure 3-14

(1) The physical context procedure failed with the expiry of T9108.

Note the given scenario is valid only for physical context procedures performed during callrelease scenarios.

(2) The BSC attempts to release the RF channel in the BTS.

(3) The RF channel release procedure failed, with the expiry of T_RCR_ACK.(4) The BSC attempts to release again.

(5) The second attempt fails, so the BSC releases the resources locally and sends an O&Merror report (cause "RF channel release failure").

Note if the BTS RF channel is still allocated in the BTS, the situation will be rectified by alocal release in the BTS before the new channel activation.


30/75


31/75



2.2.3.4.1 No RELEASE INDICATION received during channel release procedure (T3109EXPIRY)

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 passacknowledged data.

On T3109 expiry, the MS should have detected the radio link failure condition (due to the lack ofSACCH frames on the main SACCH), in which case the MS will perform a local release of the LapDmand deem the connection terminated.

When T3109 expires the RF channel release procedure is initiated by the BSC. This procedure maybe 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).

MSC

DATA REQ (CHANNEL RELEASE)

BSCBTSMS

DEACTIVATE SACCHStart T3109

Start T9108PHYSICAL CONTEXT REQUEST

T3109 expiry

Stop T9108

CHANNEL RELEASE

RF CHANNEL RELEASE


RF CHANNEL RELEASE ACKStop T_RCR_ACK

(1)

(2)

(4)

(3)

Start T_RCR_ACK

(5)

Note A

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 theLapDm in the MS can not accept it.

(2) BSC commands the stopping of the SACCH messages and ignores the transcoder alarms.

MS starts to detect the radio link failure condition.

(3) MS has detected the radio link failure condition (before expiry of T3109) and performs thelocal release.


32/75



(4) T3109 expires in the BSC (any ERROR INDICATION message received from the BTS withcause value set to "Timer T200 expired N200+1 times" - and due to the repetition of theCHANNEL 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 : BSCinitiated RF channel release towards the BTS.

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 LapDmentity will respond with a UA (SAPI 0) and inform the BSC that the SAPI 0 connection has beenreleased 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 hasreceived the CHANNEL RELEASE message) or of its own accord (when disconnecting off the RRconnection).

The BSC on reception of the RELEASE INDICATION (SAPI 0) starts the timer T3111 and awaits theexpiry of this timer before initiating the release of the RF channel (see section 2.2.3.1 RfRel : BSCinitiated RF channel release towards the BTS"). The BSC sets the T3111 timer so that the BTS cansend 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 RELEASEINDICATION (SAPI 0) when initiated by the MS.

See the section 2.2.3.4 "MsRel : BSC initiated channel release towards the MS/BTS for themessage sequence chart where this procedure is initiated as part of the BSC initiated release of theMS connection.

MSCBSCBTSMS

Start T3111

Start T9108PHYSICAL CONTEXT REQUEST

T3111 expiry

Stop T9108

DISC

UARELEASE INDICATION

RF CHANNEL RELEASE


Start T_RCR_ACK

RF CHANNEL RELEASE ACK Stop T_RCR_ACK

(1)

(2)

(3)

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 beawaiting transmission in the BTS due to the timing of the TDMA frame.


33/75



(2) The BSC upon reception of the RELEASE INDICATION (SAPI 0) starts the timer T3111 andawaits 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 : BSCinitiated RF channel release towards the BTS.

2.2.4 BTS call release function

The BTS takes no autonomous release actions during the release of an MS RR connection (with theexception 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 theDEACTIVATE SACCH or RF CHANNEL RELEASE message),

and to inform of the release of LapDm SAPI 0 (by sending to the BSC the RELEASEINDICATION (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 RELEASEmessage 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 theseactions 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 MSC

1 note A

2 start T3109

3 T3109 expiry

3 ----------SABME--------->

3

5 note B

6 ----CLEAR REQUEST'---->

6 ----CLEAR REQUEST"--->

figure 3-18

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


34/75



1 TRX detects that the A-bis link has failed.

2 SACCH frames sent to all MSs are stopped, LapDm is pu into NULL state and T3109 isstarted.

The TRX ensures that the LapD link can not be re-established.

3 T3109 expires and the BTS attempts to re-establish the LapD connection.

4 The ERROR REPORT (cause "O&M intervention") is sent to the BSC.

5 The TRX awaits completion of the re-initialisation sequence performed by the BSC (ref.[5]).

6 The BSC releases the RF resources for the connections on the associated TRX locally andperforms the call release sequence towards the MSC.

2.2.4.2 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 immediatelystop 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 arestill connected to the BTS will detect a radio link failure condition and therefore perform a local endrelease.

The sequence of events is as follows:

1) When the O&M event is received, the sending of all Radio interface frames are disabled forall active connections.

2) 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 oftime which the channel is out of use.

3) If the BTS has performed the reset sequence before the timer T3109 expires. The BTS willwait 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.

4) 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. TheTRX 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 "BSCinitiated 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 cellmay perform the cell re-selection procedure, as during this procedure no BCCH messages will be sentuntil 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 SACCHframes 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. Oncethe BTS counts a certain number of missing SACCH frames the radio link failure algorithm sends tothe BSC the CONNECTION FAILURE INDICATION (cause "Radio link failure"). The BSC theninitiates the "BSC initiated normal call release towards the MSC" and initiated the "BSC initiated RFchannel release towards the BTS" procedures towards all the channels involved in this connection.


35/75



The scenario below shows the BSS behaviour on detection of the radio link failure - see also eventN0700 in this document.

MSCBSCBTSMS

Start T9104

RF CHANNEL RELEASE

CONNECTION FAILURE INDICATION

Start T_RCR_ACK

CLEAR REQUEST

(1)

(4)

(2)

(3)

Note A

Note A

Note A

Figure 3-19

Note A : The BTS counts the number of missing SACCH frames.

(1) The MS disappears.

(2) The BTS starts to detect the radio link failure condition.

(3) The BTS detects the radio link failure condition and sends the CONNECTION FAILUREINDICATION (cause "Radio link failure") to the BSC.

(4) The BSC on reception initiates a call release to the MSC - see section 2.2.2.1 CrRel : BSCinitiated normal call release towards the MSC - and a release towards the BTS for thechannel 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 CONNECTIONFAILURE INDICATION (cause "Radio link failure") message. For more details, see ref.[2],[12] & [13].


36/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 theMS/BTS" (i.e. when it receives the CHANNEL RELEASE message). The MS mayalso initiate thisprocedure 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 therelease of LapDm SAPI 0.

MSCBSCBTSMS

T3111 expiry

CLEAR REQUEST

Start T9104

DISC

UA

RELEASE INDICATION

(SAPI 0)

RF CHANNEL RELEASE

(1)

(2)

(3)

(4)

Start T3111

Figure 3-20

(1) MS releases the LapDm by sending DISC at SAPI 0.

(2) The BTS relays the event to the BSC by sending a RELEASE INDICATION (SAPI 0) to theBSC.

The BSC releases immediately towards the MSC see section 2.2.2.1 CrRel : BSC initiatednormal call release towards the MSC.

Note during channel change procedures the RELEASE INDICATION (SAPI 0) may beignored - see ref.[2], [12] & [13].

The BSC starts T3111 so that the UA, which is to be sent to the MS by the BTS, can be sentbefore releasing the RF Channel.

(3) The UA is sent by the BTS to the MS at LapDm layer 2.

(4) The timer T3111 expires and the BSC initiates a release towards the BTS for the channelinvolved in this connection - see section 2.2.3.1 RfRel : BSC initiated RF channel releasetowards the BTS.

2.2.6 Call release trigger upon BSC detected events

This section contains a set of tables. Each table belongs to a specific L3 function (procedure) anddefines the messages (and therefore the protocol required) sent to each of the call release functionsupon 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.


37/75



The following table contains some abbreviations used in the notation.

Abbr Description

P A physical context procedure is to be performed on the main channel beforethe RF channel release procedure.

The absence of a P means that no physical context procedure will beperformed on the main channel.

Aint Abbreviation for "A interface".

OC Abbreviation for "Old RF Channel(s)"

Used in notation during channel change procedure to represent the channelto which the MS was connected.

NC Abbreviation for "New RF Channel(s)".

Used in notation during channel change procedure to represent the channelto which the MS is to be connected to.

RFC Abbreviation for the currently in use "RF Channel".

Used in notation when no channel change is in progress or when there isonly one channel allocated to the transaction.

NA 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 : BSCinitiated channel release towards the MS/BTS on page 30.

A release of both the MS and the BTS is to be performed. Thisscenario is always specified with a cause value contained in Table3-3. This cause value will be sent in the CHANNEL RELEASEmessage.

SapiRel This release scenario is specified in section 2.2.3.5 "SapiRel :BSC initiated release towards the MS/BTS due to MS initiatedSAPI 0 disconnection on page 32.

T3111 is started and allowed to expire before performing the RFchannel release procedure.

RfRel The release scenario specified in section 2.2.3.1 "RfRel : BSCinitiated RF channel release towards the BTS on page 27will betriggered for the given channel.

LocRel This scenario causes in the BTS a local release (i.e. no messageexchange appears on A-bis interface) of all the radio channelsinvolved in this connection.

The release (if any) that is presently being performed towards theMS/BTS is to be cancelled and the RF channels concerned are tobe released locally (i.e. without exchange of messages).


38/75



BscRel This scenario causes in the BSC a local release of all the radiochannels 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 thefailure of a channel activation procedure.

For the channel involved in the activation procedure :

- If CHAN ACT NACK has been received : LocRel is performed-If nothing has been received : RfRel is performed

X 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 valueabbreviation

CHANNEL RELEASE GSM Cause values names

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

Messageabbreviation

Description

MscRel This message causes the scenario specified in section 2.2.1.1"MscRel : MSC initiated normal release towards the BSS on page16.

Release caused by MSC (i.e. reception of CLEAR COMMAND).

CrRel This message causes the scenario specified in section 2.2.2.1"CrRel : BSC initiated normal call release towards the MSC onpage 20.

Release initiated from BSC by sending CLEAR REQUEST with acause specified in table 3-5.

SccpRel This message causes the scenario specified in section 2.2.2.4"SccpRel : BSC initiated SCCP release towards the MSC onpage 25.

Release the SCCP connection.

HOF Send HANDOVER FAILURE message to the MSC with a causespecified in table 3-5.

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


39/75



AFcic Send ASSIGNMENT FAILURE message with a cause specified intable 3-5 and put the associated circuit in idle state. No explicitclearing sequence is performed to free the circuit.

X 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 valueabbreviation

Cause

value (hex)

CAUSE VALUES

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. TheBTS will detect the loss of synchronisation with the TC: see N0800.

The following table provides a list of call/resource release notation and their correspondingdescriptions. 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) scenariothere is an event number allocated.


40/75



The event number is made up of 1 to 3 letters followed by a four digit number. An event number isallocated in this document to events specified in ref.[6], [2], [1], [3], [12] & [13]. For each event numbera scenario is specified using the notation as shown in the table of examples below.

Example Description

Aint CrRel o&m

OC MsRel ar_un P

NC RfRel

Example during channel change where there are two RF channelsallocated to the connection.

On A interface perform a BSC initiated call release by sending a CLEARREQUEST message with the cause "O&M Intervention".

On the old RF channel perform a release of the MS and BTS by sending aCHANNEL 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, nophysical context procedure is required.

Aint HOF revoc

OC X

NC RfRel P

Channel change example.

On the A interface send a HANDOVER FAILURE message to the MSCwith cause "Radio interface failure - reversion to old channel".

On the old channel no release is required.

On the new channel an RF channel release procedure is to be initiatedpreceded by a physical context procedure.

Aint SccpRel

RFC MsRel ar_un P

No channel change is in progress in this example.

The A interface SCCP connection is released.

On the RF channel perform a release of the MS and BTS by sending aCHANNEL RELEASE message with the cause "Abnormal release,unspecified", a physical context procedure is required to be performed.

Aint CrRel rif

RFC LocRel

No channel change is in progress in this example.

On A interface perform a BSC initiated call release by sending a CLEARREQUEST message with the cause "Radio interface failure"

Release the RF channel locally.

Table 3-6 : Examples


41/75



2.2.7 Standard release scenarios

The following events and call release scenarios deal with cases where the MS is connected and acall/resource release scenario has not been started.

EVENTNO

EVENT DESCRIPTION BEHAVIOUR

N0100 Reception of ERROR INDICATION with cause values: TimerT200 expired (N200+1) times ; Unsolicited DM response,Multiple frame established state ; and Sequence error.

Aint CrRel rifRFC MsRel ar_na P

Note 3

N0200 Reception of RELEASE INDICATION (SAPI 0). Aint CrRel rifRFC SapiRel P

Note 3

N0300 Reception of O&M initiated release. Aint CrRel o&mRFC MsRel ar_un P

Note 3

N0400 Reception of ERROR REPORT cause "O&M intervention". Aint CrRel rifRFC LocRel

N0500 Primitive SCCP-N-DISC-IND - see Note 2- being sent by theSCCP entity.

Aint SccpRelRFC MsRel ar_un P

Note 3

N0600 Reception of CLEAR COMMAND. Aint MscRelRFC MsRel nr P

Note 3

N0700 Reception of CONNECTION FAILURE INDICATION (causeRadio link failure).

Aint CrRel rifRFC RfRel P

Note 3

N0800 Reception of CONNECTION FAILURE INDICATION (causeRemote transcoder failure).

Aint CrRel eqflRFC MsRel ar_un P

Note 3

N0900 Reception of RESET or internally detected Reset - seeref.[6].

Aint SccpRelRFC MsRel ar_un P

Note 3

N1000 Reception of RESET CIRCUIT - see ref.[7]. Aint SccpRelRFC MsRel ar_un P

Note 3

N1100 Reception of LapD failure. Aint CrRel rifRFC LocRel

N1200 Reception of ERROR REPORT (SAPI 0, cause "Messagesequence error") for an activated channel in the BSC.

Aint CrRel rifRFC MsRel ar_un P

Notes 1 & 3

N1400 Mismatch between BTS (idle resource) and BSC (busyresource) concerning Interference measurement reporting.

Aint CrRel rifRFC BscRel

N1500 Mismatch between BTS (busy resource) and BSC (idleresource) concerning channel activation.

Aint NA

RFC LocRel


42/75



N1600 Loss of the MS associated to the SDCCH/TCH channel (BTS

and BSC with busy resources) - see ref.[16]: autocleaningprocedure.

Aint CrRel rif

RFC RfRel PNote 3

N1700 Pre-emption of an on-going call due to higher priorityconnection request see ref.[16]: pre-emption procedure

Aint CrRel pre-empt

RFC MsRel prempt P

Table 3-7

Note 1 : The sending of the CHANNEL RELEASE message in this case will cause the BTS to sendanother ERROR REPORT (SAPI 0, cause "Message sequence error"). This is not a mis-behaviour as it is foreseen that the BTS will send this message in the future for otherreasons 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, itwill be sent to the MS before the release is performed.

The exchange of SCCP RELEASED and SCCP RELEASE COMPLETE messages on the Ainterface 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 BSCinitiated 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 theinitiation of the call release procedure.


43/75



2.2.8 Scenarios during immediate assignment

The reception of CLEAR COMMAND, CONNECTION FAILURE INDICICATION (cause Remotetranscoder 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].

EVENTNO


IA0101 CHAN ACT NACK all causes. Aint NARFC LocRel

IA0200 Expiry of T9103. I.e. non reaction of BTS during channelactivation procedure.

Aint NARFC RfRel

IA0300 Expiry of T3101. No establishment of channel after havingsent the IMMEDIATE ASSIGNMENT message to the MS.

Aint NARFC RfRel P

Note 1

IA0301 ESTABLISH INDICATION without a layer 3 message orwith a L3 message containing a protocol discriminatordifferent of RR, CC, MM, or a L3 message with skipindicator (RR) different of zero..

Aint NARFC MsRel ar_un P

IA0400 Expiry of T9105 after the sending of the SCCP-N-CONNECT- REQ.

I.e. no response has been received from the MSC.

Aint SccpRelNote 5

RFC MsRel ar_te P

IA0500 Reception of an SCCP-N-DISC-IND.

See Note 2.

Aint NARFC MsRel nr P

IA0600 Whilst the SCCP connection establishment phase of theimmediate assignment procedure a releasing eventoccurred on the Radio/A-bis interface.

Aint SccpRelNote 4

RFC see Note 3

IA0700 CHANNEL ACTIVATION ACKNOWLEDGE after IA0900. Aint NARFC RfRel P

IA0702 CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGEall causes after IA0900.

Aint NARFC LocRel

IA0703 T9103 expiry after IA0900. Aint NARFC RfRel

IA0800 ESTABLISH INDICATION with or without layer 3message after IA0901.

Aint NARFC MsRel ar_un P

IA0801 T3101 expiry after IA0901. Aint NARFC RfRel P

Note 1

IA0900 Reception of RESET or internally detected reset duringRF channel activation (T9103 is running). The outcome ofthe activation is awaited.

Aint NARFC await IA070X


44/75



IA0901 Reception of RESET or internally detected reset duringMS establishment procedure (T3101 is running). Theoutcome of the establishment is awaited.

Aint NARFC await IA080X

Table 3-8

Note 1 : Due to performance problems with the availability of SDCCH channels, the RF channelrelease 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 asfollows:

- if the DTAP is for SAPI 0, it is transmitted towards the MS prior to any possibleCHANNEL RELEASE, (Note the message could be a CM SERVICE REJECT orLOCATION UPDATING REJECT),

- if the DTAP is for SAPI 3 and SAPI 3 connection is established, it is transmittedtowards 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 immediatelyafter the event on the Radio/A-bis was detected, and is dependant on the event which wasdetected during the period when the SCCP connection establishment was awaited. Seerelease scenarios in the section 2.2.7 Standard release scenarios" for the required scenarioon 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.


45/75



2.2.9 Scenarios during normal assignment

The reception of CONNECTION FAILURE INDICATION (cause Remote transcoder failure), isimpossible 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 yetto 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.

EVENTNO


A0100 (Old channel) ASSIGNMENT FAILURE from MS. Aint AF revocNote 1

OC XNC RfRel P

A0201 (New channel) CHAN ACT NACK cause "Requestedtranscoding / rate adaptation not available" for a Data call

Aint AF raunOC XNC ActRel

A0202 CHAN ACT NACK cause "Radio resource not available" or"Protocol error".

Aint AF rifOC XNC ActRel

A0203 CHAN ACT NACK cause "O&M Intervention". Aint AF rifOC X

NC ActRel

A0204 CHAN ACT NACK cause "Encryption algorithm notimplemented" - Note 5.

Aint AF cansOC XNC ActRel

A0205 CHAN ACT NACK received with an unexpected cause value. Aint AF rifOC XNC ActRel

A0206 (New channel) CHAN ACT NACK cause "Requestedtranscoding / rate adaptation not available" for a Speech call

Aint AF spun

OC X

NC ActRel

A0300 (New channel) Expiry of T9103. I.e. non reaction of BTSduring Channel activation procedure.

Aint AF rifOC XNC ActRel

A0400 (New channel) Reception of ASSIGNMENT COMPLETEfrom the MS.

Aint X

Call Release B9

Documents