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

5/27/2018 UMT SYS DD 018824 V03.06 en - AMR CS Speech Service Support - UMTS Access Standard - slidep...

http:///reader/full/umt-sys-dd-018824-v0306-en-amr-cs-speech-service-support-umts-ac

AMR CS speech service support - UMTS Access

Document number: UMT/SYS/DD/018824Document issue: 03.06 / ENDocument status: StandardDate: 19/May/2008

External document

Copyright2007 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




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 review05/May/2008


Descoping of 32687 functionality (no iRM table checks at call admission, noAMR rate control for multi-service calls when PS is mapped to R99 DCH)

Remove support of SRB#5

25/Apr/2008


Update according review comments

04/Apr/2008

Issue 03.03 / EN, Preliminary

Market Information added

16/Feb/2008


Update after review

28/Jan/2008


Creation based on issue 02.05

Feature 34216 added for UA6.0

05/Dec/2007


Update after review

26/Nov/2007


POR update






19/Sep/2007


13/Sep/2007Issue 02.02 / EN, Preliminary

31/Aug/2007


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............................................................................................................................71.1 OBJECT....................................................................................................................................71.2 FRS ........................................................................................................................................71.3 SCOPE OF THIS DOCUMENT .......................................................................................................71.4 AUDIENCE FOR THIS DOCUMENT ................................................................................................81.5 DEFINITIONS &EDITORIAL CONVENTIONS ...................................................................................8

2 RELATED DOCUMENTS ............................................................................................................102.1 APPLICABLE DOCUMENTS ........................................................................................................102.2 REFERENCE DOCUMENTS ........................................................................................................10

3 FUNCTION OVERVIEW ..............................................................................................................124 BENEFITS....................................................................................................................................16

4.1 CUSTOMER/SERVICE PROVIDER BENEFITS ................................................................................164.2 END-USER/SUBSCRIBER BENEFITS ........................................................................................17

5 FUNCTIONAL DESCRIPTION....................................................................................................185.1

PRINCIPLE ..............................................................................................................................18

5.1.1 AMR support with Iu UP V1 (features 30229 & 18717 not activated)...........................185.1.2 AMR multi-mode support with Iu UP V2 (18717, 30229, 33863)..................................215.1.3 Wideband AMR (27803)................................................................................................285.1.4 AMR mode change during call (32687) ........................................................................335.1.5 AMR support with Iu UP V1 (featurE 34216 activated).................................................40

5.2 INTER SUB-SYSTEM FUNCTIONAL DISTRIBUTION ........................................................................415.2.1 RNC...............................................................................................................................415.2.2 Node B ..........................................................................................................................415.2.3 OMC..............................................................................................................................41

5.3 USE CASES.............................................................................................................................425.3.1 AMR support with Iu UP V1 ..........................................................................................425.3.2 AMR-NB multi-mode support with Iu UP V2 (18717, 30229)........................................425.3.3 Wideband AMR (27803)................................................................................................445.3.4 AMR mode change during call (32687) ........................................................................455.3.5 34216 AMR IMprovements ........................................................................................46

5.4 RNSINTER-RELEASE COMPATIBILITY USE CASES ....................................................................475.4.1 Features 30229, 18717 .................................................................................................475.4.2 Feature 27803...............................................................................................................485.4.3 Feature 32687...............................................................................................................495.4.4 Feature 34216...............................................................................................................49

5.5 FEATURE INTERWORKING ........................................................................................................505.5.1 Dependencies ...............................................................................................................505.5.2

Interaction......................................................................................................................51

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






5.6.1 System performances...................................................................................................555.6.2 Dimensioning ................................................................................................................555.6.3 Capacity ........................................................................................................................565.6.4 Dependability ................................................................................................................565.6.5 End User Performances................................................................................................56

5.7 SECURITY...............................................................................................................................566 INTERFACES ..............................................................................................................................56

6.1 UMTSINTERFACES ................................................................................................................576.1.1 UUinterface...................................................................................................................576.1.2 IUinterface ....................................................................................................................756.1.3 IURinterface ..................................................................................................................766.1.4 IUBinterface ..................................................................................................................776.1.5 IUPCInterface (RNC/SAS).............................................................................................786.1.6 IUBCInterface (RNC/CBC)............................................................................................78

6.2 OAMINTERFACES ..................................................................................................................796.2.1 3GPP OAM interfaces...................................................................................................796.2.2 External ALCATEL-LUCENT OAM interfaces ..............................................................79

6.3 TRANSMISSION NETWORK INTERFACES ....................................................................................796.3.1 Physical layer ................................................................................................................796.3.2 Ethernet.........................................................................................................................806.3.3 ATM...............................................................................................................................806.3.4 IP ...................................................................................................................................80

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

7.1.1 RAN Managed Objects .................................................................................................817.1.2 RAN Customer Parameters ..........................................................................................907.1.3 CDL ............................................................................................................................ 1067.1.4 CDL: New/Modified/removed COMPONENTS.......................................................... 1067.1.5 Control rules............................................................................................................... 106

7.2 FAULT MANAGEMENT ........................................................................................................... 1087.2.1 RNC CNode, BTS and OAM Alarm Notifications....................................................... 1087.2.2 RNC INode Alarm Notifications.................................................................................. 1087.2.3 State Changes ........................................................................................................... 108

7.3 PERFORMANCE MANAGEMENT .............................................................................................. 1087.3.1 Counters..................................................................................................................... 1087.3.2 Metrics........................................................................................................................ 1197.3.3 Traces ........................................................................................................................ 119

7.4 MISCELLANEOUS ................................................................................................................. 1217.4.1 Static Data.................................................................................................................. 1217.4.2 Inventory..................................................................................................................... 1217.4.3 Action ......................................................................................................................... 121

8 OAM PROCEDURES ............................................................................................................... 1228.1 UPGRADES .......................................................................................................................... 122

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

8.2 INSTALLATION &COMMISSIONING PROCEDURES .................................................................... 1268.3 MAINTENANCE ..................................................................................................................... 1268.4 OPERATION ......................................................................................................................... 126






8.5 EXTENSION ......................................................................................................................... 1268.6 TECHNICAL ASSISTANCE SUPPORT ....................................................................................... 1278.7 STABILITY DATA ANALYSER .................................................................................................. 127

9 FIELD INTRODUCTION ........................................................................................................... 1279.1 HARDWARE CONSTRAINTS.................................................................................................... 1279.2 SPARE PART CONSTRAINTS .................................................................................................. 1279.3 INTER RNSVERSION INTERWORKING ................................................................................... 128

9.3.1 Features 30229, 18717.............................................................................................. 1289.3.2 Feature 27803............................................................................................................ 1289.3.3 Feature 32687............................................................................................................ 128

9.4 CORE NETWORK INTERWORKING........................................................................................... 1289.5 UEINTERWORKING .............................................................................................................. 1289.6 GERANINTERWORKING ...................................................................................................... 128

10 TOOLS IMPACTS..................................................................................................................... 12911 RESTRICTION TABLE.....................................................ERROR! BOOKMARK NOT DEFINED.12 ABBREVIATIONS AND DEFINITIONS.................................................................................... 130

12.1 ABBREVIATIONS ................................................................................................................... 13012.2 DEFINITIONS........................................................................................................................ 131

12.2.1 ALCATEL-LUCENT specific definitions ..................................................................... 13112.2.2 AMR specific definitions............................................................................................. 13212.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.0applicable FRS(s) are:

FRS #30229 Iu UP SMpSDU V2

FRS #18717 AMR-NB multi-mode support (for Iu UP V2)

The UA05.0.3applicable FRS(s) are:

FRS #33863 Initialisation of AMR DL Rate from OMC

In UA05.1applicable FRS(s):

FRS #27803 Adaptive Multi Rate - Wide Band


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


FRS #34216 AMR improvements

1.3 SCOPE OF THIS DOCUMENT

The scope of this document is UTRAN. According to 3GPP this includes the followingnodes: 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. systemvalidation 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 codecwith the exclusion of rates related to the silent mode (SID rate and NoData rate)

o AMR rate It refers to any AMR rate including the silent moderates

Iu UP Iu User Plane

SMpSDU Support Mode for predefined SDU size

For other definitions used throughout this document, please refer to section12.

The following editorial conventions are used:

Cross out (strikethrough): when used in tabular: means not supported or notused.

Change bar: indicates additions or deletions

1.6 DEFINITIONS AND SPECIFICATION PRINCIPLES

The present document addresses several markets with potentially different behavioursin 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 (formerLucent 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 taggingof a heading indicates that the heading preceding the tag"[Global Market]" and the section following the heading appliesonly to the Global Market.This tagging shall, in particular, be used under the parametername 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 ofa heading indicates that the heading preceding the tag "[USAMarket]" and the section following the heading applies only tothe 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. Multiplesequential paragraphs applying only to Global Market areenclosed 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 "[USAMarket - " applies only to the USA Market. Multiple sequentialparagraphs applying only to USA Market are enclosedseparately to enable insertion of Global Market specific (orcommon) paragraphs between the USA Market specificparagraphs.

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


http:///reader/full/umt-sys-dd-018824-v0306-en-amr-cs-speech-service-support-umts-acc




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


[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


[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


[R30] M3100 Maintenance Telecommunications Management Network: GenericNetwork 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 (akaSCR (VAD/DTX)) with use of version 1 of Iu UP.

The following set of features provides the bearer service support for additional AMRcodecs:

[Global Market]The UA05.0 features 18717 AMR-NB multi-mode support and30229Iu UP SMpSDU V2 provide the bearer service support with use ofversion 2 of Iu UP for a number of narrowband AMR speech service and thesupport of a number of functions to allow core network Transcoder/TandemFree mode of Operation (TrFO/TFO) speech calls.

RbSetConf#B

RbSetConf#A

12.212.27.955.9

4.75

SIDNo

SIDNo

10.26.75.9

4.75

SIDNo

5.94.75

SIDNo

4.75

SIDNo

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 RABsare with

VAD/DTX

Only with Version 2 of Iu UP

[Global Market]The UA05.0.3 feature 33863 Initialisation of AMR DL Ratefrom OMC allows the operator to control the max allowed AMR DL rate forthe OMC

[Global Market]The UA05.1 feature 27803 AMR-WB provides the support bythe RAN of the necessary means to provide the CS WB telephony built on themulti-mode AMR WB speech codec. This consists in providing the requiredRAB as well as the means for changing UL and DL Rates. This feature worksonly with Iu UP v2.






12,658,856,6

SIDNo

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 & Radiointerfaces

All RABsare 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 supportmore 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 per3GPP 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 maxpower threshold during at least an OAM configurable amount of time,the RNC will request the Core Network to reduce the DL AMR rate inorder 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, theRNC will no more restrict the upper rates provided that there is norestriction from Iub resource perspective.

The Max permitted DL Tx power for a individual AMR call depends onthe 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 CoreNetwork 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 todetermine the Equivalent Bit Rate (EBR) over Iub instance related tothe added link.

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

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

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

Before re-enabling a previously disabled AMR rate the RNC needs to checkwhether this AMR rate is inline with the bandwidth of the currently establishedtransport bearers.

Note: The load colors of all cells in the UEs active set is taken into account whenselecting 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 thereis 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 changeTrigger 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 toselect AMR12.2 or AMR5.9 in monorate mode to increase the voice capacity relativeto a AMR12.2 only scenario. The codec selection is done at RAB Assignment anddependent 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 whenthere 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. OtherwiseSF128 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-NItf-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 OMC30229 X X18717 X* X X33863 X X**27803 X* X X32687 X X X34216 X X

(*) Only test and capacity impacts

(**) Only from UA05.1

The following table indicates which features are commercially supported by iBTS andOneBTS:

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


32687 AMR mode change during the call - Evolution

benefit loss


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 (AMRImprovements):

benefit loss


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


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 ) XQuality Of Service (call drop, availability..) X

New services X


32687 AMR mode change during the call - Evolution


Voice quality (HO, call handling enhancement )

Quality Of Service (call drop, availability..) XNew services

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


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 & 18717NOT ACTIVATED)

The AMR 12.2 mode with VAD/DTX is supported (AMR 12.2 without VAD/DTXsupport 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 RABparameters with a provisioned user service configuration and to retrieve and/orcompute 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 algorithmare: 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, SDUformat information Parameter (SDU sizes per sub-flow and AMR rate).

The requested RAB parameters are considered as consistent if the following rule isfulfilled:

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 causeRequested 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 compoundSDU sizes corresponding to a rate greater or equal to the requested GBR for case ofthe Iu UP V1 protocol.

Case 1: Version 1 of Iu UP is requested by the CNThe RNC selects the RbSetConf, which supports the AMR 12.2 rate providedthat the 12.2 rate is part of the Core Network requested rate.






Case 2: Version 2 of Iu UP is requested by the CNThe RAB Assignment Request is rejected

Case 3: the CN allows both Versions of Iu UPThe RNC behaves as only Version 1 of Iu UP (same behavior as for Case 1applies)

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 nonselected 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 casecomputed gain factors have been provisioned and a reference TFC ismissing (i.e. was removed at 1st step) the RAB matching is failed andthe 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 asin 5.1.1.1.1.2

RbSetConf matchingas in 5.1.1.1.1.2

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

If the RAB matching fails due to AsConf matching failure, the RAB assignmentprocedure 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)

12.2 mono-mode (IuUp

V1) Partial success

(**)

Success

AMR-NB (IuUp V2)

Failure (*)

Partial success

(**)

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 RABattributes):

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 afterrelocation (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 RNCdoes not attempt partial relocation) or if the AsConf matching failed, the Relocation

Resource Allocation procedure is failed (and thus the relocation) with RANAP causeUnable 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 thanthese supported in serving role, e.g. including other rates. This is to prevent Iur anyinter-working issues when facing RNC from other manufacturer or Alcatel-Lucent RNCin 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 besupported in drift role. In such cases RL setup or reconfiguration are failed withRNSAP 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 AMRconfigurations 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 speechservice along with possible PS data services

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

The following principles apply:

As per 3GPP specification, the call setup in version 2 of Iu UP requires theinitialization 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 theselected configuration if feature #33863 is not activated otherwise theinitial max allowed DL rate is the min between the max rate supportedby 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 corenetwork) is forwarded by means of an RRC TFC control commandover 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 compoundSDU sizes (N+1 compound SDU) for case of the Iu UP V2 protocol or to one of therequested compound SDU sizes corresponding to a rate greater or equal to therequested 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 CNSame 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 followingcriteria:The RbSetConf shall satisfy to the set of N+1 compound SDU sizes (allrequested rates shall be supported)

Case 3: the CN allows both Versions of Iu UPThe 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 asin case 1

5.1.2.1.1.3 ASCONF MATCHING


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 provisionedparameters (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 in5.1.1.1.1.2

RbSetConf matching asin 5.1.1.1.1.2

v2 or v1 RbSetConf matching as in5.1.2.1.1.2 / case 2

RbSetConf matching as in5.1.2.1.1.2 / case 3

RbSetConf matching asin 5.1.1.1.1.2

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

If the RAB matching fails due to AsConf matching failure, the RAB assignmentprocedure 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 isenabled, 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)

12.2 mono-mode

(IuUp V1) Partial success(**)

Success

AMR-NB (IuUp V2)

Failure (*)

Partial success

(**)

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 isassumed that SRB#5 support is not required in SRNS Relocations.

The received TFC subset IE is included in the UL Transport channel informationcommon 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 (exceptthat 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, anyPS 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 thehighest initialised rate. According to the maximum rate for the uplink included in theRate Control acknowledgement, the RNC triggers an RRC TFC Control procedure.

If the feature #33863 is enabled the following applies at call setup or after relocationscenarios, 2G to 3G handover scenario:

The initial maximum DL rate is evaluated as following:

maxFromOam = lowest value of maxDlAmrRateFromOam across all cells ofactive set

Note: If no value was provisioned for a cell, or if a cell is controlled by anotherRNC, 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 tomaxFromOam 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 UPinitialisation 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 maximumDL 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 allowed10.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 parameterisCnInitiatedRateControlAllowed is set to True, the Iu UP is in version 2 and theframe is correctly formatted, otherwise they are ignored. For case the RNC accepts

the rate control request, the RNC acknowledges it with indication of the currentmaximum rate in the downlink (within the scope of this feature this is always thehighest initialised rate).

Then the RNC triggers an RRC TFC Control procedure indicating the new maximumrate in the uplink. The RNC ignores any attempt to disallow the lowest AMR rate orSID or NO_DATA.

The RNC does not check on the User Plane that the UE actually complies with theTFC control. In case the UE continues to use a rate that is no longer allowed, the RNCcontinues to handle normally the frames. This may occur e.g. because the TFCControl was lost over the radio. The assumption is that the originator of the ratecontrol 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 alltransport channels optional IE of various RRC messages such as RB SETUP,RB RECONFIGURATION, RB RELEASE and also SRNS RELOCATIONINFORMATION (included in Source RNC To Target RNC TransparentContainer IE used at relocation). TFC subset is mandatory for TFCCONTROL over SRB#2 (called DPCH/PUSCH TFCS in uplink).

TFC subset represents a subset of the UL TFCS. It allows to restrict the useof 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 CONTROLmessage 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 connectionunavailability, the rate control is not memorized but dropped.

In case the RNC receives TFC CONTROL FAILURE (case the TFC CONTROL wassent over SRB#2 and the UE found that the TFC subset were inconsistent with theconfigured 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 assumedthat 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 perPhysical Channel in DL extension from 64 to 128) one in order to support the newmulti-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 withvalue 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 ina TrFO scenario.

If the RNC initiated the Iu UP connection in version 1, any incoming initialisationrequest is ignored.

If the RNC initiated the Iu UP connection in version 2, any incoming initializationrequest 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 thehighest permitted UL rate (embedded rate control). The RNC forwards this rate controlby 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 uponreception 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-WBconfigurations 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 beingpossibly locked to 0 kbps rate (no AMR-WB class C bits) or with 2 Iu sub-flows. Inboth cases only 3 sub-flow is configured over radio/Iub/Iur.

Step2

The RNC identifies the RbSetConf, which satisfies to the list of requested compoundSDU 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


Step4

CAC proceeds as usual

Step5

Initialization:

RFCI allocation (number of RFCI = number of Compound SDU sizes). Allocationscheme should be from lowest rate to the highest rate (0*, SID, etc) in order to avoidas much as possible RFCI mismatch for TFO/TrFO operation. RFCI for 0 rate onlyinitiated 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 currentimplementation.

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-flowsbetween 2 and 3. The number of sub-flows configured of the radio/Iub/Iuris 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 followingdifference:

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/Initprocedure.

The Iub transport bearer is replaced. For Iur transport there is no modification nor TBreplacement.

Iu CS transport bearer is either kept or replaced as requested by the CN (thepresence of the TLI IE in the RAB Assignment Request triggers the transport bearerreplacement 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 setupcase.

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

RFCI #






(example)4 AMR-WB 12.653 AMR-WB 8.852 AMR-WB 6.61 AMR-WB SID

0* NO-DATA(**) If SDUs for NO-DATA rate provided in RANAP RAB AssignmentRequest message

Mapping between RFI & TFI and RFCI and TFCI

RFCS

RFCI RF 1 RF 2RF 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 1326.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 toavoid 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 4or 9TF4,TF3,TF0,

TF0/TF112.65

3 3or 8TF3,TF2,TF0,

TF0/TF18.85

2 2or 7TF2,TF1,TF0,

TF0/TF16.6

1 1or 6TF1,TF0,TF0,

TF0/TF1SID

0 0or 5TF0,TF0,TF0,

TF0/TF1NO-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. Feature33863 cannot be applied on an AMR-WB call (i.e. no outgoing Iu Rate Control)






5.1.4 AMR MODE CHANGE DURING CALL (32687) [GLOBALMARKET]

The feature activation flag is the parameter isAmrRateControlDuringTheCallAllowed

Several concurrent criteria are taken into account by the RNC to trigger any AMR ratecontrol:

o The possible criteria to control the AMR rate are the DL Tx CP, the DL powerload*, 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 thefeature 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, inaddition 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 rateprovided 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 dedicatedchannel(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-DSCHchannel(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 configuresNBAP dedicated measurement Reporting on the primary cell in order to track the DLTransmitted Code Power.

Thus, the RNC can detect when the DL transmitted power rises above a giventhreshold, which indicates that radio conditions become worst enough to require a ratedecrease.

(*) AMR rate control is allowed if there are any rate controllable AMR modes, i.e. AMRrates above the Requested Guaranteed Bit Rate. In case of multiple RABcombinations, eligibility to AMR rate adaptation requires that some additionalconditions are met. Refer to section Multi-service Handling.

1. Dedicated measurements configuration

In order to detect a rate decrease / increase condition, the RNC configures dedicatedmeasurement 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 timeduring which the threshold condition should be fulfilled before the UE sends theevent to the RNC.

2. Dedicated measurements initiation

The dedicated measurement is initiated on the primary cell at call establishment timeor whenever there is a change of the primary cell (the dedicated measurement on theold 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 thatthe max current DL rate* is now prohibited / allowed.

(*) In case of TFO/TrFO the DL rate may change. Despite the fact that themeasurement 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].maxDlTxPowerRateDecThreshold = pcpichPower + maxDlTxPower dlAmrRateDecreaseTxcpTrigger.thresholdDeltaRateIncThreshold = pcpichPower + maxDlTxPower dlAmrRateIncreaseTxcpTrigger.thresholdDelta

WheredlAmrRateDecreaseTxcpTrigger.thresholdDelta






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

The Iub DS load criteria is taken into account if the parameterisAmrRateControlDuringTheCallAllowedand isAmrRatecontrolOnIubDsLoadAllowedareset to True.

A specific iRM table is introduced to determine the max allowed AMR rate based onthe 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 loadcolour change. Any ping-pong effect would due to e.g. downgrade by TxCPmeasurement 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 IuUP rate control / TFC control messages may be successively sent. The Iu UP ratecontrol / 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 loado 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 RNCo 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 symmetricservices: speech or Video Telephony calls, Symmetric CS streaming) orasymmetric services with higher rate in the DL

Iub transport Color OLS Max AMR rateGold 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 processof 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 thetarget 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 radiolink

(*) 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 commonmeasurement on Received Total Wideband Power (RTWP) and determination of theUL cell load colors based on it.

A specific UL iRM table is introduced to determine the max allowed AMR rate basedon 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 cellload color of the cells of the Active Set

After every primary cell update, to help determine the new max UL rate basedon 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. parameterdelayBetweenAmrRateControls )

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 loado To a given value of the pair (UE AS UL cell color, OLS) corresponds the

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

UL cell load Color OLS Max AMR rate

Gold e.g. 12.2


Bronze e.g. 7.95

Gold e.g. 12.2


Bronze e.g. 5.9

Gold e.g. 5.9

RED Silver e.g. 4.75

Bronze e.g. 4.75






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

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

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

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

In order to avoid any ping pong effects due to the application of differentcriteria, the downlink rate upgrade is not triggered based on DL power loadcolour change. Any ping-pong effect would due to e.g. downgrade by TxCPmeasurement 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 PSRAB(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 loado 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 Powerload Color

OLS Max AMR rate

Gold e.g. 12.2


Bronze e.g. 7.95

Gold e.g. 12.2


Bronze e.g. 5.9

Gold e.g. 5.9

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

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 be7.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 theRATE CONTROL frame has not been correctly interpreted or received, the Iu UPshall retrigger an Iu Rate Control procedure. If after NRC repetitions the rate stillnot 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

CNRNCUE 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 directionof the RATE CONTROL control frame, or a RATE CONTROL NEGATIVE ACKNOWLEDGEMENT control frame

has been received,

or no RATE CONTROL POSITIVE ACKNOWLEDGEMENT control framewas received before the supervision timer TRCexpires),

the Iu UP shall retrigger a Iu Rate Control procedure. If after N RCrepetitions, 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

ails. Up to NRC repetitions allowed

Notes:






In this version of the document, the OAM parameter tInit is used to set both25.415 TRC and TINIT and, the OAM parameter nInit is used to set both25.415 NRCand NINIT.

The IuUP Rate Control Ack message contains rate control information

relevant for UL operation. If the maximum AMR rate provided by thismessage is lower than the currently used AMR rate, then the RNC needs torate control the UL by sending a Transport Format Combination Controlmessage 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 measurementssupported). 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.2in the RAB Parameters IE of the RAB Assignment Request or intra-system RelocationRequest of type UE involved in relocation of SRNS requesting Iu UP V1. In thisscenario 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 PSRAB 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 basedon the OLS and the DL power load color. The table is played at call admission. Thepower load from all cells in the active set which are managed by the SRNC is takeninto account. The DL power load color is derived from DL Tx power measurementsprovided 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 basedon the OLS and the UL cell load color. The table is played at call admission. The ULcell 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 basedon the OLS and the Iub DS DL load color. The table is played at call admission. TheIub DS DL load from all cells in the active set which are managed by the SRNC istaken 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 ofAMR5.9. The DL OVSF code load from all cells in the active set which are managedby the SRNC is taken into account.

5.1.5.2 AMR CODEC RECONFIGURATION FROM AMR5.9 TO AMR12.2

AMR5

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

Documents

standard update

standard descoping

immediately5272018 umt

support of srb

preliminary update

multiservice calls

preliminary creation

property of alcatel