umt sys dd 018824 v03.06 en - amr cs speech service support - umts access standard

AMR CS speech service support - UMTS Access Document number: UMT/SYS/DD/018824 Document issue: 03.06 / EN Document status: Standard Date: 19/May/2008

External document

Copyright 2007 Alcatel-Lucent, All Rights Reserved

Printed in France

ALCATEL-LUCENT CONFIDENTIAL

The information contained in this document is the property of Alcatel-Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information contained herein confidential, shall disclose the information only to its employees with a need to know, and shall protect the information from disclosure and dissemination to third parties. Except as expressly authorized in writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have received this document in error, please notify the sender and destroy it immediately

without notice. Nortel Networks assumes no responsibility for errors that might appear in t.All other brand and

AMR CS speech service support - UMTS Access

Alcatel-Lucent confidential

UMT/SYS/DD/018824 03.06 / EN Standard 19/May/2008 Page 2/129

PUBLICATION HISTORY 19/May/2008 Issue 03.06 / EN, Standard Update after review

05/May/2008 Issue 03.05 / EN, Standard Descoping of 32687 functionality (no iRM table checks at call admission, no

AMR rate control for multi-service calls when PS is mapped to R99 DCH) Remove support of SRB#5

25/Apr/2008 Issue 03.04 / EN, Standard Update according review comments

04/Apr/2008 Issue 03.03 / EN, Preliminary Market Information added

16/Feb/2008 Issue 03.02 / EN, Preliminary Update after review

28/Jan/2008 Issue 03.01 / EN, Preliminary Creation based on issue 02.05 Feature 34216 added for UA6.0

05/Dec/2007 Issue 02.05 / EN, Standard Update after review

26/Nov/2007 Issue 02.04 / EN, Preliminary POR update




19/Sep/2007 Issue 02.03 / EN, Standard 13/Sep/2007 Issue 02.02 / EN, Preliminary 31/Aug/2007 Issue 02.01 / EN, Preliminary Updated after review

16/Jul/2007 Issue 02.00 / EN, Draft Creation based on 01.05 document Updated for UA06.0 (features #27804, #32647 & #32687)




CONTENTS

1 INTRODUCTION............................................................................................................................7 1.1 OBJECT....................................................................................................................................7 1.2 FRS ........................................................................................................................................7 1.3 SCOPE OF THIS DOCUMENT .......................................................................................................7 1.4 AUDIENCE FOR THIS DOCUMENT ................................................................................................8 1.5 DEFINITIONS & EDITORIAL CONVENTIONS ...................................................................................8

2 RELATED DOCUMENTS ............................................................................................................10 2.1 APPLICABLE DOCUMENTS ........................................................................................................10 2.2 REFERENCE DOCUMENTS ........................................................................................................10

3 FUNCTION OVERVIEW ..............................................................................................................12

4 BENEFITS....................................................................................................................................16 4.1 CUSTOMER/SERVICE PROVIDER BENEFITS ................................................................................16 4.2 END-USER/SUBSCRIBER BENEFITS ........................................................................................17

5 FUNCTIONAL DESCRIPTION ....................................................................................................18 5.1 PRINCIPLE ..............................................................................................................................18

5.1.1 AMR support with Iu UP V1 (features 30229 & 18717 not activated)...........................18 5.1.2 AMR multi-mode support with Iu UP V2 (18717, 30229, 33863)..................................21 5.1.3 Wideband AMR (27803)................................................................................................28 5.1.4 AMR mode change during call (32687) ........................................................................33 5.1.5 AMR support with Iu UP V1 (featurE 34216 activated).................................................40

5.2 INTER SUB-SYSTEM FUNCTIONAL DISTRIBUTION ........................................................................41 5.2.1 RNC...............................................................................................................................41 5.2.2 Node B ..........................................................................................................................41 5.2.3 OMC..............................................................................................................................41

5.3 USE CASES.............................................................................................................................42 5.3.1 AMR support with Iu UP V1 ..........................................................................................42 5.3.2 AMR-NB multi-mode support with Iu UP V2 (18717, 30229)........................................42 5.3.3 Wideband AMR (27803)................................................................................................44 5.3.4 AMR mode change during call (32687) ........................................................................45 5.3.5 34216 AMR IMprovements ........................................................................................46

5.4 RNS INTER-RELEASE COMPATIBILITY USE CASES ....................................................................47 5.4.1 Features 30229, 18717 .................................................................................................47 5.4.2 Feature 27803...............................................................................................................48 5.4.3 Feature 32687...............................................................................................................49 5.4.4 Feature 34216...............................................................................................................49

5.5 FEATURE INTERWORKING ........................................................................................................50 5.5.1 Dependencies ...............................................................................................................50 5.5.2 Interaction......................................................................................................................51

5.6 PERFORMANCE IMPACTS. ........................................................................................................55




5.6.1 System performances ...................................................................................................55 5.6.2 Dimensioning ................................................................................................................55 5.6.3 Capacity ........................................................................................................................56 5.6.4 Dependability ................................................................................................................56 5.6.5 End User Performances................................................................................................56

5.7 SECURITY...............................................................................................................................56

6 INTERFACES ..............................................................................................................................56 6.1 UMTS INTERFACES ................................................................................................................57

6.1.1 UU interface...................................................................................................................57 6.1.2 IU interface ....................................................................................................................75 6.1.3 IUR interface ..................................................................................................................76 6.1.4 IUB interface ..................................................................................................................77 6.1.5 IUPC Interface (RNC/SAS).............................................................................................78 6.1.6 IUBC Interface (RNC/CBC) ............................................................................................78

6.2 OAM INTERFACES ..................................................................................................................79 6.2.1 3GPP OAM interfaces...................................................................................................79 6.2.2 External ALCATEL-LUCENT OAM interfaces ..............................................................79

6.3 TRANSMISSION NETWORK INTERFACES ....................................................................................79 6.3.1 Physical layer ................................................................................................................79 6.3.2 Ethernet.........................................................................................................................80 6.3.3 ATM...............................................................................................................................80 6.3.4 IP ...................................................................................................................................80

7 OAM MODEL DESCRIPTION .....................................................................................................81 7.1 CONFIGURATION MANAGEMENT...............................................................................................81

7.1.1 RAN Managed Objects .................................................................................................81 7.1.2 RAN Customer Parameters ..........................................................................................90 7.1.3 CDL ............................................................................................................................ 106 7.1.4 CDL: New/Modified/removed COMPONENTS .......................................................... 106 7.1.5 Control rules............................................................................................................... 106

7.2 FAULT MANAGEMENT ........................................................................................................... 108 7.2.1 RNC CNode, BTS and OAM Alarm Notifications....................................................... 108 7.2.2 RNC INode Alarm Notifications.................................................................................. 108 7.2.3 State Changes ........................................................................................................... 108

7.3 PERFORMANCE MANAGEMENT .............................................................................................. 108 7.3.1 Counters..................................................................................................................... 108 7.3.2 Metrics........................................................................................................................ 119 7.3.3 Traces ........................................................................................................................ 119

7.4 MISCELLANEOUS ................................................................................................................. 121 7.4.1 Static Data.................................................................................................................. 121 7.4.2 Inventory..................................................................................................................... 121 7.4.3 Action ......................................................................................................................... 121

8 OAM PROCEDURES ............................................................................................................... 122 8.1 UPGRADES .......................................................................................................................... 122

8.1.1 OAM platform Upgrade .............................................................................................. 122 8.1.2 RNC & BTS Upgrade ................................................................................................. 122

8.2 INSTALLATION & COMMISSIONING PROCEDURES .................................................................... 126 8.3 MAINTENANCE ..................................................................................................................... 126 8.4 OPERATION ......................................................................................................................... 126




8.5 EXTENSION ......................................................................................................................... 126 8.6 TECHNICAL ASSISTANCE SUPPORT ....................................................................................... 127 8.7 STABILITY DATA ANALYSER .................................................................................................. 127

9 FIELD INTRODUCTION ........................................................................................................... 127 9.1 HARDWARE CONSTRAINTS.................................................................................................... 127 9.2 SPARE PART CONSTRAINTS .................................................................................................. 127 9.3 INTER RNS VERSION INTERWORKING ................................................................................... 128

9.3.1 Features 30229, 18717 .............................................................................................. 128 9.3.2 Feature 27803............................................................................................................ 128 9.3.3 Feature 32687............................................................................................................ 128

9.4 CORE NETWORK INTERWORKING........................................................................................... 128 9.5 UE INTERWORKING .............................................................................................................. 128 9.6 GERAN INTERWORKING ...................................................................................................... 128

10 TOOLS IMPACTS..................................................................................................................... 129

11 RESTRICTION TABLE.....................................................ERROR! BOOKMARK NOT DEFINED.

12 ABBREVIATIONS AND DEFINITIONS.................................................................................... 130 12.1 ABBREVIATIONS ................................................................................................................... 130 12.2 DEFINITIONS ........................................................................................................................ 131

12.2.1 ALCATEL-LUCENT specific definitions ..................................................................... 131 12.2.2 AMR specific definitions ............................................................................................. 132 12.2.3 Other 3GPP definitions .............................................................................................. 133

13 ANNEX A. ................................................................................................................................. 134




1 INTRODUCTION

1.1 OBJECT This document describes the AMR speech service capability supported by the Alcatel-Lucent UTRAN.

1.2 FRS The UA05.0 applicable FRS(s) are: FRS #30229 Iu UP SMpSDU V2 FRS #18717 AMR-NB multi-mode support (for Iu UP V2)

The UA05.0.3 applicable FRS(s) are: FRS #33863 Initialisation of AMR DL Rate from OMC

In UA05.1 applicable FRS(s): FRS #27803 Adaptive Multi Rate - Wide Band

In UA06.0 applicable FRS(s): FRS #32687 AMR mode change during call - evolution

o 32687-1 AMR rate control based on radio criteria o 32687-2 AMR rate control based on Iub load criteria

In UA06.0 applicable FRS(s): FRS #34216 AMR improvements

1.3 SCOPE OF THIS DOCUMENT The scope of this document is UTRAN. According to 3GPP this includes the following nodes: Node B, RNC and OMC. This document applies respectively to: The UMTS06.0 solution version i.e. UA06.0 and OAM06.0 releases

1.4 AUDIENCE FOR THIS DOCUMENT This document is provided for the following manufacturer and customer departments: validation, engineering and installation.




This document is used for Alcatel-Lucent internal purposes as well (e.g. system validation and engineering).

1.5 DEFINITIONS & EDITORIAL CONVENTIONS The following definitions are used: Within this document the following definition convention is used:

o AMR mode It refers to any AMR rate delivered by an AMR codec with the exclusion of rates related to the silent mode (SID rate and No Data rate)

o AMR rate It refers to any AMR rate including the silent mode rates

Iu UP Iu User Plane SMpSDU Support Mode for predefined SDU size For other definitions used throughout this document, please refer to section

12. The following editorial conventions are used: Cross out (strikethrough): when used in tabular: means not supported or not

used. Change bar: indicates additions or deletions

1.6 DEFINITIONS AND SPECIFICATION PRINCIPLES The present document addresses several markets with potentially different behaviours in those markets. The definition of Global Market and USA Market are: Global Market: customers other than those part of the following market. USA Market: customers with UTRAN where Alcatel-Lucent 939X Node B (former Lucent Flexent Node B) is deployed. For the purpose of the present document, the following notations apply: [Global Market] This tagging of a word indicates that the word preceding the tag

"[Global Market]" applies only to the Global Market. This tagging of a heading indicates that the heading preceding the tag "[Global Market]" and the section following the heading applies only to the Global Market. This tagging shall, in particular, be used under the parameter name of parameters specific to the Global Market.

[USA Market] This tagging of a word indicates that the word preceding the tag "[USA Market]" applies only to the USA Market. This tagging of a heading indicates that the heading preceding the tag "[USA Market]" and the section following the heading applies only to the USA Market. This tagging shall, in particular, be used under the parameter name of parameters specific to the USA Market.




[Global Market - ] This tagging indicates that the enclosed text following the "[Global Market - " applies only to the Global Market. Multiple sequential paragraphs applying only to Global Market are enclosed separately to enable insertion of USA Market specific (or common) paragraphs between the Global Market specific paragraphs.

[USA Market - ] This tagging indicates that the enclosed text following the "[USA Market - " applies only to the USA Market. Multiple sequential paragraphs applying only to USA Market are enclosed separately to enable insertion of Global Market specific (or common) paragraphs between the USA Market specific paragraphs.

Text that is not identified via one of the hereabove tags is common to all markets.




2 RELATED DOCUMENTS

2.1 APPLICABLE DOCUMENTS

Ref. # Document Identifier Document Title [A0] UMT/SYS/DD/018826 Call Admission Control [A1] UMT/SYS/DD/000111 Alcatel-Lucent RNS V6.0 Compliance to 3GPP-TS25.415- UTRAN Iu

Interface User Plane Protocols

2.2 REFERENCE DOCUMENTS

The.3GPP baseline for UA06.0 is described in the FRS 33817 3GPP baseline & additional CRs for UA06. 3GPP documents

Ref. # Document Identifier Document Title [R1] TS 25.331 Radio Resource Control (RRC); Protocol Specification [R2] TS 25.413 UTRAN Iu interface RANAP signalling [R3] TS 25.423 UTRAN Iur interface RNSAP signalling [R4] TS 25.433 UTRAN Iub interface NBAP signalling [R5] TS 32.104 3G Performance Management (PM) [R6] TS 25.415 UTRAN Iu interface user plane protocols [R7] TS 26.102 AMR speech codec; Interface to Iu, Uu and Nb [R8] TS 26.202 AMR wideband speech codec; Interface to Iu, Uu and Nb [R9] TS 34.108 Common Test Environments for User Equipment (UE); Conformance

Testing [R10] TR 25.993 Typical examples of RABs and RBs supported by UTRA; R6 [R11] TS 23.153 Out of band transcoder control [R12] TS 28.062 Inband Tandem Free Operation (TFO) of speech codecs [R13] TS 26.103 Speech codec list for GSM and UMTS

Alcatel-Lucent documents

Ref. # Document Identifier Document Title [R20] UMT/SYS/DD/0054 UMTS radio mobility [R21] UMT/SYS/DD/0128 Intelligent RAB mapping (iRM) [R22] UMT/SYS/DD/0034 PS call management [R23] UMT/SYS/DD/18470 SRNS Relocation - UE not involved




[R25] UMT/SYS/DD/0086 UTRAN power management [R26] UMT/SYS/DD/08326 Radio Bearer configuration parameters

Other standard documents

Ref. # Document Identifier Document Title [R30] M3100 Maintenance Telecommunications Management Network: Generic

Network Information Model [R31] X721 OSI Systems management: Definition of Management Information [R32] X730 OSI Systems management: Object Management [R33] X731 OSI Systems management: State management [R34] X733 OSI Systems management: Alarm reporting [R35] GR-1929-Core Telcordia Technologies: Reliability and Quality Measurements for

Telecommunications Systems (RQMS Wireless) [R36] GR-815-Core Telcordia Technologies: Generic Requirements for Network

Security/Network System (NE/NS) Security




3 FUNCTION OVERVIEW Up to release UA04.2 the bearer service support for AMR was restricted to mono-mode AMR, i.e. bearer service support for AMR 12.2 and support of silent mode (aka SCR (VAD/DTX)) with use of version 1 of Iu UP. The following set of features provides the bearer service support for additional AMR codecs: [Global Market]The UA05.0 features 18717 AMR-NB multi-mode support and

30229 Iu UP SMpSDU V2 provide the bearer service support with use of version 2 of Iu UP for a number of narrowband AMR speech service and the support of a number of functions to allow core network Transcoder/Tandem Free mode of Operation (TrFO/TFO) speech calls.

RbSetConf # B

RbSetConf # A

12.2 12.2 7.95 5.9

4.75

SID [No]

SID [No]

10.2 6.7 5.9

4.75

SID [No]

5.9 4.75

SID [No]

4.75

SID [No]

DL SF 128 (CS speech service only) DL SF 256 Multi-service possible with DL SF 128 Only Mono-service

Only with Version 2 of Iu UP Version 1 or 2 of Iu UP

All AMR-NB configurations are with 3 AMR sub-flows over Iub/Iur and radio interfaces

All RABs are with

VAD/DTX

Only with Version 2 of Iu UP

[Global Market]The UA05.0.3 feature 33863 Initialisation of AMR DL Rate

from OMC allows the operator to control the max allowed AMR DL rate for the OMC

[Global Market]The UA05.1 feature 27803 AMR-WB provides the support by

the RAN of the necessary means to provide the CS WB telephony built on the multi-mode AMR WB speech codec. This consists in providing the required RAB as well as the means for changing UL and DL Rates. This feature works only with Iu UP v2.




RbSetonf # C

12,65 8,85 6,6

SID [No]

DL SF 128 (CS speech service only)

Multi-service possible with DL SF 128

All AMR-WB configurations are with 3 AMR sub-flows over Iub/Iur & Radio interfaces

All RABs are with VAD/DTX

Only with Version 2 of Iu UP

RbSetConf # C

The following set of UA06.0 features provides some optimizations in order to support more speech calls per cell:

[Global Market]DL AMR mode adaptation during the call (feature 32687)

No AMR Radio Bearer allocation change is performed during the call, only the rate is controlled. - This applies only to CS speech AMR calls with any controllable rate(s) (as per

3GPP 25.415 spec definitions)*. - The RNC may unilaterally decide to change the set of allowed the UL rate(s):

Whenever the Cell -RTWP- becomes highly (respectively lowly) loaded

- The RNC may unilaterally decide to change the DL rate: Whenever the Cell -DL Total Transmitted power- becomes highly

(respectively lowly) loaded Whenever the DL Transmitted power is above is pre-defined max

power threshold during at least an OAM configurable amount of time, the RNC will request the Core Network to reduce the DL AMR rate in order to avoid excessive power consumption in the cell by a single call.

Whenever the DL transmitted power is under a pre-defined min power threshold during at least an OAM configurable amount of time, the RNC will no more restrict the upper rates provided that there is no restriction from Iub resource perspective.

The Max permitted DL Tx power for a individual AMR call depends on the Cell, the physical channel configuration (AsConf) and the OLS

The assigned DL Target BLER depends on the DCH configuration -DCH carrying the Class A bits- and the OLS

- The RNC decides on the set of allowed rates based on the Iub resource load The Iub DS iRM table determines the max allowed rate. If the current

rate excesses the max allowed rate, the RNC will request the Core Network to prohibit some of the upper DL AMR rates and the UE to prohibit some of the upper UL AMR rates (TFCS reduction).




The max allowed rate as output of the Iub iRM table is used to determine the Equivalent Bit Rate (EBR) over Iub instance related to the added link.

- The RNC may unilaterally decide to restrict the UL and the DL rates of several individual calls if an Iub instance becomes loaded:

Whenever the Iub resource becomes loaded, the RNC will restrict the rate of some of the individual AMR call using this Iub and having any rate above a pre-defined max rate threshold being above GBR.

This typically copes with cases where in some cells there would be many stationary UEs.

Before re-enabling a previously disabled AMR rate the RNC needs to check whether this AMR rate is inline with the bandwidth of the currently established transport bearers.

Note: The load colors of all cells in the UEs active set is taken into account when selecting the appropriate AMR rate. The most loaded cell defines the load color. This applies to DL power load, UL cell load and Iub DS DL load. Whenever there is a change in the active set, the load colors are recalculated. Rate Control based on allocated RB between RB MBR and GBR

(indication of the max allowed rate)

Trigger for rate control UL & DL - AS Iub resource color change Trigger for rate control in DL: - Power consumption based

Rate 4 Rate 3 Rate 2 Rate 1

Allocated RB several rates above SID rate Rate-4 is the granted Max Bit Rate, with MBR Rate-4 < GBR

Non-controllable rates, in order to satisfy to GBR (case GBR = Rate-2)

- The feature 32687 does not apply to the following particular cases::

The RAB parameters (list of SDU size) correspond to an AMR WB codec set.

The RAB parameters (list of SDU size) correspond to an AMR mono-mode codec.

The requested DL GBR equates to the requested DL MBR, i.e. there is no RNC rate controllable rate.

The UE has a concurrent PS RAB which is mapped onto a R99 DCH in DL.

[USA Market]The UA06.0 feature 34216 AMR Improvements introduces a method to select AMR12.2 or AMR5.9 in monorate mode to increase the voice capacity relative to a AMR12.2 only scenario. The codec selection is done at RAB Assignment and dependent on DL power load UL cell load Iub DL DS load.

The feature only applies to calls using Iu UP V1. AMR5.9 which is only selected when there is no simultaneous PS RAB, is supported with SF128 and SF256. SF256 is




selected, if the number of spreading codes in the cell is running short. Otherwise SF128 is selected, because this configuration requires less Tx power. The UTRAN nodes being impacted by these features are the RNC, the Node B and the OMC:

UE

Node B MSC

Uu

Iub

UTRAN Core Network

IuCs

UMTS NETWORK

OMC

Itf-N Itf-xDRF

Itf-B Itf-R

UTRAN impacted interfaces by AMR CS speech Service

Shaded area: scope of this document UTRAN Node impacted by AMR CS speech Service

RNC

Iur

Figure: UMTS Network Architecture / scope of the document The following table indicates if a node is impacted by a given feature Feature Node B RNC OMC 30229 X X 18717 X* X X 33863 X X** 27803 X* X X 32687 X X X 34216 X X (*) Only test and capacity impacts (**) Only from UA05.1 The following table indicates which features are commercially supported by iBTS and OneBTS: Feature iBTS OneBTS AMR12.2 X X 30229 X 18717 X 33863 X 27803 X




32687 X 34216 X

4 BENEFITS

4.1 CUSTOMER/SERVICE PROVIDER BENEFITS [Global Market]Customer/service provider benefits related to the following features: 30229 Iu UP SMpSDU V2 18717 AMR-NB multi-mode support (with Iu UP V2) 33863 Initialisation of AMR DL Rate from OMC 27803 AMR-WB

benefit loss Cost ownership (day to day operation, fault management, upgrade, preventive/curative maintenance....)

Capacity Dimensioning (Connectivity, storage capacity..) Engineering (coverage, C/I..) X Traffic management (load sharing, compliance with recommendations ..) Robustness (restart/recovery enhancement..)

[Global Market]Customer/service provider benefits related to the following features: 32687 AMR mode change during the call - Evolution


Capacity X Dimensioning (Connectivity, storage capacity..) Engineering (coverage, C/I..) X Traffic management (load sharing, compliance with recommendations ..) Robustness (restart/recovery enhancement..)

[USA Market]Customer/service provider benefits related to feature 34216 (AMR Improvements):


Capacity X Dimensioning (Connectivity, storage capacity..) Engineering (coverage, C/I..) X




Traffic management (load sharing, compliance with recommendations ..) Robustness (restart/recovery enhancement..)

4.2 END-USER/SUBSCRIBER BENEFITS [Global Market]Customer/service provider benefits related to the following features: 30229 Iu UP SMpSDU V2 18717 AMR-NB multi-mode support 33863 Initialisation of AMR DL Rate from OMC 27803 AMR-WB

Benefit benefit loss Voice quality (HO, call handling enhancement ) X Quality Of Service (call drop, availability..) X New services X

[Global Market]Customer/service provider benefits related to the following features: 32687 AMR mode change during the call - Evolution

Benefit benefit loss Voice quality (HO, call handling enhancement ) Quality Of Service (call drop, availability..) X New services

[USA Market]End-User/Subscriber benefits related to feature 34216 (AMR Improvements):

Benefit benefit loss Voice quality (HO, call handling enhancement ) Quality Of Service (call drop, availability..) X New services




5 FUNCTIONAL DESCRIPTION

5.1 PRINCIPLE

5.1.1 AMR SUPPORT WITH IU UP V1 (FEATURES 30229 & 18717 NOT ACTIVATED)

The AMR 12.2 mode with VAD/DTX is supported (AMR 12.2 without VAD/DTX support has been removed from release UA05.0).

5.1.1.1 DESCRIPTION

5.1.1.1.1 RAB MATCHING (RNC) The RAB matching function allows the matching based on the requested RAB parameters with a provisioned user service configuration and to retrieve and/or compute the parameters necessary to setup or reconfigure the call.

5.1.1.1.1.1 RANAP PARAMETERS CONTROL The CS Speech service is identified by the triplet (CN domain = CS, Traffic Class = Conversational, Source Statistics Descriptor = Speech) The RAB parameters being taken into account as input of the RAB matching algorithm are: UP Mode Versions (i.e. versions proposed by CN: version 1 and/or version 2), Maximum Bit Rate (MBR), Guaranteed Bit Rate (GBR), Maximum SDU Size, SDU format information Parameter (SDU sizes per sub-flow and AMR rate). The requested RAB parameters are considered as consistent if the following rule is fulfilled: Max AMR rate (calculated from Max (Compound SDU size) = Max SDU size) = MBR GBR > SID rate (calculated from Min (Compound SDU size) > 0) In case of failure, the RNC rejects the RAB Assignment Request with RANAP cause Requested Maximum Bit Rate not Available.

5.1.1.1.1.2 RBSETCONF MATCHING The RNC identifies the RbSetConf, which satisfies to one of the requested compound SDU sizes corresponding to a rate greater or equal to the requested GBR for case of the Iu UP V1 protocol. Case 1: Version 1 of Iu UP is requested by the CN

The RNC selects the RbSetConf, which supports the AMR 12.2 rate provided that the 12.2 rate is part of the Core Network requested rate.




Case 2: Version 2 of Iu UP is requested by the CN

The RAB Assignment Request is rejected Case 3: the CN allows both Versions of Iu UP

The RNC behaves as only Version 1 of Iu UP (same behavior as for Case 1 applies)

5.1.1.1.1.3 ASCONF MATCHING AsConf matching proceeds as usual.

5.1.1.1.1.4 PARAMETERS COMPUTATION Following successful RbSet and AsConf matching, the actual UL and DL AMR TFS(s) are derived from the provisioned TFS(s) by removing TF(s) corresponding to non selected rates. The UL and DL TFCS(s) are derived from the provisioned TFCS(s) by:

o removing TFC(s) corresponding to non selected AMR rates o recalculating CTFC(s) as per 25.331 o checking consistency of gain factors (only applicable to UL): in case

computed gain factors have been provisioned and a reference TFC is missing (i.e. was removed at 1st step) the RAB matching is failed and the failure is handled as for a AsConf matching failure

5.1.1.1.2 CALL CONTROL (RNC) The role of the Call Control function is to setup, reconfigure or release the call.

5.1.1.1.2.1 RAB ASSIGNMENT Only version 1 of Iu UP is allowed within the scope of this feature:

RAB Assignment Request / UP Mode Versions = v1 v2 v2 or v1 v1 Failure RbSetConf matching as

in 5.1.1.1.1.2 RbSetConf matching as in 5.1.1.1.1.2

If the RAB matching fails due to RbSetConf matching failure, the RAB assignment procedure is failed with RANAP cause RNC unable to establish all RFC(s). If the RAB matching fails due to AsConf matching failure, the RAB assignment procedure is failed with RANAP cause RNC unable to establish all RFC(s).

5.1.1.1.2.2 [GLOBAL MARKET]RAB RECONFIGURATION Some CS AMR-NB speech RAB reconfiguration are supported. If AMR-WB is enabled, the reconfiguration between NB and WB is supported.




Recall of the possible transitions triggered by the Rab CS Modification

Target Configuration

12.2 mono-mode (IuUp V1)

AMR-NB

(IuUp V2)

AMR-LR

(IuUp V2)

AMR-WB

(IuUp V2)


Partial success (**)

Success

AMR-NB (IuUp V2)

Failure (*)


Success

AMR-LR (IuUp V2)

Success Success Failure (*) Success

Source Configuration

AMR-WB (IuUp V2)

Success Success Partial success

(**) Failure (*)

(*) only modification with change of UL/DL AsConf is supported (**) multi-service restrictions : AMR-LR is mono-service

5.1.1.1.2.3 RAB RELEASE Release proceeds as usual.

5.1.1.1.2.4 INCOMING UE INVOLVED RELOCATION The target RNC performs the RAB matching for all RABs requested to relocate. The target RNC performs the following as for the call setup (evaluation of the RAB attributes):

The version of the Iu UP* The RbSetConf matching, including the AMR rate selection* The AsConf matching, including the parameters computation

(*) The AMR rates and version of Iu UP may therefore be different before and after relocation (e.g. if the source RNC is non Alcatel-Lucent).




Relocation failure cases: If the RbSetConf matching fails for some of the RABs requested to relocate (the RNC does not attempt partial relocation) or if the AsConf matching failed, the Relocation Resource Allocation procedure is failed (and thus the relocation) with RANAP cause Unable to Establish during Relocation.

5.1.1.1.3 HANDLING WITHIN THE DRIFT RNC The RbSetConf / AsConf matching on drift role allow AMR configurations other than these supported in serving role, e.g. including other rates. This is to prevent Iur any inter-working issues when facing RNC from other manufacturer or Alcatel-Lucent RNC in a future release. However the two sub-flows based AMR configurations are not supported in drift role. Also multi-service combinations other than those supported in serving role may not be supported in drift role. In such cases RL setup or reconfiguration are failed with RNSAP cause Requested Configuration not Supported.

5.1.1.1.4 IU UP Iu UP V1 Time Alignment procedure is fully supported.

5.1.2 AMR MULTI-MODE SUPPORT WITH IU UP V2 (18717, 30229, 33863) [GLOBAL MARKET]

These features extend the UTRAN capability to support the following AMR configurations with the version 2 of Iu User Plane:

AMR (12.2, 7.95, 5.9, 4.75), AMR (10.2, 6.7, 5.9, 4.75) and AMR 12.2 speech service along with possible PS data services

AMR (5.9, 4.75) and AMR 4.75 standalone speech service: use of DL SF 256 based physical channel

The following principles apply: As per 3GPP specification, the call setup in version 2 of Iu UP requires the

initialization of all the requested rates. Mobility: Support of any mobility case as for AMR 12.2 DL rate control:

o The initial max allowed DL rate is set to the max rate supported by the selected configuration if feature #33863 is not activated otherwise the initial max allowed DL rate is the min between the max rate supported by the configuration and the max allowed rate by configuration .

o No rate control is initiated by the RNC during the call UL rate control:

o No rate control is initiated by the RNC during the call




o Any valid incoming rate control command (originated by the core network) is forwarded by means of an RRC TFC control command over the SRB#2.

Note that SRB#5 shall not be enabled in UA06.

5.1.2.1 DESCRIPTION

5.1.2.1.1 RAB MATCHING (RNC) 5.1.2.1.1.1 RANAP PARAMETERS CONTROL

Refer to the section 5.1.1.1.1.1

5.1.2.1.1.2 RBSETCONF MATCHING The RNC identifies the RbSetConf, which satisfies to the list of requested compound SDU sizes (N+1 compound SDU) for case of the Iu UP V2 protocol or to one of the requested compound SDU sizes corresponding to a rate greater or equal to the requested GBR for case of the Iu UP V1 protocol Where N+1 = number of AMR rates + SID rate + No_Data rate* * Optionally provided by the CN. Case 1: Version 1 of Iu UP is requested by the CN

Same behavior as described in section 5.1.1.1.1.2 / case 1 Case 2: Version 2 of Iu UP is requested by the CN

The RNC establishes the list of RbSetConf candidates based on the following criteria: The RbSetConf shall satisfy to the set of N+1 compound SDU sizes (all requested rates shall be supported)

Case 3: the CN allows both Versions of Iu UP

The RNC will first try with Version 2 of Iu UP (same behavior as for Case 2) Should the RAB matching with version 2 of Iu UP fail, the RNC will behave as in case 1

5.1.2.1.1.3 ASCONF MATCHING AsConf matching proceeds as usual.

5.1.2.1.1.4 PARAMETERS COMPUTATION Same behavior as this described in section 5.1.1.1.1.4.

5.1.2.1.2 CALL CONTROL (RNC) The role of the Call Control function is to setup, reconfigure or release the call.




5.1.2.1.2.1 RAB ASSIGNMENT The determination of the allowed version(s) of Iu UP is based on a set of provisioned parameters (Cf. section 7.1.2): If (allowedIuUpVersion == v1 Or isAmrMultiModeAllowed == disabled) {

AllowedIuUpVersionAtSetup = v1 } Otherwise {

If ((isAmrMultiModeAllowed == completelyEnabled) OR (isAmrMultiModeAllowed == enabledPerCell && FddCell/isAmrMultiModeSetupAllowed == completelyEnabled)) {

AllowedIuUpVersionAtSetup = v2 or v1 } Otherwise {

AllowedIuUpVersionAtSetup = v1 }

} AllowedIuUpVersion RAB Assignment Request / UP Mode Versions v2 v2 or v1 v1

v1 Failure RbSetConf matching as in 5.1.1.1.1.2

RbSetConf matching as in 5.1.1.1.1.2

v2 or v1 RbSetConf matching as in 5.1.2.1.1.2 / case 2

RbSetConf matching as in 5.1.2.1.1.2 / case 3

RbSetConf matching as in 5.1.1.1.1.2

If the RAB matching fails due to RbSetConf matching failure, the RAB assignment procedure is failed with RANAP cause RNC unable to establish all RFC(s). If the RAB matching fails due to AsConf matching failure, the RAB assignment procedure is failed with RANAP cause RNC unable to establish all RFC(s).

5.1.2.1.2.2 RAB RECONFIGURATION Some CS AMR-NB speech RAB reconfigurations are supported. If AMR-WB is enabled, the reconfiguration between NB and WB is supported.

Recall of the possible transitions triggered by the Rab CS Modification

Target Configuration

12.2 mono-mode

(IuUp V1) AMR-NB

(IuUp AMR-LR

(IuUp V2) AMR-WB

(IuUp




V2)

V2)



Success

AMR-NB (IuUp V2)

Failure (*)


Success

AMR-LR (IuUp V2) Success Success Failure (*) Success

Source Configuration

AMR-WB (IuUp V2) Success Success Partial success (**)

Failure (*)

(*) only modification with change of UL/DL AsConf is supported (**) multi-service restrictions: AMR-LR is mono-service

5.1.2.1.2.3 RAB RELEASE The RAB release proceeds as usual.

5.1.2.1.2.4 INCOMING UE INVOLVED RELOCATION

5.1.2.1.2.4.1 3G to 3G handover The target RNC performs the RAB matching as described in section 5.1.1.1.2.4. It is assumed that SRB#5 support is not required in SRNS Relocations. The received TFC subset IE is included in the UL Transport channel information common for all transport channels IE at the RB reconfiguration, so that the rate control information is preserved within the UE. A rate control is, in addition, initiated by the target RNC.

5.1.2.1.2.4.2 2G to 3G handover The RNC performs RAB matching identical to the incoming 3G to 3G case (except that it is mono RAB).




5.1.2.1.2.5 MULTI-SERVICE SUPPORT

Multi-service is supported along with the high rate AMR configuration. Multi-service is not supported along with low rate AMR configuration : o If there is any ongoing PS data, any CS speech call for AMR 4.75 or AMR

(5.9, 4.75) is rejected (AsConf failure). o If there is any ongoing CS speech call with low rate AMR configuration, any

PS data call request is rejected (AsConf failure).

5.1.2.1.3 RATE CONTROL HANDLING (RNC) 5.1.2.1.3.1 HANDLING OF OUTGOING IU RATE CONTROLS

The RNC does not send any Rate Control toward the CN as part of feature 18717, except in relocation scenarios when the target RNC receives the relocation trigger (mandatory per 25.415). The indicated maximum rate for the downlink is again the highest initialised rate. According to the maximum rate for the uplink included in the Rate Control acknowledgement, the RNC triggers an RRC TFC Control procedure. If the feature #33863 is enabled the following applies at call setup or after relocation scenarios, 2G to 3G handover scenario: The initial maximum DL rate is evaluated as following:

maxFromOam = lowest value of maxDlAmrRateFromOam across all cells of active set

Note: If no value was provisioned for a cell, or if a cell is controlled by another RNC, this cell does not contribute, i.e. 12.2 is assumed allowed.

If there is at least one selected rate above or equal to GBR and below or equal to maxFromOam then the highest rate is selected Otherwise the lowest selected rate above GBR is selected

The initial maximum DL rate is transmitted to the CN embedded in the Iu UP initialisation frame. If the feature #33863 is enabled the following applies for Soft-handover scenarios: Whenever the active set is updated the applicable maximum DL rate is re-evaluated the same way as it is evaluated for call setup i.e. if and only if the applicable maximum DL rate is modified or changed, a rate control toward the Core Network is issued. Example: Set of initialised rates: {10.2, 6.7, 5.9, 4.75}, GBR=4.75 Cell A: maxDlAmrRateFromOam=12.2, cell B: maxDlAmrRateFromOam=7.95 Active set update {A} {A, B}: a rate control is sent with maximum rate allowed 6.7 Active set update {A, B} {A}: a rate control is triggered with maximum rate allowed 10.2




5.1.2.1.3.2 HANDLING OF INCOMING IU RATE CONTROLS Any incoming rate controls (Iu UP FP RC) are accepted if the OAM parameter isCnInitiatedRateControlAllowed is set to True, the Iu UP is in version 2 and the frame is correctly formatted, otherwise they are ignored. For case the RNC accepts the rate control request, the RNC acknowledges it with indication of the current maximum rate in the downlink (within the scope of this feature this is always the highest initialised rate). Then the RNC triggers an RRC TFC Control procedure indicating the new maximum rate in the uplink. The RNC ignores any attempt to disallow the lowest AMR rate or SID or NO_DATA. The RNC does not check on the User Plane that the UE actually complies with the TFC control. In case the UE continues to use a rate that is no longer allowed, the RNC continues to handle normally the frames. This may occur e.g. because the TFC Control was lost over the radio. The assumption is that the originator of the rate control will repeat if needed.

5.1.2.1.3.3 HANDLING OF RRC TFC CONTROL The RRC rate control mechanism is based on the Information Element:

- TFC subset This IE is present in UL Transport channel information common for all transport channels optional IE of various RRC messages such as RB SETUP, RB RECONFIGURATION, RB RELEASE and also SRNS RELOCATION INFORMATION (included in Source RNC To Target RNC Transparent Container IE used at relocation). TFC subset is mandatory for TFC CONTROL over SRB#2 (called DPCH/PUSCH TFCS in uplink). TFC subset represents a subset of the UL TFCS. It allows to restrict the use of the UL TFCS by the UE and therefore to control the uplink rate.

The TFC Control procedure is performed regardless the current state of rate control, i.e. the currently allowed rates. The TFC Control procedure is performed over SRB#2. The SRB#2 provides a reliable transfer service (RLC-AM). The RNC selects the format of the TFC subset IE to be used in TFC CONTROL message as following: - Non-allowed transport format combination list for single AMR call - Restricted TrCH information for multi RAB call In case the TFC Control procedure cannot be performed because of RRC connection unavailability, the rate control is not memorized but dropped. In case the RNC receives TFC CONTROL FAILURE (case the TFC CONTROL was sent over SRB#2 and the UE found that the TFC subset were inconsistent with the configured TFCS), no action is taken (the message is traceable. Cf. 7.3.3.2.1.1).

5.1.2.1.4 HANDLING WITHIN THE DRIFT RNC The behaviour and associated restrictions described in 5.1.1.1.3 applies. It is assumed that support of SRB#5 is not required for softhandover over Iur.




5.1.2.1.5 HANDLING WITHIN THE NODEB The CEM-alpha capability is aligned with iCEM capabilities for the TFCS size (CEM-alpha Software modification in order to support Maximum number of TFC per Physical Channel in DL extension from 64 to 128) one in order to support the new multi-service configurations with multi-mode AMR.

5.1.2.1.6 IU UP 5.1.2.1.6.1 INITIALISATION OF IU UP BY RNC

The RNC initializes the Iu UP upon the following events: RAB assignment (setup) Incoming relocation RAB assignment (modification) provided that feature 27803 is supported

The version of Iu UP is determined as described in 5.1.2.1.2. The rates to initialize result from the RAB matching phase (cf. 5.1.2.1.1.) The RNC allocates the RFCI(s) in the order of compound SDU sizes, starting with value 0 for the smallest compound SDU size. The RFCI corresponding to highest rate first (initial rate control) is signaled first in list.

5.1.2.1.6.2 INITIALISATION OF IU UP BY CN The CN may re-initialize the Iu UP connection in order to solve any RFCI mismatch in a TrFO scenario. If the RNC initiated the Iu UP connection in version 1, any incoming initialisation request is ignored. If the RNC initiated the Iu UP connection in version 2, any incoming initialization request is taken into account, provided that the same set of rates are requested, otherwise a negative acknowledgement is sent. The first RFCI in the list of RFCIs received in the initialization request determines the highest permitted UL rate (embedded rate control). The RNC forwards this rate control by means of an RRC TFC Control procedure.

5.1.2.1.6.3 HANDLING OF TIME ALIGNMENT Handling of incoming TA: A negative acknowledgement (TS 25.415) is sent upon reception of any Time Alignment frame. RNC initiated Time Alignment procedure is supported.

5.1.3 WIDEBAND AMR (27803) [GLOBAL MARKET] This feature extends the UTRAN capability to support the following AMR-WB configurations with the version 2 of Iu User Plane:




AMR (12.65, 8,85, 6,6) speech service along with possible PS data services Same principles apply as for AMR-NB multi-mode (see section 5.1.2)

5.1.3.1.1 CALL SETUP RAB matching corresponds to Step1 up to Step2. Step1 The RNC checks the RANAP parameters consistency Max AMR rate (calculated from Max (Compound SDU size) = Max SDU size) MBR GBR > SID rate (calculated from Min (Compound SDU size) > 0) If there is any inconsistency then the RNC rejects the call. Note: the presence of SDU sizes for NO-DATA rate is not checked (SDU sizes for NO-DATA rate optionally provided by the MSC) No modification compared to AMR-NB multi-mode, AMR-WB RAB may be requested either with 3 Iu sub-flows, the 3rd sub-flow being possibly locked to 0 kbps rate (no AMR-WB class C bits) or with 2 Iu sub-flows. In both cases only 3 sub-flow is configured over radio/Iub/Iur. Step2 The RNC identifies the RbSetConf, which satisfies to the list of requested compound SDU sizes (N+1 compound SDU). Where N+1 = number of AMR rates + SID rate + No_Data rate* * Optionally provided by the CN. The AMR-WB is identified by its rate. It must be > 12.2 kbps and




Step3 AsConf matching proceeds as usual. Step4 CAC proceeds as usual Step5 Initialization: RFCI allocation (number of RFCI = number of Compound SDU sizes). Allocation scheme should be from lowest rate to the highest rate (0*, SID, etc) in order to avoid as much as possible RFCI mismatch for TFO/TrFO operation. RFCI for 0 rate only initiated if SDU sizes for No-DATA rate were provided. The mapping table (TFCI / RFCI) is initialised Iu UP Initialization provides all RFCIs (i.e. all CN requested rates) The max rate of allocated RB is the first RFCI in the list (embedded Rate Control) RB Setup The RNC configures the UE & NodeB on the allocated RB basis

Interaction with multi-service If there is any PS I/B or PS STR RAB being established, the RAB matching algorithm (iRM table) for the PS part is played as well. This is already the case in the current implementation.

5.1.3.1.2 CALL MODIFICATION

Assumptions taken in order to ease / speed up transitions between AMR-WB & AMR-NB:

The modification may lead to a change in the number of Iu sub-flows between 2 and 3. The number of sub-flows configured of the radio/Iub/Iur is not changed and equals 3.

The same set of RAB combinations is supported with Full rate AMR-NB (cf. feature 18717) and AMR-WB

The following transitions between AMR-NB & AMR-WB are not supported: AMR-NB with 3 sub-flows and AMR-WB with 2 sub-flows over radio/Iub/Iur. RAB matching corresponds to Step1 up to Step2. Step1 The RNC checks the RANAP parameters consistency as Call setup




If there is any inconsistency then the RNC rejects the call. Step2 Idem step 2 of Call setup. Step3 AsConf matching proceeds as in section Call setup / step 3 but with the following difference: Step4 CAC proceeds as usual Step5 Idem step 5 of Call establishment but with the following differences: Previously allocated RFCIs are replaced with the new RFCIs by the IuUP/Init procedure. The Iub transport bearer is replaced. For Iur transport there is no modification nor TB replacement. Iu CS transport bearer is either kept or replaced as requested by the CN (the presence of the TLI IE in the RAB Assignment Request triggers the transport bearer replacement on Iu). Interaction with multi-service If there is any PS I/B or PS STR RAB being established, the RAB matching algorithm (iRM table) for the PS part is played as well. Similar policy applied as for the setup case.

5.1.3.1.3 SRB#5 MANAGEMENT

SRB#5 is no longer supported in UA06.

5.1.3.1.4 RFCI MANAGEMENT RFCI allocation

The system shall support RFCI allocation scheme for AMR (12.65, 8.85, 6.6) + SID

Solution choice: The RFCI(s) values are allocated in order of increasing SDU sizes.

RFCI #




(example) 4 AMR-WB 12.65 3 AMR-WB 8.85 2 AMR-WB 6.6 1 AMR-WB SID 0* NO-DATA

(**) If SDUs for NO-DATA rate provided in RANAP RAB Assignment Request message

Mapping between RFI & TFI and RFCI and TFCI RFCS

RFCI RF 1 RF 2

RF 3 (if configured

) Total (bit)

Source rate (kbps)

4** 72 181 0 253 12.65 3** 64 113 0 177 8.85

2** 54 78 0 132 6.6 1* 40 0 0 40 SID

RFCS

0*** 0 0 0 0 NO-DATA RF RAB sub-flow RFCI RAB sub-flow Combination Indicator RFCS RAB sub-flow Combination Set (*) Always part of RFCS assuming that VAD/DTX is now supported by any UE / RAN (**) Assuming that the RFCI are allocated by increasing rates The allocation scheme should be based according to the most probable rule in order to avoid any RFCI mismatch solving (CN originated Iu UP Init (RFCI list) procedure) (***) Optionally part of RFCS TFCS UL/DL

TFCS (RF#1, RF#2, RF#3, DCCH)= (TF0,TF0,TF0, TFj) NO-DATA, TFC # (0 + 5j) (TF1,TF0,TF0, TFj) SID+0+0, TFC # (1 + 5*j) (TF2,TF1,TF0, TFj) 42+53+0, 6.6 rate TFC # (2 + 5*j) (TF3,TF2,TF0, TFj) 55+63+0, 8.85 rate TFC # (3 + 5*j) (TF4,TF3,TF0, TFj) 75+84+0, 12.65 rate TFC # (4+ 5*j) With j = 0, 1

RFCI TFCI mapping

RFCI TFCI TFI list Source rate (kbps) 4 4 or 9 TF4,TF3,TF0, TF0/TF1 12.65 3 3 or 8 TF3,TF2,TF0, TF0/TF1 8.85 2 2 or 7 TF2,TF1,TF0, TF0/TF1 6.6 1 1 or 6 TF1,TF0,TF0, TF0/TF1 SID 0 0 or 5 TF0,TF0,TF0, TF0/TF1 NO-DATA

RFCI modification




Case of RFCI mismatch (TrFO/TFO scenario support) Case of RAB modification

RFCI release

Case of RFCI mismatch (TrFO/TFO scenario support) Case of RAB modification Case of RAB release

5.1.3.1.5 RATE CONTROL DURING THE CALL

Idem as AMR-NB multi-mode provided that the feature 33863 is not activated. Feature 33863 cannot be applied on an AMR-WB call (i.e. no outgoing Iu Rate Control)




5.1.4 AMR MODE CHANGE DURING CALL (32687) [GLOBAL MARKET]

The feature activation flag is the parameter isAmrRateControlDuringTheCallAllowed Several concurrent criteria are taken into account by the RNC to trigger any AMR rate control: o The possible criteria to control the AMR rate are the DL Tx CP, the DL power

load*, the UL cell load* and the Iub DS load** o DL Tx CP NBAP measurement report events A & B are used o The AMR rate control only applies with version 2 of Iu UP protocol (*) Use of these criteria are respectively controllable via the parameters isAmrRateControlOnDlPowerLoadAllowed, isAmrRateControlOnULCellLoadAllowed (**) Use of this criterion is controllable via the parameter isAmrRateControlOnIubDsLoadAllowed

5.1.4.1 DESCRIPTION AMR rate modification during the call may be initiated by the RNC provided that the feature 32687 is activated. During the call, there is no AMR RB reconfiguration based on e.g. the cell load (power, code) or Iu DS load. During the call, the RNC only controls the AMR rate. During the call, the RNC will control

the DL AMR rate based on the observed amount of DL power consumption provided that the following condition is fulfilled:

DL Requested MBR rate > DL Requested GBR

the UL/DL AMR rate based on the observed Iub DS load provided that, in addition of the above condition, the following one is fulfilled:

UL Requested MBR rate > UL Requested GBR Control of the AMR DL Rate based on DL power consumption criteria In case of a mono-service call, the RNC continuously control the DL AMR rate provided that there is any configured AMR rate above GBR. In case of a multi-service call where the PS data part is carried over DL dedicated channel(s), no DL AMR Rate Control is performed for power reason. In case of a multi-service call where the PS data part is carried over HS-DSCH channel(s), the RNC behaves as for a mono-service speech call case.




5.1.4.1.1 DL AMR RATE CONTROL BASED ON DL TX CP At establishment of a speech bearer eligible* to rate control, the RNC configures NBAP dedicated measurement Reporting on the primary cell in order to track the DL Transmitted Code Power. Thus, the RNC can detect when the DL transmitted power rises above a given threshold, which indicates that radio conditions become worst enough to require a rate decrease. (*) AMR rate control is allowed if there are any rate controllable AMR modes, i.e. AMR rates above the Requested Guaranteed Bit Rate. In case of multiple RAB combinations, eligibility to AMR rate adaptation requires that some additional conditions are met. Refer to section Multi-service Handling. 1. Dedicated measurements configuration In order to detect a rate decrease / increase condition, the RNC configures dedicated measurement reporting with the following characteristics: - measurement quantity = transmitted code power (Radio Link) - reporting mode = event triggered - event = A / B - threshold1 = RateDecTh - threshold2 = RateIncTh - time to trigger = RateDecTTT / RateIncTTT. This time to trigger indicates the time

during which the threshold condition should be fulfilled before the UE sends the event to the RNC.

2. Dedicated measurements initiation The dedicated measurement is initiated on the primary cell at call establishment time or whenever there is a change of the primary cell (the dedicated measurement on the old primary cell is terminated), provided that the following conditions are met: There is any DL AMR rate(s), which is/are controllable by the RNC (rate(s) above

GBR) Speech only user traffic or Speech + PS data over high speed shared channel The dedicated measurements are managed over both Iub and Iur. 3. NBAP dedicated measurements processing On reception of an event A / B, and provided that rate decrease / increase is allowed / possible, the RNC issues an Iu UP Rate Control to the Core Network indicating that the max current DL rate* is now prohibited / allowed. (*) In case of TFO/TrFO the DL rate may change. Despite the fact that the measurement report trigger may relate to an AMR rate below the current max rate, only the current max allowed rate is prohibited. Illustration of the process of DL AMR rate control based on DL TxCP




Time

Measured entity (DL TxCP)

maxDlTxPower

RateDecTh

RateIncTh

minDlTxPower

NBAP Event A

NBAP Event B

RateDecTTT

RateIncTTT

ReportPeriodicity

t1 t2

The thresholds are determined as following: maxDlTxPower = maxDlTxPowerPerOls[CurrentOls].maxDlTxPower RateDecThreshold = pcpichPower + maxDlTxPower dlAmrRateDecreaseTxcpTrigger.thresholdDelta RateIncThreshold = pcpichPower + maxDlTxPower dlAmrRateIncreaseTxcpTrigger.thresholdDelta Where dlAmrRateDecreaseTxcpTrigger.thresholdDelta




5.1.4.1.2 CONTROL OF THE AMR UL/DL RATE BASED ON IUB DS LOAD CRITERIA

The Iub DS load criteria is taken into account if the parameter isAmrRateControlDuringTheCallAllowed and isAmrRatecontrolOnIubDsLoadAllowed are set to True. A specific iRM table is introduced to determine the max allowed AMR rate based on the OLS and the Iub DS DL load color of the Active Set. This table is played

After any mobility event, to help determine the new max UL/DL rate* During stable state, determine possible UL/DL rate change by checking the

Active Set Iub DS DL load color every configurable period In order to avoid any ping pong effects due to the application of different

criteria, the downlink rate upgrade is not triggered based on Iub DS load colour change. Any ping-pong effect would due to e.g. downgrade by TxCP measurement report, then upgrade by table DlIrmTableIubDsLoadConfClass, then downgrade by TxCP measurement report, etc. Only the trigger of TxCP measurement report is used to upgrade the rate of an AMR call.

Procedures: DL Rate control: Iu UP Rate Control frame sent to core network UL rate control: RRC TFC control message sent to UE Whenever applicable, the rate is decreased step by step, this means that several Iu UP rate control / TFC control messages may be successively sent. The Iu UP rate control / TFC control messages will be issued with a configurable frequency (i.e. 1 / delayBetweenAmrRateControls). Multi-service: The RNC initiated AMR rate control for Iub DS load reason does not apply when

the UE has a simultaneous PS RAB. Iub DS iRM table: o It defines the maximum AMR rate based on the OLS and the Iub DS load o To a given value of the pair (Iub DS color, OLS) corresponds the Operators

provisioned max allowed rate. o There is only one instance of the table per RNC o The table applies for both UL & DL. o The Iub DS load is only calculated for the DL assuming that in most of the cases

the traffic over Iub DS is rather symmetric (CS domain calls are mostly symmetric services: speech or Video Telephony calls, Symmetric CS streaming) or asymmetric services with higher rate in the DL

Iub transport Color OLS Max AMR rate

Gold e.g. 12.2 GREEN Silver e.g. 12.2

Bronze e.g. 7.95 Gold e.g. 12.2

YELLOW Silver e.g. 7.95 Bronze e.g. 5.9 Gold e.g. 5.9

RED Silver e.g. 4.75 Bronze e.g. 4.75




Remark: The Max AMR rate as output of the iRM table does not influence the process of selection of the RB configuration (RbSetConf). The table is played during the call for rate control purpose:

For stationary UE / Stable AS: the color of the AS Iub* may change because one Iub instance part of the AS becomes loaded / unloaded

Mobility cases o Intra RNC inter-frequency HO: the Iub instance color related to the

target cell is different from AS Iub of the source AS cell o Soft handover: the color of AS Iub* changes due to the addition /

deletion of an Iub instance, which supports the added / deleted radio link

(*) AS Iub: Iub related to the NodeBs supporting the Active Set Cell

5.1.4.1.3 CONTROL OF THE AMR UL RATE BASED ON UL CELL LOAD CRITERIA

The UA05.0 UL Cell Load feature introduces the support of the NBAP common measurement on Received Total Wideband Power (RTWP) and determination of the UL cell load colors based on it. A specific UL iRM table is introduced to determine the max allowed AMR rate based on the OLS and the UL cell load color of the cells of the active set. This table is played

At admission to help determine the max initial UL rate based on the UL cell load color of the cells of the Active Set

After every primary cell update, to help determine the new max UL rate based on the UL cell load color of the cells of the Active Set

During stable state, determine possible UL rate change by checking the UL cell load color of the Active Set every configurable period (Cf. parameter delayBetweenAmrRateControls)

Procedures: UL rate control: RRC TFC control message sent to UE Multi-service: The RNC initiated AMR rate control based on radio criteria (UL Cell Load) does

not apply UL cell load iRM table: o It defines the maximum AMR rate based on the OLS and the UL cell load o To a given value of the pair (UE AS UL cell color, OLS) corresponds the

Operators provisioned max allowed rate o There is only one instance of the table per RNC

UL cell load Color OLS Max AMR rate








5.1.4.1.4 CONTROL OF THE AMR DL RATE BASED ON DL POWER LOAD

CRITERIA A specific DL iRM table is introduced to determine the max allowed AMR rate based on the OLS and the DL power load color of the cells of the active set. This table is played per individual call:

After every primary cell update, to help determine the new max DL rate based on the DL power load color of the cells of the active set

During stable state, determine possible DL rate change by checking the DL power load color of the Active Set every configurable period (Cf. parameter delayBetweenAmrRateControls)

In order to avoid any ping pong effects due to the application of different criteria, the downlink rate upgrade is not triggered based on DL power load colour change. Any ping-pong effect would due to e.g. downgrade by TxCP measurement report, then upgrade by table DlIrmTablePowerLoadConfClass, then downgrade by TxCP measurement report, etc. Only the trigger of TxCP measurement report is used to upgrade the rate of an AMR call.

Procedures: DL Rate control: Iu UP Rate Control frame sent to core network Multi-service: The RNC initiated AMR rate control based on radio criteria (Total DL Tx Power

load) does not apply if PS RAB(s) mapped on DCH (whereas it applies if PS RAB(s) mapped on HSDPA)

DL cell power load iRM table: o It defines the maximum AMR rate based on the OLS and the DL cell power load o To a given value of the pair (UE AS Total DL Tx Power color, OLS) corresponds

the Operators provisioned max allowed rate. o There is only one instance of the table per RNC

Total DL Tx Power

load Color OLS Max AMR rate





5.1.4.1.5 RATE CONTROL HANDLING (RNC) Rate control Applicability: DL is rate controllable by the RNC if DL MBR > DL GBR UL is rate controllable by the RNC if UL MBR > UL GBR Rate initialization cases: RAB establishment Mobility cases involving relocation procedure (idem RAB establishment case)




Rate control cases during call: Rate control shall be performed in a way to ensure the following behavior: Rate increase shall only be performed step per step, e.g. for case AMR (12.2,

7.95, 5.9, 4.75) is initialized and current rate is 4.75 then the target rate will be 5.9. Rate decrease shall only be performed step per step, e.g. for case AMR (12.2,

7.95, 5.9, 4.75) is initialized and current rate is 12.2 then the target rate will be 7.95.

Rate control failure handling: Case the rate is outside the set of permitted rates:

As per 3GPP TS 25.415 [R6] section 6.5.3.2, if the RNC / Iu UP detects that the RATE CONTROL frame has not been correctly interpreted or received, the Iu UP shall retrigger an Iu Rate Control procedure. If after NRC repetitions the rate still not conforms than the RNC should drop the call .

For other failure cases, refer to TS 25.415 [R6]

5.1.4.1.5.1 RATE CONTROL OVER IU Only version 2 of Iu UP is applicable Iu UP version 2

CN RNC UE NodeB

Iu UP/ Rate Control (RFCIs, ) Iu UP/ Rate Control Ack (RFCIs, )

The RNC informs the CN that the DL rate should be reduced (resp. that it accepts increase of the DL rate)

If the RNC detects that the RATE CONTROL has not been correctly interpreted or received (e.g. the observed rate is outside the set of permitted rates in the reverse direction

of the RATE CONTROL control frame, or a RATE CONTROL NEGATIVE ACKNOWLEDGEMENT control frame

has been received, or no RATE CONTROL POSITIVE ACKNOWLEDGEMENT control frame

was received before the supervision timer TRC expires), the Iu UP shall retrigger a Iu Rate Control procedure. If after N RC repetitions, the error situation persists, the Iu UP protocol layers (sending and receiving) take the appropriate local actions.

TRC

Iu UP/ Data frame

May be repeated if the procedure fails. Up to NRC repetitions allowed

Notes:




In this version of the document, the OAM parameter tInit is used to set both 25.415 TRC and TINIT and, the OAM parameter nInit is used to set both 25.415 NRC and NINIT.

The IuUP Rate Control Ack message contains rate control information relevant for UL operation. If the maximum AMR rate provided by this message is lower than the currently used AMR rate, then the RNC needs to rate control the UL by sending a Transport Format Combination Control message to the UE.

5.1.4.1.6 HANDLING WITHIN THE NODEB The Node B performs the DL Tx Code Power measurements with events A & B (cf. 3GPP spec 25.433). There is some capacity limitation (number of simultaneous DL Tx CP measurements supported). Refer to section 5.6.3 for details.

5.1.5 AMR SUPPORT WITH IU UP V1 (FEATURE 34216 ACTIVATED) [USA MARKET]

With feature 34216 enabled, the RNC supports the following AMR configuration: AMR12.2 AMR5.9 with SF128 AMR5.9 with SF256

5.1.5.1 AMR CODEC SELECTION AT CALL SETUP Feature 34216 is applicable when the MSC offers at least the AMR5.9 and AMR12.2 in the RAB Parameters IE of the RAB Assignment Request or intra-system Relocation Request of type UE involved in relocation of SRNS requesting Iu UP V1. In this scenario the RNC checks the current DL power load color UL cell load color Iub DS DL load color

to determine the suitable AMR codec rate. The initially selected AMR codec rate is not changed during the call when the load conditions change. However the AMR codec is reconfigured to AMR12.2, when a PS RAB is established in addition to the voice bearer.

5.1.5.1.1 DL POWER LOAD CRITERIA The RNC supports an iRM table to determine the maximum allowed AMR rate based on the OLS and the DL power load color. The table is played at call admission. The power load from all cells in the active set which are managed by the SRNC is taken into account. The DL power load color is derived from DL Tx power measurements provided by the NodeBs.




5.1.5.1.2 UL CELL LOAD CRITERIA The RNC supports an iRM table to determine the maximum allowed AMR rate based on the OLS and the UL cell load color. The table is played at call admission. The UL cell load from all cells in the active set which are managed by the SRNC is taken into account. The UL cell load color is derived from RTWP measurements from the NodeB.

5.1.5.1.3 IUB DS DL LOAD CRITERIA The RNC supports an iRM table to determine the maximum allowed AMR rate based on the OLS and the Iub DS DL load color. The table is played at call admission. The Iub DS DL load from all cells in the active set which are managed by the SRNC is taken into account.

5.1.5.1.4 SPREADING FACTOR SELECTION FOR AMR5.9 The RNC supports an iRM table to determine the spreading factor for AMR5.9 rate based on the OLS and OVSF code tree load color. The table is played at selection of AMR5.9. The DL OVSF code load from all cells in the active set which are managed by the SRNC is taken into account.

5.1.5.2 AMR CODEC RECONFIGURATION FROM AMR5.9 TO AMR12.2 AMR5.9 is not supported in combination with any PS RAB. To avoid that a PS RAB needs to be rejected when the UE has an active voice call using AMR5.9, the RNC reconfigures the voice call to AMR12.2 when establishing the PS radio bearers. To prepare the Iu UP for the reconfiguration the RNC establishes a RFCI also for AMR12.2 at call setup. Thus the RNC only needs to send an Iu UP rate control frame to the MGW in order to request a modification of the DL AMR codec rate. No RANAP interworking is required for this modification. On the interface towards the NodeB(s) and the UE a synchronized radio link reconfiguration procedure is used. No AMR codec reconfiguration is triggered when CAC fails for the PS RAB.

5.2 INTER SUB-SYSTEM FUNCTIONAL DISTRIBUTION

5.2.1 RNC Iu UP handling, RAB matching, call control and rate control functions as described in section 5.1

5.2.2 NODE B [Global Market] bearer and measurement support as described in section 5.1

5.2.3 OMC Support for new parameters, counters and traces. Refer to section 7




5.3 USE CASES

5.3.1 AMR SUPPORT WITH IU UP V1 Case the operator allows only version 1 of Iu UP (allowedIuUpVersion set to V1) Sub-cases

CN proposes only V1*: nominal case CN proposes only V2*: failure case CN proposes V1 and V2*: nominal case

Note (*) UP Mode Versions IE of the RANAP RAB Assignment Request or the Relocation Request message

5.3.2 AMR-NB MULTI-MODE SUPPORT WITH IU UP V2 (18717, 30229) [GLOBAL MARKET]

Case the operator allows version 1 and 2 of Iu UP (allowedIuUpVersion set to V1&V2) Sub-cases

CN proposes only V1* CN proposes only V2* CN proposes V1 and V2*

Note (*) UP Mode Versions IE of the RANAP RAB Assignment Request or the Relocation Request message

Cases: SINGLE AMR CALL SETUP

Sub-cases: - All supported AMR RAB(s) -

PS TO PS+AMR AMR TO AMR+PS SINGLE AMR CALL RELEASE AMR+PS TO AMR AMR+PS TO PS




AMR+PS, PS RECONFIGURATION AMR CALL SETUP WITH UP INIT BY CN

In this scenario the CN re-initializes Iu UP after call setup in order to resolve RFCI mismatch during TrFO establishment. Obviously this cannot occur with two identical RNC(s).

UPLINK RATE CHANGE The UE changes the UL rate e.g. because it reached its maximum transmit power. To do so it needs to switch the rate of the speech encoder and then select the appropriate TFC on the radio interface.

DOWNLINK RATE CHANGE The distant UE changed its UL rate in a TFO/TrFO configuration.

RATE CONTROL RECEIVED FROM CN This case is applicable in a TFO/TrFO configuration: 1. In a UMTS to GSM call the MS requested rate change 2. Or in a UMTS to UMTS call the distant RNC requested rate change Refer to section 5.1.2.1.3.2 for additional information.

RATE CONTROL SENT TOWARD THE CN Refer to section 5.1.2.1.3 for the description of the case.

UE INVOLVED RELOCATION SUCCESSFUL UE INVOLVED RELOCATION, ALCATEL-LUCENT END TO

END Case the source and target RNS are Alcatel-Lucent with same release & same configuration. Variants: - All supported AMR RABs SUCCESSFUL UE INVOLVED RELOCATION, IOT Case the source RNC is from a 3rd party vendor. FAILED UE INVOLVED RELOCATION Examples: - The AMR RAB to relocate is not supported - The AMR RAB to relocate is supported but the multi RAB combination is not supported

UE NOT INVOLVED RELOCATION 1. SUCCESSFUL UE NOT INVOLVED RELOCATION, ALCATEL-LUCENT TO

ALCATEL-LUCENT Case the source and target RNS are Alcatel-Lucent with same release & same configuration.




Variants: - all supported AMR RABs

2. SUCCESSFUL UE NOT INVOLVED RELOCATION, IOT

In this scenario the source RNC is from other vendor or simulated. 3. FAILED UE NOT INVOLVED RELOCATION

Examples: - The AMR RAB to relocate is not supported - The AMR RAB to relocate is supported but the multi RAB combination is not supported

SOFT HANDOVER OVER IUR, ALCATEL-LUCENT TO ALCATEL-LUCENT Case the serving and drift RNS are Alcatel-Lucent with same release & same configuration. Variants: - All supported AMR RABs

SOFT HANDOVER OVER IUR, OTHER VENDOR TO ALCATEL-LUCENT In this case the serving RNC is a 3rd party vendor and uses an AMR configuration being not supported by Alcatel-Lucent RNC in serving role, e.g.

- Unsupported rates

RAB MODIFICATION Example: the CN request a modification of an established AMR RAB from AMR (12.2, 7.95, 5.9, 4.75) to AMR (12.2) This case is not supported.

MODIFICATION OF AMR DCH(S) IN DRIFT ROLE Example: the CN attempts to modification of an established AMR RAB from AMR (12.2, 7.95, 5.9, 4.75) to AMR (12.2) with a serving RNC supporting this procedure. This case is not supported.

5.3.3 WIDEBAND AMR (27803) [GLOBAL MARKET] Use cases described for AMR-NB multi-mode are applicable taking into account the specific codec modes of AMR-WB. Use case introduced by AMR-WB is the RAB modification procedure used to support any transition between AMR-WB multi-rate codec & AMR-NB multi-rate codec. The mobility use cases assume that the core network is responsible for Codec change in case that the target RNC/RAT does not support AMR-WB, there is no specific management required at originating RNC side.




5.3.4 AMR MODE CHANGE DURING CALL (32687) [GLOBAL MARKET]

Cases: AMR CALL SETUP / No ongoing PS session

Variants: - Version 1 of Iu UP is proposed or not - Multiple rates are proposed or not

AMR CALL SETUP / Ongoing PS session

Sub-cases: - Speech service is established and PS session is removed - Speech service is established and PS session(s) is maintained

- Variants: With or without HSDPA

SINGLE AMR CALL RELEASE AMR+PS TO AMR AMR+PS TO PS AMR+PS, PS RECONFIGURATION RATE CONTROL SENT TOWARD THE CN

Criteria: - Cell power load - DL Transmitted Code Power - Iub DS load

TFC CONTROL SENT TOWARD THE UE Criteria: - UL Cell load - Iub DS load

UE INVOLVED RELOCATION The initial max rate is determined as for AMR call setup.

UE NOT INVOLVED RELOCATION 1. SUCCESSFUL UE NOT INVOLVED RELOCATION, Alcatel-Lucent TO

Alcatel-Lucent




Case the source and target RNS are Alcatel-Lucent with same release & same configuration.

- No rate control assuming that radio resources are let unchanged and Iur transport load are not taken into account

2. SUCCESSFUL UE NOT INVOLVED RELOCATION, IOT In this scenario the source RNC is from other vendor or simulated.

- Any possible rate control issued assuming that Iub DS load criteria may apply

SOFT HANDOVER within RNS

NBAP Dedicated measurement initiation request (Event A & B) upon change of primary cell

SOFT HANDOVER OVER IUR, ALCATEL-LUCENT TO ALCATEL-LUCENT Case the serving and drift RNS are Alcatel-Lucent with same release & same configuration.

- RNSAP Dedicated measurement initiation request (Event A & B) upon change of primary cell under the drift RNC

SOFT HANDOVER OVER IUR, OTHER VENDOR TO ALCATEL-LUCENT

In this case the serving RNC is a 3rd party vendor and may not support RNSAP Dedicated measurement initiation request (Event A & B)

5.3.5 34216 AMR IMPROVEMENTS [USA MARKET] Cases: AMR12.2 selection if the UE has a simultaneous PS RAB

12.2 selection independent of cell load colors

AMR5.9 selection based on DL power load UL cell load Iub DS DL load

Spreading factor selection for AMR5.9 Soft handover with and without Iur

SRNS Relocation type UE involved in Relocation of SRNS

SRNS Relocation type UE not involved in Relocation of SRNS




Reconfiguration 5.9 to 12.2 Iub only Reconfiguration with Iur involvement Reconfiguration with Iur involvement towards

umt sys dd 018824 v03.06 en - amr cs speech service support - umts access standard

Documents

umtsysdd018824 document

en document status

en standard 19may2008

standard 13sep2007 issue

16feb2008 issue

19sep2007 issue

16jul2007 issue

25apr2008 issue