AMR

Site
VELIZY TECHNICAL DEPARTMENT

not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Originators SPEECH AND ADAPTATIVE MULTI–RATE

J. RZEZNIK
AMR
Domain : ALCATEL900
Division : SYSTEM DOCUMENTATION
Rubric : GENERAL ANALYSIS
Type : SPECIFICATION
Distribution Codes Internal : 9999 External : 900000
ABSTRACT
This document specifies the Speech Teleservice offered by the NSS in GSM since R6 and UMTS since
R7.
Approvals
Name M.JACOB R.RAYNAUD M.BIGNON

App.
Name
App.
REVIEW
Reference of the minutes SRD/TD/SYS/DFB/ES/00.171.03/MJ

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01 RELEASED
CIT AAC033638800DS En Y 1/ 2
2
HISTORY
01 on 03–01–23
Creation.
This document has been created from document AAC033638700DS edition 03.
Modifications associated with following Change Requests have been included:

– SYSA01CAG055335 Take into account INAP V5 evolutions for U2 concerning TcInfo
parameter of CREATE message.
– SYSA01FAG060883 Removal of SDU Error Ratio in RAB parameters in case of no error
detection consideration.
– SYSA01FAG065374 Indication on whether IEs of RANAP interface messages are optional
or mandatory has been removed.
– SYSA01FAG067385 Modification of value of Guaranteed Bit Rate for speech calls with
12.2kbit/s codec only.
– SYSA01CAG071949 Take into account the function Service Handover – FEB2167.
– SYSA01FAG076093 Wrong implementation of DTX function in RCP.
– SYSA01FAG083485 AMR – Guaranteed Bit Rate can be set to any value belonging to the
list of codecs sent in RAB assignment.
– SYSA01FAG078864 Incoherence between traffic class in RAB ASSIGNMENT REQ and
Paging Cause.
FOR INTERNAL USE ONLY
Note on implementation:
In release NSS R7.0, only AMR_12.2 is supported by the Tc in UMTS, or when only AMR_12.2 is offered
the RAB which is assigned by the NSS is limited to the corresponding 12.2kb/s rate.
The RAB parameters have the following specific values:
– Guaranteed Bit Rate=12.2kbit/s,
– Subflow SDU size for classes A, B and C is only provided for 12.2kbit/s.
END OF DOCUMENT
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01 RELEASED
CIT AAC033638800DS En Y 2/ 2
2
SPECIFICATION
TABLE OF CONTENTS
LIST OF FIGURES AND TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
HISTORY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
REFERENCED DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
GLOSSARY / TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1 General description of the function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2 codecs applicable to GSM/UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.3 In GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.4 AMR in UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.5 Role of the NSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1.6 DTX aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1.7 TFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1.8 Charging aspects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1.9 MS–MS calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.1.10 International calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1.11 Circuit Pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.1.12 Service Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2 Functional options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Involved network elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 DETAILED DESCRIPTION AND SCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1 Channel assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Channel Assignment in the MOC case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.2 Channel Assignment in the MTC case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2 RAB assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.1 RAB assignment in the MOC case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.2 RAB assignment in MTC case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 GSM Handover and UMTS relocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 GSM Internal Intra–Cell Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 GSM Internal Inter–Cell Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.3 GSM External Intra–MSC Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
01 030123 Creation CA–SYS CA–SYS
ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR

1AA 00014 0004 (9007) A4 – ALICE 04.10
SPEECH and ADAPTATIVE MULTI–RATE
AMR
ED 01
CIT AAC033638800DS En 1 / 103
103
2.3.4 External Inter–MSC Handover within a GSM PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.5 UMTS relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.6 In–call modification (successful) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3.7 In–call modification (rejected) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3 DESCRIPTION OF INTER–ENTITIES MESSAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.1 RCF – MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.1 SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.2 CALL CONFIRMED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.3 CALL PROCEEDING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.4 MODIFY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.5 MODIFY COMPLETE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2 RCF – BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.1 CHANNEL ASSIGNMENT REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.2 CHANNEL ASSIGNMENT COMPLETE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.3 CHANNEL ASSIGNMENT FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.4 HANDOVER FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.5 HANDOVER REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.6 HANDOVER REQUEST ACKNOWLEDGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.2.7 HANDOVER REQUIRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2.8 HANDOVER PERFORMED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.3 RCF–RNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.1 RAB ASSIGNMENT REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.2 RAB ASSIGNMENT RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3.3 RELOCATION REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.4 RELOCATION REQUIRED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.4 RCF – SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4.2 RETRIEVE RESULT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4 DESCRIPTION OF NETWORK ENTITIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.1 HLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 VLR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3 RCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.1 Data and retrofit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3.2 Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.3 Functional description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.4 Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.3.5 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.3.6 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.3.7 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.3.8 Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4 SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5 INTERACTIONS WITH OTHER SERVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 2 / 103
103
LIST OF FIGURES AND TABLES
Figure 1. Variable partitioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 2. Network configuration for AMR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 3. In band Signalling for AMR codec adaptation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 4. Architecture for speech in UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Table 1. Source code bit–rates for the UMTS AMR codec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 2. Number of bits in the Speech frames. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Table 3. Number of bits in Classes A, B and C for each AMR codec mode. . . . . . . . . . . . . . . . . . . . . 16
Table 4. Number of bits in Classes A, B and C for SID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 5. Generic UMTS AMR frame structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Table 5. Interpretation of Frame Type Index used for the Frame Type, Mode Indication, and Mode
Request fields of UMTS AMR Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 6. Basic Circuit pools with speech v3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 6. Channel Assignment in the MOC case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 7. Channel Assignment in the MTC case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 8. RAB Assignment in the MOC case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 9. Intra BSS Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 10. Intra MSC Handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 11. 3G 3G relocation – intra MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 12. 3G 3G relocation – inter MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 13. 3G 2G relocation – intra MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 14. 3G 2G relocation – inter MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figure 15. 2G 3G handover – intra MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 16. 2G 3G handover – inter MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Figure 17. In–call modification (successful). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 18. In–call modification (rejected due to new received GSM–BC). . . . . . . . . . . . . . . . . . . . . . 45
Figure 19. In–call modification (rejected due to assignment failure). . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Table 7. MSC–MS: SETUP message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 8. GSM–BC – Speech Teleservice request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 9. GSM–BC – Radio Channel Requirement field in octet 3, in case of octet 3a... extension. 48
Table 10. GSM–BC – Speech versions in octet 3a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Table 11. MSC–MS: CALL CONFIRMED message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Table 12. MSC–MS: CALL PROCEEDING message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 13. MSC–MS: MODIFY message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Table 14. MSC–MS: MODIFY COMPLETE message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Table 15. MSC–BSC: CHANNEL ASSIGNMENT REQUEST message. . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 20. Channel Type IE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Table 16. Channel Type IE – Speech / data indicator field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Table 17. Channel Type IE – Channel rate and type field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 18. Channel Type IE – Permitted speech version indication field. . . . . . . . . . . . . . . . . . . . . . . . 57
Table 19. MSC–BSC: CHANNEL ASSIGNMENT COMPLETE message . . . . . . . . . . . . . . . . . . . . . . 58
Table 20. Chosen Channel IE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Table 21. MSC–BSC: CHANNEL ASSIGNMENT FAILURE message . . . . . . . . . . . . . . . . . . . . . . . . . 59
Table 22. MSC–BSC: HANDOVER REQUEST message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Table 23. MSC–BSC: HANDOVER REQUEST ACKNOWLEDGE message . . . . . . . . . . . . . . . . . . . 62
Table 24. MSC–BSC: HANDOVER REQUIRED message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 21. Speech Version IE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Table 25. MSC–BSC: HANDOVER PERFORMED message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 26. RAB ASSIGNMENT REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1AA 00014 0004 (9007) A4 – ALICE 04.10
Table 27. RELOCATION REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Table 28. MS–SPEECH–V and MS–SPEECH–V–STORED tables. . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 22. SDL 1/2: Received GSM–BC analysis against speech version. . . . . . . . . . . . . . . . . . . . . 78
Figure 23. SDL 2/2: Received GSM–BC analysis against speech version. . . . . . . . . . . . . . . . . . . . . 79
ED 01
CIT AAC033638800DS En 3 / 103
103
Table 29. POOL–BASIC: Basic table of pools meeting MS speech versions preferences. . . . . . . . 81
Table 30. Fallback pools without support of speech v3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 24. SDL: Selection of the pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Table 31. ASSIGNMENT REQUEST: Channel type IE fields values. . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 25. SDL 1/3: Channel Type IE for assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87


Figure 28. Determination of the type of call for paging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 29. SDL: In–call modification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Table 32. Translation of generated errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 4 / 103
103
HISTORY
01 on 03–01–23
Creation.
REFERENCED DOCUMENTS
[1] GSM REC 04.08.

Mobile radio interface layer 3 specification.
[2] GSM REC 08.08.

MSC – BSS interface; layer 3 specification.
[3] GSM REC 05.09.

Link adaptation.
[4] 3GPP TS 22.002.

Circuit Bearer Services supported by a PLMN.
[5] 3GPP TR 23.107.

QoS Concept and Architecture.
[6] 3GPP TS 24.008.

Mobile Radio Interface Layer 3, Core Network Protocols – Stage 3.
[7] 3GPP TS 25.413.

UTRAN Iu Interface RANAP Signalling.
[8] 3GPP TS 25.415.

UTRAN Iu Interface User Plane protocols.
[9] 3GPP TS 26.071.

Mandatory Speech Codec speech processing functions – AMR speech codec; General description.
[10] 3GPP TS 26.101.

AMR Speech Codec frame structure.
[11] 3GPP TS 26.102.

Speech Codec List for GSM and UMTS.
[12] 3GPP TS 26.103.

AMR Speech Codec; interface to Iu and Uu.
[13] 3GPP TS 29.002.

MAP.
[14] 3GPP TS 48.008.

MSC – BSS interface; layer 3 specification.
[15] RCF–SSP INAP V6 interface (INAPI).

AAC033632700DS.
1AA 00014 0004 (9007) A4 – ALICE 04.10
[16] Radio Resource Management (RM).

AAC020015700DS.
ED 01
CIT AAC033638800DS En 5 / 103
103
[17] Handover (HO).
AAC020007700DS.
[18] Basic Call Handling for Alcatel E10 NSS (BCH).

AAC033643700DS.
[19] Data Transmission, Basic Data Call Control (DA).

AAC020248700DS.
[20] Circuit Pool Management (TPOOLM).

AAC030654600DS.
[21] High Speed Circuit Switched Data (HSCSD).

AAC033505000DS.
[22] Man Machine commands in the RCP (MMCRCP).

AAC020767700DS.
[23] Functional options list (FL).

This reference refers to multiple documents, one per customer.
[24] Charging Data collection (CG).

AAC020017700DS.
[25] ISDN–BC <–> GSM–BC Translation (BCTRL).

AAC020339700DS.
[26] RCP–RNC RANAP Interface (RANAPI).

AAC033690700DS.
[27] Handling of PLMN Specific Data in HLR and RCP (PSDATA).

AAC030551800DS.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 6 / 103
103
GLOSSARY / TERMINOLOGY
GSM and/or UMTS:

AMR Adaptative Multi–Rate.

BC Bearer Capability.
BS Bearer Service.
BSC Base Station Controller.
BSS Base Station Subsystem.
BSSMAP Base Station System Management Application Part.
BTS Base Transceiver Station.
CDR Charging Detailed Record.
CIC Circuit Identity Code.
CN Core Network.
DTAP Direct Transfer Application Part.
DTX Discontinuous Transmission.
EFR Enhanced Full Rate.
FR Full Rate.
GBR Guaranteed Bit Rate.
HR Half Rate.
HSCSD High Speed Circuit Switched Data.
IAM Initial Address Message.
IE Information Element.
IMSI International Mobile Subscriber Identity.
ISDN Integrated Services Digital Network.
ITC Information Transfer Capability
MS Mobile Station.
NSS Network SubSystem.
MCC Mobile Country Code.
MNC Mobile Network Code.
MOC Mobile Originating Call.
MTC Mobile Terminated Call.
MxBR Maximum Bit Rate.
PDU Protocol Data Unit.
PLMN Public Land Mobile Network.
PSTN Public Switched Telephony Network.
QoS Quality of Service.
RCR Radio channel requirement.
SDU Service Data Unit.
Tc Transcoder.
TCH Traffic CHannel.
TCH/AFS Traffic Channel/AMR Full rate Speech.
TCH/AHS Traffic Channel/AMR Half rate Speech.
TDM Time Division Multiplex.
TE Terminal Equipment.
TFO Tandem Free Operation.
TRAU Transcoder and Rate Adaptator Unit.
TS Tele Service.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 7 / 103
103
Adaptative Multi–Rate In GSM, speech and channel codec capable of operating at gross bit–
rates of 11.4kbps (half rate) and 22.8kbps (full rate). In addition, the codec
may operate at various combinations of speech and channel coding
(codec mode) bit–rates for each channel mode
AMR is also referred to as ”speech version 3”.

in UMTS, an AMR codec, different from the GSM one, has also been
defined.
AMR handover Handover between FR and HR channel modes to optimize AMR operation
Channel mode Half–rate or full–rate operation
Channel mode adaptation The control and selection of the (FR or HR) channel mode
Circuit Pool A circuit pool is a group of circuits, between MSC and BSC, to which a
TRAU with speech and usually data handling capabilities is assigned. The
characteristics of a circuit pool (i.e. different speech versions and data
rates supported) are defined by the GSM recommendations
Codec mode For a given channel mode, the bit partitioning between speech and
channel codec.
Codec mode adaptation The control and selection of the codec mode bit rates.
In–Band Signalling Signalling for DTX, Channel and codec mode modification carried within
the channel by reserving or stealing bits normally used for speech
transmission.
Internal handover An internal handover is a handover which takes place between channels
on a cell or cells controlled by a single BSS. It operates without reference
to the MSC, although the MSC is informed upon completion.
Gross bit–rate The bit rate of the channel mode selected (22.8kbps or 11.4kbps)
Speech version 3 synonymous to AMR or AMR version 1
2G refers to 2nd generation networks i.e. GSM networks
3G refers to 3rd generation networks i.e. UMTS networks
Channel Assignment refers to the GSM environment only.

RAB Assignment refers to the UMTS environment only.
UMTS only:
AAL2 ATM Adaptation Layer type 2.

ATM Asynchronous Transfer Mode.
BER Bit Error Rate.
DCH Dedicated CHannel.
ITI Iu Timing Interval.
Iu UP Interface u, User Plane.
RAB Radio Access Bearer.
RANAP Radio Access Network Apllication Part.
RBER Residual Bit Error Rate.
RFC RAB Subflow Combination.
RFCI RFC Indicator.
RNC Radio Network Controller.
SID Silence Insertion Descriptor.
SMpSDU Support Mode for predefined SDU size.
SRNC Serving RNC.
SRNS Serving RN Subsystem.
TrM Transparent Mode.
UE User Equipement.
1AA 00014 0004 (9007) A4 – ALICE 04.10
UTRAN UMTS Radio Access Network
ED 01
CIT AAC033638800DS En 8 / 103
103
1 INTRODUCTION
1.1 General description of the function

1.1.1 Overview.
This feature brings the ability to support Adaptative Multi–Rate (AMR) speech codec by the GSM and
UMTS Network SubSystem (NSS).
In GSM AMR is also known as speech version 3.
1.1.2 codecs applicable to GSM/UMTS
The codecs applicable to GSM are:

– GSM FR or FR speech v1,
– GSM HR or HR speech v1,
– EFR or speech v2,
– GSM AMR or, FR and HR speech v3.
In UMTS, UMTS AMR is the only and mandatory codec.
1.1.3 In GSM
1.1.3.1 Description
The currently used FR speech codec is growing aged.

The HR codec has been an attempt to increase the network capacity, however it turned out to be of poor
speech quality under bad radio conditions, and especially for MS–MS calls where the quality is impaired
by the double transcoding.
There is also the EFR codec which brings an improved speech quality.
All these speech codecs (HR, FR, EFR) operate at a fixed coding rate. Channel protection against errors
is also added at a fixed rate. Therefore they are not adaptable.
The AMR speech codec has been designed to:

– increase the speech quality, both in full and half rate,
– increase the network capacity,
– bring a long term generic solution which prevents from adding new individual codecs,
– taking into account the Tandem Free Operation mode.
So, contrary to the previous codecs, the principle of AMR is to be adaptable to changing radio and traffic
conditions, and also to be customized to the specific needs of network operators.
There are three levels of adaptation:

– handovers between HR and FR channels according to traffic demands,
– variable partitioning between speech and channel coding bit–rates to adapt channel conditions in
order to obtain the best speech quality,
– possibility of channel and codec control algorithms optimization to meet specific operators needs and
network conditions.
1AA 00014 0004 (9007) A4 – ALICE 04.10
One principle of AMR is to have a set of codecs, and for any radio condition, to use the one with the best
speech quality
ED 01
CIT AAC033638800DS En 9 / 103
103
Under good radio conditions, a codec with a high bit rate is used. More information is used to encode
speech, so the speech quality is better. In the channel coding, little room is left for redundancy.
Under poor radio conditions, a codec with a low bit rate is used. Speech is encoded with less information,
but this information is well protected thanks to the redundancy of the channel coding.
The variable partitioning his shown hereunder.
moving boundary according to

radio conditions
speech coding channel coding
Figure 1. Variable partitioning.
The codec is dynamically adapted by the MS (downlink) and the BTS (uplink). The codec used uplink can
be different from the codec used downlink.
N.B. AMR is referred to in the GSM recommendations as ”speech version 3”.
1.1.3.2 AMR network level strategies.
The advantages are twofold:

– for the end user, the speech quality is increased both in half and full rate modes,
– for the GSM network operator, the use of the available radio specter is optimized and therefore the
network capacity increased.
The codecs can be used in three different ways:

– FR only ³ for maximum robustness to channel errors, hence better quality,
– HR only ³ for maximum network capacity advantage,
– mixed HR/FR ³ allows a trade–off between capacity and quality enhancements according to radio
and traffic conditions.
In the future, when most MSs will handle AMR, the versatility of AMR will make the existing codecs redun-
dant.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 10 / 103
103
1.1.3.3 AMR functional operation.
The next figure shows in which PLMN elements the introduction of AMR induces evolutions.
speech encoder/decoder signalling speech v3 in

assignment, handovers...
channel encoder/
decoder
BTS BSC RCP SSP

• • • • • •
NetĆ
• • • • • • work
Abis A
TRAU
AMR channel coding
Figure 2. Network configuration for AMR.
The following of this section is provided for information.
The next figure shows all the inband signalling between speech and channel encoder/decoder.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 11 / 103
103
MS BTS TRAU
SPE CHE CHD SPD

Uplink Speech Data

Codec Mode Indication (for uplink)
Suggested Codec Mode (for downlink)
Codec Codec
Adaptation Adaptation
Codec Mode Command (for uplink)
Codec Mode Indication (for downlink) Downlink Speech Data
SPD CHD CHE SPE
CHE: Channel Encoder

CHD: Channel Decoder
SPD: Speech Decoder
SPE: Speech Encoder
Figure 3. In band Signalling for AMR codec adaptation.
The AMR speech codec includes a set of fixed rate speech codec modes for HR and FR with the possibility
to switch between the modes depending on the propagation errors.
There are:
– 8 codec modes for FR, including GSM EFR:
• 2 modes exclusively available in FR 12.2kbps and 10.2kbps
• 6 modes both available in FR and HR 7.95kbps, 7.4kbps, 6.7kbps, 5.9kbps, 5.15kbps
and 4.75kbps.
– 6 codec modes for HR:
• 6 modes both available in FR and HR 7.95kbps, 7.4kbps, 6.7kbps, 5.9kbps, 5.15kbps
and 4.75kbps.
4 modes are selected by the BSS at call set up or handover and may be used during the communication.
Each codec mode provides a different level of error protection through a dedicated distribution of the avail-
lable gross bit rate (22.8kbps in FR and 11.4kbps in HR) between speech and channel coding. Therefore
the actual speech rate depends on the actual radio condition. A codec adaptation algorithm selects the
optimal speech rate (or codec mode) according to the channel quality. The codec mode adaptation relies
1AA 00014 0004 (9007) A4 – ALICE 04.10
on channel quality measurements performed in the MS and the network and on inband information sent
together with the speech data. Each link (up, down) may use a different codec mode, however the channel
type is the same, HR or FR .
ED 01
CIT AAC033638800DS En 12 / 103
103
In the above figure, in both directions, the speech data are associated with a Codec Mode Indication to
enable the receiver to select the proper channel decoder (in MS and BTS) and the proper speech decoder
(in MS and TRAU).
For the adaptation of the uplink codec mode, the BTS estimates the channel quality, selects the best codec
mode, and sends this information inband to the MS in Codec Mode Command.
For the downlink codec adaptation, the MS estimates the downlink channel quality, and sends inband this
quality information to the network as a Suggested Codec Mode.
1.1.4 AMR in UMTS
1.1.4.1 Architecture
Transcoding between Iu–UP

over AAL2 and TDM, and
UMTS AMR codec processing
TC
Towards UTRAN Towards PSTN/ISDN
SSP
#7 signalling link
RCP
Serving MSC
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 4. Architecture for speech in UMTS.
ED 01
CIT AAC033638800DS En 13 / 103
103
In UMTS the principle of UMTS AMR remains the same as in GSM: inband signalling between MS, RNC
and Transcoder (TC) for codec mode adaptation. However, in UMTS the notion of HR and FR is no longer
applicable.
The Transport network between RNC and TC is based on ATM AAL2 on top of which there is Iu UP.
In addition to transcoding the speech, the TC converts the TDM framing to/from Iu UP PDUs.
The MSCs being only connected through TDM links, the TC is always located at the serving MSC.
1.1.4.2 Codec modes
In UMTS the notions of HR and FR being inexistant, the codec is only characterised by the modes it sup-
ports (i.e. source codec bit rates)
The defined UMTS AMR codec modes are listed in the following table. (see 3GPP TS 26.071 Ref.[9]).
Codec mode Source codec bit rates
AMR_12.20 12.20 kbit/s
AMR_10.20 10.20 kbit/s
AMR_7.95 7.95 kbit/s
AMR_SID 1.80 kbit/s note.
Table 1. Source code bit–rates for the UMTS AMR codec.
N.B. The rate for SID corresponds to the background encoding noise.
1.1.4.3 Transmission of speech frames.
Speech frames are sent every 20ms. The number of bits of a speech frame depends on the rate as shown
in the following table.
Source codec bit rates Total number of bits
12.20 kbit/s 244
10.20 kbit/s 204
7.95 kbit/s 159

1AA 00014 0004 (9007) A4 – ALICE 04.10
7.40 kbit/s 148
6.70 kbit/s 134
ED 01
CIT AAC033638800DS En 14 / 103
103
Source codec bit rates Total number of bits
5.90 kbit/s 118

5.15 kbit/s 103

4.75 kbit/s 95
1.80 kbit/s 39
Table 2. Number of bits in the Speech frames.
The bit rate (i.e. codec mode) can change every 20ms upon reception of an inband AMR command (Codec
Mode Request)
The AMR speech frames are transmitted over Iu UP used in SMpSDU mode. The predefined SDU size
corresponds to the size of the speech frame.
1.1.4.4 Notion of class
To each codec mode and SID are associated one, two or three classes: A,B and C. See 3GPP TS 26.101
Ref.[10].
Each class corresponds to a level of sensitiveness to errors.
Class ’A’ offers the best level of protection against errors, class ’C’ the worst level. The way an erroneous
speech frame is handled depends on the class where the error occurred.
An error in class ’A’ bits results in a corrupted speech frame which should not be decoded without applying
error concealment (see 3GPP TS 26.101 Ref.[10]).
An error in class ’B’ or ’C’ bits only reduces the speech quality.
The N bits of a speech frame for a given AMR codec mode and SID (for instance 244bits at 12.2kbit/s)
are split into up to three parts, each part is assigned to a class.
Over the radio interface, the different classes are sent over different co–ordinated DCHs offering different
bit protection classes.
The next table (from 3GPP TS 26.101 Ref.[10]) gives the description of the classes for every codec mode.
AMR codec mode Total number of Bits in Bits in Bits in

bits Class A Class B Class C
4.75 95 42 53 0
5.15 103 49 54 0
5.90 118 55 63 0
6.70 134 58 76 0
7.40 148 61 87 0
1AA 00014 0004 (9007) A4 – ALICE 04.10
7.95 159 75 84 0
ED 01
CIT AAC033638800DS En 15 / 103
103
10.2 204 65 99 40
12.2 244 81 103 60
Table 3. Number of bits in Classes A, B and C for each AMR codec mode.
Following table (from 3GPP TS 26.101 Ref.[10]) gives the description of the classes for SID frames. SID
is relevant when DTX is applied.

1.80 39 39 0 0
Table 4. Number of bits in Classes A, B and C for SID.
The repartitions in these two above table are used to define the RAB assigned by the NSS.
N.B. The decomposition of the two above tables comes from 3GPP TS 26.101 Ref.[10] where it is
provided for information.
1.1.4.5 AMR frame basic structure
This section is given for information, it does not affect the NSS.
The figure below provides a basic description of an AMR speech frame.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 16 / 103
103
Frame Type (4 bits)

AMR Header
Frame Quality Indicator (1 bit)
Mode Indication (3 bits)

AMR Auxiliary
Information (for
Mode Request (3 bits) TFO, Mode
Adaptation and
Codec CRC (8 bits)
Error Detection)
Class A bits
AMR Core Frame
Class B bits (speech or comfort
noise data)
Class C bits
Figure 5. Generic UMTS AMR frame structure
The frame fields are:

– Frame Type:
Designates the type of frame. Possible values are given in next table from 3GPP TS 26.101 Ref.[10].
Frame Type Index Frame content (AMR mode, comfort

noise, or other)
0 4.75 kbit/s
1 5.15 kbit/s
1AA 00014 0004 (9007) A4 – ALICE 04.10
2 5.90 kbit/s
3 6.70 kbit/s
ED 01
CIT AAC033638800DS En 17 / 103
103
Frame Type Index Frame content (AMR mode, comfort
noise, or other)
4 7.40 kbit/s
5 7.95 kbit/s
6 10.2 kbit/s
7 12.2 kbit/s (equivalent to GSM EFR)
8 AMR Comfort Noise Frame
9 GSM–EFR Comfort Noise Frame
10 IS–641 Comfort Noise Frame
11 PDC–EFR Comfort Noise Frame
12–14 For future use
15 No transmission/No reception
Table 5. Interpretation of Frame Type Index used for the Frame Type, Mode Indication, and Mode
Request fields of UMTS AMR Header.
– Frame Quality Indicator:

Indicates whether the frame contains errors.
– Mode Indication:
Designates the current AMR codec mode (values 0 to 7 of above table)
– Mode Request:
Designates the requested AMR codec mode (values 0 to 7 of above table)
– Codec CRC:
CRC over the class ’A’ bits.
1.1.4.6 Characterisation of a RAB for Speech
The RAB is assigned as follows:

– Only one RAB is assigned,
– One RAB Subflow Combination (RFC) is associated to each Codec Mode,
– For each RFC, a ’RAB Subflow’ is associated to each class of the Codec Mode.
To a ’RAB Subflow’ corresponds a SDU size which is equal to the number of speech bits.
For instance the RFC of Codec Mode 12.2kbit/s is built up of three Subflows, one for class ’A’ with
an SDU size of 81 bits, one for class ’B’ with an SDU size of 103 bits, and finally one for class ’C’ with
an SDU size of 60 bits.
The RAB which is assigned for speech reflects the TC capabilities. The TC supports all the UMTS AMR
modes (i.e. from AMR_12.20 to AMR_SID in Table 1. ).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 18 / 103
103
1.1.5 Role of the NSS.
1.1.5.1 Channel Assignment.

For outgoing and terminated calls, the MS may indicate to the MSC at call set up, which speech version(s)
it supports, and among them the speech v3. The MSC then selects a list of pools according to the MS
preferences and the serving BSC capabilities. It finally assigns a channel, for which the choice upon the
speech version is left open to the BSC. When the channel assignment procedure has been completed,
the RCP is informed of the speech version chosen by the MS, and updates a CDR when it is the speech
v3.
1.1.5.2 RAB Assignment
The UMTS RAB Assignment procedure is functionally equivalent to the GSM Channel Assignment proce-
dure. The characteristics of the RAB assigned can be configured according to the operator’s needs (i.e.
selected codec modes, DTX and QoS parameters).
1.1.5.3 Handover and relocation
1.1.5.3.1 Within GSM
When the BSS performs autonomously an internal handover, this is signalled to the RCP. The new speech
version in use may be the version 3. Some internal handovers may be related to AMR change of rate only.
For external handovers, the new channel at the serving BSC depends on the serving BSC speech v3 sup-
port and characteristics, and on the MS preferences related to speech v3 which are known at the control-
ling MSC. This allows to pursue a call with speech v3 through handovers.
1.1.5.3.2 Within UMTS
The target MSC relocates the RAB with characteristics which can be chosen at the target MSC according
to the operator’s needs (i.e. selected codec modes, DTX and QoS parameters).
1.1.5.3.3 From GSM to UMTS
This case is similar to the former one, the characteristics of the relocated RAB can be chosen at the target
MSC according to the operator’s needs (i.e. selected codec modes, DTX and QoS parameters).
1.1.5.3.4 From UMTS to GSM
The new channel assigned at the target BSC depends on the serving BSC characteristics, and on the MS
preferences which are known at the controlling MSC from the call establishment. This is similar to the GSM
to GSM case.
1.1.5.4 Dual services
Dual services are relevant to the GSM case only.
When a dual service (speech and data) has been requested the processing is not different from the speech
only case, except that the selected pools must satisfy both the MS preferred speech version(s), and the
required data service.
When the call moves or reverses to a speech phase, the in–call modification procedure includes a channel
assignment which is not different from an initial assignment.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 19 / 103
103
1.1.5.5 Control over the codec modes
In UMTS, the RAB is assigned with a subset of or all the codec modes supported by the Tc. The Tc supports
all the 3GPP defined codec modes. The subset can be chosen according to the operator’s needs.
In GSM a control is offered as described below.
The possibility is offered to the network operator, when compatible with the MS capabilities, to have a con-
trol over the codec modes, half or full rate only and forbid AMR handovers, or allocate channels with a
preference between full and half rate and allow AMR handovers. This applies to the assignment, handover
and modify procedures.
This is possible at the BSS level through MMCs related to the management of the BSC (CREBSC and
MODBSC) by the MSC.
All the various combinations of BSC characteristics, offer the network operator, at the geographical level
of a BSC coverage and while the network evolves in time, the possibility to either privilege AMR over other
speech versions or to be neutral, and/or to favor one rate over the other, and/or to allow/forbid handovers
between rates.
This finally permits to privilege a dense coverage over quality (resp. quality over dense coverage) or to
find and equilibrium. In time, when a great majority of MSs will support AMR, with appropriate BSC charac-
teristics it will be possible to use this feature almost exclusively.
1.1.6 DTX aspects.
The AMR codec supports the use of DTX.
In UMTS the use of DTX can be configured according to the operator’s needs.
1.1.7 TFO
The introduction of TFO is of no consequences for the NSS because it only implies inband signalling
between two AMR codecs.
1.1.8 Charging aspects.
An indication is provided in the CDRs when speech v3 has been selected upon channel assignment
completion.
Other provided information is whether the choice between full and half rate has been left to the BSS, with
or without a preference from the NSS, and which rate has finally been chosen.
Although the speech version and rate may change upon handover, they are not updated in the CDR.
1.1.9 MS–MS calls
This section applies to the GSM case only.
In case of MS–MS call with MSs belonging to the same PLMN, depending on the functional options
F–RM–011 and F–RM–012, speech v1 can be forced to Full Rate, this to prevent from having Half Rate
1AA 00014 0004 (9007) A4 – ALICE 04.10
channels both on calling and called sides, which would result in poor speech quality.
ED 01
CIT AAC033638800DS En 20 / 103
103
This possibility is not kept with speech v3 because the AMR has been designed to enable internal hand-
overs when speech quality is found not sufficient. In situations where AMR handovers are forbidden or not
possible, AMR HR outclasses speech v1 HR.
1.1.10 International calls
This section applies to the GSM case only.
In case of international call (i.e. call routed toward or from an international gateway), depending on the
functional option F–RM–010, speech v1 can be forced to Full Rate, this to prevent from having a poor
speech quality.
This possibility is not kept with speech v3 because of the same reason as stated above.
1.1.11 Circuit Pool.
The notion of Pool is relevant only in the GSM case.
The management of circuit pools in the MSC depends on a functional option (i.e. F–RM–007).
When the circuit pool management is not supported, and when speech v3 is offered, then all the circuits
between MSC and BSC should support speech v3.
When circuit pool management is supported, then only some pools are capable of handling speech v3.
Pools have been added in the GSM recommendations for the support of speech version 3. A list of them
is given in the following table. They are selected for speech only or dual services with standard switched
data services.
1.1.12 Service Handover.
Service Handover feature enables the operator to control or prompt 3G³2G handover of speech calls
according to the country and PLMN of origin of the roamer (MCC+MNC of the subscriber’s IMSI). It is also
applicable to its own subscribers in their home PLMN.
Low bandwidth services like speech could for instance be redirected towards GSM for the operator’s own
subscribers, while the redirection could depend on inter–PLMN charging agreements for other roamers.
The control is ensured by the UTRAN, based on information provided by the RCP in RAB assignment or
relocation. There may be no control at all, or the control can be:
– handover should be performed,
– handover should not be performed,
– handover shall not be performed.
The value of the control is provided by a table managed by MMC MODSHO.
The provision of the feature needs the activation of a functional option (i.e.F–HO–014).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 21 / 103
103
Pool Coding Supported channels and speech coding algorithms
circuit pool number 23 0001 0111 FR speech v3

HR speech v3

FR data (12, 6, 3.6kbps)
HR speech v3

FR speech v2
FR speech v3
HR speech v3

FR speech v2
FR speech v3
HR speech v1
HR speech v3
HR data (6, 3.6kbps)
Table 6. Basic Circuit pools with speech v3.
1.2 Functional options
The conditions on the provision of the different speech versions by the NSS are as follows.
a) GSM Speech version 1 is always provided in Full Rate, and in Half Rate when F–RM–001 is active.
b) The provision of GSM Speech version 2 depends on a functional option:
• F–RM–005 ”Speech multiversion support”
If this option is active, the MSC handles the speech version indications.
c) GSM AMR depends on a functional option:
• F–RM–013 Support of speech version 3 (AMR).
This option is only meaningful when F–RM–005 is already active.
When it is active, speech version 3 is supported by the NSS. This functionality is also known
as AMR standing for Adaptative Multi–Rate.
When the MS supports speech v3, an ordered list of speech versions, including speech v3 when
the necessary resources are available, is sent to the BSC by the MSC at channel assignment
and handover. The ordering depends on BSC related MMCs. This enable either to force a Full
Rate only mode, or to force a Half Rate only mode, or else to allow both rates. It is also possible
to favor speech v3 over other speech versions. In this way miscellaneous operators needs,
related to covered areas, can be satisfied.
1AA 00014 0004 (9007) A4 – ALICE 04.10
The support of AMR is available whatever the state of F–RM–007. If is not active, all the trans-
coders should be equipped with speech v3 capabilities.
ED 01
CIT AAC033638800DS En 22 / 103
103
Otherwise, when F–RM–013 is not active, the speech version 3 MS capabilities are ignored by
the NSS and therefore cannot be used. In that case Full Rate is always preferred to Half Rate
and speech version 2 is preferred to version 1.
This option only applies to the RCP.

• F–CG–056 Speech version 3 (AMR) charging.
This option is only meaningful when F–RM–005 and F–RM–013 are already active.
When it is active, the CDR is updated, at channel assignment time, with speech version 3 when
chosen by the MS and with indications on the choices between Full Rate and Half Rate which
had been left to the BSC and what rate it has retained.Although, the speech version may
change. the CDR is not updated due to handover
Furthermore, the GSM AMR makes use of the following options:
• F–RM–001 ”Simplified handling of half–rate channels”
If this option is active, allocation of a half–rate channel is possible.
This option should always be active when F–RM–013 is.
• F–RM–007 ”Circuit pool management”
The activation of this option is needed to treat the circuit pools associated with the BSCs. When
this option is not active all the transcoders must support speech version 3.
• F–RM–008 ”Circuit pool management in MMC RCP”
The activation of this option is needed to manage the circuit pools associated with the BSCs
in the MMC in charge of the BSC administration.
This option is not yet offered.
• F–RM–005 ”Speech multiversion support”
The option F–RM–005 must also be active. Actually when F–RM–005 is not active only the
speech version 1 FR and HR are taken into account.
d) UMTS speech (UMTS AMR version 1) is always provided.
e) UMTS speech (UMTS AMR version 1) is charged depending on a functional option.
• F–CG–062 ”UMTS Speech charging (UMTS AMR version 1)”
When it is active, the CDR ’Chosen speech version’ is updated at Radio Access Bearer assign-
ment for UMTS speech calls with an indication on the use of ”UMTS AMR version 1”. Although
the used speech codec may change, particularly after a handover to a GSM network, the indica-
tion is not updated.
When it is not active, the CDR is updated for speech calls at Radio Access Bearer assignment
with a default value which is not significant.
1AA 00014 0004 (9007) A4 – ALICE 04.10
f) Service Handover depends on a functional option.
ED 01
CIT AAC033638800DS En 23 / 103
103
• F–HO–014 ”Service Handover (UMTS to GSM)”
When the option is active the Service Handover feature is applied to speech calls for roamers
depending on the MCC+MNC of their IMSI.
1.3 Involved network elements
Only the RCF is involved with the function.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 24 / 103
103
2 DETAILED DESCRIPTION AND SCENARIOS
In the following scenarios the Network stands for a PSTN, an ISDN or another PLMN. The AMR related
treatments are effective only when the option F–RM–013 is active.
2.1 Channel assignment
The scenarios described here are summarized, to get a thorough description see document RM Ref.[16].
2.1.1 Channel Assignment in the MOC case.
MS
BSC RCP SSP
• • • • Network
• • • •
Signalling channel establish-

ment, authentication...
(1)
SETUP
(2)
CALL PROCEEDING (GSM–BC)
(3)
CREATE
(4)
RETRIEVE RESULT
(5)
ASSIGNMENT REQUEST
(6)
ASSIGNMENT COMMAND
(7)
ASSIGNMENT COMPLETE
(8)
ASSIGNMENT COMPLETE
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 6. Channel Assignment in the MOC case.
ED 01
CIT AAC033638800DS En 25 / 103
103
(1) After the signalling link establishment, authentication procedure and controls at the VLR, the MS may
request for a speech Teleservice, at version 3. To that purpose the bearer capability (GSM–BC) of the
SETUP message contains a list of preferred speech version, and among them speech version 3.
If the SETUP message requests dual services the SETUP carries a second GSM–BC, one is for the
speech TS and the other for the data service.
(2) The request is acknowledged by the RCP. However, no indication is provided to the MS in the returned
GSM–BC of CALL PROCEEDING, upon the speech version that will be used.
(3) A leg is created by the SSP towards the BSS. To that purpose a CREATE request is sent to the SSP
by the RCF with a list of preferred pools.
If multiversion speech and speech version 3 are supported (i.e. options F–RM–005 and F–RM–013 are
active), and speech v3 was present in the list of preferred speech version of the received GSM–BC,
then the list of pools provided to the SSP will include support of speech v3 (i.e. the transcoders
associated to the CICs are equipped with AMR).
In case of dual services the list of selected pools additionally takes into account the data basic service
deduced from the associated received GSM–BC. Therefore the subset is common to the MS request and
the NSS capabilities, and this for both speech and data.
(4) The SSP returns back the CIC of the selected circuit and the identification of the pool where the circuit
has been allocated.
In cases where the SSP returns a pool which does not support speech v3, due to a configuration or
no free circuit left, speech v3 will not be proposed to the BSC in the ASSIGNMENT REQUEST.
(5) The ASSIGNMENT REQUEST sent to the BSC provides a list of the permitted speech versions,
and among them possibly speech v3. These versions are the versions supported by the pool selected
by the SSP. They are ordered according to the preferences of the MS. This ordering may however be
superseded by the RCP according to BSC characteristics set on AMR.
The ASSIGNMENT REQUEST also indicates to the BSS to allocate the TCH only in HR, or only in FR,
or leave to the BSC the choice between HR and FR, with or without a preference from the RCP, allowing
or forbidding handovers between HR and FR. These possibilities partly depend on MS preferences which
may be superseded by the RCP according to BSC characteristics set on AMR.
This enables to fully take advantage of the AMR codec possibilities.
(6) With the ASSIGNMENT COMMAND message the BSC forwards the request to the MS.
(7) Then the MS acknowledges the Traffic Channel assignment.
(8) The ASSIGNMENT COMPLETE message forwarded by the BSC indicates the chosen channel char-
acteristics and speech version. Afterwards the call is handled as described in document BCH Ref.[18].
If speech v3 has been chosen a dedicated indication is added in the CDR.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 26 / 103
103
2.1.2 Channel Assignment in the MTC case.
VMSC
MS
BSC RCP SSP

• • • •
(1)
IAM
(2)
Provide Instruction
Paging, Signalling channel
establishment, Authentica-
tion...
(3)
SETUP
(4)
CALL CONFIRMED
(5)
CREATE
(6)
RETRIEVE RESULT
(7)
ASSIGNMENT REQUEST
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 27 / 103
103
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
MS
01
•
•
•
BSC
(9)
(8)
•
ASSIGNMENT COMMAND
ASSIGNMENT COMPLETE
•
•
RCP
•
•
(10)
ASSIGNMENT COMPLETE
VMSC
SSP
Figure 7. Channel Assignment in the MTC case.
103
AAC033638800DS
Network
En
28 / 103
(1) The incoming IAM message at the VMSC indicates the request of a speech service, either through its
ISDN–BC or in the multinumberring case through the GSM–BC associated to the called MSISDN, or else
if none of them is found the speech TS is requested by default.
(2) The information of an incoming call is forwarded to the RCF with the Provide Instruction. Afterwards
the MS is paged, a signalling channel established and the authentication processed.
(3) Then the SETUP is sent with a GSM–BC requesting for the speech TS. The RCF provides no informa-
tion upon its speech version support.
(4) The MS returns back a CALL CONFIRMED message usually with a GSM–BC.
If no indication upon the MS speech versions capabilities or no GSM–BC is returned, speech version 1
is assumed.
Otherwise, the MS may indicate in the GSM–BC its preferences for speech versions similarly to the OC
case. To that purpose the bearer capability (GSM–BC) of the CALL CONFIRMED message contains a list
of preferred speech version, and among them possibly speech version 3.
(5) A leg is created by the SSP towards the BSS. A CREATE request is therefore sent to the SSP by the
RCF with a list of preferred pools.
If multiversion speech and speech version 3 are supported (i.e. options F–RM–005 and F–RM–013 are
active), and speech v3 was present in the list of preferred speech version of the received GSM–BC,
then the list of pools provided to the SSP will include support of speech v3 (i.e. the transcoders
associated to the CICs are equipped with AMR).
(6) The SSP returns back the CIC of the selected circuit and the identification of the pool where the circuit
has been allocated.
In cases where the SSP returns a pool which does not support speech v3, due to a configuration or
no free circuit left, speech v3 will not be proposed to the BSC in the ASSIGNMENT REQUEST.
(7) The ASSIGNMENT REQUEST sent to the BSC provides a list of the permitted speech versions,
and among them possibly speech v3. These versions are the versions supported by the pool selected
by the SSP. They are ordered according to the preferences of the MS. This ordering may however be
superseded by the RCP according to BSC characteristics set on AMR.
The ASSIGNMENT REQUEST also indicates to the BSS to allocate the TCH only in HR, or only in FR,
or leave to the BSC the choice between HR and FR, with or without a preference from the RCP, allowing
or forbiding AMR handovers. These possibilities partly depend on MS preferences which may be super-
seded by the RCP according to BSC characteristics set on AMR.
This enables to fully take advantage of the AMR codec possibilities.
(8) With the ASSIGNMENT COMMAND message the BSC forwards the request to the MS.
(9) Then the MS acknowledges the Traffic Channel assignment.
(10) The ASSIGNMENT COMPLETE message forwarded by the BSC indicates the chosen channel char-
acteristics and speech version. Afterwards the call is handled as described in document BCH Ref.[18].
If speech v3 has been chosen a dedicated indication is added in the CDR.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 29 / 103
103
2.2 RAB assignment
2.2.1 RAB assignment in the MOC case

In this scenario the SSP covers both the switch and the Tc which is on the contrary to the GSM casefunc-
tionaly part of the MSC.
MS
RNC RCP SSP
• • • • Tc Network
• •
(1)
SETUP
(2)
CALL PROCEEDING (GSM–BC)
(3)
CREATE
(4)
RAB ASSIGNMENT REQUEST
(5)
ERQ Establishment Request
(6)
ECF Establishment Confirm
(7)
RAB ASSIGNMENT RESPONSE
Figure 8. RAB Assignment in the MOC case.
(1) The MS requests for the speech Teleservice with the ITC field of the bearer capability (GSM–BC) of
the SETUP message set to speech.
All the other speech related fields of the GSM–BC are not analysed but memorised in case of a later
1AA 00014 0004 (9007) A4 – ALICE 04.10
request for a handover to a 2G network.
ED 01
CIT AAC033638800DS En 30 / 103
103
(2) The request is acknowledged by the RCP through CALL PROCEEDING which contains a GSM–BC.
The RCP however removes the indications provided by the MS on its support of speech versions in a GSM
network because they are only relevant in the MS to MSC way.
(3) A CREATE operation is sent to the SSP. Upon this operation the SSP expects to receive an incoming
AAL2 connection request from the RNC.

The TCinfo parameter is intended for the Tc and therefore forwarded by the SSP. It indicates that the Tc
will be used in SMpSDU. After having been set in SMpSDU the Tc awaits for its Iu UP initialisation by the
RNC.
(4) The RAB ASSIGNMENT REQUEST sent to the RNC is built according to a subset of the codec modes
supported by the Tc or all of them. The Tc supports all the UMTS AMR codec modes defined in 3GPP
26.102. The parameters associated with the codec modes (i.e. SDU size, Subflow SDU size) are system
parameters.
One RFC is associated to each codec mode, for each RFC three subflows are defined, one sublow being
associated to one AMR bit protection class. For some subflows, the SDU size may be equal to zero.
The message also requests for the Iu UP ’Support Mode for predefined SDU size’ (SMpSDU). An SDU
size is associated to each codec mode according to the rate. The sum of the three subflow SDU sizes
corresponding to the three classes equals the predefined SDU size.
(5) AAL2 establishment, not described here, see RANAPI Ref.[26].
(6) AAL2 establishment, not described here, see RANAPI Ref.[26].
(7) After AAL2 has been established the RNC runs the Iu UP initialisation procedure (see 3GPP TS 25.415
Ref.[8]). This procedure provides the Tc with the RAB parameters: RFC identifiers, Subflow SDU size and
the means to deduce the time interval between PDU emission. The parameters represent a common sub-
set between the capabities of the MS, the RNC, and the Tc. Upon completion of the procedure the Iu UP
connection is established between RNC and Tc.
The RAB ASSIGNMENT RESPONSE is sent by the RNC after the Iu UP connection has been success-
fully established.
The speech TS is now fully available.
2.2.2 RAB assignment in MTC case
The principle is identical to the MOC case.
The RCP requests for speech with a SETUP message with the ITC field of the GSM–BC set to speech.
The MS acknowledges with CALL CONFIRMED which contains a GSM–BC which indicates its support
of the GSM speech versions.
The RAB is assigned identically to the MOC case.
The Tc is always located at the serving MSC.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 31 / 103
103
2.3 GSM Handover and UMTS relocation.
The scenarios described here are summarized, to get a thorough description see document HO Ref.[17].
2.3.1 GSM Internal Intra–Cell Handover
This handover occurs between channels belonging to the same cell. At this occasion changes in the chan-
nel resources such as channel rate (HR/FR) and speech version, may happen. However the support of
this procedure by the BSS is optional.
An overhead due to an increased signalling trafic may be brought to the MSC by these handovers.
MS
BSC RCP SSP
• • • •
• • • •
Intra BSS
Handover
(1)
HANDOVER PERFORMED
Figure 9. Intra BSS Handover
(1) The HANDOVER PERFORMED message may indicate a change in the chosen speech version and
channel rate, half or full.
The new chosen speech may be version 3.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 32 / 103
103
2.3.2 GSM Internal Inter–Cell Handover
This handover occurs between channels belonging to different cells of the same BSS. At this occasion
changes in the channel resources such as channel rate (HR/FR) and speech version, may happen. How-
ever the support of this procedure by the BSS is optional.

From the NSS standpoint there is no difference with the Internal intra–Cell Handover. A HANDOVER PER-
FORMED message may be received indicating a chosen speech version v3.
However, an increased rate of handovers, due to AMR handovers may increase the signalling throughput.
2.3.3 GSM External Intra–MSC Handover
The MS is under a serving BSS control and is transfered to the control of a target BSS. This scenario corre-
sponds to the case where the target and serving cells are both controlled by the same MSC.
serving target
MS
BSC BSC RCP SSP
• • • • • •
• • • • • •
speech v3 is
used
(1)
HANDOVER REQUIRED
(2)
CREATE
(3)
RETRIEVE RESULT
(4)
HANDOVER REQUEST
(5)
HANDOVER REQUEST ACKNOWLEDGE
(6)
HANDOVER COMMAND
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 33 / 103
103
serving target
MS
BSC BSC RCP SSP
• • • • • •
• • • • • •
The fixed net-

work side leg is
connected to
the target BSC
leg
(7)
HANDOVER ACCESS
(8)
HANDOVER DETECT
(9)
HANDOVER COMPLETE
channel of and leg to serving BSS are released
Figure 10. Intra MSC Handover.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 34 / 103
103
(1) The HANDOVER REQUIRED message requires from the MSC to carry out a handover for a MS. THE
message provides information on the currently used speech version and channel. It also may request the
MSC to transfer information transparently to the target BSC (”Old BSS to New BSS information” IE).
When speech v3 is used this IE gives useful indications to the target BSC on the AMR codec present
mode.
(2) If the RCP can satisfy the request for handover, a leg is created by the SSP towards the target BSS.
To that purpose a CREATE request is sent to the SSP by the RCF with a list of preferred pools.
The list of preferred pools is computed in the same way as it has originally been done in the assignment
procedure. That is to say, the received GSM–BC is taken into account (i.e. the preferred speech versions,
and possibly speech v3). In case of dual services the list of selected pools additionally takes into account
the data service.
(3) The RCF gets back the selected CIC and pool identification from the RETRIEVE RESULT sent by the
SSP.
(4) Then a HANDOVER REQUEST message is sent to the target BSC. It contains the selected CIC and
the informations received from the serving BSC; namely the ”Old to New BSS information” , the used
speech version and current channel type, if they have been previously received in HANDOVER
REQUIRED.
This message also carries a Channel type IE which is built similarly to the assignment case.
The Channel type IE carries a list of the permitted speech versions, and among them possibly
speech v3. These versions are the versions supported by the pool selected by the SSP. They are ordered
according to the preferences of the MS. This ordering may however be superseded by the RCP according
to BSC characteristics set on AMR.
It also indicates to the BSS to allocate the TCH only in HR, or only in FR, or leave to the BSC the choice
between HR and FR, with or without a preference from the RCP, allowing or forbiding AMR handovers.
These possibilities partly depend on MS preferences which may be superseded by the RCP according
to BSC characteristics set on AMR.
This, in addition to the assignment procedure, enables to fully take advantage of the AMR codec possibili-
ties.
(5) If the target BSS can fulfill the request it sends back a HANDOVER REQUEST ACKNOWLEDGE mes-
sage. However, the target BSC may chose new characteristics for the channel and another speech ver-
sion. If so, it is indicated in the message.
Futhermore the message contains the whole HANDOVER COMMAND message which will be sent later
on to the MS.
(6) The HANDOVER COMMAND message provides the MS with the target channel identity chosen by
the target BSS and a handover reference in order for the this BSS to recognize the MS. It is still sent to
the MS through the serving BSS.
(7) The MS tries to access the target BSS.
(8) The HANDOVER DETECT is sent by the BSS when it has recognized the handover reference number.
(9) When the MS has successfully established a communication path with the new BSS then the latter
sends a HANDOVER COMPLETE messages.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 35 / 103
103
2.3.4 External Inter–MSC Handover within a GSM PLMN
The related scenarios correspond to the various combinations where the controlling, target and serving
MSCs may be all or partly different network nodes.
The scenarios do not differ when speech v3 functionality is involved, they are not further described
here. See document HO Ref. [17] for full details. When F–RM–013 is active the difference lies in the
Channel type IE of the HANDOVER REQUEST message exchanged between the target MSC and BSC,
or between MSCs.
The difference comes from the fact that, in some cases, the target MSC may not know the GSM–BC, and
in particular the MS preferred speech versions, including speech v3.
The target MSC sends a HANDOVER REQUEST message to its target BSC. The rule applied to make
this message is as follows:
– when F–RM–013 is active, the HANDOVER REQUEST message sent to the target MSC contains
a faithful picture of the MS preferred speech versions, regardless of any BSC characteristics
related to AMR.
– at the target MSC, when F–RM–013 is active, the Channel type IE is built from the received Channel
type IE and the target BSC characteristics related to AMR. The pool list also depends on the
received Channel type IE.
– when F–RM–013 is not active, the processing is as described in document HO Ref. [17] (i.e. the
Channel type IE is modified to privilege FR speech v1 prior to be sent to the target MSC, the target
MSC does not modify the received Channel type IE).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 36 / 103
103
2.3.5 UMTS relocation
2.3.5.1 3G³3G relocation intra–MSC

serving
target
RNC RCP RNC

• • • • • •
• •
(1)
RELOCATION REQUIRED
(2)
RELOCATION REQUEST
Figure 11. 3G ³ 3G relocation – intra MSC
(1) The relocation procedure is triggered by the reception of a RELOCATION REQUIRED message from
the SRNS. The message identifies a target RNC. It carries a Source RNC to target RNC container.
(2) A RELOCATION REQUEST is then sent to the target RNC. It transparently forwards the Source RNC
to target RNC container. It requests for a single RAB defined by a RAB parameters IE defined as in the
RAB assignment case.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 37 / 103
103
2.3.5.2 3G³3G relocation inter–MSC
serving target
RNC RCP RCP RNC

• • • • • • • •
• • • •
(1)
RELOCATION REQUIRED
(2)
PREPARE HANDOVER REQUEST
(3)
RELOCATION REQUEST
Figure 12. 3G ³ 3G relocation – inter MSC
(1) Same as in the above intra–MSC case.
(2) The request for relocation is forwarded to the target MSC thanks to a MAP PREPARE HANDOVER
REQUEST message. It contains an AN–APDU parameter which contains a RELOCATION REQUEST
message. The RAB parameters of RELOCATION REQUEST include all the codec modes [4.75kbit/s –
12.2kbit/s], without DTX.
(3) On reception of the PREPARE HANDOVER REQUEST message, the RAB parameters of included
RELOCATION REQUEST are ignored.The RAB parameters sent to the RNC in RELOCATION
REQUEST are generated in the target MSC depending on local configuration of DTX and codec modes
(i.e. identical to the RAB assignment case).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 38 / 103
103
2.3.5.3 3G³2G relocation intra MSC
serving
target
RNC RCP BSC

• • • • • •
• • • •
(1)
RELOCATION REQUIRED
(2)
HANDOVER REQUEST
Figure 13. 3G ³ 2G relocation – intra MSC
the SRNS. The message identifies a target BSC. It carries a Old BSS to new BSS Information IE with
AMR related information.
(2) The MSC then sends a HANDOVER REQUEST message to the target BSC. It carries a Channel type
IE which contains a list of permitted speech versions and a preference between HR and FR, which
depend similarly to the pure GSM case on the preferences set on the BSC, on the MS signalled GSM–
BC and on the pool availability. It also forwards transparently the Old BSS to new BSS Information
IE. Some information as Current Channel Type 1 IE or Speech Version (Used) IE which is not relevant
in UMTS are not transmitted.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 39 / 103
103
2.3.5.4 3G³2G relocation inter MSC
serving target
RNC RCP RCP BSC

• • • • • • • •
• • • • • •
(1)
RELOCATION REQUIRED
(2)
(3)
HANDOVER REQUEST
Figure 14. 3G ³ 2G relocation – inter MSC
the SRNS. The message identifies a target BSC. It carries a Old BSS to new BSS Information IE with
AMR related information.
(2) The PREPARE HANDOVER REQUEST message includes a HANDOVER REQUEST. It carries a
Channel type IE which contains a list of permitted speech versions which, similarly to the pure GSM
case, only depends on the MS signalled GSM–BC. When the MS supports multiple speech versions,
the Channel type IE indicates no preference between HR and FR. The Old BSS to new BSS Information
IE is also forwarded transparently. Some information as Current Channel Type 1 IE or Speech Version
(Used) IE which are not relevant in UMTS are not transmitted.
(2) The target MSC then sends a HANDOVER REQUEST message to the target BSC. It carries a Channel
type IE which is deduced from the received Channel type IE and of which permitted speech versions
and preference between HR and FR depend, similarly to the pure GSM case, on the preferences set
on the BSC, and on the pool availability. It also forwards transparently the Old BSS to new BSS
Information IE. Some information as Current Channel Type 1 IE or Speech Version (Used) IE which
is not relevant in UMTS are not transmitted.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 40 / 103
103
2.3.5.5 2G³3G handover intra MSC
serving
target
BSC RCP RNC

• • • • • •
• • • •
(1)
HANDOVER REQUIRED
(2)
RELOCATION REQUEST
Figure 15. 2G ³ 3G handover – intra MSC
(1) The handover is triggered at the MSC on reception of a HANDOVER REQUIRED message from the
BSC. It contains a Source RNC to target RNC transparent information IE.
(2) The RCP then sends a RELOCATION REQUEST message to the target RNC. The Source RNC to
target RNC transparent information IE is passed transparently. The Current Channel Type 1 IE and
Speech version (Used) IE that may have been received from the BSC are ignored. The RELOCATION
REQUEST requests for a single RAB defined by a RAB parameters IE depending on configuration of DTX
and codec modes (i.e. identical to the RAB assignment case. It also requests for the SMpSDU Iu mode
needed for speech.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 41 / 103
103
2.3.5.6 2G³3G handover inter MSC
serving target
BSC RCP RCP RNC

• • • • • • • •
• • • • • •
(1)
HANDOVER REQUIRED
(2)
(3)
RELOCATION REQUEST
Figure 16. 2G ³ 3G handover – inter MSC
(1) The handover is triggered at the MSC on reception of a HANDOVER REQUIRED message from the
BSC. It contains a Source RNC to target RNC transparent information IE.
(2) The PREPARE HANDOVER REQUEST message includes a HANDOVER REQUEST. It carries a
Channel type IE which contains a list of permitted speech versions which, similarly to the pure GSM
case, only depends on the MS signalled GSM–BC. When the MS supports multiple speech versions,
the Channel type IE indicates no preference between HR and FR. The Source RNC to target RNC
transparent information IE is also forwarded transparently. Some information as Current Channel Type
1 IE or Speech Version (Used) IE which are not relevant in UMTS are not transmitted.
(3) The target RCP then sends a RELOCATION REQUEST message to the target RNC. The Source RNC
to target RNC transparent information IE is passed transparently. The Current Channel Type 1 IE and
Speech version (Used) IE that may have been received from the BSC are ignored. The RELOCATION
REQUEST requests for a single RAB defined by a RAB parameters IE based on local configuration of
DTX and codec modes (i.e. identical to the RAB assignment case). It also requests for the SMpSDU Iu
mode needed for speech.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 42 / 103
103
2.3.6 In–call modification (successful)
MS
BSC RCP SSP
• • • •
A data transfer is inprogress.
(1)
MODIFY
(2)
ASSIGNMENT REQUEST
(3)
ASSIGNMENT COMPLETE
(4)
MODIFY COMPLETE
call is in the speech phase,

possibly with speech v3.
Figure 17. In–call modification (successful).

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 43 / 103
103
(1) A MODIFY message is received by the RCF while a data service is in progress. The message carries
a GSM–BC which must correspond to a mode already negotiated at call set up, speech in the present case.
The GSM–BC is analyzed, if compatible a new channel is assigned for the speech TS.
(2) The ASSIGNEMENT REQUEST is sent to the BSS. The characteristics are the same as for the initial
assignment case.
(3) The ASSIGNEMENT COMPLETE is returned by the BSS when the allocation has been sucessful. The
characteristics are the same as for the initial assignment case.
(4) The RCF sends back to the MS a MODIFY COMPLETE with the GSM–BC received in the MODIFY.
N.B. The In Call modification procedure is not applicable to UMTS.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 44 / 103
103
2.3.7 In–call modification (rejected)
MS
BSC RCP SSP

• • • •
(1)
MODIFY
(2)
MODIFY REJECT
The data phase is pursued.
Figure 18. In–call modification (rejected due to new received GSM–BC).
The GSM–BC is analyzed, a list of pools is deduced. However none of these pools matches the current
pool with regard to speech only, the modification is therefore rejected.
(2) The MODIFY REJECT message sent back to the MS, carries the currently used GSM–BC (i.e. which
corresponds to a data service) and invokes the cause ”Bearer capability not authorized”. The call follows
on in the speech phase.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 45 / 103
103
MS
BSC RCP SSP
• • • •
(1)
MODIFY
(2)
ASSIGNMENT REQUEST
(3)
ASSIGNMENT FAILURE
(4)
MODIFY REJECT
The data phase is pursued.
Figure 19. In–call modification (rejected due to assignment failure).
The GSM–BC is analyzed, a list of pools is deduced.
(2) The ASSIGNEMENT REQUEST is sent to the BSS. The characteristics are the same as for the initial
assignment case.
(3) The ASSIGNEMENT FAILURE is returned by the BSS after the channel allocation failed.
(4) The MODIFY REJECT message sent back to the MS, carries the currently used GSM–BC (i.e. which
corresponds to a data service) and invokes the cause ”Bearer capability not authorized”.
1AA 00014 0004 (9007) A4 – ALICE 04.10
N.B. The In Call modification procedure is not applicable to UMTS.
ED 01
CIT AAC033638800DS En 46 / 103
103
3 DESCRIPTION OF INTER–ENTITIES MESSAGES
This chapter lists the messages and Information Elements involved with the function. However, their
descriptions are only partially provided because restricted only to those fields directly necessary to the
function. For a thorough picture see the related recommendations 3GPP TS 24.008 Ref. [6] and 3GPP
TS 48.008 [14].
3.1 RCF – MS
3.1.1 SETUP
In the MOC case, when speech is requested, the MS may indicate in the GSM–BC of the SETUP message
the different speech versions it supports, hence its support of AMR.
MS³MSC: SETUP
information element type length
GSM–BC (Bearer Capabilities) M
Table 7. MSC–MS: SETUP message
If the MS requests the speech teleservice it is indicated in the Information Transfer Capability (ITC) field
(bits 321) of octet 3. In that case octets 4, 5, 5a, 5b, 6, 6a, 6b, 6c, 6d, 6e, 6f and 7 are not included by the
MS. Were they present the RCF would ignore them.
octet 3 meaning
bits 3 2 1 Information transfer capability
000 speech
Table 8. GSM–BC – Speech Teleservice request.
In UMTS the ITC is sufficient to request for speech. The other speech related parameters described here
are still valid, but only useful for handovers with 2G networks.
When octet ”3a etc” is not present, only speech version 1 is supported by the MS, FR and optionally HR
with a preference. The preference is given by octet 3, bits 76 ’radio channel requirement’ field (bit 76 mean-
ing either ”only FR v1 supported”, or ”dual rate speech v1 MS, HR preferred”, or finally ”dual rate speech
v1 MS, FR preferred” ).
In case of octet ”3a etc” presence, then the MS supports at least speech version 1 FR, and optionally
speech version 1 HR with a preference between HR and FR. This is indicated in octet 3 bits 76 as described
in the following table.
The extension octets ”3a etc” are only checked if option F–RM–005 is active.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 47 / 103
103
octet 3 meaning
bits 7 6
01 The MS supports at least FR speech v1 but does not support HR

speech v1. The complete voice codec preference is specified in

octet(s) 3a etc.
10 The MS supports at least FR speech v1 and HR speech v1. The MS

has a greater preference for HR speech v1 than for FR speech v1. The
complete voice codec preference is specified in octet(s) 3a etc.
11 The MS supports at least FR speech v1 and HR speech v1. The MS

has a greater preference for FR speech v1 than for HR speech v1. The
complete voice codec preference is specified in octet(s) 3a etc.
Table 9. GSM–BC – Radio Channel Requirement field in octet 3, in case of octet 3a... extension.
Furthermore, when present, ”octet 3a” is instantiated as many times as different speech versions sup-
ported by the MS. The different octet 3a are listed in order of preference, first octet 3a being the best pre-
ferred. The possible values are given in the following table.
octet 3a etc meaning codec

bits 4 3 2 1
0000 GSM full rate speech version 1 1st generation
0010 GSM full rate speech version 2 EFR
0100 GSM full rate speech version 3 AMR
0001 GSM half rate speech version 1 1st generation
0101 GSM half rate speech version 3 AMR
other value speech version tbd
Table 10. GSM–BC – Speech versions in octet 3a.
N.B. ”octet 3a” has only a meaning in the MS ³ network direction and is ignored by the MS when
received. Therefore the RCF won’t provide it in the GSM–BC(s) it sends to the MS.
Any additional value to those defined in the above table has the meaning ”speech version tbd” and is
ignored by the RCF when received. If none of these versions is supported or known by the RCF the version
1 given in octet 3 is assumed (i.e. the MS supports FR version 1, optionally HR version and gives a prefer-
ence between HR and FR).
When there is a discrepancy between the octet(s) 3a contents and the Radio Channel Requirement, the
content of octets 3a prevails. This is notably the case when:
– RCR indicates speech FR v1 preferred rather than HR speech v1, and the two rates are found in
reverse order in octets 3a,
1AA 00014 0004 (9007) A4 – ALICE 04.10
– RCR indicates speech HR v1 preferred rather than FR speech v1, and the two rates are found in
reverse order in octets 3a,
– RCR indicates HR speech v1 is not supported and HR speech v1 is found in octets 3a,
ED 01
CIT AAC033638800DS En 48 / 103
103
If RCR indicates no other speech codec than v1 (i.e. there is no octet 3a), the present function cannot of
course be activated.
The values ”GSM full rate speech version 3” or ”GSM half rate speech version 3” are only taken into
account when the functional option F–RM–013 is active.

However, if bit 7 of octet 3a indicates ”octet used for other extension of octet 3”, then octet 3a is ignored.
If F–RM–013 is not active the RCF selects the first preferred speech version which is supported. If there
is none, speech version 1 as defined in octet 3 is assumed (i.e. the support of GSM full rate speech version
1 is mandatory).
In the MTC case, when speech is requested, the MSC sends a SETUP message to the MS, possibly with
a GSM–BC. As already indicated the GSM–BC octets ”3a etc...” are absent. See also BCTRL Ref. [25]
for further details.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 49 / 103
103
3.1.2 CALL CONFIRMED
In the MTC case, when speech TS has been requested in the GSM–BC of the SETUP message, the MS
may indicate in the GSM–BC returned in CALL CONFIRMED the different speech versions it supports,
and possibly speech v3, in the same way as for the MOC case already described. The analysis is there-
fore the same.
MS³MSC: CALL CONFIRMED
Table 11. MSC–MS: CALL CONFIRMED message
The GSM–BC IE follows the same pattern and analysis as for the SETUP message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 50 / 103
103
3.1.3 CALL PROCEEDING
In the MOC case, the MSC sends back this message to the MS to acknowledge the request for speech.
MSC³MS: CALL PROCEEDING
GSM–BC (Bearer Capabilities) O
Table 12. MSC–MS: CALL PROCEEDING message
When the RCP returns a GSM–BC, it is identical to the received one, except the octets ”3a etc” are not
present and bits 76 of octet 3 are set to 01.
On the conditions for returning a GSM–BC see BCH [18]. Basically, a GSM–BC is returned in the case
of an alternate service and no GSM–BC is returned when the speech teleservice alone has been invoked.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 51 / 103
103
3.1.4 MODIFY
The MS may send this message to switch the call from a data phase to a speech phase and vice versa
when a dual service has been negotiated at call set up.
MS³MSC: MODIFY
Table 13. MSC–MS: MODIFY message
When the request means to switch to speech the GSM–BC IE may contain speech versions preferences,
and possibly speech v3, similarly to what has already been described for the SETUP message. The IE
is analyzed following the same pattern.
The In Call Modification procedure is not applicable to UMTS, MODIFY cannot be received in that environ-
ment.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 52 / 103
103
3.1.5 MODIFY COMPLETE
If the in–call modification has been successful the RCF sends back to the MS a MODIFY COMPLETE mes-
sage.
MSC³MS: MODIFY COMPLETE
Table 14. MSC–MS: MODIFY COMPLETE message
The GSM–BC IE of this message corresponds to the new channel mode and is the same as the one
received in the MODIFY message, except for the speech versions preferences which are meaningless
in the MSC³ MS way and therefore should be removed from the received GSM–BC.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 53 / 103
103
3.2 RCF – BSC
3.2.1 CHANNEL ASSIGNMENT REQUEST

This message is sent from the MSC to request the BSC to assign a radio resource.
MSC³BSC: ASSIGNMENT REQUEST
Channel Type M 5–10
Circuit Identity Code O 3
Table 15. MSC–BSC: CHANNEL ASSIGNMENT REQUEST message.
The Channel Type IE contains the necessary information for the BSC to assign a channel. It is derived
from the GSM–BC IE negotiated at call set up. When AMR is used the informations it carries additionally
depend on the pool attributed by the SSP and whether .
The fields of the Channel Type IE are:
– Speech / data indicator,
– Channel rate and type,
– Permitted speech version indication / data rate + transparency indicator.
The Circuit Identity Code IE is included by the RCP, it corresponds to the circuit allocated by the SSP for
the leg towards the BSC.
When AMR is used the values of the Channel Type IE fields are as described in the next subsection.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 54 / 103
103
3.2.1.1 Channel Type IE description
8 7 6 5 4 3 2 1
Element identifier octet 1
Length octet 2
spare Speech/data indicator octet 3
Channel rate and type octet 4
ext Permitted speech version identifier octet 5
ext Permitted speech version identifier octet 5a
ext Permitted speech version identifier octet 5b
ext Permitted speech version identifier octet 5c
ext Permitted speech version identifier octet 5d
0 Permitted speech version identifier octet 5e
Figure 20. Channel Type IE.
octet 3 meaning
bits 4 3 2 1
0001 speech
Table 16. Channel Type IE – Speech / data indicator field.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 55 / 103
103
octet 4 meaning
bits 8 7 6 5 4321 code

0000 1000 8 Full rate TCH channel Bm.

Preference between the permitted speech versions for
full rate TCH as indicated in octet 5, 5a etc...
0000 1001 9 Half rate TCH channel Lm.

half rate TCH as indicated in octet 5, 5a etc...
0000 1010 A Full or Half rate TCH channel, Full rate preferred,
changes between full and half rate allowed also after first
channel allocation as a result of the request.
the respective channel rates as indicated in octet 5, 5a
etc...
0000 1011 B Full or Half rate TCH channel, Half rate preferred,
changes between full and half rate allowed also after first
etc...
0001 1010 1A Full or Half rate TCH channel, Full rate preferred,
changes between full and half rate not allowed after first
etc...
0001 1011 1B Full or Half rate TCH channel, Half rate preferred,
changes between full and half rate not allowed after first
etc...
0000 1111 F Full or Half rate TCH channel.

Preference between the permitted speech versions as
indicated in octet 5, 5a etc..., changes between full and
half rate allowed after first channel allocation as a result
of the request.
0001 1111 1F Full or Half rate TCH channel.

Preference between the permitted speech versions as
indicated in octet 5, 5a etc..., changes between full and
half rate not allowed after first channel allocation as a
result of the request.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 56 / 103
103
Table 17. Channel Type IE – Channel rate and type field.
When AMR is offered, the possibility to change between half and full rate, or to allow half or full rate only,
may depend on the operator specific requirements as expressed through BSC characteristics managed
by MMCs. Of course, that comes in addition to the MS and network possibilities.
octet 5, 5a, 5b... meaning

bits 7 6 5 4 3 2 1
000 0001 GSM speech full rate version 1
000 0101 GSM speech half rate version 1
001 0101 GSM speech half rate version 2 (1)
010 0101 GSM speech half rate version 3
Table 18. Channel Type IE – Permitted speech version indication field.
(1) GSM speech half rate version 2 code point is present in the recommendations but the corresponding
codec does not exist, it is therefore not used.
Octets 5a, 5b... are present depending on the extension bit of previous octet.
The speech versions available depend on the MS capabilities, the selected pool and the NSS offering.
Speech version 3 can only be present when F–RM–013 is active. In addition, the presence of half
and/or full rate speech v3 may depend on the operator specific requirements as expressed through BSC
characteristics managed by MMCs.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 57 / 103
103
3.2.2 CHANNEL ASSIGNMENT COMPLETE
This message is sent from the BSC to the MSC to indicate that the requested assignment request has been
completed by the BSS.
BSC³MSC: ASSIGNMENT COMPLETE
Chosen Channel O 2
Speech Version (Chosen) O 2
Table 19. MSC–BSC: CHANNEL ASSIGNMENT COMPLETE message
The Chosen Channel IE should always indicate ”speech (full rate or half rate)” when the function has been
invoked.
When the function is invoked the Chosen Channel IE is coded as follows:
octet 2 meaning
bits 8 7 6 5
1001 speech (full rate or half rate)
octet 2 meaning
bits 4 3 2 1
1000 Full rate TCH

1001 Half rate TCH
Table 20. Chosen Channel IE.
The Speech Version (Chosen) IE is included at least when the choice of speech version has been made
by the BSS. It is the case when a list of speech versions has been provided in the Channel Type IE of the
ASSIGNMENT REQUEST message.
However, it may happen that a BSC does not return the Speech Version (Chosen) IE even if it has made
a choice. In that case, the MSC assumes the chosen speech version to be the value indicated by the Per-
mitted speech version identifier (see above section 3.2.1.1) in octet 5 of Channel type IE of CHANNEL
ASSIGNMENT REQUEST.
Speech Version (Chosen) IE is coded in the same way as the permitted speech version identifier in the
Channel type IE.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 58 / 103
103
3.2.3 CHANNEL ASSIGNMENT FAILURE
This message is sent from the BSC to the MSC to indicate that the assignment procedure has been
aborted by the BSS due to a failure.
BSC³MSC: ASSIGNMENT FAILURE
Cause M 3–4
Table 21. MSC–BSC: CHANNEL ASSIGNMENT FAILURE message
The Cause IE may be ”requested speech version unavailable”.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 59 / 103
103
3.2.4 HANDOVER FAILURE
This message is sent from the BSC to the MSC to signal that due to a failure in the resource allocation
the handover has been aborted.
BSC³MSC: HANDOVER FAILURE
Cause M 3–4
Other values for Cause IE and related to the function are:

– ”requested speech version unavailable”.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 60 / 103
103
3.2.5 HANDOVER REQUEST
This message is sent by the MSC to the BSC to indicate that the MS is to be handed over to that BSC.
MSC³BSC: HANDOVER REQUEST
Channel Type M 5–10
Circuit Identity Code O 3
Cause O 3–4
Current Channel Type 1 O 2
Speech Version (Used) O 2
Old BSS to New BSS Information O 2–n
Source RNC to target RNC transparent information (UMTS) O n–m
Table 22. MSC–BSC: HANDOVER REQUEST message
The Channel Type IE gives the characteristics of the channel requested from the target BSC. The way
this IE is managed is described further in the document. When F–RM–013 is active it may depend on
the MS preferences and BSC characteristics.
The Circuit Identity Code IE is included by the RCP, it corresponds to the circuit allocated by the SSP
for the leg towards the target BSC.
The cause IE may be included by the MSC according to a BSC characteristic (see document HO Ref.[17]),
and it is equal to the one received in the HANDOVER REQUIRED message.
The Current Channel Type 1 IE is included by the MSC only when it has been previously received in a
HANDOVER REQUIRED message. In this case the sent IE is equal to the received one.
The Speech Version (Used) IE is included by the MSC only when it has been previously received in a
HANDOVER REQUIRED message. In this case the sent IE is equal to the received one.
The Old BSS to New BSS Information IE is included by the MSC only when it has been previously
received in a HANDOVER REQUIRED or RELOCATION REQUIRED message. In this case the sent IE
is equal to the received one.
The Source RNC to target RNC transparent information (UMTS) IE is the exact copy of the same IE
previously included by the BSS in a HANDOVER REQUIRED or by the RNC in a RELOCATION
REQUIRED. It is a container passed transparently to the tartget RNC by the CN. It may carry speech
related information.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 61 / 103
103
3.2.6 HANDOVER REQUEST ACKNOWLEDGE
This message is sent by the BSC to the MSC to indicate that the request to support a handover at the target
BSS can be supported.
BSC³MSC: HANDOVER REQUEST
Chosen Channel O 2
Table 23. MSC–BSC: HANDOVER REQUEST ACKNOWLEDGE message
The Chosen Channel IE is included if the choice upon channel type/rate was done by the BSS.
The Speech Version (Chosen) IE is included if the choice was done by the BSS. It may be speech v3
if it has been previously given as Permitted speech version.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 62 / 103
103
3.2.7 HANDOVER REQUIRED
This message is sent to the MSC when a handover is required by the BSC for a MS which already has
a dedicated resource assigned.
BSC³MSC: HANDOVER REQUIRED
Cause M 3–4
Current Channel Type 1 O 2
Speech Version (Used) O 2
Old BSS to New BSS Information O 2–n
Source RNC to target RNC transparent information (UMTS) O n–m
Table 24. MSC–BSC: HANDOVER REQUIRED message
The Current Channel Type 1 IE, however optional, should always be included.
When the Speech TS is in use, the Speech Version (Used) IE should be always present. It may be speech
v3.
The Old BSS to New BSS Information IE is passed transparently by the MSC from the BSC.
If the present codec is an AMR codec, this IE may inform the target BSS of the current multirate
codec configuration.
The Source RNC to target RNC transparent information (UMTS) IE is included by the BSS in case of
handover with UMTS. It is a container passed transparently to the tartget RNC by the CN. It may carry
speech related information.
8 7 6 5 4 3 2 1
Element identifier octet 1
spare Speech version identifier octet 2
Figure 21. Speech Version IE.

1AA 00014 0004 (9007) A4 – ALICE 04.10
The Speech version identifier is coded in the same way as the Speech version identifier field in the Channel
type IE.
ED 01
CIT AAC033638800DS En 63 / 103
103
3.2.8 HANDOVER PERFORMED
This message is sent from the BSC to the MSC to indicate that the BSS has performed an internal hand-
over.
BSC³MSC: HANDOVER PERFORMED
Cause M 3–4
Chosen Channel O 2
Table 25. MSC–BSC: HANDOVER PERFORMED message
The Chosen Channel IE is included when the channel rate/type has changed during the handover.
The Speech Version IE is present when the speech version has been changed by the BSS. It may be
speech version 3, if it was a permitted choice offered to the BSC.
No check is performed on Chosen Channel IE and Speech Version IE.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 64 / 103
103
3.3 RCF–RNC
These messages apply to the UMTS case only.

3.3.1 RAB ASSIGNMENT REQUEST
This message is sent from the MSC to the SRNC to request the establishment of a RAB.
MSC³RNC: RAB ASSIGNMENT REQUEST
RABs to be setup or modified
>First setup or modify item
IE value comment
RAB ID
>>RAB parameters IE
IE value comment
Traffic Class conversa-

tional
RAB Asymmetry Indicator Symmetric

bidirectional
Maximum Bit Rate 12.2kbit/s maximum codec mode

from 4.75kbit/s to 12.2kbit/s
depends on selected codec(s)
Guaranteed Bit Rate 4.75kbit/s minimum codec mode

from 4.75kbit/s to 12.2kbit/s
Delivery Order delivery order

requested
Maximum SDU size 244 associated with maximum
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
codec mode
SDU parameters : Subflow 1 Class A
SDU Error Ratio 7*10–3 defined as PLMN data
Residual Bit Error Ratio 10–6 defined as PLMN data
Delivery of Erroneous SDU Yes for class A, error concealment

will be applied
SDU format information Parameter: 12.2kbit/s

1AA 00014 0004 (9007) A4 – ALICE 04.10
Subflow SDU size 81 depends on a PLMN data
ED 01
CIT AAC033638800DS En 65 / 103
103

SDU format information Parameter: 0kbit/s
RAB Subflow Combination Bit 0 0 kbit/s for DTX
Rate depends on a PLMN data
SDU parameters : Subflow 2 Class B
Residual Bit Error Ratio 10–3 defined as PLMN data
Delivery of Erroneous SDU No–error– SDUs are always delivered,

detection– without error indication.
consideration

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 66 / 103
103

SDU parameters : Subflow 3 Class C
Residual Bit Error Ratio 5*10–3 defined as PLMN data
Delivery of Erroneous SDU No–error– SDUs are always delivered,

detection– without error indication.
consideration

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 67 / 103
103

Transfer Delay 100ms indicates max delay for 95%
of the distribution of delay.
This IE is requested for a
Conv. Stream.
defined as PLMN data
Source Statictics descriptor speech For a Conv. Stream this IE

indicates the characteristics
of the source, which is
speech here.
>>User Plane Information
IE value comment
User Plane mode SMpSDU
>>Service Handover
IE value comment
Service Handover IE according Parameter to control hand-

F–HO–014 overs towards 2G.
and table
SHPLMN
Table 26. RAB ASSIGNMENT REQUEST
In the RAB ASSIGNMENT REQUEST described in above table, only the information relevant to speech
is provided. See document RANAPI Ref.[26] to get the whole description of the message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
The message definition according to 3GPP TS 25.413 Ref.[7] makes provisions for the establishment of
multiple RABs and for the release of RABs in case of multiple RABs already established.
ED 01
CIT AAC033638800DS En 68 / 103
103
Provision of speech necessitates a single RAB. That is why only the first section of the message ’RABs
to be setup or modified’ and ’First setup or modify item ’ are needed.
A RAB ID IE is filled by the RCP to later identify the acknowledgment. It is unique for a particular UE.
The values set on the RAB parameters IE are those which have been described in 1.1.4.4. They are taken
as default values.
The RAB parameters IE carries selected codec modes which constitute a subset of the codec modes
supported by the TC which actually supports all the UMTS AMR codec modes.
The selection of codec mode(s) among [4.75kbit/s to 12.2kbit/s] to be included in RAB parameters IE
depends on a PLMN data. At least one codec mode must be selected. By default all the codec modes
[4.75kbit/s to 12.2kbit/s] are selected. The values of the associated RAB Subflow SDU size IE are those
of Table 3.
RAB parameters IE describes each class A, B and C separately. Within each class the selected codec
modes are ordered from the highest to the lowest rate. This ordering is arbitrary.
Maximum Bit Rate is set to the highest bit rate of the selected codec mode(s) [4.75kbit/s to 12.2kbit/s].
Guaranteed Bit Rate can be set to any bit rate value among the selected codec mode(s) [4.75kbit/s to
12.2kbit/s]. The default chosen value is the lowest selected codec mode.
Maximum SDU size is set according to the highest bit rate of the selected codec mode(s). The value is
given in Table 3.
The RAB Subflow Combination Bit Rate and the 1.80kbit/s subflow (SID ) are present only when DTX
is applied, i.e. when DTXAMR PLMN data is set to ON. For SID the values of RAB Subflow SDU size
IE are those of Table 4.
The User Plane mode IE of the ’User Plane Information’ section of the message requests for the Iu UP
SMpSDU mode which is needed for speech.
The Service Handover IE may be present if option F–HO–014 is active, and is always absent otherwise.
When F–HO–014 is active, its presence, or value, depends on the table SHPLMN managed by MMC
MODSHO. See further in the document.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 69 / 103
103
3.3.2 RAB ASSIGNMENT RESPONSE
UTRAN³MSC: RAB ASSIGNMENT RESPONSE

RABs setup or modified
IE value comment
RAB ID – Same value as in request

message
See document RANAPI Ref.[26] to get the whole description of the RAB ASSIGNMENT RESPONSE mes-
sage.
As the Provision of speech necessitates a single RAB, only ’RABs setup or modified’ is normaly to be found
in the message.
In case of failure to assign a RAB, the ’RABs failed to setup or modify’ with a Cause IE is also present,
see documentt RANAPI Ref.[26] for the possible reasons.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 70 / 103
103
3.3.3 RELOCATION REQUEST
This message is sent from the MSC to the SRNC to request the allocation of the necessary resources for
the relocation of the UE.
MSC³RNC: RELOCATION REQUEST
IE value comment
Source RNC to target RNC transparent con- Transferred transparently as

tainer. received.
RABs to be setup
IE value comment
>>Servic e Handover
IE value comment
Service Handover IE according Parameter to control hand-

F–HO–014 overs towards 2G.
and table
SHPLMN
Table 27. RELOCATION REQUEST
In the RELOCATION REQUEST described in above table, only the information relevant to speech is pro-
vided. See document RANAPI Ref.[26] to get the whole description of the message.
The description of the RABs to be setup is identical to the RAB assignment case, see section 3.3.1. The
selected codec modes and DTX depend on the associated PLMN data of the target MSC.
The Source RNC to target RNC transparent container carries information to be transparently passed
from SRNC to target RNC. Part of it may be related to speech.
The Service Handover IE may be present if option F–HO–014 is active, and is always absent otherwise.
When F–HO–014 is active, its presence, or value, depends on the table SHPLMN managed by MMC
MODSHO. See further in the document.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 71 / 103
103
3.3.4 RELOCATION REQUIRED
This message is sent from the SRNC to the MSC to request for a relocation procedure.
MSC³RNC: RELOCATION REQUIRED
IE value comment
Source RNC to target RNC transparent con- Transferred transparently as

tainer. received.
Old BSS to new BSS Information. Transferred transparently as

received.
In case of a 3G target, the Source RNC to target RNC transparent container carries information to be
transparently passed from SRNC to target RNC. Part of it may be related to speech.
In case of a 2G target, the Old BSS to new BSS Information IE carries speech related information to be
transparently passed from SRNC to target BSS.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 72 / 103
103
3.4 RCF – SSP
A thorough description of these messages is provided by the document INAPI [15].

3.4.1 CREATE
In GSM, it is sent by the RCF to the SSP to request the establishment of a half call towards the BSC or
the fixed network.
In UMTS, the purpose of the CREATE is to have the SSP ready for an incoming AAL2 connection from
the RNC. In that case no RETRIEVE operation is performed by the RCF.
RCF³SSP: CREATE
TRAU types O
TC Info O
The TRAU types IE, only present in the GSM case and when the option F–RM–007 is active, contains an
ordered list of pools (see further in 4.3.3.3 the possible lists of pools) .
When speech v3 is requested, the preferred pools support speech v3. As the codecs always support
HR and FR, it is also the case for each pool.
The TC Info IE only present in the UMTS case, is used for the initialisation of the Transcoder by the SSP.
In the case of speech it is set as follows:
– Iu User Plane mode parameter is set to SMpSDU,
– Type of Data Service parameter is set to no indication.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 73 / 103
103
3.4.2 RETRIEVE RESULT
This message, received from the SSP by the RCF, gives the selected pool and CIC when the CREATE
request was related to a leg towards a BSC. Towards the fixed network, only CIC is retrieved.
It is not used in UMTS case.
RCF³SSP: RETRIEVE RESULT
CIC O 2
TRAU Type O 1
The CIC is the circuit selected by the SSP.
The TRAU Type IE is sent back by the SSP when a CREATE requesting the creation of a leg towards a
BSC included a list of pools. It represents the pool selected amid the list of preferred pools provided by
the RCP. If speech v3 is requested, the selected pool should support this version to follow on the call
with speech v3. In case this information is not present while expected by the RCP, or invalid, the call is
released.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 74 / 103
103
4 DESCRIPTION OF NETWORK ENTITIES
4.1 HLR
At the HLR a translation on speech between ISDN–BC and GSM–BC may be performed according to doc-
ument BCTRL Ref. [25].
4.2 VLR
At the VLR a translation on speech between ISDN–BC and GSM–BC may be performed according to doc-
4.3 RCF
4.3.1 Data and retrofit
4.3.1.1 Introduction of GSM AMR
The data associated with the function are those associated to each BSC and managed by CREBSC and
MODBSC.
For all existing BSCs, at the time of introduction of the function, the values are set to AMR not supported,
to FR preferred, to allow handovers between HR and FR and preferred speech versions ordered from high-
est to lowest as up to R5 NSS release. This corresponds to the set of parameters defined in next subsec-
tion:
– AMRRATE=NONE,
– AMRPRATE=FR,
– AMRHO=Y.
Furthermore, when F–RM–007 is active, at least one pool with the support of speech v3 should have been
created at the SSP for each controlled BSC which is intended to support AMR before activating
F–RM–013.
4.3.1.2 Introduction of UMTS AMR
Parameters defined as PLMN data data can be tuned to meet operator’s specific needs. At introduction
of UMTS function, these parameters are assigned generic default values.
RAB QoS parameters defined as PLMN data are:

– Transfer Delay,
– SDU Error Ratio,
– Residual Bit Error Ratio.
RBER can be controlled separately for each RAB sub–flow, i.e. for class A bits, class B and class C. As
erroneous SDUs are delivered with error indication for class A only, SDU Error Ratio is applicable to that
class only.
At the introduction of the function, default values are applied as defined in section 3.3.1.
DTX is applied (resp. not applied) on speech in UMTS when PLMN data DTXAMR is set to ON (resp. OFF).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ON is the default value at the introduction of the function.
ED 01
CIT AAC033638800DS En 75 / 103
103
The selected codec mode(s) among [4.75kbit/s to 12.2kbit/s] to be put in RAB assignment and relocation
messages depend on a PLMN data. At least one codec mode must be selected. At the introduction of the
function all the codec modes are selected by default.
MxBR, GBR and Maximum SDU size are set according to the codec mode(s) actually selected as
described in section 3.3.1.

4.3.2 Administration
4.3.2.1 UMTS case
There is no administration on UMTS AMR.
When option F–HO–014 is active, the service handover UMTS³GSM feature is managed by MMC MOD-
SHO (table SHPLMN, see MMCRCP Ref.[22]).
4.3.2.2 GSM case
The operator can shape the use of GSM AMR to his own requirements. This is done thanks to BSC man-
agement MMCs (CREBSC, MODBSC, see document MMCRCP Ref. [22]) which allow, if F–RM–013 is
active, to modify AMR profile parameters. These parameters are:
– AMRRATE can be HR, FR, BOTH or NONE,
this parameter is used to force the utilization of the AMR codecs only in HR, only in FR or allowing
both rates. Of course when the MS indicates only FR (resp.HR), the RCP does not compel the use
of HR (resp.FR).
When it is equal to NONE, the BSC does not yet support AMR.
– AMRPRATE can be HR, FR, MS
this parameter is only meaningful when AMRRATE=BOTH. When set to MS, the RCF abides by the
MS choices over speech versions and rates (i.e. the ordering received from the MS is used).
When set to FR (resp. HR) FR (resp. HR) is preferred. In these two cases, for each rate, the MS
speech versions are reordered from the highest (v3) to the lowest (v1).
– AMRHO can be Y or N.
this parameter is only meaningful when AMRRATE=BOTH.
When F–RM–013 is not active the default values are:

– AMRRATE=NONE,
– AMRPRATE=FR,
– AMRHO=Y.
They correspond to BSCs without support of AMR, and a NSS behaviour regarding speech unchanged
compared to R5 release (i.e. FR speech versions ordered from highest to lowest).
4.3.3 Functional description.
In UMTS, UMTS AMR speech is always offered.
In GSM speech v1 FR is always offered. The other different speech versions are available on condition
of functional options as follows.
When F–RM–005 is not active only speech v1, FR and/or HR is available at the NSS. The supply of HR
v1 depends on F–RM–001.
Otherwise when F–RM–005 is active, multispeech version is offered, in particular speech v3 can be pro-
1AA 00014 0004 (9007) A4 – ALICE 04.10
vided by the NSS if F–RM–013 is also active. Then, the utilization of speech v3 depends on the calling/
called MS preferences and the covering BSS capabilities.
ED 01
CIT AAC033638800DS En 76 / 103
103
4.3.3.1 Translation mechanisms ISDN–BC <–> GSM–BC.
At the RCF a translation on speech between ISDN–BC and GSM–BC may be performed according to doc-
4.3.3.2 Analysis of GSM–BC against speech.
In UMTS there is only one codec available which is mandatory, the UMTS AMR codec. The ITC field value
is therefore sufficient to deduce a request for speech, no further analysis of the GSM–BC is needed.
However, in case of 3G to 2G handover an analysis of the GSM–BC is necessary. It is performed when

the handover is requested. The analysis is identical to the GSM case at call setup and is described in this
section.
The following SDL describes the process to analyze the speech version(s) supported by a MS according
to the informations the MS provides in the GSM–BC of SETUP or CALL CONFIRMED messages.
The output of this analysis is a table, named MS–SPEECH–V, constituted of a list of speech versions sup-
ported by the MS, ordered according to the preferences shown by the MS. This table is memorized for later
use during the handover procedure, and named MS–SPEECH–V–STORED. MS–SPEECH–V–STORED
is never modified.
This table is compared to the speech capabilities of the serving BSS, at call establishment or at handover,
to deduce what can be assigned to the MS.
The table structure is as follows:
speech version
1st preferred
2nd preferred
3rd preferred
...................
nth preferred
Table 28. MS–SPEECH–V and MS–SPEECH–V–STORED tables.
The speech versions may be among the values defined in Table 10.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 77 / 103
103
GSM–BC analysis
for speech ver-
sion 1/2
GSM–BC analysis
Erase
MS–SPEECH–V
N bit321=000,
ITC=speech of
octet 3 meaning speech
N the MS supports
ext bit of octet 3
set multiple speech
versions
N only speech v1
F–RM–005 active offered if option
not active
MS supports supported speech

speech V1 FR, Vi indicated by
and optionally HR octet(s) 3a
bits 76 of oct 3
FR v1 HR/FR v1 FR/HR v1
01 10 11
MS supports at
speech FR v1 speech FR+HR speech FR+HR least speech v1
only v1 v1
HR preferred FR preferred
Figure 22. SDL 1/2: Received GSM–BC analysis against speech version.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 78 / 103
103
GSM–BC analysis
for speech ver-
sion 2/2
2
next octet 3a ana-

lyzed
bit 7=0 means N
bit 7 of oct 3a
oct3a is an exten- indicates exten-
sion of ITC sion of ITC
N
HR and/or FR V3
indicated in 1
oct(s)3a
N N
F–RM–013 active oct 3a speech ”speech tbd”... or
version supported other not sup-
by RCF ported versions
are ignored
Y
AMR speech speech other than ext bit of oct 3a
1 codec AMR as indicated set
in oct3a
Update Update MS supports end of oct 3a

MS–SPEECH–V MS–SPEECH–V speech V1 FR, extensions
and optionally HR
Y
Speech V1
1 1 already in table
MS–SPEECH–V
speech v1 sup- Update

ported by MS MS–SPEECH–V
according to RCR
bits76 of oct 3
copy from
Copy to
MS–SPEECH–V
MS–SPEECH–V–
STORED
N if two GSM–BC
dual service
have been
received
all HR speech v only

removed from MS–SPEECH–V
MS–SPEECH–V is updated
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 23. SDL 2/2: Received GSM–BC analysis against speech version.
ED 01
CIT AAC033638800DS En 79 / 103
103
4.3.3.3 Selection of pools.
The notion of pool is relevant in the GSM environment only.

See document TPOOLM Ref.[20] for a thorough description of pool management.

This section applies only when F–RM–007 is active. When not active all the circuits between BSC and SSP
are equipped with transcoders to handle speech v3.
The list of pools supported by the RCF is enhanced according to the pools defined in Table 6.
After the speech versions supported by the MS have been deduced from the received GSM–BC a table
MS–SPEECH–V has been created.
The following table of this section provides a list of pools in association to each combination of speech
versions that may appear in MS–SPEECH–V. The pools are given by order of preference from left to right,
the left being the best choice.
The MS speech preferences of the table are here only listed as possible combinations, regardless of the
MS ordering.
The constitution of the lists of pools is driven by the following rules:

– when possible, the first pool of the list exactly matches the requested capabilities,
– then pools covering the requested capabilities, from the poorest to the richest additional capabilities
in order to avoid waste of resources,
– and finally pools only covering subsets of the requested capabilities, ordered from the larger to the
smaller coverage, and from the poorest to the richest additional capabilities in order to avoid waste
of resources).
If only the speech TS is to be used then the pool is to be searched out in the pools of next table. For dual
services with basic data services, the search is made in the same table but the pool 23 without data trans-
coder is removed.
The list of pools is sent to the SSP in the TRAU types IE of the CREATE request to establish a leg towards
the BSC.
Some pools of the list may not be physically present on the SSP/BSC interface, but it does not matter
because they will not be selected by the SSP which knows the actual configuration, and no error is gener-
ated.
Note that due to the definition of AMR itself, all the pools supporting speech v3 handle both full and half
rate speech v3.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 80 / 103
103
MS supported speech ver- pools
sions (speech only or basic dual service)
GSM full rate speech v1 25, 27, 23, 24, 1, 3, 5, 7

GSM full/half rate speech v3
GSM full rate speech v1 27, 25, 23, 24, 3, 7, 1, 5, 6

GSM half rate speech v1
GSM full rate speech v1 25, 27, 23, 24, 5, 7, 4, 6, 1, 3

GSM full rate speech v2
GSM full rate speech v1 27, 25, 23, 24, 7, 5, 6, 4, 3, 1

Table 29. POOL–BASIC: Basic table of pools meeting MS speech versions preferences.
(1) pool 23 is for speech only, and therefore cannot be selected for dual services.
In the above table, the first column gives the combinations of speech versions supported by the MS that
may be found in MS–SPEECH–V, regardless of any ordering.
In each list, the pools in bold italic include speech v3 transcoders, the remaining pools without speech
v3 transcoders are considered fallback solutions in cases where the SSP has been misconfigured or no
free pool with speech v3 is left. That increases the probability to still process the call when no speech v3
transcoder is available. The following table gives a description of these additional pools.


HR speech v1


FR speech v2
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 81 / 103
103

HR speech v1

FR speech v2
HR speech v1
Table 30. Fallback pools without support of speech v3.
Pool selection
Pool selection
get pools from according to

POOL–BASIC MS–SPEECH–V
Y
dual service
requested
remove pools
without data
transcoders
build TRAU types

IE of CREATE
request
Figure 24. SDL: Selection of the pools.

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 82 / 103
103
4.3.3.4 Channel Assignment
To assign a traffic channel an ASSIGNMENT REQUEST message is sent by the RCF to the BSS.
This message contains the CIC which has been retrieved from the SSP and a Channel Type IE which
describes the channel with the following information:

– a speech/data indicator, which is always set to speech in the present case,
– the rate, half or full, with or without preferences, and,
– the permitted speech versions.
The permitted speech versions depend on:

– the MS speech preferences (as received in the GSM–BC and found in table MS–SPEECH–V),
– the network operator choices relatively to the AMR preferred rate (as defined by MMCs CREBSC and
MODBSC).
The Channel rate and type depends on:

– the MS speech preferences (as received in the GSM–BC and found in table MS–SPEECH–V),
– whether handovers are allowed by the network operator (as defined by MMCs CREBSC and
MODBSC).
If the BSC does not support multi versions of speech, it cannot support speech v3 either, or else when the
BSC supports multi versions of speech but not speech v3 (i.e. when AMRRATE=NONE), the Channel
Type IE is then built according to document RM Ref. [16] with F–RM–013 not active. Otherwise, the follow-
ing of this section applies.
When there are more than one permitted speech version in MS–SPEECH–V, if it is still the case in the
Channel type IE of the ASSIGNMENT REQUEST, their order of appearance will not necessary be the
same. It depends on the network operator choices made over the BSC characteristics.
This section describes the process to build the Channel Type IE from the MS–SPEECH–V table and the
BSC characteristics.
At first, the pool which has been selected by the SSP is checked. The requested speech versions which
are not supported by the pool are removed from MS–SPEECH–V. If no speech v3 is left the Channel Type
IE is then built according to document RM Ref. [16] with F–RM–013 not active. Otherwise, the treatment
is as follows.
When AMRRATE is NONE, the behaviour is the same as it was up to release R5. The ordering of the
speech versions is made as described in document RM Ref.[16] (i.e. FR preferred, from highest to lowest
speech version).
When AMRPRATE is different from MS, MS–SPEECH–V is reshuffled in order that speech versions
appear from highest to lowest within each rate, FR and HR.
If the received GSM–BC contains for instance:

– speech FR v1,
– speech HR v3,
– speech FR v2,
– speech FR v3.
When AMRPRATE=HR (and if AMRRATE=BOTH), this is reshuffled into:
– speech HR v3,
– speech FR v3,
– speech FR v2,
1AA 00014 0004 (9007) A4 – ALICE 04.10
– speech FR v1.
When AMRPRATE is MS, AMR–SPEECH–V is kept unchanged as input table.
ED 01
CIT AAC033638800DS En 83 / 103
103
Then MS–SPEECH–V is used with next table to get permitted speech versions of the Channel Type IE.
This table only takes into account speech v3. When other speech versions are also found in MS–
SPEECH–V, they may also be kept in the Channel type IE (see document RM Ref. [16]).
When the AMRRATE is HR or FR only, and the MS supports both HR and FR, then the speech v3 rate
which does not fit the BSC characteristic is removed. The network preferences supersede the MS prefer-
ences. However, when a MS indicates only one speech v3 rate (FR or HR) of speech v3 and the BSC
characteristic indicates the opposite rate, then the MS rate is kept in the Channel Type IE. This is possible
because the AMR codecs always support both rates.
When the AMRRATE is BOTH, then AMRPRATE is checked. If AMRPRATE indicates HR or FR, the net-
work preferences supersede the MS preferences, and the order between two speech v3 HR and FR is
reversed if need be. The MS preferences between rates are kept when AMRPRATE is MS.
Finally the channel rate and type information field of Channel Type IE also depends on AMRHO value.
The code values for Channel rate and type of next table, are those given in Table 17.
MS speech preferences Operator’s preferences ASSIGNMENT REQ

(MS–SPEECH–V) Channel type IE
MS speech preferences A A A Permitted Channel

M M M speech rate and
R R R version type
R P H
A R O
T A
E T
E
GSM full rate speech v3 FR Y FR v3 8
FR N FR v3 8
HR Y FR v3 8
HR N FR v3 8
BOTH FR Y FR v3 A or 8
BOTH FR N FR v3 1A or 8
BOTH HR Y FR v3 B or 8
BOTH HR N FR v3 1B or 8
BOTH MS Y FR v3 F or 8
BOTH MS N FR v3 1F or 8
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 84 / 103
103
R R R version type
R P H
A R O
T A
E T
E
GSM half rate speech v3 FR Y HR v3 9
FR N HR v3 9
HR Y HR v3 9
HR N HR v3 9
BOTH FR Y HR v3 A or 9
BOTH FR N HR v3 1A or 9
BOTH HR Y HR v3 B or 9
BOTH HR N HR v3 1B or 9
BOTH MS Y HR v3 F or 9
BOTH MS N HR v3 1F or 9
GSM full rate speech v3 FR Y FR v3 8

FR N FR v3 8
HR Y HR v3 9
HR N HR v3 9
BOTH FR Y FR v3 A
HR v3
BOTH FR N FR v3 1A
HR v3
BOTH HR Y HR v3 B
FR v3
BOTH HR N HR v3 1B
FR v3
BOTH MS Y FR v3 F
HR v3
BOTH MS N FR v3 1F
HR v3
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 85 / 103
103
R R R version type
R P H
A R O
T A
E T
E
GSM half rate speech v3 FR Y FR v3 8

FR N FR v3 8
HR Y HR v3 9
HR N HR v3 9
BOTH FR Y FR v3 A
HR v3
BOTH FR N FR v3 1A
HR v3
BOTH HR Y HR v3 B
FR v3
BOTH HR N HR v3 1B
FR v3
BOTH MS Y HR v3 F
FR v3
BOTH MS N HR v3 1F
FR v3
Table 31. ASSIGNMENT REQUEST: Channel type IE fields values.
Codes for Channel rate and type field (see Table 17. ) are attributed as follows:
– Codes ’F’ and ’1F’ are used when AMRRATE is BOTH and AMRPRATE is MS. This allows the BSC
to be neutral towards the MS preferences.
However if the MS indicates a single type of rate, regardless of the version, they are replaced by ’8’
or ’9’.
– Codes ’8’ and ’9’ are used when AMRRATE is HR or FR only.
However when the MS indicates a single type of rate, but the opposite one, ’8’ is replaced with ’9’
and vice versa.
– Codes ’A’, ’1A’, ’B’, and ’1B’ are used when AMRRATE is BOTH and AMRPRATE is HR or FR.
However when the MS indicates a single type of rate, regardless of the version, they are replaced
by ’8’ or ’9’.
The Channel type IE must comply with the following rules:

– when a preference for a channel rate is indicated, there must be at least one permitted speech version
for each rate. The non empty sets of permitted speech versions for the respective channel rate are
1AA 00014 0004 (9007) A4 – ALICE 04.10
included in order of the channel rate preferences. Within a set of permitted speech versions for a
channel rate, the permitted speech versions are included in order of speech version preferences.
– if one specific rate is indicated, there must be at least one permitted speech version.
ED 01
CIT AAC033638800DS En 86 / 103
103
– if no preference for a specific rate is indicated, the permitted speech versions are included in order
of speech version preferences.
Channel Type IE Channel Type IE

for assignment
1/3
Y
requested speech
v supported by
selected pool
remove not sup-

ported speech v
MS–SPEECH–V
N
at least one
speech v3 left in
MS–SPEECH–V
treatment according
to Ref. [16] with
AMRRATE F–RM–013 not
active
FR HR BOTH
B C E
reshuffle MS– reshuffle MS– HR/FR reordered

SPEECH–V SPEECH–V speech versions 2
ordered for each
rate
MS rate
FR only HR only BOTH all the speech

versions of MS–
B C E SPEECH–V are
considered
code ’8’ code ’9’ code ’8’
all HR of MS–
SPEECH–V
removed
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 25. SDL 1/3: Channel Type IE for assignment.
ED 01
CIT AAC033638800DS En 87 / 103
103
1 Channel Type IE
for assignment
2/3
MS rate

versions of MS–
considered
code ’8’ code ’9’ code ’9’
all FR of MS–
SPEECH–V
removed

1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 88 / 103
103
Channel Type IE
for assignment
3/3
MS rate

versions of MS–
considered
code ’8’ code ’9’ AMRPRATE
FR HR MS
B C E
N N N
AMRHO AMRHO AMRHO
code ’1A’ code ’A’ code ’B’ code ’1B’ code ’F’ code ’1F’
all FR speech v all FR speech v all HR speech v all HR speech v speech v ordered speech v ordered
bome before HR come before HR come before FR come before FR as MS– as MS–
speech v speech v FR speech v speech v SPEECH–V SPEECH–V
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 89 / 103
103
4.3.3.5 RAB Assignment
To assign a RAB a RAB ASSIGNMENT REQUEST message is sent to the RNC by the RCP.
In the case of speech this message requests for the establishment of a single RAB which is described by
the RAB parameters IE. The RAB is identified by the RAB ID IE which must be unique for a given UE.
The message also requests for the Iu UP SMpSDU mode with the User Plane mode IE.
The RAB parameters IE contains parameters associated to the selected codec modes which constitute
a subset of the codec modes supported by the Tc. The Tc supports all the codec modes defined in 3GPP
TS 26.102 Ref.[11] from 4.75kbit/s to 12.2kbit/s, the 1.80kbit/s rate for comfort noise and DTX. The codec
modes selected are given by a PLMN data (refer to §4.3.1.2).
MxBR, GBR and Maximum SDU size are set according to the codec mode(s) actually selected as
described in section §3.3.1.
The RAB parameters IE is built as follows:

– Three classes (A, B and C) resulting in three subflows are defined,
– For each one of the three sublows:
• QoS parameters are given (BER and RBER),
• A Subflow SDU size is provided for each codec mode (depending on the codec mode, some
Subflow SDU sizes may be null).
On reception of RAB ASSIGNMENT REQUEST, the RNC establishes the RAB and runs the initial Iu UP
procedure, upon its completion the Iu UP connection between RNC and TC is established in SMpSDU
mode. The TC had previously been set in this mode by the SSP after the CREATE operation.
The Tc gets all the necessary parameters (Subflow SDU size, rates...) at the initial procedure (see 3GPP
TS 26.071 Ref.[8]). These parameters are a consistent subset wich reflects the common capabilities of
the UE, of the UTRAN, and of the selected codec modes sent at the RAB ASSIGNMENT REQUEST.
Some parameters have been computed by the RNC from the RAB parameters. For instance the Iu Timing
Interval (ITI) is deduced from the Maximum SDU size and Maximum Bit Rate. With the 12.2kbit/s codec
mode and a 244 bits SDU size, the interval is 20ms. Iu speech PDUs are indeed sent every 20ms, which-
ever the codec mode.
When the RAB has been successfully established the RNC sends back to the RCP a RAB ASSIGNMENT
RESPONSE. The established RAB is identified by the returned RAB ID IE.
4.3.3.5.1 DTX in UMTS
DTX may be applied on speech depending on the value of DTXAMR PLMN data (see §4.3.1.2).
In case of speech inactivity no frame is sent over the radio interface when DTX is active except for comfort
noise frames (i.e.SID).
DTX is therefore handled as a 0 kbit/s source rate to which is associated a1.80kbit/s source rate for SID.
For DTX activation, a RAB Subflow Combination Bit Rate parameter is included with value set to 0 and
a 1.80kbit/s sublow is defined in the RAB parameters IE of RAB ASSIGNMENT REQUEST and
RELOCATION REQUEST messages. Iu initialisation procedure forwards these information to the TC
which applies DTX.
When DTX is not activated, neither RAB Subflow Combination Bit Rate parameter nor the 1.80kbit/s
1AA 00014 0004 (9007) A4 – ALICE 04.10
subflow are part of the RAB parameters IE.
ED 01
CIT AAC033638800DS En 90 / 103
103
4.3.3.6 Establishment of a MOC in GSM
The treatment described here is confined to AMR. A thorough picture if available from documents [16] and
[18].
In the MOC case the MS signals to the RCP its capability to support speech v3 (or AMR) in the GSM–BC
IE of the SETUP message.
The GSM–BC may give informations on the MS preferred speech versions as described in 3.1.1.
In case no GSM–BC is found in the SETUP, then speech version 1 is considered to be requested.
The GSM–BC is analyzed according to section 4.3.3.2. A table MS–SPEECH–V results from this analysis.
It contains a list of the MS preferred speech versions supported by the NSS. Speech v3 is available at the
NSS only if speech multiversion is available (i.e. F–RM–005 is active) and the functional option associated
with the present function, F–RM–013, is active.
In case the MS invokes dual services, only the GSM–BC associated with the speech TS is analyzed as
described above.
If the functional option F–RM–005 ”speech multi–version support” is not active, only speech version 1 is
supported by the NSS.
If the functional option F–RM–005 is active, but F–RM–013 is not, then the usual version 1, or version
2 corresponding to the ”Enhanced Full Rate”, is to be used (see document RM Ref.[16]).
Then a CALL PROCEEDING message is sent back to the MS to acknowledge the SETUP. The GSM–BC
it carries contains no indication upon speech versions.
If the circuit pool management is not provided at the RCP (i.e. F–RM–007 is not active) a leg can be directly
created toward the BSS. In that case all the circuits must be equipped with transcoders able to handle
speech v3 in both full and half rates.
Otherwise, if the circuit pool management is available (i.e. F–RM–007 is active), only some circuits are
able to handle speech v3. Following the GSM recommendations the pools they belong to are given in
Table 6. To establish a leg towards the BSS, a CREATE request is sent to the SSP which contains a list
of pools in the TRAU type IE. This parameter, being optional, is not present when F–RM–007 is not active.
The pools are selected according to 4.3.3.3.
The SSP selects a circuit among the pools of the list that are physically present (i.e. the list contains suit-
able pools defined by the recommendations, but not necessary present at the SSP/BSS interface).
The SSP then returns the CIC of the selected circuit, together with the corresponding pool when
F–RM–007 is active.
It is verified whether this pool belongs to the list of pools that support speech v3. If it is not the case (i.e.
due to a SSP misconfiguration or a lack of free circuits) the speech v3 (HR and FR) is removed from the
permitted speech versions of the ASSIGNMENT REQUEST.
This CIC is provided to the BSC through the ASSIGNMENT REQUEST message. The message also car-
ries the channel type with permitted speech versions and rates, half and/or full. The Channel type IE is
constructed according to section 4.3.3.4.
It is acknowledged by an ASSIGNMENT COMPLETE message which normally gives the used speech
1AA 00014 0004 (9007) A4 – ALICE 04.10
version in the Speech version (chosen) IE.
If the chosen speech version IE is not present, the speech version indicated by the Permitted speech
version identifier (see section 3.2.1.1) in octet 5 of Channel type IE is assumed to have been chosen.
ED 01
CIT AAC033638800DS En 91 / 103
103
The Chosen speech version, received or assumed, is used to update the CDR.
4.3.3.7 Establishment of a MTC in GSM

The treatment described here is confined to AMR. A thorough picture if available from documents RM [16]
and BCH [18].
In the MTC case the RCP sends to the MS a SETUP message with a GSM–BC IE requesting for speech
TS. No indication is provided on the RCP capabilities or choices related to the speech versions.
From the speech v3 point of view, the treatment is similar to the MOC case.
The MS signals its speech versions capabilities in the GSM–BC of the CALL CONFIRMED message it
sends to acknowledge the SETUP. This GSM–BC, or its absence, are analyzed just as in the MOC case.
Then the pool selection and channel assignment are strictly identical.
4.3.3.8 Establishment of a call in UMTS
The complete treatment to describe a call establishment is described in BCH [18].
In the MOC case the UE signals to the RCP its request for the speech TS in the GSM–BC IE of the SETUP
message. To that purpose the ITC field is set to ’speech’.
The RCP acknowledges the request by sending back a CALL PROCEEDING message to the UE. The
message carries a GSM–BC from which the MS supported speech versions, if any, have been removed
(see 3.1.1 on GSM–BC structure)
In the MTC case the RCP requests for the speech in the GSM–BC IE of the SETUP message with the ITC
field is set to ’speech’. The UE returns back a CALL CONFIRMED with possibly a GSM–BC. If it does
not return a GSM–BC, the request is implicitly acknowledged.
The GSM–BC sent by the UE in SETUP or CALL CONFIRMED may also give information on the MS pre-
ferred speech versions as described in 3.1.1, however this information is not analysed but just memorised
in case of later need for handover. If the MS has not provided a GSM–BC it is considered to support only
FR speech v1 in a GSM network.
After having sent the CALL PROCEEDING or received the CALL CONFIRMED message the RCP per-
forms a CREATE operation towards the SSP.
The purpose of the CREATE is to prepare the SSP and TC resources to the incoming AAL2 and Iu UP
connections. To get a detailed description see document BCH Ref.[18].
The RCP sets the TCinfo parameter of CREATE to ’Support Mode for predefined SDU size’ which is the
Iu UP necessary mode for speech.
In the same time the RCP sends to the RNC the RAB ASSIGNMENT REQUEST which has been built
according to 4.3.3.5.
The SSP sets the previously allocated TC into the SMpSDU mode, the RNC then establishes the AAL2
connection and runs the Iu UP initial procedure. This initial procedure provides the TC with all the parame-
ters to map between the speech TDM frames and Iu UP PDUs. These parameters result from the codec
modes supported by TC, RNC and UE in common.
Upon successful Iu UP inital procedure the RNC acknowledges the RCP with RAB ASSIGNMENT
1AA 00014 0004 (9007) A4 – ALICE 04.10
RESPONSE.
From now on the speech teleservice is available.
ED 01
CIT AAC033638800DS En 92 / 103
103
4.3.3.9 Paging in UMTS
In UMTS the PAGING message (refer to BCH Ref.[18]) includes an optional Paging cause parameter
which has the value Terminating Conversational Call in case of a speech call.
To that purpose, when the VLR requests paging for terminated calls, the PLMN–BC received from the VLR
by the RCF is analyzed to identify whether the call will be for speech or data.
In case no PLMN–BC is available the Paging cause is not included in the PAGING message.
When a PLMN–BC is available, its analysis is as follows.
Determination of
the type of call
N
PLMN–BC avail-
able?
Y Speech
ITC=speech?
refer to document data call

CDU treatment
Paging Cause = No Paging Cause

Terminating parameter
Conversational included
Figure 28. Determination of the type of call for paging.
4.3.3.10 Handover and Relocation
The term ’Handover’ is applicable when the serving entity is 2G, and ’Relocation’ when 3G.
4.3.3.10.1 Channel Type for the handover case.
In some handover cases described further in the document, handover related messages carry a Channel
Type IE. Since a target RCP may have no knowledge of the received GSM–BC, and the characteristics
of the target BSC may differ from those of the serving BSC, the Channel Type IE has to be determined
in a different way from the channel assignment case.
Therefore, the Channel Type IE is built as follows:

– the permitted speech versions are the same as those deduced from the GSM–BC and stored in MS–
1AA 00014 0004 (9007) A4 – ALICE 04.10
SPEECH–V–STORED regardless of any BSC characteristic,

– the channel rate and type is set to value ’F’ (see Table 17. ) meaning ’Full or Half rate TCH channel.
Preference between the permitted speech versions as indicated in octet 5, 5a etc.’.
ED 01
CIT AAC033638800DS En 93 / 103
103
The above rule applies in the 2G³2G handover and in the 3G³2G handover cases. In the latter case
the GSM–BC received from the MS has in addition to be analysed as stated in 4.3.3.2.
4.3.3.10.2 Intra–BSS handover

The reception of HANDOVER PERFORMED message means that the BSS has performed an internal
handover. In particular, it is the case when AMR handovers occur between FR and HR.
It is expected to have less than 5 such handovers in a two minute call. This figure is only provided for
information, the RCP performs no specific associated treatment.
The HANDOVER PERFORMED message may describe the characteristics of the new channel with a
Chosen Channel IE and a Speech Version (Chosen) IE. At any receiving MSC no check is performed on
these IEs. As a consequence if a value happens to be in contradiction with the characteristics of the allo-
cated channel type/speech version, no action of defense is undertaken and the call is carried on.
4.3.3.10.3 Inter–BSS Intra–MSC handover
[18].
These handover procedures start upon the reception by the RCP of a HANDOVER REQUIRED message.
When speech is used, this message always contain the optional Speech version (used) IE. Current Chan-
nel type 1 IE should also always been present and in our case indicate ”speech”. The message may also
contain Old BSS to New BSS Information IE and Current Channel type 1 IE.
If F–RM–013 is active, the Speech version (used) IE may indicate GSM full rate speech v3 or GSM half
rate speech v3. If it indicates so while F–RM–013 is not active, the IE is ignored.
When received, the Speech version (used) IE is included unchanged in the HANDOVER REQUEST later
sent to the target BSS. When none has been received, a Speech version (used) is nevertheless sent in
the HANDOVER REQUEST based on the last received speech version (in ASSIGNMENT COMPLETE,
HANDOVER PERFORMED or HANDOVER REQUEST ACKNOWLEDGE). However, the inclusion of
Speech version (used) IE depends on a BSC characteristic (see document HO Ref. [17]).
The Old BSS to New BSS Information IE, when received, is to be passed transparently to the target BSS
by the RCP in the HANDOVER REQUEST. This IE may contain a MultiRate configuration information
Field Element which gives informations about the current AMR speech codec configuration. The target
BSS will use this information to build the HANDOVER COMMAND if it uses AMR.
The HANDOVER REQUEST message sent to the target BSS contains a Channel type IE which is man-
aged similarly to 4.3.3.4. with as input table a newly built MS–SPEECH–V. The new MS–SPEECH–V
comes from MS–SPEECH–V–STORED which had been memorized upon GSM–BC analysis, and takes
into account the characteristics of the target BSS (AMRRATE, AMRPRATE, AMRHO). The pool selected
by the SSP is also checked as in the assignment case to remove not supported speech versions. Finally
the new MS–SPEECH–V constitutes an input to define the Channel type IE fields.
However, prior to sending HANDOVER REQUEST, a leg toward the target BSS is created. When
F–RM–007 is active, the list of pools is built up according to 4.3.3.3 and also depends on the received
GSM–BC.
If the target BSS can support the handover it sends back a HANDOVER REQUEST ACKNOWLEDGE
message with a Speech version (Chosen) IE and a Chosen channel IE. In our case, the speech version
1AA 00014 0004 (9007) A4 – ALICE 04.10
may be v3.
When the handover finally succeeds a HANDOVER COMPLETE message is received by the RCF.
ED 01
CIT AAC033638800DS En 94 / 103
103
4.3.3.10.4 Inter–MSC handover within a GSM PLMN
[18].
When the handover procedure involves more than one MSC, the HANDOVER REQUEST message is
exchanged on the E interface between MSCs, encapsulated within MAP operation PrepareHandover
(invoke). In return a HANDOVER REQUEST ACKNOWLEDGE or HANDOVER FAILURE is received from
the target MSC, encapsulated in the PrepareHandover (result) MAP operation. The HANDOVER
REQUEST always carries a Channel type IE. When F–RM–005 and F–RM–013 are active, this IE may
contain multiple speech versions, and among them speech v3.
A few different cases are considered.
a) Serving RCF=controlling RCF, different from the target RCF.
The controlling RCF builds a Channel Type IE according to 4.3.3.10.1. and sends it in a HANDOVER
REQUEST to the target RCF.
At the target MSC, when F–RM–007 is active, the Channel type IE of the received HANDOVER REQUEST
is used according to section 4.3.3.3 text and Table 29. to get an appropriate list of pools for the leg creation
toward the target BSS. However, pools without support of data (e.g. pool number 23) are removed from
the list of pools provided to the SSP. The rationale is, the target MSC being not aware of the type of the
call, speech only or dual speech/data, a selected pool without data support would cause the rejection of
a later in–call modification.
At the target MSC the characteristics of the target BSC are applied on the received Channel Type IE per-
mitted speech versions in the same way as on MS–SPEECH–V for the assignment case. The new result-
ing Channel Type IE is used by the target RCP to send the HANDOVER REQUEST to the target BSC.
b) Target, serving and controlling RCF are all different.
This is the so–called subsequent handover with three MSCs involved. The serving sends a HANDOVER
REQUEST to the controlling MSC, with a Channel Type IE. This IE is ignored by the controlling MSC, which
builds a new Channel Type IE as in 4.3.3.10.4 case a ). This new Channel Type IE is forwarded to the
target MSC in a HANDOVER REQUEST.
At the target MSC the characteristics of the target BSC are applied on the received Channel Type IE per-
mitted speech versions in the same way as on MS–SPEECH–V for the assignment case. The new result-
ing Channel Type IE is used by the target RCP to send the HANDOVER REQUEST to the target BSC.
This is similar to 4.3.3.10.4 case a ). Also about pool selection, pools without support of data (e.g. pool
number 23) are removed from the list of pools provided to the SSP.
c) Controlling = target RCF, different from the serving RCF.
This is the so–called subsequent handover with two MSCs involved. The serving RCF sends a HAND-
OVER REQUEST to the controlling MSC, with a Channel Type IE. This IE is ignored by the controlling
MSC.
The pool list is deduced just as in the assignment case.
The controlling/target MSC builds a new Channel Type IE from the MS–SPEECH–V table and the charac-
teristics of the target BSC. This IE is then forwarded to the target BSC in a HANDOVER REQUEST.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 95 / 103
103
4.3.3.10.5 Intra–BSS handover at a serving MSC
This case occurs when an inter MSC happened beforehand. The target and serving cells are controlled
by same RCF which is not the controlling RCF.
The informations of the Channel Type IE of HANDOVER REQUEST and to get the pool list are the same
as in 4.3.3.10.4 case a ).
When an intra–BSS handover occurs at a serving MSC, different from the controlling MSC, a HANDOVER
PERFORMED message is sent to the controlling MSC through the E interface encapsulated within the
MAP operation Process Access Signalling.
The reception of HANDOVER PERFORMED message at the controlling MSC means that the serving BSS
has performed an internal handover. In particular, it is the case when AMR handovers occur between FR
and HR.
It is expected to have less than 5 such handovers in a two minute call which can induce an increased sig-
nalling traffic at MSCs. This figure is provided for information. No treatment is associated at the MSC.
4.3.3.10.6 Relocation within a UMTS PLMN
Preamble:
As in UMTS there is only one possible and thus mandatory codec, no treatment is really associated with
speech. The only information which is carried over between 3G MSCs is related with the UMTS AMR
codec modes supported by the TC. This is a consequence of the possible configuration where Iu UP over
AAL2 may be used between MSCs. In that configuration the TC is always located at the anchor MSC.
In our present configuration the MSCs are always connected through a TDM link. The TC is therefore
always connected to the serving MSC and the signalling on TC capabilities between MSCs is not useful.
UMTS relocation:
The relocation is triggered by the Serving RNC sending an Iu RELOCATION REQUIRED message to its
serving MSC.
Two cases are then considered.
Intra MSC:
In this case an Iu RELOCATION REQUEST message is forwarded to the target RNC.This message car-
ries a RAB parameters IE and a User Plane mode IE. These parameters are set for speech identically
to the RAB assignment case described in 4.3.3.5.
The remaining of the procedure and the other parameters are fully described in document HO Ref.[17].
Inter MSC:
In that case a MAP PREPARE HANDOVER REQUEST message is forwarded to the target 3G MSC. This
message carries a RANAP Iu RELOCATION REQUEST in a AN–APDU container (see 3GPP TS 29.002
Ref.[13]). The RAB parameters IE of the RELOCATION REQUEST message include all the codec modes
[4.75kbit/s – 12.2kbit/s], without DTX.
At the target 3G MSC the RAB parameters IE of the received RELOCATION REQUEST message are
ignored. RAB parameters IE are instead replaced in the RELOCATION REQUEST message sent to the
1AA 00014 0004 (9007) A4 – ALICE 04.10
target RNC with parameters depending on the target MSC configuration of DTX and codec modes (target
MSC PLMN data) as for the RAB assignment case described in 4.3.3.5.
ED 01
CIT AAC033638800DS En 96 / 103
103
4.3.3.10.7 Handover from GSM to UMTS
As in UMTS there is only one possible and thus mandatory codec, no particular treatment is associated
with speech.
The handover is triggered by the Serving BSC sending a HANDOVER REQUIRED message to its serving
MSC. The message may carry the optional following IEs:
– Current Channel Type 1,
– Speech Version (Used),
– Old BSS to New BSS Information.
These information IE, of no use in UMTS, are simply ignored.
Furthermore, the HANDOVER REQUIRED message carries a Source RNC to target RNC transparent
information (UMTS) IE which has the same structure as when generated in a RNC (see GSM 08.08 [2]).
Intra MSC:
In this case the MSC justs sends a RELOCATION REQUEST message to the serving RNC. This message
carries the received Source RNC to target RNC transparent information (UMTS) IE, a RAB parame-
ters IE and a User Plane mode IE. These parameters are set for speech identically to the RAB assignment
case described in 4.3.3.5. The RAB parameters IE setting is performed according to 4.3.3.5.
Inter MSC:
In that case a MAP PREPARE HANDOVER REQUEST is sent to the target 3G MSC. This message car-
ries a HANDOVER REQUEST message as in the intra GSM case. HANDOVER REQUEST carries the
received optional IEs (Current Channel Type IE, Speech Version (Used) IE and Old BSS to new BSS
Information IE). It also carries the received Source RNC to target RNC transparent information
(UMTS) IE. At the target 3G MSC an Iu RELOCATION REQUEST message is sent to the RNC. This mes-
sage contains the received Source RNC to target RNC transparent information (UMTS) IE, a User
Plane mode IE which is set to SMpSDU, and a RAB parameters IE which setting is performed according
to 4.3.3.5.
4.3.3.10.8 Relocation from UMTS to GSM
This case of handover is very similar to the GSM to GSM case.
The Handover is triggered by the Serving RNC sending an Iu RELOCATION REQUIRED message to its
serving MSC. This message carries an Old BSS to new BSS Information IE which has the same struc-
ture as when generated in a BSS (see 3.2.7 and [2]).
Intra MSC:
In this case the serving MSC sends a HANDOVER REQUEST message to its controlled BSC (see 3.2.5).
The message is built as follows:
1AA 00014 0004 (9007) A4 – ALICE 04.10
– the optional Speech Version (Used) IE is not provided,

– the received Old BSS to new BSS Information IE is forwarded,
– the optional Current Channel Type 1 IE is not provided,
– the Channel Type IE is built as in the intra–GSM case described in 4.3.3.10.1.
ED 01
CIT AAC033638800DS En 97 / 103
103
Inter MSC:
In that case the serving MSC sends a MAP PREPARE HANDOVER REQUEST message to the target 2G
MSC. This message carries a HANDOVER REQUEST message which has been built identically to above
Intra–MSC case.
At the receiving target 2G–MSC the MAP PREPARE HANDOVER REQUEST message is treated as is
intra 2G–MSC case (see document HO Ref.[17]).
The remaining of the procedure is fully described in document HO Ref.[17].
4.3.3.11 Service Handover for speech
Service handover UMTS³GSM feature is supported for speech calls when option F–HO–014 is active.
When option F–HO–014 is active MMC MODSHO (see MMCRCP Ref.[22]) is available. This command
associates in a table (SHPLMN) to a PLMN identification MCC+MNC a ’Service Handover for speech’
parameter (SHSPEECH).
The MCC+MNC of the IMSI of the subscriber is used here to get SHSPEECH value. The IMSI may corre-
spond to a visiting roamer, or to a subscriber in his home PLMN.
SHSPEECH may have one of the following values:

– No Service Handover,
– Handover to GSM should be performed,
– Handover to GSM should not be performed,
– Handover to GSM shall not be performed.
If there is no entry in SHPLMN table for that MCC+MNC (i.e.no SHSPEECH parameter defined, the opera-
tor has not yet invoked MODSHO for that MCC+MNC), or if the IMSI is not available (i.e.if it has not been
received by the serving RCP), a default value for SHSPEECH is used.
There exists a single default value for SHSPEECH which is associated to MCC+MNC=’000 000’. This
default value can be modified by MODSHO.
Following the introduction of Service Handover function (i.e. activation of F–HO–014) the default value
of SHSPEECH parameter associated with MCC+MNC=’000 000’ may remain undefined until MMC MOD-
SHO has been applied, in that case No Service Handover is used.
If SHSPEECH is set to No Service Handover, the Service Handover IE is not used.
Otherwise, the value of SHSPEECH is used to generate Service Handover IE.
The Service Handove IE is then included in:

– RAB ASSIGNMENT message sent by RCP to RNC.
– RELOCATION REQUEST message sent by RCP to RNC.
– RELOCATION REQUEST message sent by RCP to MSC in a PREPARE HANDOVER REQUEST-
message.
– RELOCATION REQUEST message sent by RCP to MSC in a PREPARE SUBSEQUENT HAND-
OVER REQUEST message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 98 / 103
103
Locally managed SHPLMN table is used to get the value of SHSPEECH and decide on the emission of
Service Handover IE and its content. That implies that the Service Handove IE received in a RELOCA-
TION REQUEST message contained in a PREPARE HANDOVER REQUEST is superseded by a locally
generated Service Handove IE or removed, depending on local SHSPEECH value, before sending
RELOCATION REQUEST message to the RNC.

When option F–HO–014 is not active Service Handover IE is never sent for speech calls.
4.3.3.12 In–call modification
This procedure only applies to GSM.
The in–call modification is initiated by the MS if a dual service has been negotiated at call setup and if the
MS desires to change the call mode, from data to speech, or conversely. In the present description we are
only interested with the data to speech case.
The RCF receives a MODIFY message with a GSM–BC which is analyzed as described in 4.3.3.2. A MS–
SPEECH–V table results from this analysis. In addition, the RCP ability to treat data transmissions limited
to FR channels being extended to speech in dual services calls, any reference to an HR channel is
removed from MS–SPEECH–V.
Then a Channel Type IE is built an ASSIGNMENT REQUEST sent as in 4.3.3.4.
If the channel assignment fails the RCF sends a MODIFY REJECT with Cause IE set to ”Bearer capability
not presently available”.
The MODIFY REJECT message contains the current GSM–BC which corresponds to the data service in
progress.
If the assignment procedure is successful, then a MODIFY COMPLETE is returned to the MS with the
GSM–BC which has been received in the MODIFY.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 99 / 103
103
In–call modifica-
tion
data call in prog-

ress
MODIFY
GSM–BC
analysis
N
speech
output
MODIFY REJECT build MS–SPEECH–V
Channel Type IE
according to BSC
data call in prog- ASSIGNMENT characteristics
ress REQUEST
ASSIGNMENT ASSIGNMENT
COMPLETE FAILURE
MODIFY COM- MODIFY REJECT

PLETE
call in speech data call in prog-

phase ress
1AA 00014 0004 (9007) A4 – ALICE 04.10
Figure 29. SDL: In–call modification.
ED 01
CIT AAC033638800DS En 100 / 103
103
4.3.4 Observation
No observation is related to the function.

4.3.5 Charging
4.3.5.1 GSM AMR
The CDR is updated with AMR related informations only when the option F–CG–056 is active.
In that case, the CDR includes the following indications:
– choice left to the BSC between FR and HR, with or without a preference,
– which rate the BSC has retained,
– and the chosen speech version.
It is also updated with the best speech version supported by the MS for both Half and Full Rate which have
been provided at call setup in its bearer capabilities. Speech v3 is considered better than v2, which is better
than v1. It is also indicated if the MS does not support any Half Rate speech.
Although the chosen speech version may change due to handover, the CDR is updated once, upon suc-
cessful channel assignment.
If F–CG–056 is inactive while F–RM–013 is active, and the MS supports speech v3, the CDR is updated
by default values (see document CG Ref.[24]) which do not truthfully reflect the choices left to the BSC,
what the BSC has retained and the chosen speech version. This state where the two options are not simul-
taneously active should however be a transient state, until the CDR collector is able to process the AMR
related parameter values.
4.3.5.2 UMTS AMR
The ’Chosen speech version’ is updated with the value ”UMTS AMR speech v1” when option F–CG–062
is active.
Although the ’Chosen speech version’ may later change due to handover towards GSM, the CDR is not
updated.
When F–CG–062 is not active ’Chosen speech version’ is not relevant. This situtation should however be
transient until the CDR collector is able to process the UMTS AMR related parameter value.
The BSC speech related information (Required bearer capability) is not relevant, it is therefore set to a
default value as stated in CG Ref.[24].
4.3.6 Timers
The function needs no timer.
4.3.7 Errors
The following error is generated in case a second call or a call waiting requesting for a data service cannot
be processed due to an incompatible allocated pool (e.g. the pool supports only speech such as pool 23).
See document RM Ref.[16] for a detailed description.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 101 / 103
103
ERR_RM_006 The requested channel or circuit pool is not compatible with the channel or cir-
cuit pool already allocated.
Internal Error Corresponding error on external Interface

Interface Message error labelling
ERR_RM_006 MS N_DISC Call rejected

SSP FREE_I No Circuit / channel
available
Table 32. Translation of generated errors.
This error is not applicable to UMTS because the notion of pool is not relevant.
4.3.8 Warnings
No warning is associated to the function.
4.4 SSP
In the SSP, associated to each BSC, only 16 pools can be defined. However the SSP knows up to 64 pools.
The 16 pools can therefore be numbered from 0 to 63.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 102 / 103
103
5 INTERACTIONS WITH OTHER SERVICES
Interaction with suplementary services while resources are already established:

In GSM, in the case of interaction with suplementary services such as CALL HOLD and CALL WAIT , the
ASSIGNMENT REQUEST corresponding to the acceptance of a call takes into account the already estab-
lished ressources. That is to say, if the pool currently in use does not support some speech versions, they
are not proposed in the Channel Type IE of the ASSIGNMENT REQUEST.
Furthermore, a call waiting or a second call, requesting for a data service is rejected if the currently allo-
cated pool only supports speech (e.g. pool 23) and the error ERR_RM_006 is generated.
END OF DOCUMENT
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
CIT AAC033638800DS En 103 / 103
103

AMR

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AMR

Uploaded by

Copyright:

Available Formats

Site

VELIZY TECHNICAL DEPARTMENT

Originators SPEECH AND ADAPTATIVE MULTI–RATE

Name M.JACOB R.RAYNAUD M.BIGNON

Reference of the minutes SRD/TD/SYS/DFB/ES/00.171.03/MJ

Modifications associated with following Change Requests have been included:

FOR INTERNAL USE ONLY

LIST OF FIGURES AND TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 DETAILED DESCRIPTION AND SCENARIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

01 030123 Creation CA–SYS CA–SYS

ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR

SPEECH and ADAPTATIVE MULTI–RATE

CIT AAC033638800DS En 1 / 103

3 DESCRIPTION OF INTER–ENTITIES MESSAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 DESCRIPTION OF NETWORK ENTITIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5 INTERACTIONS WITH OTHER SERVICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

CIT AAC033638800DS En 2 / 103

Figure 1. Variable partitioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 3. In band Signalling for AMR codec adaptation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 4. Architecture for speech in UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Table 27. RELOCATION REQUEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

CIT AAC033638800DS En 3 / 103

Figure 25. SDL 1/3: Channel Type IE for assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Figure 26. SDL 2/3: Channel Type IE for assignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

CIT AAC033638800DS En 4 / 103

[1] GSM REC 04.08.

[2] GSM REC 08.08.

[3] GSM REC 05.09.

[4] 3GPP TS 22.002.

[5] 3GPP TR 23.107.

[6] 3GPP TS 24.008.

[7] 3GPP TS 25.413.

[8] 3GPP TS 25.415.

[9] 3GPP TS 26.071.

[10] 3GPP TS 26.101.

[11] 3GPP TS 26.102.

[12] 3GPP TS 26.103.

[13] 3GPP TS 29.002.

[14] 3GPP TS 48.008.

[15] RCF–SSP INAP V6 interface (INAPI).

[16] Radio Resource Management (RM).

CIT AAC033638800DS En 5 / 103

[18] Basic Call Handling for Alcatel E10 NSS (BCH).

[19] Data Transmission, Basic Data Call Control (DA).

[20] Circuit Pool Management (TPOOLM).

[21] High Speed Circuit Switched Data (HSCSD).

[22] Man Machine commands in the RCP (MMCRCP).

[23] Functional options list (FL).

[24] Charging Data collection (CG).

[25] ISDN–BC <–> GSM–BC Translation (BCTRL).

[26] RCP–RNC RANAP Interface (RANAPI).

[27] Handling of PLMN Specific Data in HLR and RCP (PSDATA).

CIT AAC033638800DS En 6 / 103

GSM and/or UMTS:

AMR Adaptative Multi–Rate.

CIT AAC033638800DS En 7 / 103

AMR is also referred to as ”speech version 3”.

Channel Assignment refers to the GSM environment only.

AAL2 ATM Adaptation Layer type 2.

UTRAN UMTS Radio Access Network

CIT AAC033638800DS En 8 / 103

1.1 General description of the function

In GSM AMR is also known as speech version 3.