Académique Documents
Professionnel Documents
Culture Documents
AMR
Domain : ALCATEL900
Division : SYSTEM DOCUMENTATION
Rubric : GENERAL ANALYSIS
Type : SPECIFICATION
Distribution Codes Internal : 9999 External : 900000
ABSTRACT
This document specifies the Speech Teleservice offered by the NSS in GSM since R6 and UMTS since
R7.
Approvals
Name
App.
REVIEW
ED 01 RELEASED
CIT AAC033638800DS En Y 1/ 2
2
HISTORY
01 on 03–01–23
Creation.
not permitted without written authorization from Alcatel.
This document has been created from document AAC033638700DS edition 03.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Note on implementation:
In release NSS R7.0, only AMR_12.2 is supported by the Tc in UMTS, or when only AMR_12.2 is offered
the RAB which is assigned by the NSS is limited to the corresponding 12.2kb/s rate.
The RAB parameters have the following specific values:
– Guaranteed Bit Rate=12.2kbit/s,
– Subflow SDU size for classes A, B and C is only provided for 12.2kbit/s.
END OF DOCUMENT
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01 RELEASED
CIT AAC033638800DS En Y 2/ 2
2
SPECIFICATION
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
TABLE OF CONTENTS
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
AMR
ED 01
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
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
ED 01
103
LIST OF FIGURES AND TABLES
ED 01
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
not permitted without written authorization from Alcatel.
ED 01
103
HISTORY
01 on 03–01–23
Creation.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
REFERENCED DOCUMENTS
ED 01
103
[17] Handover (HO).
AAC020007700DS.
AAC033643700DS.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
ED 01
103
GLOSSARY / TERMINOLOGY
BC Bearer Capability.
BS Bearer Service.
BSC Base Station Controller.
BSS Base Station Subsystem.
BSSMAP Base Station System Management Application Part.
BTS Base Transceiver Station.
CDR Charging Detailed Record.
CIC Circuit Identity Code.
CN Core Network.
DTAP Direct Transfer Application Part.
DTX Discontinuous Transmission.
EFR Enhanced Full Rate.
FR Full Rate.
GBR Guaranteed Bit Rate.
HR Half Rate.
HSCSD High Speed Circuit Switched Data.
IAM Initial Address Message.
IE Information Element.
IMSI International Mobile Subscriber Identity.
ISDN Integrated Services Digital Network.
ITC Information Transfer Capability
MS Mobile Station.
NSS Network SubSystem.
MCC Mobile Country Code.
MNC Mobile Network Code.
MOC Mobile Originating Call.
MTC Mobile Terminated Call.
MxBR Maximum Bit Rate.
PDU Protocol Data Unit.
PLMN Public Land Mobile Network.
PSTN Public Switched Telephony Network.
QoS Quality of Service.
RCR Radio channel requirement.
SDU Service Data Unit.
Tc Transcoder.
TCH Traffic CHannel.
TCH/AFS Traffic Channel/AMR Full rate Speech.
TCH/AHS Traffic Channel/AMR Half rate Speech.
TDM Time Division Multiplex.
TE Terminal Equipment.
TFO Tandem Free Operation.
TRAU Transcoder and Rate Adaptator Unit.
TS Tele Service.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
Adaptative Multi–Rate In GSM, speech and channel codec capable of operating at gross bit–
rates of 11.4kbps (half rate) and 22.8kbps (full rate). In addition, the codec
may operate at various combinations of speech and channel coding
(codec mode) bit–rates for each channel mode
not permitted without written authorization from Alcatel.
in UMTS, an AMR codec, different from the GSM one, has also been
defined.
AMR handover Handover between FR and HR channel modes to optimize AMR operation
Channel mode Half–rate or full–rate operation
Channel mode adaptation The control and selection of the (FR or HR) channel mode
Circuit Pool A circuit pool is a group of circuits, between MSC and BSC, to which a
TRAU with speech and usually data handling capabilities is assigned. The
characteristics of a circuit pool (i.e. different speech versions and data
rates supported) are defined by the GSM recommendations
Codec mode For a given channel mode, the bit partitioning between speech and
channel codec.
Codec mode adaptation The control and selection of the codec mode bit rates.
In–Band Signalling Signalling for DTX, Channel and codec mode modification carried within
the channel by reserving or stealing bits normally used for speech
transmission.
Internal handover An internal handover is a handover which takes place between channels
on a cell or cells controlled by a single BSS. It operates without reference
to the MSC, although the MSC is informed upon completion.
Gross bit–rate The bit rate of the channel mode selected (22.8kbps or 11.4kbps)
Speech version 3 synonymous to AMR or AMR version 1
2G refers to 2nd generation networks i.e. GSM networks
3G refers to 3rd generation networks i.e. UMTS networks
UMTS only:
ED 01
103
1 INTRODUCTION
1.1.1 Overview.
This feature brings the ability to support Adaptative Multi–Rate (AMR) speech codec by the GSM and
UMTS Network SubSystem (NSS).
1.1.3 In GSM
1.1.3.1 Description
All these speech codecs (HR, FR, EFR) operate at a fixed coding rate. Channel protection against errors
is also added at a fixed rate. Therefore they are not adaptable.
So, contrary to the previous codecs, the principle of AMR is to be adaptable to changing radio and traffic
conditions, and also to be customized to the specific needs of network operators.
One principle of AMR is to have a set of codecs, and for any radio condition, to use the one with the best
speech quality
ED 01
103
Under good radio conditions, a codec with a high bit rate is used. More information is used to encode
speech, so the speech quality is better. In the channel coding, little room is left for redundancy.
Under poor radio conditions, a codec with a low bit rate is used. Speech is encoded with less information,
not permitted without written authorization from Alcatel.
but this information is well protected thanks to the redundancy of the channel coding.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The codec is dynamically adapted by the MS (downlink) and the BTS (uplink). The codec used uplink can
be different from the codec used downlink.
In the future, when most MSs will handle AMR, the versatility of AMR will make the existing codecs redun-
dant.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
1.1.3.3 AMR functional operation.
The next figure shows in which PLMN elements the introduction of AMR induces evolutions.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
TRAU
The next figure shows all the inband signalling between speech and channel encoder/decoder.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
MS BTS TRAU
Codec Codec
Adaptation Adaptation
The AMR speech codec includes a set of fixed rate speech codec modes for HR and FR with the possibility
to switch between the modes depending on the propagation errors.
There are:
– 8 codec modes for FR, including GSM EFR:
• 2 modes exclusively available in FR 12.2kbps and 10.2kbps
• 6 modes both available in FR and HR 7.95kbps, 7.4kbps, 6.7kbps, 5.9kbps, 5.15kbps
and 4.75kbps.
– 6 codec modes for HR:
• 6 modes both available in FR and HR 7.95kbps, 7.4kbps, 6.7kbps, 5.9kbps, 5.15kbps
and 4.75kbps.
4 modes are selected by the BSS at call set up or handover and may be used during the communication.
Each codec mode provides a different level of error protection through a dedicated distribution of the avail-
lable gross bit rate (22.8kbps in FR and 11.4kbps in HR) between speech and channel coding. Therefore
the actual speech rate depends on the actual radio condition. A codec adaptation algorithm selects the
optimal speech rate (or codec mode) according to the channel quality. The codec mode adaptation relies
1AA 00014 0004 (9007) A4 – ALICE 04.10
on channel quality measurements performed in the MS and the network and on inband information sent
together with the speech data. Each link (up, down) may use a different codec mode, however the channel
type is the same, HR or FR .
ED 01
103
In the above figure, in both directions, the speech data are associated with a Codec Mode Indication to
enable the receiver to select the proper channel decoder (in MS and BTS) and the proper speech decoder
(in MS and TRAU).
For the adaptation of the uplink codec mode, the BTS estimates the channel quality, selects the best codec
not permitted without written authorization from Alcatel.
mode, and sends this information inband to the MS in Codec Mode Command.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
For the downlink codec adaptation, the MS estimates the downlink channel quality, and sends inband this
quality information to the network as a Suggested Codec Mode.
1.1.4.1 Architecture
SSP
#7 signalling link
RCP
Serving MSC
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
In UMTS the principle of UMTS AMR remains the same as in GSM: inband signalling between MS, RNC
and Transcoder (TC) for codec mode adaptation. However, in UMTS the notion of HR and FR is no longer
applicable.
not permitted without written authorization from Alcatel.
The Transport network between RNC and TC is based on ATM AAL2 on top of which there is Iu UP.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
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.
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]).
N.B. The rate for SID corresponds to the background encoding noise.
Speech frames are sent every 20ms. The number of bits of a speech frame depends on the rate as shown
in the following table.
ED 01
103
Source codec bit rates Total number of bits
4.75 kbit/s 95
1.80 kbit/s 39
The bit rate (i.e. codec mode) can change every 20ms upon reception of an inband AMR command (Codec
Mode Request)
The AMR speech frames are transmitted over Iu UP used in SMpSDU mode. The predefined SDU size
corresponds to the size of the speech frame.
To each codec mode and SID are associated one, two or three classes: A,B and C. See 3GPP TS 26.101
Ref.[10].
Class ’A’ offers the best level of protection against errors, class ’C’ the worst level. The way an erroneous
speech frame is handled depends on the class where the error occurred.
An error in class ’A’ bits results in a corrupted speech frame which should not be decoded without applying
error concealment (see 3GPP TS 26.101 Ref.[10]).
An error in class ’B’ or ’C’ bits only reduces the speech quality.
The N bits of a speech frame for a given AMR codec mode and SID (for instance 244bits at 12.2kbit/s)
are split into up to three parts, each part is assigned to a class.
Over the radio interface, the different classes are sent over different co–ordinated DCHs offering different
bit protection classes.
The next table (from 3GPP TS 26.101 Ref.[10]) gives the description of the classes for every codec mode.
4.75 95 42 53 0
5.15 103 49 54 0
5.90 118 55 63 0
6.70 134 58 76 0
7.40 148 61 87 0
1AA 00014 0004 (9007) A4 – ALICE 04.10
7.95 159 75 84 0
ED 01
103
AMR codec mode Total number of Bits in Bits in Bits in
bits Class A Class B Class C
10.2 204 65 99 40
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Table 3. Number of bits in Classes A, B and C for each AMR codec mode.
Following table (from 3GPP TS 26.101 Ref.[10]) gives the description of the classes for SID frames. SID
is relevant when DTX is applied.
1.80 39 39 0 0
The repartitions in these two above table are used to define the RAB assigned by the NSS.
N.B. The decomposition of the two above tables comes from 3GPP TS 26.101 Ref.[10] where it is
provided for information.
This section is given for information, it does not affect the NSS.
ED 01
103
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Class A bits
AMR Core Frame
Class B bits (speech or comfort
noise data)
Class C bits
0 4.75 kbit/s
1 5.15 kbit/s
1AA 00014 0004 (9007) A4 – ALICE 04.10
2 5.90 kbit/s
3 6.70 kbit/s
ED 01
103
Frame Type Index Frame content (AMR mode, comfort
noise, or other)
4 7.40 kbit/s
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
5 7.95 kbit/s
6 10.2 kbit/s
15 No transmission/No reception
Table 5. Interpretation of Frame Type Index used for the Frame Type, Mode Indication, and Mode
Request fields of UMTS AMR Header.
The RAB which is assigned for speech reflects the TC capabilities. The TC supports all the UMTS AMR
modes (i.e. from AMR_12.20 to AMR_SID in Table 1. ).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
1.1.5 Role of the NSS.
For outgoing and terminated calls, the MS may indicate to the MSC at call set up, which speech version(s)
All rights reserved. Passing on and copying of this
document, use and communication of its contents
it supports, and among them the speech v3. The MSC then selects a list of pools according to the MS
preferences and the serving BSC capabilities. It finally assigns a channel, for which the choice upon the
speech version is left open to the BSC. When the channel assignment procedure has been completed,
the RCP is informed of the speech version chosen by the MS, and updates a CDR when it is the speech
v3.
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).
When the BSS performs autonomously an internal handover, this is signalled to the RCP. The new speech
version in use may be the version 3. Some internal handovers may be related to AMR change of rate only.
For external handovers, the new channel at the serving BSC depends on the serving BSC speech v3 sup-
port and characteristics, and on the MS preferences related to speech v3 which are known at the control-
ling MSC. This allows to pursue a call with speech v3 through handovers.
The target MSC relocates the RAB with characteristics which can be chosen at the target MSC according
to the operator’s needs (i.e. selected codec modes, DTX and QoS parameters).
This case is similar to the former one, the characteristics of the relocated RAB can be chosen at the target
MSC according to the operator’s needs (i.e. selected codec modes, DTX and QoS parameters).
The new channel assigned at the target BSC depends on the serving BSC characteristics, and on the MS
preferences which are known at the controlling MSC from the call establishment. This is similar to the GSM
to GSM case.
When a dual service (speech and data) has been requested the processing is not different from the speech
only case, except that the selected pools must satisfy both the MS preferred speech version(s), and the
required data service.
When the call moves or reverses to a speech phase, the in–call modification procedure includes a channel
assignment which is not different from an initial assignment.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
1.1.5.5 Control over the codec modes
In UMTS, the RAB is assigned with a subset of or all the codec modes supported by the Tc. The Tc supports
all the 3GPP defined codec modes. The subset can be chosen according to the operator’s needs.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The possibility is offered to the network operator, when compatible with the MS capabilities, to have a con-
trol over the codec modes, half or full rate only and forbid AMR handovers, or allocate channels with a
preference between full and half rate and allow AMR handovers. This applies to the assignment, handover
and modify procedures.
This is possible at the BSS level through MMCs related to the management of the BSC (CREBSC and
MODBSC) by the MSC.
All the various combinations of BSC characteristics, offer the network operator, at the geographical level
of a BSC coverage and while the network evolves in time, the possibility to either privilege AMR over other
speech versions or to be neutral, and/or to favor one rate over the other, and/or to allow/forbid handovers
between rates.
This finally permits to privilege a dense coverage over quality (resp. quality over dense coverage) or to
find and equilibrium. In time, when a great majority of MSs will support AMR, with appropriate BSC charac-
teristics it will be possible to use this feature almost exclusively.
In UMTS the use of DTX can be configured according to the operator’s needs.
1.1.7 TFO
The introduction of TFO is of no consequences for the NSS because it only implies inband signalling
between two AMR codecs.
An indication is provided in the CDRs when speech v3 has been selected upon channel assignment
completion.
Other provided information is whether the choice between full and half rate has been left to the BSS, with
or without a preference from the NSS, and which rate has finally been chosen.
Although the speech version and rate may change upon handover, they are not updated in the CDR.
In case of MS–MS call with MSs belonging to the same PLMN, depending on the functional options
F–RM–011 and F–RM–012, speech v1 can be forced to Full Rate, this to prevent from having Half Rate
1AA 00014 0004 (9007) A4 – ALICE 04.10
channels both on calling and called sides, which would result in poor speech quality.
ED 01
103
This possibility is not kept with speech v3 because the AMR has been designed to enable internal hand-
overs when speech quality is found not sufficient. In situations where AMR handovers are forbidden or not
possible, AMR HR outclasses speech v1 HR.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
In case of international call (i.e. call routed toward or from an international gateway), depending on the
functional option F–RM–010, speech v1 can be forced to Full Rate, this to prevent from having a poor
speech quality.
This possibility is not kept with speech v3 because of the same reason as stated above.
The management of circuit pools in the MSC depends on a functional option (i.e. F–RM–007).
When the circuit pool management is not supported, and when speech v3 is offered, then all the circuits
between MSC and BSC should support speech v3.
When circuit pool management is supported, then only some pools are capable of handling speech v3.
Pools have been added in the GSM recommendations for the support of speech version 3. A list of them
is given in the following table. They are selected for speech only or dual services with standard switched
data services.
Service Handover feature enables the operator to control or prompt 3G³2G handover of speech calls
according to the country and PLMN of origin of the roamer (MCC+MNC of the subscriber’s IMSI). It is also
applicable to its own subscribers in their home PLMN.
Low bandwidth services like speech could for instance be redirected towards GSM for the operator’s own
subscribers, while the redirection could depend on inter–PLMN charging agreements for other roamers.
The control is ensured by the UTRAN, based on information provided by the RCP in RAB assignment or
relocation. There may be no control at all, or the control can be:
– handover should be performed,
– handover should not be performed,
– handover shall not be performed.
The provision of the feature needs the activation of a functional option (i.e.F–HO–014).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
Pool Coding Supported channels and speech coding algorithms
HR speech v3
All rights reserved. Passing on and copying of this
document, use and communication of its contents
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.
If this option is active, the MSC handles the speech version indications.
When it is active, speech version 3 is supported by the NSS. This functionality is also known
as AMR standing for Adaptative Multi–Rate.
When the MS supports speech v3, an ordered list of speech versions, including speech v3 when
the necessary resources are available, is sent to the BSC by the MSC at channel assignment
and handover. The ordering depends on BSC related MMCs. This enable either to force a Full
Rate only mode, or to force a Half Rate only mode, or else to allow both rates. It is also possible
to favor speech v3 over other speech versions. In this way miscellaneous operators needs,
related to covered areas, can be satisfied.
1AA 00014 0004 (9007) A4 – ALICE 04.10
The support of AMR is available whatever the state of F–RM–007. If is not active, all the trans-
coders should be equipped with speech v3 capabilities.
ED 01
103
Otherwise, when F–RM–013 is not active, the speech version 3 MS capabilities are ignored by
the NSS and therefore cannot be used. In that case Full Rate is always preferred to Half Rate
and speech version 2 is preferred to version 1.
not permitted without written authorization from Alcatel.
This option is only meaningful when F–RM–005 and F–RM–013 are already active.
When it is active, the CDR is updated, at channel assignment time, with speech version 3 when
chosen by the MS and with indications on the choices between Full Rate and Half Rate which
had been left to the BSC and what rate it has retained.Although, the speech version may
change. the CDR is not updated due to handover
The activation of this option is needed to treat the circuit pools associated with the BSCs. When
this option is not active all the transcoders must support speech version 3.
The activation of this option is needed to manage the circuit pools associated with the BSCs
in the MMC in charge of the BSC administration.
The option F–RM–005 must also be active. Actually when F–RM–005 is not active only the
speech version 1 FR and HR are taken into account.
When it is active, the CDR ’Chosen speech version’ is updated at Radio Access Bearer assign-
ment for UMTS speech calls with an indication on the use of ”UMTS AMR version 1”. Although
the used speech codec may change, particularly after a handover to a GSM network, the indica-
tion is not updated.
When it is not active, the CDR is updated for speech calls at Radio Access Bearer assignment
with a default value which is not significant.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
• F–HO–014 ”Service Handover (UMTS to GSM)”
When the option is active the Service Handover feature is applied to speech calls for roamers
depending on the MCC+MNC of their IMSI.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
ED 01
103
2 DETAILED DESCRIPTION AND SCENARIOS
In the following scenarios the Network stands for a PSTN, an ISDN or another PLMN. The AMR related
treatments are effective only when the option F–RM–013 is active.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The scenarios described here are summarized, to get a thorough description see document RM Ref.[16].
MS
BSC RCP SSP
• • • • Network
• • • •
(1)
SETUP
(2)
CALL PROCEEDING (GSM–BC)
(3)
CREATE
(4)
RETRIEVE RESULT
(5)
ASSIGNMENT REQUEST
(6)
ASSIGNMENT COMMAND
(7)
ASSIGNMENT COMPLETE
(8)
ASSIGNMENT COMPLETE
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
(1) After the signalling link establishment, authentication procedure and controls at the VLR, the MS may
request for a speech Teleservice, at version 3. To that purpose the bearer capability (GSM–BC) of the
SETUP message contains a list of preferred speech version, and among them speech version 3.
not permitted without written authorization from Alcatel.
If the SETUP message requests dual services the SETUP carries a second GSM–BC, one is for the
All rights reserved. Passing on and copying of this
document, use and communication of its contents
(2) The request is acknowledged by the RCP. However, no indication is provided to the MS in the returned
GSM–BC of CALL PROCEEDING, upon the speech version that will be used.
(3) A leg is created by the SSP towards the BSS. To that purpose a CREATE request is sent to the SSP
by the RCF with a list of preferred pools.
If multiversion speech and speech version 3 are supported (i.e. options F–RM–005 and F–RM–013 are
active), and speech v3 was present in the list of preferred speech version of the received GSM–BC,
then the list of pools provided to the SSP will include support of speech v3 (i.e. the transcoders
associated to the CICs are equipped with AMR).
In case of dual services the list of selected pools additionally takes into account the data basic service
deduced from the associated received GSM–BC. Therefore the subset is common to the MS request and
the NSS capabilities, and this for both speech and data.
(4) The SSP returns back the CIC of the selected circuit and the identification of the pool where the circuit
has been allocated.
In cases where the SSP returns a pool which does not support speech v3, due to a configuration or
no free circuit left, speech v3 will not be proposed to the BSC in the ASSIGNMENT REQUEST.
(5) The ASSIGNMENT REQUEST sent to the BSC provides a list of the permitted speech versions,
and among them possibly speech v3. These versions are the versions supported by the pool selected
by the SSP. They are ordered according to the preferences of the MS. This ordering may however be
superseded by the RCP according to BSC characteristics set on AMR.
The ASSIGNMENT REQUEST also indicates to the BSS to allocate the TCH only in HR, or only in FR,
or leave to the BSC the choice between HR and FR, with or without a preference from the RCP, allowing
or forbidding handovers between HR and FR. These possibilities partly depend on MS preferences which
may be superseded by the RCP according to BSC characteristics set on AMR.
This enables to fully take advantage of the AMR codec possibilities.
(6) With the ASSIGNMENT COMMAND message the BSC forwards the request to the MS.
(8) The ASSIGNMENT COMPLETE message forwarded by the BSC indicates the chosen channel char-
acteristics and speech version. Afterwards the call is handled as described in document BCH Ref.[18].
If speech v3 has been chosen a dedicated indication is added in the CDR.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.1.2 Channel Assignment in the MTC case.
VMSC
MS
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • •
(1)
IAM
(2)
Provide Instruction
Paging, Signalling channel
establishment, Authentica-
tion...
(3)
SETUP
(4)
CALL CONFIRMED
(5)
CREATE
(6)
RETRIEVE RESULT
(7)
ASSIGNMENT REQUEST
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
All rights reserved. Passing on and copying of this
document, use and communication of its contents
not permitted without written authorization from Alcatel.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED
CIT
MS
01
•
•
•
BSC
(9)
(8)
•
ASSIGNMENT COMMAND
ASSIGNMENT COMPLETE
•
•
RCP
•
•
(10)
ASSIGNMENT COMPLETE
VMSC
SSP
103
AAC033638800DS
Network
En
28 / 103
(1) The incoming IAM message at the VMSC indicates the request of a speech service, either through its
ISDN–BC or in the multinumberring case through the GSM–BC associated to the called MSISDN, or else
if none of them is found the speech TS is requested by default.
not permitted without written authorization from Alcatel.
(2) The information of an incoming call is forwarded to the RCF with the Provide Instruction. Afterwards
All rights reserved. Passing on and copying of this
document, use and communication of its contents
(3) Then the SETUP is sent with a GSM–BC requesting for the speech TS. The RCF provides no informa-
tion upon its speech version support.
(4) The MS returns back a CALL CONFIRMED message usually with a GSM–BC.
If no indication upon the MS speech versions capabilities or no GSM–BC is returned, speech version 1
is assumed.
Otherwise, the MS may indicate in the GSM–BC its preferences for speech versions similarly to the OC
case. To that purpose the bearer capability (GSM–BC) of the CALL CONFIRMED message contains a list
of preferred speech version, and among them possibly speech version 3.
(5) A leg is created by the SSP towards the BSS. A CREATE request is therefore sent to the SSP by the
RCF with a list of preferred pools.
If multiversion speech and speech version 3 are supported (i.e. options F–RM–005 and F–RM–013 are
active), and speech v3 was present in the list of preferred speech version of the received GSM–BC,
then the list of pools provided to the SSP will include support of speech v3 (i.e. the transcoders
associated to the CICs are equipped with AMR).
(6) The SSP returns back the CIC of the selected circuit and the identification of the pool where the circuit
has been allocated.
In cases where the SSP returns a pool which does not support speech v3, due to a configuration or
no free circuit left, speech v3 will not be proposed to the BSC in the ASSIGNMENT REQUEST.
(7) The ASSIGNMENT REQUEST sent to the BSC provides a list of the permitted speech versions,
and among them possibly speech v3. These versions are the versions supported by the pool selected
by the SSP. They are ordered according to the preferences of the MS. This ordering may however be
superseded by the RCP according to BSC characteristics set on AMR.
The ASSIGNMENT REQUEST also indicates to the BSS to allocate the TCH only in HR, or only in FR,
or leave to the BSC the choice between HR and FR, with or without a preference from the RCP, allowing
or forbiding AMR handovers. These possibilities partly depend on MS preferences which may be super-
seded by the RCP according to BSC characteristics set on AMR.
This enables to fully take advantage of the AMR codec possibilities.
(8) With the ASSIGNMENT COMMAND message the BSC forwards the request to the MS.
(10) The ASSIGNMENT COMPLETE message forwarded by the BSC indicates the chosen channel char-
acteristics and speech version. Afterwards the call is handled as described in document BCH Ref.[18].
If speech v3 has been chosen a dedicated indication is added in the CDR.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.2 RAB assignment
In this scenario the SSP covers both the switch and the Tc which is on the contrary to the GSM casefunc-
tionaly part of the MSC.
MS
RNC RCP SSP
• • • • Tc Network
• •
(1)
SETUP
(2)
CALL PROCEEDING (GSM–BC)
(3)
CREATE
(4)
RAB ASSIGNMENT REQUEST
(5)
ERQ Establishment Request
(6)
ECF Establishment Confirm
(7)
RAB ASSIGNMENT RESPONSE
(1) The MS requests for the speech Teleservice with the ITC field of the bearer capability (GSM–BC) of
the SETUP message set to speech.
All the other speech related fields of the GSM–BC are not analysed but memorised in case of a later
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
(2) The request is acknowledged by the RCP through CALL PROCEEDING which contains a GSM–BC.
The RCP however removes the indications provided by the MS on its support of speech versions in a GSM
network because they are only relevant in the MS to MSC way.
not permitted without written authorization from Alcatel.
(3) A CREATE operation is sent to the SSP. Upon this operation the SSP expects to receive an incoming
All rights reserved. Passing on and copying of this
document, use and communication of its contents
(4) The RAB ASSIGNMENT REQUEST sent to the RNC is built according to a subset of the codec modes
supported by the Tc or all of them. The Tc supports all the UMTS AMR codec modes defined in 3GPP
26.102. The parameters associated with the codec modes (i.e. SDU size, Subflow SDU size) are system
parameters.
One RFC is associated to each codec mode, for each RFC three subflows are defined, one sublow being
associated to one AMR bit protection class. For some subflows, the SDU size may be equal to zero.
The message also requests for the Iu UP ’Support Mode for predefined SDU size’ (SMpSDU). An SDU
size is associated to each codec mode according to the rate. The sum of the three subflow SDU sizes
corresponding to the three classes equals the predefined SDU size.
(7) After AAL2 has been established the RNC runs the Iu UP initialisation procedure (see 3GPP TS 25.415
Ref.[8]). This procedure provides the Tc with the RAB parameters: RFC identifiers, Subflow SDU size and
the means to deduce the time interval between PDU emission. The parameters represent a common sub-
set between the capabities of the MS, the RNC, and the Tc. Upon completion of the procedure the Iu UP
connection is established between RNC and Tc.
The RAB ASSIGNMENT RESPONSE is sent by the RNC after the Iu UP connection has been success-
fully established.
The RCP requests for speech with a SETUP message with the ITC field of the GSM–BC set to speech.
The MS acknowledges with CALL CONFIRMED which contains a GSM–BC which indicates its support
of the GSM speech versions.
ED 01
103
2.3 GSM Handover and UMTS relocation.
The scenarios described here are summarized, to get a thorough description see document HO Ref.[17].
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
This handover occurs between channels belonging to the same cell. At this occasion changes in the chan-
nel resources such as channel rate (HR/FR) and speech version, may happen. However the support of
this procedure by the BSS is optional.
An overhead due to an increased signalling trafic may be brought to the MSC by these handovers.
MS
BSC RCP SSP
• • • •
• • • •
Intra BSS
Handover
(1)
HANDOVER PERFORMED
(1) The HANDOVER PERFORMED message may indicate a change in the chosen speech version and
channel rate, half or full.
The new chosen speech may be version 3.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.2 GSM Internal Inter–Cell Handover
This handover occurs between channels belonging to different cells of the same BSS. At this occasion
changes in the channel resources such as channel rate (HR/FR) and speech version, may happen. How-
not permitted without written authorization from Alcatel.
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.
The MS is under a serving BSS control and is transfered to the control of a target BSS. This scenario corre-
sponds to the case where the target and serving cells are both controlled by the same MSC.
serving target
MS
BSC BSC RCP SSP
• • • • • •
• • • • • •
speech v3 is
used
(1)
HANDOVER REQUIRED
(2)
CREATE
(3)
RETRIEVE RESULT
(4)
HANDOVER REQUEST
(5)
HANDOVER REQUEST ACKNOWLEDGE
(6)
HANDOVER COMMAND
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
serving target
MS
BSC BSC RCP SSP
• • • • • •
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • • • •
(7)
HANDOVER ACCESS
(8)
HANDOVER DETECT
(9)
HANDOVER COMPLETE
ED 01
103
(1) The HANDOVER REQUIRED message requires from the MSC to carry out a handover for a MS. THE
message provides information on the currently used speech version and channel. It also may request the
MSC to transfer information transparently to the target BSC (”Old BSS to New BSS information” IE).
When speech v3 is used this IE gives useful indications to the target BSC on the AMR codec present
not permitted without written authorization from Alcatel.
mode.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
(2) If the RCP can satisfy the request for handover, a leg is created by the SSP towards the target BSS.
To that purpose a CREATE request is sent to the SSP by the RCF with a list of preferred pools.
The list of preferred pools is computed in the same way as it has originally been done in the assignment
procedure. That is to say, the received GSM–BC is taken into account (i.e. the preferred speech versions,
and possibly speech v3). In case of dual services the list of selected pools additionally takes into account
the data service.
(3) The RCF gets back the selected CIC and pool identification from the RETRIEVE RESULT sent by the
SSP.
(4) Then a HANDOVER REQUEST message is sent to the target BSC. It contains the selected CIC and
the informations received from the serving BSC; namely the ”Old to New BSS information” , the used
speech version and current channel type, if they have been previously received in HANDOVER
REQUIRED.
This message also carries a Channel type IE which is built similarly to the assignment case.
The Channel type IE carries a list of the permitted speech versions, and among them possibly
speech v3. These versions are the versions supported by the pool selected by the SSP. They are ordered
according to the preferences of the MS. This ordering may however be superseded by the RCP according
to BSC characteristics set on AMR.
It also indicates to the BSS to allocate the TCH only in HR, or only in FR, or leave to the BSC the choice
between HR and FR, with or without a preference from the RCP, allowing or forbiding AMR handovers.
These possibilities partly depend on MS preferences which may be superseded by the RCP according
to BSC characteristics set on AMR.
This, in addition to the assignment procedure, enables to fully take advantage of the AMR codec possibili-
ties.
(5) If the target BSS can fulfill the request it sends back a HANDOVER REQUEST ACKNOWLEDGE mes-
sage. However, the target BSC may chose new characteristics for the channel and another speech ver-
sion. If so, it is indicated in the message.
Futhermore the message contains the whole HANDOVER COMMAND message which will be sent later
on to the MS.
(6) The HANDOVER COMMAND message provides the MS with the target channel identity chosen by
the target BSS and a handover reference in order for the this BSS to recognize the MS. It is still sent to
the MS through the serving BSS.
(8) The HANDOVER DETECT is sent by the BSS when it has recognized the handover reference number.
(9) When the MS has successfully established a communication path with the new BSS then the latter
sends a HANDOVER COMPLETE messages.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.4 External Inter–MSC Handover within a GSM PLMN
The related scenarios correspond to the various combinations where the controlling, target and serving
MSCs may be all or partly different network nodes.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The scenarios do not differ when speech v3 functionality is involved, they are not further described
here. See document HO Ref. [17] for full details. When F–RM–013 is active the difference lies in the
Channel type IE of the HANDOVER REQUEST message exchanged between the target MSC and BSC,
or between MSCs.
The difference comes from the fact that, in some cases, the target MSC may not know the GSM–BC, and
in particular the MS preferred speech versions, including speech v3.
The target MSC sends a HANDOVER REQUEST message to its target BSC. The rule applied to make
this message is as follows:
– when F–RM–013 is active, the HANDOVER REQUEST message sent to the target MSC contains
a faithful picture of the MS preferred speech versions, regardless of any BSC characteristics
related to AMR.
– at the target MSC, when F–RM–013 is active, the Channel type IE is built from the received Channel
type IE and the target BSC characteristics related to AMR. The pool list also depends on the
received Channel type IE.
– when F–RM–013 is not active, the processing is as described in document HO Ref. [17] (i.e. the
Channel type IE is modified to privilege FR speech v1 prior to be sent to the target MSC, the target
MSC does not modify the received Channel type IE).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.5 UMTS relocation
serving
target
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• •
(1)
RELOCATION REQUIRED
(2)
RELOCATION REQUEST
(1) The relocation procedure is triggered by the reception of a RELOCATION REQUIRED message from
the SRNS. The message identifies a target RNC. It carries a Source RNC to target RNC container.
(2) A RELOCATION REQUEST is then sent to the target RNC. It transparently forwards the Source RNC
to target RNC container. It requests for a single RAB defined by a RAB parameters IE defined as in the
RAB assignment case.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.5.2 3G³3G relocation inter–MSC
serving target
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • •
(1)
RELOCATION REQUIRED
(2)
PREPARE HANDOVER REQUEST
(3)
RELOCATION REQUEST
(2) The request for relocation is forwarded to the target MSC thanks to a MAP PREPARE HANDOVER
REQUEST message. It contains an AN–APDU parameter which contains a RELOCATION REQUEST
message. The RAB parameters of RELOCATION REQUEST include all the codec modes [4.75kbit/s –
12.2kbit/s], without DTX.
(3) On reception of the PREPARE HANDOVER REQUEST message, the RAB parameters of included
RELOCATION REQUEST are ignored.The RAB parameters sent to the RNC in RELOCATION
REQUEST are generated in the target MSC depending on local configuration of DTX and codec modes
(i.e. identical to the RAB assignment case).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.5.3 3G³2G relocation intra MSC
serving
target
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • •
(1)
RELOCATION REQUIRED
(2)
HANDOVER REQUEST
(1) The relocation procedure is triggered by the reception of a RELOCATION REQUIRED message from
the SRNS. The message identifies a target BSC. It carries a Old BSS to new BSS Information IE with
AMR related information.
(2) The MSC then sends a HANDOVER REQUEST message to the target BSC. It carries a Channel type
IE which contains a list of permitted speech versions and a preference between HR and FR, which
depend similarly to the pure GSM case on the preferences set on the BSC, on the MS signalled GSM–
BC and on the pool availability. It also forwards transparently the Old BSS to new BSS Information
IE. Some information as Current Channel Type 1 IE or Speech Version (Used) IE which is not relevant
in UMTS are not transmitted.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.5.4 3G³2G relocation inter MSC
serving target
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • • • •
(1)
RELOCATION REQUIRED
(2)
PREPARE HANDOVER REQUEST
(3)
HANDOVER REQUEST
(1) The relocation procedure is triggered by the reception of a RELOCATION REQUIRED message from
the SRNS. The message identifies a target BSC. It carries a Old BSS to new BSS Information IE with
AMR related information.
(2) The PREPARE HANDOVER REQUEST message includes a HANDOVER REQUEST. It carries a
Channel type IE which contains a list of permitted speech versions which, similarly to the pure GSM
case, only depends on the MS signalled GSM–BC. When the MS supports multiple speech versions,
the Channel type IE indicates no preference between HR and FR. The Old BSS to new BSS Information
IE is also forwarded transparently. Some information as Current Channel Type 1 IE or Speech Version
(Used) IE which are not relevant in UMTS are not transmitted.
(2) The target MSC then sends a HANDOVER REQUEST message to the target BSC. It carries a Channel
type IE which is deduced from the received Channel type IE and of which permitted speech versions
and preference between HR and FR depend, similarly to the pure GSM case, on the preferences set
on the BSC, and on the pool availability. It also forwards transparently the Old BSS to new BSS
Information IE. Some information as Current Channel Type 1 IE or Speech Version (Used) IE which
is not relevant in UMTS are not transmitted.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.5.5 2G³3G handover intra MSC
serving
target
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • •
(1)
HANDOVER REQUIRED
(2)
RELOCATION REQUEST
(1) The handover is triggered at the MSC on reception of a HANDOVER REQUIRED message from the
BSC. It contains a Source RNC to target RNC transparent information IE.
(2) The RCP then sends a RELOCATION REQUEST message to the target RNC. The Source RNC to
target RNC transparent information IE is passed transparently. The Current Channel Type 1 IE and
Speech version (Used) IE that may have been received from the BSC are ignored. The RELOCATION
REQUEST requests for a single RAB defined by a RAB parameters IE depending on configuration of DTX
and codec modes (i.e. identical to the RAB assignment case. It also requests for the SMpSDU Iu mode
needed for speech.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.5.6 2G³3G handover inter MSC
serving target
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • • • •
(1)
HANDOVER REQUIRED
(2)
PREPARE HANDOVER REQUEST
(3)
RELOCATION REQUEST
(1) The handover is triggered at the MSC on reception of a HANDOVER REQUIRED message from the
BSC. It contains a Source RNC to target RNC transparent information IE.
(2) The PREPARE HANDOVER REQUEST message includes a HANDOVER REQUEST. It carries a
Channel type IE which contains a list of permitted speech versions which, similarly to the pure GSM
case, only depends on the MS signalled GSM–BC. When the MS supports multiple speech versions,
the Channel type IE indicates no preference between HR and FR. The Source RNC to target RNC
transparent information IE is also forwarded transparently. Some information as Current Channel Type
1 IE or Speech Version (Used) IE which are not relevant in UMTS are not transmitted.
(3) The target RCP then sends a RELOCATION REQUEST message to the target RNC. The Source RNC
to target RNC transparent information IE is passed transparently. The Current Channel Type 1 IE and
Speech version (Used) IE that may have been received from the BSC are ignored. The RELOCATION
REQUEST requests for a single RAB defined by a RAB parameters IE based on local configuration of
DTX and codec modes (i.e. identical to the RAB assignment case). It also requests for the SMpSDU Iu
mode needed for speech.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
2.3.6 In–call modification (successful)
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
MS
BSC RCP SSP
• • • • Network
• • • •
(1)
MODIFY
(2)
ASSIGNMENT REQUEST
(3)
ASSIGNMENT COMPLETE
(4)
MODIFY COMPLETE
ED 01
103
(1) A MODIFY message is received by the RCF while a data service is in progress. The message carries
a GSM–BC which must correspond to a mode already negotiated at call set up, speech in the present case.
The GSM–BC is analyzed, if compatible a new channel is assigned for the speech TS.
not permitted without written authorization from Alcatel.
(2) The ASSIGNEMENT REQUEST is sent to the BSS. The characteristics are the same as for the initial
All rights reserved. Passing on and copying of this
document, use and communication of its contents
assignment case.
(3) The ASSIGNEMENT COMPLETE is returned by the BSS when the allocation has been sucessful. The
characteristics are the same as for the initial assignment case.
(4) The RCF sends back to the MS a MODIFY COMPLETE with the GSM–BC received in the MODIFY.
ED 01
103
2.3.7 In–call modification (rejected)
MS
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • •
(1)
MODIFY
(2)
MODIFY REJECT
(1) A MODIFY message is received by the RCF while a data service is in progress. The message carries
a GSM–BC which must correspond to a mode already negotiated at call set up, speech in the present case.
The GSM–BC is analyzed, a list of pools is deduced. However none of these pools matches the current
pool with regard to speech only, the modification is therefore rejected.
(2) The MODIFY REJECT message sent back to the MS, carries the currently used GSM–BC (i.e. which
corresponds to a data service) and invokes the cause ”Bearer capability not authorized”. The call follows
on in the speech phase.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
MS
BSC RCP SSP
• • • • Network
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• • • •
(1)
MODIFY
(2)
ASSIGNMENT REQUEST
(3)
ASSIGNMENT FAILURE
(4)
MODIFY REJECT
(1) A MODIFY message is received by the RCF while a data service is in progress. The message carries
a GSM–BC which must correspond to a mode already negotiated at call set up, speech in the present case.
The GSM–BC is analyzed, a list of pools is deduced.
(2) The ASSIGNEMENT REQUEST is sent to the BSS. The characteristics are the same as for the initial
assignment case.
(3) The ASSIGNEMENT FAILURE is returned by the BSS after the channel allocation failed.
(4) The MODIFY REJECT message sent back to the MS, carries the currently used GSM–BC (i.e. which
corresponds to a data service) and invokes the cause ”Bearer capability not authorized”.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3 DESCRIPTION OF INTER–ENTITIES MESSAGES
This chapter lists the messages and Information Elements involved with the function. However, their
descriptions are only partially provided because restricted only to those fields directly necessary to the
not permitted without written authorization from Alcatel.
function. For a thorough picture see the related recommendations 3GPP TS 24.008 Ref. [6] and 3GPP
All rights reserved. Passing on and copying of this
document, use and communication of its contents
TS 48.008 [14].
3.1 RCF – MS
3.1.1 SETUP
In the MOC case, when speech is requested, the MS may indicate in the GSM–BC of the SETUP message
the different speech versions it supports, hence its support of AMR.
MS³MSC: SETUP
If the MS requests the speech teleservice it is indicated in the Information Transfer Capability (ITC) field
(bits 321) of octet 3. In that case octets 4, 5, 5a, 5b, 6, 6a, 6b, 6c, 6d, 6e, 6f and 7 are not included by the
MS. Were they present the RCF would ignore them.
octet 3 meaning
bits 3 2 1 Information transfer capability
000 speech
In UMTS the ITC is sufficient to request for speech. The other speech related parameters described here
are still valid, but only useful for handovers with 2G networks.
When octet ”3a etc” is not present, only speech version 1 is supported by the MS, FR and optionally HR
with a preference. The preference is given by octet 3, bits 76 ’radio channel requirement’ field (bit 76 mean-
ing either ”only FR v1 supported”, or ”dual rate speech v1 MS, HR preferred”, or finally ”dual rate speech
v1 MS, FR preferred” ).
In case of octet ”3a etc” presence, then the MS supports at least speech version 1 FR, and optionally
speech version 1 HR with a preference between HR and FR. This is indicated in octet 3 bits 76 as described
in the following table.
The extension octets ”3a etc” are only checked if option F–RM–005 is active.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
octet 3 meaning
bits 7 6
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.
N.B. ”octet 3a” has only a meaning in the MS ³ network direction and is ignored by the MS when
received. Therefore the RCF won’t provide it in the GSM–BC(s) it sends to the MS.
Any additional value to those defined in the above table has the meaning ”speech version tbd” and is
ignored by the RCF when received. If none of these versions is supported or known by the RCF the version
1 given in octet 3 is assumed (i.e. the MS supports FR version 1, optionally HR version and gives a prefer-
ence between HR and FR).
When there is a discrepancy between the octet(s) 3a contents and the Radio Channel Requirement, the
content of octets 3a prevails. This is notably the case when:
– RCR indicates speech FR v1 preferred rather than HR speech v1, and the two rates are found in
reverse order in octets 3a,
1AA 00014 0004 (9007) A4 – ALICE 04.10
– RCR indicates speech HR v1 preferred rather than FR speech v1, and the two rates are found in
reverse order in octets 3a,
– RCR indicates HR speech v1 is not supported and HR speech v1 is found in octets 3a,
ED 01
103
If RCR indicates no other speech codec than v1 (i.e. there is no octet 3a), the present function cannot of
course be activated.
The values ”GSM full rate speech version 3” or ”GSM half rate speech version 3” are only taken into
not permitted without written authorization from Alcatel.
However, if bit 7 of octet 3a indicates ”octet used for other extension of octet 3”, then octet 3a is ignored.
If F–RM–013 is not active the RCF selects the first preferred speech version which is supported. If there
is none, speech version 1 as defined in octet 3 is assumed (i.e. the support of GSM full rate speech version
1 is mandatory).
In the MTC case, when speech is requested, the MSC sends a SETUP message to the MS, possibly with
a GSM–BC. As already indicated the GSM–BC octets ”3a etc...” are absent. See also BCTRL Ref. [25]
for further details.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.1.2 CALL CONFIRMED
In the MTC case, when speech TS has been requested in the GSM–BC of the SETUP message, the MS
may indicate in the GSM–BC returned in CALL CONFIRMED the different speech versions it supports,
not permitted without written authorization from Alcatel.
and possibly speech v3, in the same way as for the MOC case already described. The analysis is there-
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The GSM–BC IE follows the same pattern and analysis as for the SETUP message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
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.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
When the RCP returns a GSM–BC, it is identical to the received one, except the octets ”3a etc” are not
present and bits 76 of octet 3 are set to 01.
On the conditions for returning a GSM–BC see BCH [18]. Basically, a GSM–BC is returned in the case
of an alternate service and no GSM–BC is returned when the speech teleservice alone has been invoked.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.1.4 MODIFY
The MS may send this message to switch the call from a data phase to a speech phase and vice versa
when a dual service has been negotiated at call set up.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
MS³MSC: MODIFY
When the request means to switch to speech the GSM–BC IE may contain speech versions preferences,
and possibly speech v3, similarly to what has already been described for the SETUP message. The IE
is analyzed following the same pattern.
The In Call Modification procedure is not applicable to UMTS, MODIFY cannot be received in that environ-
ment.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
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.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The GSM–BC IE of this message corresponds to the new channel mode and is the same as the one
received in the MODIFY message, except for the speech versions preferences which are meaningless
in the MSC³ MS way and therefore should be removed from the received GSM–BC.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.2 RCF – BSC
This message is sent from the MSC to request the BSC to assign a radio resource.
The Channel Type IE contains the necessary information for the BSC to assign a channel. It is derived
from the GSM–BC IE negotiated at call set up. When AMR is used the informations it carries additionally
depend on the pool attributed by the SSP and whether .
The fields of the Channel Type IE are:
– Speech / data indicator,
– Channel rate and type,
– Permitted speech version indication / data rate + transparency indicator.
The Circuit Identity Code IE is included by the RCP, it corresponds to the circuit allocated by the SSP for
the leg towards the BSC.
When AMR is used the values of the Channel Type IE fields are as described in the next subsection.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.2.1.1 Channel Type IE description
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
8 7 6 5 4 3 2 1
Length octet 2
octet 3 meaning
bits 4 3 2 1
0001 speech
ED 01
103
octet 4 meaning
0000 1010 A Full or Half rate TCH channel, Full rate preferred,
changes between full and half rate allowed also after first
channel allocation as a result of the request.
Preference between the permitted speech versions for
the respective channel rates as indicated in octet 5, 5a
etc...
0000 1011 B Full or Half rate TCH channel, Half rate preferred,
changes between full and half rate allowed also after first
channel allocation as a result of the request.
Preference between the permitted speech versions for
the respective channel rates as indicated in octet 5, 5a
etc...
0001 1010 1A Full or Half rate TCH channel, Full rate preferred,
changes between full and half rate not allowed after first
channel allocation as a result of the request.
Preference between the permitted speech versions for
the respective channel rates as indicated in octet 5, 5a
etc...
0001 1011 1B Full or Half rate TCH channel, Half rate preferred,
changes between full and half rate not allowed after first
channel allocation as a result of the request.
Preference between the permitted speech versions for
the respective channel rates as indicated in octet 5, 5a
etc...
ED 01
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,
not permitted without written authorization from Alcatel.
may depend on the operator specific requirements as expressed through BSC characteristics managed
All rights reserved. Passing on and copying of this
document, use and communication of its contents
(1) GSM speech half rate version 2 code point is present in the recommendations but the corresponding
codec does not exist, it is therefore not used.
Octets 5a, 5b... are present depending on the extension bit of previous octet.
The speech versions available depend on the MS capabilities, the selected pool and the NSS offering.
Speech version 3 can only be present when F–RM–013 is active. In addition, the presence of half
and/or full rate speech v3 may depend on the operator specific requirements as expressed through BSC
characteristics managed by MMCs.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.2.2 CHANNEL ASSIGNMENT COMPLETE
This message is sent from the BSC to the MSC to indicate that the requested assignment request has been
completed by the BSS.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Chosen Channel O 2
The Chosen Channel IE should always indicate ”speech (full rate or half rate)” when the function has been
invoked.
octet 2 meaning
bits 8 7 6 5
octet 2 meaning
bits 4 3 2 1
The Speech Version (Chosen) IE is included at least when the choice of speech version has been made
by the BSS. It is the case when a list of speech versions has been provided in the Channel Type IE of the
ASSIGNMENT REQUEST message.
However, it may happen that a BSC does not return the Speech Version (Chosen) IE even if it has made
a choice. In that case, the MSC assumes the chosen speech version to be the value indicated by the Per-
mitted speech version identifier (see above section 3.2.1.1) in octet 5 of Channel type IE of CHANNEL
ASSIGNMENT REQUEST.
Speech Version (Chosen) IE is coded in the same way as the permitted speech version identifier in the
Channel type IE.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.2.3 CHANNEL ASSIGNMENT FAILURE
This message is sent from the BSC to the MSC to indicate that the assignment procedure has been
aborted by the BSS due to a failure.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Cause M 3–4
ED 01
103
3.2.4 HANDOVER FAILURE
This message is sent from the BSC to the MSC to signal that due to a failure in the resource allocation
the handover has been aborted.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Cause M 3–4
ED 01
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.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Cause O 3–4
The Channel Type IE gives the characteristics of the channel requested from the target BSC. The way
this IE is managed is described further in the document. When F–RM–013 is active it may depend on
the MS preferences and BSC characteristics.
The Circuit Identity Code IE is included by the RCP, it corresponds to the circuit allocated by the SSP
for the leg towards the target BSC.
The cause IE may be included by the MSC according to a BSC characteristic (see document HO Ref.[17]),
and it is equal to the one received in the HANDOVER REQUIRED message.
The Current Channel Type 1 IE is included by the MSC only when it has been previously received in a
HANDOVER REQUIRED message. In this case the sent IE is equal to the received one.
The Speech Version (Used) IE is included by the MSC only when it has been previously received in a
HANDOVER REQUIRED message. In this case the sent IE is equal to the received one.
The Old BSS to New BSS Information IE is included by the MSC only when it has been previously
received in a HANDOVER REQUIRED or RELOCATION REQUIRED message. In this case the sent IE
is equal to the received one.
The Source RNC to target RNC transparent information (UMTS) IE is the exact copy of the same IE
previously included by the BSS in a HANDOVER REQUIRED or by the RNC in a RELOCATION
REQUIRED. It is a container passed transparently to the tartget RNC by the CN. It may carry speech
related information.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.2.6 HANDOVER REQUEST ACKNOWLEDGE
This message is sent by the BSC to the MSC to indicate that the request to support a handover at the target
BSS can be supported.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Chosen Channel O 2
The Chosen Channel IE is included if the choice upon channel type/rate was done by the BSS.
The Speech Version (Chosen) IE is included if the choice was done by the BSS. It may be speech v3
if it has been previously given as Permitted speech version.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.2.7 HANDOVER REQUIRED
This message is sent to the MSC when a handover is required by the BSC for a MS which already has
a dedicated resource assigned.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Cause M 3–4
The Current Channel Type 1 IE, however optional, should always be included.
When the Speech TS is in use, the Speech Version (Used) IE should be always present. It may be speech
v3.
The Old BSS to New BSS Information IE is passed transparently by the MSC from the BSC.
If the present codec is an AMR codec, this IE may inform the target BSS of the current multirate
codec configuration.
The Source RNC to target RNC transparent information (UMTS) IE is included by the BSS in case of
handover with UMTS. It is a container passed transparently to the tartget RNC by the CN. It may carry
speech related information.
8 7 6 5 4 3 2 1
The Speech version identifier is coded in the same way as the Speech version identifier field in the Channel
type IE.
ED 01
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.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Cause M 3–4
Chosen Channel O 2
The Chosen Channel IE is included when the channel rate/type has changed during the handover.
The Speech Version IE is present when the speech version has been changed by the BSS. It may be
speech version 3, if it was a permitted choice offered to the BSC.
ED 01
103
3.3 RCF–RNC
This message is sent from the MSC to the SRNC to request the establishment of a RAB.
IE value comment
RAB ID
>>RAB parameters IE
IE value comment
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
codec mode
depends on selected codec(s)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
SDU parameters : Subflow 1 Class A
ED 01
103
SDU format information Parameter: 10.2kbit/s
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Rate depends on a PLMN data
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
SDU parameters : Subflow 2 Class B
ED 01
103
SDU format information Parameter: 7.40kbit/s
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
RAB Subflow Combination Bit 0 0 kbit/s for DTX
Rate depends on a PLMN data
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
SDU parameters : Subflow 3 Class C
ED 01
103
SDU format information Parameter: 5.90kbit/s
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Rate depends 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
IE value comment
>>Service Handover
IE value comment
In the RAB ASSIGNMENT REQUEST described in above table, only the information relevant to speech
is provided. See document RANAPI Ref.[26] to get the whole description of the message.
1AA 00014 0004 (9007) A4 – ALICE 04.10
The message definition according to 3GPP TS 25.413 Ref.[7] makes provisions for the establishment of
multiple RABs and for the release of RABs in case of multiple RABs already established.
ED 01
103
Provision of speech necessitates a single RAB. That is why only the first section of the message ’RABs
to be setup or modified’ and ’First setup or modify item ’ are needed.
A RAB ID IE is filled by the RCP to later identify the acknowledgment. It is unique for a particular UE.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The values set on the RAB parameters IE are those which have been described in 1.1.4.4. They are taken
as default values.
The RAB parameters IE carries selected codec modes which constitute a subset of the codec modes
supported by the TC which actually supports all the UMTS AMR codec modes.
The selection of codec mode(s) among [4.75kbit/s to 12.2kbit/s] to be included in RAB parameters IE
depends on a PLMN data. At least one codec mode must be selected. By default all the codec modes
[4.75kbit/s to 12.2kbit/s] are selected. The values of the associated RAB Subflow SDU size IE are those
of Table 3.
RAB parameters IE describes each class A, B and C separately. Within each class the selected codec
modes are ordered from the highest to the lowest rate. This ordering is arbitrary.
Maximum Bit Rate is set to the highest bit rate of the selected codec mode(s) [4.75kbit/s to 12.2kbit/s].
Guaranteed Bit Rate can be set to any bit rate value among the selected codec mode(s) [4.75kbit/s to
12.2kbit/s]. The default chosen value is the lowest selected codec mode.
Maximum SDU size is set according to the highest bit rate of the selected codec mode(s). The value is
given in Table 3.
The RAB Subflow Combination Bit Rate and the 1.80kbit/s subflow (SID ) are present only when DTX
is applied, i.e. when DTXAMR PLMN data is set to ON. For SID the values of RAB Subflow SDU size
IE are those of Table 4.
The User Plane mode IE of the ’User Plane Information’ section of the message requests for the Iu UP
SMpSDU mode which is needed for speech.
The Service Handover IE may be present if option F–HO–014 is active, and is always absent otherwise.
When F–HO–014 is active, its presence, or value, depends on the table SHPLMN managed by MMC
MODSHO. See further in the document.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.3.2 RAB ASSIGNMENT RESPONSE
IE value comment
See document RANAPI Ref.[26] to get the whole description of the RAB ASSIGNMENT RESPONSE mes-
sage.
As the Provision of speech necessitates a single RAB, only ’RABs setup or modified’ is normaly to be found
in the message.
In case of failure to assign a RAB, the ’RABs failed to setup or modify’ with a Cause IE is also present,
see documentt RANAPI Ref.[26] for the possible reasons.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.3.3 RELOCATION REQUEST
This message is sent from the MSC to the SRNC to request the allocation of the necessary resources for
the relocation of the UE.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
IE value comment
RABs to be setup
IE value comment
>>Servic e Handover
IE value comment
In the RELOCATION REQUEST described in above table, only the information relevant to speech is pro-
vided. See document RANAPI Ref.[26] to get the whole description of the message.
The description of the RABs to be setup is identical to the RAB assignment case, see section 3.3.1. The
selected codec modes and DTX depend on the associated PLMN data of the target MSC.
The Source RNC to target RNC transparent container carries information to be transparently passed
from SRNC to target RNC. Part of it may be related to speech.
The Service Handover IE may be present if option F–HO–014 is active, and is always absent otherwise.
When F–HO–014 is active, its presence, or value, depends on the table SHPLMN managed by MMC
MODSHO. See further in the document.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.3.4 RELOCATION REQUIRED
This message is sent from the SRNC to the MSC to request for a relocation procedure.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
IE value comment
In case of a 3G target, the Source RNC to target RNC transparent container carries information to be
transparently passed from SRNC to target RNC. Part of it may be related to speech.
In case of a 2G target, the Old BSS to new BSS Information IE carries speech related information to be
transparently passed from SRNC to target BSS.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.4 RCF – SSP
3.4.1 CREATE
In GSM, it is sent by the RCF to the SSP to request the establishment of a half call towards the BSC or
the fixed network.
In UMTS, the purpose of the CREATE is to have the SSP ready for an incoming AAL2 connection from
the RNC. In that case no RETRIEVE operation is performed by the RCF.
RCF³SSP: CREATE
TRAU types O
TC Info O
The TRAU types IE, only present in the GSM case and when the option F–RM–007 is active, contains an
ordered list of pools (see further in 4.3.3.3 the possible lists of pools) .
When speech v3 is requested, the preferred pools support speech v3. As the codecs always support
HR and FR, it is also the case for each pool.
The TC Info IE only present in the UMTS case, is used for the initialisation of the Transcoder by the SSP.
In the case of speech it is set as follows:
– Iu User Plane mode parameter is set to SMpSDU,
– Type of Data Service parameter is set to no indication.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
3.4.2 RETRIEVE RESULT
This message, received from the SSP by the RCF, gives the selected pool and CIC when the CREATE
request was related to a leg towards a BSC. Towards the fixed network, only CIC is retrieved.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
CIC O 2
TRAU Type O 1
The TRAU Type IE is sent back by the SSP when a CREATE requesting the creation of a leg towards a
BSC included a list of pools. It represents the pool selected amid the list of preferred pools provided by
the RCP. If speech v3 is requested, the selected pool should support this version to follow on the call
with speech v3. In case this information is not present while expected by the RCP, or invalid, the call is
released.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
4 DESCRIPTION OF NETWORK ENTITIES
4.1 HLR
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
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
The data associated with the function are those associated to each BSC and managed by CREBSC and
MODBSC.
For all existing BSCs, at the time of introduction of the function, the values are set to AMR not supported,
to FR preferred, to allow handovers between HR and FR and preferred speech versions ordered from high-
est to lowest as up to R5 NSS release. This corresponds to the set of parameters defined in next subsec-
tion:
– AMRRATE=NONE,
– AMRPRATE=FR,
– AMRHO=Y.
Furthermore, when F–RM–007 is active, at least one pool with the support of speech v3 should have been
created at the SSP for each controlled BSC which is intended to support AMR before activating
F–RM–013.
Parameters defined as PLMN data data can be tuned to meet operator’s specific needs. At introduction
of UMTS function, these parameters are assigned generic default values.
RBER can be controlled separately for each RAB sub–flow, i.e. for class A bits, class B and class C. As
erroneous SDUs are delivered with error indication for class A only, SDU Error Ratio is applicable to that
class only.
At the introduction of the function, default values are applied as defined in section 3.3.1.
DTX is applied (resp. not applied) on speech in UMTS when PLMN data DTXAMR is set to ON (resp. OFF).
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
The selected codec mode(s) among [4.75kbit/s to 12.2kbit/s] to be put in RAB assignment and relocation
messages depend on a PLMN data. At least one codec mode must be selected. At the introduction of the
function all the codec modes are selected by default.
MxBR, GBR and Maximum SDU size are set according to the codec mode(s) actually selected as
not permitted without written authorization from Alcatel.
4.3.2 Administration
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]).
The operator can shape the use of GSM AMR to his own requirements. This is done thanks to BSC man-
agement MMCs (CREBSC, MODBSC, see document MMCRCP Ref. [22]) which allow, if F–RM–013 is
active, to modify AMR profile parameters. These parameters are:
– AMRRATE can be HR, FR, BOTH or NONE,
this parameter is used to force the utilization of the AMR codecs only in HR, only in FR or allowing
both rates. Of course when the MS indicates only FR (resp.HR), the RCP does not compel the use
of HR (resp.FR).
When it is equal to NONE, the BSC does not yet support AMR.
– AMRPRATE can be HR, FR, MS
this parameter is only meaningful when AMRRATE=BOTH. When set to MS, the RCF abides by the
MS choices over speech versions and rates (i.e. the ordering received from the MS is used).
When set to FR (resp. HR) FR (resp. HR) is preferred. In these two cases, for each rate, the MS
speech versions are reordered from the highest (v3) to the lowest (v1).
– AMRHO can be Y or N.
this parameter is only meaningful when AMRRATE=BOTH.
In GSM speech v1 FR is always offered. The other different speech versions are available on condition
of functional options as follows.
When F–RM–005 is not active only speech v1, FR and/or HR is available at the NSS. The supply of HR
v1 depends on F–RM–001.
Otherwise when F–RM–005 is active, multispeech version is offered, in particular speech v3 can be pro-
1AA 00014 0004 (9007) A4 – ALICE 04.10
vided by the NSS if F–RM–013 is also active. Then, the utilization of speech v3 depends on the calling/
called MS preferences and the covering BSS capabilities.
ED 01
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].
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
In UMTS there is only one codec available which is mandatory, the UMTS AMR codec. The ITC field value
is therefore sufficient to deduce a request for speech, no further analysis of the GSM–BC is needed.
The following SDL describes the process to analyze the speech version(s) supported by a MS according
to the informations the MS provides in the GSM–BC of SETUP or CALL CONFIRMED messages.
The output of this analysis is a table, named MS–SPEECH–V, constituted of a list of speech versions sup-
ported by the MS, ordered according to the preferences shown by the MS. This table is memorized for later
use during the handover procedure, and named MS–SPEECH–V–STORED. MS–SPEECH–V–STORED
is never modified.
This table is compared to the speech capabilities of the serving BSS, at call establishment or at handover,
to deduce what can be assigned to the MS.
speech version
1st preferred
2nd preferred
3rd preferred
...................
nth preferred
The speech versions may be among the values defined in Table 10.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
GSM–BC analysis
for speech ver-
sion 1/2
GSM–BC analysis
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Erase
MS–SPEECH–V
N bit321=000,
ITC=speech of
octet 3 meaning speech
N the MS supports
ext bit of octet 3
set multiple speech
versions
N only speech v1
F–RM–005 active offered if option
not active
bits 76 of oct 3
FR v1 HR/FR v1 FR/HR v1
01 10 11
MS supports at
speech FR v1 speech FR+HR speech FR+HR least speech v1
only v1 v1
HR preferred FR preferred
Figure 22. SDL 1/2: Received GSM–BC analysis against speech version.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
GSM–BC analysis
for speech ver-
sion 2/2
2
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
N
HR and/or FR V3
indicated in 1
oct(s)3a
N N
F–RM–013 active oct 3a speech ”speech tbd”... or
version supported other not sup-
by RCF ported versions
are ignored
Y
AMR speech speech other than ext bit of oct 3a
1 codec AMR as indicated set
in oct3a
Y
Speech V1
1 1 already in table
MS–SPEECH–V
copy from
Copy to
MS–SPEECH–V
MS–SPEECH–V–
STORED
N if two GSM–BC
dual service
have been
received
Figure 23. SDL 2/2: Received GSM–BC analysis against speech version.
ED 01
103
4.3.3.3 Selection of pools.
This section applies only when F–RM–007 is active. When not active all the circuits between BSC and SSP
are equipped with transcoders to handle speech v3.
The list of pools supported by the RCF is enhanced according to the pools defined in Table 6.
After the speech versions supported by the MS have been deduced from the received GSM–BC a table
MS–SPEECH–V has been created.
The following table of this section provides a list of pools in association to each combination of speech
versions that may appear in MS–SPEECH–V. The pools are given by order of preference from left to right,
the left being the best choice.
The MS speech preferences of the table are here only listed as possible combinations, regardless of the
MS ordering.
If only the speech TS is to be used then the pool is to be searched out in the pools of next table. For dual
services with basic data services, the search is made in the same table but the pool 23 without data trans-
coder is removed.
The list of pools is sent to the SSP in the TRAU types IE of the CREATE request to establish a leg towards
the BSC.
Some pools of the list may not be physically present on the SSP/BSC interface, but it does not matter
because they will not be selected by the SSP which knows the actual configuration, and no error is gener-
ated.
Note that due to the definition of AMR itself, all the pools supporting speech v3 handle both full and half
rate speech v3.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
MS supported speech ver- pools
sions (speech only or basic dual service)
Table 29. POOL–BASIC: Basic table of pools meeting MS speech versions preferences.
(1) pool 23 is for speech only, and therefore cannot be selected for dual services.
In the above table, the first column gives the combinations of speech versions supported by the MS that
may be found in MS–SPEECH–V, regardless of any ordering.
In each list, the pools in bold italic include speech v3 transcoders, the remaining pools without speech
v3 transcoders are considered fallback solutions in cases where the SSP has been misconfigured or no
free pool with speech v3 is left. That increases the probability to still process the call when no speech v3
transcoder is available. The following table gives a description of these additional pools.
ED 01
103
Pool Coding Supported channels and speech coding algorithms
HR speech v1
HR data (6, 3.6kbps)
Pool selection
Pool selection
Y
dual service
requested
remove pools
without data
transcoders
ED 01
103
4.3.3.4 Channel Assignment
To assign a traffic channel an ASSIGNMENT REQUEST message is sent by the RCF to the BSS.
not permitted without written authorization from Alcatel.
This message contains the CIC which has been retrieved from the SSP and a Channel Type IE which
All rights reserved. Passing on and copying of this
document, use and communication of its contents
If the BSC does not support multi versions of speech, it cannot support speech v3 either, or else when the
BSC supports multi versions of speech but not speech v3 (i.e. when AMRRATE=NONE), the Channel
Type IE is then built according to document RM Ref. [16] with F–RM–013 not active. Otherwise, the follow-
ing of this section applies.
When there are more than one permitted speech version in MS–SPEECH–V, if it is still the case in the
Channel type IE of the ASSIGNMENT REQUEST, their order of appearance will not necessary be the
same. It depends on the network operator choices made over the BSC characteristics.
This section describes the process to build the Channel Type IE from the MS–SPEECH–V table and the
BSC characteristics.
At first, the pool which has been selected by the SSP is checked. The requested speech versions which
are not supported by the pool are removed from MS–SPEECH–V. If no speech v3 is left the Channel Type
IE is then built according to document RM Ref. [16] with F–RM–013 not active. Otherwise, the treatment
is as follows.
When AMRRATE is NONE, the behaviour is the same as it was up to release R5. The ordering of the
speech versions is made as described in document RM Ref.[16] (i.e. FR preferred, from highest to lowest
speech version).
When AMRPRATE is different from MS, MS–SPEECH–V is reshuffled in order that speech versions
appear from highest to lowest within each rate, FR and HR.
– speech FR v1.
ED 01
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]).
not permitted without written authorization from Alcatel.
When the AMRRATE is HR or FR only, and the MS supports both HR and FR, then the speech v3 rate
All rights reserved. Passing on and copying of this
document, use and communication of its contents
which does not fit the BSC characteristic is removed. The network preferences supersede the MS prefer-
ences. However, when a MS indicates only one speech v3 rate (FR or HR) of speech v3 and the BSC
characteristic indicates the opposite rate, then the MS rate is kept in the Channel Type IE. This is possible
because the AMR codecs always support both rates.
When the AMRRATE is BOTH, then AMRPRATE is checked. If AMRPRATE indicates HR or FR, the net-
work preferences supersede the MS preferences, and the order between two speech v3 HR and FR is
reversed if need be. The MS preferences between rates are kept when AMRPRATE is MS.
Finally the channel rate and type information field of Channel Type IE also depends on AMRHO value.
The code values for Channel rate and type of next table, are those given in Table 17.
FR N FR v3 8
HR Y FR v3 8
HR N FR v3 8
BOTH FR Y FR v3 A or 8
BOTH FR N FR v3 1A or 8
BOTH HR Y FR v3 B or 8
BOTH HR N FR v3 1B or 8
BOTH MS Y FR v3 F or 8
BOTH MS N FR v3 1F or 8
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
MS speech preferences A A A Permitted Channel
M M M speech rate and
R R R version type
not permitted without written authorization from Alcatel.
R P H
All rights reserved. Passing on and copying of this
document, use and communication of its contents
A R O
T A
E T
E
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
FR N FR v3 8
HR Y HR v3 9
HR N HR v3 9
BOTH FR Y FR v3 A
HR v3
BOTH FR N FR v3 1A
HR v3
BOTH HR Y HR v3 B
FR v3
BOTH HR N HR v3 1B
FR v3
BOTH MS Y FR v3 F
HR v3
BOTH MS N FR v3 1F
HR v3
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
MS speech preferences A A A Permitted Channel
M M M speech rate and
R R R version type
not permitted without written authorization from Alcatel.
R P H
All rights reserved. Passing on and copying of this
document, use and communication of its contents
A R O
T A
E T
E
HR Y HR v3 9
HR N HR v3 9
BOTH FR Y FR v3 A
HR v3
BOTH FR N FR v3 1A
HR v3
BOTH HR Y HR v3 B
FR v3
BOTH HR N HR v3 1B
FR v3
BOTH MS Y HR v3 F
FR v3
BOTH MS N HR v3 1F
FR v3
Codes for Channel rate and type field (see Table 17. ) are attributed as follows:
– Codes ’F’ and ’1F’ are used when AMRRATE is BOTH and AMRPRATE is MS. This allows the BSC
to be neutral towards the MS preferences.
However if the MS indicates a single type of rate, regardless of the version, they are replaced by ’8’
or ’9’.
– Codes ’8’ and ’9’ are used when AMRRATE is HR or FR only.
However when the MS indicates a single type of rate, but the opposite one, ’8’ is replaced with ’9’
and vice versa.
– Codes ’A’, ’1A’, ’B’, and ’1B’ are used when AMRRATE is BOTH and AMRPRATE is HR or FR.
However when the MS indicates a single type of rate, regardless of the version, they are replaced
by ’8’ or ’9’.
included in order of the channel rate preferences. Within a set of permitted speech versions for a
channel rate, the permitted speech versions are included in order of speech version preferences.
– if one specific rate is indicated, there must be at least one permitted speech version.
ED 01
103
– if no preference for a specific rate is indicated, the permitted speech versions are included in order
of speech version preferences.
not permitted without written authorization from Alcatel.
for assignment
1/3
Y
requested speech
v supported by
selected pool
N
at least one
speech v3 left in
MS–SPEECH–V
treatment according
to Ref. [16] with
AMRRATE F–RM–013 not
active
FR HR BOTH
B C E
MS rate
all HR of MS–
SPEECH–V
removed
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
1 Channel Type IE
for assignment
not permitted without written authorization from Alcatel.
2/3
All rights reserved. Passing on and copying of this
document, use and communication of its contents
MS rate
all FR of MS–
SPEECH–V
removed
ED 01
103
Channel Type IE
for assignment
not permitted without written authorization from Alcatel.
3/3
All rights reserved. Passing on and copying of this
document, use and communication of its contents
MS rate
FR HR MS
B C E
N N N
AMRHO AMRHO AMRHO
code ’1A’ code ’A’ code ’B’ code ’1B’ code ’F’ code ’1F’
all FR speech v all FR speech v all HR speech v all HR speech v speech v ordered speech v ordered
bome before HR come before HR come before FR come before FR as MS– as MS–
speech v speech v FR speech v speech v SPEECH–V SPEECH–V
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
4.3.3.5 RAB Assignment
To assign a RAB a RAB ASSIGNMENT REQUEST message is sent to the RNC by the RCP.
not permitted without written authorization from Alcatel.
In the case of speech this message requests for the establishment of a single RAB which is described by
All rights reserved. Passing on and copying of this
document, use and communication of its contents
the RAB parameters IE. The RAB is identified by the RAB ID IE which must be unique for a given UE.
The message also requests for the Iu UP SMpSDU mode with the User Plane mode IE.
The RAB parameters IE contains parameters associated to the selected codec modes which constitute
a subset of the codec modes supported by the Tc. The Tc supports all the codec modes defined in 3GPP
TS 26.102 Ref.[11] from 4.75kbit/s to 12.2kbit/s, the 1.80kbit/s rate for comfort noise and DTX. The codec
modes selected are given by a PLMN data (refer to §4.3.1.2).
MxBR, GBR and Maximum SDU size are set according to the codec mode(s) actually selected as
described in section §3.3.1.
On reception of RAB ASSIGNMENT REQUEST, the RNC establishes the RAB and runs the initial Iu UP
procedure, upon its completion the Iu UP connection between RNC and TC is established in SMpSDU
mode. The TC had previously been set in this mode by the SSP after the CREATE operation.
The Tc gets all the necessary parameters (Subflow SDU size, rates...) at the initial procedure (see 3GPP
TS 26.071 Ref.[8]). These parameters are a consistent subset wich reflects the common capabilities of
the UE, of the UTRAN, and of the selected codec modes sent at the RAB ASSIGNMENT REQUEST.
Some parameters have been computed by the RNC from the RAB parameters. For instance the Iu Timing
Interval (ITI) is deduced from the Maximum SDU size and Maximum Bit Rate. With the 12.2kbit/s codec
mode and a 244 bits SDU size, the interval is 20ms. Iu speech PDUs are indeed sent every 20ms, which-
ever the codec mode.
When the RAB has been successfully established the RNC sends back to the RCP a RAB ASSIGNMENT
RESPONSE. The established RAB is identified by the returned RAB ID IE.
DTX may be applied on speech depending on the value of DTXAMR PLMN data (see §4.3.1.2).
In case of speech inactivity no frame is sent over the radio interface when DTX is active except for comfort
noise frames (i.e.SID).
DTX is therefore handled as a 0 kbit/s source rate to which is associated a1.80kbit/s source rate for SID.
For DTX activation, a RAB Subflow Combination Bit Rate parameter is included with value set to 0 and
a 1.80kbit/s sublow is defined in the RAB parameters IE of RAB ASSIGNMENT REQUEST and
RELOCATION REQUEST messages. Iu initialisation procedure forwards these information to the TC
which applies DTX.
When DTX is not activated, neither RAB Subflow Combination Bit Rate parameter nor the 1.80kbit/s
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
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].
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
In the MOC case the MS signals to the RCP its capability to support speech v3 (or AMR) in the GSM–BC
IE of the SETUP message.
The GSM–BC may give informations on the MS preferred speech versions as described in 3.1.1.
In case no GSM–BC is found in the SETUP, then speech version 1 is considered to be requested.
The GSM–BC is analyzed according to section 4.3.3.2. A table MS–SPEECH–V results from this analysis.
It contains a list of the MS preferred speech versions supported by the NSS. Speech v3 is available at the
NSS only if speech multiversion is available (i.e. F–RM–005 is active) and the functional option associated
with the present function, F–RM–013, is active.
In case the MS invokes dual services, only the GSM–BC associated with the speech TS is analyzed as
described above.
If the functional option F–RM–005 ”speech multi–version support” is not active, only speech version 1 is
supported by the NSS.
If the functional option F–RM–005 is active, but F–RM–013 is not, then the usual version 1, or version
2 corresponding to the ”Enhanced Full Rate”, is to be used (see document RM Ref.[16]).
Then a CALL PROCEEDING message is sent back to the MS to acknowledge the SETUP. The GSM–BC
it carries contains no indication upon speech versions.
If the circuit pool management is not provided at the RCP (i.e. F–RM–007 is not active) a leg can be directly
created toward the BSS. In that case all the circuits must be equipped with transcoders able to handle
speech v3 in both full and half rates.
Otherwise, if the circuit pool management is available (i.e. F–RM–007 is active), only some circuits are
able to handle speech v3. Following the GSM recommendations the pools they belong to are given in
Table 6. To establish a leg towards the BSS, a CREATE request is sent to the SSP which contains a list
of pools in the TRAU type IE. This parameter, being optional, is not present when F–RM–007 is not active.
The pools are selected according to 4.3.3.3.
The SSP selects a circuit among the pools of the list that are physically present (i.e. the list contains suit-
able pools defined by the recommendations, but not necessary present at the SSP/BSS interface).
The SSP then returns the CIC of the selected circuit, together with the corresponding pool when
F–RM–007 is active.
It is verified whether this pool belongs to the list of pools that support speech v3. If it is not the case (i.e.
due to a SSP misconfiguration or a lack of free circuits) the speech v3 (HR and FR) is removed from the
permitted speech versions of the ASSIGNMENT REQUEST.
This CIC is provided to the BSC through the ASSIGNMENT REQUEST message. The message also car-
ries the channel type with permitted speech versions and rates, half and/or full. The Channel type IE is
constructed according to section 4.3.3.4.
It is acknowledged by an ASSIGNMENT COMPLETE message which normally gives the used speech
1AA 00014 0004 (9007) A4 – ALICE 04.10
If the chosen speech version IE is not present, the speech version indicated by the Permitted speech
version identifier (see section 3.2.1.1) in octet 5 of Channel type IE is assumed to have been chosen.
ED 01
103
The Chosen speech version, received or assumed, is used to update the CDR.
The treatment described here is confined to AMR. A thorough picture if available from documents RM [16]
All rights reserved. Passing on and copying of this
document, use and communication of its contents
In the MTC case the RCP sends to the MS a SETUP message with a GSM–BC IE requesting for speech
TS. No indication is provided on the RCP capabilities or choices related to the speech versions.
From the speech v3 point of view, the treatment is similar to the MOC case.
The MS signals its speech versions capabilities in the GSM–BC of the CALL CONFIRMED message it
sends to acknowledge the SETUP. This GSM–BC, or its absence, are analyzed just as in the MOC case.
Then the pool selection and channel assignment are strictly identical.
In the MOC case the UE signals to the RCP its request for the speech TS in the GSM–BC IE of the SETUP
message. To that purpose the ITC field is set to ’speech’.
The RCP acknowledges the request by sending back a CALL PROCEEDING message to the UE. The
message carries a GSM–BC from which the MS supported speech versions, if any, have been removed
(see 3.1.1 on GSM–BC structure)
In the MTC case the RCP requests for the speech in the GSM–BC IE of the SETUP message with the ITC
field is set to ’speech’. The UE returns back a CALL CONFIRMED with possibly a GSM–BC. If it does
not return a GSM–BC, the request is implicitly acknowledged.
The GSM–BC sent by the UE in SETUP or CALL CONFIRMED may also give information on the MS pre-
ferred speech versions as described in 3.1.1, however this information is not analysed but just memorised
in case of later need for handover. If the MS has not provided a GSM–BC it is considered to support only
FR speech v1 in a GSM network.
After having sent the CALL PROCEEDING or received the CALL CONFIRMED message the RCP per-
forms a CREATE operation towards the SSP.
The purpose of the CREATE is to prepare the SSP and TC resources to the incoming AAL2 and Iu UP
connections. To get a detailed description see document BCH Ref.[18].
The RCP sets the TCinfo parameter of CREATE to ’Support Mode for predefined SDU size’ which is the
Iu UP necessary mode for speech.
In the same time the RCP sends to the RNC the RAB ASSIGNMENT REQUEST which has been built
according to 4.3.3.5.
The SSP sets the previously allocated TC into the SMpSDU mode, the RNC then establishes the AAL2
connection and runs the Iu UP initial procedure. This initial procedure provides the TC with all the parame-
ters to map between the speech TDM frames and Iu UP PDUs. These parameters result from the codec
modes supported by TC, RNC and UE in common.
Upon successful Iu UP inital procedure the RNC acknowledges the RCP with RAB ASSIGNMENT
1AA 00014 0004 (9007) A4 – ALICE 04.10
RESPONSE.
ED 01
103
4.3.3.9 Paging in UMTS
In UMTS the PAGING message (refer to BCH Ref.[18]) includes an optional Paging cause parameter
which has the value Terminating Conversational Call in case of a speech call.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
To that purpose, when the VLR requests paging for terminated calls, the PLMN–BC received from the VLR
by the RCF is analyzed to identify whether the call will be for speech or data.
In case no PLMN–BC is available the Paging cause is not included in the PAGING message.
Determination of
the type of call
N
PLMN–BC avail-
able?
Y Speech
ITC=speech?
The term ’Handover’ is applicable when the serving entity is 2G, and ’Relocation’ when 3G.
In some handover cases described further in the document, handover related messages carry a Channel
Type IE. Since a target RCP may have no knowledge of the received GSM–BC, and the characteristics
of the target BSC may differ from those of the serving BSC, the Channel Type IE has to be determined
in a different way from the channel assignment case.
ED 01
103
The above rule applies in the 2G³2G handover and in the 3G³2G handover cases. In the latter case
the GSM–BC received from the MS has in addition to be analysed as stated in 4.3.3.2.
The reception of HANDOVER PERFORMED message means that the BSS has performed an internal
handover. In particular, it is the case when AMR handovers occur between FR and HR.
It is expected to have less than 5 such handovers in a two minute call. This figure is only provided for
information, the RCP performs no specific associated treatment.
The HANDOVER PERFORMED message may describe the characteristics of the new channel with a
Chosen Channel IE and a Speech Version (Chosen) IE. At any receiving MSC no check is performed on
these IEs. As a consequence if a value happens to be in contradiction with the characteristics of the allo-
cated channel type/speech version, no action of defense is undertaken and the call is carried on.
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 also
contain Old BSS to New BSS Information IE and Current Channel type 1 IE.
If F–RM–013 is active, the Speech version (used) IE may indicate GSM full rate speech v3 or GSM half
rate speech v3. If it indicates so while F–RM–013 is not active, the IE is ignored.
When received, the Speech version (used) IE is included unchanged in the HANDOVER REQUEST later
sent to the target BSS. When none has been received, a Speech version (used) is nevertheless sent in
the HANDOVER REQUEST based on the last received speech version (in ASSIGNMENT COMPLETE,
HANDOVER PERFORMED or HANDOVER REQUEST ACKNOWLEDGE). However, the inclusion of
Speech version (used) IE depends on a BSC characteristic (see document HO Ref. [17]).
The Old BSS to New BSS Information IE, when received, is to be passed transparently to the target BSS
by the RCP in the HANDOVER REQUEST. This IE may contain a MultiRate configuration information
Field Element which gives informations about the current AMR speech codec configuration. The target
BSS will use this information to build the HANDOVER COMMAND if it uses AMR.
The HANDOVER REQUEST message sent to the target BSS contains a Channel type IE which is man-
aged similarly to 4.3.3.4. with as input table a newly built MS–SPEECH–V. The new MS–SPEECH–V
comes from MS–SPEECH–V–STORED which had been memorized upon GSM–BC analysis, and takes
into account the characteristics of the target BSS (AMRRATE, AMRPRATE, AMRHO). The pool selected
by the SSP is also checked as in the assignment case to remove not supported speech versions. Finally
the new MS–SPEECH–V constitutes an input to define the Channel type IE fields.
However, prior to sending HANDOVER REQUEST, a leg toward the target BSS is created. When
F–RM–007 is active, the list of pools is built up according to 4.3.3.3 and also depends on the received
GSM–BC.
If the target BSS can support the handover it sends back a HANDOVER REQUEST ACKNOWLEDGE
message with a Speech version (Chosen) IE and a Chosen channel IE. In our case, the speech version
1AA 00014 0004 (9007) A4 – ALICE 04.10
may be v3.
When the handover finally succeeds a HANDOVER COMPLETE message is received by the RCF.
ED 01
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].
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
When the handover procedure involves more than one MSC, the HANDOVER REQUEST message is
exchanged on the E interface between MSCs, encapsulated within MAP operation PrepareHandover
(invoke). In return a HANDOVER REQUEST ACKNOWLEDGE or HANDOVER FAILURE is received from
the target MSC, encapsulated in the PrepareHandover (result) MAP operation. The HANDOVER
REQUEST always carries a Channel type IE. When F–RM–005 and F–RM–013 are active, this IE may
contain multiple speech versions, and among them speech v3.
The controlling RCF builds a Channel Type IE according to 4.3.3.10.1. and sends it in a HANDOVER
REQUEST to the target RCF.
At the target MSC, when F–RM–007 is active, the Channel type IE of the received HANDOVER REQUEST
is used according to section 4.3.3.3 text and Table 29. to get an appropriate list of pools for the leg creation
toward the target BSS. However, pools without support of data (e.g. pool number 23) are removed from
the list of pools provided to the SSP. The rationale is, the target MSC being not aware of the type of the
call, speech only or dual speech/data, a selected pool without data support would cause the rejection of
a later in–call modification.
At the target MSC the characteristics of the target BSC are applied on the received Channel Type IE per-
mitted speech versions in the same way as on MS–SPEECH–V for the assignment case. The new result-
ing Channel Type IE is used by the target RCP to send the HANDOVER REQUEST to the target BSC.
This is the so–called subsequent handover with three MSCs involved. The serving sends a HANDOVER
REQUEST to the controlling MSC, with a Channel Type IE. This IE is ignored by the controlling MSC, which
builds a new Channel Type IE as in 4.3.3.10.4 case a ). This new Channel Type IE is forwarded to the
target MSC in a HANDOVER REQUEST.
At the target MSC the characteristics of the target BSC are applied on the received Channel Type IE per-
mitted speech versions in the same way as on MS–SPEECH–V for the assignment case. The new result-
ing Channel Type IE is used by the target RCP to send the HANDOVER REQUEST to the target BSC.
This is similar to 4.3.3.10.4 case a ). Also about pool selection, pools without support of data (e.g. pool
number 23) are removed from the list of pools provided to the SSP.
This is the so–called subsequent handover with two MSCs involved. The serving RCF sends a HAND-
OVER REQUEST to the controlling MSC, with a Channel Type IE. This IE is ignored by the controlling
MSC.
The controlling/target MSC builds a new Channel Type IE from the MS–SPEECH–V table and the charac-
teristics of the target BSC. This IE is then forwarded to the target BSC in a HANDOVER REQUEST.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
4.3.3.10.5 Intra–BSS handover at a serving MSC
This case occurs when an inter MSC happened beforehand. The target and serving cells are controlled
by same RCF which is not the controlling RCF.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The informations of the Channel Type IE of HANDOVER REQUEST and to get the pool list are the same
as in 4.3.3.10.4 case a ).
When an intra–BSS handover occurs at a serving MSC, different from the controlling MSC, a HANDOVER
PERFORMED message is sent to the controlling MSC through the E interface encapsulated within the
MAP operation Process Access Signalling.
The reception of HANDOVER PERFORMED message at the controlling MSC means that the serving BSS
has performed an internal handover. In particular, it is the case when AMR handovers occur between FR
and HR.
It is expected to have less than 5 such handovers in a two minute call which can induce an increased sig-
nalling traffic at MSCs. This figure is provided for information. No treatment is associated at the MSC.
Preamble:
As in UMTS there is only one possible and thus mandatory codec, no treatment is really associated with
speech. The only information which is carried over between 3G MSCs is related with the UMTS AMR
codec modes supported by the TC. This is a consequence of the possible configuration where Iu UP over
AAL2 may be used between MSCs. In that configuration the TC is always located at the anchor MSC.
In our present configuration the MSCs are always connected through a TDM link. The TC is therefore
always connected to the serving MSC and the signalling on TC capabilities between MSCs is not useful.
UMTS relocation:
The relocation is triggered by the Serving RNC sending an Iu RELOCATION REQUIRED message to its
serving MSC.
Intra MSC:
In this case an Iu RELOCATION REQUEST message is forwarded to the target RNC.This message car-
ries a RAB parameters IE and a User Plane mode IE. These parameters are set for speech identically
to the RAB assignment case described in 4.3.3.5.
The remaining of the procedure and the other parameters are fully described in document HO Ref.[17].
Inter MSC:
In that case a MAP PREPARE HANDOVER REQUEST message is forwarded to the target 3G MSC. This
message carries a RANAP Iu RELOCATION REQUEST in a AN–APDU container (see 3GPP TS 29.002
Ref.[13]). The RAB parameters IE of the RELOCATION REQUEST message include all the codec modes
[4.75kbit/s – 12.2kbit/s], without DTX.
At the target 3G MSC the RAB parameters IE of the received RELOCATION REQUEST message are
ignored. RAB parameters IE are instead replaced in the RELOCATION REQUEST message sent to the
1AA 00014 0004 (9007) A4 – ALICE 04.10
target RNC with parameters depending on the target MSC configuration of DTX and codec modes (target
MSC PLMN data) as for the RAB assignment case described in 4.3.3.5.
The remaining of the procedure and the other parameters are fully described in document HO Ref.[17].
ED 01
103
4.3.3.10.7 Handover from GSM to UMTS
As in UMTS there is only one possible and thus mandatory codec, no particular treatment is associated
with speech.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The handover is triggered by the Serving BSC sending a HANDOVER REQUIRED message to its serving
MSC. The message may carry the optional following IEs:
– Current Channel Type 1,
– Speech Version (Used),
– Old BSS to New BSS Information.
Furthermore, the HANDOVER REQUIRED message carries a Source RNC to target RNC transparent
information (UMTS) IE which has the same structure as when generated in a RNC (see GSM 08.08 [2]).
Intra MSC:
In this case the MSC justs sends a RELOCATION REQUEST message to the serving RNC. This message
carries the received Source RNC to target RNC transparent information (UMTS) IE, a RAB parame-
ters IE and a User Plane mode IE. These parameters are set for speech identically to the RAB assignment
case described in 4.3.3.5. The RAB parameters IE setting is performed according to 4.3.3.5.
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 the
received optional IEs (Current Channel Type IE, Speech Version (Used) IE and Old BSS to new BSS
Information IE). It also carries the received Source RNC to target RNC transparent information
(UMTS) IE. At the target 3G MSC an Iu RELOCATION REQUEST message is sent to the RNC. This mes-
sage contains the received Source RNC to target RNC transparent information (UMTS) IE, a User
Plane mode IE which is set to SMpSDU, and a RAB parameters IE which setting is performed according
to 4.3.3.5.
The remaining of the procedure and the other parameters are fully described in document HO Ref.[17].
The Handover is triggered by the Serving RNC sending an Iu RELOCATION REQUIRED message to its
serving MSC. This message carries an Old BSS to new BSS Information IE which has the same struc-
ture as when generated in a BSS (see 3.2.7 and [2]).
Intra MSC:
In this case the serving MSC sends a HANDOVER REQUEST message to its controlled BSC (see 3.2.5).
The message is built as follows:
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
The remaining of the procedure and the other parameters are fully described in document HO Ref.[17].
Inter MSC:
not permitted without written authorization from Alcatel.
In that case the serving MSC sends a MAP PREPARE HANDOVER REQUEST message to the target 2G
All rights reserved. Passing on and copying of this
document, use and communication of its contents
MSC. This message carries a HANDOVER REQUEST message which has been built identically to above
Intra–MSC case.
At the receiving target 2G–MSC the MAP PREPARE HANDOVER REQUEST message is treated as is
intra 2G–MSC case (see document HO Ref.[17]).
Service handover UMTS³GSM feature is supported for speech calls when option F–HO–014 is active.
When option F–HO–014 is active MMC MODSHO (see MMCRCP Ref.[22]) is available. This command
associates in a table (SHPLMN) to a PLMN identification MCC+MNC a ’Service Handover for speech’
parameter (SHSPEECH).
The MCC+MNC of the IMSI of the subscriber is used here to get SHSPEECH value. The IMSI may corre-
spond to a visiting roamer, or to a subscriber in his home PLMN.
If there is no entry in SHPLMN table for that MCC+MNC (i.e.no SHSPEECH parameter defined, the opera-
tor has not yet invoked MODSHO for that MCC+MNC), or if the IMSI is not available (i.e.if it has not been
received by the serving RCP), a default value for SHSPEECH is used.
There exists a single default value for SHSPEECH which is associated to MCC+MNC=’000 000’. This
default value can be modified by MODSHO.
Following the introduction of Service Handover function (i.e. activation of F–HO–014) the default value
of SHSPEECH parameter associated with MCC+MNC=’000 000’ may remain undefined until MMC MOD-
SHO has been applied, in that case No Service Handover is used.
ED 01
103
Locally managed SHPLMN table is used to get the value of SHSPEECH and decide on the emission of
Service Handover IE and its content. That implies that the Service Handove IE received in a RELOCA-
TION REQUEST message contained in a PREPARE HANDOVER REQUEST is superseded by a locally
generated Service Handove IE or removed, depending on local SHSPEECH value, before sending
not permitted without written authorization from Alcatel.
When option F–HO–014 is not active Service Handover IE is never sent for speech calls.
The in–call modification is initiated by the MS if a dual service has been negotiated at call setup and if the
MS desires to change the call mode, from data to speech, or conversely. In the present description we are
only interested with the data to speech case.
The RCF receives a MODIFY message with a GSM–BC which is analyzed as described in 4.3.3.2. A MS–
SPEECH–V table results from this analysis. In addition, the RCP ability to treat data transmissions limited
to FR channels being extended to speech in dual services calls, any reference to an HR channel is
removed from MS–SPEECH–V.
If the channel assignment fails the RCF sends a MODIFY REJECT with Cause IE set to ”Bearer capability
not presently available”.
The MODIFY REJECT message contains the current GSM–BC which corresponds to the data service in
progress.
If the assignment procedure is successful, then a MODIFY COMPLETE is returned to the MS with the
GSM–BC which has been received in the MODIFY.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
In–call modifica-
tion
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
MODIFY
GSM–BC
analysis
N
speech
output
MODIFY REJECT build MS–SPEECH–V
Channel Type IE
according to BSC
data call in prog- ASSIGNMENT characteristics
ress REQUEST
ASSIGNMENT ASSIGNMENT
COMPLETE FAILURE
ED 01
103
4.3.4 Observation
4.3.5 Charging
The CDR is updated with AMR related informations only when the option F–CG–056 is active.
In that case, the CDR includes the following indications:
– choice left to the BSC between FR and HR, with or without a preference,
– which rate the BSC has retained,
– and the chosen speech version.
It is also updated with the best speech version supported by the MS for both Half and Full Rate which have
been provided at call setup in its bearer capabilities. Speech v3 is considered better than v2, which is better
than v1. It is also indicated if the MS does not support any Half Rate speech.
Although the chosen speech version may change due to handover, the CDR is updated once, upon suc-
cessful channel assignment.
If F–CG–056 is inactive while F–RM–013 is active, and the MS supports speech v3, the CDR is updated
by default values (see document CG Ref.[24]) which do not truthfully reflect the choices left to the BSC,
what the BSC has retained and the chosen speech version. This state where the two options are not simul-
taneously active should however be a transient state, until the CDR collector is able to process the AMR
related parameter values.
The ’Chosen speech version’ is updated with the value ”UMTS AMR speech v1” when option F–CG–062
is active.
Although the ’Chosen speech version’ may later change due to handover towards GSM, the CDR is not
updated.
When F–CG–062 is not active ’Chosen speech version’ is not relevant. This situtation should however be
transient until the CDR collector is able to process the UMTS AMR related parameter value.
The BSC speech related information (Required bearer capability) is not relevant, it is therefore set to a
default value as stated in CG Ref.[24].
4.3.6 Timers
4.3.7 Errors
The following error is generated in case a second call or a call waiting requesting for a data service cannot
be processed due to an incompatible allocated pool (e.g. the pool supports only speech such as pool 23).
See document RM Ref.[16] for a detailed description.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
ERR_RM_006 The requested channel or circuit pool is not compatible with the channel or cir-
cuit pool already allocated.
not permitted without written authorization from Alcatel.
This error is not applicable to UMTS because the notion of pool is not relevant.
4.3.8 Warnings
4.4 SSP
In the SSP, associated to each BSC, only 16 pools can be defined. However the SSP knows up to 64 pools.
The 16 pools can therefore be numbered from 0 to 63.
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103
5 INTERACTIONS WITH OTHER SERVICES
In GSM, in the case of interaction with suplementary services such as CALL HOLD and CALL WAIT , the
All rights reserved. Passing on and copying of this
document, use and communication of its contents
ASSIGNMENT REQUEST corresponding to the acceptance of a call takes into account the already estab-
lished ressources. That is to say, if the pool currently in use does not support some speech versions, they
are not proposed in the Channel Type IE of the ASSIGNMENT REQUEST.
Furthermore, a call waiting or a second call, requesting for a data service is rejected if the currently allo-
cated pool only supports speech (e.g. pool 23) and the error ERR_RM_006 is generated.
END OF DOCUMENT
1AA 00014 0004 (9007) A4 – ALICE 04.10
ED 01
103