Transmission Resource Management

Transmission Resource Management SRAN5.
Feature Parameter Description
Issue Date
03 2011-09-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2011. 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 purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. 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.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: Email: http://www.huawei.com support@huawei.com
SingleRAN Transmission Resource Management
Contents
Contents
1 Introduction ................................................................................................................................1-1
1.1 Scope ............................................................................................................................................ 1-1 1.2 Intended Audience ........................................................................................................................ 1-1 1.3 Change History.............................................................................................................................. 1-1
2 Overview of TRM .......................................................................................................................2-1

2.1 Definition of TRM........................................................................................................................... 2-1 2.2 Structure of TRM Functions .......................................................................................................... 2-1 2.3 Similarities and Differences Between 2G, 3G, and Co-Transmission Systems ............................ 2-3 2.3.1 Transmission Resources ...................................................................................................... 2-3 2.3.2 Load Control ......................................................................................................................... 2-3 2.3.3 User Plane Processing and QoS.......................................................................................... 2-4 2.3.4 Differences of Co-TRM From 2G TRM and 3G TRM ........................................................... 2-5 2.4 Benefits of TRM ............................................................................................................................. 2-5
3 Transmission Resources ........................................................................................................3-1

3.1 Overview of Transmission Resources ........................................................................................... 3-1 3.2 Physical Transmission Resources ................................................................................................ 3-3 3.2.1 Physical Layer Resources for ATM Transmission ................................................................ 3-4 3.2.2 Physical Layer Resources for TDM Transmission................................................................ 3-4 3.2.3 Physical and Data Link Layer Resources for HDLC Transmission ...................................... 3-4 3.2.4 Physical and Data Link Layer Resources for IP Transmission............................................. 3-4 3.3 Logical Ports and Resource Groups ............................................................................................. 3-5 3.3.1 Introduction to LPs................................................................................................................ 3-5 3.3.2 ATM LPs at the RNC ............................................................................................................ 3-7 3.3.3 IP LPs at the BSC/RNC/MBSC ............................................................................................ 3-8 3.3.4 LPs at the NodeB ................................................................................................................. 3-9 3.3.5 LPs at the BTS ................................................................................................................... 3-10 3.3.6 Resource Groups at the BSC/RNC .................................................................................... 3-10 3.4 Path Resources ........................................................................................................................... 3-10 3.4.1 AAL2 Paths ......................................................................................................................... 3-10 3.4.2 IP Paths .............................................................................................................................. 3-10 3.5 Networking Application ................................................................................................................ 3-12 3.5.1 2G and 3G Networking ....................................................................................................... 3-12 3.5.2 Co-Transmission Networking ............................................................................................. 3-13
4 Quality of Service .....................................................................................................................4-1

4.1 Overview ....................................................................................................................................... 4-1 4.2 Transport Priorities ........................................................................................................................ 4-1 4.2.1 DSCP .................................................................................................................................... 4-1 4.2.2 VLAN Priorities ..................................................................................................................... 4-2
Issue 03 (2011-09-30)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd
Contents
4.2.3 Priority Queues ..................................................................................................................... 4-4 4.2.4 Priority Queues and Rate Limiting in the NodeB .................................................................. 4-5 4.3 Service QoS .................................................................................................................................. 4-6 4.4 Transmission Resource Mapping .................................................................................................. 4-6 4.4.1 Traffic Bearers ...................................................................................................................... 4-6 4.4.2 Transport Bearers ................................................................................................................. 4-7 4.4.3 Mapping from Traffic Bearers to Transport Bearers ............................................................. 4-7 4.5 Summary ..................................................................................................................................... 4-12
5 Load Control ..............................................................................................................................5-1

5.1 Overview of Load Control .............................................................................................................. 5-1 5.2 Definition and Calculation of Transmission Load .......................................................................... 5-2 5.3 Calculation of Reserved Bandwidth .............................................................................................. 5-2 5.3.1 Calculation of Bandwidth Reserved for 2G Signaling .......................................................... 5-2 5.3.2 Calculation of Bandwidth Reserved for Traffic ..................................................................... 5-3 5.4 Load Thresholds............................................................................................................................ 5-4 5.5 Admission Control ......................................................................................................................... 5-4 5.5.1 Admission Process ............................................................................................................... 5-5 5.5.2 Admission Strategy ............................................................................................................... 5-5 5.5.3 Load Sharing ........................................................................................................................ 5-8 5.5.4 Load Balancing ..................................................................................................................... 5-9 5.5.5 Preemption ......................................................................................................................... 5-11 5.5.6 Queuing .............................................................................................................................. 5-12 5.6 Load Reshuffling and Overload Control ...................................................................................... 5-12 5.6.1 Congestion Detection ......................................................................................................... 5-12 5.6.2 Overload Detection ............................................................................................................. 5-13 5.6.3 Congestion and Overload Handling ................................................................................... 5-14 5.7 Summary ..................................................................................................................................... 5-15
6 User Plane Processing ............................................................................................................6-1

6.1 Overview of User Plane Processing.............................................................................................. 6-1 6.2 Scheduling and Shaping ............................................................................................................... 6-2 6.2.1 RNC/BSC Scheduling and Shaping ..................................................................................... 6-2 6.2.2 NodeB Scheduling and Shaping .......................................................................................... 6-3 6.2.3 BTS Shaping ........................................................................................................................ 6-3 6.3 Iub Overbooking ............................................................................................................................ 6-3 6.4 Congestion Control of Iub User Plane .......................................................................................... 6-4 6.5 Downlink Iub Congestion Control Algorithm .................................................................................. 6-5 6.5.1 Overview of the Downlink Iub Congestion Control Algorithm ............................................... 6-5 6.5.2 RNC RLC Retransmission Rate-Based Downlink Congestion Control Algorithm ................ 6-6 6.5.3 RNC Backpressure-Based Downlink Congestion Control Algorithm ................................... 6-8 6.5.4 NodeB HSDPA Adaptive Flow Control Algorithm ................................................................. 6-9 6.6 Uplink Iub Congestion Control Algorithm .................................................................................... 6-12
Issue 03 (2011-09-30)
ii
Contents
6.6.1 Overview of the Uplink Iub Congestion Control Algorithm ................................................. 6-12 6.6.2 NodeB Backpressure-Based Uplink Congestion Control Algorithm (R99 and HSUPA)..... 6-13 6.6.3 NodeB Uplink Bandwidth Adaptive Adjustment Algorithm .................................................. 6-14 6.6.4 RNC R99 Single Service Uplink Congestion Control Algorithm ......................................... 6-15 6.6.5 NodeB Uplink Congestion Control Algorithm for Cross-Iur Single HSUPA Service ........... 6-15 6.7 Dynamic Bandwidth Adjustment Based on IP PM ...................................................................... 6-16
7 Engineering Guidelines...........................................................................................................7-1
7.1 Configuring Co-TRM (with GSM BSC and UMTS RNC Combined) ............................................. 7-1 7.2 Using Default TRMLOADTH Table ................................................................................................ 7-1
8 Parameters .................................................................................................................................8-1 9 Counters ......................................................................................................................................9-1 10 Glossary ..................................................................................................................................10-1 11 Reference Documents .........................................................................................................11-1
Issue 03 (2011-09-30)
iii
1 Introduction
1 Introduction
1.1 Scope
This document mainly describes the management of transmission resources at the base station controller. The transmission resources refer to those carried on the Abis interface of the 2G system and on the Iub interface of the 3G system, and those shared by the Abis and Iub interfaces of the common transmission (co-transmission) system. This document merges the Transmission Resource Management (TRM) feature descriptions of the 2G, 3G, and co-transmission systems. It describes transmission resources, Quality of Service (QoS), load control, user plane processing, and associated parameters. It is applicable for R99, HSDPA, and HSUPA. In this document, HSDPA transport resource management (WRFD-01061014 HSDPA Transport Resource Management) and HSUPA transport resource management (WRFD-01061207 HSUPA Transport Resource Management) mainly refer to the transmission resource mapping and load control.
The base station controllers of the 2G, 3G, and co-transmission systems are BSC, RNC, and Multi-Mode Base Station Controller (MBSC) respectively. MBSC is the GSM+UMTS multi-mode base station controller introduced in Huawei SRAN3.0 solution. SRAN3.0 supports the co-transmission resource management (Co-TRM) feature (corresponding to MRFD-211503 Co-Transmission Resources Management on MBSC) only in the co-transmission scenario where the MBSC is deployed on the base station controller side, and the MBTS is deployed on the base station side. In this scenario, Co-TRM refers to the common management of IP logical ports (LPs) transmission resources when the 2G system and the 3G system implement IP-based co-transmission on the Abis and Iub interfaces. Co-TRM improves the usage of transmission resources and provides the QoS services. In the Co-TRM feature, Abis and Iub share IP LPs, and IP LPs share IP physical transmission resources. The 2G IP paths are independent of the 3G IP paths. Co-TRM implements the common load control and traffic shaping within the shared LPs. SRAN5.0 also supports the Co-TRM feature in the scenario where the GSM BSC and the UMTS RNC are deployed separately, and IP-based co-transmission is implemented on the base station side. In this scenario, Abis and Iub do not share LPs and physical ports. Co-TRM improves the transmission bandwidth utilization in the GSM and UMTS co-transmission scenario. For details, see Bandwidth Sharing of MBTS Multi-Mode Co-Transmission Feature Parameter Description.
1.2 Intended Audience

This document is intended for:

Personnel who are familiar with WCDMA or GSM basics Personnel who need to understand the TRM feature of the 2G, 3G, and co-transmission systems Personnel who work with Huawei products
1.3 Change History

This section provides information on the changes in different document versions. There are two types of changes, which are defined as follows:

Feature change: refers to the change in the Transmission Resource Management feature. Editorial change: refers to the change in wording or the addition of the information that was not described in the earlier version.
Document Issues
The document issues are as follows:
03 (2011-09-30)
Issue 03 (2011-09-30)
1-1

1 Introduction
02 (2011-03-30) 01 (2010-05-15) Draft (2010-03-30)
03 (2011-09-30)
This is the document for the third commercial release of SRAN5.0. Compared with 02 (2011-03-30) of SRAN5.0, this issue incorporates the following changes: Change Type Feature change Editorial change Change Description None Parameter Change None.
The algorithm for NodeB backpressure-based uplink None. congestion control is optimized. For details, see the section "NodeB Backpressure-Based Uplink Congestion Control Algorithm (R99 and HSUPA)."
02 (2011-03-30)
This is the document for the second commercial release of SRAN5.0. Compared with 01 (2010-05-15) of SRAN5.0, this issue incorporates the following changes: Change Type Feature change Editorial change Change Description None Optimized the description of principles of load balancing. For details, See "Principles of Load Balancing". Parameter Change None. None.
01 (2010-05-15)
This is the document for the first commercial release of SRAN5.0. Compared with Draft (2010-03-30) of SRAN5.0, this issue optimizes the description.
Draft (2010-03-30)
This is the draft of the document for SRAN5.0. Compared with 03 (2010-01-20) of SRAN3.0, this issue incorporates the following changes: Change Type Feature change Change Description The description of LPs at the BTS is added. Parameter Change None.
The description of Co-TRM in the MBTS None. co-transmission scenario where the GSM BSC and the UMTS RNC are deployed separately is added. Editorial change None. None.
Issue 03 (2011-09-30)
1-2
2 Overview of TRM
2 Overview of TRM
2.1 Definition of TRM
TRM is the management of transmission resources on the interfaces in various networking modes. The transmission interfaces of the 2G system include Abis, Ater, and A; the transmission interfaces of the 3G system include Iub, Iur, Iu-CS, and Iu-PS. Compared with the transmission on the other interfaces, the transmission on the Abis and Iub interfaces has higher costs, more complicated networking modes, and greater impact on system performance. Therefore, this document mainly describes the TRM for the Iub and Abis interface. In the co-transmission system, TRM implements common management of transmission resources shared by the Abis and Iub interfaces and so TRM is also focused on the Abis and Iub interfaces. TRM in the co-transmission system is called Co-TRM. Transmission resources are one type of resource that the radio network access 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.
2.2 Structure of TRM Functions

Figure 2-1 shows the structure of TRM functions.
Issue 03 (2011-09-30)
2-1
2 Overview of TRM
Figure 2-1 Structure of the TRM functions
As shown in Figure 2-1, the TRM feature covers the following aspects:

Transmission resources involved in TRM include physical and logical resources. For details, see section 3 "Transmission Resources." Load control is applied to the control plane in TRM. It includes admission control, load reshuffling (LDR), and overload control (OLC). For details, see section 5 "Load Control." QoS priority mapping, shaping, and scheduling, dynamic bandwidth adjustment based on IP Performance Monitor (PM), and congestion control are applied to the user plane in TRM. For details, see section 4 "Quality of Service" and 6 "User Plane Processing."
Issue 03 (2011-09-30)
2-2
2 Overview of TRM
2.3 Similarities and Differences Between 2G, 3G, and Co-Transmission Systems
2.3.1 Transmission Resources
Overview
In the SingleRAN 3.0 solution, the related concepts and configurations of the 2G and 3G systems in IP transmission mode are almost the same.
The
2G and 3G systems can use the same physical transmission resources, data link layer protocols, and IP-based interface boards. For details, see section 3.2.4 "Physical and Data Link Layer Resources for IP Transmission." concepts and functions of LPs, resource groups, and paths for the 2G and 3G systems are the same. For details, see section 3.3 "Logical Ports and Resource Groups." 2G and 3G systems can use the same commands to configure LPs, resource groups, and IP paths. For details, see section 3.3.3 "IP LPs at the BSC/RNC/MBSC", 3.3.6 "Resource Groups at the BSC/RNC", and 3.4.2 "IP Paths."
The The
The Abis interface of the 2G system and the Iub interface of the 3G system are applied to almost the same networking scenarios, which include direct connection, bandwidth variation, and convergence. For details, see section 3.5.1 "2G and 3G Networking."
Characteristics of 2G TRM
The 2G system supports the TDM and HDLC transmission modes. For details about available transmission resources, see section 3.2.2 "Physical Layer Resources for TDM " and 3.2.3 "Physical and Data Link Layer Resources for HDLC Transmission."
The 3G system supports the ATM transmission mode. Transmission resources of the 3G system are classified into physical transmission resources, LPs, resource groups, and path resources. For details, see section 3.2.1 "Physical Layer Resources for ATM ", 3.3.2 "ATM LPs at the RNC", 3.3.6 "Resource Groups at the BSC/RNC", and 3.4.1 "AAL2 Paths." The LPs of the 3G system can also be applied in RAN sharing scenario for transmission resource admission control. For details, see section 3.3.1 "Introduction to LP." The 3G system also supports configuration of NodeB LPs. For details, see section 3.3.4 "LPs at the NodeB." For the Iub hybrid IP transmission mode, non-QoS paths can be further classified into high-quality paths and low-quality paths. For details, see section 3.4.2 "IP Paths." The Iub interface of the 3G system supports the ATM&IP dual stack networking and hybrid IP networking. For details, see section 3.5.1 "2G and 3G Networking."
2.3.2 Load Control

Overview
The 2G system and the 3G system perform load control in respective control planes. Their load control methods include admission control, LDR, and OLC. For details, see section 5 "Load Control."
For
the ATM, IP, and HDLC transmission modes, the definitions and calculation methods of transmission load of the 2G and 3G systems are the same. For details, see section 5.2 "Definition and Calculation of Transmission Load."
Issue 03 (2011-09-30)
2-3

Both
2 Overview of TRM
2G system and 3G system make requests for admission of services according to the bandwidth reserved for services, and both calculate the bandwidth reserved for services based on activity factors. For different services of the 2G and 3G systems, the reserved bandwidth differs. For details, see section 5.3.2 "Calculation of Bandwidth Reserved for Traffic." the process of transmission resources admission control, the 2G and 3G systems have the same admission processes, the same admission strategies, and the same principles of preemption and queuing. Switches and actions of preemption and queuing in the 2G and 3G systems are different. For details, see section 5.5 "Admission Control." the processes of LDR and OLC, the principles of congestion and overload detection for the 2G and 3G systems are the same, but the procedures for handling congestion and overload are different. For details, see section 5.6 "Load Reshuffling and Overload Control." 2G and 3G systems use the same load threshold table template and use the same command to configure the table. For details, see section 5.4 "Load Thresholds," 2G and 3G systems use the same activity factor table template and use the same command to configure the table. For details, see section 5.3.2 "Calculation of Bandwidth Reserved for Traffic."
In
In
In the SRAN3.0 solution:

The The
The 2G Abis signaling needs to calculate the reserved bandwidth. For details, see section 5.3.1 "Calculation of Bandwidth Reserved for 2G Signaling."

The GBR of BE services of the 3G system are configurable. For details, see section 5.3 "Calculation of Reserved Bandwidth." In Iub hybrid transmission mode, the admission of primary and secondary paths is supported in the process of transmission resource admission. For details, see section 5.5.4 "Load Balancing."
2.3.3 User Plane Processing and QoS

Overview
The 2G and 3G systems implement leaf LP shaping and hub LP scheduling functions in respective user planes. The related concepts and principles are the same. For details, see section 6.2 "Scheduling and Shaping." The 2G and 3G systems implement the adjacent-node-oriented mapping from services to transmission resources in respective user planes. The related concepts such as DSCP and queue priority are the same. For details, see 4.2 "Transport Priorities." In the SRAN3.0 solution, the 2G and 3G systems use the same TRMMAP table template and use the same command to configure the mapping from services to transmission resources. For details, see section 4.4 "Transmission Resource Mapping."

In HDLC transmission mode, the HDLC also supports shaping and scheduling functions. For details, see section 6.2.1 "RNC/BSC Scheduling and Shaping." The mapping from 2G Abis signaling services to transmission resources is not oriented to adjacent nodes and therefore needs to be configured separately. For details, see "Mapping from Abis Signaling Traffic to Transmission Resources."
Issue 03 (2011-09-30)
2-4
2 Overview of TRM

The NodeB of the 3G system also supports shaping and scheduling functions. For details, see section 6.2.2 "NodeB Scheduling and Shaping." The Iub interface of the 3G system implements a series of congestion control algorithms in the user plane. For details, see section 6.3 "Iub Overbooking." When the mapping from services to transmission resources is configured, the 3G services are differentiated by user priority, traffic priority, and type of radio bearer. The 3G system also supports configuration of primary and secondary paths. For details, see sections 4.3 "Service QoS" and 4.4 "Transmission Resource Mapping."
2.3.4 Differences of Co-TRM From 2G TRM and 3G TRM

Characteristics of Co-TRM in SRAN3.0:

The Abis interface of the 2G system and the Iub interface of the 3G system share IP LPs, and IP LPs share physical IP transmission resources. Within a shared LP, common load control is implemented based on common load thresholds, that is, common admission strategies and common congestion and overload detection. In the process of handling overload caused by LP admission, the 2G and 3G systems reserve bandwidth proportionally. For details, see section 5.6.3 "Congestion and Overload Handling." Common traffic shaping is implemented within a shared LP. Co-TRM is applicable only to one of the co-transmission networking scenarios. For details, see section 3.5.2 "Co-Transmission Networking."
In SRAN5.0, the Co-TRM in the scenario where the GSM BSC and the UMTS RNC are deployed separately, and the GSM and UMTS systems do not share the LPs. In Co-TRM, the management of GSM and UMTS transmission resources is similar to 2G TRM and 3G TRM. The only difference is that Co-TRM has special requirements for BSC or RNC configurations to improve transmission bandwidth utilization. Co-TRM inherits the concepts, principles, and functions of 2G TRM and 3G TRM, which include concepts and functions of paths and LPs, definition and calculation of load, calculation of bandwidth reserved for services, principles and methods of load control, transmission resource mapping, and LP shaping and scheduling. In the Co-TRM feature:

2G IP paths and 3G IP paths are mutually independent. The 2G system and the 3G system implement transmission resource mapping separately. The 2G system and the 3G system calculate reserved bandwidth separately. The 2G system and the 3G system set preemption and queuing switches separately, and take preemption and queuing actions separately. The 2G system and the 3G system handle congestion and overload separately.
2.4 Benefits of TRM

TRM increases the system capacity with the QoS guaranteed and provides differentiated services.
Real-time (RT) services, such as conversational and streaming services RT services do not allow packet loss and are sensitive to delay. The activity of RT services follows an obvious rule. When multiple services access the network, the total actual traffic volume is relatively stable.
Issue 03 (2011-09-30)
2-5

Through
2 Overview of TRM
the transmission resource mapping, RT services can be mapped to high-priority paths and thus be transmitted preferentially when congestion occurs. This reduces packet loss and transmission delay. For details, see section 4 "Quality of Service." services are admitted at the Maximum Bit Rate (MBR). With appropriate activity factors configured, the access of more users are allowed under the condition that the QoS is guaranteed. Overload control and preemption can achieve differentiated services. For details, see section 5 "Load Control."
RT
Non-real-time (NRT) services, such as interactive and background services NRT services do not have strict requirements for bandwidth. When transmission resources are insufficient, the data can be buffered to reduce the traffic throughput. The activity of NRT services does not follow an obvious rule. When multiple services access the network, the total actual traffic volume fluctuates significantly.
Through
transmission resource mapping, NRT services can be mapped to low-priority paths and thus the QoS of RT services can be guaranteed preferentially. For details, see section 4 "Quality of Service." TRM feature provides the Guaranteed Bit Rate (GBR) and a user plane congestion control algorithm, which allow the access of more users under the condition that the QoS is guaranteed. For details, see section 6 "User Plane Processing." the Scheduling Priority Indicator (SPI) weighting, bandwidth allocation for NRT services can be differentiated. For details, see section 6 "User Plane Processing." SPI is used to indicate the scheduling priorities of services, and SPI weighting is used to adjust the queuing priorities of scheduling services or to proportionally allocate bandwidth to services in Iub congestion control. A larger SPI weight indicates a higher queuing priority or a higher bandwidth allocated to the Iub interface.
The
Through
Signaling, such as Signaling Radio Bearer (SRB), Session Initiation Protocol (SIP), Network Control Protocol (NCP), Communication Control Port (CCP), and Abis interface signaling The traffic volume of signaling is low and its performance is closely related to Key Performance Indexes (KPIs) of the network. Therefore, through transmission resource mapping, signaling can be mapped to high-priority paths and the transmission of signaling takes precedence, thus preventing packet loss and transmission delay.
Issue 03 (2011-09-30)
2-6
3 Transmission Resources
3.1 Overview of Transmission Resources
The 2G, 3G, and co-transmission systems can use the transmission resources described in Table 3-1. Table 3-1 Transmission resources used by the 2G, 3G, and co-transmission systems Transmission Resource TDM HDLC IP ATM 2G System 3G System Co-Transmission System -
ATM transmission resources and IP transmission resources can be further classified into physical resources, logical ports, resource groups, and paths. In TDM and HDLC transmission, the user plane data is carried on the timeslots of physical ports. Figure 3-1, Figure 3-2, Figure 3-3 and Figure 3-4 show examples of different transmission resources. Figure 3-1 ATM transmission resources
Issue 03 (2011-09-30)
3-1
Figure 3-2 IP transmission resources of the 3G system
Figure 3-3 IP transmission resources of the 2G system
Issue 03 (2011-09-30)
3-2
Figure 3-4 IP transmission resources of the co-transmission system
3.2 Physical Transmission Resources

Table 3-2 describes the physical transmission resources used by the 2G, 3G, and co-transmission systems. Table 3-2 Physical transmission resources used by the 2G, 3G, and co-transmission systems Physical 2G TDM 2G HDLC 2G IP 3G ATM 3G IP Co-Transmissio Transmissio Transmissio Transmissio Transmissio Transmissio Transmissio n System n Resource n n n n n E1/T1 electrical port FE/GE electrical port GE optical port -
Unchannelize d STM-1/OC-3c optical port Channelized STM-1/OC-3 optical port Flex Abis resource pool
Issue 03 (2011-09-30)
3-3
3.2.1 Physical Layer Resources for ATM Transmission

The physical ports for ATM transmission are as follows: Physical Port E1/T1 electrical port Transmission Mode

IMA UNI Fractional ATM IMA UNI Fractional ATM
Channelized STM-1/OC-3 optical port
Unchannelized STM-1/OC-3c optical port NCOPT
3.2.2 Physical Layer Resources for TDM Transmission

The physical ports for TDM transmission are as follows:

E1/T1 electrical port Channelized STM-1/OC-3 optical port
In TDM transmission on the Abis interface, Abis timeslots can be shared as a Flex Abis pool within the BSC. For details about Flex Abis, see Flex Abis Feature Parameter Description of the GBSS.
3.2.3 Physical and Data Link Layer Resources for HDLC Transmission
HDLC resources include physical layer resources and data link layer resources, which are listed as follows:

Physical layer resources include E1/T1 electrical port and channelized STM-1/OC-3 optical port. Data link layer resources refer to HDLC channels.
3.2.4 Physical and Data Link Layer Resources for IP Transmission

Table 3-3 describes the physical ports and data link layer protocols for IP transmission. Table 3-3 Physical ports for IP transmission Physical Port E1/T1 electrical port FE/GE electrical port GE optical port Unchannelized STM-1/OC-3c optical port Data Link Layer Protocol PPP/MLPPP Ethernet Ethernet PPP/MLPPP 2G System 3G System Co-Transmission System -
Issue 03 (2011-09-30)
3-4
Physical Port Channelized STM-1/OC-3 optical port
Data Link Layer Protocol PPP/MLPPP
2G System 3G System
Co-Transmission System
3.3 Logical Ports and Resource Groups

Logical Ports (LPs) and resource groups are applicable to the 2G, 3G, and co-transmission systems, as described in Table 3-4. Table 3-4 LPs and resource groups applicable to the 2G, 3G, and co-transmission systems LP and 2G TDM 2G HDLC 2G IP 3G ATM 3G IP Co-Transmission Resource Transmission Transmission Transmission Transmission Transmission System Group ATM LP IP LP -
Resource group
3.3.1 Introduction to LPs

LPs are used to configure bandwidth at transmission nodes and perform bandwidth admission and traffic shaping to prevent congestion. After the physical ports and paths are configured, the system can start to operate and services can be established. There are problems, however, in the following scenarios:
Transmission aggregation
Transmission
aggregation exists either on the transport network (for example, aggregation of NB1 and NB2, as shown in Figure 3-5) or at the hub NodeB or hub BTS (for example, aggregation of NB3 and NB4 at NB1, as shown in Figure 3-5). only physical ports and paths are configured, the bandwidth constraints at the aggregation nodes are unavailable. As shown in Figure 3-5, the total available bandwidth BW0 of NB1 through NB4 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, in the downlink the total volume of data sent to NB2 may exceed BW2, and congestion and packet loss may occur.
If
Issue 03 (2011-09-30)
3-5
Figure 3-5 Transmission aggregation on the Iub or Abis interface
NB: NodeB or BTS
BW: bandwidth
BW0: bandwidth of physical ports on the RNC or BSC or MBSC
RAN sharing in the RNC

In
this scenario, operators share the bandwidth at one NodeB and the bandwidth needs to be configured for each operator so that the bandwidth used by each operator does not exceed their respective reserved bandwidth. only physical ports and paths are configured, the preceding requirement cannot be fulfilled.
If
To solve the preceding problems, the LP concept is introduced to the TRM feature.

An LP indicates 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 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. Multiple levels of IP LP are supported.
In the 3G TRM, LPs need to be configured on both the RNC and NodeB sides; in the 2G TRM, LPs need to be configured only on the BSC side; in the Co-TRM, LPs need to be configured only on the MBSC side. LPs are configured on the RNC or BSC or MBSC side for the following purposes:

To implement admission control in the aggregation or RAN sharing scenario in the RNC To implement traffic shaping in the downlink
LPs are configured on the NodeB side for the following purposes:
To achieve fairness between local data and forwarded data in the aggregation scenario
Issue 03 (2011-09-30)
3-6
To implement traffic shaping in the RAN sharing scenario
For details about LP shaping, see section 6.2 "Scheduling and Shaping."
3.3.2 ATM LPs at the RNC

ATM LPs, also called Virtual Ports (VPs), provide the functions of ATM traffic shaping and bandwidth admission. They can be configured on ATM interface boards through the ADD ATMLOGICPORT command. These LPs have the following attributes:

Types of LP: hub LP and leaf LP 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: SHARE or EXCLUSIVE, which indicates whether operators in the RAN sharing scenario share the Iub transmission resources.
When the ADD AAL2PATH, ADD SAALLNK, or ADD IPOAPVC command is executed to specify the bearer type of an AAL2 path, an SAAL link, or an IPoA PVC as ATMLOGICPORT, the path, link, or PVC can be set to join an LP. The parameters associated with ATM LPs are as follows:

LPNTYPE TXBW RXBW RSCMNGMODE
In the ATM transmission aggregation scenario, LPs need to be configured for each NodeB and at each aggregation node; in the RAN sharing scenario, an LP needs to be configured for each operator that shares the NodeB. As shown in Figure 3-6, below is an example of transmission aggregation.
Issue 03 (2011-09-30)
3-7
Figure 3-6 Transmission aggregation 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 relationship 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. 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 transmission resource admission 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.
The RNC supports multi-level shaping (a maximum of five levels), which involves leaf LPs and hub LPs.
3.3.3 IP LPs at the BSC/RNC/MBSC

IP LPs have the functions of IP traffic shaping and bandwidth admission. They can be configured on IP interface boards through the ADD IPLOGICPORT command. These LPs have the following attributes:

Types of LP: hub LP and leaf LP 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: SHARE or EXCLUSIVE, which indicates whether operators in the RAN sharing scenario share the Iub transmission resources.
Issue 03 (2011-09-30)
3-8
When the ADD IPPATH command is executed to specify the bearer type of IP path as IPLGCPORT, or when the RNC and MBSC bind the IP LPs through the ADD SCTPLNK command, 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 supports a maximum of five levels of IP LPs. The parameters associated with IP LPs are as follows:

LPNTYPE RSCMNGMODE CIR OAMFLOWBW
3.3.4 LPs at the NodeB

LPs at the NodeB have the function of traffic shaping, which are mainly used to differentiate operators in the RAN sharing scenario. ATM or IP LPs can be configured on the interface board through the ADD RSCGRP command. The LPs have the following attributes:

Types of LPs: ATM and IPv4 Transmit bandwidth: used for traffic shaping Receive bandwidth: used to calculate the remaining bandwidth for backpressure-based flow control Port types
For ATM For
LPs, the port types are IMA, UNI, fractional ATM, and unchannelized STM-1.
IP LPs, the port types are PPP, MLPPP group, and Ethernet port.
In ATM transmission mode, 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. In IP transmission mode, when the ADD IPPATH command is executed to add an IP path, the path can be set to join an LP so as to add the data traffic volume carried on the path of the local NodeB to the LP. The MML command ADD IP2RSCGRP is executed to bind an LP to the target IP network segment. The command is executed to join the signaling stream, OM traffic, and forwarded data traffic to a specified LP. The parameters associated with LPs at the NodeB are as follows:

BEAR PT TXBW RXBW
The LP capabilities of NodeB interface boards are as follows:

Each physical port of the NodeB supports a maximum of four IP LPs. When a Main Processing & Transmission interface board (WMPT) is configured, each interface board supports a maximum of 4 ATM LPs or a maximum of 8 IP LPs. When other interface boards are configured, each interface board supports a maximum of 16 ATM LPs or a maximum of 8 IP LPs.
Issue 03 (2011-09-30)
3-9
3.3.5 LPs at the BTS

In IP over FE/GE transmission mode, you can run the MML command ADD BTSIPLGCPORT to configure LPs at the BTS. The TXBW parameter is used for traffic shaping in the GSM and UMTS co-transmission to reduce the impact of GSM uplink traffic on the UMTS uplink traffic. The MML command ADD BTSIPTOLGCPORT is used to bind the LPs to the target IP addresses of LPs. The command is executed to join the signaling stream, OM traffic, and data traffic to the LPs.
3.3.6 Resource Groups at the BSC/RNC

Resource groups support bandwidth admission but do not support traffic shaping. Resource groups are applicable to ATM and IP transmission modes. Multiple levels of transmission resource groups are supported. To add a resource group, run the ADD RSCGRP command. To join an IP path to a resource group, run the ADD IPPATH command. To associate with ATM paths, run the ADD AAL2PATH command.
On the RNC or BSC side, LPs cannot contain transmission resource groups, and transmission resource groups cannot contain LPs either.
3.4 Path Resources

Path resources comprise paths in the control plane, user plane, and management plane. The paths in the user plane, that is, AAL2 paths for ATM transmission and IP paths for IP transmission, are key resources. The allocation and management of transmission resources are based on paths. Table 3-5 describes the path resources that can be used by the 2G, 3G, and co-transmission systems. Table 3-5 Path resources that can be used by the 2G, 3G, and co-transmission systems Path 2G TDM 2G HDLC 2G IP 3G ATM 3G IP Co-Transmission Resource Transmission Transmission Transmission Transmission Transmission System AAL2 path IP path
3.4.1 AAL2 Paths

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

CBR RT-VBR NRT-VBR UBR
The AAL2 path can be configured through the ADD AAL2PATH command. When an AAL2 path is configured, the TXTRFX and RXTRFX parameters need to be set by running ADD ATMTRF command. These parameters determine the type of the AAL2 path.
3.4.2 IP Paths
IP paths can be classified into QoS paths and non-QoS paths.
Issue 03 (2011-09-30)
3-10
On QoS paths, different services share the bandwidth of paths. The Per Hop Behavior (PHB) of IP paths is determined by transmission resource mapping. For details about transmission resource mapping, see section 4.4 "Transmission Resource Mapping." PHB is the next-hop behavior of the IP path. Services can be prioritized based on the mapping from PHB to DSCP.
On non-QoS paths, different services do not share the bandwidth of IP paths. The PHB of IP paths is determined by the path type. Non-QoS paths can be further classified into high-quality paths and low-quality paths. The low-quality path, denoted as LQ_xxx, is applicable to only hybrid IP transmission on the Iub interface. In hybrid IP transmission mode, if the physical port is an PPP or MLPPP port, high-quality paths are configured; if the physical port is an Ethernet port, low-quality paths are configured. For details about the hybrid IP transmission on the Iub interface, see section 3.5.1 "2G and 3G Networking."
The IP path can be configured through the ADD IPPATH command. For details about the classification of non-QoS paths, see Table 3-6. Table 3-6 Classification of non-QoS paths High-Quality Path BE AF11 AF12 AF13 AF21 AF22 AF23 AF31 AF32 AF33 AF41 AF42 AF43 EF Low-Quality Path LQ_BE LQ_AF11 LQ_AF12 LQ_AF13 LQ_AF21 LQ_AF22 LQ_AF23 LQ_AF31 LQ_AF32 LQ_AF33 LQ_AF41 LQ_AF42 LQ_AF43 LQ_EF
Issue 03 (2011-09-30)
3-11

NOTE

On the Iu-PS interface, even if IPoA transmission is used, IP paths still need to be configured. High Speed Downlink Packet Access (HSDPA) and High Speed Uplink Packet Access (HSUPA) services can be carried on the same IP path, with HSDPA services carried in the downlink and HSUPA services carried in the uplink.
3.5 Networking Application

3.5.1 2G and 3G Networking
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. Transmission aggregation: As shown in Figure 3-5, the Iub traffic volume of more than one NodeB is converged, for example, on the transport network or at the hub NodeB. 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. ATM&IP dual stack: Both ATM and IP transmission resources are available for one Iub interface so that the transmission cost is reduced. Hybrid IP: Both high-QoS transmission (such as IP over E1) and low-QoS transmission (such as IP over FE) are applicable to one Iub interface so that differentiated management of services is implemented. RAN sharing: Operators share the physical bandwidth. In this scenario, bandwidth should be reserved for each operator.
The typical networking scenarios for the Abis interface are similar to the Iub interface, except that networking scenarios such as dual stack, hybrid IP, and RAN sharing are not applied to the Abis interface. For details about the 2G and 3G networking, see the IP BSS Feature Parameter Description of the GBSS and the IP RAN Feature Parameter Description of the RAN.
Table 3-7 lists the types of transmission applicable to each interface. Table 3-7 Types of transmission applicable to each interface Interface Iub Iur Iu-CS Iu-PS Abis A Ater Pb Gb ATM TDM HDLC IP ATM&IP Dual Stack Hybrid IP -
Issue 03 (2011-09-30)
3-12
The IP transmission mode of the Ater interface supports only TDM networking on IP over E1.
3.5.2 Co-Transmission Networking

Co-TRM is applied to the following co-transmission networking scenarios: Figure 3-7 Co-transmission scenario where the GSM BSC and the UMTS RNC are combined
GSM+UMTS MBSC deployed and GSM+UMTS MBTSs deployed GSM+UMTS MBTS sharing IP LP transmission resources over the Abis and Iub interfaces
Figure 3-8 Co-transmission scenario where the GSM BSC and the UMTS RNC are deployed separately
BSC and RNC separately deployed, without sharing physical ports GSM+UMTS MBTS deployed, sharing physical ports
For details about the co-transmission networking, see the Common Transmission Feature Parameter Description.
Issue 03 (2011-09-30)
3-13
4 Quality of Service
4.1 Overview
The purpose of TRM algorithms is to guarantee the Quality of Service (QoS). Different types of service have different QoS requirements.
The Iub or Abis control plane and the Uu signaling require reliable transmission. Packet loss rate and delay may affect KPIs such as connection delay, handover success rate, access success rate, and call drop rate. CS services have requirements for delay and packet loss rate. For example, speech services are sensitive to end-to-end latency, and data services are sensitive to packet loss. NRT services are relatively insensitive to delay, but in some scenarios, they are sensitive to delay. When the load is light, the requirement for delay should be fulfilled. whereas when the load is heavy, the requirement for delay can be lowered to a certain extent to guarantee the throughput.
The transport layer provides various transport bearers and transport priorities. The appropriate type of transport bearer and transport priority should be selected according to the traffic classes, user priorities, traffic priorities, and radio bearer type of service. High-priority services take precedence in transmission when congestion occurs. This reduces packet loss and transmission delay. Transmission resource mapping maps services of different QoS requirements to different transport bearers. Transmission resource mapping (WRFD-050424 Traffic Priority Mapping onto Transmission Resources) is an important method to guarantee the QoS and differentiate the users and services. It mainly involves data in the user plane. This section describes transmission resource mapping and associated concepts such as transport priorities and service QoS. For the differences in implementing QoS-related services in the 2G TRM, 3G TRM, and Co-TRM, see the following sections.
4.2 Transport Priorities

Transport priority-related concepts include Differentiated Service Code Point (DSCP), Virtual Local Area Network (VLAN) priority, and Priority Queue (PQ).
4.2.1 DSCP
The 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 required. DSCP provides differentiated services (DiffServ) for layer 3 (L3). When entering the network, services are differentiated and subject to flow control according to the QoS requirement. In addition, the DSCP fields of the packets are set. The DSCP field is in the header of each IP packet. On the network, DiffServ is applied to different types of traffic according to the DSCP values and services for the traffic are provided. 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. Policies for using DSCP are as follows:

The traffic carried on QoS paths uses the DSCPs mapped from services. For details, see "Mapping from TC to PHB or PVC" and "Mapping from PHB to DSCP." The traffic carried on the non-QoS path uses the DSCP that the PHB of the IP path corresponds to. For details, see "Mapping from PHB to DSCP."
Issue 03 (2011-09-30)
4-1
It is recommended that you set the path type to QoS path when configuring the IP path. This ensures simple configuration, better multiplexing, and higher QoS.
4.2.2 VLAN Priorities

VLAN provides services of different priorities to isolate different users and enhance security of IP transport network. VLAN provides differentiated services for layer 2 (L2). The principles of VLAN priorities are similar in the 2G and 3G systems. This section takes the VLAN solution of the 3G system as an example. Figure 4-1 shows a typical example of the VLAN solution on the Iub interface. In this solution, the Multi-Service Transmission Platform Network (MSTP) provides two Ethernets carried on two different Virtual Channel (VC) trunks.

One Ethernet is a private network for RT services of multiple NodeBs. The RT services in this Ethernet are not affected by other services and thus used for carrying high-priority services. The other Ethernet is a public network for NRT services of multiple NodeBs. It can be shared by other services. The NRT services in this Ethernet might be affected by other services and thus used for carrying low-priority services.
Figure 4-1 Typical example of solution of the VLAN on the Iub interface
Red line: private network
Blue line: public network
Black line: connection between routers
Each NodeB or RNC provides an Ethernet port that connects to the MSTP network. The MSTP transmits the Ethernet data of different QoS to either of the VC trunks according to the VLAN priority in the frame header of Ethernet data. On the same VC trunk, different NodeB data is distinguished by VLANID. Figure 4-2 shows an example of using VLAN priorities.
Issue 03 (2011-09-30)
4-2
Figure 4-2 Example of using VLAN priorities
The RNC, NodeB1, and NodeB2 are connected to the same L2 network. Data of NodeB1 (VLAN 10) and NodeB2 (VLAN 20) is isolated according to different VLANIDs. VLANIDs are attached to data of different traffic classes sent from the Ethernet port. Data of different traffic classes use VLAN priorities mapped from DSCP. Then, the L2 network provides differentiated services based on the VLAN priorities. When IP paths are configured, the VLANFLAG parameter specifies whether a VLAN is available. Table 4-1 describes the default mapping from DSCP to VLANPRI. Table 4-1 Default mapping from DSCP to VLANPRI DSCP 0-7 8-15 16-23 24-31 32-39 40-47 48-55 56-63 VLANPRI 0 1 2 3 4 5 6 7
Issue 03 (2011-09-30)
4-3
You can run the SET DSCPMAP command to dynamically configure the mapping from DSCP to VLANPRI.
4.2.3 Priority Queues

At each ATM port (such as IMA, UNI, fractional ATM, or NCOPT port) or leaf LP of the RNC, there are five types of priorities, as shown in Figure 4-3. The scheduling order is as follows: CBR > RT-VBR > UBR+ (MCR) > WRR (NRT-VBR, UBR) > UBR+ (non-MCR), where MCR refers to Minimum Cell Rate. Figure 4-3 Queues at each ATM port or leaf LP of the RNC
At each IP port (such as PPP/MLPPP or Ethernet port) or leaf LP of the RNC, BSC or MBSC, there are six types of priorities, as shown in Figure 4-4. The default scheduling order is as follows: Queue1 > Queue2 > WRR (Queue3, Queue4, Queue5, and Queue6), where WRR refers to Weighted Round Robin. Figure 4-4 Queues at each IP port or leaf LP of the RNC
Different types of services enter queues of different priorities for transmission. In this way, services are differentiated. For details, see section 4.4.3 "Mapping from Traffic Bearers to Transport Bearers." At each ATM port (such as IMA, UNI, fractional ATM, or NCOPT port) or LP of the NodeB, there are four types of priorities, as shown in Figure 4-5. The scheduling order is as follows: CBR or UBR+ (MCR) > RT-VBR > NRT-VBR > UBR or UBR+ (non-MCR).
Issue 03 (2011-09-30)
4-4
Figure 4-5 Queues at each ATM port or LP of the NodeB
At each IP port (such as PPP/MLPPP or Ethernet port) or LP of the NodeB, there are six types of priorities, as shown in Figure 4-6. The default scheduling order is as follows: Queue1 > WFQ (Queue2, Queue3, Queue4, Queue5, and Queue6). Where, WFQ refers to Weighted Fair Queuing. Figure 4-6 Queues at each IP port or LP of the NodeB
Priority queues are used for RNC backpressure-based downlink congestion control. For details, see section 6.5.3 "RNC Backpressure-Based Downlink Congestion Control Algorithm."
In the 2G TRM, there are no priority queues at the BTS.
4.2.4 Priority Queues and Rate Limiting in the NodeB

The NodeB automatically configures priority queues (PQs). PQ and Rate Limiting (RL) supplement each other. When the actual bandwidth exceeds the specified bandwidth, the NodeB buffers or discards the congested data to ensure the bandwidth at the physical port. When the physical port is congested, the NodeB discards low-priority packets according to the PQ rules. Table 4-2 describes the PQ rules based on the Most Significant Bits (MSBs) of DSCP in the NodeB. Table 4-2 PQ rules in the NodeB MSB of DSCP 110 or 111 101 100 or 011 010 or 001 0 PQ Default urgent queue; manual configuration of PQ is not required. TOP MIDDLE NORMAL BOTTOM
Issue 03 (2011-09-30)
4-5
Parameters associated with PQs in the NodeB are as follows:

SIGPRI OMPRI PTPPRI
4.3 Service QoS

For service QoS, the following aspects need to be taken into consideration:

Traffic classes at the radio network layer: conversational service, streaming service, interactive service, and background service, which are in descending order of QoS requirement. User priorities: Services of the same traffic class can be differentiated based on the ARP.
The
radio access network (RAN) provides DiffServ for users with different priorities based on the Allocation Retention Priority (ARP). ARP is a core network (CN) QoS parameter regarding user priorities. are three user priorities, that is, gold, silver, and copper. The relation between user priority and ARP can be set through SET UUSERPRIORITY command. 2G and 3G systems differentiate user priorities, but the 2G system uses the ARP for admission, and there is no mapping from user priority to ARP.
There Both
Traffic Handling Priority (THP): Interactive services of the same ARP can be differentiated based on the THP. THPs are classified into high priority, middle priority, and low priority. The transport network layer of the 2G system does not differentiate THPs. Types of radio bearer: Radio bearers represent the service types of bearers, including R99 and HSPA (HSUPA and HSDPA). Interactive services of the same ARP and THP can be differentiated based on the parameter CarrierTypePriorInd.
For details about user priorities and THP, see the Load Control Feature Parameter Description of the RAN.
4.4 Transmission Resource Mapping

Transmission resource mapping refers to the mapping from traffic bearers to transport bearers. The RNC and BSC support configuration of mapping to transport bearers according to the characteristics of service QoS.
4.4.1 Traffic Bearers

For 2G services, traffic bearers refer to the traffic class (TC) of the 2G system; for 3G services, traffic bearers refer to the combination of TC, ARP, THP, and type of radio bearer that corresponds to one transport bearer. The RNC provides the following traffic classes that can be used in transmission resource mapping configuration:

Common channel SRB SIP AMR speech service CS conversational service CS streaming service
Issue 03 (2011-09-30)
4-6

PS conversational service PS streaming service PS interactive service PS background service
The BSC provides the following traffic classes that can be used in transmission resource mapping configuration:

Abis OML Abis RSL Abis ESL Abis EML CS speech service CS data service PS data service
2G Abis signaling traffic classes have higher QoS requirement than other traffic classes, except Abis EML.
4.4.2 Transport Bearers

Transport bearers refer to transmission of traffic on a certain type of paths. For details about the types of paths for transport bearers, see section 3.4 "Path Resources." Priorities of paths are the basis of transmission resource mapping:

Priorities of ATM paths are specified by the Pre-defined Virtual Connection (PVC). Priorities of IP paths are specified by PHB. PHB is then indicated by the DSCP priority.
4.4.3 Mapping from Traffic Bearers to Transport Bearers

Overview
For the mapping from traffic bearers to transport bearers, default or dynamic configuration and adjacent-node-oriented or non-adjacent-node-oriented configuration are provided. The keyword used for configuring transmission resource mapping is traffic type. In transmission resource mapping:

For 2G services, each TC corresponds to one priority of transport bearer, as shown in Figure 4-7. For 3G services, each combination of TC, ARP, THP, and type of radio bearer corresponds to one priority of transport bearer, as shown in Figure 4-8.
Issue 03 (2011-09-30)
4-7
Only the mapping of Abis signaling services in the 2G system is non-adjacent-node-oriented configuration. For details, see "Mapping from Abis Signaling Traffic to Transmission Resources." The transmission resource mapping of the RNC also supports configuration of primary and secondary paths. For details, see section 5.5 "Admission Control."
Figure 4-7 2G transmission mapping
Figure 4-8 3G transmission mapping
Issue 03 (2011-09-30)
4-8
Mapping from TC to PHB or PVC

For each combination of interface type and transport type, a transmission resource mapping can be configured by default. The RNC and BSC provide default transmission resource mapping tables (TRMMAP tables) for various networking scenarios. The default TRMMAP table can be queried through the LST TRMMAP command. Table 4-3 describes the default TRMMAP table, where IDs 0 to 8 represent Iub ATM, Iub IP, Iub ATM IP, Iub HYBRID IP, Iur ATM, Iur IP, Iu-CS ATM, Iu-CS IP, and Iu-PS of the RNC respectively, and IDs 10 to 12 represent Abis IP, A IP, and Ater IP of the BSC respectively. Table 4-3 Default TRMMAP table Interface Iub Iur Iu-CS Iu-PS Abis A Ater ATM 0 4 6 IP 1 5 7 8 10 11 12 ATM&IP Dual Stack 2 Hybrid IP 3 -
In HDLC transmission mode, traffic is directly mapped to port queues. The default TRMMAP table differentiates neither operators nor user priorities. If transmission resource mapping is not dynamically configured, the default TRMMAP table is used.
To provide better differentiated services, the RNC and BSC support dynamic configuration of the transmission resource mapping and thus traffic bearers can be mapped to transport bearers freely. The RNC also supports separate configuration of transmission resource mapping under an Iub adjacent node for a certain operator or a certain user priority. To dynamically configure transmission resource mapping, do as follows: Step 1 Run the ADD TRMMAP command to specify the mapping from the TCs of a specific interface type and transport type to a transport bearer. Step 2 Run the ADD ADJMAP command to use the configured TRMMAP table. When the RNC ADJMAP is configured, the TRMMAP tables need to be specified for gold, silver, and copper users respectively.
In the RAN sharing scenario, the operator index needs to be set to specify transmission resource mapping of the operator under the adjacent node, if the resource management mode is set to EXCLUSIVE. When the transmission mode on the Iub interface is ATM&IP dual stack or hybrid IP, the load balance index of primary and secondary paths needs to be configured.
----End The associated parameters are as follows:
ITFT
Issue 03 (2011-09-30)
4-9

TRANST CNMNGMODE CNOPINDEX TMIGLD TMISLV TMIBRZ LEIGLD LEISLV LEIBRZ
Mapping from PHB to DSCP

The service QoS can be mapped to transport QoS by configuring the mapping between PHB and DSCP. Table 4-4 describes the default mapping from PHB to DSCP. Table 4-4 Default mapping from PHB to DSCP PHB EF AF43 AF42 AF41 AF33 AF32 AF31 AF23 AF22 AF21 AF13 AF12 AF11 BE DSCP (Binary) 101110 100110 100100 100010 11110 11100 11010 10110 10100 10010 1110 1100 1010 0 DSCP (Decimal) 46 38 36 34 30 28 26 22 20 18 14 12 10 0
You can run the SET PHBMAP command to dynamically configure the mapping from PHB to DSCP (PHBMAP).

If the traffic is carried on a non-QoS path, the PHB of the path is determined by the path type. Run the SET PHBMAP command to configure PHBMAP. If the traffic is carried on a QoS path, the PHB of the path is determined by the TRMMAP. Run the ADD TRMMAP command to determine the PHB of the path, and then run the SET PHBMAP command to configure PHBMAP.
Issue 03 (2011-09-30)
4-10
Mapping from DSCP to Queue Priority

By configuring the mapping from DSCP to queue priority, you can achieve differentiated services for the traffic classes with different DSCP values according to different queue priorities. Table 4-5 describes the default mapping from DSCP to queue priority. Table 4-5 Default mapping from DSCP to queue priority Minimum DSCP 40 32 24 16 8 0 Queue Priority 0 1 2 3 4 5
You can run the SET QUEUEMAP command to dynamically configure the minimum DSCP value that each queue at the IP port corresponds to. The associated parameters are as follows:

Q0MINDSCP Q1MINDSCP Q2MINDSCP Q3MINDSCP Q4MINDSCP
The minimum DSCP value of queue 5 need not be set. The IP packet that meets the condition (0 <= DSCP value < minimum DSCP value for queue 4) enters queue 5 for transmission.
Mapping from Abis Signaling Traffic to Transmission Resources

You need to configure the mapping from Abis signaling traffic of the BSC to transmission resources independently. Both the default configuration and the dynamically configuration are available for the mapping. You can use the SET BSCABISPRIMAP command to dynamically configure the mapping. Table 4-6 and Table 4-7 describe the default mapping from traffic to transmission resources. Table 4-6 Mapping from traffic to transmission resources in IP transmission mode TC ESL OML RSL EML DSCP 48 48 48 0
Issue 03 (2011-09-30)
4-11
Table 4-7 Mapping from traffic to transmission resources in HDLC transmission mode TC ESL OML RSL EML Queue Priority 0 0 0 5
For IP transmission on the Abis interface, the associated parameters are as follows:

OMLDSCP RSLDSCP EMLDSCP ESLDSCP
For HDLC transmission on the Abis interface, the associated parameters are as follows:

OMLPRI RSLPRI EMLPRI ESLPRI
4.5 Summary
Table 4-8 describes the difference between traffic bearers in the 2G, 3G, and co-transmission systems. Table 4-8 Difference between traffic bearers in the 2G, 3G, and co-transmission systems Traffic Bearer TC ARP THP Radio bearer type 2G System 3G System Co-Transmission System
The 2G system uses the ARP for admission, and there is no mapping from user priority to ARP. The transport layer of the 2G system does not differentiate THPs.
Table 4-9 describes the adjacent-node-oriented transmission resource mapping of the 2G TRM, 3G TRM, and Co-TRM. Table 4-9 Adjacent-node-oriented transmission resource mapping of the 2G TRM, 3G TRM, and Co-TRM Transmission Mode Adjacent-Node-Oriented Transmission Resource Mapping 3G ATM transmission From TC + ARP + THP + radio bearer type to PVC 3G IP transmission From TC + ARP + THP + radio bearer type to PHB, from PHB to DSCP to queue priority
Issue 03 (2011-09-30)
4-12
Transmission Mode Adjacent-Node-Oriented Transmission Resource Mapping 2G HDLC transmission From TC (excluding signaling traffic) to queue priority 2G IP transmission Co-transmission From TC (excluding signaling traffic) to PHB, from PHB to DSCP to queue priority
For 2G services: from TC (excluding signaling traffic) to PHB, from PHB to DSCP to queue priority For 3G services: from TC + ARP + THP + radio bearer type to PHB, from PHB to DSCP to queue priority
The mapping from signaling traffic of the Abis interface of the 2G system to transmission resources is not oriented to adjacent nodes. It needs to be configured independently. In TDM transmission mode of the 2G system, traffic is directly carried on the timeslot at the port. Thus, transmission resource mapping is not required. In IP transmission mode of the 3G system, configuration of primary and secondary paths is also supported.
Issue 03 (2011-09-30)
4-13
5 Load Control
5 Load Control
5.1 Overview of Load Control
Load control at the transport layer is used to manage transmission bandwidth and control transmission load, for the purpose of allowing more users to access the network and increasing the system capacity with the QoS guaranteed. Load control is responsible for management of data in the control plane. Load control methods include admission control, LDR, and OLC.
Admission control is the basic method of load control. In the process of transmission resource admission, admission control is used to determine whether the transmission resources are sufficient to accept the admission request from a user. Admission control prevents excessive admission of users and guarantees the quality of admitted services. LDR is used to prevent congestion, reduce transmission load, and increase admission success rate and system capacity. OLC is used to quickly eliminate overload when congestion occurs, and to reduce the impact of overload on high-priority users.
Differentiated services are implemented as follows:
Admission strategies: Different admission strategies are used for different types of users. During admission based on transmission resources, differentiated services for user priorities are implemented. Preemption: High-priority users preempt bandwidth of low-priority users. Thus, differentiated services for different service types and user priorities are implemented. LDR: Different LDR actions are used for different services. During congestion, differentiated services for different service types are implemented. OLC: Bandwidth of low-priority users is released, which reduces the impact of overload on high-priority users. In the case of overload, differentiated services for different service types and user priorities are implemented.
Table 5-1 describes load control applied in the 2G TRM, 3G TRM, and Co-TRM. Table 5-1 Load control applied in the 2G TRM, 3G TRM, and Co-TRM Load Control Admission control Reserved bandwidth admission Load balancing Preemption Queuing LDR OLC 2G TRM 3G TRM Co-TRM
This section describes the definition and calculation of transmission load, calculation of reserved bandwidth, and load thresholds in addition to admission control, LDR, and OLC. For differences of implementing load control in the 2G TRM, 3G TRM, and Co-TRM, see the following sections.
Issue 03 (2011-09-30)
5-1
5 Load Control
5.2 Definition and Calculation of Transmission Load

Transmission load refers to transmission resources required by access users. In the ATM, IP, or HDLC transmission mode, transmission resources are measured based on bandwidth, and load control management is based on transmission bandwidth only. Load is defined on the basis of reserved bandwidth. Bandwidth is reserved for each service in load control. Load is the sum of bandwidth reserved for all services, and the uplink load and downlink load are calculated separately. Load of all paths and all LPs (including leaf LPs and hub LPs) needs to be calculated as follows:

Path load: The load on a path is equal to the sum of reserved bandwidth of all services. Leaf LP load: The load on a leaf LP is equal to the sum of load of all paths. Hub LP load: The load on a hub LP is equal to the sum of load of all LPs.
5.3 Calculation of Reserved Bandwidth

Reserved bandwidth is used for both load calculation and user admission. Therefore, calculation of reserved bandwidth for each service should be specified.
5.3.1 Calculation of Bandwidth Reserved for 2G Signaling

This section describes the bandwidth reserved for signaling of the 2G Link Access Protocol on the D channel (LAPD) link. When the IP transmission mode is applied to the Abis interface, some LAPD links and user plane data share the transport channels. The LAPD links include OML, ESL, and RSL. These links occupies a large proportion of bandwidth and therefore the bandwidth of LPs needs to be reserved for LAPD links to prevent congestion. The calculation of bandwidth reserved for LAPD links is as follows:

Bandwidth reserved for uplink signaling = Average bandwidth for uplink OMLs and ESLs of the BTS + Number of TRXs x Average bandwidth for uplink RSLs of the BTS Bandwidth reserved for downlink signaling = Average bandwidth for downlink OMLs and ESLs of the BTS + Number of TRXs x Average bandwidth for downlink RSLs of the BTS
You can adjust the bandwidth reserved for LAPD signaling of the BTSs using Abis IP. The associated parameters are as follows:

OMLESLUL OMLESLDL RSLUL RSLDL
In IP over E1 mode, the bandwidth reserved for LAPD signaling takes effect on LPs. To ensure the accuracy of admission based on bandwidth for PPP and MLPPP links, you are advised to take one of the following measures:
Issue 03 (2011-09-30)
5-2

5 Load Control
Configure LPs on the PPP or MLPPP links with the same bandwidth as the PPP or MLPPP links Configure IP paths of the QoS type: Bandwidth of IP path = Bandwidth of PPP or MLPPP - Max (Bandwidth reserved for uplink signaling, Bandwidth reserved for downlink signaling)
5.3.2 Calculation of Bandwidth Reserved for Traffic

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 or BSC calculates the reserved bandwidth based on the activity factor and performs admission control based on the reserved bandwidth. The bandwidth reservation policies for different services are as follows:

For RT services: Reserved bandwidth = MBR x Activity factor For 3G NRT services: Reserved bandwidth = GBR x Activity factor For 2G NRT PDCH services (with the backpressure switch disabled): Reserved bandwidth = MBR x Activity factor 3G signaling:
Admission
of SRB at 3.4 kbit/s: The bandwidth for 3G SRB signaling is fixed at 3.4 kbit/s. This admission mode is applicable to R99, HSDPA, and HSUPA services. 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. of IMS at the GBR reserved for E-FACH = GBR x Activity factor reserved for other common channels = MBR x Activity factor
Admission
3G common channels:
Bandwidth Bandwidth
NOTE

For 2G PS services, the recommended activity factor is 1. For 3G common channels or SRBs, the activity factors are identical for all users, instead of varying according to user priorities. In TDM transmission mode, the bandwidth is allocated in a fixed manner instead of based on activity factors.
Activity factors can be configured for different types of services and adjacent nodes:
Both default configuration and dynamic configuration are available for activity factors for different types of service. The default configuration can be queried through the LST TRMFACTOR command. You can run the ADD TRMFACTOR command to dynamically configure activity factors for different types of service. You can run the ADD ADJMAP command to configure the same activity factor table for an adjacent node by specifying the FTI parameter.
For 3G BE services, the GBR can be set by running the SET UUSERGBR command, according to traffic classes, traffic priorities, user priorities, and types of radio bearers. The associated parameters are as follows:

TrafficClass THPClass BearType UserPriority UlGBR DlGBR
Issue 03 (2011-09-30)
5-3
5 Load Control
5.4 Load Thresholds

In the admission process based on transmission resources, load and threshold are compared to determine whether the admission is successful. The thresholds can be configured through the parameters such as relative residual resource (%, percentage of residual bandwidth to total bandwidth) or absolute residual resource (kbit/s, residual bandwidth). Uplink and downlink thresholds are configured separately.
Admission threshold of a new user (handover reserved threshold) This threshold controls the admission of a new user and can be configured through the parameters FWDRSVHOBW, BWDRSVHOBW, FWDRESVHOTH, and BWDRESVHOTH.
Congestion threshold (admission threshold of a user requesting a rate increase) This threshold triggers LDR and can be configured through the parameters FWDCONGBW, BWDCONGBW, FWDCONGTH, and BWDCONGTH.
Congestion clear threshold This threshold clears congestion and can be configured through the parameters FWDCONGCLRBW, BWDCONGCLRBW, FWDCONGCLRTH, and BWDCONGCLRTH.
Overload threshold This threshold triggers overload control and can be configured through the parameters FWDOVLDRSVBW, BWDOVLDRSVBW, FWDOVLDTH, and BWDOVLDTH.
Overload clear threshold This threshold clears overload and can be configured through the parameters FWDOVLDCLRRSVBW, BWDOVLDCLRRSVBW, FWDOVLDCLRTH, and BWDOVLDCLRTH.
NOTE
In 2G TDM transmission mode, there are only congestion threshold and congestion clear threshold, which are configured through the parameters TDMCONGTH and TDMCONGCLRTH.
The congestion threshold and congestion clear threshold, and the overload threshold and overload clear threshold are used to prevent ping-pong effect. It is recommended that they should be set to different values. By running the ADD TRMLOADTH command, you can configure a load threshold table (TRMLOADTH table) for paths, LPs, resource groups, or physical ports. By specifying the TRMLOADTHINDEX parameter, the TRMLOADTH table can be referred to. In ATM transmission, you can run the MML command ADD AAL2PATH or ADD ATMLOGICPORT command to refer to the TRMLOADTH table. In IP transmission, you can run the MML command ADD IPPATH or ADD IPLOGICPORT command to refer to the TRMLOADTH table. In TDM/HDLC transmission, you can run the MML command SET BSCABISPRIMAP to refer to the TRMLOADTH table. For details about the preceding thresholds, see sections 5.5 "Admission Control" and 5.6 "Load Reshuffling and Overload Control."
5.5 Admission Control

Admission control is used to determine whether the transmission resources are sufficient to accept the admission request from a user. If the transmission resources are sufficient, the admission request is admitted; otherwise, the request is rejected. Admission control can prevent admission of excessive users and guarantee the QoS.
Issue 03 (2011-09-30)
5-4
5 Load Control
5.5.1 Admission Process

Figure 5-1 shows the admission control during the request for transmission resources. Figure 5-1 Admission control during the request for transmission resources
As shown in Figure 5-1, when the users request transmission resources, the admission control process is as follows: 1. The admission based on transmission resources is decided according to the admission strategy. If the admission is successful, a user can obtain transmission resources. If the admission fails, go to step 2. For details about the admission strategy, see section 5.5.2 "Admission Strategy." 2. The attempt to preempt resources is made. If the preemption is successful, a user can obtain transmission resources. If the preemption fails or the preemption function is not supported, go to step 3. For details about preemption, see section 5.5.5 "Preemption." 3. The attempt for queuing is made. If the queuing is successful, a user can obtain transmission resources. If the queuing fails or the queuing function is not supported, the admission based on transmission resources fails. For details about queuing, see section 5.5.6 "Queuing." After transmission resources are successfully admitted, bandwidth needs to be reserved on the corresponding paths and ports. In addition, bandwidth needs to be updated to the load.
5.5.2 Admission Strategy

Overview
The principles of ATM/IP transmission resource admission are as follows:
Issue 03 (2011-09-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 5-5
5 Load Control
Multiple levels of admission. After the user initiates a request for transmission resources, admission based on transmission resources is decided in the sequence of paths -> LPs -> physical ports.
If a certain level of admission is not supported, you can directly perform the admission decision of transmission resources of the next level. If the LP is not configured, the admission is performed in the sequence of paths -> physical ports. In multiple levels of admission, users can obtain transmission resources only when the admission based on all resources is successful. In TDM Flex Abis transmission, the transmission resource admission is performed from the Flex Abis resources of the lowest-level base station step by step in an ascending order. In HDLC transmission, admission is based on HDLC links.
The service priorities need to be taken into consideration. New users, handover users, and users requesting a rate increase use different admission strategies.
The admission based on transmission resources is determined according to the current load, bandwidth requested by users, and admission thresholds. The admission strategy varies according to the types of users.
For a new user

Admission
based on paths
Path load + Bandwidth required by the user < Total configured bandwidth for the path - Path bandwidth reserved for handover.
Admission
based on LPs
The admission based on LPs is performed level by level. For each level of admission, the strategy is as follows: LP load + Bandwidth required by the user < Total bandwidth for the LP - LP bandwidth reserved for handover.
For a handover user

Admission
based on paths based on LPs
Path load + Bandwidth required by the user < Total bandwidth for the path.
Admission
The admission based on LP resources is performed level by level. For each level of admission, the strategy is as follows: LP load + Bandwidth required by the user < Total bandwidth for the LP.
For a user requesting a rate increase

Admission
based on paths
Path load + Bandwidth required by the user < Total bandwidth for the path - Path congestion threshold.
Admission
based on LPs
The admission based on LPs is performed level by level. For each level of admission, the strategy is as follows: LP load + Bandwidth required by the user < Total bandwidth for the LP - LP congestion threshold.
NOTE
If no admission threshold is configured for the user, the admission strategy can be simplified as: Load + Bandwidth required by the user < Total bandwidth configured.
Procedure for the Admission Based on Paths

One type of service can be mapped to multiple paths of the same type by configuring transmission resource mapping. Figure 5-2 shows the procedure for the admission based on paths.
Issue 03 (2011-09-30)
5-6
5 Load Control
Figure 5-2 Procedure for the admission based on paths
Step 1 Paths are selected according to transmission resource mapping. For details about transmission resource mapping, see section 4.4 "Transmission Resource Mapping." If no paths are available for use, for example, when the mapped path type does not exist, the admission fails. Step 2 The admission sequence for all paths is determined. For details, see the section "Sequence of the Admission Based on Paths." Step 3 According to the sequence, a path is selected to undergo admission decision. If The admission succeeds. The admission fails. Then The admission based on paths is complete. Go to Step 4.
Step 4 Whether there are still available paths is determined. If There is no available path. There are still available paths. Then The admission fails, the admission based on paths is complete. Go to Step 3.
Issue 03 (2011-09-30)
5-7
5 Load Control
Sequence of the Admission Based on Paths

During the admission process, the sequence of the admission based on the paths needs to be determined after all paths available for a type of service are determined.

If the type of service requests a rate decrease, successful admission is directly performed on its original path. If the type of service requests a rate increase, an admission decision is preferentially performed on its original path. If a type of service is mapped to multiple paths of the same type,
When
paths are configured as primary and secondary paths and load balancing algorithm is enabled, firstly whether the admission is based on the primary paths or the secondary paths is determined according to the algorithm of path load balancing. For details, see section 5.5.4 "Load Balancing." Then the specific primary or secondary path to undergo admission decision is determined according to the algorithm of path load sharing. For details, see section 5.5.3 "Load Sharing." Otherwise, the path to undergo admission decision is determined according to the algorithm of path load sharing. For details, see section 5.5.3 "Load Sharing."
5.5.3 Load Sharing

As Figure 5-3 shows, the round robin path algorithm helps implement load sharing between paths.

One type of service can be mapped to multiple paths of the same type. The paths form a circular chain. In the circular chain, the admission sequence for all paths is fixed. A cursor is used to indicate the current path for admission decision. If the admission succeeds, the cursor moves to the next path for use in the next admission procedure. If the admission fails, the next path is chosen to undergo admission decision in the sequence of the circular chain.
Figure 5-3 Path round robin
For example,

One type of service is mapped to five paths of the same type that are numbered path 1 to path 5. The five paths form a circular chain: 123451. Assume that the type of service needs to be admitted for 100 times in response to 100 requests. The times are respectively marked T1, T2, T3, Assume that the admission of T1 succeeds on path 1.
Issue 03 (2011-09-30)
5-8

5 Load Control
Then the admission of T2 is performed in the sequence of 23451. Assume that the admission succeeds on path 4. Then the admission of T3 is performed in the sequence of 51234. Assume that the admission fails on all paths. In this case, the admission of T3 is rejected. Then the admission of T4 is performed in the sequence of 51234.
If the admission of all the 100 times succeeds on the first path for admission decision, then the 100 service requests are respectively admitted on one of the five paths in the following way:
5.5.4 Load Balancing

In the admission control, load balancing is a method used to achieve the load balance between primary and secondary paths.
Principles of Load Balancing

The principles of load balancing are as follows:

Load balancing between primary and secondary paths is applied only in the Iub hybrid transmission scenario, including ATM&IP dual stack and hybrid IP transmission. A service is not always preferably admitted based on the primary path. If the load of the primary path exceeds the load threshold and the ratio of secondary path load to primary path load is lower than the load ratio threshold, then the service is preferably admitted based on the secondary path to improve the resource usage and user experience.
Calculation of the Load of Primary and Secondary Paths

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.
Issue 03 (2011-09-30)
5-9
5 Load Control
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 Table of Primary and Secondary Paths

The load balancing table of primary and secondary paths is applicable to default configuration or dynamic configuration.
A default load balancing table is used when the ADJMAP is not configured for an adjacent node. Index 0 is the default index. The default load balancing table can be queried through the LST LOADEQ command. A load balancing table can be dynamically configured by running the ADD LOADEQ command. Load balancing thresholds include primary path load threshold and primary-to-secondary path load ratio threshold. The thresholds can vary depending on different types of service and the ARP needs to be taken into consideration. When load balancing parameters need to be set for Iub adjacent nodes, you can run the ADD ADJMAP or MOD ADJMAP command.
Admission Based on Primary and Secondary Paths

According to the mapping from traffic classes to transmission resources, the RNC calculates the load of the primary and secondary paths. The RNC 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 classes to transmission resources, see section 4.4 "Transmission Resource Mapping." Assume that the secondary path is available for a new user, and the primary path is a preferred path. The admission procedure for a new user on the Iub interface is as follows: Step 1 The new user attempts to be admitted to available bandwidth 1 on the primary path, as shown in Figure 5-4. Step 2 If the user succeeds in requesting the resources on the primary path, the user is admitted to the primary path. Step 3 If the user fails to request 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 5-4. Step 4 If the user succeeds in requesting the resources on the secondary path, the user is admitted to the secondary path. Otherwise, the bandwidth admission request of the user is rejected. ----End
Issue 03 (2011-09-30)
5-10
5 Load Control
Figure 5-4 Admission bandwidth for the primary and secondary paths of 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
5.5.5 Preemption
In the case of preemption, a high-priority user preempts the bandwidth from a low-priority access user for admission based on transmission resources. This improves satisfaction of high-priority users. In the Co-TRM, preemption is performed only within the 2G or 3G system. A high-priority 2G user preempts the bandwidth of a low-priority 2G user, and a high-priority 3G user preempts the bandwidth of a low-priority 3G user. If the admission based on transmission resources fails, the preemption function is triggered when the following conditions are met:

The transmission channel (path, LP, resource group, or physical port) supports preemption. The user who requests transmission resources supports preemption as defined in the user request. The preemption switch is enabled.
In In In
the 2G system, the preemption switch is enabled through the ENPREEMPTTRANSADMT parameter. the 3G system, the preemption switch is enabled through the PreemptAlgoSwitch parameter. the Co-TRM, the preemption switches for 2G and 3G services are set separately. Both ENPREEMPTTRANSADMT and PreemptAlgoSwitch need to be set.
Intelligent Access Control (IAC) is aimed at improving the access success rate. Preemption is one of the IAC procedures. For details about the principles of preemption at the RNC, see the Load Control Feature Parameter Description of the RAN. The principles of preemption at the BSC are as follows:
In IP and HDLC transmission modes

If If
transmission resources are insufficient, preemption for bandwidth of different types of service is performed. That is, preemption for bandwidth is performed between CS services and PS services. conditions for preemption between different types of service are not met, preemption is performed on bandwidth of the same traffic class. That is, a high-priority CS service preempts the bandwidth of a low-priority CS service, and a high-priority PS service preempts the bandwidth of a low-priority PS service.
In Flex Abis mode, a CS service preempts the bandwidth of a low-priority PS service.
Issue 03 (2011-09-30)
5-11
5 Load Control
The principles of bandwidth preemption between CS services and PS services are as follows:
During transmission resource admission, a CS service can preempt the bandwidth of low-priority PS service only when the ratio of the bandwidth occupied by the CS service to the total bandwidth is lower than the GSMCSBWRATE parameter. During transmission resource admission, a PS service can preempt the bandwidth of low-priority CS service only when the ratio of the bandwidth occupied by the CS service to the total bandwidth is higher than the GSMCSBWRATE parameter.
Whether a CS service is of high priority can be determined by configuring the GSMCSUSERHIGHPRILEV parameter. If the priority of the CS service indicated in the user request is lower than or equal to the value of this parameter, the CS service is considered as of high priority. Otherwise, it is of low priority.
5.5.6 Queuing
In the queuing function, the user that requests transmission resources is put in a queue to wait for free transmission resources. If the admission based on transmission resources fails, or the user that requests transmission resources does not support the preemption function, or the preemption function fails, the queuing function is triggered when the following conditions are met:

The transmission channel (path, LP, resource group, or physical port) supports queuing. The user that requests transmission resources supports queuing as defined in the user request. The 2G user for queuing must be a non-handover CS user. The queuing switch is enabled.
In In In
the 2G system, the queuing switch is enabled through the ENQUETRANSADMT parameter. the 3G system, the queuing switch is enabled through the QueueAlgoSwitch parameter.
the Co-TRM, the preemption switches for 2G and 3G services are set separately. Both ENQUETRANSADMT and QueueAlgoSwitch need to be set.
Queuing is also one of the IAC procedures. For details about the principles of queuing at the RNC, see the Load Control Feature Parameter Description of the RAN. The principle of queuing at the BSC is that the user entering a queue captures transmission resources according to the First in First Out (FIFO) strategy when transmission resources are released.
5.6 Load Reshuffling and Overload Control

LDR is used to prevent congestion, reduce the transmission load, and increase the access success rate. OLC is used to quickly eliminate overload when transmission congestion occurs, and to reduce the adverse impact on high-priority users. This section describes the LDR and OLC on the Abis interface of the 2G system, the Iub interface of the 3G system, and the Abis and Iub interfaces of the Co-TRM. This section involves the following aspects:

Congestion detection Overload detection Congestion and overload handling
5.6.1 Congestion Detection

For a path or port (LP or physical port), the following congestion-related thresholds are applicable:
Issue 03 (2011-09-30)
5-12

5 Load Control
Congestion threshold: When the usage of transmission resources increases and the remaining bandwidth falls below the congestion threshold, the system considers that congestion occurs. Congestion clear threshold: When the usage of transmission resources decreases and the remaining bandwidth exceeds the congestion clear threshold, the system considers that congestion is cleared.
For parameters associated with the congestion, see section 5.4 "Load Thresholds." 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
Congestion detection for a path is similar to that for a port. Assume that the forward parameters of a port for congestion detection are defined as follows:

Configured bandwidth: AVE Forward congestion threshold: CON Forward congestion clear threshold: CLEAR Used bandwidth: USED
Then, the policies of congestion detection for the port are as follows:

Congestion occurs on the port when AVE - USED < CON. Congestion is cleared from the port when AVE - USED > CLEAR.
Generally, congestion thresholds need to be set for only physical ports or resource groups. If different types of paths require different congestion thresholds, the TRM load threshold tables need to be adjusted by running the ADD TRMLOADTH command, and then be referred by specifying the TRMLOADTHINDEX parameter when the paths are configured. If ATM LPs or IP LPs are configured, LDR is also applicable to ATM LPs or IP LPs. LDR for LPs is similar to that for resource groups.
5.6.2 Overload Detection

For a path or port (LP or physical port), the following overload congestion-related thresholds are applicable.

Overload threshold: When the usage of transmission resources increases and the remaining bandwidth falls below the overload threshold, the system considers that overload occurs. Overload clear threshold: When the usage of transmission resources decreases and the remaining bandwidth exceeds the overload clear threshold, the system considers that overload is cleared.
For parameters associated with the overload congestion, see section 5.4 "Load Thresholds." Overload congestion can be triggered in any of the following conditions:

In the ATM IMA networking scenario, an IMA group contains multiple E1s, among which some E1s are broken whereas others work properly. In the 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.
Issue 03 (2011-09-30)
5-13
5 Load Control
Overload detection for a path is similar to that for a port. Assume that the forward parameters of an LP for overload detection are defined as follows:

Total bandwidth: AVE Forward overload congestion remain threshold: OVERLOD Forward overload congestion clear remain threshold: CLEAR Used bandwidth: USED
Then, the policies of overload detection for the LPs are as follows:

Overload occurs on the LP when AVE - USED < OVERLOD. Overload is cleared on the LP when AVE - USED > CLEAR.
If a path, or port is not configured with overload thresholds, the policy of overload detection is simplified as USED > AVE.
5.6.3 Congestion and Overload Handling

Overview
Congestion in different systems is handled as follows:

In the 2G system, bandwidth requested by a new user and bandwidth used by an access user are both reduced. In the 3G system, bandwidth used by an access user is reduced. In the Co-TRM, bandwidth requested by a new 2G user and bandwidth used by 2G and 3G access users are reduced.
Overload in different systems is handled as follows: Admission of all users is rejected and bandwidth of low-priority users is released. In the Co-TRM, during the handling of overload triggered by admission of LPs, bandwidth is reserved according the proportion of the 2G services to the 3G services, and at the same time the used bandwidth is released. If the bandwidth in one system cannot be released any more and overload is not cleared, the bandwidth in the other system is released. The proportion of reserved bandwidth of the 2G services to the 3G services can be configured through the GSMBWRATE parameter.
Handling on the Iub Interface

If IUB_LDR under the NodeBLdcAlgoSwitch parameter is turned on,
After the RNC receives a congestion message, the RNC triggers LDR actions.
Renegotiation Inter-RAT
on the QoS of the uncontrollable RT services. The subparameter QoSRenego is used to trigger LDR. handover. The subparameters CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, and PSInterRatShouldNotLDHO are used to trigger LDR.
The sequence of LDR actions in the uplink can be different from that of LDR actions in the downlink. The parameters UlLdrFirstAction, UlLdrSecondAction, UlLdrThirdAction, UlLdrFourthAction, UlLdrFifthAction, and UlLdrSixthAction are used to set the sequence in the uplink direction. The parameters DlLdrFirstAction, DlLdrSecondAction, DlLdrThirdAction, DlLdrFourthAction, DlLdrFifthAction, and DlLdrSixthAction are used to set the sequence in the downlink direction. You can run the ADD UNODEBLDR command to set the relation between the parameters and the LDR actions in each direction for the purpose of adjusting the LDR policy. If the number of actual LDR actions is smaller than six, you can use the NOACT subparameter to cancel corresponding LDR actions. In addition, different NodeBs can take different LDR actions.
Issue 03 (2011-09-30)
5-14
5 Load Control
After the RNC receives an overload message, the RNC triggers OLC actions. OLC triggers release of resources used by users in order of comprehensive priority. For details about the LDR actions for various types of services and the comprehensive priorities, see the Load Control Feature Parameter Description of the RAN.
Handling on the Abis Interface

When the BSC detects that congestion occurs, it triggers LDR. The LDR actions are as follows:

The rate of PS services is reduced through the PSDOWN subparameter. The admission of CS users that prefer half-rates is controlled through the CSPH subparameter. Rate limits of CS Adaptive Multi Rate (AMR) services during admission are controlled through the AMRC subparameter. The switchover from full rates to half rates of CS users is controlled through the CSFHHO subparameter.
The sequence of LDR actions can be configured through the parameters LDRFST, LDRSND, LSRTRD, and LDRFOUH. You can run the SET LDR command to set the relation between the four parameters and the LDR actions for the purpose of adjusting the LDR policy. If the number of actual LDR actions is smaller than four, you can use the CLOSE subparameter to cancel other LDR actions. In addition, different BTSs can take different LDR actions. When the BSC detects that overload occurs, the admission requests of all users are rejected.
Handling on Other Interfaces
On the Iur interface The congestion on the Iur interface can trigger Serving Radio Network Subsystem (SRNS) relocation. For details about SRNS relocation, see the SRNS Relocation and DSCR Feature Parameter Description of the RAN.
On the Iu interface During Iu signaling flow control, if congestion is detected on the signaling link towards the signaling point, the congested state is reported to the Radio Access Network Application Part (RANAP) subsystem of the RNC. Then, the RANAP subsystem discards user messages in the following sequence: short message service > CS and PS call > registration.
On the Ater interface When the AterCongHRFlag parameter is enabled, the half-rate channels are preferentially allocated to new access users to allow more users to access the network if the usage of transmission resources on the Ater interface exceeds the AterCongstRatio parameter. In Ater TDM transmission mode, the BSC triggers the local exchange function, if any, to allow more users to be admitted when the usage of transmission resources on the Ater interface exceeds the AterJamThreshold2StartLs parameter.
5.7 Summary
Figure 5-5 shows the load control process in the increase of transmission bandwidth usage during the admission of transmission resources.
Issue 03 (2011-09-30)
5-15
5 Load Control
Figure 5-5 Load control in the increase of transmission bandwidth usage
As shown in Figure 5-5, the load control process in the increase of transmission bandwidth usage is as follows:
Admission control
All
users are admitted when Remaining bandwidth > Congestion threshold.
New
users and handover users are admitted when Handover reserved threshold < Remaining bandwidth < Congestion threshold. users are admitted when Overload threshold < Remaining bandwidth <. Handover reserved threshold users are allowed to preempt the bandwidth of admitted users, but cannot be allocated new bandwidth when Remaining < Overload threshold.
Handover New
LDR: LDR starts when Remaining bandwidth < Congestion threshold. OLC: OLC starts when Remaining bandwidth < Overload threshold.
When the usage of transmission bandwidth decreases and Remaining bandwidth > Overload clear threshold, OLC is cleared. When the usage of transmission bandwidth decreases and Remaining bandwidth > Congestion clear threshold, LDR is cleared. Table 5-2 summarizes the difference of load control between the 2G TRM, 3G TRM, and Co-TRM. Table 5-2 Difference of load control between the 2G TRM, 3G TRM, and Co-TRM
Networking Scenario Congestion Threshold & Congestion Clear Threshold Overload Threshol d& Overload Clear Threshol d Handover Preemption Queuing Calculatio Reserved n of Threshol Bandwidth d Reserved for Signaling Calculatio n of Bandwidth Reserved for Traffic
2G IP transmission Path LP
Issue 03 (2011-09-30)
5-16

Networking Scenario Congestion Threshold & Congestion Clear Threshold Overload Threshol d& Overload Clear Threshol d
5 Load Control
Handover Preemption Queuing Calculatio Reserved n of Threshol Bandwidth d Reserved for Signaling Calculatio n of Bandwidth Reserved for Traffic
Resource group
PPPLNK/MP GRP 2G HDLC transmission 2G Flex Abis
3G IP transmission Path LP Resource group
PPPLNK/MP GRP 3G ATM transmission Path LP Resource group
IMAGRP/UNI LNK/FRALNK Co-transmission IP LP
In the 3G Iub hybrid transmission scenario, including ATM&IP dual stack and hybrid IP transmission, the load balancing is supported in the process of transmission resource admission.
Issue 03 (2011-09-30)
5-17
6 User Plane Processing

6.1 Overview of User Plane Processing
User plane processing refers to the management of data in the user plane. The user plane processes user data, limits users' transmit rate in congestion scenario, prevents congestion and packet loss, and increases bandwidth usage. User plane processing involves the following aspects:
Scheduling and shaping

Leaf Hub
LP shaping: limits the total transmit rate of the RNC, BSC, MBSC, BTS or NodeB and prevents congestion on the transport network LP scheduling: schedules all the ports under the hub node, limits the total transmit rate of the hub node, and guarantees the fairness between ports
Iub overbooking The Iub overbooking feature considers the statistic multiplexing of service activities and multiple users. Through the admission of more users, Iub overbooking increases the resource utilization on the Iub interface.
Congestion control in the Iub user plane: limits the transmit rate of NRT services, prevents congestion and packet loss on the Iub interface Dynamic bandwidth adjustment based on IP PM: the RNC dynamically adjusts transmission bandwidth available on the Iub LPs based on the monitoring result from IP PM.
The differentiated services are implemented as follows:
In traffic shaping, differentiated services are implemented through queue priorities and WRR scheduling. The scheduling order is high-priority RT services -> low-priority RT services -> lower-priority NRT services scheduled by WRR. In congestion control, differentiated services are implemented by the SPI weighting (differentiated service based on SPI weight). Bandwidth resources are allocated proportionally between NRT services according to service priorities, with the GBR of NRT services guaranteed.
Table 6-1 describes the user plane processing in the 2G TRM, 3G TRM, and Co-TRM. Table 6-1 User plane processing in the 2G TRM, 3G TRM, and Co-TRM User Plane Processing Shaping 2G TRM Leaf LP shaping HDLC shaping BTS shaping Scheduling Hub LP scheduling HDLC scheduling Iub overbooking Hub LP scheduling NodeB scheduling Iub overbooking Hub LP scheduling 3G TRM Leaf LP shaping NodeB shaping Co-TRM Leaf LP shaping
Dynamic bandwidth adjustment based on IP PM
Dynamic bandwidth adjustment based on IP PM
Issue 03 (2011-09-30)
6-1
User Plane Processing
2G TRM
3G TRM Downlink:
Co-TRM Bandwidth sharing of MBTS multi-mode co-transmission
Iub user plane congestion control algorithm
RNC RLC retransmission rate-based downlink congestion control algorithm RNC backpressure-based downlink congestion control algorithm NodeB HSDPA adaptive flow control algorithm NodeB backpressure-based uplink congestion control algorithm NodeB uplink bandwidth adaptive adjustment algorithm RNC R99 single service uplink congestion control algorithm NodeB uplink congestion control algorithm for cross-Iur single HSUPA service
Uplink:
Bandwidth sharing of MBTS multi-mode co-transmission is applied to the scenario where the MBTS is in co- transmission mode and the BSC and RNC are deployed separately.
This section describes user plane processing in terms of scheduling, shaping, Iub overbooking, Iub user plane congestion control, and dynamic bandwidth adjustment based on IP PM.
6.2 Scheduling and Shaping

This section describes the scheduling and shaping of the RNC/BSC and NodeB.
6.2.1 RNC/BSC Scheduling and Shaping

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

The leaf LP performs the shaping function. The total data transmit 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 transmit 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. The HDLC channel performs both shaping and scheduling functions.
For For
each HDLC channel performing the shaping function, the total data transmission rate does not exceed the bandwidth configured for the HDLC channel. each HDLC channel performing the scheduling function, the scheduling rate of the HDLC channel is in direct proportion to the load of the channel, which guarantees fairness between the channels.
Issue 03 (2011-09-30)
6-2
6.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 transmit rate does not exceed the bandwidth configured for the LP. The scheduling function is described as follows:
Scheduling in ATM transmission mode: The ATM physical port performs Round Robin (RR) scheduling between LPs. The PVCs of the same LP or of the same physical port are scheduled according to priorities. Scheduling in IP transmission mode: When there are multiple LPs, the IP physical port performs RR scheduling of all the LPs to guarantee fairness between the LPs.
6.2.3 BTS Shaping

The BTS performs 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.
6.3 Iub Overbooking

This section involves the following features:

WRFD-050405 Overbooking on ATM Transmission WRFD-050408 Overbooking on IP Transmission WRFD-050406 ATM QoS Introduction on Hub Node B (Overbooking on Hub Node B Transmission)
Since services are incontinuous, there are periods with transmission activities and periods without transmission activities. To achieve better utilization of Iub transmission resources, Huawei provides the Iub overbooking function, which applies admission control policy to access the services. Services are admitted according to the different activity factors, and admission of more services can be allowed to the bandwidth. Other policies applied in overbooking are as follows:
RNC RLC Retransmission Rate-Based Downlink Congestion Control Algorithm After Iub overbooking is applied, if no flow control is performed on the RNC, the utilization of Iub transmission resources is quite low. Because random packet loss on the Iub interface leads to PDU re-transmission by the RLC and thus the transmission rate is degraded when the time delay for transmitting TCP packet increases and the TCP flow control starts. To solve this problem, RNC RLC retransmission rate-based downlink congestion control algorithm is introduced to avoid packet loss and delay on the Iub interface.
RNC Backpressure-Based Downlink Congestion Control Algorithm After activity factors are taken into consideration, admission of more services can be allowed to the bandwidth, but the probability of congestion on the Iub interface increases accordingly. If all services are transmitted at the rate higher than their respective admission bandwidth at the same time, congestion and packet loss are likely to occur on the Iub interface. Therefore, user experience deteriorates and Iub bandwidth usage decreases. To solve possible congestion problems, RNC backpressure-based downlink congestion control algorithm is introduced.
Shaping Shaping is applied to avoid transmission congestion and packet loss in the scenario of limited transmission resource bandwidth.
Issue 03 (2011-09-30)
6-3
6.4 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 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 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 HSDPA Feature Parameter Description of the RAN and HSUPA Feature Parameter Description of the RAN. 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.
To implement differentiated services in the same way, the Iub congestion control algorithm also uses SPI weighting for implementing differentiated services (WRFD-020806 Differentiated Service Based on SPI Weight) on the Iub interface, that is, the bandwidth is allocated by proportion based on the SPI weighting 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 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:

Radio Link Control (RLC) retransmission rate-based downlink congestion control algorithm Backpressure-based downlink congestion control algorithm NodeB HSDPA adaptive flow control algorithm NodeB backpressure-based uplink congestion control algorithm NodeB Uplink Bandwidth Adaptive Adjustment Algorithm
Issue 03 (2011-09-30)
6-4

R99 single service uplink congestion control algorithm NodeB Uplink Congestion Control Algorithm for Cross-Iur Single HSUPA Service
6.5 Downlink Iub Congestion Control Algorithm

6.5.1 Overview of the Downlink Iub Congestion Control Algorithm
The downlink congestion control algorithms, also known as downlink flow control of user plane, are of four types, which are described in Table 6-2. Table 6-2 Downlink congestion control algorithms Congestion Control Algorithm RNC RLC retransmission rate-based congestion control algorithm NodeB HSDPA adaptive flow control algorithm RNC backpressure-based downlink congestion control algorithm Scenario All networking scenarios All networking scenarios Service Type R99 service, HSDPA service, RLC AM mode HSDPA service
Congestion and packet loss in the R99 service, HSDPA RNC. For packet loss at the transport NRT service layer, the shaping algorithm is also required.
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 transmission 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. Relation between the NodeB HSDPA flow control algorithm and the RNC backpressure-based congestion control algorithm The NodeB flow control algorithm switch is set to BW_SHAPING_ONOFF_TOGGLE by default. In default configuration:
If
the RNC backpressure switch is set to OFF, the NodeB flow control policy is automatically adjusted to DYNAMIC_BW_SHAPING, and can independently solve the congestion problem of HSDPA users. the RNC backpressure switch is set to ON and direct connection networking is applied, the NodeB flow control policy is automatically adjusted to NO_BW_SHAPING and the RNC backpressure algorithm takes effect. the RNC backpressure switch is set to ON and transmission convergence networking is applied, the NodeB flow control policy is automatically adjusted to DYNAMIC_BW_SHAPING, and both NodeB flow control algorithm and RNC backpressure algorithm take effect. The NodeB flow control
If
If
Issue 03 (2011-09-30)
6-5
algorithm solves the congestion problem on the transmission network whereas the RNC backpressure algorithm solves the congestion problem on the Iub interface of the RNC side.
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. 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.
When
6.5.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 UCORRMALGOSWITCH command, and set the DRA_R99_DL_FLOW_CONTROL_SWITCH subparameter of DraSwitch to on. For the HSDPA BE service, use the SET UCORRMALGOSWITCH command, and set the DRA_HSDPA_DL_FLOW_CONTROL_SWITCH subparameter of DraSwitch to on.
The algorithm is implemented as follows: Step 1 The RNC initiates periodic monitoring of the RLC PDU retransmission rate. The monitoring period is specified by the MoniterPrd parameter. Step 2 When the retransmission rate is higher than EventAThred in a specified continuous period (TimeToTriggerA x MoniterPrd), event A is triggered. That is, the RNC reduces the current transmission rate of the R99/HSDPA BE service. 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. That is, the RNC increases the current transmission rate of the R99/HSDPA BE service. 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 this algorithm of the BE service is shown in Figure 6-1.
Issue 03 (2011-09-30)
6-6
Figure 6-1 Procedure for the RLC retransmission rate-based flow control of the BE service
Through this algorithm, the transmission rate of the RNC matches the bandwidth on the Iub interface, as shown in Figure 6-2. Figure 6-2 BE service flow control in the case of Iub congestion
Issue 03 (2011-09-30)
6-7
----End
6.5.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. The prerequisites for implementing the algorithm are as follows:
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 Hub IP
Iub overbooking: used for the ATM non-hub network Iub overbooking: used for the ATM hub network
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 For
the ATM network, the ports are the UNI link, IMA group, fractional link, LP, and optical port. the IP network, the ports are the LP, PPP link, MLPPP group, optical port, and Ethernet port.
The algorithm is implemented as follows: Step 1 The interface boards monitor the transmission buffers of the queues on the Iub interface. The ATM interface board has four 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.
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 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.
Issue 03 (2011-09-30) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 6-8
The recovery thresholds are CONGCLRTHD0, CONGCLRTHD1, CONGCLRTHD2, CONGCLRTHD3, CONGCLRTHD4, and CONGCLRTHD5.
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). For detailed about MBR, see Load Control Feature Parameter Descriptio. ----End The result of this algorithm for the BE service is shown in Figure 6-3. Figure 6-3 Result of the backpressure-based flow control algorithm for the BE service
The other parameters used in flow control algorithm 2 are as follows:

TrafficClass UserPriority THPClass SPI BearType
6.5.4 NodeB HSDPA Adaptive Flow Control Algorithm

The NodeB HSDPA adaptive flow control algorithm (corresponding to feature WRFD-01061010 HSDPA flow control) is implemented in the NodeB. It is applied to the MAC-hs queues of the BE service.

The BE service is less sensitive to delay. The rate fluctuates considerably. When the data burst occurs, the rate may become very high. The HSDPA 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.
This flow control has the following benefits:
This algorithm enables the RNC and NodeB to exchange resource information to ensure that the data to be transmitted by the UE matches the scheduled data.
Issue 03 (2011-09-30)
6-9

This algorithm enables the service scheduling and retransmission functions on the NodeB and reduces data transmission latency. This algorithm minimizes the buffer size and buffer time of the NodeB to prevent data loss caused by data buffering timeout. This algorithm prevents packet loss and maximizes the power and code resource efficiency. This algorithm solves the Iub congestion problems of HSDPA users in various scenarios.
The prerequisites for implementing the algorithm are as follows:
The HSDPA MBR reporting switch is set as follows:

When 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. the switch is set to OFF, the Iub MBR reporting function is disabled.
NOTE
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. 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. 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.
When
When
When SWITCH is set to DYNAMIC_BW_SHAPING or BW_SHAPING_ONOFF_TOGGLE, the cell throughput decreases in the case of severe packet loss in the transport network. This section describes the flow control policy used when SWITCH is set to BW_SHAPING_ONOFF_TOGGLE. The algorithm architecture is shown in Figure 6-4.
Issue 03 (2011-09-30)
6-10
Figure 6-4 Dynamic flow control algorithm architecture
The algorithm is implemented as follows: 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.
The The If If
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. Iub delay congestion threshold is specified by TD. If the detected delay is lower than the threshold, no congestion due to delay occurs. 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. 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 (Optional, If the Iub shaping function of the NodeB is disabled, skip this step.) 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. Step 5 The RNC limits the bandwidth for each MAC-hs queue based on the HS-DSCH capacity allocation result.
Issue 03 (2011-09-30)
6-11
----End
6.6 Uplink Iub Congestion Control Algorithm

6.6.1 Overview of the Uplink Iub Congestion Control Algorithm
The uplink congestion control algorithms are of four types, which are described in Table 6-3. Table 6-3 Uplink congestion control algorithms Congestion Control Algorithm Scenario Service Type
NodeB backpressure-based uplink The available bandwidth for LPs is known, R99 service and congestion control algorithm HSUPA service and the NodeB boards support the algorithm. NodeB uplink bandwidth adaptive The bandwidth of various transport adjustment algorithm networks is unknown or the scenarios include ATM convergence, hub convergence, and slow changes in the bandwidth of transport networks. RNC R99 single service uplink congestion control algorithm NodeB uplink congestion control algorithm for cross-Iur single HSUPA service All networking scenarios Iur congestion scenario R99 service and HSUPA service
R99 service HSUPA service
The recommended configurations for the uplink congestion control algorithms are as follows:

All the algorithm switches are enabled. In the IP transmission 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 uplink congestion control
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd 6-12
Issue 03 (2011-09-30)
algorithm for cross-Iur single HSUPA service can solve the packet loss problem due to Iur interface congestion for HSUPA users.
6.6.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 packet loss does not occur due to congestion in the NodeB. When detecting Iub congestion, the NodeB reduces the rate for all BE users. After congestion is eliminated, the NodeB increases the rate for all BE users. This ensures fairness among all BE users.
NOTE
The switch for this algorithm is not configurable. It is set to ON by default.
Figure 6-5 shows the principle of the NodeB backpressure-based congestion control algorithm. Figure 6-5 Principle of the NodeB backpressure-based uplink congestion control algorithm
The algorithm is implemented as follows: Step 1 The interface boards monitor the transmission buffering duration for the LPs and LP queues on the Iub interface. Step 2 When detecting that the transmission buffering duration exceeds the congestion threshold, the NodeB determines that transmission congestion occurs on the Iub interface. The congestion threshold is not configurable and is fixed at 40 ms. When congestion occurs on the Iub interface, the NodeB limits the transmission rates for BE users carried on the Iub LPs. The transmission rates for BE users, however, will not be lower than their GBRs. Step 3 When detecting that data packets in a queue for BE users are buffered for a time longer than the allowed buffering duration, the NodeB starts to discard the data packets.

Data packets in the queue for HSUPA users can be buffered for 500 ms. Data packets in the queue for R99 users can be buffered for 60 ms.
Issue 03 (2011-09-30)
6-13
Step 4 When detecting that the transmission buffering duration falls below the congestion recover threshold, the NodeB determines that transmission congestion is eliminated. The congestion recover threshold is not configurable and is fixed at 20 ms. After Iub congestion is eliminated, the NodeB increases the transmission rates for all BE users carried on the Iub LPs up to their MBRs.
The The
NodeB increases the transmission rates for BE users in certain steps every 10 ms.
step varies with the user priority. The transmission rate for a BE user with a higher priority is increased in larger steps.
----End
6.6.3 NodeB Uplink Bandwidth Adaptive Adjustment Algorithm

The NodeB uplink bandwidth adaptive adjustment algorithm (corresponding to feature WRFD-010637 HSUPA Iub flow control in case of Iub congestion) is implemented in the NodeB. In the scenario of network convergence or hub NodeB, the bandwidth configured by the NodeB may be 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.
NOTE
The switch of this algorithm is not configurable. It is set to ON by default.
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 6-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 6-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.
Issue 03 (2011-09-30)
6-14
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.
This algorithm enables monitoring Iub transmission resources to dynamically adjust the exit bandwidth on the NodeB side, which greatly increases resource efficiency. If a large number of packets are lost in the transport network, the HSUPA throughput decreases.
6.6.4 RNC R99 Single Service Uplink Congestion Control Algorithm

The RNC R99 single service uplink congestion control algorithm (corresponding to feature WRFD-020124 Uplink Flow Control of User Plane) 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.
NOTE
The spare field in the uplink DCH data frame is extended to implement FP-based uplink congestion detection. The algorithm is implemented as follows: Step 1 The NodeB sends the DCH FP frame that carries the total number of FP packets. Step 2 The RNC performs R99 single service uplink congestion detection due to frame loss. Step 3 If a frame loss is detected, the RNC reduces the rate of the uplink service (not lower than the GBR) and notifies the UE through the TFC Control signaling. Step 4 If there is no frame loss and the current rate of the user does not reach the MBR, the RNC increases the rate and notifies the UE through the TFC Control signaling. ----End
6.6.5 NodeB Uplink Congestion Control Algorithm for Cross-Iur Single HSUPA Service
The NodeB uplink congestion control algorithm for cross-Iur single HSUPA service 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.
NOTE
The algorithm is implemented as follows: 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.
Issue 03 (2011-09-30)
6-15
Step 3 In a certain period, the NodeB increases the transmission rate for the uplink cross-Iur HSUPA user until the rate of the BE user reaches the MBR. 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
6.7 Dynamic Bandwidth Adjustment Based on 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 bandwidth on the LP over the Iub interface can be adjusted adaptively. The dynamic bandwidth adjustment function over the Iub interface corresponds to feature WRFD-050422 Dynamic Bandwidth Control of Iub IP. The adjusted bandwidth can be used as the input for port backpressure. The predicted available bandwidth is also applied to the admission algorithm. For details, see section 5.5 "Admission Control." The IP PM function is used in IP over FE/GE transmission scenario. IP PM can be used in the following scenarios:

ADSL and ADSL 2+ are adopted over the Iub interface and the bandwidth of Iub interface is affected by line quality. IP traffic convergence. When HSPA services are largely deployed, congestion occurs if multiple nodes transmit packets with large throughput simultaneously.
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 The The
transmitter sends a Forward Monitoring (FM) packet containing the count and timestamp of the transmit packet to the receiver. 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. 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.
You can run the ADD IPLOGICPORT command to enable the IP PM function:

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/FG2c/GOUa/GOUc board supports IP PM on the base station controller side.
You can run the ACT IPPM command to activate the IP PM, and the DEA IPPM command to deactivate the IP PM.
The IP PM for the Abis interface is similar to that for the Iub interface.
Issue 03 (2011-09-30)
6-16
7 Engineering Guidelines
7 Engineering Guidelines
This section provides engineering guidelines regarding the configuration of the TRM feature.
7.1 Configuring Co-TRM (with GSM BSC and UMTS RNC Combined)
The requirements for co-transmission networking are as follows:

GSM+UMTS dual-mode base station controllers and GSM+UMTS dual-mode base stations are deployed. GSM+UMTS multi-mode base stations share IP LP transmission resources over the Abis and Iub interfaces.
In Co-TRM networking, the GSM and UMTS services share LP resources. It is recommended that the GSM and UMTS services use a common LP. The principles of configuring bandwidth for an LP are as follows:
If an LP is carried on an Ethernet port (ETHER), the bandwidth of the LP should be lower than or equal to that of ETHER. Assume that the bandwidth of ETHER could be 5 kbit/s. Then, the bandwidth of the LP could be 4 kbit/s. If an LP is carried on the PPP link, the bandwidth of the LP should be lower than or equal to that of PPP link. If an LP is carried on the MLPPP link, the bandwidth of the LP should be lower than or equal to that of MLPPP link.
To configure Co-TRM, perform the following steps: Step 1 (Optional) Run the MML command ADD TRMLOADTH to configure the TRMLOADTH table. Set TRANST to IP. It is recommended that you set THTYPE to PERCENTAGE.
You can run the MML command LST TRMLOADTH to query the default TRMLOADTH table. The default value of TRMLOADTHINDEX is 3. If you want to set the parameter to a different value, perform this step. However, the default TRMLOADTH table is strongly recommended.
Step 2 Run the MML command ADD IPLOGICPORT to set the LPNTYPE parameter to Leaf and change TRMLOADTHINDEX to the value set in Step 1. For example, ADD IPLOGICPORT: SRN=0, SN=0, BT=FG2c, LPNTYPE=Leaf, LPN=0, CARRYT=ETHER, PN=0, RSCMNGMODE=SHARE, BWADJ=OFF, CIR=200, FLOWCTRLSWITCH=ON, TRMLOADTHINDEX=3;
7.2 Using Default TRMLOADTH Table

A default TRM load threshold index list is provided for IP LPs. If the list is used when you run the ADD IPLOGICPORT command to configure IP LPs, the following modifications are required:

In the 2G and co-transmission systems, set the TRMLOADTHINDEX parameter to 3. In the 3G system, set the TRMLOADTHINDEX parameter to 2.
Issue 03 (2011-09-30)
7-1
8 Parameters
8 Parameters
Table 8-1 Parameter description for 2G TRM, 3G TRM, and Co-TRM Parameter ID NE MML Description
BWDCONGBW BSC6900
ADD Meaning: If the available backward bandwidth is TRMLOADTH(Optional) less than or equal to this value, the backward congestion alarm is emitted and backward congestion control is triggered. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
BWDCONGCLR BSC6900 BW
ADD Meaning: If the available backward bandwidth is TRMLOADTH(Optional) greater than this value, the backward congestion alarm is cleared and backward congestion control is stopped. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
BWDCONGCLR BSC6900 TH
ADD Meaning: If the ratio of available backward TRMLOADTH(Optional) bandwidth is greater than this value, the backward congestion alarm is cleared and backward congestion control is stopped. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 20
BWDCONGTH BSC6900
ADD Meaning: If the ratio of available backward TRMLOADTH(Optional) bandwidth is less than or equal to this value, the backward congestion alarm is emitted and backward congestion control is triggered. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 15
BWDOVLDCLR BSC6900 RSVBW
ADD Meaning: If the available backward bandwidth is TRMLOADTH(Optional) greater than this value, the backward overload congestion alarm is cleared and backward overload control is stopped. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
Issue 03 (2011-09-30)
8-1
8 Parameters
Parameter ID
NE
MML
Description
BWDOVLDCLR BSC6900 TH
ADD Meaning: If the ratio of available backward TRMLOADTH(Optional) bandwidth is greater than this value, the backward overload congestion alarm is cleared and backward overload control is stopped. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 1
BWDOVLDRSV BSC6900 BW
ADD Meaning: If the available backward bandwidth is TRMLOADTH(Optional) less than or equal to this value, the backward overload congestion alarm is emitted and backward overload control is triggered. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
BWDOVLDTH
BSC6900
ADD Meaning: If the ratio of available backward TRMLOADTH(Optional) bandwidth is less than or equal to this value, the backward overload congestion alarm is emitted and backward overload control is triggered. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 0
BWDRESVHOT BSC6900 H
ADD Meaning: Ratio of reserved backward bandwidth TRMLOADTH(Optional) for handover user GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 5
BWDRSVHOB BSC6900 W
ADD Meaning: Reserved backward bandwidth for TRMLOADTH(Optional) handover user GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
CIR
BSC6900
ADD Meaning: Bandwidth of the logical port IPLOGICPORT(Optiona l) GUI Value Range: 1~1562 MOD Actual Value Range: 64~100000, step:64 IPLOGICPORT(Optiona Unit: kbit/s l) Default Value: None
Issue 03 (2011-09-30)
8-2
8 Parameters
Parameter ID DSCP
NE BSC6900
MML
Description
SET Meaning: Differentiated service code is used to DSCPMAP(Mandatory) identify the service priority of the user. GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None
FCINDEX
BSC6900
SET OPT(Mandatory)
Meaning: Flow control parameter index GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: None
FCINDEX
BSC6900
SET Meaning: Flow control parameter index ETHPORT(Mandatory) GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: None ADD PPPLNK(Optional) Meaning: Flow control parameter index MOD PPPLNK(Mandatory) GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: 0 ADD MPGRP(Optional) Meaning: Flow control parameter index MOD MPGRP(Mandatory) GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: 0 ADD Meaning: Flow control parameter index IPLOGICPORT(Optiona l) GUI Value Range: 0~1999 MOD Actual Value Range: 0~1999 IPLOGICPORT(Optiona Unit: None l) Default Value: 0 SET OPT(Optional) Meaning: Port flow control switch GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None Default Value: None
FCINDEX
BSC6900
FCINDEX
BSC6900
FCINDEX
BSC6900
FLOWCTRLSWI BSC6900 TCH
SET ETHPORT(Optional)
Meaning: Port flow control switch GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None
Issue 03 (2011-09-30)
8-3
8 Parameters
Parameter ID
NE
MML
Description Default Value: None
ADD PPPLNK(Optional) Meaning: Link flow control switch MOD PPPLNK(Optional) GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None Default Value: ON ADD MPGRP(Optional) Meaning: Link flow control switch MOD MPGRP(Optional) GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None Default Value: ON ADD Meaning: Logical port flow control switch IPLOGICPORT(Optiona l) GUI Value Range: OFF(OFF), ON(ON) MOD Actual Value Range: OFF, ON IPLOGICPORT(Optiona Unit: None l) Default Value: ON ADD ADJMAP(Mandatory) MOD ADJMAP(Optional) Meaning: Activation factor table index GUI Value Range: 0~33 Actual Value Range: 0~33 Unit: None Default Value: None
FTI
BSC6900
FTI
BSC6900
ADD Meaning: Activation factor table index TRMFACTOR(Mandato ry) GUI Value Range: 1~33 MOD Actual Value Range: 1~33 TRMFACTOR(Mandato Unit: None Default Value: None ry) RMV TRMFACTOR(Mandato ry) ADD Meaning: If the available forward bandwidth is less TRMLOADTH(Optional) than or equal to this value, the forward congestion alarm is emitted and forward congestion control is triggered. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
FWDCONGBW BSC6900
Issue 03 (2011-09-30)
8-4
8 Parameters
Parameter ID
NE
MML
Description
FWDCONGCLR BSC6900 BW
ADD Meaning: If the available forward bandwidth is TRMLOADTH(Optional) greater than this value, the forward congestion alarm is cleared and forward congestion control is stopped. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
FWDCONGCLR BSC6900 TH
ADD Meaning: If the ratio of available forward TRMLOADTH(Optional) bandwidth is greater than this value, the forward congestion alarm is cleared and forward congestion control is stopped. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 20
FWDCONGTH BSC6900
ADD Meaning: If the ratio of available forward TRMLOADTH(Optional) bandwidth is less than or equal to this value, the forward congestion alarm is emitted and forward congestion control is triggered. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 15
FWDOVLDCLR BSC6900 RSVBW
ADD Meaning: If the available forward bandwidth is TRMLOADTH(Optional) greater than this value, the forward overload congestion alarm is cleared and forward overload control is stopped. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
FWDOVLDCLR BSC6900 TH
ADD Meaning: If the ratio of available forward TRMLOADTH(Optional) bandwidth is greater than this value, the forward overload congestion alarm is cleared and forward overload control is stopped. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 1
Issue 03 (2011-09-30)
8-5
8 Parameters
Parameter ID
NE
MML
Description
FWDOVLDRSV BSC6900 BW
ADD Meaning: If the available forward bandwidth is less TRMLOADTH(Optional) than or equal to this value, the forward overload congestion alarm is emitted and forward overload control is triggered. GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
FWDOVLDTH
BSC6900
ADD Meaning: If the ratio of available forward TRMLOADTH(Optional) bandwidth is less than or equal to this value, the forward overload congestion alarm is emitted and forward overload control is triggered. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 0
FWDRESVHOT BSC6900 H
ADD Meaning: Ratio of reserved forward bandwidth for TRMLOADTH(Optional) handover user GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 5
FWDRSVHOB BSC6900 W
ADD Meaning: Reserved forward bandwidth for TRMLOADTH(Optional) handover user GUI Value Range: 0~200000 Actual Value Range: 0~200000 Unit: kbit/s Default Value: 0
LPNTYPE
BSC6900
ADD Meaning: Type of logical port IPLOGICPORT(Mandat ory) GUI Value Range: Hub(Hub), Leaf(Leaf) MOD Actual Value Range: Hub, Leaf IPLOGICPORT(Mandat Unit: None ory) Default Value: None ADD Meaning: Maximum bandwidth for dynamic IPLOGICPORT(Optiona adjustment at the logical port l) MOD GUI Value Range: 1~1562 IPLOGICPORT(Optiona Actual Value Range: 64~100000, step:64 l) Unit: kbit/s Default Value: None
MAXBW
BSC6900
Issue 03 (2011-09-30)
8-6
8 Parameters
Parameter ID MINBW
NE BSC6900
MML
Description
ADD Meaning: Minimum bandwidth for dynamic IPLOGICPORT(Optiona adjustment at the logical port l) MOD GUI Value Range: 1~1562 IPLOGICPORT(Optiona Actual Value Range: 64~100000, step:64 l) Unit: kbit/s Default Value: None SET ETHPORT(Optional) Meaning: Ratio of the minimum guarantee bandwidth of the OAM stream to the port bandwidth GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: None
OAMFLOWBW BSC6900
OAMFLOWBW BSC6900
ADD PPPLNK(Optional) Meaning: Minimum guarantee bandwidth of the MOD OAM stream PPPLNK(Optional) GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 0 ADD MPGRP(Optional) Meaning: Minimum guarantee bandwidth of the MOD MPGRP(Optional) OAM stream GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 0
OAMFLOWBW BSC6900
OAMFLOWBW BSC6900
ADD Meaning: Minimum guarantee bandwidth of the IPLOGICPORT(Optiona OAM stream l) MOD GUI Value Range: 0~100 IPLOGICPORT(Optiona Actual Value Range: 0~100 l) Unit: % Default Value: 0 SET PHBMAP(Mandatory) Meaning: Value of the per-hop behavior (PHB) GUI Value Range: BE(BE), AF11(AF11), AF12(AF12), AF13(AF13), AF21(AF21), AF22(AF22), AF23(AF23), AF31(AF31), AF32(AF32), AF33(AF33), AF41(AF41), AF42(AF42), AF43(AF43), EF(EF) Actual Value Range: BE, AF11, AF12, AF13, AF21, AF22, AF23, AF31, AF32, AF33, AF41, AF42, AF43, EF Unit: None Default Value: None
PHB
BSC6900
Issue 03 (2011-09-30)
8-7
8 Parameters
Parameter ID Q0MINDSCP
NE BSC6900
MML
Description
SET Meaning: Minimum DSCP of queue 0. The IP QUEUEMAP(Optional) packets with DSCP in a relation that "Min DSCP of queue 0" <= DSCP <= 63 is added to queue 0. GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None
Q1MINDSCP
BSC6900
SET Meaning: Minimum DSCP of queue 1. The IP QUEUEMAP(Optional) packets with DSCP in a relation that "Min DSCP of queue 1" <= DSCP < "Min DSCP of queue 0" is added to queue 1. GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None
Q2MINDSCP
BSC6900
Q3MINDSCP
BSC6900
Q4MINDSCP
BSC6900
SET Meaning: Minimum DSCP of queue 4. The IP QUEUEMAP(Optional) packets with DSCP in a relation that "Min DSCP of queue 4" <= DSCP < "Min DSCP of queue 3" is added to queue 4. The IP packets with DSCP in a relation that 0 <= DSCP < "Min DSCP of queue 4" is added to queue 5. GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None
Issue 03 (2011-09-30)
8-8
8 Parameters
Parameter ID TRANST
NE BSC6900
MML ADD IPPATH(Mandatory)
Description Meaning: Transport type of the adjacent node to which the path belongs GUI Value Range: IP(IP), HYBRID_IP(HYBRID IP) Actual Value Range: IP, HYBRID_IP Unit: None Default Value: None
TRANST
BSC6900
ADD TRMMAP(Optional) MOD TRMMAP(Optional)
Meaning: This parameter indicates the transport type. GUI Value Range: ATM(ATM), IP(IP), ATM_IP(ATM and IP), HYBRID_IP(HYBRID IP), HDLC(HDLC) Actual Value Range: ATM, IP, ATM_IP, HYBRID_IP, HDLC Unit: None Default Value: None
TRANST
BSC6900
ADD Meaning: Transport type TRMLOADTH(Mandato ry) GUI Value Range: ATM(ATM), IP(IP), HDLC(HDLC), TDM(TDM) Actual Value Range: ATM, IP, HDLC, TDM Unit: None Default Value: None ADD IPPATH(Optional) Meaning: TRM load threshold index. The TRM MOD IPPATH(Optional) load threshold must be configured. GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: 2
TRMLOADTHIN BSC6900 DEX
ADD TRMLOADTH(Mandato ry) RMV TRMLOADTH(Mandato ry)
Meaning: TRM load threshold index. It is the unique ID of the load threshold. GUI Value Range: 10~199 Actual Value Range: 10~199 Unit: None Default Value: None
ADD Meaning: TRM load threshold index IPLOGICPORT(Optiona l) GUI Value Range: 0~199 MOD Actual Value Range: 0~199 IPLOGICPORT(Optiona Unit: None l) Default Value: 2
Issue 03 (2011-09-30)
8-9
8 Parameters
Parameter ID VLANFlAG
NE BSC6900
MML
Description
ADD IPPATH(Optional) Meaning: If the parameter is set to Disable, the MOD IPPATH(Optional) added IP path is not configured with the VLAN ID. If the parameter is set to Enable, the added IP path is configured with the VLAN ID. GUI Value Range: DISABLE(Disable), ENABLE(Enable) Actual Value Range: DISABLE, ENABLE Unit: None Default Value: DISABLE
VLANPRI
BSC6900
SET DSCPMAP(Optional)
Meaning: VLAN priority GUI Value Range: 0~7 Actual Value Range: 0~7 Unit: None Default Value: None
CNOPINDEX
BSC6900
ADD Meaning: Index of the operator IPLOGICPORT(Optiona l) GUI Value Range: 0~3 Actual Value Range: 0~3 Unit: None Default Value: None ADD Meaning: Resource management mode. The IPLOGICPORT(Optiona logical port working in the SHARE mode can be l) shared by multiple carriers. The logical port working in the EXCLUSIVE mode can be used by only one carrier. GUI Value Range: SHARE, EXCLUSIVE Actual Value Range: SHARE, EXCLUSIVE Unit: None Default Value: None
RSCMNGMOD BSC6900 E
DSCP
BSC6900
SET PHBMAP(Mandatory)
Meaning: The DSCP is a field of the IP data packet. It is used to assign the differentiated service to the communication networks. The DSCP code is used to label each data packet on the network and allocate the corresponding service levels. In the same network environment, the larger the DSCP is, the higher the priority is. GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: 48
Issue 03 (2011-09-30)
8-10
8 Parameters
Parameter ID DSCP
NE BSC6900
MML ADD SCTPLNK(Optional) MOD SCTPLNK(Optional)
Description Meaning: The DSCP is a field of the IP data packet. It is used to assign the differentiated service to the communication networks. The DSCP code is used to label each data packet on the network and allocate the corresponding service levels. In the same network environment, the larger the DSCP is, the higher the priority is. GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: 48
ITFT
BSC6900
ADD ADJMAP(Mandatory) MOD ADJMAP(Mandatory) RMV ADJMAP(Mandatory)
Meaning: This parameter indicates the type of the adjacent node. GUI Value Range: IUB(Iub Interface), IUR(Iur Interface), IUCS(Iu-CS Interface), IUPS(Iu-PS Interface), ABIS(Abis Interface), A(A Interface), ATER(ATER Interface), IUR_G(IUR_G Interface) Actual Value Range: IUB, IUR, IUCS, IUPS, ABIS, A, ATER, IUR_G Unit: None Default Value: None Meaning: This parameter indicates the type of the adjacent node. GUI Value Range: IUB(Iub Interface), IUR(Iur Interface), IUCS(Iu-CS Interface), IUPS(Iu-PS Interface), ABIS(Abis Interface), A(A Interface), ATER(ATER Interface), IUR_G(IUR_G Interface) Actual Value Range: IUB, IUR, IUCS, IUPS, ABIS, A, ATER, IUR_G Unit: None Default Value: None Meaning: This parameter indicates the type of the adjacent node. GUI Value Range: IUB(Iub Interface), IUR(Iur Interface), IUCS(Iu-CS Interface), IUPS(Iu-PS Interface), ABIS(Abis Interface), A(A Interface), ATER(ATER Interface), IUR_G(IUR_G Interface) Actual Value Range: IUB, IUR, IUCS, IUPS, ABIS, A, ATER, IUR_G Unit: None Default Value: None
ITFT
BSC6900
ADD IPPATH(Mandatory) MOD IPPATH(Mandatory)
ITFT
BSC6900
ADD TRMMAP(Mandatory) MOD TRMMAP(Mandatory)
Issue 03 (2011-09-30)
8-11
8 Parameters
Parameter ID TRANST
NE BSC6900
MML ADD ADJMAP(Mandatory) MOD ADJMAP(Optional)
Description Meaning: Transport type of the adjacent node and interface type GUI Value Range: ATM(ATM), IP(IP), ATM_IP(ATM and IP), HYBRID_IP(HYBRID IP) Actual Value Range: ATM, IP, ATM_IP, HYBRID_IP Unit: None Default Value: None
TRANST
BSC6900
ADD Meaning: This parameter indicates the transport ADJNODE(Mandatory) type of the adjacent node. MOD ADJNODE(Optional) GUI Value Range: ATM(ATM), IP(IP), ATM_IP(ATM and IP), HYBRID_IP(HYBRID IP) Actual Value Range: ATM, IP, ATM_IP, HYBRID_IP Unit: None Default Value: None ADD IPPATH(Mandatory) MOD IPPATH(Mandatory) Meaning: VLANID of the IP address of the specified next hop GUI Value Range: 2~4094 Actual Value Range: 2~4094 Unit: None Default Value: None Meaning: VLANID of the IP address of the specified next hop GUI Value Range: 2~4094 Actual Value Range: 2~4094 Unit: None Default Value: None
VLANID
BSC6900
VLANID
BSC6900
ADD VLANID(Mandatory)
Table 8-2 Parameter Description for 3G TRM Parameter ID NE MML Description
CarrierTypePrior BSC6900 Ind
SET Meaning: Decide which carrier is prior when ARP UUSERPRIORITY(Opti and TrafficClass are both identical. onal) GUI Value Range: NONE, DCH, HSPA Actual Value Range: NONE, DCH, HSPA Unit: None Default Value: NONE
Issue 03 (2011-09-30)
8-12
8 Parameters
Parameter ID
NE
MML
Description
CONGCLRTHD BSC6900 0
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 0 is less than or equals to the value of this A(Optional) parameter, flow control is canceled. For the flow control adopting the ATM, this parameter indicates the recovery threshold for congestion in the CBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 15
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 1 is less than or equals to the value of this A(Optional) parameter, flow control is canceled. For the flow control adopting the ATM, this parameter indicates the recovery threshold for congestion in the RTVBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 15
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 2 is less than or equals to the value of this A(Optional) parameter, flow control is canceled. For the flow control adopting the ATM, this parameter indicates the recovery threshold for congestion in the NRTVBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 15
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 3 is less than or equals to the value of this A(Optional) parameter, flow control is canceled. For the flow control adopting the ATM, this parameter indicates the recovery threshold for congestion in the UBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 15
Issue 03 (2011-09-30)
8-13
8 Parameters
Parameter ID
NE
MML
Description
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 4 is less than or equals to the value of this A(Optional) parameter, flow control is canceled. For the flow control adopting the ATM, this parameter indicates the recovery threshold for congestion in the UBR+ queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 25
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 5 is less than or equals to the value of this A(Optional) parameter, flow control is canceled. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 25
CONGTHD0
BSC6900
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 0 is more than or equals to the value of this A(Optional) parameter, flow control is triggered. For the flow control adopting the ATM, this parameter indicates the threshold for congestion in the CBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 25
CONGTHD1
BSC6900
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 1 is more than or equals to the value of this A(Optional) parameter, flow control is triggered. For the flow control adopting the ATM, this parameter indicates the threshold for congestion in the RTVBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 25
CONGTHD2
BSC6900
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 2 is more than or equals to the value of this A(Optional) parameter, flow control is triggered. For the flow control adopting the ATM, this parameter indicates the threshold for congestion in the NRTVBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 25
Issue 03 (2011-09-30)
8-14
8 Parameters
Parameter ID CONGTHD3
NE BSC6900
MML
Description
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 3 is more than or equals to or equals to the A(Optional) value of this parameter, flow control is triggered. For the flow control adopting the ATM, this parameter indicates the threshold for congestion in the UBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 25
CONGTHD4
BSC6900
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 4 is more than or equals to the value of this A(Optional) parameter, flow control is triggered. For the flow control adopting the ATM, this parameter indicates the threshold for congestion in the UBR+ queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 50
CONGTHD5
BSC6900
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 5 is more than or equals to the value of this A(Optional) parameter, flow control is triggered. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 50
DlGBR
BSC6900
SET Meaning: Downlink guaranteed bit rate (GBR) of UUSERGBR(Optional) the BE service. GBR is the minimum bit rate that the system shall guarantee for the service.When BearType set to R99,virtual value of DlGBR is not greater than D384. GUI Value Range: D0, D8, D16, D32, D64, D128, D144, D256, D384, D512, D768, D1024, D1536, D1800, D2048, D3600, D7200, D8640, D10100, D13900, D16000, D21000 Actual Value Range: 0, 8, 16, 32, 64, 128, 144, 256, 384, 512, 768, 1024, 1536, 1800, 2048, 3600, 7200, 8640, 10100, 13900, 16000, 21000 Unit: kbit/s Default Value: D64
Issue 03 (2011-09-30)
8-15
8 Parameters
Parameter ID
NE
MML
Description
DlR99CongCtrlS BSC6900 witch
SET Meaning: When the switch is on, the congestion UDPUCFGDATA(Optio detection and control for DL R99 service is nal) supported. GUI Value Range: OFF(The switch of DL R99 congestion control is off), ON(The switch of DL R99 congestion control is on) Actual Value Range: OFF, ON Unit: None Default Value: OFF
DraSwitch
BSC6900
SET Meaning: Dynamic resource allocation switch UCORRMALGOSWITC group. H(Optional) 1) DRA_AQM_SWITCH: When the switch is on, the active queue management algorithm is used for the RNC. 2) DRA_BASE_ADM_CE_BE_TTI_L2_OPT_SWITC H: When the switch is on, the TTI dynamic adjustment algorithm for admission CE-based BE services applies to the UE with the UL enhanced L2 feature. This parameter is valid when DRA_BASE_ADM_CE_BE_TTI_RECFG_SWITC H(DraSwitch) is set to ON. 3) DRA_BASE_ADM_CE_BE_TTI_RECFG_SWITC H: When the switch is on, the TTI dynamic adjustment algorithm is supported for admission CE-based BE services. 4) DRA_BASE_COVER_BE_TTI_L2_OPT_SWITCH : When the switch is on, the TTI dynamic adjustment algorithm for coverage-based BE services applies to the UE with the UL enhanced L2 feature. This parameter is valid when DRA_BASE_COVER_BE_TTI_RECFG_SWITCH (DraSwitch) is set to ON. 5) DRA_BASE_COVER_BE_TTI_RECFG_SWITCH: When the switch is on, the TTI dynamic adjustment algorithm is supported for coverage-based BE services. 6) DRA_BASE_RES_BE_TTI_L2_OPT_SWITCH: When the switch is on, the TTI dynamic adjustment algorithm for differentiation-based BE services applies to the UE with the UL enhanced L2 feature. This parameter is valid when DRA_BASE_RES_BE_TTI_RECFG_SWITCH(Dr aSwitch) is set to ON. 7) DRA_BASE_RES_BE_TTI_RECFG_SWITCH: When the switch is on, the TTI dynamic adjustment algorithm is supported for differentiation-based BE services.
Issue 03 (2011-09-30)
8-16
8 Parameters
Parameter ID
NE
MML
Description 8) DRA_DCCC_SWITCH: When the switch is on, the dynamic channel reconfiguration control algorithm is used for the RNC. 9) DRA_HSDPA_DL_FLOW_CONTROL_SWITCH: When the switch is on, flow control is enabled for HSDPA services in AM mode. 10) 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. 11) 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. 12) 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. 13) DRA_IP_SERVICE_QOS_SWITCH: Switch of the algorithm for increasing the quality of subscribed services. When this parameter is set to ON, the service priority weight of the subscriber whose key parameters (IP Address, IP Port, and IP Protocol Type) match the specified ones can be adjusted. In this way, the QoS is improved. 14) 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. 15) 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. 16) 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
Issue 03 (2011-09-30)
8-17
8 Parameters
Parameter ID
NE
MML
Description speed and TX power. When the switch is on, the R99 downlink flow control function is enabled. 17) DRA_THROUGHPUT_DCCC_SWITCH: When the switch is on, the DCCC based on traffic statistics is supported over the DCH. 18) DRA_VOICE_SAVE_CE_SWITCH: when the switch is on, the TTI selection based on the voice service type (including VoIP and CS over HSPA) is supported when the service is initially established. 19) DRA_VOICE_TTI_RECFG_SWITCH: when the switch is on, the TTI adjustment based on the voice service type (including VoIP and CS over HSPA) is supported. GUI Value Range: DRA_AQM_SWITCH, DRA_BASE_ADM_CE_BE_TTI_L2_OPT_SWITC H, DRA_BASE_ADM_CE_BE_TTI_RECFG_SWITC H, DRA_BASE_COVER_BE_TTI_L2_OPT_SWITCH , DRA_BASE_COVER_BE_TTI_RECFG_SWITCH, DRA_BASE_RES_BE_TTI_L2_OPT_SWITCH, DRA_BASE_RES_BE_TTI_RECFG_SWITCH, DRA_DCCC_SWITCH, DRA_HSDPA_DL_FLOW_CONTROL_SWITCH, DRA_HSDPA_STATE_TRANS_SWITCH, DRA_HSUPA_DCCC_SWITCH, DRA_HSUPA_STATE_TRANS_SWITCH, DRA_IP_SERVICE_QOS_SWITCH, DRA_PS_BE_STATE_TRANS_SWITCH, DRA_PS_NON_BE_STATE_TRANS_SWITCH, DRA_R99_DL_FLOW_CONTROL_SWITCH, DRA_THROUGHPUT_DCCC_SWITCH, DRA_VOICE_SAVE_CE_SWITCH, DRA_VOICE_TTI_RECFG_SWITCH Actual Value Range: DRA_AQM_SWITCH, DRA_BASE_ADM_CE_BE_TTI_L2_OPT_SWITC H, DRA_BASE_ADM_CE_BE_TTI_RECFG_SWITC H, DRA_BASE_COVER_BE_TTI_L2_OPT_SWITCH , DRA_BASE_COVER_BE_TTI_RECFG_SWITCH, DRA_BASE_RES_BE_TTI_L2_OPT_SWITCH, DRA_BASE_RES_BE_TTI_RECFG_SWITCH, DRA_DCCC_SWITCH, DRA_HSDPA_DL_FLOW_CONTROL_SWITCH, DRA_HSDPA_STATE_TRANS_SWITCH, DRA_HSUPA_DCCC_SWITCH, DRA_HSUPA_STATE_TRANS_SWITCH, DRA_IP_SERVICE_QOS_SWITCH,
Issue 03 (2011-09-30)
8-18
8 Parameters
Parameter ID
NE
MML
Description DRA_PS_BE_STATE_TRANS_SWITCH, DRA_PS_NON_BE_STATE_TRANS_SWITCH, DRA_R99_DL_FLOW_CONTROL_SWITCH, DRA_THROUGHPUT_DCCC_SWITCH, DRA_VOICE_SAVE_CE_SWITCH, DRA_VOICE_TTI_RECFG_SWITCH Unit: None Default Value: None
DROPPKTTHD BSC6900 0
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 0 is more than or equals to the value of this A(Optional) parameter, the subsequent packets added to queue 0 are discarded. For the flow control adopting the ATM, this parameter indicates the threshold for discarding packets in the CBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 60
Issue 03 (2011-09-30)
8-19
8 Parameters
Parameter ID
NE
MML
Description
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 1 is more than or equals to the value of this A(Optional) parameter, the subsequent packets added to queue 1 are discarded. For the flow control adopting the ATM, this parameter indicates the threshold for discarding packets in the RTVBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 60
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 2 is more than or equals to the value of this A(Optional) parameter, the subsequent packets added to queue 2 are discarded. For the flow control adopting the ATM, this parameter indicates the threshold for discarding packets in the NRTVBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 60
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 3 is more than or equals to the value of this A(Optional) parameter, the subsequent packets added to queue 3 are discarded. For the flow control adopting the ATM, this parameter indicates the threshold for discarding packets in the UBR queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 60
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 4 is more than or equals to the value of this A(Optional) parameter, the subsequent packets added to queue 4 are discarded. For the flow control adopting the ATM, this parameter indicates the threshold for discarding packets in the UBR+ queue. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 80
Issue 03 (2011-09-30)
8-20
8 Parameters
Parameter ID
NE
MML
Description
ADD Meaning: If the duration for buffering the data in PORTFLOWCTRLPAR queue 5 is more than or equals to the value of this A(Optional) parameter, the subsequent packets added to queue 5 are discarded. GUI Value Range: 10~150 Actual Value Range: 10~150 Unit: ms Default Value: 80
FCINDEX
BSC6900
ADD Meaning: Flow control parameter index ATMLOGICPORT(Optio nal) GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: 1 ADD Meaning: This parameter applies to the FG2a, PORTFLOWCTRLPAR GOUa, and UOIa(IP) boards. For the boards A(Optional) working in ATM transmission mode, this parameter is always set to 2. For the FG2c, GOUc, or POUc board, this parameter is always set to 2. GUI Value Range: 0~5 Actual Value Range: 0~5 Unit: None Default Value: 2
PQNUM
BSC6900
PreemptAlgoSwi BSC6900 tch
SET Meaning: Determines whether preemption is UQUEUEPREEMPT(O supported. When this switch is enabled, the RNC ptional) allows privileged users or services to preempt cell resources from the users or services with the preempted attributes and lower priority in the case of cell resource insufficiency. When the switch is disabled, the RNC terminates the service for the user due to the failure in cell resource application. GUI Value Range: OFF, ON Actual Value Range: OFF, ON Unit: None Default Value: OFF
QueueAlgoSwitc BSC6900 h
SET Meaning: Indicating whether queue is supported. UQUEUEPREEMPT(O When a user initiates a call, if cell resources are ptional) insufficient and the user is queue supportive, the RNC tries to arrange this user to join the queue to increase access success ratio. GUI Value Range: OFF, ON Actual Value Range: OFF, ON Unit: None Default Value: OFF
Issue 03 (2011-09-30)
8-21
8 Parameters
Parameter ID
NE
MML ADD RSCGRP(Mandatory)
Description Meaning: The parameter indicates whether the resource group is shared or is used by a specific telecom carrier. GUI Value Range: SHARE(SHARE), EXCLUSIVE(EXCLUSIVE) Actual Value Range: SHARE, EXCLUSIVE Unit: None Default Value: None
RSCMNGMOD BSC6900 E
RSCMNGMOD BSC6900 E
ADD Meaning: Resource management mode of logical ATMLOGICPORT(Optio port nal) GUI Value Range: SHARE, EXCLUSIVE Actual Value Range: SHARE, EXCLUSIVE Unit: None Default Value: None SET Meaning: Traffic Handling Priority (THP) class that UUSERGBR(Mandator the THP priority is mapped to. This parameter is y) valid for only interactive services. The mapping relationship between the traffic handling priority value of INTERACTIVE service and its corresponding class can be set through command "SET UTHPCLASS". GUI Value Range: High, Medium, Low Actual Value Range: High, Medium, Low Unit: None Default Value: None
THPClass
BSC6900
TrafficClass
BSC6900
SET Meaning: Traffic class. This parameter only USCHEDULEPRIOMA applies to interactive and background services, as P(Mandatory) the Scheduling Priority Indicator (SPI) of the other classes such as conversational or streaming are configured by default. GUI Value Range: INTERACTIVE, BACKGROUND Actual Value Range: INTERACTIVE, BACKGROUND Unit: None Default Value: None
TrafficClass
BSC6900
SET Meaning: Traffic class which includes Best UUSERGBR(Mandator Effort(BE) and PTT. BE services comprise y) interactive services, background services, and IMS. GUI Value Range: INTERACTIVE, BACKGROUND, IMSSIGNALLING, PTT Actual Value Range: INTERACTIVE, BACKGROUND, IMSSIGNALLING, PTT Unit: None
Issue 03 (2011-09-30)
8-22
8 Parameters
Parameter ID
NE
MML
Description Default Value: None
UlGBR
BSC6900
SET Meaning: Uplink guaranteed bit rate (GBR) of the UUSERGBR(Optional) BE service. GBR is the minimum bit rate that the system can guarantee for the service.When BearType set to R99,virtual value of UlGBR is not greater than D384. GUI Value Range: D0, D8, D16, D32, D64, D128, D144, D256, D384, D608, D1280, D2048, D2720, D5440 Actual Value Range: 0, 8, 16, 32, 64, 128, 144, 256, 384, 608, 1280, 2048, 2720, 5440 Unit: kbit/s Default Value: D64
UserPriority
BSC6900
SET Meaning: User priority that is defined according to USCHEDULEPRIOMA the Allocation/Retention Priority (ARP) from the P(Mandatory) RAB assignment. The user classes in descending order of priority are Gold, Silver, and Copper. For details, see help information of the "SET UUSERPRIORITY" command. GUI Value Range: GOLD, SILVER, COPPER Actual Value Range: GOLD, SILVER, COPPER Unit: None Default Value: None
UserPriority
BSC6900
SET Meaning: User priority that is defined according to UUSERGBR(Mandator the Allocation/Retention Priority (ARP) from the y) RAB assignment. The user classes in descending order of priority are Gold, Silver, and Copper. For details, see help information of the "SET UUSERPRIORITY" command. GUI Value Range: GOLD, SILVER, COPPER Actual Value Range: GOLD, SILVER, COPPER Unit: None Default Value: None
ADD Meaning: TRM load threshold index ATMLOGICPORT(Optio nal) GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None
Issue 03 (2011-09-30)
8-23
8 Parameters
Parameter ID
NE
MML
Description Default Value: 0
BearType
BSC6900
SET Meaning: Bearer type of the service. R99 indicates UUSERGBR(Mandator that the service is carried on a non-HSPA channel. y) HSPA indicates that the service is carried on an HSPA channel. GUI Value Range: R99, HSPA Actual Value Range: R99, HSPA Unit: None Default Value: None
BWADJ
BSC6900
ADD Meaning: Switch for adjusting the dynamical IPLOGICPORT(Mandat bandwidth of the logical port. If this switch is ory) turned on, the system adjusts the dynamical MOD bandwidth of the logical port according to the IPLOGICPORT(Optiona transmission quality of the link monitored by the l) IPPM. After this switch is turned on, the IPPM function must be activated on the IPPATH of this logical port. For details about the IPPM, see the description of the command "ACT IPPM". GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None Default Value: None
CNMNGMODE BSC6900
Meaning: Resource management mode. When the interface type is IUB, the value can be set to SHARE or EXCLUSIVE. When the interface type is IUR, IUCS, or IUPS, the value can be set to SHARE only. GUI Value Range: SHARE(SHARE), EXCLUSIVE(EXCLUSIVE) Actual Value Range: SHARE, EXCLUSIVE Unit: None Default Value: None
CNOPINDEX
BSC6900
Meaning: Operator index of the resource group GUI Value Range: 0~3 Actual Value Range: 0~3 Unit: None Default Value: None
Issue 03 (2011-09-30)
8-24
8 Parameters
Parameter ID CNOPINDEX
NE BSC6900
MML
Description
ADD Meaning: Index of the operator ATMLOGICPORT(Optio nal) GUI Value Range: 0~3 Actual Value Range: 0~3 Unit: None Default Value: None ADD Meaning: Index of the operator IPLOGICPORT(Optiona l) GUI Value Range: 0~3 Actual Value Range: 0~3 Unit: None Default Value: None ADD RSCGRP(Mandatory) Meaning: Operator index of the resource group GUI Value Range: 0~3 Actual Value Range: 0~3 Unit: None Default Value: None
CNOPINDEX
BSC6900
CNOPINDEX
BSC6900
EventAThred
BSC6900
ADD Meaning: Threshold of event A, that is, the upper UTYPRABRLC(Optiona limit of RLC retransmission ratio. When the l) monitored RLC retransmission ratio exceeds this MOD threshold and triggers the event A, it indicates that UTYPRABRLC(Optiona the quality of the radio link is poor, and flow control l) measures need to be taken to reduce the RLC throughput. GUI Value Range: 0~1000 Actual Value Range: 0~100, step: 0.1 Unit: % Default Value: 160
EventBThred
BSC6900
ADD Meaning: Threshold of event B, that is, the lower UTYPRABRLC(Optiona limit of RLC retransmission ratio. hen the l) monitored RLC retransmission ratio goes lower MOD than this threshold and triggers the event B, it UTYPRABRLC(Optiona indicates that the quality of the radio link is good, l) and RLC throughput can be increased. GUI Value Range: 0~1000 Actual Value Range: 0~100, step: 0.1 Unit: % Default Value: 80
FCINDEX
BSC6900
MOD Meaning: Flow control parameter index ATMLOGICPORT(Man datory) GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: None
Issue 03 (2011-09-30)
8-25
8 Parameters
Parameter ID FCINDEX
NE BSC6900
MML
Description
ADD FRALNK(Optional) Meaning: Flow control parameter index. This MOD parameter must be a flow control parameter that is FRALNK(Mandatory) already set through the "ADD PORTFLOWCTRLPARA" command. GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: 1
FCINDEX
BSC6900
ADD IMAGRP(Optional) Meaning: Flow control parameter index MOD IMAGRP(Mandatory) GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: 1 ADD PORTFLOWCTRLPAR A(Mandatory) RMV PORTFLOWCTRLPAR A(Mandatory) Meaning: Flow control parameter index GUI Value Range: 10~1999 Actual Value Range: 10~1999 Unit: None Default Value: None
FCINDEX
BSC6900
FCINDEX
BSC6900
ADD UNILNK(Optional) Meaning: Flow control parameter index MOD UNILNK(Mandatory) GUI Value Range: 0~1999 Actual Value Range: 0~1999 Unit: None Default Value: 1 ADD LOADEQ(Mandatory) MOD LOADEQ(Mandatory) RMV LOADEQ(Mandatory) Meaning: Path load EQ threshold table index GUI Value Range: 1~63 Actual Value Range: 1~63 Unit: None Default Value: None
LEI
BSC6900
LEIBRZ
BSC6900
ADD ADJMAP(Mandatory) MOD ADJMAP(Optional)
Meaning: Bronze user load EQ index used by the current adjacent node GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None
Issue 03 (2011-09-30)
8-26
8 Parameters
Parameter ID LEIGLD
NE BSC6900
MML ADD ADJMAP(Mandatory) MOD ADJMAP(Optional)
Description Meaning: Gold user load EQ index used by the current adjacent node GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None Meaning: Silver user load EQ index used by the current adjacent node GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None
LEISLV
BSC6900
MoniterPrd
BSC6900
ADD Meaning: Sampling period of the RLC UTYPRABRLC(Optiona retransmission ratio monitoring l) MOD GUI Value Range: 40~60000 UTYPRABRLC(Optiona Actual Value Range: 40~60000 l) Unit: ms Default Value: 1000 ADD UNODEBALGOPARA( Optional) MOD UNODEBALGOPARA( Optional) Meaning: 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. GUI Value Range: IUB_LDR(IUB LDR Algorithm), NODEB_CREDIT_LDR(NodeB Credit LDR Algorithm), LCG_CREDIT_LDR(LCG Credit LDR Algorithm), IUB_OLC(IUB OLC Algorithm)
NodeBLdcAlgoS BSC6900 witch
Issue 03 (2011-09-30)
8-27
8 Parameters
Parameter ID
NE
MML
Description Actual Value Range: IUB_LDR, NODEB_CREDIT_LDR, LCG_CREDIT_LDR, IUB_OLC Unit: None Default Value: None
PendingTimeA BSC6900
ADD Meaning: Number of pending periods after event A UTYPRABRLC(Optiona related to RLC retransmission ratio is triggered. l) During the pending time, no such event is MOD reported. UTYPRABRLC(Optiona l) GUI Value Range: 0~1000 Actual Value Range: 0~1000 Unit: None Default Value: 1 ADD Meaning: Number of pending periods after event B UTYPRABRLC(Optiona related to RLC retransmission ratio is triggered. l) During the pending time, no such event is MOD reported. UTYPRABRLC(Optiona l) GUI Value Range: 0~1000 Actual Value Range: 0~1000 Unit: None Default Value: 1 SET Meaning: Scheduling priority of interactive and USPIWEIGHT(Mandato background services. Value 15 indicates the ry) highest priority, while value 0 indicates the lowest priority. GUI Value Range: 0~15 Actual Value Range: 0~15 Unit: None Default Value: None
PendingTimeB BSC6900
SPI
BSC6900
Issue 03 (2011-09-30)
8-28
8 Parameters
Parameter ID
NE
MML
Description
TimeToTriggerA BSC6900
ADD Meaning: Number of consecutive periods during UTYPRABRLC(Optiona which the percentage of retransmitted RLC PDUs l) is higher than the threshold of event A before MOD event A is triggered. UTYPRABRLC(Optiona l) GUI Value Range: 1~100 Actual Value Range: 1~100 Unit: None Default Value: 2 ADD Meaning: Number of consecutive periods during UTYPRABRLC(Optiona which the percentage of retransmitted RLC PDUs l) is higher than the threshold of event B before MOD event B is triggered. UTYPRABRLC(Optiona l) GUI Value Range: 1~100 Actual Value Range: 1~100 Unit: None Default Value: 14 ADD ADJMAP(Mandatory) MOD ADJMAP(Optional) Meaning: Bronze user TRMMAP index used by the current adjacent node GUI Value Range: 0~163 Actual Value Range: 0~163 Unit: None Default Value: None Meaning: Gold user TRMMAP index used by the current adjacent node GUI Value Range: 0~163 Actual Value Range: 0~163 Unit: None Default Value: None Meaning: Silver user TRMMAP index used by the current adjacent node GUI Value Range: 0~163 Actual Value Range: 0~163 Unit: None Default Value: None
TimeToTriggerB BSC6900
TMIBRZ
BSC6900
TMIGLD
BSC6900
TMISLV
BSC6900
ADD Meaning: Logical port flow control switch ATMLOGICPORT(Optio nal) GUI Value Range: OFF(OFF), ON(ON) MOD Actual Value Range: OFF, ON ATMLOGICPORT(Optio Unit: None nal) Default Value: ON
Issue 03 (2011-09-30)
8-29
8 Parameters
Parameter ID
NE
MML
Description
ADD FRALNK(Optional) Meaning: Link flow control switch MOD FRALNK(Optional) GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None Default Value: ON ADD IMAGRP(Optional) Meaning: Link flow control switch MOD IMAGRP(Optional) GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None Default Value: ON ADD UNILNK(Optional) Meaning: Logical port flow control switch MOD UNILNK(Optional) GUI Value Range: OFF(OFF), ON(ON) Actual Value Range: OFF, ON Unit: None Default Value: ON ADD ATMLOGICPORT(Man datory) MOD ATMLOGICPORT(Man datory) Meaning: Type of logical port GUI Value Range: Hub(Hub), Leaf(Leaf) Actual Value Range: Hub, Leaf Unit: None Default Value: None
LPNTYPE
BSC6900
RXTRFX
BSC6900
ADD Meaning: RX traffic record index of the AAL2 Path AAL2PATH(Mandatory) on the out RNC port (ATM layer PVC traffic). The MOD traffic index is configured in the ATM traffic table AAL2PATH(Optional) (see "LST ATMTRF"). GUI Value Range: 100~1999 Actual Value Range: 100~1999 Unit: None Default Value: None
RXTRFX
BSC6900
ADD Meaning: RX traffic record index of the SAAL link SAALLNK(Mandatory) MOD GUI Value Range: 100~1999 SAALLNK(Optional) Actual Value Range: 100~1999 Unit: None Default Value: None ADD Meaning: Backward bandwidth of the logical port ATMLOGICPORT(Man datory) GUI Value Range: 512~149000 MOD Actual Value Range: 512~149000 ATMLOGICPORT(Optio Unit: kbit/s nal) Default Value: None
RXBW
BSC6900
Issue 03 (2011-09-30)
8-30
8 Parameters
Parameter ID
NE
MML ADD AAL2PATH(Optional) MOD AAL2PATH(Optional)
Description Meaning: TRM load threshold index. The TRM load threshold must be configured (see "ADD TRMLOADTH"). GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: 0
MOD Meaning: TRM load threshold index ATMLOGICPORT(Optio nal) GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: None ADD FRALNK(Optional) Meaning: TRM load threshold index MOD FRALNK(Optional) GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: 0 ADD IMAGRP(Optional) Meaning: TRM load threshold index MOD IMAGRP(Optional) GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: 0 ADD RSCGRP(Optional) MOD RSCGRP(Optional) Meaning: TRM load threshold index. The TRM load threshold must be configured (see "ADD TRMLOADTH"). GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: 0
ADD UNILNK(Optional) Meaning: TRM load threshold index MOD UNILNK(Optional) GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: 0 ADD Meaning: Backward bandwidth of the logical port ATMLOGICPORT(Man datory) GUI Value Range: 512~149000 MOD Actual Value Range: 512~149000 ATMLOGICPORT(Optio Unit: kbit/s nal) Default Value: None
TXBW
BSC6900
Issue 03 (2011-09-30)
8-31
8 Parameters
Parameter ID TXTRFX
NE BSC6900
MML
Description
ADD Meaning: TX traffic record index of the AAL2 Path AAL2PATH(Mandatory) on the out RNC port (ATM layer PVC traffic). The MOD traffic index is configured in the ATM traffic table AAL2PATH(Optional) (see "LST ATMTRF"). GUI Value Range: 100~1999 Actual Value Range: 100~1999 Unit: None Default Value: None
TXTRFX
BSC6900
ADD Meaning: TX traffic record index of the SAAL link SAALLNK(Mandatory) MOD GUI Value Range: 100~1999 SAALLNK(Optional) Actual Value Range: 100~1999 Unit: None Default Value: None ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) DlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct
DlLdrFifthAction BSC6900
Issue 03 (2011-09-30)
8-32
8 Parameters
Parameter ID
NE
MML
Description
DlLdrFirstAction BSC6900
ADD Meaning: NOACT: No load reshuffling action is UNODEBLDR(Optional) taken. MOD BERATERED: Channels are reconfigured for the UNODEBLDR(Optional) BE service to reduce rate. QOSRENEGO: The renegotiation on the QoS of the uncontrollable real-time service is performed to reduce service QoS. CSINTERRATSHOULDBELDHO: The inter-RAT SHOULDBE load handover of the CS domain is performed. For details, refer to 3GPP TS 25.331. PSINTERRATSHOULDBELDHO: The inter-RAT SHOULDBE load handover of the PS domain is performed. PSINTERRATSHOULDNOTBELDHO: The inter-RAT SHOULDNOTBE load handover of the PS domain is performed. PSINTERRATSHOULDNOTLDHO: The inter-RAT SHOULDNOTBE load handover of the PS domain is performed. The LDR takes the actions in the preset sequence and judges whether each action is successful. If an action is unsuccessful, the LDR turns to the next action. If an action is successful, a parameter is set to NOACT, or all the preceding actions are taken, the downlink LDR is finished, and the system waits for the next triggering of the LDR. Because each action is performed by its algorithm module, the LDR algorithm only selects users and delivers control messages, the execution result of each action can be obtained after a delay, and the LDR algorithm cannot wait for a long time, so the LDR can only judge whether the actions succeed by whether candidate users are found. The inter-frequency load handover has no impact on the QoS of users and can balance the cell load, so the inter-frequency load handover usually serves as the first action. The BE service rate reduction is effective only when the DCCC algorithm is enabled. GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO,
Issue 03 (2011-09-30)
8-33
8 Parameters
Parameter ID
NE
MML
Description PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: BERateRed
DlLdrFourthActi BSC6900 on
ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) DlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct
Issue 03 (2011-09-30)
8-34
8 Parameters
Parameter ID
NE
MML
Description
DlLdrSecondAct BSC6900 ion
ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) DlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) DlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct
DlLdrSixthAction BSC6900
Issue 03 (2011-09-30)
8-35
8 Parameters
Parameter ID
NE
MML
Description
DlLdrThirdActio BSC6900 n
ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) DlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) UlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct
UlLdrFifthAction BSC6900
Issue 03 (2011-09-30)
8-36
8 Parameters
Parameter ID
NE
MML
Description
UlLdrFirstAction BSC6900
ADD Meaning: NOACT: No load reshuffling action is UNODEBLDR(Optional) taken. MOD BERATERED: Channels are reconfigured for the UNODEBLDR(Optional) BE service to reduce rate. QOSRENEGO: The renegotiation on the QoS of the uncontrollable real-time service is performed to reduce service QoS. CSINTERRATSHOULDBELDHO: The inter-RAT SHOULDBE load handover of the CS domain is performed. For details, refer to 3GPP TS 25.331. PSINTERRATSHOULDBELDHO: The inter-RAT SHOULDBE load handover of the PS domain is performed. PSINTERRATSHOULDNOTBELDHO: The inter-RAT SHOULDNOTBE load handover of the CS domain is performed. PSINTERRATSHOULDNOTLDHO: The inter-RAT SHOULDNOTBE load handover of the PS domain is performed. The LDR takes the actions in the preset sequence and judges whether each action is successful. If an action is unsuccessful, the LDR turns to the next action. If an action is successful, a parameter is set to NOACT, or all the preceding actions are taken, the downlink LDR is finished, and the system waits for the next triggering of the LDR. Because each action is performed by its algorithm module, the LDR algorithm only selects users and delivers control messages, the execution result of each action can be obtained after a delay, and the LDR algorithm cannot wait for a long time, so the LDR can only judge whether the actions succeed by whether candidate users are found. The inter-frequency load handover has no impact on the QoS of users and can balance the cell load, so the inter-frequency load handover usually serves as the first action. The BE service rate reduction is effective only when the DCCC algorithm is enabled. GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO,
Issue 03 (2011-09-30)
8-37
8 Parameters
Parameter ID
NE
MML
Description PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: BERateRed
UlLdrFourthActi BSC6900 on
ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) UlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct
Issue 03 (2011-09-30)
8-38
8 Parameters
Parameter ID
NE
MML
Description
UlLdrSecondAct BSC6900 ion
ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) UlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) UlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct
UlLdrSixthAction BSC6900
Issue 03 (2011-09-30)
8-39
8 Parameters
Parameter ID
NE
MML
Description
UlLdrThirdActio BSC6900 n
ADD Meaning: This parameter has the same content as UNODEBLDR(Optional) UlLdrFirstAction. The selected actions, however, MOD should be unique. UNODEBLDR(Optional) GUI Value Range: NoAct(no action), BERateRed(BE traff rate reduction), QoSRenego(uncontrolled real-time traff Qos re-negotiation), CSInterRatShouldBeLDHO(CS domain inter-rat should be load handover), PSInterRatShouldBeLDHO(PS domain inter-rat should be load handover), CSInterRatShouldNotLDHO(CS domain inter-rat should not be load handover), PSInterRatShouldNotLDHO(PS domain inter-rat should not be load handover) Actual Value Range: NoAct, BERateRed, QoSRenego, CSInterRatShouldBeLDHO, PSInterRatShouldBeLDHO, CSInterRatShouldNotLDHO, PSInterRatShouldNotLDHO Unit: None Default Value: NoAct ADD RSCGRP(Optional) MOD RSCGRP(Optional) Meaning: Rx bandwidth GUI Value Range: 32~300000 Actual Value Range: 32~300000 Unit: kbit/s Default Value: Meaning: Tx bandwidth GUI Value Range: 32~300000 Actual Value Range: 32~300000 Unit: kbit/s Default Value: -
RXBW
NodeB
TXBW
NodeB
ADD RSCGRP(Optional) MOD RSCGRP(Optional)
BEAR
NodeB
SET Meaning: Bearing type HSDPAFLOWCTRLPA RA(Optional) GUI Value Range: ATM, IPV4 Actual Value Range: ATM, IPV4 Unit: None Default Value: ADD RSCGRP(Mandatory) RMV RSCGRP(Mandatory) MOD RSCGRP(Mandatory) Meaning: Indicating the resource group bear type, IP or ATM. GUI Value Range: ATM, IPV4 Actual Value Range: ATM, IPV4 Unit: None Default Value: -
BEAR
NodeB
Issue 03 (2011-09-30)
8-40
8 Parameters
Parameter ID DR
NE NodeB
MML
Description
SET Meaning: Discard rate. The link is not congested HSDPAFLOWCTRLPA when the frame loss ratio is lower than or equal to RA(Optional) this threshold. GUI Value Range: 0~1000 Actual Value Range: 0~1, Step: 0.001 Unit: None Default Value: 50
OMLPRI
NodeB
SET DIFPRI(Optional) Meaning: Refers to OM Low priority. GUI Value Range: 0~62 Actual Value Range: 0~62 Unit: None Default Value: -
OMPRI
NodeB
SET DIFPRI(Optional) Meaning: Refers to OM priority. GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: -
SIGPRI
NodeB
SET DIFPRI(Optional) Meaning: Signaling priority. IPPRECEDENCE: 0 (low), and 7 (high) DSCP: For default PHB, DSCP is 000000. For Class-Selector PHB, DSCP is XXX000, where X is 0 or 1. The service level is consistent with the IP Precedence in the current network. For expedited forwarding PHB, DSCP is 101110. For assured forwarding PHB, four service level (bandwidth and buffer size) and three packet drop priorities are listed below: GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: -
TD
NodeB
SET Meaning: Time delay threshold HSDPAFLOWCTRLPA RA(Optional) GUI Value Range: 0~100 Actual Value Range: 0~500, Step: 5 Unit: ms Default Value: 4
Issue 03 (2011-09-30)
8-41
8 Parameters
Parameter ID SWITCH
NE NodeB
MML
Description
SET Meaning: Flow control switch HSDPAFLOWCTRLPA RA(Optional) GUI Value Range: STATIC_BW_SHAPING, DYNAMIC_BW_SHAPING, NO_BW_SHAPING, BW_SHAPING_ONOFF_TOGGLE Actual Value Range: STATIC_BW_SHAPING, DYNAMIC_BW_SHAPING, NO_BW_SHAPING, BW_SHAPING_ONOFF_TOGGLE Unit: None Default Value: BW_SHAPING_ONOFF_TOGGLE
Table 8-3 Parameter Description for 2G TRM Parameter ID EMLDSCP NE BSC6900 MML Description
SET Meaning: Differentiated service code of the BSCABISPRIMAP(Opti specified EML onal) GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None SET Meaning: Service priority of the specified EML BSCABISPRIMAP(Opti onal) GUI Value Range: 0~7 Actual Value Range: 0~7 Unit: None Default Value: None SET BSCBASIC(Optional) Meaning: When this parameter is set to "ON", if there are no available Abis transmission resources, a high-priority user can preempt the transmission resources of a low-priority user. If the preemption succeeds, a call drop occurs at the low-priority user. GUI Value Range: OFF(Off), ON(On) Actual Value Range: OFF, ON Unit: None Default Value: ON
EMLPRI
BSC6900
ENPREEMPTT BSC6900 RANSADMT
ENQUETRANS BSC6900 ADMT
SET BSCBASIC(Optional)
Meaning: When this parameter is set to "ON", if there are no available Abis transmission resources, the BSC starts the queuing procedure for the services to wait for available transmission resources. GUI Value Range: OFF(Off), ON(On) Actual Value Range: OFF, ON Unit: None Default Value: ON
Issue 03 (2011-09-30)
8-42
8 Parameters
Parameter ID ESLDSCP
NE BSC6900
MML
Description
SET Meaning: Differentiated service code of the BSCABISPRIMAP(Opti specified ESL onal) GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None SET Meaning: Service priority of the ESL BSCABISPRIMAP(Opti onal) GUI Value Range: 0~7 Actual Value Range: 0~7 Unit: None Default Value: None ADD Meaning: Ratio of bandwidth occupied by the CS TRMLOADTH(Optional) service in the GSM GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 80
ESLPRI
BSC6900
GSMCSBWRAT BSC6900 E
GSMCSUSERH BSC6900 IGHPRILEV
SET BSCBASIC(Optional)
Meaning: Standard priority for GSM CS(Circuit Switched) high-priority MSs. 15 is the highest priority. GUI Value Range: 1~15 Actual Value Range: 1~15 Unit: None Default Value: 10
LDRFOUH
BSC6900
SET LDR(Optional)
Meaning: Fourth action taken for load control GUI Value Range: CLOSE(Close), PSDOWN(PS Downspeeding), AMRC(AMRC), CSPH(CS Preference TCHH), CSFHHO(CS TCHF-TCHH HO) Actual Value Range: CLOSE, PSDOWN, AMRC, CSPH, CSFHHO Unit: None Default Value: CSFHHO
LDRFST
BSC6900
SET LDR(Optional)
Meaning: First action taken for load control GUI Value Range: CLOSE(Close), PSDOWN(PS Downspeeding), AMRC(AMRC), CSPH(CS Preference TCHH), CSFHHO(CS TCHF-TCHH HO) Actual Value Range: CLOSE, PSDOWN, AMRC, CSPH, CSFHHO Unit: None Default Value: PSDOWN
Issue 03 (2011-09-30)
8-43
8 Parameters
Parameter ID LDRSND
NE BSC6900
MML SET LDR(Optional)
Description Meaning: Second action taken for load control GUI Value Range: CLOSE(Close), PSDOWN(PS Downspeeding), AMRC(AMRC), CSPH(CS Preference TCHH), CSFHHO(CS TCHF-TCHH HO) Actual Value Range: CLOSE, PSDOWN, AMRC, CSPH, CSFHHO Unit: None Default Value: AMRC
LSRTRD
BSC6900
SET LDR(Optional)
Meaning: Third action taken for load control GUI Value Range: CLOSE(Close), PSDOWN(PS Downspeeding), AMRC(AMRC), CSPH(CS Preference TCHH), CSFHHO(CS TCHF-TCHH HO) Actual Value Range: CLOSE, PSDOWN, AMRC, CSPH, CSFHHO Unit: None Default Value: CSPH
OMLDSCP
BSC6900
SET Meaning: Differentiated service code of the BSCABISPRIMAP(Opti specified OML onal) GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None SET Meaning: The summation of average BTSBWPARA(Mandato down-bandwidth of OML&ESL link in BTS. ry) GUI Value Range: 0~256 Actual Value Range: 0~256 Unit: kbit/s Default Value: 64 SET Meaning: The summation of average BTSBWPARA(Mandato up-bandwidth of OML&ESL link in BTS. ry) GUI Value Range: 0~256 Actual Value Range: 0~256 Unit: kbit/s Default Value: 64 SET Meaning: Average down-bandwidth of RSL link in BTSBWPARA(Mandato BTS. ry) GUI Value Range: 0~64 Actual Value Range: 0~64 Unit: kbit/s Default Value: None
OMLESLDL
BSC6900
OMLESLUL
BSC6900
RSLDL
BSC6900
Issue 03 (2011-09-30)
8-44
8 Parameters
Parameter ID RSLDSCP
NE BSC6900
MML
Description
SET Meaning: Differentiated service code of the BSCABISPRIMAP(Opti specified RSL onal) GUI Value Range: 0~63 Actual Value Range: 0~63 Unit: None Default Value: None SET Meaning: RSL service priority BSCABISPRIMAP(Opti onal) GUI Value Range: 0~7 Actual Value Range: 0~7 Unit: None Default Value: None SET Meaning: Average up-bandwidth of RSL link in BTSBWPARA(Mandato BTS. ry) GUI Value Range: 0~64 Actual Value Range: 0~64 Unit: kbit/s Default Value: None SET Meaning: Whether to enable the BSC to assign OTHSOFTPARA(Optio half rate channels preferentially when the Ater nal) interface is congested GUI Value Range: Close(Close), Open(Open) Actual Value Range: Close, Open Unit: None Default Value: Open
RSLPRI
BSC6900
RSLUL
BSC6900
AterCongHRFla BSC6900 g
AterCongstRatio BSC6900
SET Meaning: Threshold for considering the Ater OTHSOFTPARA(Optio interface, if congested, the BSC determines nal) whether to assign full or half rate channels preferentially according to the congestion situations at the Ater interface. If the Ater resource usage exceeds this parameter, the Ater interface is considered congested. GUI Value Range: 80~100 Actual Value Range: 80~100 Unit: % Default Value: 85
AterJamThresho BSC6900 ld2StartLs
SET BSSLS(Optional) Meaning: Threshold for enabling the BSC local switching. When the congestion rate at the Ater interface exceeds this threshold, the function is enabled. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 90
Issue 03 (2011-09-30)
8-45
8 Parameters
Parameter ID
NE
MML
Description
TDMCONGCLR BSC6900 TH
ADD Meaning: If the ratio of available TDM bandwidth TRMLOADTH(Optional) is greater than this value, congestion control is stopped. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 20
TDMCONGTH BSC6900
ADD Meaning: If the ratio of available TDM bandwidth TRMLOADTH(Optional) is less than or equal to this value, congestion control is triggered. GUI Value Range: 0~100 Actual Value Range: 0~100 Unit: % Default Value: 15
ADD RSCGRP(Optional)
Meaning: TRM load threshold index GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: 2
SET Meaning: TRM load threshold index BSCABISPRIMAP(Man datory) GUI Value Range: 0~199 Actual Value Range: 0~199 Unit: None Default Value: None
The Default Value column is valid only for optional parameters and the "-" symbol indicates that there is no default value.
Issue 03 (2011-09-30)
8-46
9 Counters
9 Counters
There are no specific counters associated with this feature.
Issue 03 (2011-09-30)
9-1
10 Glossary
10 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.
Issue 03 (2011-09-30)
10-1
11 Reference Documents
11 Reference Documents
[1] Load Control Feature Parameter Description of the RAN [2] IP BSS Feature Parameter Description of the GBSS [3] IP RAN Feature Parameter Description of the RAN [4] Common Transmission Feature Parameter Description of the SingleRAN [5] SRNS Relocation and DSCR Feature Parameter Description of the RAN [6] HSDPA Feature Parameter Description of the RAN [7] HSUPA Feature Parameter Description of the RAN [8] Flex Abis Feature Parameter Description of the GBSS [9] Bandwidth Sharing of MBTS Multi-Mode Co-Transmission Feature Parameter Description of the SingleRAN
Issue 03 (2011-09-30)
11-1

Transmission Resource Management

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Transmission Resource Management

Caricato da

Copyright:

Formati disponibili

Transmission Resource Management SRAN5.

Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2011. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

SingleRAN Transmission Resource Management

2 Overview of TRM .......................................................................................................................2-1

3 Transmission Resources ........................................................................................................3-1

4 Quality of Service .....................................................................................................................4-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

5 Load Control ..............................................................................................................................5-1

6 User Plane Processing ............................................................................................................6-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

1.2 Intended Audience

1.3 Change History

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

02 (2011-03-30) 01 (2010-05-15) Draft (2010-03-30)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

2.2 Structure of TRM Functions

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

Figure 2-1 Structure of the TRM functions

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

2.3.2 Load Control

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

In the SRAN3.0 solution:

2.3.3 User Plane Processing and QoS

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

2.3.4 Differences of Co-TRM From 2G TRM and 3G TRM

2.4 Benefits of TRM

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

Figure 3-2 IP transmission resources of the 3G system

Figure 3-3 IP transmission resources of the 2G system

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

Figure 3-4 IP transmission resources of the co-transmission system

3.2 Physical Transmission Resources

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management

3.2.1 Physical Layer Resources for ATM Transmission

IMA UNI Fractional ATM IMA UNI Fractional ATM

Channelized STM-1/OC-3 optical port

Unchannelized STM-1/OC-3c optical port NCOPT

3.2.2 Physical Layer Resources for TDM Transmission

E1/T1 electrical port Channelized STM-1/OC-3 optical port

3.2.4 Physical and Data Link Layer Resources for IP Transmission

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd

SingleRAN Transmission Resource Management