Transmission Resource Management

Error! Unknown document property

name.

RAN

Transmission Resource Management Parameter Description

Issue 01

Date 2009-03-30


name.

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For

any assistance, please contact our local office or company headquarters.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

Bantian, Longgang

Shenzhen 518129

People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Copyright © Huawei Technologies Co., Ltd. 2009. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior

written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective

holders.

Notice

The information in this document is subject to change without notice. Every effort has been made in the

preparation of this document to ensure accuracy of the contents, but all statements, information, and

recommendations in this document do not constitute the warranty of any kind, express or implied.

http://www.huawei.com/

mailto:[email protected]

Error! Unknown document property name.

Error! Unknown document property name. About This Document

Issue Error! Unknown

document property name.

(Error! Unknown document

property name.)


name.

iii

About This Document

Author

Prepared by Xing Ruizhi Date 2008-10-16

Edited by Sun Jingshu Date 2008-11-20

Reviewed by Date

Translated by Zhang Lijun Date 2008-12-10

Tested by Lu Feng Date 2009-01-10

Approved by Duan Zhongyi Date 2009-03-30


Error! Unknown document property name. Contents




property name.)


name.

v

Contents

1 Change History ........................................................................................................................... 1-1

2 Introduction................................................................................................................................. 2-1

3 TRM Algorithm Overview ....................................................................................................... 3-1

3.1 Contents of TRM Algorithms ........................................................................................................................ 3-1

3.2 Requirements of TRM Algorithms ................................................................................................................ 3-1

3.2.1 Networking Requirement ..................................................................................................................... 3-1

3.2.2 QoS Requirement ................................................................................................................................. 3-2

3.2.3 Capacity Requirement .......................................................................................................................... 3-3

3.2.4 Differentiated Service Requirement ..................................................................................................... 3-3

4 Transmission Resources ........................................................................................................... 4-1

4.1 Transmission Resource Introduction ............................................................................................................. 4-1

4.2 Physical Transmission Resources .................................................................................................................. 4-2

4.2.1 Physical Layer Resources of the RNC for ATM Transport .................................................................. 4-2

4.2.2 Physical and Data Link Layer Resources of the RNC for IP Transport ............................................... 4-3

4.3 LP Resources ................................................................................................................................................. 4-4

4.3.1 LP Introduction .................................................................................................................................... 4-4

4.3.2 ATM LP at the RNC ............................................................................................................................. 4-6

4.3.3 IP LP at the RNC .................................................................................................................................. 4-8

4.3.4 Resource Group at the RNC ................................................................................................................. 4-8

4.3.5 ATM LP at the NodeB .......................................................................................................................... 4-8

4.3.6 IP LP at the NodeB ............................................................................................................................... 4-9

4.4 Path Resources .............................................................................................................................................. 4-9

4.4.1 AAL2 Path ........................................................................................................................................... 4-9

4.4.2 IP Path .................................................................................................................................................. 4-9

4.5 Priorities ...................................................................................................................................................... 4-10

5 TRM Mapping ............................................................................................................................ 5-1

5.1 Traffic Bearer ................................................................................................................................................ 5-2

5.2 Transport Bearer ............................................................................................................................................ 5-3

5.2.1 Type of Path ......................................................................................................................................... 5-3

5.2.2 DiffServ and DSCP .............................................................................................................................. 5-3

5.3 Mapping from Traffic Bearers to Transport Bearers ..................................................................................... 5-4

5.3.1 RNC-Oriented Default Mapping .......................................................................................................... 5-4

5.3.2 Adjacent-Node-Oriented Mapping ....................................................................................................... 5-5






property name.)


name.

vi

6 Load Control................................................................................................................................ 6-1

6.1 Definition of Load ......................................................................................................................................... 6-1

6.2 Bandwidth Reserved for Services ................................................................................................................. 6-1

6.3 Admission Control ........................................................................................................................................ 6-4

6.3.1 Admission Control Algorithm .............................................................................................................. 6-4

6.3.2 Load Balancing .................................................................................................................................... 6-5

6.3.3 Admission Procedure ........................................................................................................................... 6-8

6.4 Intelligent Access Control ........................................................................................................................... 6-11

6.5 Load Reshuffling and Overload Control ..................................................................................................... 6-11

6.5.1 Iub Congestion Detection ................................................................................................................... 6-11

6.5.2 Iub Overload Detection ...................................................................................................................... 6-12

6.5.3 Congestion and Overload Handling ................................................................................................... 6-12

7 User Plane Processing ............................................................................................................... 7-1

7.1 Overview of User Plane Processing .............................................................................................................. 7-1

7.2 Hub Scheduling and Shaping ........................................................................................................................ 7-1

7.2.1 RNC Scheduling and Shaping .............................................................................................................. 7-1

7.2.2 NodeB Scheduling and Shaping ........................................................................................................... 7-2

7.3 Congestion Control of Iub User Plane........................................................................................................... 7-2

7.4 Downlink Iub Congestion Control Algorithm ............................................................................................... 7-3

7.4.1 Overview of the Downlink Iub Congestion Control Algorithm ........................................................... 7-3

7.4.2 RNC RLC Retransmission Rate-Based Downlink Congestion Control Algorithm ............................. 7-5

7.4.3 RNC Backpressure-Based Downlink Congestion Control Algorithm ................................................. 7-8

7.4.4 RNC R99 Single Service Downlink Congestion Control Algorithm ................................................... 7-9

7.4.5 NodeB HSDPA Adaptive Flow Control Algorithm ............................................................................ 7-10

7.5 Uplink Iub Congestion Control Algorithm .................................................................................................. 7-12

7.5.1 Overview of the Uplink Iub Congestion Control Algorithm .............................................................. 7-12

7.5.2 NodeB Backpressure-Based Uplink Congestion Control Algorithm (R99 and HSUPA) ................... 7-13

7.5.3 NodeB Uplink Bandwidth Adaptive Adjustment Algorithm .............................................................. 7-15

7.5.4 RNC R99 Single Service Uplink Congestion Control Algorithm ...................................................... 7-16

7.5.5 NodeB Cross-Iur Single HSUPA Service Uplink Congestion Control Algorithm ............................. 7-17

7.6 Iub Efficiency Improvement ....................................................................................................................... 7-17

7.6.1 IP RAN FP-MUX ............................................................................................................................... 7-18

7.6.2 IP RAN Header Compression ............................................................................................................ 7-18

7.6.3 FP Silent Mode ................................................................................................................................... 7-19

7.7 IP PM .......................................................................................................................................................... 7-19

8 TRM Parameters ......................................................................................................................... 8-1

8.1 Description .................................................................................................................................................... 8-1

8.2 Values and Ranges ......................................................................................................................................... 8-6

9 TRM Reference Documents ..................................................................................................... 9-1

10 Appendix ................................................................................................................................. 10-1






property name.)


name.

vii

10.1 Default TRMMAP Table for the ATM-Based Iub and Iur Interfaces ........................................................ 10-1

10.2 Default TRMMAP Table for the IP-Based Iub and Iur Interfaces ............................................................. 10-2

10.3 Default TRMMAP Table for the ATM&IP-Based Iub Interface ............................................................... 10-4

10.4 Default TRMMAP Table for the Hybrid-IP-Based Iub Interface .............................................................. 10-5

10.5 Default TRMMAP Table for the ATM-Based Iu-CS Interface .................................................................. 10-7

10.6 Default TRMMAP Table for the IP-Based Iu-CS Interface ...................................................................... 10-7

10.7 Default TRMMAP Table for the Iu-PS Interface ...................................................................................... 10-8



Error! Use the Home tab to apply 标题 1 to the

text that you want to appear here.Error! Use the

Home tab to apply 标题 1 to the text that you

want to appear here.




property name.)


name.

1-1

1 Change History

The change history provides information on the changes in different document versions.

Document and Product Versions

Table 1-1 Document and product versions

Document Version RAN Version

01 (2009-03-30) 11.0

Draft (2009-03-10) 11.0

Draft (2009-01-15) 11.0

This document is based on the BSC6810 and 3900 series NodeBs.

The available time of each feature is subject to the RAN product roadmap.

There are two types of changes, which are defined as follows:

Feature change: refers to the change in the transmission resource management.

Editorial change: refers to the change in the information that was inappropriately

described or the addition of the information that was not described in the earlier version.

01 (2009-03-30)

This is the document for the first commercial release of RAN11.0.

Compared with draft (2009-03-10) of RAN11.0, this issue incorporates the following changes:

Change Type Change Description Parameter Change

Feature change None. None.

Editorial change The description of UBR PLUS is changed to

UBR +.

None.




text that you want to appear here.Error! Use the

Home tab to apply 标题 1 to the text that you

want to appear here.




property name.)


name.

1-2

Draft (2009-03-10)

This is the second draft of the document for RAN11.0.

Compared with draft (2009-01-15), draft (2009-03-10) optimizes the description.

Draft (2009-01-15)

This is the initial draft of the document for RAN11.0.

Compared with 02 (2008-07-30) of RAN10.0, draft (2009-01-15) incorporates the following

changes:

Change Type Change Description Parameter Change

Feature change None. None.

Editorial change General documentation change:

The contents of the Iub Overbooking Description are added to this document, and the

description in this document is revised.

None.

The title of the document is changed from

Transmission Resource Management

Description to Transmission Resource Management Parameter Description.

None.

Parameter names are replaced with parameter

IDs.

None.

None. The added parameters

are as follows:

MoniterPrd

TimeToTriggerA

EventAThred

PendingTimeA

TimeToTriggerB

TimeToMoniter

EventBThred

PendingTimeB




text that you want to appear here.Error! Use

the Home tab to apply 标题 1 to the text that

you want to appear here.




property name.)


name.

2-1

2 Introduction

Transmission Resource Management (TRM) is aimed at increasing the system capacity in

various networking scenarios without affecting the Quality of Service (QoS). In addition,

TRM provides differentiated services for Best Effort (BE) services to improve the data

transmission efficiency.

TRM involves management of the transmission resources on the Iub, Iur, and Iu interfaces.

Transmission resources are one type of resource that the UTRAN provides. Closely related to

TRM algorithms are Radio Resource Management (RRM) algorithms, such as the scheduling

algorithm and load control algorithm for the Uu interface. The TRM algorithm policies should

be consistent with the RRM algorithm policies.

Compared with the transmission on the other interfaces, the transmission on the Iub interface

is of higher costs and more complex networking modes and has a greater impact on the

system performance. Therefore, this document describes only the TRM algorithms for the Iub

interface.

Intended Audience

This document is intended for:

System operators who need a general understanding of transmission resource

management.

Personnel working on Huawei products or systems.

Impact

Impact on system performance

None.

Impact on other features

None.

Network Elements Involved

Table 2-1 lists the Network Elements (NEs) involved in TRM.




text that you want to appear here.Error! Use

the Home tab to apply 标题 1 to the text that

you want to appear here.




property name.)


name.

2-2

Table 2-1 NEs involved in TRM

UE NodeB RNC MSC Server MGW SGSN GGSN HLR

– √ √ – √ √ – –

NOTE:

–: not involved

√: involved

UE = User Equipment, RNC = Radio Network Controller, MSC Server = Mobile Service Switching

Center Server, MGW = Media Gateway, SGSN = Serving GPRS Support Node, GGSN = Gateway

GPRS Support Node, HLR = Home Location Register




property name.)


name.

3-1

3 TRM Algorithm Overview

3.1 Contents of TRM Algorithms

TRM algorithms cover the following aspects:

Transmission resources: basic transmission resources, including key objects such as ports

and paths, and attributes such as priorities and bandwidth.

Mapping from traffic bearers to transmission bearers: Transport networks can provide

priority-based services. According to the QoS requirements, traffic class,

Allocation/Retention Priority (ARP), Traffic Handling Priority (THP), and radio bearer

types of services, the transport networks map traffic to the transport bearers with the

appropriate characteristics of transport types and transmission priorities.

Load control for transmission resources: The TRM algorithms control access of users to

the network. With the QoS guaranteed, the network allows access of users to the

maximum extent.

Congestion control on the user plane of the transport network layer: For non-real-time

(NRT) services, the control helps prevent congestion and packet loss.

Improvement in efficiency on the user plane of the transport network layer: The

bandwidth occupied by services is reduced to improve the transmission efficiency on the

user plane.

3.2 Requirements of TRM Algorithms

3.2.1 Networking Requirement

The typical networking scenarios for the Iub interface are as follows:

Direct connection: The RNC is directly connected to a NodeB through a physical port,

the bandwidth of which is exclusively occupied by this Iub interface. This is the simplest

scenario, in which the TRM algorithms are also simple.

Transmission convergence: As shown in Figure 3-1, the Iub traffic of more than one

NodeB is converged, for example, on the transport network or by the hub NodeB. In this

scenario, the transmission convergence information, which can serve as the input to

TRM algorithms, must be configurable. The TRM algorithms applicable in transmission

convergence scenarios are relatively complicated.




property name.)


name.

3-2

Figure 3-1 Iub transmission convergence networking

NB = NodeB BW = bandwidth BW0 = bandwidth of the physical port

Bandwidth being variable: The bandwidth on the transport network might be variable.

For example, the bandwidth of Asymmetric Digital Subscriber Line (ADSL)

transmission is variable. In this case, the TRM algorithms need to be able to detect the

available bandwidth.

ATM&IP dual stack: ATM and IP transmission resources are available for one Iub

interface at the same time so that the transmission cost is reduced.

Hybrid IP: High-QoS transmission (such as IP over E1) and low-QoS transmission (IP

over FE) are applicable to one Iub interface at the same time so as to enable

differentiated management of services.

RAN sharing: Operators share the physical bandwidth. In this case, some bandwidth

should be reserved for each operator.

Table 3-1 lists the types of transport applicable to each interface.

Table 3-1 Types of transport applicable to each interface

Interface ATM IP ATM&IP Dual Stack Hybrid IP

Iub √ √ √ √

Iur √ √ – –

Iu-CS √ √ – –

Iu-PS – √ – –

3.2.2 QoS Requirement

The WCDMA system supports the following types of service:

Signaling, such as SRB, SIP, NCP, and CCP




property name.)


name.

3-3

Real-time (RT) service, such as conversational and streaming

NRT or BE service, such as interactive and background

The requirements are as follows:

For RT services, the bandwidth must be guaranteed. In terms of QoS, RT services do not

allow packet loss or buffering of a huge data volume. The buffering of a huge data

volume will result in an increase in the delay.

For NRT services, the Guaranteed Bit Rate (GBR) is not provided, so the bandwidth is

not required to be guaranteed. In the case of resource shortage, the data can be buffered

so as to reduce the traffic throughput. In order to guarantee the basic QoS of NRT

services, the RAN allows the configuration of the GBR for NRT services.

For the signaling such as NCP, CCP, SRB, and SIP, the traffic is low and its performance

is closely related to Key Performance Indicators (KPIs) of the network. Therefore, the

transmission of signaling takes precedence, and packet loss and long delay should be

prevented.

For R99 services, the time window mechanism is employed in the downlink, and the Iub

delay and jitter are required to stay within a certain range.

3.2.3 Capacity Requirement

The capacity requirements are as follows:

With the QoS guaranteed, the network should allow access of users to the maximum

extent. This is mainly implemented by the load control algorithm.

When data needs to be transferred for NRT services with innate bursty characteristic, the

bandwidth should be fully utilized to ensure a high throughput and prevent congestion.

This is mainly implemented by the user plane congestion control algorithm.

3.2.4 Differentiated Service Requirement

Different types of service have different requirements. Therefore, the level of quality

guaranteed varies according to the type of service. Service differentiation needs to take the

following factors into consideration:

Traffic class: The WCDMA system provides four traffic classes: conversational,

streaming, interactive, and background, in descending order of traffic priority.

User priority: There are three user priorities: Gold, Silver, and Copper, in descending

order of priority. The mapping between user priorities and ARPs is configurable. For

details, see the Load Control Parameter Description.

Type of radio bearer: R99, High Speed Downlink Packet Access (HSDPA), and High

Speed Uplink Packet Access (HSUPA).

To provide differentiated services is to provide different QoSs according to the traffic class,

user priority, and type of radio bearer. The details are as follows:

Differentiated service requirement for the transport layer: The transport layer provides

multiple types of transport bearers and transmission priorities. The appropriate type of

transport bearer and transmission priority should be selected according to the traffic class,

user priority, and radio bearer type of the service. The transmission of high-priority

traffic takes precedence upon transmission congestion, and thus the frame loss rate of the

traffic is low and the transmission delay is short. For details, see chapter 5 "TRM

Mapping."




property name.)


name.

3-4

Differentiated service requirement for the load control algorithm: The load control

algorithm for the Uu interface already supports differentiated services. The load control

algorithm for transmission resources should keep consistent with that for the Uu

interface. For details, see chapter 6 "Load Control."

Differentiated service requirement for the GBR of NRT services: For NRT services, the

GBR is configurable by running the SET USERGBR command according to the traffic

class, user priority, and bearer type (that is, DCH or HSPA) of the services.

Differentiated service requirement for the allocation of bandwidth for NRT services: The

activity of NRT services does not follow any obvious rule. When the demand from NRT

services for the transmission bandwidth exceeds the total available Iub bandwidth, the

bandwidth needs to be allocated to the services in a certain way. For High Speed Packet

Access (HSPA) services, when Uu resources face a hurdle, the Uu resources are

allocated to NRT services according to the Scheduling Priority Indicator (SPI) weight.

Accordingly, in the case of Iub transmission resource shortage, the Iub transmission

resources also need to be allocated to the NRT services according to the SPI. For details,

see section 7.3 "Congestion Control of Iub User Plane."




property name.)


name.

4-1

4 Transmission Resources

4.1 Transmission Resource Introduction

Transmission resources consist of ATM transmission resources and IP transmission resources.

ATM transmission resources are as follows:

Physical transmission resources: E1/T1, channelized STM-1, unchannelized STM-1,

ATM physical port (IMA, UNI, and fractional ATM)

Logical Port (LP) resources: ATM hub LP and ATM leaf LP

Path resources: AAL2 path, SAAL link, and IPoA PVC

Figure 4-1 shows the relation between the ATM transmission resources.

Figure 4-1 Relation between the ATM transmission resources

IP transmission resources are as follows:




property name.)


name.

4-2

Physical transmission resources: Ethernet port, E1/T1, channelized STM-1,

unchannelized STM-1, IP physical port (PPP/MLPPP port and trunk port)

LP resources: IP LP

Path resources: IP path and SCTP link

Figure 4-2 shows the relation between the IP transmission resources.

Figure 4-2 Relation between the IP transmission resources

4.2 Physical Transmission Resources

4.2.1 Physical Layer Resources of the RNC for ATM Transport

The following types of physical transmission port are available for ATM transport:

E1/T1: electrical ports on the AEUa board

Channelized STM-1/OC-3: optical ports on the AOUa board

Unchannelized STM-1/OC-3c: optical ports on the UOIa board




property name.)


name.

4-3

Table 4-1 describes the ATM interface boards.

Table 4-1 ATM interface boards

Board Description Transmission Mode

VPI /VCI Range Type of Service at the ATM Layer

AEUa AEUa refers to the RNC 32-port ATM

over E1/T1 interface unit (REV: a).

The AEUa is applicable to the Iu-CS,

Iur, and Iub interfaces.

UNI

IMA

Fractional

ATM

Fractional

IMA

LP

VPI: 0 to 255

VCI: 32 to

65535

CBR

RTVBR

NRTVBR

UBR

UBR+

AOUa AOUa refers to the RNC 2-port ATM

over channelized optical STM-1/OC-3

interface unit (REV: a).

The AOUa is applicable to the Iu-CS,

Iur, and Iub interfaces.

UNI

IMA

LP

VPI: 0 to 255

VCI: 32 to

65535

CBR

RTVBR

NRTVBR

UBR

UBR+

UOIa UOIa refers to the RNC 4-port

ATM/packet over unchannelized

optical STM-1/OC-3c interface unit

(REV: a).

The UOIa is applicable to the Iu-CS,

Iu-PS, Iu-BC, Iur, and Iub interfaces.

NCOPT VPI: 0 to 255

VCI: 32 to

65535

CBR

RTVBR

NRTVBR

UBR

UBR+

4.2.2 Physical and Data Link Layer Resources of the RNC for IP Transport

The IP transmission resources include the physical layer and data link layer resources.

In IP transport mode, the user plane data of the Iub, Iur, Iu-CS, and Iu-PS interfaces is carried

on UDP/IP.

The following types of physical transmission port are available for IP transport:

E1/T1: electrical ports on the PEUa board

FE/GE: electrical ports on the FG2a board

Optical GE: optical GE ports on the GOUa board

Unchannelized STM-1/OC-3c: optical ports on the UOIa board

Table 4-2 describes the IP interface boards.




property name.)


name.

4-4

Table 4-2 IP interface boards

Board Description Transmission Mode

PEUa PEUa refers to the RNC 32-port packet over E1/T1

interface unit (REV: a).

The PEUa is applicable to the IP-based Iub, Iur, and Iu-CS

interfaces.

PPP

MLPPP

MCPPP

FG2a FG2a refers to the RNC packet over electrical 8-port FE or

2-port GE Ethernet interface unit (REV: a).

The FG2a is applicable to the IP-based Iub, Iur, Iu-CS, and

Iu-PS interfaces.

IP over Ethernet

GOUa GOUa refers to the RNC 2-port packet over optical GE

Ethernet interface unit (REV: a).

The GOUa is applicable to the IP-based Iub, Iur, Iu-CS,

and Iu-PS interfaces.

IP over Ethernet

UOIa The board provides four unchannelized STM-1/OC-3c

optical ports and supports IP over SDH/SONET.

PPP

POUa POUa refers to the RNC 2-port packet over channelized

optical STM-1/OC-3 interface unit (REV: a).

The POUa provides two IP over channelized STM-1/OC-3

optical ports and supports IP over E1/T1 over

SDH/SONET.

The POUa supports 42 MLPPP groups in E1 mode and 64

MLPPP groups in T1 mode.

PPP

MLPPP

4.3 LP Resources

4.3.1 LP Introduction

After the physical transmission resources and path resources are configured, the system can

start to operate and services can be established. There are problems, however, in the following

scenarios:

Transmission convergence

Transmission convergence can be performed either on the transport network (for

example, convergence of NB1 and NB2, as shown in Figure 4-3) or at the hub NodeB

(for example, convergence of NB3 and NB4 at NB1, as shown in Figure 4-3). If only

physical transmission resources and path resources are configured, the bandwidth

constraints at the convergence points are unavailable. As shown in Figure 4-3, the total

available bandwidth BW0 is known, but the values of BW1 through BW4 are unknown.

Thus, the admission algorithm does not work properly. For example, if the total reserved

bandwidth at NB2 exceeds BW2, congestion and packet loss may occur and in the

downlink, the total volume of data sent to NB2 may exceed BW2.




property name.)


name.

4-5

Figure 4-3 Iub transmission convergence

RAN sharing

Operators share the bandwidth at one NodeB. In this case, the bandwidth needs to be

configured for each operator so that the bandwidth used by each operator does not

exceed their respective reserved bandwidth. If only physical transmission resources and

path resources are configured, such a requirement fails to be fulfilled.

To solve the preceding problems, the Logical Port (LP) concept is introduced to the TRM

feature. LPs are used for bandwidth configuration at transport nodes and for bandwidth

admission and traffic shaping, so as to prevent congestion.

An LP describes the bandwidth constraints between paths or between other LPs.

An LP can be comprised of only paths. Such an LP is called a leaf LP. A physical port

can be a leaf LP.

An LP can also be comprised of only other LPs. Such an LP is called a hub LP. A

physical port can be a hub LP.

One key characteristic of LPs is the bandwidth. For an LP, the uplink bandwidth can be

different from the downlink bandwidth.

LPs at the RNC can be classified into the following types:

ATM LP: used for bandwidth admission and traffic shaping. Multiple levels of ATM LPs

are supported.

IP LP: used for bandwidth admission and traffic shaping. Only one level of IP LP is

supported.

Transmission resource group: used for admission only and applicable to ATM and IP

transport. Multiple levels of transmission resource groups are supported.

On the RNC side, LPs cannot contain transmission resource groups, and transmission

resource groups cannot contain LPs either.

LPs need to be configured on both the RNC and NodeB sides.

LPs are configured on the RNC side for the following purposes:




property name.)


name.

4-6

Admission control in convergence or RAN sharing scenario

Traffic shaping in the downlink

LPs are configured on the NodeB side for the following purposes:

Fairness between local data and forwarded data in convergence scenario

Traffic shaping in RAN sharing scenario

4.3.2 ATM LP at the RNC

ATM LPs, also called Virtual Ports (VPs), have the functions of ATM traffic shaping and

bandwidth admission. They are configured on ATM interface boards by running the ADD

ATMLOGICPORT command. These LPs have the following attributes:

Type of LP, that is, hub or leaf

Bandwidth: The downlink bandwidth is used for traffic shaping and bandwidth

admission, and the uplink bandwidth is used for bandwidth admission only.

Resource management mode, that is, SHARE or EXCLUSIVE: indicates whether

operators in RAN sharing scenario share the Iub transmission resources.

When the ADD AAL2PATH, ADD SAALLNK, or ADD IPOAPVC command is executed

to add an AAL2 path, an SAAL link, or an IPoA PVC respectively, the path, link, or PVC can

be set to join an LP.

The RNC supports multi-level shaping (a maximum of five levels), which involves both leaf

LPs and hub LPs.

In the case of ATM traffic convergence, LPs need to be configured for each NodeB and at

each convergence point, so as to implement bandwidth admission and traffic shaping.

Take the convergence shown in Figure 4-4 as an example.




property name.)


name.

4-7

Figure 4-4 Traffic convergence at LPs

NB = NodeB BW = bandwidth BW0 = bandwidth of the physical port on the RNC

The leaf LPs, that is, LP1, LP2, LP3, and LP4, have a one-to-one relation with the

NodeBs. The bandwidth of each leaf LP is equal to the Iub bandwidth of each

corresponding NodeB.

The hub LP, that is, LP125, corresponds to the hub NodeB, and the LPs connected to the

hub LP correspond to the NodeBs on the network. The bandwidth of the hub LP is equal

to the Iub bandwidth of the hub NodeB.

The actual rate at a leaf LP is limited by the bandwidth of the leaf LP and the scheduling

rate at the hub LP and physical port.

In the Call Admission Control (CAC) algorithm, the reserved bandwidth of a leaf LP is

limited by not only the bandwidth of the leaf LP but also the bandwidth of the hub LP

and the bandwidth of the physical port. That is, the total reserved bandwidth of all the

LPs under a hub LP cannot exceed the bandwidth of the hub LP.

In RAN sharing scenario, an LP needs to be configured for each operator that uses the NodeB.

Table 4-3 describes the ATM LP capabilities of interface boards at the RNC.

Table 4-3 ATM LP capabilities of interface boards at the RNC

Board Number of LPs Level of LPs

AEUa Leaf LP: 0 to 127

Hub LP: 128 to 191

Five




property name.)


name.

4-8

Board Number of LPs Level of LPs

AOUa Leaf LP: 0 to 255

Hub LP: 256 to 383

Five

UOIa_ATM Leaf LP: 0 to 383

Hub LP: 384 to 447

Five

4.3.3 IP LP at the RNC

IP LPs have the functions of IP traffic shaping and bandwidth admission. They are configured

on IP interface boards by running the ADD IPLOGICPORT command. These LPs have the

following attributes:

Bandwidth: The downlink bandwidth is used for traffic shaping and bandwidth

admission, and the uplink bandwidth is used for bandwidth admission only.

Resource management mode, that is, SHARE or EXCLUSIVE: indicates whether

operators in RAN sharing scenario share the Iub transmission resources.

When the ADD IPPATH or ADD SCTPLNK command is executed to add an IP path or an

SCTP link respectively, the path or link can be set to join an LP.

IP LPs are similar to ATM LPs in terms of principles and application. The current version of

RAN supports only one level of IP LP.

Table 4-4 describes the IP LP capabilities of interface boards at the RNC.

Table 4-4 IP LP capabilities of interface boards at the RNC

Board Number of LPs Level of Shaping

PEUa None One-level shaping at PPP or MLPPP ports

FG2a 0 to 119 Two-level shaping at LPs and Ethernet ports

GOUa 0 to 119 Two-level shaping at LPs and Ethernet ports

UOIa 0 to 119 One-level shaping at PPP ports

POUa None One-level shaping at PPP or MLPPP ports

4.3.4 Resource Group at the RNC

Resource groups have the bandwidth admission function but do not have the traffic shaping

function. To add a resource group, run the ADD RSCGRP command.

4.3.5 ATM LP at the NodeB

ATM LPs at the NodeB have the function of ATM traffic shaping. To configure an ATM LP,

run the ADD RSCGRP command to add an ATM resource group to the interface board at the

NodeB. The LP has attributes such as the TX bandwidth, RX bandwidth, bearing port type,

and bearing port number. The TX bandwidth is used for traffic shaping, and the RX




property name.)


name.

4-9

bandwidth is used to calculate the remaining bandwidth for backpressure. Then, when the

ADD AAL2PATH, ADD SAALLNK, or ADD OMCH command is executed to add an

AAL2 path, an SAAL link, or an OM channel respectively, the path, link, or channel can be

set to join an LP.

ATM LPs at the NodeB are mainly used to differentiate operators in RAN sharing scenario.

Each interface board of the NodeB supports a maximum of four ATM LPs.

4.3.6 IP LP at the NodeB

IP LPs at the NodeB have the function of IP traffic shaping. To configure an IP LP, run the

ADD RSCGRP command to add an IP resource group to the interface board at the NodeB.

The LP has attributes such as the TX bandwidth, RX bandwidth, bearing port type, and

bearing port number. The TX bandwidth is used for traffic shaping, and the RX bandwidth is

used to calculate the remaining bandwidth for backpressure. Then, when the ADD IPPATH

command is executed to add an IP path, that is, a path carrying the data traffic of the local

NodeB, the path can be set to join an LP; when the ADD IP2RSCGRP command is executed,

the signaling traffic and the forwarded data traffic can be set to join an LP.

IP LPs at the NodeB are mainly used to differentiate operators in RAN sharing scenario.

Each interface board of the NodeB supports a maximum of four IP LPs.

4.4 Path Resources

Path resources involve those on the control plane, user plane, and management plane. The

paths on the user plane, that is, AAL2 paths for ATM transport and IP paths for IP transport,

are key resources. The allocation and management of transmission resources are based on

paths.

4.4.1 AAL2 Path

In ATM transport mode, the following types of AAL2 path can be configured:

CBR

RT-VBR

NRT-VBR

UBR

UBR+

When an AAL2 path is configured, the TXTRFX and RXTRFX parameters need to be set.

They determine the type of path. The traffic record indexes are configured by running the

ADD ATMTRF command.

4.4.2 IP Path

IP paths can be categorized into the following classes:

High-quality class

Low-quality class

The low-quality class, denoted LQ_xx, is applicable to only hybrid IP transport.




property name.)


name.

4-10

IP paths can be further classified into QoS path and non-QoS path.

The Per Hop Behavior (PHB) of QoS paths is determined by the TRM mapping

configuration.

The PHB of non-QoS paths is determined by the type of path.

Table 4-5 lists the types of IP path.

Table 4-5 Types of IP path

Type High-Quality Class Low-Quality Class

QoS path QoS LQ_QoS

Non-QoS path BE LQ_BE

AF11 LQ_AF11

AF12 LQ_AF12

AF13 LQ_AF13

AF21 LQ_AF21

AF22 LQ_AF22

AF23 LQ_AF23

AF31 LQ_AF31

AF32 LQ_AF32

AF33 LQ_AF33

AF41 LQ_AF41

AF42 LQ_AF42

AF43 LQ_AF43

EF LQ_EF

On the Iu-PS interface, even if IPoA transport is used, IP paths still need to be configured.

HSDPA and HSUPA services can be carried on the same IP path, with HSDPA services in the

downlink and HSUPA services in the uplink.

4.5 Priorities

At each ATM port (such as IMA, UNI, or fractional ATM port) or leaf LP of the RNC, there

are five types, as shown in Figure 4-5. The scheduling order is as follows: CBR > RT-VBR >

MCR of UBR+ > NRT-VBR > UBR > UBR+.

NOTE




property name.)


name.

4-11

Figure 4-5 Priorities at each ATM port of the RNC

At each IP port (such as PPP/MLPPP port) or LP of the RNC, there are six types, as shown

in Figure 4-6. The default scheduling order is as follows: Queue1 > Queue2 > WRR (Queue3,

Queue4, Queue5, Queue6), where WRR refers to Weighted Round Robin.

Figure 4-6 Priorities at each IP port of the RNC

At each ATM port (such as IMA, UNI, or fractional ATM port) or LP of the NodeB, there are

four types, as shown in Figure 4-7. The scheduling order is as follows: CBR or MCR of

UBR+ > RT-VBR > NRT-VBR > UBR or UBR+.

Figure 4-7 Priorities at each ATM port of the NodeB

At each IP port (such as Ethernet port or PPP/MLPPP port) or LP of the NodeB, there are six

types, as shown in Figure 4-8. The default scheduling order is as follows: Queue1 > WFQ

(Queue2, Queue3, Queue4, Queue5, Queue6), where WFQ refers to Weighted Fair Queuing.




property name.)


name.

4-12

Figure 4-8 Priorities at each IP port of the NodeB




property name.)


name.

5-1

5 TRM Mapping

The transport network can provide differentiated QoS services, and the QoS requirements of

traffic vary according to the traffic types. TRMMAP refers to the mapping from traffic bearers

to transport bearers.

The RNC supports configuration of mapping to transport bearers according to the

characteristics of traffic.

Figure 5-1 shows the TRM mapping.

Figure 5-1 TRM mapping




property name.)


name.

5-2

5.1 Traffic Bearer

The prerequisite for TRM algorithms is the guarantee of QoS. Different types of service have

different QoS requirements.

For the Iub control plane and the Uu signaling, reliable transmission is required. The

factors such as the frame loss rate and delay will affect KPIs such as the connection

delay, handover success rate, access success rate, and call drop rate.

For R99 services, excessive delay and jitter must be avoided. Otherwise, the time

window will be adjusted frequently.

For CS services, there are requirements for the delay and frame loss rate. For example,

the end-to-end latency of voice services affects the Mean Opinion Score (MOS); Video

Phone (VP) services are closely sensitive to packet loss.

BE services are relatively insensitive to the delay, but they still have delay specifications

for ping commands. When the load is light, the delay requirement must be fulfilled.

When the load is heavy, the delay requirement can be lowered to a certain extent so as to

guarantee the throughput.

Traffic types are defined as follows:

From the narrow perspective, traffic types are determined by the traffic class at the radio

network layer and the type of radio bearer.

From the broad perspective, traffic types are determined jointly by the traffic class, type

of radio bearer, ARP, and THP. Traffic bearers are used to describe the traffic types in the

broad sense only. These traffic types are further classified according to user priorities, for

the purpose of better differentiated services.

The mapping from traffic types to transmission resources takes the following factors into

consideration:

Traffic class at the radio network layer: conversational, streaming, interactive, and

background, in descending order of QoS requirement.

The RNC provides the following traffic classes that can be used in TRMMAP

configuration:

− Common channel

− SRB

− SIP

− AMR speech

− CS conversational

− CS streaming

− PS conversational

− PS streaming

− PS interactive

− PS background

Type of radio bearer: R99, HSDPA, and HSUPA. R99 bearers have certain requirements

for the delay because of the time window mechanism. HSPA bearers, however, have

relatively low requirements for the delay because of the absence of the time window

mechanism on the Iub interface.

ARP: Even for traffic of the same type, the QoS requirements of different users vary.

Thus, high-priority services may require high-QoS transport bearers at the transport layer.




property name.)


name.

5-3

THP: For interactive services, such as PS interactive services, THP parameters are

available. There are three classes of THP: high, medium, and low.

In summary, the inputs to TRMMAP are the traffic class, type of radio bearer, user priority

and ARP, and THP. That is, each combination of these inputs corresponds to one priority of

transport bearer.

5.2 Transport Bearer

5.2.1 Type of Path

Paths are defined for the purpose of preventing the impact of different types of interface

boards and different traffic queues at the physical layer. The transport bearer service refers to

the service of transmitting traffic over paths of specific types. For path types, see section 4.4

"Path Resources."

5.2.2 DiffServ and DSCP

Differentiated Services (DiffServ) is a key technology adopted in IP transport to improve the

network QoS. The QoS information, that is, the Differentiated Services Code Point (DSCP), is

carried in the header of each IP packet to inform the nodes on the network of the QoS

requirement. Through the DSCP, each router on the propagation path knows which type of

service is desired.

When entering the network, traffic is differentiated and applied with flow control according to

the QoS requirement. In addition, the DSCP fields of the packets are set. On the network, the

QoS mechanism differentiates traffic and QoS requirements according to the DSCP values

and also provides services for the traffic. The services include resource allocation, queue

scheduling, and packet discard policies, which are collectively called PHB. All nodes within

the DiffServ domain implement PHB according to the DSCP field in each packet.




property name.)


name.

5-4

Figure 5-2 DSCP field in an IP packet

The DSCP mechanism employed at the RNC is as follows: The traffic carried on QoS paths

uses the DSCPs mapped from services, whereas the traffic carried on non-QoS paths uses the

DSCPs corresponding to the type of IP path, that is, PHB. The mapping from PHB to DSCP

can be set by running the SET PHBMAP command.

Value range of DSCP: 0 to 63. Each DSCP corresponds to a PHB attribute.

Value range of PHB: BE, AF11, AF12, AF13, AF21, AF22, AF23, AF31, AF32, AF33,

AF41, AF42, AF43, and EF, in ascending order of priority.

QoS paths are recommended, because of simple configuration and better implementation of

multiplexing, QoS guarantee, and service differentiation.

5.3 Mapping from Traffic Bearers to Transport Bearers

For the mapping from traffic bearers to transport bearers, both the default configuration and

the adjacent-node-oriented configuration are available.

The keyword used for configuring TRMMAP is the traffic type, that is, the combination of

traffic class, type of radio bearer, and THP. Primary and secondary paths can be configured.

For details about primary and secondary paths, see section 6.3 "Admission Control."

5.3.1 RNC-Oriented Default Mapping

The RNC provides default mapping tables with IDs from 0 to 8 for Iub ATM, Iub IP, Iub

ATM&IP, Iub hybrid IP, Iur ATM, Iur IP, Iu-CS ATM, Iu-CS IP, and Iu-PS respectively. These

tables can only be queried by running the LST TRMMAP command.

Table 5-1 lists the default TRMMAP tables.




property name.)


name.

5-5

Table 5-1 Default TRMMAP tables

Interface ATM IP ATM&IP Hybrid IP

Iub 0 1 2 3

Iur 4 5

Iu-CS 6 7

Iu-PS 8

The RNC-oriented default TRM mapping is not specific for operators or user priorities. If no adjacent-

node-oriented mapping is configured, the RNC-oriented default TRM mapping applies.

Configuration of TRM Mapping

For details, see chapter 10 "Appendix."

Configuration of DSCP Mapping

Table 5-2 lists the default mapping from PHB to DSCP.

Table 5-2 Default mapping from PHB to DSCP

PHB DSCP (Binary) DSCP (Decimal)

EF 101110 46

AF43 100110 38

AF42 100100 36

AF41 100010 34

AF33 11110 30

AF32 11100 28

AF31 11010 26

AF23 10110 22

AF22 10100 20

AF21 10010 18

AF13 1110 14

AF12 1100 12

AF11 1010 10

If the mapping from PHB to DSCP is not configured by running the SET PHBMAP

command, the default mapping applies.

NOTE




property name.)


name.

5-6

If the traffic is carried on a non-QoS IP path, the DSCP corresponding to the path type is

used.

If the traffic is carried on a QoS IP path, the DSCP is determined by the mapping (that is,

the PHBMAP) from the PHB, which is further determined by the mapping (that is, the

TRMMAP) from traffic classes to QoS paths. Thus, the user needs to configure only one

QoS path before obtaining diversified mapping from different traffic classes and user

priorities to different DSCPs.

5.3.2 Adjacent-Node-Oriented Mapping

To provide better differentiated services, the RNC supports configuration of TRMMAP for

adjacent nodes and even for a specific operator and a specific user priority at a specific

adjacent node. This helps achieve flexible configuration of mapping from traffic bearers to

transport bearers.

To configure the mapping for an adjacent node, perform the following steps:

Step 1 Run the ADD TRMMAP command to specify the mapping from the traffic classes of a

specific interface type and transport type to the transport bearers.

Step 2 Run the ADD ADJMAP command to reference the configured TRMMAP tables for the

adjacent node. In this step, the TRMMAP tables need to be individually specified for Gold,

Silver, and Copper users.

In RAN sharing scenario, if the resource management mode is set to EXCLUSIVE, the operator index

needs to be set so as to specify the TRMMAP for the users of that operator at the adjacent node.

The related commands are ADD TRMMAP, MOD TRMMAP, ADD ADJMAP, and MOD ADJMAP.

----End

NOTE




property name.)


name.

6-1

6 Load Control

The load control algorithm allocates transmission resources to services, manages the

transmission bandwidth, and controls the transmission load for the purpose of allowing access

of users to the maximum extent without affecting the QoS.

6.1 Definition of Load

The load control algorithm is implemented at the RNC, and therefore, the load is defined and

measured at the RNC. The definition of load is based on the reserved bandwidth. The load

control algorithm reserves bandwidth for each service. The load refers to the sum of

bandwidth reserved for all services. The uplink load and downlink load are calculated

separately.

The load of each path and that of each LP (including leaf LP and hub LP) need to be

calculated. The load definitions are as follows:

Load of a path: sum of bandwidth reserved for all services on the path

Load of a leaf LP: total load of all paths carried on the LP

Load of hub LP: total load of all LPs under the hub LP

6.2 Bandwidth Reserved for Services

The load is defined on the basis of the bandwidth reserved for each service. Therefore, the

method of calculating the bandwidth reserved for each type of service must be provided.

Bandwidth reserved for a service = Transport-layer rate of the service x Activity factor, where

the transport-layer rate of the service derives from the rate that the user applies for.

The RNC calculates the reserved bandwidth based on the activity factor and performs

admission control based on the reserved bandwidth, thus enabling Iub overbooking, that is,

allowing admission of more services to the bandwidth. The more the services admitted, the

higher the statistical multiplexing gain.

After activity factors are taken into consideration, a larger number of users can access the

network over the Iub interface. In this case, however, the Iub congestion probability increases

accordingly. If all services are transmitted at the rate higher than their respective admission

bandwidth at the same time, congestion and packet loss occur on the Iub interface. Then, the




property name.)


name.

6-2

user experience deteriorates and the Iub bandwidth usage decreases. To solve the possible

congestion problem, the Iub interface requires the related congestion control algorithm. For

details, see section 7.3 "Congestion Control of Iub User Plane."

The following bandwidth reservation policies apply:

RT services, including conversational and streaming services, are admitted at the

Maximum Bit Rate (MBR).

− The bandwidth for RT services must be guaranteed. RT services do not allow packet

loss or large-volume data buffering.

− The activity of RT services follows an obvious rule. When multiple services access

the network, the total actual traffic volume is relatively stable. The appropriate setting

of activity factors can help achieve correct admission of the services.

− RT services should be admitted on the basis of the average actual traffic volume, so

that the number of users allowed to access the network can be increased to the

maximum extent under the condition that the QoS is guaranteed.

− Reserved bandwidth for admission of an RT service = MBR x Activity factor, where

the activity factor needs to be set for each type of service.

NRT services, including interactive and background services, are admitted at the GBR.

− NRT services do not have strict requirements for bandwidth guarantee. When

resources are insufficient, the traffic throughput can be lowered at the application

layer through data buffering, to which the application layer can be adaptive.

− The activity of NRT services does not follow any obvious rule. When multiple

services access the network, the total actual traffic volume fluctuates greatly.

Therefore, it is difficult to estimate the exact bandwidth used by NRT services.

− If a large number of users access the network, the bandwidth efficiency is improved

to a certain extent, but congestion and packet loss occur. If a small number of users

access the network, the bandwidth efficiency is low.

− If no appropriate user plane congestion control algorithm is available for preventing

congestion and packet loss, the services should be admitted at the MBR multiplied by

the activity factor. The MBR, however, needs to be adjusted frequently in the

interests of high bandwidth efficiency and a large number of users accessing the

network. Thus, a complicated user plane load algorithm is required.

− Huawei has developed a complete user plane congestion control algorithm, in which

the only condition of transmission admission is to provide GBR guarantee for users.

The principle is to allow access of users to the maximum extent under the condition

that the GBR is guaranteed. That is, the admission algorithm can reserve the

bandwidth for users based on the GBR.

In terms of 3G signaling, SRB services can be admitted at either the GBR or 3.4 Kbit/s.

− Admission at 3.4 Kbit/s: The bandwidth is fixed at 3.4 Kbit/s. This admission mode is

applicable to R99, HSDPA, and HSUPA services.

− Admission at the GBR: For R99 services, if the bandwidth of a transport channel

varies between 3.4 Kbit/s and 13.6 Kbit/s, resource allocation and resource admission

do not need to be performed again.

In terms of common channels, EFACH services are admitted at the GBR, and other

common channel services are admitted at the MBR.

Because of the discontinuity of traffic, there are active periods, during which data is

transmitted, and inactive periods, during which data is not transmitted. Activity factors are

used by the admission control to achieve better utilization of transmission resources.




property name.)


name.

6-3

Activity factors are applicable to the Iub, Iur, Iu-CS, and Iu-PS interfaces. The number of

users that can access the network is related to the activity factors.

For common channels or SRBs, the activity factors are identical for all users, instead of

varying according to user priorities.

Activity factors can be configured for different types of service by running the ADD

TRMFACTOR command. Table 6-1 lists the default settings of activity factors for different

types of service.

Table 6-1 Default settings of activity factors for different types of service

Type of Service UL/DL Default Activity Factor (%)

General common channel DL 70

General common channel UL 70

IMS SRB DL 15

IMS SRB UL 15

MBMS common channel DL 100

SRB DL 15

SRB UL 15

AMR voice DL 70

AMR voice UL 70

R99 CS conversational DL 100

R99 CS conversational UL 100

R99 CS streaming DL 100

R99 CS streaming UL 100

R99 PS conversational DL 70

R99 PS conversational UL 70

R99 PS streaming DL 100

R99 PS streaming UL 100

R99 PS interactive DL 100

R99 PS interactive UL 100

R99 PS background DL 100

R99 PS background UL 100

HSDPA SRB DL 50

HSDPA IMS SRB DL 15

HSDPA voice DL 70




property name.)


name.

6-4

Type of Service UL/DL Default Activity Factor (%)

HSDPA conversational DL 70

HSDPA streaming DL 100

HSDPA interactive DL 100

HSDPA background DL 100

HSUPA SRB UL 50

HSUPA IMS SRB UL 15

HSUPA voice UL 70

HSUPA conversational UL 70

HSUPA streaming UL 100

HSUPA interactive UL 100

HSUPA background UL 100

EFACH channel DL 20

When the adjacent-node-oriented mapping is added or modified by running the ADD

ADJMAP or MOD ADJMAP command respectively, the activity factor table to be

referenced can be specified by the FTI parameter.

For BE services, the GBR can be set by running the SET USERGBR command. The

associated parameters are as follows:

TrafficClass

THPClass

BearType

UserPriority

UlGBR

DlGBR

6.3 Admission Control

Admission control is used to determine whether the system resources are sufficient for the

network to accept the access request of a new user. If the system resources are sufficient, the

access request is accepted; otherwise, the request is rejected.

6.3.1 Admission Control Algorithm

The admission policy varies according to the type of user.

For a new user, the following requirements apply:

− Admission to a path:




property name.)


name.

6-5

Load of the path + Bandwidth required by the user < Total configured bandwidth of

the path – Bandwidth reserved for handover

− Admission to an LP: (The admission to LPs should be performed level by level. The

following requirement is applicable to each level of LP.)

Load of the LP + Bandwidth required by the user < Total bandwidth of the LP –

Bandwidth reserved for handover

For handover of a user, the following requirements apply:



the path



Load of the LP + Bandwidth required by the user < Total bandwidth of the LP

For rate upsizing of a user, the following requirements apply:



the path – Congestion threshold



Load of the LP + Bandwidth required by the user < Total bandwidth of the LP –

Congestion threshold

For a path that belongs to a path group, admission control must be performed at both the path level

and the path group level.

For an IMA group or MLPPP group, the RNC automatically adjusts the maximum bandwidth

available to the whole group and uses the new admission threshold if the bandwidth of an IMA link

or MLPPP link changes.

Bandwidth reserved for handover ≤ Congestion threshold ≤ Congestion resolving threshold

The congestion threshold and the congestion resolving threshold are used to prevent the ping-

pong effect.

Based on the preceding requirement, the user priorities are as follows:

User requesting handover > New user > User requesting rate upsizing

The congestion thresholds are FWDCONGBW and BWDCONGBW, and the congestion

resolving thresholds are FWDCONGCLRBW and BWDCONGCLRBW.

The parameters that are used to reserve bandwidth for handover are as follows:

FWDHORSVBW

BWDHORSVBW

6.3.2 Load Balancing

In the admission control mechanism, load balancing is an algorithm used to achieve the load

balance between primary and secondary paths. A service is not always preferably admitted to

the primary path. If the load of the primary path exceeds its load threshold and the ratio of

primary path load to secondary path load is higher than the load ratio threshold, then the

NOTE




property name.)


name.

6-6

service is preferably admitted to the secondary path, so as to improve the resource usage and

user experience.

The load of a path is calculated as follows:

PathLoad = PortUsed ÷ PortAvailable x 100%

where:

PathLoad refers to the load of the path.

PortUsed refers to the total bandwidth of the admitted services at the physical port.

PortAvailable refers to the total available bandwidth at the physical port, including the

used bandwidth.

When the primary path for a type of service exists at more than one physical port, PortUsed

and PortAvailable refer to the sum of used bandwidth and the sum of available bandwidth at

these ports respectively.

Load balancing tables can be configured by running the ADD LOADEQ command. Each

table contains primary path load thresholds and primary-to-secondary path load ratio

thresholds. The combination of a primary path load threshold and a path load ratio threshold

can vary depending on the traffic type. In addition, the ARP needs to be taken into

consideration. After the load balancing tables are configured, they can be referenced when

load balancing parameters need to be set for ATM&IP- or hybrid-IP-based Iub adjacent nodes

by running the ADD ADJMAP or MOD ADJMAP command.

The load balancing application policy is similar to the TRMMAP policy. If the reference for

load balancing tables is not set for the adjacent node, the default load balancing table applies.

The table with the index 0 is the default one. It can only be queried by running the LST

LOADEQ command.

Table 6-2 lists the default settings of load and load ratio thresholds for different types of

service.

Table 6-2 Default settings of load and load ratio thresholds for different types of service

Threshold Default Value

Primary path load threshold for common channel 100

Primary-to-secondary path load ratio threshold for common channel 0

Primary path load threshold for IMS SRB 100

Primary-to-secondary path load ratio threshold for IMS SRB 0

Primary path load threshold for SRB 100

Primary-to-secondary path load ratio threshold for SRB 0

Primary path load threshold for AMR voice 100

Primary-to-secondary path load ratio threshold for AMR voice 0

Primary path load threshold for R99 CS conversational 100

Primary-to-secondary path load ratio threshold for R99 CS

conversational

0




property name.)


name.

6-7


Primary path load threshold for R99 CS streaming 100

Primary-to-secondary path load ratio threshold for R99 CS streaming 0

Primary path load threshold for R99 PS conversational 100

Primary-to-secondary path load ratio threshold for R99 PS

conversational

0

Primary path load threshold for R99 PS streaming 100

Primary-to-secondary path load ratio threshold for R99 PS streaming 0

Primary path load threshold for R99 PS high-priority interactive 30

Primary-to-secondary path load ratio threshold for R99 PS high-

priority interactive

100

Primary path load threshold for R99 PS medium-priority interactive 30

Primary-to-secondary path load ratio threshold for R99 PS medium-


100

Primary path load threshold for R99 PS low-priority interactive 30

Primary-to-secondary path load ratio threshold for R99 PS low-


100

Primary path load threshold for R99 PS background 30

Primary-to-secondary path load ratio threshold for R99 PS

background

100

Primary path load threshold for HSDPA SRB 100

Primary-to-secondary path load ratio threshold for HSDPA SRB 0

Primary path load threshold for HSDPA IMS SRB 100

Primary-to-secondary path load ratio threshold for HSDPA IMS SRB 0

Primary path load threshold for HSDPA conversational 100

Primary-to-secondary path load ratio threshold for HSDPA

conversational

0

Primary path load threshold for HSDPA streaming 100

Primary-to-secondary path load ratio threshold for HSDPA streaming 0

Primary path load threshold for HSDPA high-priority interactive 30

Primary-to-secondary path load ratio threshold for HSDPA high-


100

Primary path load threshold for HSDPA medium-priority interactive 30

Primary-to-secondary path load ratio threshold for HSDPA medium-


100




property name.)


name.

6-8


Primary path load threshold for HSDPA low-priority interactive 30

Primary-to-secondary path load ratio threshold for HSDPA low-


100

Primary path load threshold for HSDPA background 30

Primary-to-secondary path load ratio threshold for HSDPA

background

100

Primary path load threshold for HSUPA SRB 100

Primary-to-secondary path load ratio threshold for HSUPA SRB 0

Primary path load threshold for HSUPA IMS SRB 100

Primary-to-secondary path load ratio threshold for HSUPA IMS SRB 0

Primary path load threshold for HSUPA conversational 100

Primary-to-secondary path load ratio threshold for HSUPA

conversational

0

Primary path load threshold for HSUPA streaming 100

Primary-to-secondary path load ratio threshold for HSUPA streaming 0

Primary path load threshold for HSUPA high-priority interactive 30

Primary-to-secondary path load ratio threshold for HSUPA high-


100

Primary path load threshold for HSUPA medium-priority interactive 30

Primary-to-secondary path load ratio threshold for HSUPA medium-


100

Primary path load threshold for HSUPA low-priority interactive 30

Primary-to-secondary path load ratio threshold for HSUPA low-

priority interactive 100

Primary path load threshold for HSUPA background 30

Primary-to-secondary path load ratio threshold for HSUPA

background

100

6.3.3 Admission Procedure

Primary and secondary paths are used in admission control. According to the mapping from

traffic types to transmission resources, the RNC calculates the load of the primary and

secondary paths and then determines whether to select the primary or secondary path as the

preferred path for admission based on the settings of the primary path load threshold and

primary-to-secondary path load ratio threshold. If the admission to the preferred path fails,

then the admission to the non-preferred path is performed. For details about the mapping from

traffic types to transmission resources, see chapter 5 "TRM Mapping."




property name.)


name.

6-9

For example, assume that secondary paths are available for new users, handover of users, and

rate upsizing of users and that the RNC selects primary paths as preferred paths for admission

of the new users and handover of users (the procedures of admission with secondary paths

preferred are the same). The following procedures describe the admission of these users on

the Iub interface respectively.

The admission procedure for a new user is as follows:

Step 1 The new user attempts to be admitted to available bandwidth 1 on the primary path, as shown

in Figure 6-1.

Step 2 If the user succeeds in applying for the resources on the primary path, the user is admitted to

the primary path.

Step 3 If the user fails to apply for the resources on the primary path, the user then attempts to be

admitted to available bandwidth 2 on the secondary path, as shown in Figure 6-1.

Step 4 If the user succeeds in applying for the resources on the secondary path, the user is admitted

to the secondary path. If the user fails, the bandwidth admission request of the user is rejected.

----End

Figure 6-1 Admission procedure for a new user

Available bandwidth 1 = Total bandwidth of the primary path – Used bandwidth – Bandwidth reserved for handover

Available bandwidth 2 = Total bandwidth of the secondary path – Used bandwidth – Bandwidth reserved for handover

The admission procedure for handover of a user is as follows:

Step 1 The user attempts to be admitted to available bandwidth 1 on the primary path, as shown

in Figure 6-2.

Step 2 If the user succeeds in applying for the resources on the primary path, the user is admitted to

the primary path.

Step 3 If the user fails to apply for the resources on the primary path, the user then attempts to be

admitted to available bandwidth 2 on the secondary path, as shown in Figure 6-2.

Step 4 If the user succeeds in applying for the resources on the secondary path, the user is admitted

to the secondary path. If the user fails, the bandwidth admission request of the user is rejected.

----End




property name.)


name.

6-10

Figure 6-2 Admission procedure for handover of a user

Available bandwidth 1 = Total bandwidth of the primary path - Used bandwidth

Available bandwidth 2 = Total bandwidth of the secondary path - Used bandwidth

The admission procedure for rate upsizing of a user is as follows:

Step 1 The user attempts to be admitted to available bandwidth 1 on the bearing path of the user (that

is, the primary path in this example), as shown in Figure 6-3.

Step 2 If the rate upsizing on the bearing path is successful, the traffic of the user is still carried on

the path.

Step 3 If the rate upsizing on the bearing path fails, the user attempts to be admitted to available

bandwidth 2 on the preferred path (that is, the secondary path in this example, as determined

by the load balancing algorithm), as shown in Figure 6-3.

Step 4 If the user succeeds in applying for the resources on the preferred path, the user is admitted to

the preferred path. If the user fails, it attempts to be admitted to the non-preferred path (that is,

another primary path in this example).

Step 5 If the rate upsizing on the non-preferred path is successful, the user is admitted to the non-

preferred path. Otherwise, the rate upsizing of the user fails.

----End

Figure 6-3 Admission procedure for rate upsizing of a user

Available bandwidth 1 = Total bandwidth of the primary path – Used bandwidth – Bandwidth reserved against congestion

Available bandwidth 2 = Total bandwidth of the secondary path – Used bandwidth – Bandwidth reserved against congestion




property name.)


name.

6-11

If no secondary paths are available for the users, the admission is performed only on the primary paths.

6.4 Intelligent Access Control

Intelligent Access Control (IAC) is aimed at improving the access success rate. IAC involves

the following procedures: rate negotiation, CAC, pre-emption, queuing, and Directed Retry

Decision (DRD).

For details about IAC, see the Load Control Parameter Description.

6.5 Load Reshuffling and Overload Control

When the usage of cell resources exceeds the basic-congestion threshold, the cell enters the

basic congestion state. In this case, Load Reshuffling (LDR) is required to reduce the cell load

and increase the access success rate.

The following four resources can trigger the basic congestion of a cell: power resource, code

resource, Iub resources, and NodeB credit resource. This section describes only the Iub

resources. For details about other resources, see the Load Control Parameter Description.

LDR involves the following algorithms:

Iub Congestion Detection

Iub Overload Detection

Congestion and Overload Handling

6.5.1 Iub Congestion Detection

For a path, port, or resource group, the following congestion-related parameters are applicable:

Congestion detection parameters:

− FWDCONGBW

− BWDCONGBW

The default values of the two parameters are 0, which indicates that no congestion

detection will be performed. If the parameters are set to values other than 0, TRM

performs congestion detection according to the settings.

Congestion resolving parameters:

− FWDCONGCLRBW

− BWDCONGCLRBW

These two parameters are used to determine whether the congestion is resolved.

Congestion detection can be triggered in any of the following conditions:

Bandwidth adjustment because of resource allocation, modification, or release

Change in the configured bandwidth or the congestion threshold

Fault in the physical link

Assume that the forward parameters of a port for congestion detection are defined as follows:

NOTE




property name.)


name.

6-12

Configured bandwidth: AVE

Forward congestion threshold: CON

Forward congestion resolving threshold: CLEAR (Note that CLEAR is greater than

CON.)

Used bandwidth: USED

Then, the mechanism of congestion detection for the port is as follows:

Congestion occurs on the port when CON + USED ≥ AVE.

Congestion disappears from the port when CLEAR + USED < AVE.

The congestion detection for a path or a resource group is similar to that for a port.

Generally, congestion thresholds need to be set for only ports or resource groups. If different

types of AAL2 paths or IP paths require different congestion thresholds, the associated

parameters need to be set for the paths as required.

If ATM LPs or IP LPs are configured, congestion control is also applicable to the LPs. The

congestion detection mechanism for the LPs is the same as that for resource groups.

6.5.2 Iub Overload Detection

Overload can be triggered in any of the following conditions:

In ATM IMA networking scenario, an IMA group contains multiple E1s, among which

some E1s are broken whereas others work properly.

In ADSL networking scenario, the available ADSL bandwidth deteriorates abruptly, for

example, from 8 Mbit/s to 1 Mbit/s.

Some links in a link aggregation group are faulty, and thus the available bandwidth of the

group decreases.

Some links in an IP MLPPP group are faulty, and thus the available bandwidth of the

group decreases.

Similar to congestion detection, overload detection is applicable to paths, resource groups,

and ports.

For example: Assume the available bandwidth at a port as AVE and the used bandwidth at the

port as USED. Then, overload occurs when USED > AVE.

6.5.3 Congestion and Overload Handling

Handling on the Iub Interface

If IUB_LDR under the NodeBLdcAlgoSwitch parameter is set to 1 by running the ADD

NODEBALGOPARA or MOD NODEBALGOPARA command,

After the RNC receives a congestion message, the RNC triggers LDR actions. For details

about the LDR actions, see the Load Control Parameter Description.

After the RNC receives an overload message, the RNC triggers Overload Control (OLC)

actions. OLC triggers release of resources used by users in order of comprehensive

priority.




property name.)


name.

6-13

Handling on Other Interfaces The congestion on the Iur interface can trigger Serving Radio Network Subsystem

(SRNS) relocation. For details about SRNS relocation, see the SRNS Relocation

Parameter Description.

During Iu signaling flow control, if congestion is detected on the signaling link towards

the signaling point, the congested state is reported to the RANAP subsystem of the RNC.

Then, the RANAP subsystem discards user messages in the following sequence: short

message service > CS and PS call > registration.




property name.)


name.

7-1

7 User Plane Processing

7.1 Overview of User Plane Processing

The load control algorithm described in the previous chapter is based on the bandwidth

reserved for services. It does not involve the actual processing procedure. This chapter

describes the algorithm for user plane processing. It consists of the following contents:

Hub scheduling and shaping: consists of RNC scheduling and shaping and NodeB

scheduling and shaping. Scheduling is performed to guarantee fairness between NodeBs

in the convergence scenario. Shaping refers to Logical Port (LP) shaping. Shaping is

performed to control the total transmission rate of the RNC and NodeB to prevent

congestion on the transport network.

Congestion control: controls the transmission rate of the NRT service, prevents

congestion due to packet loss on the Iub interface, and provides differentiated services.

Efficiency improvement: improves the transmission efficiency on the Iub interface by

reducing the transmission bandwidth for services.

IP Performance Management (PM): detects that the available bandwidth is provided for

shaping and admission algorithms in IP transport mode.

7.2 Hub Scheduling and Shaping

Hub scheduling and shaping consists of RNC scheduling and shaping and NodeB scheduling

and shaping.

7.2.1 RNC Scheduling and Shaping

The RNC performs scheduling and shaping of user plane data in the downlink direction.

Each port performs the shaping function. The total data transmission rate does not exceed the

bandwidth configured for the port.

The hub LP performs the scheduling function. That is, the hub LP performs scheduling of the

ports contained in the hub LP so that the total transmission rate of all the ports does not

exceed the bandwidth configured for the hub LP. This prevents congestion and packet loss at

the hub node. In addition, the scheduling rate of a port is in direct proportion to the load of the

port, which guarantees fairness between the ports.




property name.)


name.

7-2

7.2.2 NodeB Scheduling and Shaping

The NodeB performs scheduling and shaping of user plane data in the uplink direction.

Each LP performs the shaping function. The total data transmission rate does not exceed the

bandwidth configured for the LP.

The scheduling function is described as follows:

Scheduling in ATM transport mode: When there are multiple LPs or the hub NodeB

needs to transmit the uplink data of the lower-level NodeB, the physical port performs

scheduling of all the PVCs. The PVCs with high priority are dispatched preferentially.

The PVCs with the same priority are dispatched on the basis of the services carried on

the PVCs.

Scheduling in IP transport mode: When there are multiple LPs, the IP physical port

performs Round Robin (RR) scheduling of all the LPs to guarantee fairness between the

LPs.

7.3 Congestion Control of Iub User Plane

Iub congestion control is only applied to the NRT service. Iub congestion control is performed

to control the transmission rate of the NRT service.

The RT service flow is stable, and the demand for resources is relatively regular. Thus,

the load control algorithm is usually adopted to control the resource consumption for the

RT service.

The NRT service flow fluctuates significantly. Therefore, in addition to the admission

control algorithm, you also need to adopt the congestion control algorithm of the user

plane to control the resource consumption for the NRT service.

The fluctuation of the NRT service flow may cause the data flow to be sent on the Iub

interface to exceed the actual available bandwidth. As a result, congestion and packet

loss occur, thus seriously affecting the bandwidth efficiency on the Iub interface.

Therefore, the congestion control algorithm must be adopted to control the total

transmission rate on the Iub interface to prevent congestion and packet loss and to

improve the bandwidth efficiency.

Except to guarantee the total bandwidth efficiency, the congestion control algorithm is applied

to meet the requirement of differentiated NRT services.

Requirement of differentiated NRT services: The bandwidth resources are allocated

among NRT services by proportion based on the service priorities (including service type,

ARP, THP, and radio bearer type) in the case that the GBR of NRT services is guaranteed.

The HSPA scheduling algorithm (including HSDPA and HSUPA scheduling algorithms)

implements differentiated services on the air interface. The details are as follows:

Service-to-SPI mapping: Based on the TC, ARP, and THP, one service is mapped to SPI,

and the corresponding SPI weighting factors are configured. The mapping is configured

on the RNC. The RNC notifies the NodeB of the SPI corresponding to each service

through the NBAP signaling. For details on SPI mapping, see the HSPA Parameter

Description.

Differentiated resource allocation: When the resources on the air interface are limited,

the HSPA scheduling algorithm allocates the total resources among users based on the

SPI weighting factors.




property name.)


name.

7-3

To implement differentiated services in the same way, the Iub congestion control algorithm

also uses SPI weighting factors for implementing differentiated services on the Iub interface.,

that is, the bandwidth is allocated by proportion based on the SPI weighting factors in the case

that the GBR of the service is guaranteed. The differences are as follows:

The HSPA scheduling algorithm is applied to all the HSPA services except R99 services.

The Iub congestion control algorithm is applied only to the NRT services, including

HSPA and R99 services. R99 services adopt the same service-to-SPI mapping

mechanism as that of HSPA services, and SPI weighting factors are set for R99 services.

The HSPA scheduling algorithm is implemented in the NodeB. The downlink Iub

congestion control algorithm is implemented in the RNC. The uplink Iub congestion

control algorithm is implemented on the NodeB side.

The Iub congestion control algorithm must be implemented in the uplink and downlink

directions. It consists of the following algorithms:

RLC (Radio Link Control) retransmission rate-based downlink congestion control

algorithm

Backpressure-based downlink congestion control algorithm

NodeB HSDPA-based adaptive downlink flow control

R99 single service downlink congestion control algorithm

NodeB backpressure-based uplink congestion control algorithm

Transport layer uplink congestion control algorithm

R99 single service uplink congestion control algorithm

7.4 Downlink Iub Congestion Control Algorithm

7.4.1 Overview of the Downlink Iub Congestion Control Algorithm

The downlink congestion control algorithms are of four types, which are described in

Table 7-1.

Table 7-1 Downlink congestion control algorithms

Congestion Control Algorithm

Scenario Service Type

RNC RLC retransmission rate-

based congestion control

algorithm

All networking scenarios R99 service,

HSDPA service,

RLC AM mode

NodeB HSDPA adaptive flow

control algorithm

All networking scenarios HSDPA service

RNC backpressure-based

downlink congestion control

algorithm

Congestion and packet loss in the

RNC. For packet loss at the

transport layer, the shaping

algorithm is also required.

R99 service,

HSDPA NRT

service




property name.)


name.

7-4



RNC R99 single service downlink

congestion control algorithm

All networking scenarios R99 service

The recommended configurations for the downlink congestion control algorithms are as

follows:

The RLC retransmission rate-based congestion control algorithm switch is disabled.

Other algorithm switches are enabled.

In the convergence scenario, the multiple-level LPs are configured if the configuration of

multiple-level LPs is supported.

In the IP transport scenario, the IP PM is enabled if it is supported.

The relations between the four downlink congestion control algorithms are as follows:

Relation between the RNC backpressure-based congestion control algorithm and the

RNC RLC retransmission rate-based congestion control algorithm

− Both the algorithms are implemented in the RNC. Therefore, they may take effect

simultaneously.

− When the backpressure-based congestion control algorithm switch of a service is

enabled, the RLC retransmission rate-based congestion control algorithm switch is

disabled automatically.

Relation between the RNC backpressure-based congestion control algorithm and the

RNC R99 single service congestion control algorithm


simultaneously.

− In the case that backpressure takes effect, the backpressure-based congestion control

algorithm ensures that no packet loss occurs in the RNC. The R99 single service

congestion control algorithm monitors packet loss and reduces the rate only when

congestion occurs on the transport network. Therefore, it has no impact on the

backpressure-based congestion control algorithm. It serves as the supplement in the

case that backpressure does not take effect.

Relation between the RNC R99 single service congestion control algorithm and the RNC

RLC retransmission rate-based congestion control algorithm


simultaneously.

− The R99 single service congestion control algorithm can take the place of the RLC

retransmission rate-based congestion control algorithm. Therefore, when the R99

single service congestion control algorithm takes effect, the RLC retransmission rate-

based congestion control algorithm can be disabled.

Relation between the NodeB HSDPA flow control algorithm and the RNC backpressure-

based congestion control algorithm

The HSDPA flow control algorithm is implemented in the NodeB, and the backpressure-

based congestion control algorithm is implemented in the RNC. Therefore, they may

take effect simultaneously.

− If the NodeB HSDPA flow control algorithm switch is set to NO_BW_SHAPING,

then the two algorithms do not conflict in the case that backpressure takes effect. The




property name.)


name.

7-5

congestion problem on the Iub interface cannot be solved in the case that

backpressure does not take effect.

− If the NodeB HSDPA flow control algorithm switch is set to

DYNAMIC_BW_SHAPING, then the two algorithms conflict in the case that

backpressure takes effect. The NodeB HSDPA flow control algorithm can

independently solve the congestion problem of HSDPA users on the Iub interface in

the case that backpressure does not take effect.

− If the NodeB HSDPA flow control algorithm switch is set to

BW_SHAPING_ONOFF_TOGGLE, then the NodeB flow control policy is

automatically set to DYNAMIC_BW_SHAPING and can independently solve the

congestion problem of HSDPA users in the case that backpressure does not take effect.

The NodeB flow control policy is automatically set to NO_BW_SHAPING in the

case that backpressure takes effect.

Relation between the NodeB HSDPA flow control algorithm and the RNC RLC

retransmission rate-based congestion control algorithm

− The NodeB HSDPA flow control algorithm is excellent. Therefore, the RLC

retransmission rate-based congestion control algorithm of the HSDPA service is not

used.

− When both the algorithms take effect simultaneously, one is applied to R99 services,

and the other is applied to HSDPA services. They do not conflict with each other.

Generally, the priority of R99 services is higher than that of HSDPA services.

Therefore, the rate of HSDPA services is reduced till the rate reaches the minimum

value. In this case, the RLC retransmission rate-based congestion control algorithm

takes effect to limit the rate of R99 services.

Relation between the NodeB HSDPA flow control algorithm and the RNC R99 single

service congestion control algorithm

− The HSDPA flow control algorithm is implemented in the NodeB, and the R99 single

service congestion control algorithm is implemented in the RNC. Therefore, they

may take effect simultaneously.

− When both the algorithms take effect simultaneously, one is applied to R99 services,

and the other is applied to HSDPA services. They do not conflict. The R99 single

service congestion control algorithm aids the NodeB HSDPA flow control algorithm

in solving flow control problems of R99 services.

7.4.2 RNC RLC Retransmission Rate-Based Downlink Congestion Control Algorithm

The RNC RLC retransmission rate-based downlink congestion control algorithm is

implemented in the RNC. It is applied to all the Iub interface boards. Based on the RLC

retransmission rate, it solves the downlink congestion problems of R99 and HSDPA NRT

services.

The prerequisites for implementing the algorithm are as follows:

For the R99 BE service, use the SET CORRMALGOSWITCH command, and set the

DRA_R99_DL_FLOW_CONTROL_SWITCH subparameter of DraSwitch to On.

For the HSDPA BE service, use the SET CORRMALGOSWITCH command, and set

the DRA_HSDPA_DL_FLOW_CONTROL_SWITCH subparameter of DraSwitch to

On.

The algorithm is implemented as follows:




property name.)


name.

7-6

Step 1 The RNC initiates periodic monitoring of the RLC PDU retransmission rate. The monitoring

period is specified by the MoniterPrd parameter. The RNC calculates the retransmission rate

according to the following formula:

Fn = (1 – a) x Fm + a x Mn

Fn: retransmission rate to be calculated

Fm: previously calculated retransmission rate

n = m + 1

Mn: currently measured retransmission rate

a = 0.5

Step 2 When the retransmission rate is higher than EventAThred in a specified continuous period

(TimeToTriggerA x MoniterPrd ), event A is triggered.

For the R99 BE service, the RNC reduces the current transmission rate by 50%.

For the HSDPA BE service, the RNC reduces the current transmission rate by 50%.

After event A is triggered, there is a waiting period (PendingTimeA x MoniterPrd ). In this

period, the RNC stops monitoring the retransmission rate.

Step 3 When the retransmission rate is lower than EventBThred in a specified continuous period

(TimeToTriggerB x MoniterPrd ), event B is triggered.

For the R99 BE service, the RNC increases the current transmission rate by 130%.

For the HSDPA BE service, the RNC increases the current transmission rate by 130%.

After event B is triggered, there is a waiting period (PendingTimeB x MoniterPrd ). In this

period, the RNC stops monitoring the retransmission rate.

The procedure for flow control algorithm 1 of the BE service is shown in Figure 7-1.




property name.)


name.

7-7

Figure 7-1 Procedure for flow control algorithm 1 of the BE service

Through flow control algorithm 1, the transmission rate of the RNC matches the bandwidth

on the Iub interface, as shown in Figure 7-2.

Figure 7-2 BE service flow control in the case of Iub congestion

----End




property name.)


name.

7-8

7.4.3 RNC Backpressure-Based Downlink Congestion Control Algorithm

The RNC backpressure-based downlink congestion control algorithm is implemented in the

RNC. It is applied to downlink congestion of R99 and HSDPA NRT services.


This algorithm is based on backpressure flow control of the interface board. The license

must be obtained according to different network modes, and the Iub overbooking feature

must be activated. The following functions require corresponding licenses:

− ATM Iub overbooking: used for the ATM non-hub network

− Hub Iub overbooking: used for the ATM hub network

− IP Iub overbooking: used for the IP network

The algorithm switch must be enabled.

The FLOWCTRLSWITCH parameter is set to ON, and the FCINDEX parameter

together with the thresholds is used for port flow control. Therefore, the setting of

FLOWCTRLSWITCH is based on the ports.

− For the ATM network, the ports are the UNI link, IMA group, fractional link, LP, and

optical port.

− For the IP network, the ports are the LP, PPP link, MLPPP group, optical port, and

Ethernet port.


Step 1 The interface boards monitor the transmission buffers of the queues on the Iub interface.

The ATM interface board has five queues, and the IP interface board has six queues.

For the IP interface board, the number of queues with absolute priorities can be set through

the PQNUM parameter. The scheduling of queues with absolute priorities depends on the

priorities of special users. The rest queues use the RR scheduling algorithm. The number of

rest queues is equal to 6 minus the value of PQNUM. The RR scheduling is performed

according to the sequence of the queues and then the sequence of the tasks.

Step 2 When the buffer length of a queue is greater than the congestion threshold, the queue enters the

congestion state. When a queue on the port is congested, the port becomes congested

accordingly. The interface boards send congestion signals to the DPUb boards concerned. The

DPUb boards reduce the transmission rate of the BE service to GBR x 10%.

The congestion thresholds are CONGTHD0, CONGTHD1, CONGTHD2, CONGTHD3,

CONGTHD4, and CONGTHD5.

Step 3 When the buffer length of the queue is greater than the packet discarding threshold, the RNC

starts discarding data packets from the buffer.

The packet discarding thresholds are DROPPKTTHD0, DROPPKTTHD1, DROPPKTTHD2,

DROPPKTTHD3, DROPPKTTHD4, and DROPPKTTHD5.

The length of packets discarded from the queue is equal to the packet discarding threshold minus the

congestion threshold.

Step 4 When the buffer length of the queue is smaller than the congestion recovery threshold, the

queue leaves the congestion state. The port is recovered if all the queues on the port leave the




property name.)


name.

7-9

congestion state. The interface boards send congestion resolving signals to the associated

DPUb boards, and the DPUb boards restore the transmission rate of BE users on the port.

The recovery thresholds are CONGCLRTHD0, CONGCLRTHD1, CONGCLRTHD2,

CONGCLRTHD3, CONGCLRTHD4, and CONGCLRTHD5.

The restored rate is r x 95%, where r is the final transmission rate of the user before the user enters

the congestion state.

Step 5 After the BE users leave the congestion state, the RNC increases the transmission rate every 10

ms according to the increasing step until the BE users reach the Maximum Bit Rate (MBR).

The value of MBR is carried on the Radio Access Bearer (RAB) from the Core Network (CN).

The initial increasing step of the transmission rate is 2,000 bit/s x SPI, and the step is doubled at

intervals of 200 ms.

----End

The result of flow control algorithm 2 for the BE service is shown in Figure 7-3.

Figure 7-3 Result of flow control algorithm 2 for the BE service

The other parameters used in flow control algorithm 2 are as follows:

TrafficClass

UserPriority

THP

SPI

BearType

7.4.4 RNC R99 Single Service Downlink Congestion Control Algorithm

The RNC R99 single service downlink congestion control algorithm is implemented in the

RNC. The RNC extends the node synchronization frame to detect congestion in R99 service




property name.)


name.

7-10

transport and thus controls the transmission rate of the downlink R99 service. The RNC

adopts the policy of reducing rate by proportion and increasing rate by absolute rate to ensure

fairness and to implement differentiated services. Therefore, the flow control problems of the

R99 service can be solved.

The prerequisite for implementing the algorithm is that the DLR99CONGCTRLSWITCH

parameter is set to ON.


Step 1 The RNC measures the number of FP packets in real time and sends the downlink node

synchronization frame once a second to implement congestion detection based on the

downlink node synchronization frame.

The downlink node synchronization frame contains the PM packet sequence number and the

number of FP packets sent by the RNC (excluding the number of control frames).

Step 2 The NodeB measures the number of received FP packets in real time, fills the number of FP

packets in the received downlink node synchronization frame, and then generates an uplink

node synchronization frame and sends it to the RNC.

Step 3 If the RNC detects frame loss and congestion of the downlink R99 service after receiving the

uplink node synchronization frame and does not reduce the L2 transmission rate in a period of

time, the RNC reduces the L2 transmission rate by a certain percentage to a rate not smaller

than the GBR.

Step 4 The RNC increases the L2 transmission rate by a certain step every 1.5s to a rate not greater

than the MBR.

The initial increasing step of the transmission rate is 2,000 bit/s x SPI, and the step is doubled

at intervals of 20s.

Step 5 After obtaining the L2 transmission rate, the RNC sends data by using the leaky bucket

algorithm.

----End

7.4.5 NodeB HSDPA Adaptive Flow Control Algorithm

The NodeB HSDPA adaptive flow control algorithm is implemented in the NodeB. It is

applied to the MAC-hs queues of the BE service and streaming service of HSDPA users.

The BE service is less sensitive to delay. The rate fluctuates considerably. When the data

burst occurs, the rate may become very high.

The rate of the steaming service is relatively high, which may lead to congestion on the

Iub interface.

The flow control policy is not used for the SRB, IMS, VoIP, or CS AMR service of

HSDPA users because the amount of data is small and the services are sensitive to delay.

The flow control algorithm solves the Iub congestion problems of HSDPA users in various

scenarios.


The HSDPA MBR reporting switch is set as follows:

− When the switch is set to ON, the RNC sends the user MBR to the NodeB. When the

NodeB MAC-hs flow control entity distributes flow to the users, the rate does not

exceed the MBR.




property name.)


name.

7-11

− When the switch is set to OFF, the Iub MBR reporting function is disabled.

This switch is not configurable. It is set to ON by default.

The NodeB Iub flow control algorithm switch Switch is set as follows:

− When the switch is set to DYNAMIC_BW_SHAPING, the NodeB adjusts the

available bandwidth for HSDPA users based on the delay and packet loss condition

on the Iub interface. Then, considering the rate on the air interface, the NodeB

performs Iub shaping and distributes flow to HSDPA users.

− When the switch is set to NO_BW_SHAPING, the NodeB does not adjust the

bandwidth based on the delay and packet loss condition on the Iub interface. The

NodeB reports the conditions on the air interface to the RNC, and then the RNC

performs bandwidth allocation.

− When the switch is set to BW_SHAPING_ONOFF_TOGGLE, the flow control

policy for the ports of the NodeB is either DYNAMIC_BW_SHAPING or

NO_BW_SHAPING in accordance with the congestion detection mechanism of the

NodeB.

This section describes the flow control policy used when Switch is set to

BW_SHAPING_ONOFF_TOGGLE. The algorithm architecture is shown in Figure 7-4.

Figure 7-4 Dynamic flow control algorithm architecture


Step 1 The congestion status of the transport network is reported to the NodeB through the DRT and

FSN. The NodeB monitors transmission delay and packet loss periodically. If the NodeB

detects no congestion, it increases the HSDPA Iub bandwidth.

NOTE




property name.)


name.

7-12

The Iub frame loss rate threshold is specified by DR. If the detected frame loss rate is

lower than the threshold, no congestion due to packet loss occurs.

The Iub delay congestion threshold is specified by TD. If the detected delay is lower

than the threshold, no congestion due to delay occurs.

If the NodeB detects no congestion in a period of time, it stops the delay detection and

the algorithm switch is set to NO_BW_SHAPING. That is, flow shaping is disabled.

If the NodeB detects congestion due to packet loss, it continues with the delay detection

and the algorithm switch is set to DYNAMIC_BW_SHAPING. That is, the Iub

bandwidth adaptive algorithm and flow shaping are enabled.

Step 2 The NodeB adjusts the HSDPA Iub bandwidth based on the congestion due to delay and

packet loss. The adjusted bandwidth is the input for the Iub shaping function of the NodeB.

Step 3 The NodeB allocates capacity to MAC-hs based on the rate on the Uu interface.

The allocated capacity does not exceed the MBR.

Step 4 Based on the capacity allocated on the Uu interface, the NodeB allocates the Iub bandwidth to

HSDPA users and performs Iub shaping to ensure that the total flow of all the queues does not

exceed the available Iub bandwidth. In this way, Iub interface congestion is controlled, Iub

interface utilization is improved, and overload is prevented.

If the Iub shaping function of the NodeB is disabled, skip this step.

Step 5 The RNC limits the bandwidth for each MAC-hs queue based on the HS-DSCH capacity

allocation result.

----End

7.5 Uplink Iub Congestion Control Algorithm

7.5.1 Overview of the Uplink Iub Congestion Control Algorithm

The uplink congestion control algorithms are of four types, which are described in Table 7-2.

Table 7-2 Uplink congestion control algorithms



NodeB backpressure-based

uplink congestion control

algorithm

The available bandwidth for LPs is

known, and the NodeB boards

support the algorithm.

R99 service and

HSUPA service

NodeB uplink bandwidth

adaptive adjustment algorithm

The bandwidth of various transport

networks is unknown or the

scenarios include ATM convergence,

hub convergence, and slow changes

in the bandwidth of transport

networks.

R99 service and

HSUPA service

RNC R99 single service uplink

congestion control algorithm

All networking scenarios R99 service




property name.)


name.

7-13



NodeB cross-Iur single HSUPA

service uplink congestion

control algorithm

Iur congestion scenario HSUPA service

The recommended configurations for the uplink congestion control algorithms are as follows:

All the algorithm switches are enabled.

In the IP transport scenario, the IP PM is enabled if it is supported.

The relations between the four uplink congestion control algorithms are as follows:

The NodeB backpressure-based uplink congestion control algorithm and the NodeB

uplink bandwidth adaptive adjustment algorithm are implemented in the NodeB. The

RNC R99 single service uplink congestion control algorithm is implemented in the RNC.

These three algorithms may take effect simultaneously.

The result (available bandwidth for LPs) of the NodeB uplink bandwidth adaptive

adjustment algorithm is the input for the NodeB backpressure-based uplink congestion

control algorithm. If the NodeB boards support the NodeB uplink bandwidth adaptive

adjustment algorithm and the NodeB backpressure-based uplink congestion control

algorithm, both the algorithms can be used together to solve the uplink Iub congestion

problems (in direct connection and convergence scenarios). This is the main scheme of

the uplink flow control algorithm.

If the NodeB supports the NodeB backpressure-based uplink congestion control

algorithm and the NodeB uplink bandwidth adaptive adjustment algorithm, the RNC R99

single service uplink congestion control algorithm can control the transmission rate of

UEs based on the backpressure flow control and rate limiting results. They do not

conflict with each other. Otherwise, the RNC R99 single service uplink congestion

control algorithm independently controls the transmission rate of UEs based on the FP

congestion detection results.

If the NodeB supports the NodeB backpressure-based uplink congestion control

algorithm and the NodeB uplink bandwidth adaptive adjustment algorithm, the NodeB

cross-Iur single HSUPA service uplink congestion control algorithm can solve the packet

loss problem due to Iur interface congestion for HSUPA users.

7.5.2 NodeB Backpressure-Based Uplink Congestion Control Algorithm (R99 and HSUPA)

The NodeB backpressure-based uplink congestion control algorithm is implemented in the

NodeB to ensure that there is no congestion due to packet loss in the NodeB. The policy of

reducing rate by proportion and increasing rate by absolute rate is adopted to ensure fairness

between BE services.

The switch of this algorithm is not configurable. It is set to ON by default.

Figure 7-5 shows the principle of the NodeB backpressure-based congestion control algorithm.

NOTE




property name.)


name.

7-14

Figure 7-5 Principle of the NodeB backpressure-based uplink congestion control algorithm


Step 1 The interface boards monitor the transmission buffers of the LPs and queues on the Iub

interface.

When congestion is detected, the interface boards send congestion signals to the DSP

concerned. All the BE users on the DSP enter the congestion state. The transmission rate is

limited but is not lower than the GBR.

For ATM transport or IP transport based on the V1 platform: The algorithm must

calculate a virtual buffer data volume and check whether congestion occurs because LP

shaping is not supported.

− If congestion is detected on the port, all queues are congested.

− If no congestion is detected on the port, the status of the queues must be checked on

the basis of the buffer data of the queues.

For IP transport based on the V2 platform: The algorithm directly checks whether

congestion occurs on the port based on the actually measured buffer usage on the port

because LP shaping is supported. If congestion is detected on the port, the rates of all the

BE users on the port are reduced.

Step 2 When the buffer data volume on the decoding DSP is larger than a certain threshold, some

data packets in the buffer are discarded.

For HSUPA users, the data can be buffered in the decoding DSP for 500 ms and will be

discarded after 500 ms.

For R99 users, the data can be buffered in the decoding DSP for 60 ms and will be

discarded after 60 ms.

Step 3 When the buffer data volume of the LPs and queues is smaller than the congestion recovery

threshold, congestion is resolved. The interface boards send the congestion resolving signals

to the DSP concerned. The BE users on the port leave the congestion state, and the

transmission rates are restored.

Step 4 After the BE users leave the congestion state, the decoding DSP increases the transmission

rate by a certain step every 10 ms until the transmission rate of the BE users reaches the

MBR.




property name.)


name.

7-15


at intervals of 200 ms.

Step 5 The buffer data volume on the decoding DSP is the input for scheduling. The hybrid service

may consider the buffer conditions of several services on the decoding DSP.

----End

7.5.3 NodeB Uplink Bandwidth Adaptive Adjustment Algorithm

The NodeB uplink bandwidth adaptive adjustment algorithm is implemented in the NodeB. In

the scenario of network convergence or hub NodeB, the bandwidth configured by the NodeB

may be much greater than the available bandwidth on the transport network. The NodeB

uplink bandwidth adaptive adjustment algorithm automatically monitors congestion on the

transport network and adjusts the maximum available bandwidth on the Iub interface.

Therefore, this algorithm is also called transport network congestion control algorithm.

The adjustment result is the input for the NodeB backpressure-based congestion control

algorithm. Considering the difference between ATM transport and IP transport, two types of

algorithms are available.


Algorithm for ATM Transport

The RNC monitors congestion due to delay and frame loss based on the packet transmission

time specified in the Spare Extension field in the FP frame and the number of FP packets sent

by the NodeB. Then, the RNC returns the congestion indication according to the congestion

detection result. The frame structure of the congestion indication is shown in Figure 7-6. At

the same time, the cross-Iur indication is added to the congestion indication, which is used for

the NodeB to perform cross-Iur flow control for HSUPA users.

Figure 7-6 Frame structure of the congestion indication on the transport network

Congestion Status indicates the congestion status of the transport network. Its values are as

follows:

0: no TNL congestion

1: reserved for future use

2: TNL congestion detected by delay build-up

3: TNL congestion detected by frame loss

After receiving the non-cross-Iur congestion indication periodically measured on each LP, the

NodeB adjusts the exit bandwidth on the NodeB side according to the following principles:

If the NodeB receives the congestion indication in which the value of Congestion Status

is 2 or 3 in a measurement period, it reduces the exit bandwidth of the LP by a certain

step.

NOTE




property name.)


name.

7-16

Otherwise, the NodeB increases the exit bandwidth of the LP by a certain step, and the

changed exit bandwidth does not exceed the configured bandwidth.

Algorithm for IP Transport

For IP transport, the NodeB directly obtains the congestion status of the transport network

according to the IP PM result without using the congestion indication from the RNC.

After obtaining the Iub congestion status of the transport network, the NodeB adjusts the exit

bandwidth according to the following principles:

If the NodeB detects congestion due to frame loss or delay in a measurement period, it

reduces the exit bandwidth of the LP by a certain step.

Otherwise, the NodeB increases the exit bandwidth of the LP by a certain step, and the

changed exit bandwidth does not exceed the configured bandwidth.

7.5.4 RNC R99 Single Service Uplink Congestion Control Algorithm

The RNC R99 single service uplink congestion control algorithm monitors congestion by

monitoring end-to-end packet loss (from the NodeB to the RNC) for each DCH FP at the FP

layer. Then, the RNC controls the transmission rate of UEs through the RRC signaling TFC

Control. This algorithm is applied to the R99 uplink congestion control scenario in which

backpressure does not take effect.



Step 1 The uplink DCH data frame is extended to implement FP-based uplink congestion detection.

The extension information consists of the PM packet indication, PM packet transmission time,

total number of FP packets sent by the decoding DSP (including data packets discarded from

the buffer of the decoding DSP), and total number of FP packets sent by the decoding DSP to

the transport network (excluding data packets discarded from the buffer of the decoding DSP).

Step 2 If the DCH FP frame carries the total number of FP packets sent by the NodeB, the RNC

performs R99 single service uplink congestion detection.

If the FP of a service of a user detects the uplink R99 congestion due to frame loss,

− If the rate reducing period timer expires, the RNC reduces the rate of the uplink

service by a level and notifies the UE through the TFC Control signaling. The rate is

not lower than the GBR. Then, the rate reducing period timer and the congestion

recovery timer are started.

− If the rate reducing period timer does not expire, the rate cannot be reduced, and the

congestion recovery timer is restarted.

Step 3 If the congestion recovery timer expires and the current rate of the user does not reach the

MBR, the RNC increases the rate by a level and notifies the UE through the TFC CONTROL

signaling. Then, the congestion recovery timer is restarted.

----End

NOTE




property name.)


name.

7-17

7.5.5 NodeB Cross-Iur Single HSUPA Service Uplink Congestion Control Algorithm

The NodeB cross-Iur single HSUPA service uplink congestion control algorithm is

implemented in the NodeB. For users across the Iur interface, the NodeB adjusts the exit rate

of a single service according to the TNL Congestion Indication returned by the SRNC to

prevent congestion due to packet loss on the Iur interface.

The new boards of the RAN10.0 support this algorithm. The boards of the RAN10.0 or earlier

versions do not support this algorithm.



Step 1 For the cross-Iur HSUPA service, the RNC sends the cross-Iur TNL Congestion Indication to

the NodeB and indicates that the user is across the Iur interface.

Step 2 After receiving the cross-Iur TNL Congestion Indication from the RNC, the NodeB performs

the operation as follows:

The NodeB limits the transmission rate (not lower than the GBR) of the user and restarts the

rate reducing and suspension period timer of the uplink cross-Iur HSUPA service if the TNL

Congestion Indication indicates congestion due to frame loss or delay and the timer expires.

Step 3 In a period of 1s, the NodeB increases the transmission rate for the uplink cross-Iur HSUPA

user by a level by a certain step until the rate of the BE user reaches the MBR.


at intervals of 20s.

Step 4 After obtaining the transmission rate, the decoding DSP sends data by using the leaky bucket

algorithm.

If the NodeB supports uplink backpressure, the transmission rate is the minimum value

between the rate limited by the backpressure algorithm and the rate specified by this

algorithm.

----End

7.6 Iub Efficiency Improvement

The Iub efficiency is improved in the following aspects:

IP RAN FP-MUX: The frame protocol multiplexing (FP-MUX) is used to encapsulate

several small FP PDU frames (also called subframe) into a UDP packet, thus improving

the transmission efficiency. The FP-MUX is only applied to Iub user plane data based on

the UDP/IP protocol.

IP RAN header compression: IP RAN header compression is performed to compress the

protocol header of the PPP frame to improve the bandwidth utilization.

FP silent mode: The FP silent mode is a mechanism of eliminating unused and null data

on the Iub/Iur interface.

NOTE




property name.)


name.

7-18

7.6.1 IP RAN FP-MUX

The FP-MUX is used to encapsulate several small FP PDU frames (also called subframe) into

a UDP packet, thus improving the transmission efficiency.

The FP-MUX is applied only to Iub user plane data based on the UDP/IP protocol.

The FP-MUX can be applied to frames with the same priority, namely, frames with the

same DSCP value.

Figure 7-7 shows the format of the FP-MUX UDP/IP packet.

Figure 7-7 Format of the FP-MUX UDP/IP packet

To activate the FP-MUX, the FPMUXSWITCH parameter should be set to YES.

SUBFRAMELEN indicates the maximum length of the subframe; MAXFRAMELEN

indicates the maximum frame length of the FP-MUX UPD/IP packet. At the time set by

FPTIME, the UDP packet is sent.

Only the FG2a and GOUa support the FP-MUX. Each board supports 1,800 FP-MUX streams.

The QoS path occupies 14 FP-MUX streams for mapping, and the non-QoS path occupies

only one FP-MUX stream.IP RAN Header Compression

IP RAN header compression is performed to compress the protocol header of the PPP frame

to improve the bandwidth utilization. The RNC and NodeB support the following header

compression methods.

ACFC

Address and Control Field Compression (ACFC) complies with RFC 1661. It is used to

compress the address and control fields of the PPP protocol. Generally, the address and

control field values are fixed values and need not be transferred each time. After the Link

Control Protocol (LCP) negotiation of the PPP link is complete, the address and control field

of successive packets can be compressed.




property name.)


name.

7-19

PFC

Protocol Field Compression (PFC) complies with RFC 1661. It is used to compress the 2-byte

protocol field to a 1-byte one. The structure of this field is consistent with the ISO 3309

extension mechanism for the protocol field.

When the least significant bit of the protocol field is 0, the protocol field contains two

bytes. The remaining bits follow this bit.

When the least significant bit of the protocol field is 1, the protocol field contains one

byte. This byte is the last one.

Most packets can be compressed because the assigned protocol field value is generally less

than 256.

IPHC

IP Header Compression (IPHC) complies with RFC 2507 and RFC 3544. It is used to

compress the IP/UDP header on the PPP link. IPHC improves the bandwidth utilization by

using the following methods:

The unchanged header fields in the IP/UDP header are not carried in each packet.

The header fields changed in a specified mode are replaced by the less significant bits.

When a packet with a full header is occasionally sent, the header context can be established at

both ends of the link. The original header can be restored according to the context and the

received compressed header.

The associated parameter on the RNC side is IPHC.

The associated parameter on the NodeB side is IPHC.

7.6.3 FP Silent Mode

The FP silent mode saves the transmission bandwidth of the uplink R99 service and improves

the uplink transmission efficiency.

Two modes, normal mode and silent mode, can be used in uplink transmission. When the

transport bearer is established and the NodeB is informed through the related control plane

procedure, the SRNC selects the transmission mode.

In normal mode, for the DCH, the NodeB continuously sends the UL DATA FRAME to

the RNC.

In silent mode, when only one transport channel is transmitted on the transport bearer,

the NodeB does not send the UL DATA FRAME to the RNC after receiving a TFI

indicating TB numbered 0 in a TTI period.

In silent mode, for all associated DCHs, the NodeB does not send the UL DATA FRAME

to the RNC after receiving a TFI indicating TB numbered 0.

In the current release, the transmission mode is permanently set to the normal mode.

7.7 IP PM

On the actual network, the bandwidth on the Iub interface may be variable. Based on the

packet loss and delay on the IP transport network detected by IP PM, the transmission




property name.)


name.

7-20

bandwidth on the Iub IP LP can be adjusted adaptively. The adjusted bandwidth can be used

as the input for port backpressure.

The IP PM solution is described as follows:

If backpressure is implemented on the LP, congestion and packet loss do not occur on the

LP but may occur on the transport network.

The RNC and NodeB implement IP PM in the following way to detect congestion and

packet loss on the transport network:

− The transmitter sends a Forward Monitoring (FM) packet containing the count and

timestamp of the transmit packet to the receiver.

− The receiver adds the count and timestamp of the receive packet to the FM packet to

generate a Backward Reporting (BR) packet and then sends it to the transmitter.

− The transmitter adjusts the available bandwidth on the LP according to the FM and

BR packets and adjusts the rate on the LP according to the bandwidth adjustment

result.

The dynamic adjustment of the bandwidth on the LP is dependent on the IP PM detection result. During

the LP configuration, if the BWADJ parameter is set to ON, IP PM for all IP paths on the LP must be

activated. Therefore, the system dynamically adjusts the bandwidth on the LP according to the Iub

transmission quality information obtained by IP PM.

The predicted available bandwidth is also applied to the access algorithm. For details,

see section 6.3 "Admission Control."

If the BWADJ parameter is set to ON, MAXBW and MINBW must be configured.

If the BWADJ parameter is set to OFF, only one fixed bandwidth may be configured for the LP.

Only the FG2a and GOUa support IP PM. Each board supports 500 PM streams. The QoS Path

needs to occupy a maximum of 14 PM streams. The non-QoS Path occupies only one PM stream.

The ACT IPPM command is used to activate IP PM, and the DEA IPPM command is used to

deactivate IP PM.




property name.)


name.

8-1

8 TRM Parameters

8.1 Description

Table 8-1 TRM parameter description

Parameter ID Description

Beartype This parameter specifies the bearer type of the service.

- R99: The service is carried on a non-HSPA channel.

- HSPA: The service is carried on an HSPA channel.

BWADJ Automatic bandwidth adjustment switch for logical ports.

BWDCONGBW If the available backward bandwidth is less than or equal to this value, the backward

congestion alarm is emitted.

BWDCONGCLRBW If the available backward bandwidth is greater than this value, the backward

congestion alarm is cleared.

BWDHORSVBW Reserved backward bandwidth for handover user.

CONGCLRTHD0 When the time of the queue 0 buffer no more than the value of this parameter, we

cancel port flow control, and when the port flow control type is ATM, this parameter

means the recover threshold of the CBR queue.



means the recover threshold of the RTVBR queue.



means the recover threshold of the NRTVBR queue.



means the recover threshold of the UBR queue.



means the recover threshold of the UBR+ queue.


cancel port flow control.

CONGTHD0 When the time of the queue 0 buffer no less than the value of this parameter, we




property name.)


name.

8-2


begin port flow control, and when the port flow control type is ATM, this parameter

means the congestion threshold of the CBR queue.



means the congestion threshold of the RTVBR queue.



means the congestion threshold of the NRTVBR queue.



means the congestion threshold of the UBR queue.



means the congestion threshold of the UBR+ queue.


begin port flow control.

DLR99CONGCTRLS

WITCH

When the switch is selected, the congestion detection and control for DL R99 service

is supported.

DR Discard Rate. The link is not congested when the frame loss ratio is lower than or

equal to this threshold.

DraSwitch Dynamic resource allocation switch.

1) DRA_AQM_SWITCH: When the switch is on, the active queue management

algorithm is used for the RNC.

2) DRA_BE_EDCH_TTI_RECFG_SWITCH: When the switch is on, the TTI could

be reconfigured to HSUPA traffic dynamically between 2ms and 10ms.

3) DRA_BE_RATE_DOWN_BF_HO_SWITCH: When the switch is on, the

bandwidth for BE services is reduced before soft handover. It is recommended that

the DCCC switch be on when this switch is on.

4) DRA_DCCC_SWITCH: When the switch is on, the dynamic channel

reconfiguration control algorithm is used for the RNC.

5) DRA_HSDPA_DL_FLOW_CONTROL_SWITCH: When the switch is on, power

control is enabled for HSDPA services in AM mode.

6) DRA_HSDPA_STATE_TRANS_SWITCH: When the switch is on, the status of

the UE RRC that carrying HSDPA services can be changed to CELL_FACH at the

RNC. If a PS BE service is carried over the HS-DSCH, the switch

PS_BE_STATE_TRANS_SWITCH should be on simultaneously. If a PS real-time

service is carried over the HS-DSCH, the switch

PS_NON_BE_STATE_TRANS_SWITCH should be on simultaneously.

7) DRA_HSUPA_DCCC_SWITCH: When the switch is on, the DCCC algorithm is

used for HSUPA. The DCCC switch must be also on before this switch takes effect.

8) DRA_HSUPA_STATE_TRANS_SWITCH: When the switch is on, the status of

the UE RRC that carrying HSUPA services can be changed to CELL_FACH at the

RNC. If a PS BE service is carried over the E-DCH, the switch

PS_BE_STATE_TRANS_SWITCH should be on simultaneously. If a PS real-time

service is carried over the E-DCH, the switch

PS_NON_BE_STATE_TRANS_SWITCH should be on simultaneously.

9) DRA_IU_QOS_RENEG_SWITCH: When the switch is on and the Iu QoS




property name.)


name.

8-3


RENEQ license is activated, the RNC supports renegotiation of the maximum rate if

the QoS of real-time services is not ensured according to the cell status.

10) DRA_PS_BE_STATE_TRANS_SWITCH: When the switch is on, UE RRC

status transition (CELL_FACH/CELL_PCH/URA_PCH) is allowed at the RNC.

11) DRA_PS_NON_BE_STATE_TRANS_SWITCH: When the switch is on, the

status of the UE RRC that carrying real-time services can be changed to

CELL_FACH at the RNC.

12) DRA_R99_DL_FLOW_CONTROL_SWITCH: Under a poor radio environment,

the QoS of high speed services drops considerably and the TX power is overly high.

In this case, the RNC can set restrictions on certain transmission formats based on the

transmission quality, thus lowering traffic speed and TX power. When the switch is

on, the Iub overbooking function is enabled.

13) DRA_THROUGHPUT_DCCC_SWITCH: When the switch is on, the DCCC

based on traffic statistics is supported over the DCH.

DROPPKTTHD0 When the time of the queue 0 buffer no less than the value of this parameter, we

begin to loss the packets, and when the port flow control type is ATM, this parameter

means the packet discard threshold of the CBR queue.



means the packet discard threshold of the RTVBR queue.



means the packet discard threshold of the NRTVBR queue.



means the packet discard threshold of the UBR queue.



means the packet discard threshold of the UBR+ queue .


begin to loss the packets.

DSCP This parameter specifies the DiffServ Code Point for the ping command.

EventAThred This parameter specifies the threshold of event A, that is, the upper limit of RLC

retransmission ratio.

EventBThred This parameter specifies the threshold of event B, that is, the lower limit of RLC

retransmission ratio.

FCINDEX Flow control parameter index.

FLOWCTRLSWITC

H

Flow control switch.

FPMUXSWITCH Indicating whether to check the link of the IP path with FPMUX. Only FG2a and

GOUa board support FPMUX.

FTI Index of the factor table used by the current adjacent node.




property name.)


name.

8-4


FWDCONGBW If the available forward bandwidth is less than or equal to this value, the forward


FWDCONGCLRBW If the available forward bandwidth is greater than this value, the forward congestion

alarm is cleared.

FWDHORSVBW Reserved forward bandwidth for handover user.

IPHC IP header compress function of the PPP link.

IPHC IP Header Compress. DISABLE means that the IP header is not expected to be

compressed from the peer end. ENABLE means that the UDP/IP header is expected

to be compressed from the peer end.

MAXBW Maximum bandwidth of automatic adjustment for logical ports.

MAXFRAMELEN Maximum Frame Length.

MINBW Minimum bandwidth of automatic adjustment for logical ports.

MoniterPrd This parameter specifies a sampling period of retransmission ratio monitoring after

the RLC entity is established or reconfigured.

NodeBLdcAlgoSwitc

h

IUB_LDR (Iub congestion control algorithm): When the NodeB Iub load is heavy,

users are assembled in priority order among all the NodeBs and some users are

selected for LDR action (such as BE service rate reduction) in order to reduce the

NodeB Iub load.

NODEB_CREDIT_LDR (NodeB level credit congestion control algorithm): When

the NodeB level credit load is heavy, users are assembled in priority order among all

the NodeBs and some users are selected for LDR action in order to reduce the NodeB

level credit load.

LCG_CREDIT_LDR (Cell group level credit congestion control algorithm): When

the cell group level credit load is heavy, users are assembled in priority order among

all the NodeBs and some users are selected for LDR action in order to reduce the cell

group level credit load.

IUB_OLC (Iub Overload congestion control algorithm): When the NodeB Iub load is

Overload, users are assembled in priority order among all the NodeBs and some users

are selected for Olc action in order to reduce the NodeB Iub load.

To enable some of the algorithms above, select them. Otherwise, they are disabled.

PendingTimeA This parameter specifies the number of pending periods after event A is triggered.

During the pending time, no event related to retransmission ratio is reported.

PendingTimeB This parameter specifies the number of pending periods after event B is triggered.

During the pending time, no event related to retransmission ratio is reported.

PQNUM This parameter is valid only when the port flow control type is IP; Priority queue

number of ATM is fixed to 2 and can not be modified.

PT Port Type

RXTRFX Receive traffic record index of the SAAL link.

SPI This parameter indicates the scheduling priority. The value 15 indicates the highest

priority and the value 0 indicates the lowest.

SUBFRAMELEN Max subframe length.




property name.)


name.

8-5


Switch Flow Control Switch

TD Time Delay. The link is not congested when the delay is lower than this threshold.

TimeToMoniter This parameter specifies the delay time after the RLC entity is established or

reconfigured and before the retransmission ratio monitoring is started.

TimeToTriggerA This parameter specifies the number of consecutive periods during which the

percentage of retransmitted PDUs is higher than the threshold of event A before event

A is triggered.

Recommended value (default value): 2.

TimeToTriggerB This parameter specifies the number of consecutive periods during which the

percentage of retransmitted PDUs is lower than the threshold of event B before event

B is triggered.

TrafficClass This parameter specifies the traffic class that the service belongs to. Based on Quality

of Service (QoS), there are two traffic classes: interactive, background.

TXTRFX TX traffic record index at the port from which the IPoA PVC goes out of the RNC.

The TX traffic must have been configured.

UserPriority This parameter specifies the user priority. The user classes in descending order of

priority are Gold, Silver, and then Copper.

Beartype This parameter specifies the bearer type of the service.

- R99: The service is carried on a non-HSPA channel.

- HSPA: The service is carried on an HSPA channel.

BWADJ Automatic bandwidth adjustment switch for logical ports.

BWDCONGBW If the available backward bandwidth is less than or equal to this value, the backward


BWDCONGCLRBW If the available backward bandwidth is greater than this value, the backward

congestion alarm is cleared.

BWDHORSVBW Reserved backward bandwidth for handover user.



means the recover threshold of the CBR queue.



means the recover threshold of the RTVBR queue.



means the recover threshold of the NRTVBR queue.



means the recover threshold of the UBR queue.






property name.)


name.

8-6


means the recover threshold of the UBR+ queue.


cancel port flow control.



means the congestion threshold of the CBR queue.



means the congestion threshold of the RTVBR queue.



means the congestion threshold of the NRTVBR queue.



means the congestion threshold of the UBR queue.



means the congestion threshold of the UBR+ queue.

8.2 Values and Ranges

Table 8-2 TRM parameter values and parameter ranges

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

Beartype - R99, HSPA R99, HSPA None SET

USERGBR(Mandatory)

RNC

BWADJ OFF OFF, ON OFF, ON None ADD

IPLOGICPORT(Option

al)

RNC

BWDCONG

BW

0 0~320000 0~320000 kbit/s ADD

AAL2PATH(Optional)

RNC

BWDCONG

CLRBW

0 0~320000 0~320000 kbit/s ADD

AAL2PATH(Optional)

RNC

BWDHORS

VBW

0 0~320000 0~320000 kbit/s ADD

AAL2PATH(Optional)

RNC

CONGCLRT

HD0

15 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC




property name.)


name.

8-7

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

CONGCLRT

HD1

15 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

CONGCLRT

HD2

15 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

CONGCLRT

HD3

15 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

CONGCLRT

HD4

25 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

CONGCLRT

HD5

25 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

CONGTHD0 25 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC


PORTFLOWCTRLPAR

A(Optional)

RNC


PORTFLOWCTRLPAR

A(Optional)

RNC


PORTFLOWCTRLPAR

A(Optional)

RNC


PORTFLOWCTRLPAR

A(Optional)

RNC


PORTFLOWCTRLPAR

A(Optional)

RNC

DLR99CON

GCTRLSWI

TCH

- OFF(The

switch of DL

R99 congestion

control is off),

ON(The switch

of DL R99

congestion

control is on)

OFF, ON None SET

DPUCFGDATA(Option

al)

RNC

DR 1 0~1000 0~1, Step:

0.001 None SET

HSDPAFLOWCTRLPA

Node

B




property name.)


name.

8-8

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

RA(Optional)

DraSwitch - DRA_AQM_S

WITCH,

DRA_BE_EDC

H_TTI_RECF

G_SWITCH,

DRA_BE_RAT

E_DOWN_BF_

HO_SWITCH,

DRA_DCCC_S

WITCH,

DRA_HSDPA_

DL_FLOW_C

ONTROL_SWI

TCH,

DRA_HSDPA_

STATE_TRAN

S_SWITCH,

DRA_HSUPA_

DCCC_SWITC

H,

DRA_HSUPA_

STATE_TRAN

S_SWITCH,

DRA_IU_QOS

_RENEG_SWI

TCH,

DRA_PS_BE_

STATE_TRAN

S_SWITCH,

DRA_PS_NON

_BE_STATE_

TRANS_SWIT

CH,

DRA_R99_DL

_FLOW_CON

TROL_SWITC

H,

DRA_THROU

GHPUT_DCC

C_SWITCH

DRA_AQM_S

WITCH,

DRA_BE_EDC

H_TTI_RECF

G_SWITCH,

DRA_BE_RAT

E_DOWN_BF_

HO_SWITCH,

DRA_DCCC_S

WITCH,

DRA_HSDPA_

DL_FLOW_C

ONTROL_SWI

TCH,

DRA_HSDPA_

STATE_TRAN

S_SWITCH,

DRA_HSUPA_

DCCC_SWITC

H,

DRA_HSUPA_

STATE_TRAN

S_SWITCH,

DRA_IU_QOS

_RENEG_SWI

TCH,

DRA_PS_BE_

STATE_TRAN

S_SWITCH,

DRA_PS_NON

_BE_STATE_

TRANS_SWIT

CH,

DRA_R99_DL

_FLOW_CON

TROL_SWITC

H,

DRA_THROU

GHPUT_DCC

C_SWITCH

None SET

CORRMALGOSWITC

H(Optional)

RNC

DROPPKTT

HD0

60 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

DROPPKTT

HD1

60 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

DROPPKTT

HD2 60 10~150 10 to 150 ms ADD

PORTFLOWCTRLPARRNC




property name.)


name.

8-9

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

A(Optional)

DROPPKTT

HD3

60 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

DROPPKTT

HD4 80 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

DROPPKTT

HD5

80 10~150 10 to 150 ms ADD

PORTFLOWCTRLPAR

A(Optional)

RNC

DSCP 0(PING IP)

-(SET

PHBMAP,S

ET

DSCPMAP

)

62(ADD

SCTPLNK)

0~63 0 to 63 None PING IP(Optional)

SET

DSCPMAP(Mandatory)

ADD

SCTPLNK(Optional)

SET

PHBMAP(Mandatory)

RNC

EventAThred 160 0~1000 0~100, step: 0.1 per

cent

ADD

TYPRABRLC(Optional

)

RNC

EventBThred 80 0~1000 0~100, step: 0.1 per

cent

ADD

TYPRABRLC(Optional

)

RNC

FCINDEX 1(ADD

ATMLOGI

CPORT,

ADD

UNILNK,

ADD

IMAGRP,

ADD

FRALNK)

-(ADD

PORTFLO

WCTRLPA

RA, SET

ETHPORT,

SET OPT)

0(ADD

IPLOGICP

ORT, ADD

PPPLNK,

ADD

MPGRP)

0~1999 0 to 1999 None ADD

FRALNK(Optional)

ADD

IMAGRP(Optional)

SET OPT(Mandatory)

SET

ETHPORT(Mandatory)

ADD

MPGRP(Optional)

ADD

PPPLNK(Optional)

ADD

UNILNK(Optional)

ADD

ATMLOGICPORT(Opti

onal)

ADD

PORTFLOWCTRLPAR

A(Mandatory)

ADD

IPLOGICPORT(Option

al)

RNC




property name.)


name.

8-10

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

FLOWCTRL

SWITCH

ON(ADD

ATMLOGI

CPORT,

ADD

UNILNK,

ADD

MPGRP,

ADD

IPLOGICP

ORT, ADD

IMAGRP,

ADD

PPPLNK,

ADD

FRALNK)

-(SET

ETHPORT,

SET OPT)

OFF, ON OFF, ON None ADD

FRALNK(Optional)

SET OPT(Optional)

ADD

PPPLNK(Optional)

ADD

IMAGRP(Optional)

ADD

IPLOGICPORT(Option

al)

ADD

MPGRP(Optional)

ADD

UNILNK(Optional)

ADD

ATMLOGICPORT(Opti

onal)

SET

ETHPORT(Optional)

RNC

FPMUXSWI

TCH

NO NO, YES NO, YES None ADD

IPPATH(Optional)

RNC

FTI - 0~33 0~33 None ADD

ADJMAP(Mandatory)

RNC

FWDCONG

BW

0 0~320000 0~320000 kbit/s ADD

AAL2PATH(Optional)

RNC

FWDCONG

CLRBW

0 0~320000 0~320000 kbit/s ADD

AAL2PATH(Optional)

RNC

FWDHORS

VBW 0 0~320000 0~320000 kbit/s ADD

AAL2PATH(Optional) RNC

IPHC UDP/IP_H

C

No_HC,

UDP/IP_HC

No_HC(Disabl

e head

compress),UDP

/IP_HC(Use

UDP/IP head

compress)

None ADD

PPPLNK(Optional)

RNC

IPHC ENABLE DISABLE(The

IP header is not

expected to be

compressed

from the peer),

ENABLE(The

UDP/IP header

is expected to

be compressed

from the peer)

DISABLE,

ENABLE

None ADD

MPGRP(Optional)

ADD

PPPLNK(Optional)

Node

B

MAXBW - 1~1000 64~64000 kbit/s ADD RNC




property name.)


name.

8-11

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

step:64 IPLOGICPORT(Mandat

ory)

MAXFRAM

ELEN

270 24~1031 24~1031 byte ADD

IPPATH(Optional)

RNC

MINBW - 1~1000 64~64000

step:64 kbit/s ADD

IPLOGICPORT(Mandat

ory)

RNC

MoniterPrd 1000 40~60000 40~60000 ms ADD

TYPRABRLC(Optional

)

RNC

NodeBLdcAl

goSwitch

- IUB_LDR,

NODEB_CRE

DIT_LDR,

LCG_CREDIT

_LDR,

IUB_OLC

IUB_LDR,

NODEB_CRE

DIT_LDR,

LCG_CREDIT

_LDR,

IUB_OLC

None ADD

NODEBALGOPARA(O

ptional)

RNC

PendingTime

A

1 0~1000 0~1000 None ADD

TYPRABRLC(Optional

)

RNC

PendingTime

B

1 0~1000 0~1000 None ADD

TYPRABRLC(Optional

)

RNC

PQNUM - 0~5 0 to 5 None ADD

PORTFLOWCTRLPAR

A(Mandatory)

RNC

PT - BOOL(Boolean

port),

VALUE(Analo

g port)

BOOL(Boolean

port),

VALUE(Analo

g port)

None SET ALMPORT Node

B

RXTRFX - 100~1999 100~1999 None ADD

SAALLNK(Mandatory)

ADD

AAL2PATH(Mandatory

)

ADD

VPCLCX(Mandatory)

ADD

IPOAPVC(Optional)

RNC

SPI - 0~15 0~15 None SET

SPIFACTOR(Mandator

y)

SET

SCHEDULEPRIOMAP

(Mandatory)

RNC




property name.)


name.

8-12

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

SUBFRAME

LEN

127 16~1023 16~1023 byte ADD

IPPATH(Optional)

RNC

Switch BW_SHAP

ING_ONO

FF_TOGG

LE

DYNAMIC_B

W_SHAPING:

According to

the flow control

of

STATIC_BW_

SHAPING,

traffic is

allocated to

HSDPA users

when the delay

and packet loss

on the Iub

interface are

taken into

account. The

RNC use the

R6 switch to

perform this

function. It is

recommended

that the RNC in

compliance

with R6 should

perform this

function.

NO_BW_SHA

PING: The

NodeB does not

allocate

bandwidth

according to the

configuration or

delay on the Iub

interface. The

RNC allocates

the bandwidth

according to the

bandwidth on

the Uu interface

reported by the

NodeB. To

perform this

function, the

reverse flow

control switch

must be

enabled by the

RNC. The link

STATIC_BW_

SHAPING,

DYNAMIC_B

W_SHAPING,

NO_BW_SHA

PING,

BW_SHAPING

_ONOFF_TOG

GLE

None SET

HSDPAFLOWCTRLPA

RA(Optional)

Node

B




property name.)


name.

8-13

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

is not congested

when the delay

is lower than

this threshold.

The link is not

congested when

frame loss ratio

is no higher

than this

threshold.

BW_SHAPING

_ONOFF_TOG

GLE: If

BW_SHAPING

_ONOFF_TOG

GLE is

selected, the

system

automatically

selects

DYNAMIC_B

W_SHAPING

or

NO_BW_SHA

PING on the

basis of the

NodeB

congestion

detection

mechanism. In

other words,

DYNAMIC_B

W_SHAPING

is selected

when

congestion is

detected;

NO_BW_SHA

PING is

selected when

there is no

congestion

within a

specific time.

BW_SHAPING

_ONOFF_TOG

GLE,

DYNAMIC_B

W_SHAPING,

and

NO_BW_SHAPING are flow




property name.)


name.

8-14

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

control

strategies

applied at the

NodeB port.

TD 4 0~100 0~500, Step:

5ms

ms SET

HSDPAFLOWCTRLPA

RA(Optional)

Node

B

TimeToMoni

ter

5000 0~500000 0~500000 ms ADD

TYPRABRLC(Optional

)

RNC

TimeToTrigg

erA

2 1~100 1~100 None ADD

TYPRABRLC(Optional

)

RNC

TimeToTrigg

erB

14 1~100 1~100 None ADD

TYPRABRLC(Optional

)

RNC

TrafficClass - INTERACTIV

E,

BACKGROUN

D

INTERACTIV

E,

BACKGROUN

D

None SET

SCHEDULEPRIOMAP

(Mandatory)

SET

USERGBR(Mandatory)

SET

FACHBANDWIDTH(

Mandatory)

SET

USERHAPPYBR(Mand

atory)

SET

DTXDRXPARA(Manda

tory)

SET

HSSCCHLESSOPPAR

A(Mandatory)

RNC

TXTRFX - 100~1999 100 to 1999 None ADD

IPOAPVC(Optional)

ADD

AAL2PATH(Mandatory

)

ADD

SAALLNK(Mandatory)

ADD

VPCLCX(Mandatory)

RNC

UserPriority - GOLD,

SILVER,

COPPER

GOLD,

SILVER,

COPPER

None SET

SCHEDULEPRIOMAP

(Mandatory)

SET

USERGBR(Mandatory)

RNC




property name.)


name.

8-15

Parameter ID

Default Value

GUI Value Range

Actual Value Range

Unit MML Command NE

SET

FACHBANDWIDTH(

Mandatory)

SET

USERHAPPYBR(Mand

atory)

The Default Value column is valid for only the optional parameters.

The "-" symbol indicates no default value.




property name.)


name.

9-1

9 TRM Reference Documents

The following lists the reference documents related to the feature:

1. ITU-T Recommendation I.361 “B-ISDN ATM Layer Specification”

2. ITU-T Recommendation I.363.2 “ATM Adaptation layer specification: Type 2 AAL”

3. ITU-T Recommendation I.366.1 “Segmentation and Reassembly Service Specific

Convergence Sublayer for the AAL type 2”

4. AF-TM-0121.000 “Traffic Management 4.1”

5. AF-PHY-0086.001 “Inverse Multiplexing for ATM (IMA) Specification Version 1.1”

6. RFC1661 “The Point-to-Point Protocol (PPP), provides a standard method for

transporting multi-protocol datagrams over point-to-point links”

7. RFC1662 "PPP in HDLC-link Framing"

8. RFC1990 "The PPP Multilink Protocol (ML-PPP)"

9. RFC2686 "The Multi-Class Extension to Multi-link PPP (MC-PPP)"

10. RFC3153 "PPP Multiplexing (PPPmux)"

11. RFC894 "Standard for the Transmission of IP Datagrams over Ethernet Networks"

12. RFC1042 "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks"

13. 3GPP TS 25.423 "UTRAN Iur interface RNSAP signaling"

14. 3GPP TS 25.426 "UTRAN Iur and Iub Interface Data Transport"

15. 3GPP TS 25.427 "UTRAN Iur and Iub Interface User Plane Protocols for DCH Data

Streams"

16. 3GPP TS 25.212 "Multiplexing and Channel Coding"

17. 3GPP TS 25.221 "Physical Channels and Mapping of Transport Channels onto Physical

Channels"

18. Basic Feature Description of Huawei UMTS RAN11.0 V1.5

19. Optional Feature Description of Huawei UMTS RAN11.0 V1.5




property name.)


name.

10-1

10 Appendix

10.1 Default TRMMAP Table for the ATM-Based Iub and Iur Interfaces

Table 10-1 Default TRMMAP table for the ATM-based Iub and Iur interfaces

TC/THP Gold Silver Copper

Primary Secondary Primary Secondary Primary Secondary

Common channel RT_VBR None – – – –

SRB RT_VBR None – – – –

SIP RT_VBR None – – – –

AMR RT_VBR None RT_VBR None RT_VBR None

R99 CS conversational RT_VBR None RT_VBR None RT_VBR None

R99 CS streaming RT_VBR None RT_VBR None RT_VBR None

R99 PS conversational RT_VBR None RT_VBR None RT_VBR None

R99 PS streaming RT_VBR None RT_VBR None RT_VBR None

R99 PS high-priority

interactive

NRT_VB

R

None NRT_VB

R

None NRT_VB

R

None

R99 PS medium-priority

interactive

NRT_VB

R

None NRT_VB

R

None NRT_VB

R

None

R99 PS low-priority

interactive

NRT_VB

R

None NRT_VB

R

None NRT_VB

R

None

R99 PS background NRT_VB

R

None NRT_VB

R

None NRT_VB

R

None

HSDPA SRB RT_VBR None RT_VBR None RT_VBR None

HSDPA SIP RT_VBR None RT_VBR None RT_VBR None




property name.)


name.

10-2



HSDPA voice RT_VBR None RT_VBR None RT_VBR None

HSDPA conversational RT_VBR None RT_VBR None RT_VBR None

HSDPA streaming RT_VBR None RT_VBR None RT_VBR None

HSDPA high-priority

interactive

UBR None UBR None UBR None

HSDPA medium-priority

interactive


HSDPA low-priority

interactive


HSDPA background UBR None UBR None UBR None

HSUPA SRB RT_VBR None RT_VBR None RT_VBR None

HSUPA SIP RT_VBR None RT_VBR None RT_VBR None

HSUPA voice RT_VBR None RT_VBR None RT_VBR None

HSUPA conversational RT_VBR None RT_VBR None RT_VBR None

HSUPA streaming RT_VBR None RT_VBR None RT_VBR None

HSUPA high-priority

interactive UBR None UBR None UBR None

HSUPA medium-priority

interactive


HSUPA low-priority

interactive


HSUPA background UBR None UBR None UBR None

10.2 Default TRMMAP Table for the IP-Based Iub and Iur Interfaces

Table 10-2 Default TRMMAP table for the IP-based Iub and Iur interfaces



Common channel EF None – – – –




property name.)


name.

10-3



SRB EF None – – – –

SIP EF None – – – –

AMR EF None EF None EF None

R99 CS conversational AF43 None AF43 None AF43 None

R99 CS streaming AF33 None AF33 None AF33 None

R99 PS conversational AF43 None AF43 None AF43 None

R99 PS streaming AF33 None AF33 None AF33 None


interactive AF33 None AF33 None AF33 None


interactive

AF33 None AF33 None AF33 None

R99 PS low-priority

interactive


R99 PS background AF13 None AF13 None AF13 None

HSDPA SRB EF None – – – –

HSDPA SIP EF None – – – –

HSDPA voice AF43 None AF43 None AF43 None

HSDPA conversational AF43 None AF43 None AF43 None

HSDPA streaming AF33 None AF33 None AF33 None

HSDPA high-priority

interactive



interactive


HSDPA low-priority

interactive


HSDPA background BE None BE None BE None

HSUPA SRB EF None – – – –

HSUPA SIP EF None – – – –

HSUPA voice AF43 None AF43 None AF43 None

HSUPA conversational AF43 None AF43 None AF43 None

HSUPA streaming AF33 None AF33 None AF33 None




property name.)


name.

10-4



HSUPA high-priority

interactive



interactive


HSUPA low-priority

interactive


HSUPA background AF13 None AF13 None AF13 None

10.3 Default TRMMAP Table for the ATM&IP-Based Iub Interface

Table 10-3 Default TRMMAP table for the ATM&IP-based Iub interface



Common channel RT_VBR EF – – – –

SRB RT_VBR EF – – – –

SIP RT_VBR EF – – – –

AMR RT_VBR EF RT_VBR EF RT_VBR EF

R99 CS

conversational

RT_VBR AF43 RT_VBR AF43 RT_VBR AF43

R99 CS streaming RT_VBR AF33 RT_VBR AF33 RT_VBR AF33

R99 PS

conversational


R99 PS streaming RT_VBR AF33 RT_VBR AF33 RT_VBR AF33


interactive

NRT_VBR AF33 NRT_VBR AF33 NRT_VBR AF33

R99 PS medium-



R99 PS low-priority

interactive


R99 PS background NRT_VBR AF13 NRT_VBR AF13 NRT_VBR AF13

HSDPA SRB EF RTVBR – – – –




property name.)


name.

10-5



HSDPA SIP EF RTVBR – – – –

HSDPA voice RT_VBR AF43 RT_VBR AF43 RT_VBR AF43

HSDPA

conversational


HSDPA streaming RT_VBR AF33 RT_VBR AF33 RT_VBR AF33

HSDPA high-priority

interactive

AF23 UBR AF23 UBR AF23 UBR

HSDPA medium-


AF23 UBR AF23 UBR AF23 AF11

HSDPA low-priority

interactive


HSDPA background AF13 UBR AF13 UBR AF13 UBR

HSUPA SRB EF RTVBR – – – –

HSUPA SIP EF RTVBR – – – –

HSUPA voice RT_VBR AF43 RT_VBR AF43 RT_VBR AF43

HSUPA

conversational


HSUPA streaming RT_VBR AF33 RT_VBR AF33 RT_VBR AF33

HSUPA high-priority

interactive

AF23 UBR AF23 UBR AF23 UBR

HSUPA medium-



HSUPA low-priority

interactive


HSUPA background AF13 UBR AF13 UBR AF13 UBR




property name.)


name.

10-6

10.4 Default TRMMAP Table for the Hybrid-IP-Based Iub Interface

Table 10-4 Default TRMMAP table for the hybrid-IP-based Iub interface



Common channel EF LQEF – – – –

SRB EF LQEF – – – –

SIP EF LQEF – – – –

AMR EF LQEF EF LQEF EF LQEF

R99 CS conversational AF43 LQAF43 AF43 LQAF43 AF43 LQAF43

R99 CS streaming AF33 LQAF33 AF33 LQAF33 AF33 LQAF33

R99 PS conversational AF43 LQAF43 AF43 LQAF43 AF43 LQAF43

R99 PS streaming AF43 LQAF43 AF43 LQAF43 AF43 LQAF43


interactive

AF33 LQAF33 AF33 LQAF33 AF33 LQAF33


interactive


R99 PS low-priority

interactive


R99 PS background AF13 LQAF13 AF13 LQAF13 AF13 LQAF13

HSDPA SRB EF LQEF – – – –

HSDPA SIP EF LQEF – – – –

HSDPA voice AF33 LQAF33 AF33 LQAF33 AF33 LQAF33

HSDPA conversational AF33 LQAF33 AF33 LQAF33 AF33 LQAF33

HSDPA streaming AF33 LQAF33 AF33 LQAF33 AF33 LQAF33

HSDPA high-priority

interactive



interactive


HSDPA low-priority

interactive


HSDPA background AF13 LQAF13 AF13 LQAF13 AF13 LQAF13

HSUPA SRB EF LQEF – – – –




property name.)


name.

10-7



HSUPA SIP EF LQEF – – – –

HSUPA voice AF33 LQAF33 AF33 LQAF33 AF33 LQAF33

HSUPA conversational AF33 LQAF33 AF33 LQAF33 AF33 LQAF33

HSUPA streaming AF33 LQAF33 AF33 LQAF33 AF33 LQAF33

HSUPA high-priority

interactive



interactive


HSUPA low-priority

interactive


HSUPA background AF13 LQAF13 AF13 LQAF13 AF13 LQAF13

10.5 Default TRMMAP Table for the ATM-Based Iu-CS Interface

Table 10-5 Default TRMMAP table for the ATM-based Iu-CS interface



AMR RT_VBR None RT_VBR None RT_VBR None

CS conversational RT_VBR None RT_VBR None RT_VBR None

CS streaming RT_VBR None RT_VBR None RT_VBR None

10.6 Default TRMMAP Table for the IP-Based Iu-CS Interface

Table 10-6 Default TRMMAP table for the IP-based Iu-CS interface



AMR EF None EF None EF None




property name.)


name.

10-8



CS conversational AF43 None AF43 None AF43 None

CS streaming AF33 None AF33 None AF33 None

10.7 Default TRMMAP Table for the Iu-PS Interface

Table 10-7 Default TRMMAP table for the Iu-PS interface



SIP EF None – – – –

PS conversational AF43 None AF43 None AF43 None

PS streaming AF43 None AF43 None AF43 None

PS high-priority

interactive


PS medium-priority

interactive


PS low-priority

interactive


PS background AF13 None AF13 None AF13 None