ChannelModificationB10 PDF

All rights reserved.
Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Evolium.
Site VELIZY Originators F. TOMASSONI
EVOLIUM SAS CHANNEL MODIFICATION RELEASE B10
System Sub-system Document Category
: : :
ALCATEL-LUCENT GSM BSS SYS-TLA PRODUCT DEFINITION
ABSTRACT
This document specifies the "channel modification procedure" (transition from speech to data or from data to speech during a call, change of data rate during a call). Approvals S. BARRE
SYT CCM
M. TITIN-SCHNAIDER
SYT DPM
R. SABELLEK
BTS DPM
Name App.
SONG J.
BSC DPM
REVIEW
HISTORY
Ed. 01 Proposal 01 <24/05/2007> Proposal 01 based on release 7 version ref. 3BK 11202 0287 DSZZA Ed5 + addition of B10 impacts: AMR-WB and TFO with AMR-WB. Removed all references to Data transmission at 14.4 kbit/s (not supported). <12/06/2007> BSC G2 shall support AMR-WB. Remarks from Raphalle Mauger taken into account (see review report Wireless/GSM-WiMAX/R&D/SYT/FTO /207123_1). <22/06/2007> Remarks from Raphalle Mauger and Wei Yu taken into account (see review report: Wireless/GSM-WiMAX/R&D/SYT/FTO/207135_1). Update of BSC analysis of ASSIGNMENT REQUEST message. 29/10/2007 Takes into account the following approved CRs: 3BKA20CBR216691 v1 (Channel Modification: Circuit pool in Assignment Complete / Failure) 3BKA20CBR217595 v1 (Channel Modification: BTS analysis of MODE MODIFY for TFO enabling)
Ed. 01 Proposal 02
Ed. 01 Released
Ed. 02 Released
ED02 RELEASED
0475_02.doc
B10 Channel Modification

29/10/2007
3BK 11202 0475 DSZZA
1/52
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Evolium.
TABLE OF CONTENTS
1 INTRODUCTION ...........................................................................................................................................5 1.1 SCOPE...................................................................................................................................................5 1.2 DEFINITIONS ........................................................................................................................................5 2 FUNCTIONAL DESCRIPTION......................................................................................................................6 2.1 GENERAL DESCRIPTION ....................................................................................................................6 2.1.1 CC In-call modification.................................................................................................................6 2.1.2 Transmission speed change of Fax group 3 equipment transmitting in transparent mode.........7 2.2 STRATEGY ON CHANNEL MODIFICATION UNSUCCESSFUL CASES ...........................................7 2.3 BSS ENTITIES ......................................................................................................................................8 2.3.1 BSC .............................................................................................................................................8 2.3.2 BTS..............................................................................................................................................8 2.3.3 Transcoder and rate adaptation unit............................................................................................8 3 DYNAMIC BEHAVIOUR ...............................................................................................................................9 3.1 GENERAL BEHAVIOUR .......................................................................................................................9 3.1.1 Successful cases.........................................................................................................................9 3.1.2 Error cases ................................................................................................................................10 3.1.3 CHANNEL MODIFICATION state /event transition diagram & table.........................................22 3.1.4 Filtering of the CFI message .....................................................................................................26 3.2 DETAILED BEHAVIOUR WITHIN BSS ENTITIES .............................................................................27 3.2.1 BSC ...........................................................................................................................................27 3.2.2 BTS............................................................................................................................................37 3.2.3 Data rates ..................................................................................................................................38 3.2.4 MS behaviour.............................................................................................................................39 3.2.5 MSC behaviour ..........................................................................................................................39 3.3 INTERACTION WITH OTHER PROCEDURES ..................................................................................39 3.3.1 Handover ...................................................................................................................................39 3.3.2 Short message service ..............................................................................................................39 3.3.3 Interaction with DTAP SAPI 0....................................................................................................40 3.3.4 Interaction with Call Release .....................................................................................................40 3.3.5 Interaction with Ciphering procedure .........................................................................................40 3.3.6 Interaction with directed retry.....................................................................................................40 4 INTERFACE DESCRIPTIONS ....................................................................................................................41 4.1 GSM INTERFACES/PHYSICAL INTERFACES..................................................................................41 4.1.1 Radio interface...........................................................................................................................41 4.1.2 A interface..................................................................................................................................41 4.1.3 Abis interface .............................................................................................................................41 4.2 INTERNAL INTERFACES ...................................................................................................................41 4.2.1 In-band signalling.......................................................................................................................41 4.2.2 Interface with RAM ....................................................................................................................41 4.2.3 Messages description ................................................................................................................42 4.3 EXTERNAL INTERFACES..................................................................................................................42 4.4 PARAMETERS LIST ...........................................................................................................................43 4.5 TIMERS LIST.......................................................................................................................................44 5 RELEASES CHANGES...............................................................................................................................45 6 FEATURES .................................................................................................................................................46 7 GLOSSARY.................................................................................................................................................47
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
2/52
INTERNAL REFERENCED DOCUMENTS

Not applicable
REFERENCED DOCUMENTS
3GPP references [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] 3GPP TS 44.018 3GPP TS 24.008 3GPP TS 48.008 3GPP TS 48.058 3GPP TS 48.060 3GPP TS 43.045 3GPP TS 43.046 3GPP TS 27.001 3GPP TS 44.021 3GPP TS 48.020 Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol Mobile Radio Interface Layer 3 specification; Core Network Protocols Mobile-services Switching Centre - Base Station System (MSC BSS) interface Layer 3 specification Base Station Controller - Base Transceiver Station (BSC - BTS) interface Layer 3 specification In-band control of remote transcoders and rate adaptors for full rate traffic channels Technical Realization of Facsimile Group 3 Transparent Technical Realization of Facsimile Group 3 non-Transparent General on Terminal Adaptation Functions for Mobile Stations Rate Adaptation on the MS-BSS interface Rate Adaptation on the BSS-MSC interface
Alcatel references
[11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25]
3BK 11202 0438 DSZZA 3BK 11202 0432 DSZZA 3BK 11202 0466 DSZZA 3BK 11203 0134 DSZZA 3BK 11202 0476 DSZZA 3BK 11202 0173 DSZZA 3BK 11202 0437 DSZZA 3BK 11202 0433 DSZZA 3BK 11202 0435 DSZZA 3BK 11202 0445 DSZZA 3BK 11202 0156 DSZZA 3BK 11202 0457 DSZZA 3BK 11202 0440 DSZZA 3BK 11203 0140 DSZZA 3BK 11202 0479 DSZZA
Normal Assignment Procedure Call Release TC/BTS Interface BSS Telecom Parameters DTX Functional Specification Protocol Error Handling Internal Channel Change Classmark Handling External Channel Change Resource Allocation and Management Ciphering Procedure System Information Management Radio & Link Establishment Layer 3 message dictionary - Abis interface TFO Functional Specification
RELATED DOCUMENTS
None.
PREFACE
This document specifies the Alcatel BSS behaviour during the Channel modification procedure.
OPEN POINTS / RESTRICTIONS

ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
3/52
None.
ED02 RELEASED
0475_02.doc
29/10/2007
3BK 11202 0475 DSZZA
4/52
INTRODUCTION
1.1
SCOPE
This document describes, using the channel modification procedure during an already active call, how the Alcatel BSS: 1. changes a bearer service (speech - transparent data - non transparent data), 2. or changes the transmission speed of a Fax group 3 call. The document sums up briefly which teleservice or bearer service requires the usage of this procedure. The main object of the document is to describe how the assignment request procedure (A interface), the mode modify procedure (Abis interface) and the channel mode modify procedure (Radio interface) are used to perform channel modification for single slot configuration. It is shown how those procedures interact with the CC modify procedure. However the modify procedure which is part of the call control sublayer is not described in detail, as it is transparent to the BSS. The call release scenarios which occur as a result of events during the protocol are specified in ref.[12]. The referencing of these events in ref.[12] are provided by means of the reference and an event number within ref.[12]. The event number takes the form of 1 to 4 characters string followed by 4 numbers - e.g. ref.[12] ICM0100. These event numbers are to be found in ref.[12] together with the assignment failure scenario.
1.2
DEFINITIONS
CC In-call modification: Call control procedure which consists in a service change within an active call (e.g. via MMI) initiated by the MS. Prerequisite: Dual service has been activated in the SET-UP. Channel mode: In some GSM series the "Channel Mode" is coded in a different way (even if the same name is used). The "Channel Mode" defined in 3GPP TS 44.018 (e.g. in ASSIGNMENT COMMAND) is a 2 octet field. The "Channel Mode" in 3GPP TS 48.058 (e.g. in MODE MODIFY message) is a 6 octet field and has a different coding as "Channel Type" defined in 3GPP TS 48.008 (e.g. in ASSIGNMENT REQUEST), see details further in this document. Dual service: A dual service is indicated by two Bearer Capability information elements in the initial SET-UP message (preceded by a repeat indicator). This indicates that the subscriber may request a CC in-call modification within the call. Interworking function: Gateway for data communication with users outside GSM network. The interworking function (IWF) is located at MSC side.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
5/52
FUNCTIONAL DESCRIPTION
2.1
GENERAL DESCRIPTION
The channel modification procedure is used during the active phase of a call. It can be triggered externally by the MSC in order to: 1. change the service (CC In-call modification), 2. or change the transmission speed in a Fax group 3 call in transparent mode. From the BSS point of view, all cases result in another TCH ASSIGNMENT REQUEST from the MSC. The BSS identifies them by the fact that a TCH has already been assigned for speech or data to the MS connection and another TCH ASSIGNMENT REQUEST has been received for speech or data, without any change of terrestrial circuit. The BSS can not make the difference between the CC in-call modification and the fax transmission speed change. 2.1.1 CC In-call modification
The CC "in-call modification" allows a user (via MMI) to initiate a service transition during the active phase of a call. The services covered by the CC in-call modification are: - BS20: Asynchronous General Bearer Service. - BS30: Synchronous General Bearer Service. - BS40: General PAD Access Bearer Service. - BS50: General Packet Access Bearer Service.. - BS61: Alternate Speech/unrestricted digital - transparent. - BS61: Alternate Speech/unrestricted digital - non transparent. - BS81: Speech followed by Data - transparent. - BS81: Speech followed by Data - non transparent. - TS61: Alternate Speech/Fax group 3 - transparent. (Only the dual service transition phase of the call - not the transmission speed change). - TS61: Alternate Speech/Fax group 3 - non transparent. CC in-call modification is only performed for TCH full rate: BS61 does not allow the change of the traffic channel rate: the MSC shall allocate a full rate channel from the beginning of the call if full rate is needed for either the speech or the data part. So, CC in-call modification may be performed: . from full rate speech to full rate data, or vice versa; . from half rate (speech/data) to half rate (data/speech). Half rate data is not supported: the last case is not used. BS81 does not allow the change of the traffic channel rate from half rate (speech) to full rate (data): the MSC shall allocate a full rate channel for speech if full rate is needed for data. So, CC in-call modification may be performed: . from full rate speech to full rate data, . from full rate speech to half rate data, . from half rate speech to half rate data. Half rate data is not supported: the two last cases are not used. TS61 only uses full rate.
The teleservice 62 - Automatic facsimile group 3 - is not a dual service and does not belong to the services addressed by the CC in-call modification. However, TS62 Fax machines (transmitting in transparent mode) have the possibility to change the speed (see next point).
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
6/52
Note 1: If TS62 Fax machines transmitting in non transparent mode change the transmission speed, the BSS will not be impacted. The transmission speed change is done in the Radio Link Protocol and all BSS/Radio parameters do not change. Therefore the "TS62 non transparent" is a service which can be offered by the BSS like a normal data call. 2.1.2 Transmission speed change of Fax group 3 equipment transmitting in transparent mode
The transmission speed change is triggered by the MSC in case of Fax group 3 in transparent mode. If the Fax group 3 equipment detects the need to change the transmission speed (reduction from 12 kbit/s to 2.4 kbit/s by step of 2.4 kbit/s, or vice versa), the Interworking Function (IWF) in the MSC has to change the transmission speed as requested. Note 2: See ANNEX 1 section A1.2 for different cases of fax transmission speed change. The affected services are: - TS61: Alternate Speech/Fax group 3 - transparent. (only the transmission speed change - not the service transition) - TS62: Automatic Fax group 3 - transparent. Note 3: TS61 and TS62 only use full rate. The essential differences between the in-call modification and fax speed change are: The RR procedure is common to both. The trigger for ICM is the MODIFY message, the speed change procedure is triggered by inband signalling from Fax equipment towards the IWF (which is transparent to the BSS). In case of in-call modification the originating MS receives the CHANNEL MODE MODIFY message in state U26 (state, coming from the active state, where the MS has sent the MODIFY message - see ref.[1]). In case of transmission speed change the MS receives the CHANNEL MODE MODIFY message in the active state (U10 - see ref.[1]).
2.2
STRATEGY ON CHANNEL MODIFICATION UNSUCCESSFUL CASES
Alcatel BSS strategy during Channel Modification procedure is to provide a grade of service as high as possible attempting to revert the call to the old mode, when applicable, during the unsuccessful cases. The call is kept active if the channel mode between MS and BTS is "ascertained" consistent and BTS is still under BSC's control. The call is cleared either in case of proved channel mode inconsistency between MS and BTS or in case of no answer from BTS. When the channel mode is unpredictable due to no answer from MS, we assume that the MS is still present on the old mode and the call is not cleared; when the mode is unpredictable due to no answer from BTS, the call is cleared. These assumptions represent the common base for the whole of scenarios shown through this document and are summarised as follows: a. No answer received by BSC from BTS (T9103 expiry) after BSC sending the MODE MODIFY message; BSC starts immediately RF channel release and sends the ASSIGNMENT FAILURE message to MSC; BTS is in error state. See section 3.1.2.2 case b. b. No answer received by BSC from MS (T9112 expiry) or the MS reports with the CHANNEL MODE MODIFY ACKNOWLEDGE (old mode) after sending the CHANNEL MODE MODIFY message. The MS is still present and assumed being in the old mode although unpredictable. Therefore BSC sends the MODE MODIFY message to BTS (old mode); at this point in time, if BTS acknowledges the reversion to old mode the call is kept active, otherwise it is cleared. The MSC, upon receipt of the ASSIGNMENT FAILURE message from the BSC, will send either a MODIFY REJECT message to inform the MS (successful reversion to old mode, see section 3.1.2.3 case a) or a CLEAR COMMAND message to the BSC (unsuccessful reversion, see section 3.1.2.4 cases b, c, d). c. BSC receives the MODE MODIFY NEGATIVE ACKNOWLEDGE message from BTS after T9112 expiry. MS is assumed to be still in the old mode whereas BTS is in the new mode. BSC starts immediately RF channel release and sends the ASSIGNMENT FAILURE message to MSC. See section 3.1.2.4 case a.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
7/52
2.3
BSS ENTITIES
The BSS entities involved in the channel modification procedure are: 2.3.1 BSC
Resource Allocation and Management (RAM) Entity This entity is responsible of managing radio resources of the BSS. The RAM behaviour is described in ref.[20]. Channel Modification Entity This entity is responsible of managing the channel modification. 2.3.2 BTS
BTS Protocol entity The message handling function in the BTS Protocol entity has to handle the following channel modification related messages: MODE MODIFY, MODE MODIFY ACKNOWLEDGE, MODE MODIFY NEGATIVE ACKNOWLEDGE. Furthermore, the BTS layer 3 has to inform the channel encoder and the channel decoder of the new channel mode. The channel decoder has to change the type of TRAU frames in uplink direction according to the requested mode. Channel encoder/Channel decoder These entities must change the interleaving/encoding/decoding for speech and data (and within data to different data-rates) according to the request from the BTS layer 3. 2.3.3 Transcoder and rate adaptation unit
The TRAU has to perform the switch from data to speech (and vice versa) according to the commands sent by the BTS (via control bits in the received TRAU frames) - see ref.[13].
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
8/52
DYNAMIC BEHAVIOUR
3.1
3.1.1
GENERAL BEHAVIOUR
Successful cases
This section contains the successful cases of a channel modification. For the complete scenarios please see Annex 1. This section describes the channel modification triggered by MSC, who sends an ASSIGNMENT REQUEST to the BSS in order to: 1. perform the CC in-call modification, 2. or change the transmission speed of a Fax group 3 call. Only Radio, Abis and A interface messages are used in the message sequence charts within this section. The following message sequence chart shows the scenario of a successful transition for following cases: 1. MS originated CC in-call modification (see ANNEX 1, section A1.1); 2. FAX transmission speed change (see ANNEX 1, section A1.2). It should be noted that the BSS can not make the difference between the above two cases. MS BTS BSC MSC
(1) (1) (1) (1) (2) (2) (3) (3) (4) (4) (4) (5) (5) (5)
ASSIGNMENT REQUEST <------------------------- start Trr1 MODE MODIFY <------------------------- start T9103 MODE MODIFY ACKNOWLEDGE -------------------------> CHANNEL MODE MODIFY stop T9103 <-------------------------------------------------start T9112 CHANNEL MODE MODIFY ACKNOWLEDGE --------------------------------------------------> stop T9112 ASSIGNMENT COMPLETE -------------------------> Stop Trr1 Figure 1: Successful channel modification
Upon receipt of the ASSIGNMENT REQUEST message, the BSS performs channel modification procedure. The trigger for the BSC is the TCH ASSIGNMENT REQUEST when a TCH is already assigned, for a given transaction, identified by its SCCP reference. The BSC analyses the channel mode (see Table 3-6a and Table 3-6b) and performs channel mode modify. Note: The channel rate is not changed during CC in-call modification: Channel rate modification is only allowed for "followed by" services (see section 2.1), from full rate speech to half rate data. But half rate data is not supported. The BSC initiates channel mode modify by sending a MODE MODIFY message to BTS. The message contains the new mode to be used. At this point in time the BSC starts timer T9103. B10 Channel Modification
0475_02.doc
ED02 RELEASED
29/10/2007
3BK 11202 0475 DSZZA
9/52
Upon receipt of the MODE MODIFY message, the BTS layer 3 switches the layer 1 entities to the new channel mode, starts timer T_CFI_TR and responds with a MODE MODIFY ACKNOWLEDGE message to BSC. The TRAU gets information whether data or speech is applicable via in-band signalling from the channel decoder (see ref.[13]). Upon receipt of the MODE MODIFY ACKNOWLEDGE message, the BSC stops T9103; sends the CHANNEL MODE MODIFY message to the MS to request the changing of the mode for the indicated channel ; starts T9112 to supervise the channel mode modification. The CHANNEL MODE MODIFY message contains the reference of the channel and the new mode to use. When the MS receives the CHANNEL MODE MODIFY message, it changes the mode for the indicated channel and then replies by a CHANNEL MODE MODIFY ACKNOWLEDGE message indicating the new channel mode. Upon receipt of the CHANNEL MODE MODIFY ACKNOWLEDGE message, the BSC stops timer T9112 and sends the message ASSIGNMENT COMPLETE to MSC. Error cases
3.1.2
This section contains the failure cases of a channel modification triggered by the MSC, these consist mainly of timer errors and 3GPP defined messages. In this section message protocol errors or internal system errors are not taken into account; these cases are dealt with in the section on detailed dynamic behaviour where the checking and error handling is specified. Only Radio, Abis and A interface messages are used in the message sequence charts within this section. 3.1.2.1 Assignment Failure (in BSC)
The following message sequence chart deals with the MS originated CC in-call modification or fax transmission speed change (see ANNEX 1). In case of unacceptable parameters in the ASSIGNMENT REQUEST message (see section 3.2.1.1), the assignment is to be rejected. MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4)
MODIFY ------------------------------------------------------------------------------> ASSIGNMENT REQUEST <----------------------- start Trr1 ASSIGNMENT FAILURE -----------------------> MODIFY REJECT Stop Trr1 <------------------------------------------------------------------------------
Figure 2: Scenario of an unsuccessful in-call modification procedure. Rejection reason: assignment cannot be performed (any reason). 1, 2 3 See ANNEX 1. Upon receipt of the ASSIGNMENT REQUEST message, the BSC checks whether the new channel mode can be supported or not. The checking is not successful (see detailed behaviour section 3.2.1.1). The BSC informs the MSC of the failure of channel modification procedure by sending the ASSIGNMENT FAILURE message as specified in ref.[12], events ICM0100, ICM0200, ICM0600, ICM0205.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
10/52
Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message MODIFY REJECT to the MS and stops timer Trr1.
Cause values in the ASSIGNMENT FAILURE message: * Ref.[12] ICM0100: - Value: protocol error between BSC and MSC. The ASSIGNMENT REQUEST message indicates a change from half rate speech to full rate speech or vice versa (which is not a case of CC in-call modification). The ASSIGNMENT REQUEST message indicates a change from half rate speech to full rate data or vice versa (which is not a case of CC in-call modification). The ASSIGNMENT REQUEST message indicates a change from full rate data to half rate data (which is not a case of CC in-call modification). The ASSIGNMENT REQUEST message indicates a change from full rate speech to half rate data (which is not a case of CC in-call modification). The ASSIGNMENT REQUEST message indicates a change of speech version (which is not a case of CC in-call modification).
* Ref.[12] ICM0200: - Value: requested transcoding/rate adaptation unavailable. The ASSIGNMENT REQUEST message indicates a data rate of 1.2/0.075 kbit/s. The ASSIGNMENT REQUEST message indicates a data rate of 6 kbit/s non transparent. The ASSIGNMENT REQUEST message indicates a data rate higher than 12 kbit/s. The ASSIGNMENT REQUEST message indicates a change from half rate speech to half rate data.
* Ref.[12] ICM0600: - Value: radio interface failure, reversion to old channel. The ASSIGNMENT REQUEST message indicates a different CIC to the one which is presently used for the connection.
* Ref.[12] ICM0205: - Value: requested speech version unavailable. None of the speech version(s) indicated in the ASSIGNMENT REQUEST message is supported by the currently allocated resource.
3.1.2.2
Mode Modify Rejection from BTS
The message sequence charts of Figure 3a & Figure 3b deal with the CC in-call modification (see Figure A-1 & Figure A-2) or fax transmission speed change case (see ANNEX 1, Figure A-4). Two error cases are to be considered: a) BTS answers upon the MODE MODIFY message with MODE MODIFY NEGATIVE ACKNOWLEDGE message. b) BTS does not answer on the MODE MODIFY message (T9103 expires in the BSC).
case a) BTS answers upon the MODE MODIFY message with MODE MODIFY NEGATIVE ACKNOWLEDGE message
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
11/52
MS
BTS
BSC
MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (5) (6) (6)
MODIFY ------------------------------------------------------------------------------> ASSIGNMENT REQUEST <----------------------- start Trr1 MODE MODIFY <----------------------- start T9103 MODE MODIFY NEGATIVE ACKNOWLEDGE -----------------------> stop T9103 ASSIGNMENT FAILURE -----------------------> MODIFY REJECT Stop Trr1 <-----------------------------------------------------------------------------Figure 3a: Scenario of an unsuccessful in-call modification. Rejection reason: error condition in BTS.
1, 2, 3 4 5
See ANNEX 1. There is an error condition in the BTS. It responds with a MODE MODIFY NEGATIVE ACKNOWLEDGE message to the BSC. The BTS keeps the old channel mode. Upon receipt of the MODE MODIFY NEGATIVE ACKNOWLEDGE message, the BSC sends an ASSIGNMENT FAILURE message to the MSC as specified in ref.[12], event ICM0300, and stops timer T9103. Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message MODIFY REJECT to the MS and stops timer Trr1.
Cause values in the MODE MODIFY NEGATIVE ACKNOWLEDGE message: 3GPP TS 48.058 proposes "most appropriate cause value", e.g.: Value: radio resource not available: The Channel number does not comply with the BTS configuration. Value: requested transcoding\rate not available: The BSC indicates half rate data. Value: service or option not implemented, unspecified: The BSC indicates SDCCH or signalling on TCH. Value: general information element error, mandatory information element error, invalid information element contents, message sequence error. Cause values in the ASSIGNMENT FAILURE message: * Ref.[12] ICM0300: Value: radio interface failure, reversion to old channel. This cause is used whatever the Cause value received in the MODE MODIFY NEGATIVE ACKNOWLEDGE message.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
12/52
case b)
BTS does not answer to the MODE MODIFY message (T9103 expires in the BSC) MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4) (4) (4) (4) (5) (5) (6)
MODIFY ------------------------------------------------------------------------------> ASSIGNMENT REQUEST <----------------------- start Trr1 MODE MODIFY <----------------------- start T9103 : : T9103 expiry ASSIGNMENT FAILURE start T9110 -----------------------> CLEAR COMMAND <----------------------- Stop Trr1 stop T9110 Figure 3b: Scenario of an unsuccessful in-call modification. Rejection reason: BTS does not answer.
1, 2, 3 4
See ANNEX 1. The BSC does not receive the MODE MODIFY ACKNOWLEDGE message before T9103 expiry because the message is lost on Abis interface. Timer T9103 expires in the BSC. The BSC sends the CHANNEL RELEASE message to MS and then sends RF CHANNEL RELEASE message to BTS; sends the ASSIGNMENT FAILURE message to the MSC as specified in ref.[12], event ICM0502, and starts T9110 (see assumption "a" in section 2.2). If BSC receives the message ERROR REPORT with cause "message sequence error" from BTS, it releases the call and all the running timers are stopped. The ERROR REPORT message with any other cause will be discarded. Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message CLEAR COMMAND to the BSC and stops timer Trr1. Upon receipt of the CLEAR COMMAND message, the BSC stops T9110.
5 6
Cause value in ASSIGNMENT FAILURE message: * Ref.[12] ICM0502: Value: radio interface message failure. In case of remote transcoder alarm, the CONNECTION FAILURE INDICATION message cause "remote TC alarm" will be sent and the BSC will initiate call release, as foreseen in other cases.
3.1.2.3
Channel Mode Modify Failure in MS
The following message sequence charts deal with the CC in-call modification (see Figure A-1 and Figure A-2 of ANNEX 1). They are also valid for some Fax transmission speed change cases (see Figure A-4).
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
13/52
Three error cases are to be considered:
case a) BSC.
The MS does not answer to the CHANNEL MODE MODIFY message, timer T9112 expires in the
MS
BTS
BSC
MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (6) (6) (6) (7) (7) (8) (8) (9) (9) (10) (10)
MODIFY ------------------------------------------------------------------------------> ASSIGNMENT REQUEST <----------------------- start Trr1 MODE MODIFY(new mode) <----------------------- start T9103 MODE MODIFY ACKNOWLEDGE -----------------------> CHANNEL MODE MODIFY(new mode) stop T9103 <--------------------------------------------------- start T9112 : : T9112 expiry MODE MODIFY(old mode) <----------------------- start T9103 MODE MODIFY ACKNOWLEDGE -----------------------> stop T9103 CHANNEL MODE MODIFY(old mode) <--------------------------------------------------ASSIGNMENT FAILURE -----------------------> MODIFY REJECT Stop Trr1 <-----------------------------------------------------------------------------Figure 4a: Scenario of an unsuccessful channel mode modify procedure. Rejection reason: error condition in MS.
1-5 6
7 8
9 10
See ANNEX 1. The MS does not report CHANNEL MODE MODIFY ACKNOWLEDGE to the network. Timer T9112 expires in the BSC. The BSC tries to change back to the old channel mode by sending MODE MODIFY message to the BTS. The message CHANNEL MODE MODIFY ACKNOWLEDGE is discarded if it is received after T9112 expiry. Upon receipt of the MODE MODIFY message, the BTS layer 3 switches the layer 1 entities to the old mode and sends a MODE MODIFY ACKNOWLEDGE message to the BSC. Upon receipt of the MODE MODIFY ACKNOWLEDGE message, the BSC sends CHANNEL MODE MODIFY message with the old mode to the MS and does not wait for the CHANNEL MODE MODIFY ACKNOWLEDGE message. The BSC does not start T9112. The BSC sends ASSIGNMENT FAILURE message to inform the MSC of the channel mode modify failure with the cause as specified in ref.[12], see below. Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message MODIFY REJECT to the MS and stops timer Trr1. See assumption "b" in section 2.2. Note: This failure condition is not explicitly foreseen in GSM. No specific channel mode modify failure message exists where the MS can report that a channel modification has failed.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
14/52
Cause values in the ASSIGNMENT FAILURE message: * Ref.[12] ICM0400: Value: radio interface failure, reversion to old channel.
case b)
The MS acknowledges the CHANNEL MODE MODIFY message with the old channel mode
This behaviour occurs with GSM phase 2 MS but it may occur with GSM phase 1 MS as well (MS manufacturer dependent) (this specific behaviour does not require the checking of the MS revision level by the BSC): it occurs when the MS finds that it cannot change to the indicated mode. MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (7) (7) (8) (8) (9) (9) (10) (10)
MODIFY ------------------------------------------------------------------------------> ASSIGNMENT REQUEST <----------------------- start Trr1 MODE MODIFY(new mode) <----------------------start T9103 MODE MODIFY ACKNOWLEDGE -----------------------> CHANNEL MODE MODIFY(new mode) stop T9103 <--------------------------------------------------start T9112 CHANNEL MODE MODIFY ACK (old mode) ---------------------------------------------------> stop T9112 MODE MODIFY(old mode) <----------------------start T9103 MODE MODIFY ACKNOWLEDGE -----------------------> stop T9103 ASSIGNMENT FAILURE -----------------------> Stop Trr1 MODIFY REJECT <----------------------------------------------------------------------------Figure 4b: Scenario of an unsuccessful channel mode modify procedure. Rejection reason: error condition in MS which acknowledges with the old mode.
1-5 6
See ANNEX 1. The MS cannot change to the indicated mode and reports CHANNEL MODE MODIFY ACKNOWLEDGE message with the old mode in the Channel Mode IE to the network. The BSC actions depending on the mode reported by the MS are described in section 3.2.1.7. The BSC tries to change back to the old channel mode by sending MODE MODIFY message to the BTS. Upon receipt of the MODE MODIFY message, the BTS layer 3 switches the layer 1 entities to the old mode and sends a MODE MODIFY ACKNOWLEDGE message to the BSC. Upon receipt of the MODE MODIFY ACKNOWLEDGE message, the BSC sends the ASSIGNMENT FAILURE message to inform the MSC of the channel mode modify failure with the cause value as specified in ref.[12], see below. Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message MODIFY REJECT to the MS and stops timer Trr1.
7 8 9
10
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
15/52
case c) Error handling: the MS acknowledges the CHANNEL MODE MODIFY with no channel mode or the channel mode is inconsistent (different from the old or the new mode) The BSS behaviour described here aims to ensure the protocol robustness between the MS and the BSS. MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (6) (6) (6) (6) (7) (7) (8) (8) (9) (9) (10) (10)
MODIFY ------------------------------------------------------------------------------> ASSIGNMENT REQUEST <----------------------- start Trr1 MODE MODIFY(new mode) <----------------------- start T9103 MODE MODIFY ACKNOWLEDGE -----------------------> CHANNEL MODE MODIFY(new mode) stop T9103 <--------------------------------------------------- start T9112 CHANNEL MODE MODIFY ACKNOWLEDGE ---------------------------------------------------> stop T9112 MODE MODIFY(old mode) <----------------------- start T9103 MODE MODIFY ACKNOWLEDGE -----------------------> CHANNEL MODE MODIFY(old mode) stop T9103 <--------------------------------------------------ASSIGNMENT FAILURE -----------------------> MODIFY REJECT Stop Trr1 <------------------------------------------------------------------------------
Figure 4c: Scenario of an unsuccessful channel mode modify procedure.Rejection reason: error condition in MS which acknowledges with missing or inconsistent channel mode. 1-5 6 See ANNEX 1 The MS reports CHANNEL MODE MODIFY ACKNOWLEDGE message to the network in which: - the Channel Mode IE is not present or - the channel mode is different from the old and the new channel mode. The BSC tries to change back to the old channel mode by sending MODE MODIFY message to the BTS. See case a) Note: This failure condition is not explicitly foreseen in GSM.
7-10
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
16/52
3.1.2.4
Failure Cases while reverting to old channel mode
The following message sequence charts deal with the CC in-call modification (see Figure A-1 and Figure A-2 of ANNEX 1). They are also valid for some Fax transmission speed change (see Figure A-4). Figures 4a and 4b in the previous section depicts the need of a MODE MODIFY (old mode) message to revert to the old channel mode. It may happen that this reversion fails as well. Four cases are to be distinguished: case a) MODE MODIFY (old mode) message is answered with a MODE MODIFY NEGATIVE ACKNOWLEDGE message MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (6) (6) (6) (7) (7) (8) (8) (8) (9) (9) (10)
MODIFY ------------------------------------------------------------------------------------> ASSIGNMENT REQUEST <------------------------- start Trr1 MODE MODIFY(new mode) <------------------------- start T9103 MODE MODIFY ACKNOWLEDGE -------------------------> CHANNEL MODE MODIFY(new mode) stop T9103 <------------------------------------------------------- start T9112 : : : : T9112 expiry MODE MODIFY(old mode) <------------------------- start T9103 MODE MODIFY NEGATIVE ACKNOWLEDGE -------------------------> stop T9103 ASSIGNMENT FAILURE start T9110 -------------------------> CLEAR COMMAND stop Trr1 <------------------------stop T9110 The following actions are detailed in ref.[12].
Figure 5a: Scenario of an unsuccessful channel mode modify procedure. Rejection reason: error condition in MS. Reversion to old channel fails due to MODE MODIFY NEGATIVE ACKNOWLEDGE message. 1-5 6 See ANNEX 1. The MS does not report CHANNEL MODE MODIFY ACKNOWLEDGE message to the network before timer T9112 expiry in the BSC. The BSC tries to change back to the old channel mode by B10 Channel Modification
0475_02.doc
ED02 RELEASED
29/10/2007
3BK 11202 0475 DSZZA
17/52
sending MODE MODIFY message to the BTS. The message CHANNEL MODE MODIFY ACKNOWLEDGE is discarded if it is received by the BSC after T9112 expiry. 7 There is an error condition in the BTS. It responds with a MODE MODIFY NEGATIVE ACKNOWLEDGE message to BSC. The BTS does not change the channel mode. For cause values see section 3.1.2.2 (scenario 3a). Upon receipt of the MODE MODIFY NEGATIVE ACKNOWLEDGE message, the BSC sends an ASSIGNMENT FAILURE message to the MSC as specified in ref.[12], events ICM0501, sends the CHANNEL RELEASE message to MS and then the RF CHANNEL RELEASE message to BTS, start T9110 to supervise the response from MSC and stops timer T9103. See assumption "c" in section 2.2. Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message CLEAR COMMAND to the BSC, and stops timer Trr1. Upon receipt of the CLEAR COMMAND message, BSC stops T9110.
9 10
Cause values in the ASSIGNMENT FAILURE message: * Ref.[12] ICM0501: Value: radio interface message failure.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
18/52
case b)
MODE MODIFY (old mode) message is not answered by the BTS (timer T9103 expiry in the BSC) MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (6) (6) (6) (7) (7) (7) (8) (8) (9) (9) (10)
MODIFY ------------------------------------------------------------------------------------> ASSIGNMENT REQUEST <------------------------- start Trr1 MODE MODIFY(new mode) <------------------------- start T9103 MODE MODIFY ACKNOWLEDGE -------------------------> CHANNEL MODE MODIFY (new mode) stop T9103 <------------------------------------------------------- start T9112 : : T9112 expiry MODE MODIFY(old mode) <------------------------- start T9103 : : T9103 expiry ASSIGNMENT FAILURE start T9110 -------------------------> CLEAR COMMAND Stop Trr1 <------------------------stop T9110 The following actions are detailed in ref. [12]. Figure 5b: Scenario of an unsuccessful channel mode modify procedure. Rejection reason: error condition in MS. Reversion to old channel fails due time-out.
1-5 6
See ANNEX 1. The MS does not report CHANNEL MODE MODIFY ACKNOWLEDGE message to the network. Timer T9112 expires in the BSC. The BSC tries to change back to the old channel mode by sending MODE MODIFY message to the BTS. There is an error condition in the BTS. It does not answer the MODE MODIFY message. See 3.1.2.2 case b. Timer T9103 expires in the BSC. At T9103 expiry, the BSC sends the CHANNEL RELEASE message to MS and then the RF CHANNEL RELEASE message to BTS, as the mode between MS and BTS is unpredictable, see assumption "b" in section 2.2, sends an ASSIGNMENT FAILURE message to the MSC as specified in ref.[12] and starts T9110. Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message CLEAR COMMAND to the BSC, stops timer Trr1. Upon receipt of the CLEAR COMMAND message, BSC stops T9110.
7 8
9 10
Cause values in the ASSIGNMENT FAILURE message: * Ref.[12] ICM0500: ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
19/52
Value: radio interface message failure.
case c) MODE MODIFY NEGATIVE ACKNOWLEDGE received from BTS after CHANNEL MODE MODIFY ACKNOWLEDGE (old mode) received from MS MS (1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (7) (7) (7) (8) (8) (9) (9) (9) (10) (10) (11) BTS BSC MSC
MODIFY ------------------------------------------------------------------------------------> ASSIGNMENT REQUEST <------------------------- start Trr1 MODE MODIFY(new mode) <------------------------- start T9103 MODE MODIFY ACKNOWLEDGE -------------------------> CHANNEL MODE MODIFY (new mode) stop T9103 <------------------------------------------------------- start T9112 CHANNEL MODE MODIFY ACKNOWLEDGE (old mode) ---------------------------------------------------------> stop T9112 MODE MODIFY(old mode) <------------------------- start T9103 MODE MODIFY NEGATIVE ACKNOWLEDGE -------------------------> stop T9103 ASSIGNMENT FAILURE start T9110 -------------------------> CLEAR COMMAND stop Trr1 <------------------------stop T9110
Figure 5c: Scenario of unsuccessful channel mode modify procedure. Reversion to the old channel fails due MODE MODIFY NEGATIVE ACKNOWLEDGE message (inconsistent channel mode between MS and BTS) 1-5 6 7 8 See ANNEX 1. The MS reports CHANNEL MODE MODIFY ACKNOWLEDGE (old mode) to BSC within the T9112 timer. The BSC stops T9112, tries to change back to the old channel mode by sending MODE MODIFY(old mode) message to BTS and starts T9103. There is an error condition in the BTS, it responds with MODE MODIFY NEGATIVE ACKNOWLEDGE message to BSC. BTS does not change the channel mode. For cause value see section 3.1.2.2. Upon receipt of MODE MODIFY NEGATIVE ACKNOWLEDGE message, BSC sends ASSIGNMENT FAILURE to MSC, stops T9103, sends the CHANNEL RELEASE message to MS and then the RF CHANNEL RELEASE message to BTS, starts T9110 to supervise the MSC response. See assumption "b" in section 2.2. Upon receipt of ASSIGNMENT FAILURE message MSC sends CLEAR COMMAND message to BSC and stops Trr1. Upon receipt of CLEAR COMMAND message, BSC stops T9110.
10 11
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
20/52
Cause values in the ASSIGNMENT FAILURE message: * Ref.[12] ICM0402: Value: radio interface message failure. case d) MODE MODIFY (old mode) message is not answered by BTS (T9103 expiry in BSC) after CHANNEL MODE MODIFY ACKNOWLEDGE old mode received from MS MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (7) (7) (8) (8) (8) (8) (9) (9) (10)
MODIFY --------------------------------------------------------------------------------------> ASSIGNMENT REQUEST <------------------------- start Trr1 MODE MODIFY(new mode) <------------------------- start T9103 MODE MODIFY ACKNOWLEDGE -------------------------> CHANNEL MODE MODIFY (new mode) stop T9103 <--------------------------------------------------------- start T9112 CHANNEL MODE MODIFY ACKNOWLEDGE (old mode) ---------------------------------------------------------> stop T9112 MODE MODIFY(old mode) <------------------------- start T9103 : : T9103 expiry ASSIGNMENT FAILURE start T9110 -------------------------> CLEAR COMMAND stop Trr1 <---------------------stop T9110
Figure 5d: Scenario of unsuccessful channel mode modify procedure. Reversion to the old channel fails due to T9103 expiry after CHANNEL MODE MODIFY ACKNOWLEDGE (old mode) received from MS. 1-5 6 7 8 See ANNEX 1. The MS reports CHANNEL MODE MODIFY ACKNOWLEDGE message (old mode) to BSC within the T9112 timer. The BSC stops T9112, tries to change back to the old channel mode by sending MODE MODIFY message to BTS and starts T9103. There is an error condition in the BTS, it does not respond with MODE MODIFY ACKNOWLEDGE message to BSC. See section 3.1.2.2 case b. BTS does not change the channel mode. Upon T9103 expiry BSC sends ASSIGNMENT FAILURE to MSC, sends CHANNEL RELEASE message to MS and then RF CHANNEL RELEASE to BTS, starts T9110 to supervise the MSC response. See assumption "b" in section 2.2. Upon receipt of ASSIGNMENT FAILURE message MSC sends CLEAR COMMAND message to BSC and stops Trr1. Upon receipt of CLEAR COMMAND message, BSC stops T9110.
9 10
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
21/52
Cause values in the ASSIGNMENT FAILURE message: * Ref.[12] ICM0403: Value: radio interface message failure. 3.1.3 CHANNEL MODIFICATION state /event transition diagram & table
In order to give a more comprehensive and analytical description of the channel modification scenarios (successful and failed cases) a state/event approach is done. The following states are defined (only BSC side): "Call Active": It is the active phase of the call with a TCH allocated. For the channel modification procedure this state is the starting and the final state (successful case). "Call/Channel Release": It is a macro_state (its internal pending states are not taken into account, for more details see ref.[12]) where the call is cleared. "Await MODE MODIFY ACK (new mode)" and "Await MODE MODIFY ACK (old mode)": "Await MODE MODIFY ACK (new mode)" is the BSC state when waiting for the MODE MODIFY ACK/NACK message from BTS after having sent the MODE MODIFY message to BTS. "Await MODE MODIFY ACK (old mode)" is the BSC state when waiting for the MODE MODIFY ACK/NACK message from BTS after having sent the MODE MODIFY (old mode) message to BTS. The reason for duplication is due to absence of Channel Type IE in the MODE MODIFY ACK/NACK message, that requires a state differentiation to keep track of the old mode that the MODE MODIFY message previously sent to the BTS may refer to (in case of reversion to the old channel mode). "Await CHANNEL MODE MODIFY ACK": It is the BSC state waiting for CHANNEL MODE MODIFY ACKNOWLEDGE from MS.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
22/52
ASSIGNMENT REQUEST (Note 1)
MODE MODIFY ACK (Note 4) call active CHANNEL MODE MODIFY ACK (Note 2) await mode modify ack (old mode) CHANNEL MODE MODIFY ACK (Note 3)
await mode modify ack (new mode) MODE MODIFY ACK
Figure 6: State transitions for Channel Modification. Note 1: See section 3.2.1.1: 1. If the checks specified in section 3.2.1.1 are not successful, the BSC sends ASSIGNMENT FAILURE to MSC and the Channel modification procedure will not be performed (action ASS-FAIL in section 3.2.1.1); 2. In certain cases, for example the requested channel mode is the same as the current one, the BSC sends ASSIGNMENT COMPLETE to MSC and the Channel modification procedure will not be performed (action ASS-COMP in section 3.2.1.1); Note 2: CHANNEL MODE MODIFY ACKNOWLEDGE (new mode).
Note 3: CHANNEL MODE MODIFY ACKNOWLEDGE (old mode) / CHANNEL MODE MODIFY ACKNOWLEDGE (see Figure 4b and Figure 4c). Note 4: See Table 3-4
ASSIGNMENT REQUEST
MODE MODIFY NACK
T9103 expiry
T9112 expiry ack
MODE MODIFY NACK
await channel mode modify T9103 expiry
call/channel release
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
23/52
BSC state transition table for Channel Modification during Call Active state STATE EVENT ASSIGNMENT REQUEST (error of message analysis - see Note 1 of Figure 6 and action ASSFAIL of section 3.2.1.1) ASSIGNMENT REQUEST (see Note 1 of Figure 6 and action ASS-COMP of section 3.2.1.1) ASSIGNMENT REQUEST (see action MODE-MODIFY of section 3.2.1.1) CLEAR COMMAND Call Active Send ASSIGNMENT FAILURE to MSC Next state Call Active
Send ASSIGNMENT COMPLETE to MSC Next state Call Active Send MODE MODIFY message Start T9103 Next state Await Mode Modify ACK (new mode) N0600 - see ref.[12] Table 3-1: State Call Active
BSC state transition table for Channel Modification during Await Mode Modify ACK (new mode) state STATE Await Mode Modify ACK (new mode) EVENT MODE MODIFY ACK is received Stop T9103 Send the CHANNEL MODE MODIFY message (new mode) Start T9112 Next state Await Channel Mode Modify ACK Send the ASSIGNMENT FAILURE message to MSC Next state Call Active Send the ASSIGNMENT FAILURE message to MSC Start T9110 Next state Call/Channel Release N0600 - see ref.[12] Table 3-2: State Await Mode Modify ACK (new mode)
MODE MODIFY NACK is received
T9103 expiry
CLEAR COMMAND
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
24/52
BSC state transition table for Channel Modification during Await Channel Mode Modify ACK state STATE Await CHANNEL MODE MODIFY ACK EVENT CHANNEL MODE MODIFY ACK Stop T9112 (see Note 2 of Figure 6) Send ASSIGNMENT COMPLETE to MSC Next state Call Active Stop T9112 Send MODE MODIFY (old mode) to BTS Start T9103 Next state Await Mode Modify ACK (old mode) Send MODE MODIFY (old mode) to BTS Start T9103 Next state Await Mode Modify ACK (old mode) N0600 - see ref.[12] Table 3-3: State Await CHANNEL MODE MOIFY ACK BSC state transition table for Channel Modification during Await Mode Modify ACK (old mode) state STATE EVENT MODE MODIFY ACK Await Mode Modify ACK (old mode) IF the CHANNEL MODE MODIFY (new mode) message has been sent, and IF the MS replies withCHANNEL MODE MODIFY ACK (old mode) (see Figure 4b) then Stop T9103 Send ASSIGNMENT FAILURE to MSC Next state Call Active ELSE Stop T9103 Send CHANNEL MODE MODIFY (old mode) Send ASSIGNMENT FAILURE to MSC Next state Call Active ENDIF ENDIF Stop T9103 Send ASSIGNMENT FAILURE to MSC Start T9110 Next state Call/Channel Release Send ASSIGNMENT FAILURE to MSC Start T9110 Next state Call/Channel Release N0600 - see ref.[12] Table 3-4: State Await Mode Modify ACK (old mode)
CHANNEL MODE MODIFY ACK (see Note 3 of Figure 6)
T9112 expiry
CLEAR COMMAND
MODE MODIFY NACK
T9103 expiry
CLEAR COMMAND
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
25/52
BSC state transition table for Channel Modification during Call/Channel Release state STATE EVENT CLEAR COMMAND Stop T9110 ICM0701 - see ref.[12] Table 3-5: State CALL/CHANNEL RELEASE 3.1.4 Filtering of the CFI message CALL/CHANNEL RELEASE
On reception of a Mode Modify message from the BSC, the BTS starts sending TRAU frames of the new type to the transcoder. At the reception of this TRAU frame, the transcoder becomes transparent in the downlink side. At this point of time, if the IWF is not ready to transmit, then the BTS will receive idle pattern. If the IWF is too long to start sending TRAU frame (more than 1s) then the BTS detects a "Loss of Synchronisation". In order to filter the "false" loss of sync alarm (CONNECTION FAILURE INDICATION message), the timer T_CFI_TR is implemented at the BTS side: the BTS starts timer T_CFI_TR upon receipt of the MODE MODIFY message (Note 1). When T_CFI_TR is running all transcoder alarms are ignored by the BTS. Note 1: The timer T_CFI_TR is used for all type transition.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
26/52
3.2
3.2.1
DETAILED BEHAVIOUR WITHIN BSS ENTITIES

BSC BSC analysis of ASSIGNMENT REQUEST message
3.2.1.1
3.2.1.1.1
General
When receiving the ASSIGNMENT REQUEST message from MSC, the BSC performs the following checking: 1. Special checking on Channel Type MIE (section 3.2.1.1.4). 2. General checkings (section 3.2.1.1.2) + specific checking on the CIC (section 3.2.1.1.3). According to the results of checking the action to be taken can be one of the following (see also table 3-1 of section 3.1.3): 1 ASS-COMP: BSC answers the ASSIGNMENT REQUEST with ASSIGNMENT COMPLETE and the Channel Modification will not be performed. 2 ASS-FAIL: BSC answers the ASSIGNMENT REQUEST with ASSIGNMENT FAILURE (the cause values are defined in section 3.1.2.1) and the Channel Modification will not be performed. 3 MODE-MODIFY: The BSC sends MODE MODIFY message to BTS and starts the Channel Modification procedure (see figure 6). Figure 7 describes the ASSIGNMENT REQUEST message analysis.
ASSIGNMENT REQUEST
checking Channel Type (section 3.2.1.1.4) No successful ? YES
General checking (section 3.2.1.1.2) + specific checking on CIC (section 3.2.1.1.3) No successful ? YES
ASS-FAIL
MODE-MODIFY or ASS-COMP
(Note 1 Figure 6)
Figure 7: Checking ASSIGNMENT REQUEST message
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
27/52
3.2.1.1.2
General checking
The general description of the BSC analysis of the ASSIGNMENT REQUEST message is given in ref.[11]. Concerning Channel Type IE and Circuit Identity Code IE, the BSC must perform specific checks not described in [11]. Analyzing the Channel Type IE the BSC can recognize the channel modification case and perform specific checks. Specific checks in the channel modification case are also performed on the Circuit Identity Code IE. All these checks are described in the following sections. Notes: 1. the ASSIGNMENT REQUEST is always checked using the GSM phase 2+ coding specified for EFR, see ref.[3]. 2. the BSC stores the latest information received from the MSC, in case of further internal channel change: - the channel type, including the permitted speech version is memorised, see ref.[11]. - the priority level and pre-emption capabilities (pci and pvi bits from the OIE Priority) when EN_TCH_PREEMPT is enabled, see ref.[11]. - for classmark 2, see ref.[18]. If the checking is not successful, action ASS-FAIL; If the checking is successful, goes on with the algorithm. 3.2.1.1.3 Specific checking on the CIC
The CIC in the ASSIGNMENT REQUEST message from the MSC has to be the old one. If the CIC is not included, the old one has to be taken. If the CIC is different from the one presently in use for the connection, the BSC sends the message ASSIGNMENT FAILURE with cause value as specified in ref.[12], see below.
Cause value in ASSIGNMENT FAILURE is defined in section 3.1.2.1 "Assignment Failure (in BSC)". 3.2.1.1.4 Specific checking on the Channel type MIE
The BSC receives the ASSIGNMENT REQUEST message from the MSC. From the fact that the request is related to an already assigned TCH, the BSC shall compare the current Channel Type IE with the new requested one.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
28/52
REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST Channel rate and type HR TCH channel Lm See Note 1 Speech/Data indicator Speech Data Speech Data rate Speech Full rate ASS-FAIL ICM0100 ASS-FAIL ICM0200 see table 3-7 MODE-MODIFY MODE-MODIFY
CURRENT CHANNEL MODE (see Note 2) Speech HR (note 9) see table 3-7 ASS-FAIL ICM0200 see table 3-7 ASS-FAIL ICM0200 ASS-FAIL ICM0200 ASS-FAIL ICM0200 ASS-FAIL ICM0200 ASS-FAIL ICM0200 ASS-FAIL ICM0200 ASS-FAIL ICM0200 Data 12 NT full rate ASS-FAIL ICM0100 ASS-FAIL ICM0100 see table 3-8 ASS-COMP ASS-COMP Data 9.6 transparent full rate ASS-FAIL ICM0100 ASS-FAIL ICM0100 see table 3-8 Data 4.8 transparent full rate ASS-FAIL ICM0100 ASS-FAIL ICM0100 see table 3-8 Data 2.4 transparent full rate ASS-FAIL ICM0100 ASS-FAIL ICM0100 see table 3-8
N/A any rate N/A
12 kbit/s Data non transparent FR or HR TCH channel (see Note 3) 6 kbit/s HR 12 kbit/s FR see Note 6 6 kbit/s
MODE-MODIFY MODE-MODIFY MODE-MODIFY note 4 note 4 note 4 MODE-MODIFY MODE-MODIFY MODE-MODIFY note 4 note 4 note 4 ASS-FAIL ICM0200 ASS-FAIL ICM0200 ASS-FAIL ICM0200
ASS-FAIL ICM0200 MODE-MODIFY MODE-MODIFY ASS-FAIL ICM0200 MODE-MODIFY
ASS-FAIL ICM0200
9.6 kbit/s Data transparent 4.8 kbit/s 1.2/ 0.075 kbit/s else see Note 8
MODE-MODIFY ASS-COMP MODE-MODIFY MODE-MODIFY note 4 MODE-MODIFY MODE-MODIFY ASS-COMP MODE-MODIFY note 4 ASS-FAIL ASS-FAIL ASS-FAIL ASS-FAIL ICM0200 ICM0200 ICM0200 ICM0200 MODE-MODIFY MODE-MODIFY MODE-MODIFY ASS-COMP note 4
Table 3-6a: Special checking on the Channel Type MIE (1/2)
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
29/52
REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST Channel rate and type Speech/Data indicator Speech Data rate Speech Full rate see table 3-7 MODEMODIFY MODEMODIFY ASS-FAIL ICM0200 MODEMODIFY MODEMODIFY ASS-FAIL ICM0200 MODEMODIFY
CURRENT CHANNEL MODE (see Note 2) Speech HR (note 9) ASS-FAIL ICM0100 ASS-FAIL ICM0100 ASS-FAIL ICM0100 ASS-FAIL ICM0100 ASS-FAIL ICM0100 ASS-FAIL ICM0100 ASS-FAIL ICM0100 ASS-FAIL ICM0100 Data 12 NT full rate see table 3-8 ASS-COMP Data 9.6 transparent full rate see table 3-8 MODEMODIFY note 4 MODEMODIFY note 4 ASS-FAIL ICM0200 ASS-COMP Data 4.8 transparent full rate see table 3-8 MODEMODIFY note 4 MODEMODIFY note 4 ASS-FAIL ICM0200 MODEMODIFY ASS-COMP Data 2.4 transparent full rate see table 3-8 MODEMODIFY note 4 MODEMODIFY note 4 ASS-FAIL ICM0200 MODEMODIFY MODEMODIFY ASS-FAIL ICM0200 ASS-COMP
N/A
12 kbit/s
Data non transparent FR TCH channel Bm
6 kbit/s HR 12 kbit/s FR see Note 6 6 kbit/s
ASS-COMP
ASS-FAIL ICM0200 MODEMODIFY note 4 MODEMODIFY note 4 ASS-FAIL ICM0200 MODEMODIFY note 4
9.6 kbit/s
Data transparent
4.8 kbit/s
MODEMODIFY ASS-FAIL ICM0200 MODEMODIFY
1.2/ 0.075 kbit/s else see Note 8
ASS-FAIL ICM0200 MODEMODIFY
Table 3-6b: Special checking on the Channel Type MIE (2/2)
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
30/52
REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST is Speech
CURRENT CHANNEL MODE is Speech If none of the requested speech version(s) correspond to the current speech version: ASS-FAIL ICM0100 Otherwise the BSC selects the current speech version: ASS-COMP
Table 3-7: checking of speech version for channel modification from speech to speech
REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST is Speech
CURRENT CHANNEL MODE is Data If none of the requested speech version(s) is compatible with the BTS capacity (check of EFR_ENABLED for full rate speech version 2, EN_AMR_FR for full rate speech version 3, EN_AMR_WB_GMSK for full rate speech version 5): ASS-FAIL ICM0205 Otherwise the BSC selects from the most preferred speech versions allowed by the MSC (taken in descending order), the one which is supported by the BTS: - EFR_ENABLED must be checked before selecting full rate speech version 2 (EFR). - EN_AMR_FR must be checked before selecting full rate speech version 3 (NarrowBand AMR). - EN_AMR_WB_GMSK must be checked before selecting full rate speech version 5 (AMR_WB). AMR-WB is preferred to NarrowBand AMR, which is preferred to EFR, which is preferred to FR. Note that HR_ENABLED need not be checked, as HR is not supported for alternate services. MODE-MODIFY
Table 3-8: selection of speech version for channel modification from data to speech (alternate services)
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
31/52
Note 1:
The channel rate is not changed during channel modification: Channel rate modification is only allowed for "followed by" services (see section 2.1), from full rate speech to half rate data. But half rate data is not supported. Half rate data is not supported. Half rate speech is only supported if HR_ENABLED flag is TRUE. "Full or Half rate TCH channel" corresponds to the combination of channel type defined in 3GPP TS 48.008. There are different possible combinations for speech and data, see ref.[3]. In this case, the MSC connected to the BSC uses the GSM phase 2/2+ format of the ASSIGNMENT REQUEST message (see ref.[16]). The BSC decisions are the same for all possible channel types. Transition between transparent and non-transparent service should not be requested by MSC. The transparent or non transparent service is part of the Quality of service attributes negotiated between the end users during Set-up. For the time being, GSM does not offer a dual service with such capability. The MSC has the task and the responsibility to determine whether it makes sense to request an assignment request with speech followed by speech. Therefore the BSC should perform, as far as possible, the requests coming from the MSC. This case corresponds to the codepoint "000000" of the channel rate for non-transparent service. If this codepoint is received, the BSC should allocate a 12 kbit/s channel if the channel is a full rate TCH or 6 kbit/s channel if the channel is a half rate TCH (see ref.[3]). The BSS shall allocate a 12 kbit/s channel because half rate channels are not supported for data. The BSS internal behaviour (i.e. specific BTS and BSC behaviours) is detailed in ref.[11]. This case covers the user rates: 2.4 kbit/s, 1.2 kbit/s, 600 bit/s. These rates are all mapped to 2.4 kbit/s user rate on the Radio interface. Half rate speech is only supported if the HR_ENABLED flag, on-line changeable, is set to TRUE. But this flag is not checked during channel modification: if a channel has been assigned for speech half rate, another ASSIGNMENT REQUEST indicating half rate speech must be accepted by the BSC, even if the HR_ENABLED flag becomes FALSE after the first assignment.
Note 2: Note 3:
Note 4:
Note 5:
Note 6:
Note 7: Note 8:
Note 9:
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
32/52
3.2.1.2
BSC construction of ASSIGNMENT COMPLETE
The BSC sends to the MSC the ASSIGNMENT COMPLETE message once the requested assignment has been completed correctly. The construction of the ASSIGNMENT COMPLETE message is as follows: IE MIE Message Type OIE RR Cause OIE Cell identifier OIE Chosen Channel Algorithm or coding Equal to ASSIGNMENT COMPLETE, see ref.[3]. not used. not used. If GSM_PHASE = phase 1 : Not sent. If GSM_PHASE = phase 2 : This IE is always included. Equal to the TCH rate used in the old or new mode. If GSM_PHASE = phase 1 : Not sent. If GSM_PHASE = phase 2 : The BSS only includes this OIE if the MSC has given the choice to the BSC (i.e., more than one bit is set in the bitmap of the encryption information of CIPHER MODE COMMAND or HANDOVER REQUEST messages). Equal to the encryption algorithm used in the old or new mode (change of encryption algorithm is not performed upon the receipt of ASSIGNMENT REQUEST message). Sent if OIE CIC was present in the corresponding ASSIGNMENT REQUEST message. If the TC board mapped to the CIC supports AMR WB GMSK: sent with value circuit pool number 39, otherwise it is sent with value circuit pool number 27.Not used in the channel modification case. Used in other cases: see the relative specifications. Included if the MSC has left the choice to the BSS between several speech versions in the ASSIGNMENT REQUEST.
OIE Chosen Encryption Algorithm
OIE Circuit pool
OIE Speech Version (chosen)
Table 3-9: BSC construction of ASSIGNMENT COMPLETE message
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
33/52
3.2.1.3
BSC construction of ASSIGNMENT FAILURE
The BSC sends the ASSIGNMENT FAILURE message to the MSC when there has been a failure in the assignment process at the BSS and that the assignment procedure has been aborted. The construction of the ASSIGNMENT FAILURE message is as follows: IE MIE Message Type MIE Cause OIE RR Cause OIE Circuit Pool Algorithm or coding Equal to ASSIGNMENT FAILURE, see ref.[3]. See previous sections and ref.[12]. Not used Sent if OIE CIC was present in the corresponding ASSIGNMENT REQUEST message and a pool number has been identified, whatever the failure cause. If the TC board mapped to the CIC supports AMR WB GMSK: sent with value circuit pool number 39, otherwise it is sent with value circuit pool number 27.Not used in the channel modification case. Used in other cases: see the relative specifications. Not used in the channel modification case. Used in other cases: see the relative specifications.
OIE Circuit Pool List
Table 3-10: BSC construction of ASSIGNMENT FAILURE message
3.2.1.4
BSC construction of MODE MODIFY
The BSC sends the MODE MODIFY message to the BTS when the channel mode of an active channel must be changed. The construction of the MODE MODIFY message is as follows: IE MIE Message Discriminator MIE Message type MIE Channel Number Algorithm or coding See ref.[4]. Equal to MODE MODIFY. TN corresponds to the TCH channel concerned by the channel modification procedure. C5, C4, C3, C2 & C1 must be coded as 00001 ("Bm + ACCH's"). Channel modification is only supported for TCH full rate. Octet 3 bit 2 (DTXd) : In case of data to speech modification, and if FORBID_DTXD_NH_BCCH_F is set to TRUE and the allocated TCH is non-hopping and belongs to the BCCH TRX, then DTXd shall be set to 0 (i.e. DTXd is not applied), Otherwise see ref.[15]. Octet 3 bit 1 (DTXu): see ref.[15]. Octet 4 is coded as octet 3 of the Channel type MIE in the ASSIGNMENT REQUEST message. Octet 5 is the 'channel rate and type' used in the old mode: equal to the 'channel rate and type' previously sent in CHANNEL ACTIVATION message (see ref.[11]). Octet 6 - For speech indicates the chosen speech version. - For data is coded as octet 5 of the Channel type MIE in the ASSIGNMENT REQUEST (see section 3.2.1.1.4).
MIE Channel Mode
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
34/52
OIE Main Channel Reference OIE Encryption Information OIE Multirate Configuration
Not used Not used. Included only for modification from data to (NarrowBand or WideBand) AMR speech. Contains the initial codec mode, the codec subset and, if more than one codec is defined, thresholds and hysteresis used by the BTS for the uplink codec adaptation. It contains also the indication to allow or forbid use of AMR Noise Suppressor. See ref.[14]. Alcatel proprietary IE. Included in case of data to speech channel modification, when EN_TFO or EN_TFO_AMR_WB flag = Enabled. Field EN_TFO is either set to TRUE when the active codec type is HR, FR, EFR and EN_TFO flag = enable; AMR and FORCE_TFO_VS_AMR flag = enable (in this case EN_TFO = Enabled also); GMSK AMR-WB and EN_TFO_AMR_WB = Enabled. or set to 0 if the codec list is empty. Field TFO_MATCH is set to EN_TFO_MATCH flag. Field TFO_OPT is set to EN_TFO_OPT flag. Field T_TFO contains the value of the timer T_TFO. Field TFO Codec contains the TFO codec type received in TFO codec list response message from RAM except in case of TFO with AMR WB codec. It is set to 0xFF when EN_TFO field is set to False or in case of TFO with AMR WB. For the coding of this IE see ref.[24]. It is included for speech calls and present only if the field EN_TFO in OIE TFO Command is set to TRUE AND if GC selection flag (received from RAM) = 0 (in particular for legacy backward compatibility) Field Codec List indicates, as received from RAM in TFO codec list response message, a list of codecs : - supported on the cell and - allowed by the operator (via O&M) and - allowed by the MSC (in the ASSIGNMENT REQUEST) Field Preferred Codec is not used (set to 0xFF). It is included for speech calls and present only if the field EN_TFO in OIE TFO Command is set to TRUE AND if GC selection flag (received from RAM) = 1. It contains the local configuration for the TC in case of TFO with AMR-WB. Table 3-11: BSC construction of MODE MODIFY message
OIE TFO Command
OIE Supported Codec Types
OIE TFO Transparent Container
3.2.1.5
BSC analysis of MODE MODIFY ACKNOWLEDGE and MODE MODIFY NEGATIVE ACKNOWLEDGE
The BTS responds with the MODE MODIFY ACKNOWLEDGE message to BSC after having changed to the new mode. The BTS responds with the MODE MODIFY NEGATIVE ACKNOWLEDGE message to BSC to indicate that the channel mode modification could not be performed as requested. In this case, the channel mode value retained by the BTS is equal to the last value received from the BSC that was successfully acknowledged by the BTS via the CHANNEL ACTIVATION ACKNOWLEDGE or MODE MODIFY ACKNOWLEDGE messages. The BSC general behaviour upon receipt of these messages is described in section 3.1.3 of this document and in ref.[16].
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
35/52
3.2.1.6
BSC construction of CHANNEL MODE MODIFY
The BSC sends the CHANNEL MODE MODIFY message to the MS on the main DCCH when a change of the mode for the indicated channel is requested. The construction of the CHANNEL MODE MODIFY message is as follows: IE MIE Protocol Discriminator MIE Skip Indicator MIE Message Type MIE Channel Description MIE Channel Mode OIE VGCS Target Mode Indication OIE Multirate Configuration Algorithm or coding See ref.[4]. Equal to "0000". Equal to CHANNEL MODE MODIFY. Channel Description of the already active channel. See ANNEX 2. Not used Included only for modification from data to AMR (NarrowBand or WideBand) speech. Contains the initial codec mode, the codec subset and, if more than one codec is defined, thresholds and hysteresis used by the BTS for the uplink codec adaptation. It contains also the indication to allow or forbid use of AMR Noise Suppressor. See ref.[14].
Table 3-12: BSC construction of CHANNEL MODE MODIFY message 3.2.1.7 BSC analysis of CHANNEL MODE MODIFY ACKNOWLEDGE
The MS sends the CHANNEL MODE MODIFY ACKNOWLEDGE message to the network to indicate the successful or unsuccessful execution of a channel mode modify request. The analysis of the CHANNEL MODE MODIFY ACKNOWLEDGE message is as follows: - Channel Mode IE: Three cases are possible. * new mode: The MS acknowledges the channel mode sent in the CHANNEL MODE MODIFY message. The BSC shall behave as described in section 3.1.1. * old mode: The BSC shall take this case as a negative acknowledgement of the MS. The BSC shall behave as described in section 3.1.2.3 case b). * others: The Channel mode is missing or it indicates a mode different from the old or the new mode. The BSC shall take this message as an MS error and try to revert to the old channel mode as described in section 3.1.2.3 case c).
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
36/52
3.2.2 3.2.2.1
BTS BTS construction of MODE MODIFY ACKNOWLEDGE
This message is sent by BTS to BSC to confirm the change of channel mode of an active channel as requested by BSC in the ASSIGNMENT REQUEST message. The construction of MODE MODIFY ACKNOWLEDGE message is as follows: IE MIE Message Discriminator MIE Message Type MIE Channel Number Algorithm or coding See ref.[4]. Equal to MODE MODIFY ACKNOWLEDGE It is coded as in the received MODE MODIFY message
Table 3-13: BTS construction of MODE MODIFY ACKNOWLEDGE message
3.2.2.2
BTS construction of MODE MODIFY NEGATIVE ACKNOWLEDGE
This message is sent by BTS to BSC to indicate that the channel mode modification could not be performed as requested by BSC due to protocol error in the MODE MODIFY message. The construction of MODE MODIFY NEGATIVE ACKNOWLEDGE message is as follows: IE MIE Message Discriminator MIE Message Type MIE Channel Number MIE Cause Algorithm or coding See ref.[4]. Equal to MODE MODIFY NEGATIVE ACKNOWLEDGE It is coded as in the received MODE MODIFY message E bit = 0 Class field = 010 (Resource unavailable), Cause field set to 0001 (radio resource not available), or Class field = 011 (service or option not available), Cause field set to 0000 (requested transcoding/rate not available). Class field = 100 (service or option not implemented), Cause field set to 1111 (service or option not implemented, unspecified) Class field = 110 (protocol error), Cause field set to the most appropriate value from 0000 to 1111. Diagnostic: not used.
Table 3-14: BTS construction of MODE MODIFY NEGATIVE ACKNOWLEDGE message 3.2.2.3 BTS handling of OIE TFO Command
The IE TFO Command is present only in case of channel mode modification from data to speech when TFO is enabled at OMC-R in the cell. In this case, the info is forwarded to the TRAU. If for a speech call, this IE is not received, the BTS shall however send TFO default information to the TRAU to explicitly disable TFO does not send any TFO information to the TRAU (see ref.[25]).
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
37/52
If IE TFO Command is present but both IE Supported Codec Types and IE TFO Transparent Container are absent, TFO is disabled for the call. If both IE Supported Codec Types and IE TFO Transparent Container are included, TFO is disabled for the call. 3.2.3 Data rates
Three types of data rates are defined by the 3GPP for the rate adaptation. For further details, see ref.[5], [9], [10] and [13]. User bit rate: Information data rate at the end user sides. The following rates are defined: 9600 bit/s, 4800 bit/s, 2400 bit/s, 1200 bit/s, 600 bit/s, 300 bit/s, 75 bit/s, MS to network direction only. Intermediate data rate: Actual information data rate between the BTS and the TRAU; and between the TRAU and the MSC. Information is supported by V110 80 bit frames. Two rates are defined: 16 kbit/s, 8 kbit/s. These are the two rates known by the TRAU. The transcoder performs the rate adaptation at 8 or 16 kbit/s according to the control information it receives in the uplink TRAU frames from the BTS (in-band signalling). Radio interface rate: Actual information data rate (i.e. before channel encoding) on the Radio interface. Four rates are defined: 12 kbit/s, 6 kbit/s, 3.6 kbit/s. These are the four data rates known by the BTS layer 1 entities (channel encoder and channel decoder. The table 3-22 gives the correspondence between these three types of data rates. User data rate bit/s 600* 1200 2400 4800 9600 Intermediate data rate kbit/s 8 8 8 8 16 Radio interface rate kbit/s 3.6 3.6 3.6 6 12
Table 3-15: Correspondence table of GSM data rates. Note: The 300 bit/s user data rate is adapted to a synchronous 600 bit/s at the IWF side see RA0 function in ref.[9].
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
38/52
3.2.4
MS behaviour
See section 3.1 of this document and: - RR layer, channel mode modify procedure: 3GPP TS 44.018 - CC layer, in-call modification: 3GPP TS 24.008 3.2.5 MSC behaviour
When the MSC detects a need for channel modification, it sends an ASSIGNMENT REQUEST message to the BSS and starts timer Trr1. At this point in time, the MSC shall suspend transmission of all signalling layer messages except CLEAR COMMAND for the concerned channel. When the MSC receives an ASSIGNMENT COMPLETE message it shall stop Trr1 and send to MS a MODIFY COMPLETE message. When the MSC receives an ASSIGNMENT FAILURE with the cause "radio interface failure - reversion to old channel", "protocol error between BSC and MSC" or "requested transcoding/rate adaptation unavailable" it shall reset timer Trr1 ; resume transmission of all signalling layer messages and send a MODIFY REJECT message to the MS. When the MSC receives a ASSIGNMENT FAILURE message with the cause "radio interface message failure " it shall stop Trr1 , send a CLEAR COMMAND message to BSC and release the call.
3.3
3.3.1
INTERACTION WITH OTHER PROCEDURES

Handover
During the channel modification procedure the BSC will discard any handover alarm which may trigger either internal or external handover until the channel modification procedure is completed. BSC never sends HANDOVER REQUIRED messages to MSC during channel modification procedure. During channel modification procedure any HANDOVER COMMAND message from MSC will be answered by BSC with HANDOVER FAILURE message (cause value: radio interface failure, reversion to old channel). When the internal handover is started the BSC waits until the handover is finished, before it starts the channel modification procedure. During external handover, on the old BSC, (after the BSC has received from the MSC the HANDOVER COMMAND message), the BSC discards a channel modification request. The MSC has to wait for the completion of the handover (reception of HANDOVER COMPLETE or HANDOVER FAILURE message) before it can send the ASSIGNMENT REQUEST for the channel modification procedure. In the target BSC the channel modification request is discarded in all cases until the handover is completed. 3.3.2 Short message service
The initiation of a SAPI 3 connection from the MSC is delayed by the BSC, until the channel modification is completed. If a SAPI 3 connection is not yet initiated, the first SAPI 3 messages received from the MSC (up to 5) are buffered until completion of the channel modification procedure. If a SAPI 3 connection is already initiated at the start of the channel modification procedure, SAPI 3 messages received by the BSC from MSC are forwarded to the MS as soon as the connection is established. If a SAPI 3 connection is already established at the start of the channel modification procedure, SAPI 3 messages received by the BSC from MSC are forwarded to the MS during the channel modification procedure In either case, SAPI 3 messages received from the MS will be forwarded to the MSC.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
39/52
3.3.3
Interaction with DTAP SAPI 0
While the channel modification procedure is running, no DTAP messages are buffered by the BSS, they are transmitted to the MS. 3.3.4 Interaction with Call Release
A channel modification request received during a BSC or MSC initiated call release shall be discarded. This because channel modification is, by definition, allowable and valid only in the call active state. 3.3.5 Interaction with Ciphering procedure
During channel modification procedure MSC shall never activate ciphering; any CIPHER MODE COMMAND message is discarded by BSC. 3.3.6 Interaction with directed retry
The Alcatel BSS shall be able to trigger the channel mode modify procedure on the radio interface when a full rate traffic channel is allocated for speech version 1 to a phase 1 MS. Two cases are to be distinguished: - just after the completion of the directed retry procedure, as specified in ref.[17] & [19], - just after completion of an incoming external handover procedure, as specified in ref.[19]. In both cases, the CHANNEL MODE MODIFY message is sent without waiting any response from the MS (the CHANNEL MODE MODIFY ACKNOWLEDGE message is discarded).
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
40/52
INTERFACE DESCRIPTIONS
4.1
4.1.1
GSM INTERFACES/PHYSICAL INTERFACES

Radio interface
CHANNEL MODE MODIFY CHANNEL MODE MODIFY ACKNOWLEDGE 4.1.2 A interface
ASSIGNMENT REQUEST ASSIGNMENT COMPLETE ASSIGNMENT FAILURE 4.1.3 Abis interface
MODE MODIFY MODE MODIFY ACKNOWLEDGE MODE MODIFY NEGATIVE ACKNOWLEDGE
4.2
4.2.1
INTERNAL INTERFACES
In-band signalling
An in-band signalling link exists between the BTS and the transcoder. The transcoder gets the information data/speech and 16/8 kbit/s RA intermediate rate via the control bits of the TRAU frames (see ref.[13]).
4.2.2
Interface with RAM
The Figure 8 shows Internal interface between Channel Modification (CMOD) and RAM. When TFO is enabled, in the case of channel modification from data to speech (not for NarrowBand AMR cases if FORCE_TFO_VS_AMR is not enabled), the Channel Modification entity requests to RAM the list of supported codec types.
BSC
" T F O c o d e c l is t r e q u e s t "
CMOD
" T F O c o d e c l is t r e s p o n s e "
RAM
Figure 8: Internal interface between Channel Modification and RAM ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
41/52
CMOD: This entity is responsible of Channel Modification. The CMOD behaviour is described in this document. RAM: Resource Allocation and Management This entity is responsible of radio resource allocation and management. The RAM behaviour is described in ref.[20]. Messages description Message TFO codec list request Parameter or information Only requested when EN_TFO or EN_TFO_AMR_WB =TRUE in case of data -> speech modification (except if FORCE_TFO_VS_AMR = FALSE and active codec type is NarrowBand AMR FR or AMR HR). - current channel rate - current speech version - TCH channel request type - list of speech versions - TFO codec type - List of supported codec types - GC selection flag
4.2.3
Direction CMOD -> RAM
RAM -> CMOD
TFO codec list response
4.3
EXTERNAL INTERFACES
A second (not BSS relevant) in-band signalling link between the Fax machine on the other end and the MSC IWF exists. The Fax group 3 equipment (sending in transparent mode) has the possibility to request a transmission speed change via in-band signalling. The IWF in the MSC decodes this request and initiates an appropriate assignment procedure.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
42/52
4.4
PARAMETERS LIST
CGI_REQD When set to TRUE, the BSC uses the Cell Global Identifier to encode the cell identifier. EFR_ENABLED This flag enables the support of enhanced full rate (speech version 2). EN_AMR_FR This flag enables the support of (NarrowBand) AMR speech codec (speech version 3) on Full Rate Channels. EN_AMR_WB_GMSK This flag enables the support of AMR-WB GMSK in the cell. EN_TCH_PREEMPT When set to true, the pre-emption procedure may be used to satisfy new incoming calls in congested cell. EN_TFO When set to true, the basic functions of TFO are possible in the cell for GSM FR, EFR and HR codecs. EN_TFO_AMR_WB When set to true, the basic functions of TFO are possible in the cell for GMSK AMR-WB codecs. EN_TFO_MATCH When set to true, the codec mismatch resolution procedure is possible in the cell. This flag is relevant only if EN_TFO is set to true. EN_TFO_OPT When set to true, the codec optimisation procedure is possible in the cell. This flag is relevant only if EN_TFO and EN_TFO_MATCH are both set to true. FORBID_AMR_NS O&M flag to forbid / allow (NarrowBand or WideBand) AMR noise suppressor in the MS. FORBID_DTXD_NH_BCCH_F When set to true, it forbids the use of downlink DTX on the non-hopping TCH of the BCCH TRX. FORCE_TFO_VS_AMR When set to true, it forces TFO negotiation while (NarrowBand) AMR is used. This flag is relevant only if EN_TFO and (EN_AMR_FR and/or EN_AMR_HR) are set to true. GSM_PHASE This flag indicates if the A interface messages sent by the BSC to the MSC shall be compliant to GSM phase 1 or GSM phase 2 / 2+. HR_ENABLED This flag enables the support of half rate speech.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
43/52
4.5
TIMERS LIST
Timer T323 Location MS Started after sending the MODIFY message Function, Actions at expiry: Supervision of total time of the channel mode modification. On timer expiry, GSM recommends initiation of a call clearing (Cause: #102 recovery on time expiry) Supervision of the modification in the BTS. In case of a T9103 expiry the BSC reports this to the MSC with the ASSIGNMENT FAILURE message (Cause: see ref.[12]).
T9103
BSC
after sending the MODE MODIFY message
Trr1
T9112
T9110
T_CFI_Tr
T_RCR_A CK T_TFO
Supervision of ASSIGNMENT COMPLETE. On timer expiry the MSC sends a the MODIFY REJECT message to the MS. BSC Supervision of the channel modification in the MS. In case of timer expiry the BSC reports this to the MSC with the ASSIGNMENT FAILURE message (Cause: see ref.[12]) BSC after sending the Supervision of the MSC CLEAR COMMAND ASSIGNMENT answer. FAILURE with cause In case of T9110 expiry, the BSC releases the value: radio interface SCCP connection (Cause ICM0700, see ref.[12]) message failure BTS after receiving the Transcoder alarm filter timer Mode Modify message BSC after sending the Supervision of the channel release. RF CHANNEL RELEASE message BTS & TC after sending the Supervision of TFO protocol between the BTS CON_REQ message and the TC. Its value is provided by the BSC to the BTS in CHANNEL ACTIVATION and MODE MODIFY messages.
MSC
after sending the ASSIGNMENT REQUEST message after sending the CHANNEL MODE MODIFY message
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
44/52
RELEASES CHANGES
Release B10: Introduction of WideBand Adaptive Multi-Rate speech codec (AMR-WB) with GMSK modulation. Introduction of TFO with AMR-WB GMSK speech codec.
Release B7: Introduction of Adaptative Multi-Rate speech codec (AMR). Introduction of Tandem Free Operation (TFO): new IEs in MODE MODIFY, new flags EN_TFO, EN_TFO_MATCH, EN_TFO_OPT, FORCE_TFO_VS_AMR. Removal of DTX downlink modification triggered by the MSC. New O&M flag FORBID_DTXD_NH_BCCH_F is introduced to disable downlink DTX for non-hopping TCH on BCCH TRX. Introduction of eMLPP: priority level and pre-emption capabilities, contained in Priority OIE, to be stored in the call context; new O&M flag EN_TCH_PREEMPT.
Release B6: Support of DATA Transmission at 14.4 kbit/s.
Release B5: Support of EFR. Support of GSM ETR 09.94 for external handover.
Release B4: Introduction of TCH half rate for speech. Support of GSM ETR 09.94 for internal directed retry.
Release B3: Introduction of GSM phase 2. FD/3/6.2.4: In-call modification, phase 2.
Release B2: The in-call modification and channel mode modification procedures are new functions for Alcatel release B2.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
45/52
FEATURES
Release B7: 3.1.1 Adaptative Multi-Rate speech codec (AMR) 3.2.1 Tandem Free Operation (TFO) RFD 67214 Forbid downlink DTX for TCH on the BCCH TRX without hopping. RFD 85134 eMLPP feature Release B6: 15.6 Data transmission at 14.4 kbits/s Release B5: 6.7.a A interface compliance. 6.8.a Radio interface compliance. 11.25 Support of EFR. Release B4: FD/4/10.1.c: Minimum support of half rate. Release B3: FD/3/6.2.4: In-call modification, GSM phase 2. A GSM phase 2 MS shall reply with a negative acknowledgement to a channel mode modify request if it can not support the change for any reason by sending the message CHANNEL MODE MODIFY ACKNOWLEDGE with the old mode included. A GSM phase 1 MS may have as well the above described behaviour. Release B2: B1008 Automatic facsimile group 3 (transparent), B1009 Alternate speech / Fax group 3 transparent, B1010 Alternate speech / Fax group 3 non transparent, B1021 Dual service transition (in-call modification), B1022 Speech followed by data (B81), B1023 Alternate speech / data (B61), B2317 0808 Assignment: new channel mode, B2373 0858 Channel mode modify, B2415 0408 RR Transmission mode modify.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
46/52
GLOSSARY
3 Generation Partnership Project Air Interface User Rate Adaptative Multi-Rate speech codec Adaptive Multi-Rate WideBand speech codec Base Transceiver Station Base Station Controller Bearer Service xx Call Control Circuit Identity Code Channel Mode Modification = mode modify procedure (Abis interface) + channel mode modify procedure (Radio interface) Discontinuous Transmission Enhanced Full Rate Enhanced Multi-Level Precedence and Pre-emption Global System for Mobile Communications In-Call Modification Information Element Integrated Services Digital Network InterWorking Function Mandatory Information Element Man Machine Interface Mobile Station Mobile Switching Center Not Applicable Optional Information Element Public Land Mobile Network Public Switched Telephone Network Rate Adaptation Resource Allocation and Management Radio Resource Traffic CHannel Tandem Free Operation Technical Specification TeleService xx Transcoder Rate Adaptation Unit
rd
3GPP AIUR AMR AMR-WB BTS BSC BSxx CC CIC CMM DTX EFR eMLPP GSM ICM IE ISDN IWF MIE MMI MS MSC N/A OIE PLMN PSTN RA RAM RR TCH TFO TS TSxx TRAU
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
47/52
ANNEX 1
SUCCESSFUL CHANNEL MODIFICATION
This section contains the successful cases of a channel modification. Only Radio, Abis and A interface messages are used in the message sequence charts within this Annex.
A1.1 MS ORIGINATED IN-CALL MODIFICATION A1.1.1 Alternate & followed by service

The following message sequence chart shows the scenario of a successful in-call modification procedure originated by a MS and involving one TCH. The services covered by the scenario are: 1. BS61: Alternate Speech/Data; 2. BS81: Speech followed by Data. MS BTS BSC MSC
(1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (6) (7) (7) (7) (8) (8)
MODIFY ---------------------------------------------------------------------------> ASSIGNMENT REQUEST <------------------------- start Trr1 MODE MODIFY <------------------------- start T9103 MODE MODIFY ACKNOWLEDGE -------------------------> CHANNEL MODE MODIFY stop T9103 <-------------------------------------------------start T9112 CHANNEL MODE MODIFY ACKNOWLEDGE --------------------------------------------------> stop T9112 ASSIGNMENT COMPLETE -------------------------> MODIFY COMPLETE Stop Trr1 <-----------------------------------------------------------------------------Figure A-1: MS originated in-call modification procedure Alternate & followed by service
3-7 8
The MS, which has an active call, initiates the in-call modification procedure by sending the MODIFY message to the MSC. The MODIFY message includes the new mode to change to. The new mode given in the MODIFY message shall be one of those already negotiated during the establishment phase of the call. At this point in time, the MS starts the timer T323; stops sending Bm-channel information; and stops interpreting received Bm-channel information according to the old call mode. Upon receipt of the MODIFY message, the MSC checks that the requested call mode can be supported. If the checking is successful, the MSC triggers the in-call modification normal assignment procedure by sending the ASSIGNMENT REQUEST message with the new channel mode to the BSS ; starts timer Trr1 to supervise the in-call modification normal assignment procedure. See 1-5 of Figure 1 Upon receipt of the ASSIGNMENT COMPLETE message, the MSC stops timer Trr1 and sends MODIFY COMPLETE message to the MS to indicate completion of the in-call modification
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
48/52
procedure. Upon receipt of the MODIFY COMPLETE message, the MS initiates the alternation to the resources necessary to support the next call mode and stops timer T323. Note 1: The MODIFY message (CC message) is transparent for the BSS and is mentioned in this document only to see how the global in-call modification is executed and is not a subject of this document. Note 2: The channel mode modify procedure uses the old resources and can be performed without any new channel: all the traffic channels can perform data/speech services and at all data rates supported.
A1.1.2
Only changing the data rate per channel
In case of CC in-call modification, it is possible to only change the date rate per channel. The BSS behaviour is different according to the current channel mode and required channel mode (see Table 3-6a and Table 36b): MS BTS BSC MSC
(The active call uses one TCH/F9.6 data) (1) (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (6) (7) (7) (7) (8) (8) MODIFY ---------------------------------------------------------------------------> ASSIGNMENT REQUEST (total radio interface rate, rate per channel, one TCH/F4.8) <------------------------- start Trr1 MODE MODIFY <------------------------- start T9103 MODE MODIFY ACKNOWLEDGE -------------------------> CHANNEL MODE MODIFY stop T9103 <-------------------------------------------------start T9112 CHANNEL MODE MODIFY ACKNOWLEDGE --------------------------------------------------> stop T9112 ASSIGNMENT COMPLETE -------------------------> MODIFY COMPLETE Stop Trr1 <-----------------------------------------------------------------------------(The call uses now one TCH/F4.8 data) Figure A-2: MS originated in-call modification procedure (from one TCH/F9.6 to one TCH/F4.8) 1 The MS, which has an active call (TCH/F9.6 data), initiates the in-call modification procedure by sending the MODIFY message to the MSC. The MODIFY message includes the new mode (TCH/F4.8 data) to change to. The new mode given in the MODIFY message shall be one of those already negotiated during the establishment phase of the call. At this point in time, the MS starts the timer T323; stops sending Bm-channel information; and stops interpreting received Bm-channel information according to the old call mode.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
49/52
Upon receipt of the MODIFY message, the MSC checks that the requested call mode can be supported. If the checking is successful, the MSC triggers the in-call modification normal assignment procedure by sending the ASSIGNMENT REQUEST message with the new channel mode to the BSS; starts timer Trr1 to supervise the in-call modification normal assignment procedure. See 1-5 of Figure 1 Upon receipt of the ASSIGNMENT COMPLETE message, the MSC stops timer Trr1 and sends MODIFY COMPLETE message to the MS to indicate completion of the in-call modification procedure. Upon receipt of the MODIFY COMPLETE message, the MS initiates the alternation to the resources necessary to support the next call mode and stops timer T323.
3-7 8
A1.1.3
Case of crossing
The following section is provided for completion only, and has no impact on the BSS. There is no signalling message defined to transport the MODIFY request to the terminating subscriber, within the PLMN or from the PLMN to PSTN/ISDN. Only in cases of MS to MS calls, where both subscribers are in the same visiting MSC, a MODIFY message can be sent from MSC to terminating MS. However, 3GPP TS 24.008 sees this as a future evolution which is not yet completely defined (e.g. "Crossing of MODIFY messages from network to MS and from MS to network at the same time). A scenario is depicted in 3GPP TS 24.008, section 5.3.4.4, figure 5.10b. If the terminating MS wants to have in-call modification, the subscriber has to initiate that service with the same procedure as the originating MS. These two in-call modifications are not synchronised (see following figure). MS A BSS MSC BSS MS B
MODIFY ------------------------------------------> ASSIGNMENT REQUEST <------------------CHANNEL MODE MODIFY <------------------MODIFY <----------------------------------------CHANNEL MODE MODIFY ACKNOWLEDGE -------------------> ASSIGNMENT REQUEST -----------------> ASSIGNMENT COMPLETE -------------------> CHANNEL MODE MODIFY -------------------> MODIFY COMPLETE CHANNEL MODE MODIFY ACKNOWLEDGE <----------------------------------------<------------------ASSIGNMENT COMPLETE <----------------MODIFY COMPLETE -----------------------------------------> Figure A-3: In-call modification scenario with A and B subscribers
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
50/52
To ease the reading, the message flows between the BSC and BTS are not shown. For details about the message flows, refer to the previous section. Note: There is no "network provided" synchronisation of the two modify procedures (this has to be done by the users).
A1.2 SUCCESSFUL FAX TRANSMISSION SPEED CHANGE (TRANSPARENT MODE)

The following message sequence chart shows the scenario of a successful fax transmission speed reduction(see section 2.1.2). The scenario covers the following cases: 1. Reduction from 9.6 kbits/s on 1 TCH/F9.6 to 7.2 kbits/s on 1 TCH/F9.6; 2. Reduction from 7.2 kbits/s on 1 TCH/F9.6 to 4.8 kbits/s on 1 TCH/F4.8; 3. Reduction from 4.8 kbits/s on 1 TCH/F4.8 to 2.4 kbit/s on 1 TCH/F4.8; Note: the case 1 and case 2 are not supported by the BSS. It is also valid for the fax transmission speed increase cases: 1. Increase from 2.4 kbits/son 1 TCH/F4.8 to 4.8 kbit/s on 1 TCH/F4.8; 2. Increase from 4.8 kbits/s on 1 TCH/F4.8 to 7.2 kbits/s on 1 TCH/F9.6; 3. Increase from 7.2 kbits/s on 1 TCH/F9.6 to 9.6 kbits/s on 1 TCH/F9.6; Note: the case 2 and case 3 are not supported by the BSS. MS (1) (2) (2) (3) (3) (4) (4) (5) (5) (6) (6) (6) (7) (7) (7) (8) BTS BSC MSC
ASSIGNMENT REQUEST <----------------------- start Trr1 MODE MODIFY <----------------------- start T9103 MODE MODIFY ACKNOWLEDGE -----------------------> CHANNEL MODE MODIFY stop T9103 <-------------------------------------------------- start T9112 CHANNEL MODE MODIFY ACKNOWLEDGE --------------------------------------------------> stop T9112 ASSIGNMENT COMPLETE -----------------------> Stop Trr1 Figure A-4: Fax transmission speed reduction scenario
1 2-7 8
A speed reduction request (via inband signalling) is recognised by the IWF (interworking function) in the MSC. The MSC triggers a channel modification normal assignment procedure. See Figure 1. The Fax transmission speed reduction is completed upon receipt of the ASSIGNMENT COMPLETE message at MSC side.
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
51/52
ANNEX 2
MAPPING BETWEEN A ITF CHAN. TYPE IE & RADIO ITF CHAN. MODE
A INTERFACE
RADIO INTERFACE
Channel Type IE value octet 3 speech data data data data data data data data data data data data data data data data data data octet 4 full or half rate TCH full rate TCH full rate TCH full rate TCH half rate TCH full rate TCH half rate TCH full rate TCH full rate TCH full rate TCH half rate TCH full rate TCH half rate TCH full rate TCH half rate TCH full rate TCH half rate TCH full rate TCH half rate TCH octet 5 speech version(s) 14,5 kbit/s NT 12 kbit/s NT 6 kbit/s NT 6 kbit/s NT 12/6 kbit/s NT 12/6 kbit/s NT 14,4 kbit/s T 9.6 kbit/s T 4.8 kbit/s T 4.8 kbit/s T 2.4 kbit/s T 2.4 kbit/s T 1.2 kbit/s T 1.2 kbit/s T 600 bit/s T 600 bit/s T 1200/75 bit/s T 1200/75 bit/s T
Channel Mode IE value
supported?
speech version(x) data 14,5 kbit/s data 12 kbit/s data 6 kbit/s data 6 kbit/s data 12 kbit/s data 6 kbit/s data 14,5 kbit/s data 12 kbit/s data 6 kbit/s data 6 kbit/s data 3.6 kbit/s data 3.6 kbit/s data 3.6 kbit/s data 3.6 kbit/s data 3.6 kbit/s data 3.6 kbit/s data 3.6 kbit/s data 3.6 kbit/s
See Note 1 no yes no no yes no no yes yes no yes no yes no yes no no no
Note1: speech version = 1, 2, 3 or 5 for a full rate TCH (selection of speech full rate version 2, 3 or 5 if allowed by an O&M parameter). speech version = 1 or 3 for a half rate TCH (if half rate or AMR half rate is allowed by an O&M parameter). other combinations supported
supported
not supported
END OF DOCUMENT
ED02 RELEASED
0475_02.doc

29/10/2007
3BK 11202 0475 DSZZA
52/52

ChannelModificationB10 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ChannelModificationB10 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

All rights reserved.

Site VELIZY Originators F. TOMASSONI

EVOLIUM SAS CHANNEL MODIFICATION RELEASE B10

System Sub-system Document Category

ALCATEL-LUCENT GSM BSS SYS-TLA PRODUCT DEFINITION

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

INTERNAL REFERENCED DOCUMENTS

OPEN POINTS / RESTRICTIONS

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

STRATEGY ON CHANNEL MODIFICATION UNSUCCESSFUL CASES

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

3BK 11202 0475 DSZZA

(1) (1) (2) (2) (3) (3) (4) (4)

B10 Channel Modification

3BK 11202 0475 DSZZA

Mode Modify Rejection from BTS

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

Channel Mode Modify Failure in MS

B10 Channel Modification

3BK 11202 0475 DSZZA

Three error cases are to be considered:

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

Failure Cases while reverting to old channel mode

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

Value: radio interface message failure.

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

B10 Channel Modification

3BK 11202 0475 DSZZA

ASSIGNMENT REQUEST (Note 1)

await mode modify ack (new mode) MODE MODIFY ACK

MODE MODIFY NACK

T9112 expiry ack

MODE MODIFY NACK

await channel mode modify T9103 expiry

B10 Channel Modification