All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Alcatel. ED 1AA 00014 0004 (9007) A4 – ALICE 04.10 Y 1 01 RELEASED En CIT / AAC033638800DS 2 2 TECHNICAL DEPARTMENT Site Originators VELIZY : Domain SPEECH AND ADAPTATIVE MULTI–RATE Division Rubric AMR Type Distribution Codes Internal External : : : : ALCATEL900 SYSTEM DOCUMENTATION GENERAL ANALYSIS SPECIFICATION 9999 900000 : J. RZEZNIK ABSTRACT This document specifies the Speech Teleservice offered by the NSS in GSM since R6 and UMTS since R7. Approvals Name App. App. Name M.JACOB R.RAYNAUD M.BIGNON REVIEW Reference of the minutes SRD/TD/SYS/DFB/ES/00.171.03/MJ
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
Y 1
01
RELEASED
En
CIT /AAC033638800DS
2
2
TECHNICAL DEPARTMENTSite
Originators
VELIZY
:
Domain
SPEECH AND ADAPTATIVE MULTI–RATE
Division
Rubric
AMR
TypeDistribution Codes Internal External
::::
ALCATEL900SYSTEM DOCUMENTATIONGENERAL ANALYSISSPECIFICATION
9999 900000:
J. RZEZNIK
ABSTRACTThis document specifies the Speech Teleservice offered by the NSS in GSM since R6 and UMTS sinceR7.
Approvals
NameApp.
App.Name
M.JACOB
R.RAYNAUD M.BIGNON
REVIEW
Reference of the minutes SRD/TD/SYS/DFB/ES/00.171.03/MJ
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
Y 2
01
RELEASED
En
CIT /AAC033638800DS
2
2
HISTORY
01 on 03–01–23Creation.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 offeredthe 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
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
1
01
En
CIT /AAC033638800DS
103
103
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ED DATE CHANGE NOTE APPRAISAL AUTHORITY ORIGINATOR
01 030123 Creation CA–SYS CA–SYS
SPEECH and ADAPTATIVE MULTI–RATE AMR
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
2
01
En
CIT /AAC033638800DS
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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
3
01
En
CIT /AAC033638800DS
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 ModeRequest 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. 48Table 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . .
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
4
01
En
CIT /AAC033638800DS
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 26. SDL 2/3: Channel Type IE for assignment. 88. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 27. SDL 3/3: Channel Type IE for assignment. 89. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
5
01
En
CIT /AAC033638800DS
103
103
HISTORY
01 on 03–01–23Creation.
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.
[16] Radio Resource Management (RM).AAC020015700DS.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
6
01
En
CIT /AAC033638800DS
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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
7
01
En
CIT /AAC033638800DS
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 CapabilityMS 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
8
01
En
CIT /AAC033638800DS
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 codecmay operate at various combinations of speech and channel coding (codec mode) bit–rates for each channel modeAMR is also referred to as ”speech version 3”.in UMTS, an AMR codec, different from the GSM one, has also beendefined.
AMR handover Handover between FR and HR channel modes to optimize AMR operationChannel mode Half–rate or full–rate operationChannel mode adaptation The control and selection of the (FR or HR) channel modeCircuit 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. Thecharacteristics 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 channelson a cell or cells controlled by a single BSS. It operates without referenceto 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 12G refers to 2nd generation networks i.e. GSM networks3G 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.UTRAN UMTS Radio Access Network
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
9
01
En
CIT /AAC033638800DS
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 andUMTS 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 poorspeech quality under bad radio conditions, and especially for MS–MS calls where the quality is impairedby 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 errorsis 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 trafficconditions, 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.
One principle of AMR is to have a set of codecs, and for any radio condition, to use the one with the bestspeech quality
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
10
01
En
CIT /AAC033638800DS
103
103
Under good radio conditions, a codec with a high bit rate is used. More information is used to encodespeech, 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.
channel codingspeech coding
moving boundary according toradio conditions
Figure 1. Variable partitioning.
The codec is dynamically adapted by the MS (downlink) and the BTS (uplink). The codec used uplink canbe 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
11
01
En
CIT /AAC033638800DS
103
103
1.1.3.3 AMR functional operation.
The next figure shows in which PLMN elements the introduction of AMR induces evolutions.
TRAU
AMR channel coding
speech encoder/decoder
channel encoder/decoder
AAbis
BSC
• •
• •BTS
• •
• •����
����
RCP• •
• •
SSP
signalling speech v3 inassignment, handovers...
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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
12
01
En
CIT /AAC033638800DS
103
103
MS BTS TRAU
CodecAdaptation
CodecAdaptation
SPE
SPE
SPD CHECHD
CHE: Channel EncoderCHD: Channel DecoderSPD: Speech DecoderSPE: Speech Encoder
CHE SPDCHD
Codec Mode Indication (for uplink)
Suggested Codec Mode (for downlink)
Codec Mode Command (for uplink)
Codec Mode Indication (for downlink)
Uplink Speech Data
Downlink Speech Data
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 possibilityto 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. Thereforethe actual speech rate depends on the actual radio condition. A codec adaptation algorithm selects theoptimal speech rate (or codec mode) according to the channel quality. The codec mode adaptation relieson channel quality measurements performed in the MS and the network and on inband information senttogether with the speech data. Each link (up, down) may use a different codec mode, however the channeltype is the same, HR or FR .
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
13
01
En
CIT /AAC033638800DS
103
103
In the above figure, in both directions, the speech data are associated with a Codec Mode Indication toenable 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 codecmode, 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 thisquality information to the network as a Suggested Codec Mode.
1.1.4 AMR in UMTS
1.1.4.1 Architecture
SSP
RCP
TC
#7 signalling link
Towards PSTN/ISDNTowards UTRAN
Serving MSC
Transcoding between Iu–UPover AAL2 and TDM, andUMTS AMR codec processing
Figure 4. Architecture for speech in UMTS.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
14
01
En
CIT /AAC033638800DS
103
103
In UMTS the principle of UMTS AMR remains the same as in GSM: inband signalling between MS, RNCand Transcoder (TC) for codec mode adaptation. However, in UMTS the notion of HR and FR is no longerapplicable.
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_7.40 7.40 kbit/s
AMR_6.70 6.70 kbit/s
AMR_5.90 5.90 kbit/s
AMR_5.15 5.15 kbit/s
AMR_4.75 4.75 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 shownin 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
7.40 kbit/s 148
6.70 kbit/s 134
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
15
01
En
CIT /AAC033638800DS
103
103
Total number of bitsSource codec bit rates
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 (CodecMode Request)
The AMR speech frames are transmitted over Iu UP used in SMpSDU mode. The predefined SDU sizecorresponds 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.101Ref.[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 erroneousspeech 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 applyingerror 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 differentbit 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 ofbits
Bits inClass A
Bits inClass B
Bits inClass 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
7.95 159 75 84 0
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
16
01
En
CIT /AAC033638800DS
103
103
Bits inClass C
Bits inClass B
Bits inClass A
Total number ofbits
AMR codec mode
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. SIDis relevant when DTX is applied.
AMR codec mode Total number ofbits
Bits inClass A
Bits inClass B
Bits inClass C
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 isprovided 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
17
01
En
CIT /AAC033638800DS
103
103
Mode Indication (3 bits)
Mode Request (3 bits)
Codec CRC (8 bits)
Frame Quality Indicator (1 bit)
Frame Type (4 bits)
Class A bits
Class B bits
Class C bits
AMR Header
AMR AuxiliaryInformation (forTFO, ModeAdaptation andError Detection)
AMR Core Frame(speech or comfortnoise data)
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, comfortnoise, or other)
0 4.75 kbit/s
1 5.15 kbit/s
2 5.90 kbit/s
3 6.70 kbit/s
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
18
01
En
CIT /AAC033638800DS
103
103
Frame content (AMR mode, comfortnoise, or other)
Frame Type Index
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 ModeRequest 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’ withan SDU size of 81 bits, one for class ’B’ with an SDU size of 103 bits, and finally one for class ’C’ withan SDU size of 60 bits.
The RAB which is assigned for speech reflects the TC capabilities. The TC supports all the UMTS AMRmodes (i.e. from AMR_12.20 to AMR_SID in Table 1. ).
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
19
01
En
CIT /AAC033638800DS
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 MSpreferences and the serving BSC capabilities. It finally assigns a channel, for which the choice upon thespeech 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 speechv3.
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 speechversion 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 accordingto 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 targetMSC 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 MSpreferences which are known at the controlling MSC from the call establishment. This is similar to the GSMto 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 speechonly case, except that the selected pools must satisfy both the MS preferred speech version(s), and therequired data service.
When the call moves or reverses to a speech phase, the in–call modification procedure includes a channelassignment which is not different from an initial assignment.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
20
01
En
CIT /AAC033638800DS
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 supportsall 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 apreference between full and half rate and allow AMR handovers. This applies to the assignment, handoverand modify procedures.
This is possible at the BSS level through MMCs related to the management of the BSC (CREBSC andMODBSC) by the MSC.
All the various combinations of BSC characteristics, offer the network operator, at the geographical levelof a BSC coverage and while the network evolves in time, the possibility to either privilege AMR over otherspeech versions or to be neutral, and/or to favor one rate over the other, and/or to allow/forbid handoversbetween rates.
This finally permits to privilege a dense coverage over quality (resp. quality over dense coverage) or tofind 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 signallingbetween two AMR codecs.
1.1.8 Charging aspects.
An indication is provided in the CDRs when speech v3 has been selected upon channel assignmentcompletion.
Other provided information is whether the choice between full and half rate has been left to the BSS, withor 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 optionsF–RM–011 and F–RM–012, speech v1 can be forced to Full Rate, this to prevent from having Half Ratechannels both on calling and called sides, which would result in poor speech quality.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
21
01
En
CIT /AAC033638800DS
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 notpossible, 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 thefunctional option F–RM–010, speech v1 can be forced to Full Rate, this to prevent from having a poorspeech 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 circuitsbetween 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 themis given in the following table. They are selected for speech only or dual services with standard switcheddata services.
1.1.12 Service Handover.
Service Handover feature enables the operator to control or prompt 3G�2G handover of speech callsaccording to the country and PLMN of origin of the roamer (MCC+MNC of the subscriber’s IMSI). It is alsoapplicable to its own subscribers in their home PLMN.Low bandwidth services like speech could for instance be redirected towards GSM for the operator’s ownsubscribers, 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 orrelocation. 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).
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
22
01
En
CIT /AAC033638800DS
103
103
Pool Coding Supported channels and speech coding algorithms
circuit pool number 23 0001 0111 FR speech v3HR speech v3
circuit pool number 24 0001 1000 FR speech v3FR data (12, 6, 3.6kbps)HR speech v3
circuit pool number 25 0001 1001 FR speech v1FR speech v2FR speech v3FR data (12, 6, 3.6kbps)HR speech v3
circuit pool number 27 0001 1011 FR speech v1FR speech v2FR speech v3FR data (12, 6, 3.6kbps)HR speech v1HR speech v3HR 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 knownas AMR standing for Adaptative Multi–Rate.When the MS supports speech v3, an ordered list of speech versions, including speech v3 whenthe necessary resources are available, is sent to the BSC by the MSC at channel assignmentand handover. The ordering depends on BSC related MMCs. This enable either to force a FullRate only mode, or to force a Half Rate only mode, or else to allow both rates. It is also possibleto favor speech v3 over other speech versions. In this way miscellaneous operators needs,related to covered areas, can be satisfied.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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
23
01
En
CIT /AAC033638800DS
103
103
Otherwise, when F–RM–013 is not active, the speech version 3 MS capabilities are ignored bythe NSS and therefore cannot be used. In that case Full Rate is always preferred to Half Rateand 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 whenchosen by the MS and with indications on the choices between Full Rate and Half Rate whichhad been left to the BSC and what rate it has retained.Although, the speech version maychange. the CDR is not updated due to handover
This option only applies to the RCP.
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. Whenthis 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 BSCsin 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 thespeech 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”. Althoughthe 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 assignmentwith a default value which is not significant.
This option only applies to the RCP.
f ) Service Handover depends on a functional option.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
24
01
En
CIT /AAC033638800DS
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 roamersdepending on the MCC+MNC of their IMSI.
1.3 Involved network elements
Only the RCF is involved with the function.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
25
01
En
CIT /AAC033638800DS
103
103
2 DETAILED DESCRIPTION AND SCENARIOS
In the following scenarios the Network stands for a PSTN, an ISDN or another PLMN. The AMR relatedtreatments 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.
Signalling channel establish-ment, authentication...
BSC
MS
SETUP
RCP• •
• •• •
• •
ASSIGNMENT REQUEST
ASSIGNMENT COMPLETE
SSP�������
CREATE
(1)
(2)
(3)
RETRIEVE RESULT(4)
(5)
(8)
CALL PROCEEDING (GSM–BC)
ASSIGNMENT COMMAND(6)
ASSIGNMENT COMPLETE
(7)
Figure 6. Channel Assignment in the MOC case.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
26
01
En
CIT /AAC033638800DS
103
103
(1) After the signalling link establishment, authentication procedure and controls at the VLR, the MS mayrequest for a speech Teleservice, at version 3. To that purpose the bearer capability (GSM–BC) of theSETUP 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 thespeech 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 returnedGSM–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 SSPby 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 areactive), 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 transcodersassociated to the CICs are equipped with AMR).
In case of dual services the list of selected pools additionally takes into account the data basic servicededuced from the associated received GSM–BC. Therefore the subset is common to the MS request andthe 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 circuithas been allocated.In cases where the SSP returns a pool which does not support speech v3, due to a configuration orno 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 selectedby the SSP. They are ordered according to the preferences of the MS. This ordering may however besuperseded 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, allowingor forbidding handovers between HR and FR. These possibilities partly depend on MS preferences whichmay 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
27
01
En
CIT /AAC033638800DS
103
103
2.1.2 Channel Assignment in the MTC case.
Paging, Signalling channelestablishment, Authentica-tion...
BSC
MS
SETUP
RCP• •
• •• •
• •
ASSIGNMENT REQUEST
SSP�������
CREATE
(3)
(4)
(5)
RETRIEVE RESULT(6)
(7)
CALL CONFIRMED
IAM(1)
VMSC
Provide Instruction(2)
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
28
01
En
CIT /AAC033638800DS
103
103
BSC
MS
RCP• •
• •• •
• •
ASSIGNMENT COMPLETE
SSP�������
(10)
ASSIGNMENT COMMAND(8)
ASSIGNMENT COMPLETE
(9)
VMSC
Figure 7. Channel Assignment in the MTC case.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
29
01
En
CIT /AAC033638800DS
103
103
(1) The incoming IAM message at the VMSC indicates the request of a speech service, either through itsISDN–BC or in the multinumberring case through the GSM–BC associated to the called MSISDN, or elseif 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. Afterwardsthe 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 1is assumed.Otherwise, the MS may indicate in the GSM–BC its preferences for speech versions similarly to the OCcase. To that purpose the bearer capability (GSM–BC) of the CALL CONFIRMED message contains a listof 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 theRCF 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 areactive), 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 transcodersassociated 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 circuithas been allocated.In cases where the SSP returns a pool which does not support speech v3, due to a configuration orno 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 selectedby the SSP. They are ordered according to the preferences of the MS. This ordering may however besuperseded 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, allowingor 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
30
01
En
CIT /AAC033638800DS
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
SETUP
RCP• •
• •
ERQ Establishment Request
RAB ASSIGNMENT RESPONSE
�������
CREATE
(1)
(2)
(3)
(5)
(7)
CALL PROCEEDING (GSM–BC)
ECF Establishment Confirm
(6)
RAB ASSIGNMENT REQUEST
(4)
RNC• •
SSP Tc
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) ofthe SETUP message set to speech.All the other speech related fields of the GSM–BC are not analysed but memorised in case of a laterrequest for a handover to a 2G network.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
31
01
En
CIT /AAC033638800DS
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 GSMnetwork 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 incomingAAL2 connection request from the RNC.The TCinfo parameter is intended for the Tc and therefore forwarded by the SSP. It indicates that the Tcwill be used in SMpSDU. After having been set in SMpSDU the Tc awaits for its Iu UP initialisation by theRNC.
(4) The RAB ASSIGNMENT REQUEST sent to the RNC is built according to a subset of the codec modessupported by the Tc or all of them. The Tc supports all the UMTS AMR codec modes defined in 3GPP26.102. The parameters associated with the codec modes (i.e. SDU size, Subflow SDU size) are systemparameters.One RFC is associated to each codec mode, for each RFC three subflows are defined, one sublow beingassociated 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 SDUsize is associated to each codec mode according to the rate. The sum of the three subflow SDU sizescorresponding 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.415Ref.[8]). This procedure provides the Tc with the RAB parameters: RFC identifiers, Subflow SDU size andthe 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 UPconnection 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 supportof the GSM speech versions.
The RAB is assigned identically to the MOC case.
The Tc is always located at the serving MSC.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
32
01
En
CIT /AAC033638800DS
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 ofthis procedure by the BSS is optional.An overhead due to an increased signalling trafic may be brought to the MSC by these handovers.
BSC RCP• •
• •• •
• •SSP
(1)HANDOVER PERFORMED
MS
Intra BSSHandover
Figure 9. Intra BSS Handover
(1) The HANDOVER PERFORMED message may indicate a change in the chosen speech version andchannel rate, half or full.The new chosen speech may be version 3.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
33
01
En
CIT /AAC033638800DS
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 occasionchanges 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.
BSC RCP• •
• •• •
• •SSP
(1)
(6)
serving
HANDOVER REQUIRED
MS
HANDOVER COMMAND
BSC
• •
• •
target
speech v3 isused
(4)HANDOVER REQUEST
CREATE
(2)
RETRIEVE RESULT(3)
(5)HANDOVER REQUEST ACKNOWLEDGE
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
34
01
En
CIT /AAC033638800DS
103
103
BSC RCP• •
• •• •
• •SSP
servingMS
BSC
• •
• •
target
HANDOVER DETECT(8)
HANDOVER COMPLETE(9)
channel of and leg to serving BSS are released
(7)HANDOVER ACCESS
The fixed net-work side leg isconnected tothe target BSCleg
Figure 10. Intra MSC Handover.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
35
01
En
CIT /AAC033638800DS
103
103
(1) The HANDOVER REQUIRED message requires from the MSC to carry out a handover for a MS. THEmessage provides information on the currently used speech version and channel. It also may request theMSC 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 presentmode.
(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 assignmentprocedure. 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 accountthe data service.
(3) The RCF gets back the selected CIC and pool identification from the RETRIEVE RESULT sent by theSSP.
(4) Then a HANDOVER REQUEST message is sent to the target BSC. It contains the selected CIC andthe informations received from the serving BSC; namely the ”Old to New BSS information” , the usedspeech version and current channel type, if they have been previously received in HANDOVERREQUIRED.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 possiblyspeech v3. These versions are the versions supported by the pool selected by the SSP. They are orderedaccording to the preferences of the MS. This ordering may however be superseded by the RCP accordingto 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 choicebetween 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 accordingto 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 lateron to the MS.
(6) The HANDOVER COMMAND message provides the MS with the target channel identity chosen bythe target BSS and a handover reference in order for the this BSS to recognize the MS. It is still sent tothe 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 lattersends a HANDOVER COMPLETE messages.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
36
01
En
CIT /AAC033638800DS
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 servingMSCs may be all or partly different network nodes.
The scenarios do not differ when speech v3 functionality is involved, they are not further describedhere. See document HO Ref. [17] for full details. When F–RM–013 is active the difference lies in theChannel 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, andin 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 makethis 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 characteristicsrelated to AMR.
– at the target MSC, when F–RM–013 is active, the Channel type IE is built from the received Channeltype IE and the target BSC characteristics related to AMR. The pool list also depends on thereceived Channel type IE.
– when F–RM–013 is not active, the processing is as described in document HO Ref. [17] (i.e. theChannel type IE is modified to privilege FR speech v1 prior to be sent to the target MSC, the targetMSC does not modify the received Channel type IE).
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
37
01
En
CIT /AAC033638800DS
103
103
2.3.5 UMTS relocation
2.3.5.1 3G�3G relocation intra–MSC
RELOCATION REQUIRED
RCP• •
• •
RELOCATION REQUEST
(1)
(2)
RNC• •
RNC• •
serving target
Figure 11. 3G � 3G relocation – intra MSC
(1) The relocation procedure is triggered by the reception of a RELOCATION REQUIRED message fromthe 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 RNCto target RNC container. It requests for a single RAB defined by a RAB parameters IE defined as in theRAB assignment case.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
38
01
En
CIT /AAC033638800DS
103
103
2.3.5.2 3G�3G relocation inter–MSC
RELOCATION REQUIRED
RCP• •
• •
PREPARE HANDOVER REQUEST
RELOCATION REQUEST
(1)
(2)
(3)
RNC• •
RNC• •
RCP• •
• •
serving target
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 HANDOVERREQUEST message. It contains an AN–APDU parameter which contains a RELOCATION REQUESTmessage. 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 includedRELOCATION REQUEST are ignored.The RAB parameters sent to the RNC in RELOCATIONREQUEST are generated in the target MSC depending on local configuration of DTX and codec modes(i.e. identical to the RAB assignment case).
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
39
01
En
CIT /AAC033638800DS
103
103
2.3.5.3 3G�2G relocation intra MSC
RELOCATION REQUIRED
RCP• •
• •
HANDOVER REQUEST
(1)
(2)
RNC• •
serving target
BSC
• •
• •
Figure 13. 3G � 2G relocation – intra MSC
(1) The relocation procedure is triggered by the reception of a RELOCATION REQUIRED message fromthe SRNS. The message identifies a target BSC. It carries a Old BSS to new BSS Information IE withAMR related information.
(2) The MSC then sends a HANDOVER REQUEST message to the target BSC. It carries a Channel typeIE which contains a list of permitted speech versions and a preference between HR and FR, whichdepend 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 InformationIE. Some information as Current Channel Type 1 IE or Speech Version (Used) IE which is not relevantin UMTS are not transmitted.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
40
01
En
CIT /AAC033638800DS
103
103
2.3.5.4 3G�2G relocation inter MSC
RELOCATION REQUIRED
RCP• •
• •
PREPARE HANDOVER REQUEST
HANDOVER REQUEST
(1)
(2)
(3)
RNC• •
RCP• •
• •
serving target
BSC
• •
• •
Figure 14. 3G � 2G relocation – inter MSC
(1) The relocation procedure is triggered by the reception of a RELOCATION REQUIRED message fromthe SRNS. The message identifies a target BSC. It carries a Old BSS to new BSS Information IE withAMR related information.
(2) The PREPARE HANDOVER REQUEST message includes a HANDOVER REQUEST. It carries aChannel type IE which contains a list of permitted speech versions which, similarly to the pure GSMcase, 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 InformationIE 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 Channeltype IE which is deduced from the received Channel type IE and of which permitted speech versionsand preference between HR and FR depend, similarly to the pure GSM case, on the preferences seton the BSC, and on the pool availability. It also forwards transparently the Old BSS to new BSSInformation IE. Some information as Current Channel Type 1 IE or Speech Version (Used) IE whichis not relevant in UMTS are not transmitted.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
41
01
En
CIT /AAC033638800DS
103
103
2.3.5.5 2G�3G handover intra MSC
HANDOVER REQUIRED
RCP• •
• •
RELOCATION REQUEST
(1)
(2)
RNC• •
serving target
BSC
• •
• •
Figure 15. 2G � 3G handover – intra MSC
(1) The handover is triggered at the MSC on reception of a HANDOVER REQUIRED message from theBSC. 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 totarget RNC transparent information IE is passed transparently. The Current Channel Type 1 IE andSpeech version (Used) IE that may have been received from the BSC are ignored. The RELOCATIONREQUEST requests for a single RAB defined by a RAB parameters IE depending on configuration of DTXand codec modes (i.e. identical to the RAB assignment case. It also requests for the SMpSDU Iu modeneeded for speech.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
42
01
En
CIT /AAC033638800DS
103
103
2.3.5.6 2G�3G handover inter MSC
HANDOVER REQUIRED
RCP• •
• •
PREPARE HANDOVER REQUEST
RELOCATION REQUEST
(1)
(2)
(3)
RNC• •
RCP• •
• •
serving target
BSC
• •
• •
Figure 16. 2G � 3G handover – inter MSC
(1) The handover is triggered at the MSC on reception of a HANDOVER REQUIRED message from theBSC. It contains a Source RNC to target RNC transparent information IE.
(2) The PREPARE HANDOVER REQUEST message includes a HANDOVER REQUEST. It carries aChannel type IE which contains a list of permitted speech versions which, similarly to the pure GSMcase, 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 RNCtransparent information IE is also forwarded transparently. Some information as Current Channel Type1 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 RNCto target RNC transparent information IE is passed transparently. The Current Channel Type 1 IE andSpeech version (Used) IE that may have been received from the BSC are ignored. The RELOCATIONREQUEST requests for a single RAB defined by a RAB parameters IE based on local configuration ofDTX and codec modes (i.e. identical to the RAB assignment case). It also requests for the SMpSDU Iumode needed for speech.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
43
01
En
CIT /AAC033638800DS
103
103
2.3.6 In–call modification (successful)
A data transfer is inprogress.
BSC
MS
MODIFY
RCP• •
• •• •
• •
ASSIGNMENT REQUEST
ASSIGNMENT COMPLETE
SSP�������
(1)
(4)
(2)
(3)
MODIFY COMPLETE
call is in the speech phase,possibly with speech v3.
Figure 17. In–call modification (successful).
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
44
01
En
CIT /AAC033638800DS
103
103
(1) A MODIFY message is received by the RCF while a data service is in progress. The message carriesa 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 initialassignment case.
(3) The ASSIGNEMENT COMPLETE is returned by the BSS when the allocation has been sucessful. Thecharacteristics 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
45
01
En
CIT /AAC033638800DS
103
103
2.3.7 In–call modification (rejected)
A data transfer is inprogress.
BSC
MS
MODIFY
RCP• •
• •• •
• •SSP
�������
(1)
(2)MODIFY REJECT
The data phase is pursued.
Figure 18. In–call modification (rejected due to new received GSM–BC).
(1) A MODIFY message is received by the RCF while a data service is in progress. The message carriesa GSM–BC which must correspond to a mode already negotiated at call set up, speech in the present case.The GSM–BC is analyzed, a list of pools is deduced. However none of these pools matches the currentpool 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. whichcorresponds to a data service) and invokes the cause ”Bearer capability not authorized”. The call followson in the speech phase.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
46
01
En
CIT /AAC033638800DS
103
103
A data transfer is inprogress.
BSC
MS
MODIFY
RCP• •
• •• •
• •SSP
�������
(1)
(4)MODIFY REJECT
The data phase is pursued.
ASSIGNMENT REQUEST
ASSIGNMENT FAILURE
(2)
(3)
Figure 19. In–call modification (rejected due to assignment failure).
(1) A MODIFY message is received by the RCF while a data service is in progress. The message carriesa GSM–BC which must correspond to a mode already negotiated at call set up, speech in the present case.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 initialassignment 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. whichcorresponds to a data service) and invokes the cause ”Bearer capability not authorized”.
N.B. The In Call modification procedure is not applicable to UMTS.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
47
01
En
CIT /AAC033638800DS
103
103
3 DESCRIPTION OF INTER–ENTITIES MESSAGES
This chapter lists the messages and Information Elements involved with the function. However, theirdescriptions are only partially provided because restricted only to those fields directly necessary to thefunction. For a thorough picture see the related recommendations 3GPP TS 24.008 Ref. [6] and 3GPPTS 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 messagethe 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 theMS. Were they present the RCF would ignore them.
octet 3bits 3 2 1
meaningInformation transfer capability
0 0 0 speech
Table 8. GSM–BC – Speech Teleservice request.
In UMTS the ITC is sufficient to request for speech. The other speech related parameters described hereare 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 HRwith 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 speechv1 MS, FR preferred” ).
In case of octet ”3a etc” presence, then the MS supports at least speech version 1 FR, and optionallyspeech version 1 HR with a preference between HR and FR. This is indicated in octet 3 bits 76 as describedin the following table.
The extension octets ”3a etc” are only checked if option F–RM–005 is active.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
48
01
En
CIT /AAC033638800DS
103
103
octet 3bits 7 6
meaning
0 1 The MS supports at least FR speech v1 but does not support HRspeech v1. The complete voice codec preference is specified inoctet(s) 3a etc.
1 0 The MS supports at least FR speech v1 and HR speech v1. The MShas a greater preference for HR speech v1 than for FR speech v1. Thecomplete voice codec preference is specified in octet(s) 3a etc.
1 1 The MS supports at least FR speech v1 and HR speech v1. The MShas a greater preference for FR speech v1 than for HR speech v1. Thecomplete 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 etcbits 4 3 2 1
meaning codec
0 0 0 0 GSM full rate speech version 1 1st generation
0 0 1 0 GSM full rate speech version 2 EFR
0 1 0 0 GSM full rate speech version 3 AMR
0 0 0 1 GSM half rate speech version 1 1st generation
0 1 0 1 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 whenreceived. 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 isignored by the RCF when received. If none of these versions is supported or known by the RCF the version1 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, thecontent 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,– 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,
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
49
01
En
CIT /AAC033638800DS
103
103
If RCR indicates no other speech codec than v1 (i.e. there is no octet 3a), the present function cannot ofcourse be activated.
The values ”GSM full rate speech version 3” or ”GSM half rate speech version 3” are only taken intoaccount 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 thereis none, speech version 1 as defined in octet 3 is assumed (i.e. the support of GSM full rate speech version1 is mandatory).
In the MTC case, when speech is requested, the MSC sends a SETUP message to the MS, possibly witha GSM–BC. As already indicated the GSM–BC octets ”3a etc...” are absent. See also BCTRL Ref. [25]for further details.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
50
01
En
CIT /AAC033638800DS
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 MSmay 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
information element type length
GSM–BC (Bearer Capabilities) M
Table 11. MSC–MS: CALL CONFIRMED message
The GSM–BC IE follows the same pattern and analysis as for the SETUP message.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
51
01
En
CIT /AAC033638800DS
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
information element type length
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 notpresent 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 caseof an alternate service and no GSM–BC is returned when the speech teleservice alone has been invoked.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
52
01
En
CIT /AAC033638800DS
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 versawhen a dual service has been negotiated at call set up.
MS�MSC: MODIFY
information element type length
GSM–BC (Bearer Capabilities) M
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 IEis analyzed following the same pattern.
The In Call Modification procedure is not applicable to UMTS, MODIFY cannot be received in that environ-ment.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
53
01
En
CIT /AAC033638800DS
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
information element type length
GSM–BC (Bearer Capabilities) M
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 onereceived in the MODIFY message, except for the speech versions preferences which are meaninglessin the MSC� MS way and therefore should be removed from the received GSM–BC.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
54
01
En
CIT /AAC033638800DS
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
information element type length
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 derivedfrom the GSM–BC IE negotiated at call set up. When AMR is used the informations it carries additionallydepend 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 forthe leg towards the BSC.
When AMR is used the values of the Channel Type IE fields are as described in the next subsection.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
55
01
En
CIT /AAC033638800DS
103
103
3.2.1.1 Channel Type IE description
12345678
Element identifier
Length
octet 1
octet 2
octet 3
Channel rate and type octet 4
Permitted speech version identifier octet 5
spare Speech/data indicator
Permitted speech version identifier octet 5a
Permitted speech version identifier octet 5b
Permitted speech version identifier octet 5c
Permitted speech version identifier octet 5d
Permitted speech version identifier octet 5e
ext
ext
ext
ext
ext
0
Figure 20. Channel Type IE.
octet 3bits 4 3 2 1
meaning
0 0 0 1 speech
Table 16. Channel Type IE – Speech / data indicator field.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
56
01
En
CIT /AAC033638800DS
103
103
octet 4 meaning
bits 8 7 6 5 4 3 2 1 code
0 0 0 0 1 0 0 0 8 Full rate TCH channel Bm.Preference between the permitted speech versions forfull rate TCH as indicated in octet 5, 5a etc...
0 0 0 0 1 0 0 1 9 Half rate TCH channel Lm.Preference between the permitted speech versions forhalf rate TCH as indicated in octet 5, 5a etc...
0 0 0 0 1 0 1 0 A Full or Half rate TCH channel, Full rate preferred,changes between full and half rate allowed also after firstchannel allocation as a result of the request.Preference between the permitted speech versions forthe respective channel rates as indicated in octet 5, 5aetc...
0 0 0 0 1 0 1 1 B Full or Half rate TCH channel, Half rate preferred,changes between full and half rate allowed also after firstchannel allocation as a result of the request.Preference between the permitted speech versions forthe respective channel rates as indicated in octet 5, 5aetc...
0 0 0 1 1 0 1 0 1A Full or Half rate TCH channel, Full rate preferred,changes between full and half rate not allowed after firstchannel allocation as a result of the request.Preference between the permitted speech versions forthe respective channel rates as indicated in octet 5, 5aetc...
0 0 0 1 1 0 1 1 1B Full or Half rate TCH channel, Half rate preferred,changes between full and half rate not allowed after firstchannel allocation as a result of the request.Preference between the permitted speech versions forthe respective channel rates as indicated in octet 5, 5aetc...
0 0 0 0 1 1 1 1 F Full or Half rate TCH channel.Preference between the permitted speech versions asindicated in octet 5, 5a etc..., changes between full andhalf rate allowed after first channel allocation as a resultof the request.
0 0 0 1 1 1 1 1 1F Full or Half rate TCH channel.Preference between the permitted speech versions asindicated in octet 5, 5a etc..., changes between full andhalf rate not allowed after first channel allocation as aresult of the request.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
57
01
En
CIT /AAC033638800DS
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 managedby MMCs. Of course, that comes in addition to the MS and network possibilities.
octet 5, 5a, 5b...bits 7 6 5 4 3 2 1
meaning
0 0 0 0 0 0 1 GSM speech full rate version 1
0 0 1 0 0 0 1 GSM speech full rate version 2
0 1 0 0 0 0 1 GSM speech full rate version 3
0 0 0 0 1 0 1 GSM speech half rate version 1
0 0 1 0 1 0 1 GSM speech half rate version 2 (1)
0 1 0 0 1 0 1 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 correspondingcodec 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 halfand/or full rate speech v3 may depend on the operator specific requirements as expressed through BSCcharacteristics managed by MMCs.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
58
01
En
CIT /AAC033638800DS
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 beencompleted by the BSS.
BSC�MSC: ASSIGNMENT COMPLETE
information element type length
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 beeninvoked.
When the function is invoked the Chosen Channel IE is coded as follows:
octet 2bits 8 7 6 5
meaning
1 0 0 1 speech (full rate or half rate)
octet 2bits 4 3 2 1
meaning
1 0 0 01 0 0 1
Full rate TCHHalf rate TCH
Table 20. Chosen Channel IE.
The Speech Version (Chosen) IE is included at least when the choice of speech version has been madeby the BSS. It is the case when a list of speech versions has been provided in the Channel Type IE of theASSIGNMENT REQUEST message.However, it may happen that a BSC does not return the Speech Version (Chosen) IE even if it has madea 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 CHANNELASSIGNMENT REQUEST.
Speech Version (Chosen) IE is coded in the same way as the permitted speech version identifier in theChannel type IE.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
59
01
En
CIT /AAC033638800DS
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 beenaborted by the BSS due to a failure.
BSC�MSC: ASSIGNMENT FAILURE
information element type length
Cause M 3–4
Table 21. MSC–BSC: CHANNEL ASSIGNMENT FAILURE message
The Cause IE may be ”requested speech version unavailable”.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
60
01
En
CIT /AAC033638800DS
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 allocationthe handover has been aborted.
BSC�MSC: HANDOVER FAILURE
information element type length
Cause M 3–4
Other values for Cause IE and related to the function are:– ”requested speech version unavailable”.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
61
01
En
CIT /AAC033638800DS
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
information element type length
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 waythis IE is managed is described further in the document. When F–RM–013 is active it may depend onthe MS preferences and BSC characteristics.
The Circuit Identity Code IE is included by the RCP, it corresponds to the circuit allocated by the SSPfor 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 aHANDOVER 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 aHANDOVER 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 previouslyreceived in a HANDOVER REQUIRED or RELOCATION REQUIRED message. In this case the sent IEis equal to the received one.
The Source RNC to target RNC transparent information (UMTS) IE is the exact copy of the same IEpreviously included by the BSS in a HANDOVER REQUIRED or by the RNC in a RELOCATIONREQUIRED. It is a container passed transparently to the tartget RNC by the CN. It may carry speechrelated information.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
62
01
En
CIT /AAC033638800DS
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 targetBSS can be supported.
BSC�MSC: HANDOVER REQUEST
information element type length
Chosen Channel O 2
Speech Version (Chosen) 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 v3if it has been previously given as Permitted speech version.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
63
01
En
CIT /AAC033638800DS
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 hasa dedicated resource assigned.
BSC�MSC: HANDOVER REQUIRED
information element type length
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 speechv3.
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 multiratecodec configuration.
The Source RNC to target RNC transparent information (UMTS) IE is included by the BSS in case ofhandover with UMTS. It is a container passed transparently to the tartget RNC by the CN. It may carryspeech related information.
12345678
Element identifier
Speech version identifierspare
octet 1
octet 2
Figure 21. Speech Version IE.
The Speech version identifier is coded in the same way as the Speech version identifier field in the Channeltype IE.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
64
01
En
CIT /AAC033638800DS
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
information element type length
Cause M 3–4
Chosen Channel O 2
Speech Version (Chosen) 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 bespeech version 3, if it was a permitted choice offered to the BSC.
No check is performed on Chosen Channel IE and Speech Version IE.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
65
01
En
CIT /AAC033638800DS
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 Symmetricbidirectional
Maximum Bit Rate 12.2kbit/s maximum codec modefrom 4.75kbit/s to 12.2kbit/s
depends on selected codec(s)
Guaranteed Bit Rate 4.75kbit/s minimum codec modefrom 4.75kbit/s to 12.2kbit/s
depends on selected codec(s)
Delivery Order delivery orderrequested
Maximum SDU size 244 associated with maximumcodec mode
depends on selected codec(s)ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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 concealmentwill be applied
SDU format information Parameter: 12.2kbit/s
Subflow SDU size 81 depends on a PLMN data
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
66
01
En
CIT /AAC033638800DS
103
103
SDU format information Parameter: 10.2kbit/s
Subflow SDU size 65 depends on a PLMN data
SDU format information Parameter: 7.95kbit/s
Subflow SDU size 75 depends on a PLMN data
SDU format information Parameter: 7.40kbit/s
Subflow SDU size 61 depends on a PLMN data
SDU format information Parameter: 6.70kbit/s
Subflow SDU size 58 depends on a PLMN data
SDU format information Parameter: 5.90kbit/s
Subflow SDU size 55 depends on a PLMN data
SDU format information Parameter: 5.15kbit/s
Subflow SDU size 49 depends on a PLMN data
SDU format information Parameter: 4.75kbit/s
Subflow SDU size 42 depends on a PLMN data
SDU format information Parameter: 1.80kbit/s
Subflow SDU size 39 depends on a PLMN data
SDU format information Parameter: 0kbit/s
RAB Subflow Combination BitRate
0 0 kbit/s for DTXdepends 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–detection–
consideration
SDUs are always delivered,without error indication.
SDU format information Parameter: 12.2kbit/s
Subflow SDU size 103 depends on a PLMN data
SDU format information Parameter: 10.2kbit/s
Subflow SDU size 99 depends on a PLMN data
SDU format information Parameter: 7.95kbit/s
Subflow SDU size 84 depends on a PLMN data
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
67
01
En
CIT /AAC033638800DS
103
103
SDU format information Parameter: 7.40kbit/s
Subflow SDU size 87 depends on a PLMN data
SDU format information Parameter: 6.70kbit/s
Subflow SDU size 76 depends on a PLMN data
SDU format information Parameter: 5.90kbit/s
Subflow SDU size 63 depends on a PLMN data
SDU format information Parameter: 5.15kbit/s
Subflow SDU size 54 depends on a PLMN data
SDU format information Parameter: 4.75kbit/s
Subflow SDU size 53 depends on a PLMN data
SDU format information Parameter: 1.80kbit/s
Subflow SDU size 0 depends on a PLMN data
SDU format information Parameter: 0kbit/s
RAB Subflow Combination BitRate
0 0 kbit/s for DTXdepends on a PLMN dataÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
SDU parameters : Subflow 3 Class C
Residual Bit Error Ratio 5*10–3 defined as PLMN data
Delivery of Erroneous SDU No–error–detection–
consideration
SDUs are always delivered,without error indication.
SDU format information Parameter: 12.2kbit/s
Subflow SDU size 60 depends on a PLMN data
SDU format information Parameter: 10.2kbit/s
Subflow SDU size 40 depends on a PLMN data
SDU format information Parameter: 7.95kbit/s
Subflow SDU size 0 depends on a PLMN data
SDU format information Parameter: 7.40kbit/s
Subflow SDU size 0 depends on a PLMN data
SDU format information Parameter: 6.70kbit/s
Subflow SDU size 0 depends on a PLMN data
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
68
01
En
CIT /AAC033638800DS
103
103
SDU format information Parameter: 5.90kbit/s
Subflow SDU size 0 depends on a PLMN data
SDU format information Parameter: 5.15kbit/s
Subflow SDU size 0 depends on a PLMN data
SDU format information Parameter: 4.75kbit/s
Subflow SDU size 0 depends on a PLMN data
SDU format information Parameter: 1.80kbit/s
Subflow SDU size 0 depends on a PLMN data
SDU format information Parameter: 0kbit/s
RAB Subflow Combination BitRate
0 0 kbit/s for DTXdepends on a PLMN data
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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 IEindicates the characteristics
of the source, which isspeech here.
>>User Plane Information
IE value comment
User Plane mode SMpSDU
>>Service Handover
IE value comment
Service Handover IE accordingF–HO–014and tableSHPLMN
Parameter to control hand-overs towards 2G.
Table 26. RAB ASSIGNMENT REQUEST
In the RAB ASSIGNMENT REQUEST described in above table, only the information relevant to speechis provided. See document RANAPI Ref.[26] to get the whole description of the message.
The message definition according to 3GPP TS 25.413 Ref.[7] makes provisions for the establishment ofmultiple RABs and for the release of RABs in case of multiple RABs already established.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
69
01
En
CIT /AAC033638800DS
103
103
Provision of speech necessitates a single RAB. That is why only the first section of the message ’RABsto 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 takenas default values.
The RAB parameters IE carries selected codec modes which constitute a subset of the codec modessupported 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 IEdepends 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 thoseof Table 3.
RAB parameters IE describes each class A, B and C separately. Within each class the selected codecmodes 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 to12.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 isgiven in Table 3.
The RAB Subflow Combination Bit Rate and the 1.80kbit/s subflow (SID ) are present only when DTXis applied, i.e. when DTXAMR PLMN data is set to ON. For SID the values of RAB Subflow SDU sizeIE are those of Table 4.
The User Plane mode IE of the ’User Plane Information’ section of the message requests for the Iu UPSMpSDU 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 MMCMODSHO. See further in the document.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
70
01
En
CIT /AAC033638800DS
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 requestmessage
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 foundin 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
71
01
En
CIT /AAC033638800DS
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 forthe relocation of the UE.
MSC�RNC: RELOCATION REQUEST
IE value comment
Source RNC to target RNC transparent con-tainer.
Transferred transparently asreceived.
RABs to be setup
IE value comment
>>Servic e Handover
IE value comment
Service Handover IE accordingF–HO–014and tableSHPLMN
Parameter to control hand-overs towards 2G.
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. Theselected 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 passedfrom 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 MMCMODSHO. See further in the document.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
72
01
En
CIT /AAC033638800DS
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-tainer.
Transferred transparently asreceived.
Old BSS to new BSS Information. Transferred transparently asreceived.
In case of a 3G target, the Source RNC to target RNC transparent container carries information to betransparently 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 betransparently passed from SRNC to target BSS.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
73
01
En
CIT /AAC033638800DS
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 orthe fixed network.
In UMTS, the purpose of the CREATE is to have the SSP ready for an incoming AAL2 connection fromthe RNC. In that case no RETRIEVE operation is performed by the RCF.
RCF�SSP: CREATE
information element type length
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 anordered 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 supportHR 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
74
01
En
CIT /AAC033638800DS
103
103
3.4.2 RETRIEVE RESULT
This message, received from the SSP by the RCF, gives the selected pool and CIC when the CREATErequest 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
information element type length
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 aBSC included a list of pools. It represents the pool selected amid the list of preferred pools provided bythe RCP. If speech v3 is requested, the selected pool should support this version to follow on the callwith speech v3. In case this information is not present while expected by the RCP, or invalid, the call isreleased.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
75
01
En
CIT /AAC033638800DS
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-ument BCTRL Ref. [25].
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 andMODBSC.
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 beencreated at the SSP for each controlled BSC which is intended to support AMR before activatingF–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 introductionof 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. Aserroneous SDUs are delivered with error indication for class A only, SDU Error Ratio is applicable to thatclass 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).ON is the default value at the introduction of the function.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
76
01
En
CIT /AAC033638800DS
103
103
The selected codec mode(s) among [4.75kbit/s to 12.2kbit/s] to be put in RAB assignment and relocationmessages depend on a PLMN data. At least one codec mode must be selected. At the introduction of thefunction all the codec modes are selected by default.MxBR, GBR and Maximum SDU size are set according to the codec mode(s) actually selected asdescribed 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 isactive, 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 allowingboth rates. Of course when the MS indicates only FR (resp.HR), the RCP does not compel the useof HR (resp.FR).When it is equal to NONE, the BSC does not yet support AMR.
– AMRPRATE can be HR, FR, MSthis parameter is only meaningful when AMRRATE=BOTH. When set to MS, the RCF abides by theMS 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 MSspeech 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 unchangedcompared 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 conditionof 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 HRv1 depends on F–RM–001.
Otherwise when F–RM–005 is active, multispeech version is offered, in particular speech v3 can be pro-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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
77
01
En
CIT /AAC033638800DS
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-ument BCTRL Ref. [25].
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 valueis 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 whenthe handover is requested. The analysis is identical to the GSM case at call setup and is described in thissection.
The following SDL describes the process to analyze the speech version(s) supported by a MS accordingto 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 lateruse during the handover procedure, and named MS–SPEECH–V–STORED. MS–SPEECH–V–STOREDis 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
78
01
En
CIT /AAC033638800DS
103
103
GSM–BC analysisfor speech ver-sion 1/2GSM–BC analysis
ITC=speech ofoctet 3
N
supported speechVi indicated byoctet(s) 3a
F–RM–005 activeN
bit321=000,meaning speech
MS supportsspeech V1 FR,and optionally HR
the MS supportsmultiple speechversions
ext bit of octet 3set
N
EraseMS–SPEECH–V
2
only speech v1offered if optionnot active
bits 76 of oct 3
10
HR/FR v1
11
FR/HR v1
01
FR v1
speech FR v1only
speech FR+HRv1HR preferred
speech FR+HRv1FR preferred
MS supports atleast speech v1
Figure 22. SDL 1/2: Received GSM–BC analysis against speech version.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
79
01
En
CIT /AAC033638800DS
103
103
GSM–BC analysisfor speech ver-sion 2/2
HR and/or FR V3indicated in
oct(s)3a
N
AMR speechcodec
speech other thanAMR as indicatedin oct3a
ext bit of oct 3aset
Y
oct 3a speechversion supported
by RCF
NF–RM–013 active
N
1
1
MS supportsspeech V1 FR,and optionally HR
bit 7 of oct 3aindicates exten-
sion of ITC
Nbit 7=0 meansoct3a is an exten-sion of ITC
next octet 3a ana-lyzed
UpdateMS–SPEECH–V
UpdateMS–SPEECH–V
UpdateMS–SPEECH–V
1 1Speech V1
already in tableMS–SPEECH–V
Y
copy fromMS–SPEECH–V
Copy toMS–SPEECH–V–STORED
2
speech v1 sup-ported by MSaccording to RCRbits76 of oct 3
end of oct 3aextensions
”speech tbd”... orother not sup-ported versionsare ignored
dual serviceN
all HR speech vremoved fromMS–SPEECH–V
if two GSM–BChave beenreceived
onlyMS–SPEECH–Vis updated
Figure 23. SDL 2/2: Received GSM–BC analysis against speech version.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
80
01
En
CIT /AAC033638800DS
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 SSPare 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 tableMS–SPEECH–V has been created.
The following table of this section provides a list of pools in association to each combination of speechversions 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 theMS 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 wasteof 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 dualservices 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 towardsthe BSC.
Some pools of the list may not be physically present on the SSP/BSC interface, but it does not matterbecause 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 halfrate speech v3.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
81
01
En
CIT /AAC033638800DS
103
103
MS supported speech ver-sions
pools(speech only or basic dual service)
GSM full rate speech v1GSM full/half rate speech v3
25, 27, 23, 24, 1, 3, 5, 7
GSM full rate speech v1GSM half rate speech v1GSM full/half rate speech v3
27, 25, 23, 24, 3, 7, 1, 5, 6
GSM full rate speech v1GSM full rate speech v2GSM full/half rate speech v3
25, 27, 23, 24, 5, 7, 4, 6, 1, 3
GSM full rate speech v1GSM half rate speech v1GSM full rate speech v2GSM full/half rate speech v3
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 thatmay 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 speechv3 transcoders are considered fallback solutions in cases where the SSP has been misconfigured or nofree pool with speech v3 is left. That increases the probability to still process the call when no speech v3transcoder is available. The following table gives a description of these additional pools.
Pool Coding Supported channels and speech coding algorithms
circuit pool number 1 0000 0001 FR speech v1FR data (12, 6, 3.6kbps)
circuit pool number 3 0000 0011 FR speech v1FR data (12, 6, 3.6kbps)HR speech v1HR data (6, 3.6kbps)
circuit pool number 4 0000 0100 FR speech v2FR data (12, 6, 3.6kbps)
circuit pool number 5 0000 1010 FR speech v1FR speech v2FR data (12, 6, 3.6kbps)
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
82
01
En
CIT /AAC033638800DS
103
103
Supported channels and speech coding algorithmsCodingPool
circuit pool number 6 0000 0110 FR speech v2FR data (12, 6, 3.6kbps)HR speech v1HR data (6, 3.6kbps)
circuit pool number 7 0000 0111 FR speech v1FR speech v2FR data (12, 6, 3.6kbps)HR speech v1HR data (6, 3.6kbps)
Table 30. Fallback pools without support of speech v3.
Pool selection
Pool selection
dual servicerequested
Y
remove poolswithout datatranscoders
get pools fromPOOL–BASIC
build TRAU typesIE of CREATErequest
according toMS–SPEECH–V
Figure 24. SDL: Selection of the pools.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
83
01
En
CIT /AAC033638800DS
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 whichdescribes 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 theBSC supports multi versions of speech but not speech v3 (i.e. when AMRRATE=NONE), the ChannelType 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 theChannel type IE of the ASSIGNMENT REQUEST, their order of appearance will not necessary be thesame. 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 theBSC characteristics.
At first, the pool which has been selected by the SSP is checked. The requested speech versions whichare not supported by the pool are removed from MS–SPEECH–V. If no speech v3 is left the Channel TypeIE is then built according to document RM Ref. [16] with F–RM–013 not active. Otherwise, the treatmentis as follows.
When AMRRATE is NONE, the behaviour is the same as it was up to release R5. The ordering of thespeech versions is made as described in document RM Ref.[16] (i.e. FR preferred, from highest to lowestspeech version).
When AMRPRATE is different from MS, MS–SPEECH–V is reshuffled in order that speech versionsappear 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,– speech FR v1.
When AMRPRATE is MS, AMR–SPEECH–V is kept unchanged as input table.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
84
01
En
CIT /AAC033638800DS
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 ratewhich 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 BSCcharacteristic indicates the opposite rate, then the MS rate is kept in the Channel Type IE. This is possiblebecause 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 isreversed 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(MS–SPEECH–V)
Operator’s preferences ASSIGNMENT REQ
Channel type IE
MS speech preferences AMRRATE
AMRPRATE
AMRHO
Permitted
speech
version
Channel
rate and
type
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
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
85
01
En
CIT /AAC033638800DS
103
103
Channel
rate and
type
Permitted
speech
version
AMRHO
AMRPRATE
AMRRATE
MS speech preferences
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 v3GSM 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 v3HR v3
A
BOTH FR N FR v3HR v3
1A
BOTH HR Y HR v3FR v3
B
BOTH HR N HR v3FR v3
1B
BOTH MS Y FR v3HR v3
F
BOTH MS N FR v3HR v3
1F
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
86
01
En
CIT /AAC033638800DS
103
103
Channel
rate and
type
Permitted
speech
version
AMRHO
AMRPRATE
AMRRATE
MS speech preferences
GSM half rate speech v3 FR Y FR v3 8GSM full rate speech v3
FR N FR v3 8
HR Y HR v3 9
HR N HR v3 9
BOTH FR Y FR v3HR v3
A
BOTH FR N FR v3HR v3
1A
BOTH HR Y HR v3FR v3
B
BOTH HR N HR v3FR v3
1B
BOTH MS Y HR v3FR v3
F
BOTH MS N HR v3FR v3
1F
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 replacedby ’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 areincluded in order of the channel rate preferences. Within a set of permitted speech versions for achannel 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
87
01
En
CIT /AAC033638800DS
103
103
– if no preference for a specific rate is indicated, the permitted speech versions are included in orderof speech version preferences.
Channel Type IEfor assignment1/3
Channel Type IE
reshuffle MS–SPEECH–V
HR/FR reorderedspeech versionsordered for eachrate
AMRRATE
B
FR
C
HR
E
BOTH
MS rate
B
FR only
C
HR only
E
BOTH
1
2
code ’8’ code ’9’ code ’8’
all the speechversions of MS–SPEECH–V areconsidered
all HR of MS–SPEECH–Vremoved
remove not sup-ported speech vMS–SPEECH–V
requested speechv supported byselected pool
Y
at least onespeech v3 left inMS–SPEECH–V
N
treatment accordingto Ref. [16] withF–RM–013 notactive
reshuffle MS–SPEECH–V
Figure 25. SDL 1/3: Channel Type IE for assignment.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
88
01
En
CIT /AAC033638800DS
103
103
Channel Type IEfor assignment2/3
MS rate
B
FR only
C
HR only
E
BOTH
code ’8’ code ’9’ code ’9’
all the speechversions of MS–SPEECH–V areconsidered
1
all FR of MS–SPEECH–Vremoved
Figure 26. SDL 2/3: Channel Type IE for assignment.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
89
01
En
CIT /AAC033638800DS
103
103
Channel Type IEfor assignment3/3
MS rate
B
FR only
C
HR only
E
BOTH
code ’8’ code ’9’
code ’B’
all the speechversions of MS–SPEECH–V areconsidered
2
3
AMRPRATE
3
B
FR
C
HR
E
MS
AMRHON
code ’A’code ’1A’
AMRHON
code ’1B’
AMRHON
code ’F’ code ’1F’
all FR speech vbome before HRspeech v
all FR speech vcome before HRspeech v
all HR speech vcome before FRFR speech v
all HR speech vcome before FRspeech v
speech v orderedas MS–SPEECH–V
speech v orderedas MS–SPEECH–V
Figure 27. SDL 3/3: Channel Type IE for assignment.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
90
01
En
CIT /AAC033638800DS
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 bythe 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 constitutea subset of the codec modes supported by the Tc. The Tc supports all the codec modes defined in 3GPPTS 26.102 Ref.[11] from 4.75kbit/s to 12.2kbit/s, the 1.80kbit/s rate for comfort noise and DTX. The codecmodes 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 asdescribed 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 UPprocedure, upon its completion the Iu UP connection between RNC and TC is established in SMpSDUmode. 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 3GPPTS 26.071 Ref.[8]). These parameters are a consistent subset wich reflects the common capabilities ofthe 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 TimingInterval (ITI) is deduced from the Maximum SDU size and Maximum Bit Rate. With the 12.2kbit/s codecmode 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 ASSIGNMENTRESPONSE. 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 comfortnoise 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 anda 1.80kbit/s sublow is defined in the RAB parameters IE of RAB ASSIGNMENT REQUEST andRELOCATION REQUEST messages. Iu initialisation procedure forwards these information to the TCwhich applies DTX.
When DTX is not activated, neither RAB Subflow Combination Bit Rate parameter nor the 1.80kbit/ssubflow are part of the RAB parameters IE.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
91
01
En
CIT /AAC033638800DS
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–BCIE 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 theNSS only if speech multiversion is available (i.e. F–RM–005 is active) and the functional option associatedwith 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 asdescribed above.
If the functional option F–RM–005 ”speech multi–version support” is not active, only speech version 1 issupported by the NSS.
If the functional option F–RM–005 is active, but F–RM–013 is not, then the usual version 1, or version2 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–BCit 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 directlycreated toward the BSS. In that case all the circuits must be equipped with transcoders able to handlespeech 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 areable to handle speech v3. Following the GSM recommendations the pools they belong to are given inTable 6. To establish a leg towards the BSS, a CREATE request is sent to the SSP which contains a listof 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 whenF–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 thepermitted 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 isconstructed according to section 4.3.3.4.
It is acknowledged by an ASSIGNMENT COMPLETE message which normally gives the used speechversion in the Speech version (chosen) IE.
If the chosen speech version IE is not present, the speech version indicated by the Permitted speechversion identifier (see section 3.2.1.1) in octet 5 of Channel type IE is assumed to have been chosen.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
92
01
En
CIT /AAC033638800DS
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 speechTS. 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 itsends 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 SETUPmessage. 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. Themessage 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 ITCfield is set to ’speech’. The UE returns back a CALL CONFIRMED with possibly a GSM–BC. If it doesnot 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 memorisedin case of later need for handover. If the MS has not provided a GSM–BC it is considered to support onlyFR 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 UPconnections. 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 theIu UP necessary mode for speech.
In the same time the RCP sends to the RNC the RAB ASSIGNMENT REQUEST which has been builtaccording to 4.3.3.5.
The SSP sets the previously allocated TC into the SMpSDU mode, the RNC then establishes the AAL2connection 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 codecmodes supported by TC, RNC and UE in common.
Upon successful Iu UP inital procedure the RNC acknowledges the RCP with RAB ASSIGNMENTRESPONSE.
From now on the speech teleservice is available.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
93
01
En
CIT /AAC033638800DS
103
103
4.3.3.9 Paging in UMTS
In UMTS the PAGING message (refer to BCH Ref.[18]) includes an optional Paging cause parameterwhich 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 VLRby 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 ofthe type of call
ITC=speech?Y Speech
Paging Cause =Terminating
Conversational
No Paging Causeparameterincluded
data calltreatment
refer to documentCDU
PLMN–BC avail-able?
N
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 ChannelType IE. Since a target RCP may have no knowledge of the received GSM–BC, and the characteristicsof the target BSC may differ from those of the serving BSC, the Channel Type IE has to be determinedin 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–
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.’.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
94
01
En
CIT /AAC033638800DS
103
103
The above rule applies in the 2G�2G handover and in the 3G�2G handover cases. In the latter casethe 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 internalhandover. 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 forinformation, the RCP performs no specific associated treatment.
The HANDOVER PERFORMED message may describe the characteristics of the new channel with aChosen Channel IE and a Speech Version (Chosen) IE. At any receiving MSC no check is performed onthese 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
The treatment described here is confined to AMR. A thorough picture if available from documents [17] and[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 alsocontain 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 halfrate 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 latersent to the target BSS. When none has been received, a Speech version (used) is nevertheless sent inthe HANDOVER REQUEST based on the last received speech version (in ASSIGNMENT COMPLETE,HANDOVER PERFORMED or HANDOVER REQUEST ACKNOWLEDGE). However, the inclusion ofSpeech 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 BSSby the RCP in the HANDOVER REQUEST. This IE may contain a MultiRate configuration informationField Element which gives informations about the current AMR speech codec configuration. The targetBSS 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–Vcomes from MS–SPEECH–V–STORED which had been memorized upon GSM–BC analysis, and takesinto account the characteristics of the target BSS (AMRRATE, AMRPRATE, AMRHO). The pool selectedby the SSP is also checked as in the assignment case to remove not supported speech versions. Finallythe 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. WhenF–RM–007 is active, the list of pools is built up according to 4.3.3.3 and also depends on the receivedGSM–BC.
If the target BSS can support the handover it sends back a HANDOVER REQUEST ACKNOWLEDGEmessage with a Speech version (Chosen) IE and a Chosen channel IE. In our case, the speech versionmay be v3.
When the handover finally succeeds a HANDOVER COMPLETE message is received by the RCF.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
95
01
En
CIT /AAC033638800DS
103
103
4.3.3.10.4 Inter–MSC handover within a GSM PLMN
The treatment described here is confined to AMR. A thorough picture if available from documents [17] and[18].
When the handover procedure involves more than one MSC, the HANDOVER REQUEST message isexchanged on the E interface between MSCs, encapsulated within MAP operation PrepareHandover(invoke). In return a HANDOVER REQUEST ACKNOWLEDGE or HANDOVER FAILURE is received fromthe target MSC, encapsulated in the PrepareHandover (result) MAP operation. The HANDOVERREQUEST always carries a Channel type IE. When F–RM–005 and F–RM–013 are active, this IE maycontain 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 HANDOVERREQUEST to the target RCF.
At the target MSC, when F–RM–007 is active, the Channel type IE of the received HANDOVER REQUESTis used according to section 4.3.3.3 text and Table 29. to get an appropriate list of pools for the leg creationtoward the target BSS. However, pools without support of data (e.g. pool number 23) are removed fromthe list of pools provided to the SSP. The rationale is, the target MSC being not aware of the type of thecall, speech only or dual speech/data, a selected pool without data support would cause the rejection ofa 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 HANDOVERREQUEST to the controlling MSC, with a Channel Type IE. This IE is ignored by the controlling MSC, whichbuilds a new Channel Type IE as in 4.3.3.10.4 case a ). This new Channel Type IE is forwarded to thetarget 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. poolnumber 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 controllingMSC.
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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
96
01
En
CIT /AAC033638800DS
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 controlledby 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 sameas in 4.3.3.10.4 case a ).
When an intra–BSS handover occurs at a serving MSC, different from the controlling MSC, a HANDOVERPERFORMED message is sent to the controlling MSC through the E interface encapsulated within theMAP operation Process Access Signalling.
The reception of HANDOVER PERFORMED message at the controlling MSC means that the serving BSShas performed an internal handover. In particular, it is the case when AMR handovers occur between FRand 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 withspeech. The only information which is carried over between 3G MSCs is related with the UMTS AMRcodec modes supported by the TC. This is a consequence of the possible configuration where Iu UP overAAL2 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 thereforealways 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 itsserving 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 identicallyto 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. Thismessage carries a RANAP Iu RELOCATION REQUEST in a AN–APDU container (see 3GPP TS 29.002Ref.[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 areignored. RAB parameters IE are instead replaced in the RELOCATION REQUEST message sent to thetarget RNC with parameters depending on the target MSC configuration of DTX and codec modes (targetMSC PLMN data) as for 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].
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
97
01
En
CIT /AAC033638800DS
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 associatedwith speech.
The handover is triggered by the Serving BSC sending a HANDOVER REQUIRED message to its servingMSC. 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 transparentinformation (UMTS) IE which has the same structure as when generated in a RNC (see GSM 08.08 [2]).
Two cases are then considered.
Intra MSC:
In this case the MSC justs sends a RELOCATION REQUEST message to the serving RNC. This messagecarries 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 assignmentcase described in 4.3.3.5. The RAB parameters IE setting is performed according to 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 is sent to the target 3G MSC. This message car-ries a HANDOVER REQUEST message as in the intra GSM case. HANDOVER REQUEST carries thereceived optional IEs (Current Channel Type IE, Speech Version (Used) IE and Old BSS to new BSSInformation 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 UserPlane mode IE which is set to SMpSDU, and a RAB parameters IE which setting is performed accordingto 4.3.3.5.
The remaining of the procedure and the other parameters are fully described in document HO Ref.[17].
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 itsserving 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]).
Two cases are then considered.
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:– 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
98
01
En
CIT /AAC033638800DS
103
103
The remaining of the procedure and the other parameters are fully described in document HO Ref.[17].
Inter MSC:
In that case the serving MSC sends a MAP PREPARE HANDOVER REQUEST message to the target 2GMSC. This message carries a HANDOVER REQUEST message which has been built identically to aboveIntra–MSC case.
At the receiving target 2G–MSC the MAP PREPARE HANDOVER REQUEST message is treated as isintra 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 commandassociates 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 beenreceived 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’. Thisdefault value can be modified by MODSHO.
Following the introduction of Service Handover function (i.e. activation of F–HO–014) the default valueof 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
99
01
En
CIT /AAC033638800DS
103
103
Locally managed SHPLMN table is used to get the value of SHSPEECH and decide on the emission ofService 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 locallygenerated Service Handove IE or removed, depending on local SHSPEECH value, before sendingRELOCATION 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 theMS desires to change the call mode, from data to speech, or conversely. In the present description we areonly 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 limitedto FR channels being extended to speech in dual services calls, any reference to an HR channel isremoved 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 capabilitynot presently available”.
The MODIFY REJECT message contains the current GSM–BC which corresponds to the data service inprogress.
If the assignment procedure is successful, then a MODIFY COMPLETE is returned to the MS with theGSM–BC which has been received in the MODIFY.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
100
01
En
CIT /AAC033638800DS
103
103
In–call modifica-tion
data call in prog-ress
MODIFY
GSM–BCanalysis
MODIFY REJECT
data call in prog-ress
outputMS–SPEECH–Vbuild
Channel Type IE
ASSIGNMENTREQUEST
call in speechphase
ASSIGNMENTCOMPLETE
ASSIGNMENTFAILURE
MODIFY REJECTMODIFY COM-PLETE
data call in prog-ress
according to BSCcharacteristics
speechN
Figure 29. SDL: In–call modification.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
101
01
En
CIT /AAC033638800DS
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 havebeen provided at call setup in its bearer capabilities. Speech v3 is considered better than v2, which is betterthan 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 updatedby 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 AMRrelated 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–062is active.
Although the ’Chosen speech version’ may later change due to handover towards GSM, the CDR is notupdated.
When F–CG–062 is not active ’Chosen speech version’ is not relevant. This situtation should however betransient 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 adefault 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 cannotbe 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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
102
01
En
CIT /AAC033638800DS
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 MSSSP
N_DISCFREE_I
Call rejectedNo Circuit / channelavailable
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.
All
right
s re
serv
ed. P
assi
ng o
n an
d co
pyin
g of
this
docu
men
t, us
e an
d co
mm
unic
atio
n of
its
cont
ents
not p
erm
itted
with
out w
ritte
n au
thor
izat
ion
from
Alc
atel
.
ED
1AA
000
14 0
004
(900
7) A
4 –
ALI
CE
04.
10
103
01
En
CIT /AAC033638800DS
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 , theASSIGNMENT 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, theyare 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
Related Documents
