ChannelModificationB10.pdf

ED02 RELEASED B10 Channel Modification

0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 1/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

Site VELIZY

EVOLIUM SAS

Originators F. TOMASSONI

CHANNEL MODIFICATION

RELEASE B10

System : ALCATEL-LUCENT GSM BSS Sub-system : SYS-TLA Document Category : 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 M. TITIN-SCHNAIDER

SYT DPM

S. BARRE SYT CCM

R. SABELLEK BTS DPM

Name App.

SONG J. BSC DPM

REVIEW

HISTORY Ed. 01 Proposal 01 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).

Ed. 01 Proposal 02 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).

Ed. 01 Released 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.

Ed. 02 Released 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)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 2/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 3/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

INTERNAL REFERENCED DOCUMENTS Not applicable

REFERENCED DOCUMENTS 3GPP references [1] 3GPP TS 44.018 Mobile radio interface layer 3 specification; Radio Resource

Control (RRC) protocol [2] 3GPP TS 24.008 Mobile Radio Interface Layer 3 specification; Core Network

Protocols [3] 3GPP TS 48.008 Mobile-services Switching Centre - Base Station System (MSC -

BSS) interface Layer 3 specification [4] 3GPP TS 48.058 Base Station Controller - Base Transceiver Station (BSC - BTS)

interface Layer 3 specification [5] 3GPP TS 48.060 In-band control of remote transcoders and rate adaptors for full

rate traffic channels [6] 3GPP TS 43.045 Technical Realization of Facsimile Group 3 Transparent [7] 3GPP TS 43.046 Technical Realization of Facsimile Group 3 non-Transparent [8] 3GPP TS 27.001 General on Terminal Adaptation Functions for Mobile Stations [9] 3GPP TS 44.021 Rate Adaptation on the MS-BSS interface [10] 3GPP TS 48.020 Rate Adaptation on the BSS-MSC interface

Alcatel references

[11] 3BK 11202 0438 DSZZA Normal Assignment Procedure [12] 3BK 11202 0432 DSZZA Call Release [13] 3BK 11202 0466 DSZZA TC/BTS Interface [14] 3BK 11203 0134 DSZZA BSS Telecom Parameters [15] 3BK 11202 0476 DSZZA DTX Functional Specification [16] 3BK 11202 0173 DSZZA Protocol Error Handling [17] 3BK 11202 0437 DSZZA Internal Channel Change [18] 3BK 11202 0433 DSZZA Classmark Handling [19] 3BK 11202 0435 DSZZA External Channel Change [20] 3BK 11202 0445 DSZZA Resource Allocation and Management [21] 3BK 11202 0156 DSZZA Ciphering Procedure [22] 3BK 11202 0457 DSZZA System Information Management [23] 3BK 11202 0440 DSZZA Radio & Link Establishment [24] 3BK 11203 0140 DSZZA Layer 3 message dictionary - Abis interface [25] 3BK 11202 0479 DSZZA TFO Functional Specification

RELATED DOCUMENTS None.

PREFACE This document specifies the Alcatel BSS behaviour during the Channel modification procedure.

OPEN POINTS / RESTRICTIONS


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 4/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

None.


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 5/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 6/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

2 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).


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 7/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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.


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 8/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 9/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

3 DYNAMIC BEHAVIOUR

3.1 GENERAL BEHAVIOUR

3.1.1 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) ASSIGNMENT REQUEST (1) Stop Trr1

Figure 1: Successful channel modification

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 10/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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

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

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

5 Upon receipt of the CHANNEL MODE MODIFY ACKNOWLEDGE message, the BSC stops timer T9112 and sends the message ASSIGNMENT COMPLETE to MSC.

3.1.2 Error cases

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) MODIFY (1) ------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2) (4) MODIFY REJECT Stop Trr1 (4)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 11/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

4 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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 12/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

MS BTS BSC MSC

(1) MODIFY (1) ------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2) (6) MODIFY REJECT Stop Trr1 (6)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 13/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

case b) BTS does not answer to the MODE MODIFY message (T9103 expires in the BSC)

MS BTS BSC MSC

(1) MODIFY (1) ------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 14/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

Three error cases are to be considered:

case a) The MS does not answer to the CHANNEL MODE MODIFY message, timer T9112 expires in the BSC.

MS BTS BSC MSC



0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 15/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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) MODIFY (1) ------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2) Stop Trr1 (10) MODIFY REJECT (10)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 16/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.



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



0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 17/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.



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) MODIFY (1) ------------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 18/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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

8 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. 9 Upon receipt of the ASSIGNMENT FAILURE message, the MSC sends the message CLEAR

COMMAND to the BSC, and stops timer Trr1. 10 Upon receipt of the CLEAR COMMAND message, BSC stops T9110.


* Ref.[12] ICM0501: Value: radio interface message failure.


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 19/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

case b) MODE MODIFY (old mode) message is not answered by the BTS (timer T9103 expiry in the BSC)

MS BTS BSC MSC

(1) MODIFY (1) ------------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 20/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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 BTS BSC MSC

(1) MODIFY (1) ------------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2) (10) CLEAR COMMAND stop Trr1 (10)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 21/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.



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) MODIFY (1) --------------------------------------------------------------------------------------> (2) ASSIGNMENT REQUEST (2)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 22/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.



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.


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 23/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

T9103 expiry

call

await modemodify ack(old mode)

active

await channel

mode modify

ack

MODE MODIFY ACK (Note 4)

MODE MODIFY ACK

MO

DE M

OD

IFY N

ACK

MO

DE M

OD

IFY N

ACK

T9112 expiry

MO

DIFY

ACK

(Note 3)

CHANNEL M

OD

E

call/channel

release

CHANNEL M

OD

E M

OD

IFY AC

K (N

ote 2)

T9103 expiry

ASSIGNM

ENT

REQUEST

ASSIGNMENTREQUEST (Note 1)

await mode modify ack (new mode)

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 24/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

BSC state transition table for Channel Modification during Call Active state

STATE EVENT

Call Active

ASSIGNMENT REQUEST (error of message analysis - see Note 1 of Figure 6 and action ASS-FAIL of section 3.2.1.1)

Send ASSIGNMENT FAILURE to MSC Next state Call Active

ASSIGNMENT REQUEST (see Note 1 of Figure 6 and action ASS-COMP of section 3.2.1.1)

Send ASSIGNMENT COMPLETE to MSC Next state Call Active

ASSIGNMENT REQUEST (see action MODE-MODIFY of section 3.2.1.1)

Send MODE MODIFY message Start T9103

Next state Await Mode Modify ACK (new mode) CLEAR COMMAND 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 EVENT

Await Mode Modify ACK (new mode)

MODE MODIFY ACK is received Stop T9103 Send the CHANNEL MODE MODIFY message (new mode) Start T9112

Next state Await Channel Mode Modify ACK MODE MODIFY NACK is received Send the ASSIGNMENT FAILURE message to MSC

Next state Call Active T9103 expiry Send the ASSIGNMENT FAILURE message to MSC

Start T9110

Next state Call/Channel Release CLEAR COMMAND N0600 - see ref.[12]

Table 3-2: State Await Mode Modify ACK (new mode)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 25/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

BSC state transition table for Channel Modification during Await Channel Mode Modify ACK state

STATE EVENT

Await CHANNEL MODE MODIFY ACK

CHANNEL MODE MODIFY ACK (see Note 2 of Figure 6)

Stop T9112 Send ASSIGNMENT COMPLETE to MSC

Next state Call Active CHANNEL MODE MODIFY ACK (see Note 3 of Figure 6)

Stop T9112 Send MODE MODIFY (old mode) to BTS Start T9103

Next state Await Mode Modify ACK (old mode) T9112 expiry Send MODE MODIFY (old mode) to BTS

Start T9103

Next state Await Mode Modify ACK (old mode) CLEAR COMMAND 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

Await Mode Modify ACK (old mode)

MODE MODIFY ACK 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

MODE MODIFY NACK Stop T9103 Send ASSIGNMENT FAILURE to MSC Start T9110

Next state Call/Channel Release T9103 expiry Send ASSIGNMENT FAILURE to MSC

Start T9110

Next state Call/Channel Release CLEAR COMMAND N0600 - see ref.[12]

Table 3-4: State Await Mode Modify ACK (old mode)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 26/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

BSC state transition table for Channel Modification during Call/Channel Release state

STATE EVENT

CALL/CHANNEL RELEASE

CLEAR COMMAND Stop T9110

ICM0701 - see ref.[12] Table 3-5: State CALL/CHANNEL RELEASE

3.1.4 Filtering of the CFI message

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.


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 27/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

3.2 DETAILED BEHAVIOUR WITHIN BSS ENTITIES

3.2.1 BSC

3.2.1.1 BSC analysis of ASSIGNMENT REQUEST message

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.

ASS-FAILor

ASS-COMP (Note 1 Figure 6)

MODE-MODIFY

ASSIGNMENT REQUEST

General checking

(section 3.2.1.1.2)

successful ?No

+ specific checking on CIC(section 3.2.1.1.3)

YES

checking Channel Type(section 3.2.1.1.4)

successful ?

YES

No

Figure 7: Checking ASSIGNMENT REQUEST message


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 28/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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.


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 29/52

A

l

l

r

i

g

h

t

s

r

e

s

e

r

v

e

d

.

P

a

s

s

i

n

g

o

n

a

n

d

c

o

p

y

i

n

g

o

f

t

h

i

s

d

o

c

u

m

e

n

t

,

u

s

e

a

n

d

c

o

m

m

u

n

i

c

a

t

i

o

n

o

f

i

t

s

c

o

n

t

e

n

t

s

n

o

t

p

e

r

m

i

t

t

e

d

w

i

t

h

o

u

t

w

r

i

t

t

e

n

a

u

t

h

o

r

i

z

a

t

i

o

n

f

r

o

m

E

v

o

l

i

u

m

.

REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST

CURRENT CHANNEL MODE (see Note 2)

Channel rate and type

Speech/Data indicator

Data rate Speech Full rate

Speech HR (note 9)

Data 12 NT

full rate

Data 9.6 transparent

full rate


full rate


full rate HR TCH channel Lm

Speech N/A ASS-FAIL ICM0100

see table 3-7

ASS-FAIL ICM0100

ASS-FAIL ICM0100

ASS-FAIL ICM0100

ASS-FAIL ICM0100

See Note 1 Data any rate ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0100

ASS-FAIL ICM0100

ASS-FAIL ICM0100

ASS-FAIL ICM0100

Speech N/A see table 3-7

see table 3-7

see table 3-8

see table 3-8

see table 3-8

see table 3-8

12 kbit/s MODE-MODIFY ASS-FAIL ICM0200

ASS-COMP MODE-MODIFY note 4

MODE-MODIFY note 4

MODE-MODIFY note 4

Data non transparent

6 kbit/s HR 12 kbit/s FR

see Note 6

MODE-MODIFY ASS-FAIL ICM0200


MODE-MODIFY note 4

MODE-MODIFY note 4

FR or HR TCH channel

6 kbit/s ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

(see Note 3) 9.6 kbit/s MODE-MODIFY ASS-FAIL

ICM0200 MODE-MODIFY

note 4 ASS-COMP MODE-MODIFY MODE-MODIFY

Data transparent

4.8 kbit/s MODE-MODIFY ASS-FAIL ICM0200

MODE-MODIFY note 4

MODE-MODIFY ASS-COMP MODE-MODIFY

1.2/ 0.075 kbit/s

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

else see Note 8

MODE-MODIFY ASS-FAIL ICM0200

MODE-MODIFY note 4

MODE-MODIFY MODE-MODIFY ASS-COMP

Table 3-6a: Special checking on the Channel Type MIE (1/2)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 30/52

A

l

l

r

i

g

h

t

s

r

e

s

e

r

v

e

d

.

P

a

s

s

i

n

g

o

n

a

n

d

c

o

p

y

i

n

g

o

f

t

h

i

s

d

o

c

u

m

e

n

t

,

u

s

e

a

n

d

c

o

m

m

u

n

i

c

a

t

i

o

n

o

f

i

t

s

c

o

n

t

e

n

t

s

n

o

t

p

e

r

m

i

t

t

e

d

w

i

t

h

o

u

t

w

r

i

t

t

e

n

a

u

t

h

o

r

i

z

a

t

i

o

n

f

r

o

m

E

v

o

l

i

u

m

.

REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST

CURRENT CHANNEL MODE (see Note 2)

Channel rate and type

Speech/Data indicator

Data rate Speech Full rate

Speech HR (note 9)

Data 12 NT

full rate


full rate


full rate


full rate Speech N/A see table

3-7 ASS-FAIL ICM0100

see table 3-8

see table 3-8

see table 3-8

see table 3-8

12 kbit/s MODE-MODIFY

ASS-FAIL ICM0100


MODE-MODIFY note 4

MODE-MODIFY note 4

Data non transparent

6 kbit/s HR 12 kbit/s FR

see Note 6

MODE-MODIFY

ASS-FAIL ICM0100


MODE-MODIFY note 4

MODE-MODIFY note 4

FR TCH channel Bm

6 kbit/s ASS-FAIL ICM0200

ASS-FAIL ICM0100

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

9.6 kbit/s MODE-MODIFY

ASS-FAIL ICM0100

MODE-MODIFY note 4

ASS-COMP MODE-MODIFY

MODE-MODIFY

Data transparent

4.8 kbit/s MODE-MODIFY

ASS-FAIL ICM0100

MODE-MODIFY note 4

MODE-MODIFY

ASS-COMP MODE-MODIFY

1.2/ 0.075 kbit/s

ASS-FAIL ICM0200

ASS-FAIL ICM0100

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

ASS-FAIL ICM0200

else see Note 8

MODE-MODIFY

ASS-FAIL ICM0100

MODE-MODIFY note 4

MODE-MODIFY

MODE-MODIFY

ASS-COMP

Table 3-6b: Special checking on the Channel Type MIE (2/2)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 31/52

A

l

l

r

i

g

h

t

s

r

e

s

e

r

v

e

d

.

P

a

s

s

i

n

g

o

n

a

n

d

c

o

p

y

i

n

g

o

f

t

h

i

s

d

o

c

u

m

e

n

t

,

u

s

e

a

n

d

c

o

m

m

u

n

i

c

a

t

i

o

n

o

f

i

t

s

c

o

n

t

e

n

t

s

n

o

t

p

e

r

m

i

t

t

e

d

w

i

t

h

o

u

t

w

r

i

t

t

e

n

a

u

t

h

o

r

i

z

a

t

i

o

n

f

r

o

m

E

v

o

l

i

u

m

.

CURRENT CHANNEL MODE is Speech

REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST 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

CURRENT CHANNEL MODE is Data

REQUESTED CHANNEL MODE IN ASSIGNMENT REQUEST is Speech

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)


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 32/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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.

Note 2: Half rate data is not supported. Half rate speech is only supported if HR_ENABLED flag is TRUE. Note 3: "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.

Note 4: 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.

Note 5: 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.

Note 6: 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.

Note 7: The BSS internal behaviour (i.e. specific BTS and BSC behaviours) is detailed in ref.[11]. Note 8: 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. Note 9: 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.


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 33/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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 Algorithm or coding MIE Message

Type Equal to ASSIGNMENT COMPLETE, see ref.[3].

OIE RR Cause not used. OIE Cell identifier not used.

OIE Chosen Channel

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.

OIE Chosen Encryption Algorithm

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

OIE Circuit pool 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.

OIE Speech Version (chosen)

Included if the MSC has left the choice to the BSS between several speech versions in the ASSIGNMENT REQUEST.

Table 3-9: BSC construction of ASSIGNMENT COMPLETE message


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 34/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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 Algorithm or coding MIE Message Type Equal to ASSIGNMENT FAILURE, see ref.[3].

MIE Cause See previous sections and ref.[12]. OIE RR Cause Not used OIE Circuit Pool 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.

OIE Circuit Pool List Not used in the channel modification case. Used in other cases: see the relative specifications.

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 Algorithm or coding MIE Message Discriminator

See ref.[4].

MIE Message type Equal to MODE MODIFY. MIE Channel

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

MIE Channel Mode

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 35/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

OIE Main Channel Reference

Not used

OIE Encryption Information

Not used.

OIE Multirate Configuration

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

OIE TFO Command

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]. OIE Supported Codec Types

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

OIE TFO Transparent Container

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

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 36/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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 Algorithm or coding MIE Protocol Discriminator See ref.[4].

MIE Skip Indicator Equal to "0000". MIE Message Type Equal to CHANNEL MODE MODIFY.

MIE Channel Description Channel Description of the already active channel. MIE Channel Mode See ANNEX 2.

OIE VGCS Target Mode Indication Not used OIE Multirate Configuration 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).


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 37/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

3.2.2 BTS

3.2.2.1 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:


See ref.[4].

MIE Message Type

Equal to MODE MODIFY ACKNOWLEDGE

MIE Channel Number

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:


See ref.[4].

MIE Message Type

Equal to MODE MODIFY NEGATIVE ACKNOWLEDGE

MIE Channel Number

It is coded as in the received MODE MODIFY message

MIE Cause 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]).


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 38/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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

Intermediate data rate kbit/s

Radio interface rate kbit/s

600* 1200 2400 4800 9600

8 8 8 8 16

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 39/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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 INTERACTION WITH OTHER PROCEDURES

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


0475_02.doc 29/10/2007 3BK 11202 0475 DSZZA 40/52

All r

ight

s re

serv

ed. P

assi

ng

on a

nd c

opy

ing

of th

is

docu

men

t, use

and

com

munic

atio

n o

f its

co

nte

nts

not p

erm

itted

with

out w

ritte

n au

thor

izat

ion fr

om

Ev

oliu

m.

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.

Documents

ChannelModificationB10.pdf