RAN18.1 Capacity Monitoring Guide (BSC6910-Based) (02) (PDF) - EN PDF
RAN18.1 Capacity Monitoring Guide (BSC6910-Based) (02) (PDF) - EN PDF
RAN18.1 Capacity Monitoring Guide (BSC6910-Based) (02) (PDF) - EN PDF
1
Capacity Monitoring Guide
(BSC6910-based)
Issue 02
Date 2016-04-28
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 a warranty of any kind, express or implied.
Email: [email protected]
1.1 Overview
Growing traffic in mobile networks requires more and more network resources. Lack of
network resources will affect user experience. Therefore, monitoring network resources,
locating bottlenecks, and performing capacity expansion in real time are critical to the
provision of high quality services.
This document describes how to monitor the usage of various network resources and locate
network resource bottlenecks.
This document applies to BSC6910s and 3900 series base stations.
For details about the MML commands, parameters, alarms, and performance counters, see section
"Operation and Maintenance" in the BSC6910 UMTS Product Documentation or 3900 Series Base
Station Product Documentation.
02 (2016-04-28)
Compared with Issue 01 (2016-02-29) of RAN18.1, 02 of RAN18.1 includes the following
changes.
01 (2016-02-29)
This issue does not include any changes.
Draft A (2015-12-31)
Compared with Issue 02 (2015-05-8) of RAN17.1, Draft A of RAN18.1 includes the
following changes.
Editorial change
Optimized descriptions on optimization suggestions by using
flow charts.
Optimized descriptions on resource monitoring by using tables.
Added descriptions on monitoring thresholds.
Contents
1 Overview .......................................................................................................................................... 5
1.1 Network Resources ....................................................................................................................................................... 5
1.2 Monitoring Methods ..................................................................................................................................................... 7
1 Overview
RNC interface boards provide transmission ports and resources, process transport
network messages, and exchange data between RNC boards and between the RNC and
external devices. Resource overload on interface boards increases the packet loss rate,
interrupts communications, and affects user experience.
GE Switching network and Control Unit (SCU)
The SCU provides the function of inter-subrack information exchange in the RNC. If the
traffic volume of inter-subrack communication approaches the overload threshold, voice
service quality, data service quality, and network KPIs deteriorate, affecting system
stability.
RNC License
The RNC license (BSC6910) can be controlled based on the following license resource
items:
− PS user-plane traffic volume
− Voice traffic volume (Erlangs)
− HSDPA traffic volume
− HSUPA traffic volume
− RNC hardware capacity
− Cell-level HSDPA/HSUPA user number
HS-PDSCHs are used to carry HSDPA services. Insufficient HS-PDSCH codes will
decrease HSDPA data rates.
HS-SCCH
The HS-SCCH is used to carry control information for HS-PDSCHs. Insufficient
HS-SCCH codes will increase data transmission delay.
Paging Channel (PCH)
PCH usage is affected by the location area and routing area planning. PCH overload
decreases the paging success rate.
Random Access Channel (RACH) and Forward Access Channel (FACH)
RACH and FACH carry signaling and a small amount of user-plane data. RACH or
FACH overload decreases the network access success rate and affects user experience.
Helping ensure stable network operation, capacity monitoring employs the following thresholds:
Warning threshold: If this threshold is reached, the corresponding resource status becomes
"Warning" on the PRS.
Capacity expansion threshold: If this threshold is reached, the corresponding resource status
becomes "Critical" on the PRS. This threshold is lower than the alarm threshold.
This procedure applies to most resource monitoring scenarios, but sometimes the system may
be overloaded because of other abnormalities instead of traffic increases. Some of these
abnormalities can be discovered by resource cross-checking. If more extensive resource
cross-checking is unsuccessful, advanced troubleshooting is required. Chapter 3 "Network
Resource Troubleshooting" addresses advanced troubleshooting procedures.
For the sake of simplicity, it is assumed that there are no other abnormalities on the network
during the proactive monitoring process described in chapter 2 "Network Resource
Monitoring."
GPU boards process services on the RNC user plane and control plane. The CPs and UPs of
all GPU boards in the RNC form a CP pool and a UP pool, respectively. The RNC can adjust
the multi-core digital signal processors (DSPs) allocated to the CPs and UPs based on service
requirements in order to balance the load between the CPs and UPs.
Run the ADD BRD command to set the logical function type of a GPU board. If the
Logical function type parameter is set to UCUP, the GPU board is used for "UMTS
RNC control-plane and user-plane processing". Slots 8 and 9 of subrack 0 in the RNC
permanently hold GPU boards whose logical function type is RMP, which are used only
for resource management. Other slots can hold GPU boards whose logical function type
is UCUP, which are used for UMTS RNC control-plane and user-plane processing.
Run the SET UCPUPFLEXCFG command to dynamically adjust the CP and UP
subsystems. In this command, the FlexCfgMode parameter specifies the mode for
adjusting the CP and UP subsystems, and the CPProportionInTotal parameter specifies
the percentage of CPU usage for the CP in the total CPU usage. You can use these two
parameters to manually configure the ratio of CPs to UPs in order to distinguish CP and
UP subsystems.
If the peak-hour CPU load reaches the capacity expansion threshold within n days (n is
specified based the actual situation; 3 days by default) in a week, prepare for capacity
expansion as instructed in Figure 2-3.
RMP Slots 8 and 9 of subrack 0 in the RNC If the GPU boards are overloaded,
permanently hold GPU boards whose service access will be impacted.
logical function type is RMP, which are
used only for resource management.
The GPU boards in slots 8 and 9 work
in active/standby mode.
If the peak-hour RMP CPU load reaches 50% within n days (n is specified based on the actual
situation; 3 days by default) in a week, a warning is released. If the peak-hour RMP CPU load
exceeds 60% within n days (n is specified based on the actual situation; 3 days by default) in
a week, contact Huawei for technical support.
Interface RNC interface boards provide The packet loss rate increases,
board transmission ports and resources, adversely affecting communications
process transport network messages, and user experience.
and exchange data between RNC
boards and between the RNC and If all interface boards for an
external devices. interface (Iub for example) are
overloaded in Channel Identifiers
These boards also forward and process (CIDs), User Datagram Protocol
data for the Iub, Iu, and Iur interfaces. (UDP), or Tunnel Endpoint ID
(TEIDs), this interface will fail
to work.
NOTE
In effective mode, run the MML command LST BRD to query information about a specific board,
for example, whether the board is an interface board.
In ineffective mode, find the MML command ADD BRD in the RNC configuration file. If the value
of the BRDCLASS parameter is INT, the board is an interface board. You can obtain information
about this interface board using this command.
When the RNC detects that the CPU load on interface boards exceeds a specified overload
threshold, ALM-20256 CPU Overload is reported.
If the peak-hour usage of any item reaches the capacity expansion threshold within n days (n
is specified based the actual situation; 3 days by default) in a week, prepare for capacity
expansion as instructed in Figure 2-6.
NOTE
For details about the Transmission Resource Pool in RNC feature, see Transmission Resource Pool in
RNC Feature Parameter Description in the RAN Feature Documentation.
Table 2-9 Counters pertaining to license utilization in single-operator scenarios and multi-operator
scenarios
Item Counter (Single-Operator Counter (Multi-Operator
Scenario) Scenario)
The license related to the hardware capacity is listed in the following table.
The license related to the BSC6910 ENIUa traffic is described in the following table.
B
RNC Active User Hardware Capacity (per LQW1HWCL04 1000 Active Users
S
1000 Active Users)
C
The licenses related to the cell-level HSDPA/HSUPA user number capacity are listed in the
following table.
If the peak- hour utilization rate reaches the capacity expansion threshold for n days (n is
specified based on the actual situation; 3 days by default), license purchase is required.
PCH PCHs are downlink channels used to Paging messages may be lost.
transmit paging messages.
FACH FACHs are downlink transmission FACH insufficiency will cause a large
channels used to transmit signaling number of state transitions for PS
data and a small amount of user data. services, occurrence of RRC signaling
storms, and loss of signaling messages
or user data.
RACH RACHs are uplink transmission RACH insufficiency will decrease the
channels used to transmit signaling network access success rate and
data and a small amount of user data. deteriorate user experience.
PCH Usage
PCH usage = VS.UTRAN.AttPaging1/(<SP> x 60 x 5/0.01)
where
<SP> indicates the measurement period expressed in minutes.
60 indicates 60 seconds in a minute.
5 indicates the typical configuration (that is, five users in each TTI) of the PCH.
0.01 indicates the length (that is, 0.01s) of a PCH TTI.
FACH Usage
If a secondary common control physical channel (SCCPCH) carries both a FACH and a PCH,
the FACH usage is calculated using the following formula:
Usage of an FACH carried on a non-standalone SCCPCH = VS.CRNCIubBytesFACH.Tx x
8/[(60 x <SP> x 168 x 1/0.01) x VS.PCH.Bandwidth.UsageRate x 6/7 + (60 x <SP> x 360 x
1/0.01) x (1 - VS.PCH.Bandwidth.UsageRate x 6/7)]
where
VS.PCH.Bandwidth.UsageRate =
<VS.CRNCIubBytesPCH.Tx>/(<VS.CRNC.IUB.PCH.Bandwidth> x <SP> x 60)
8 indicates 8 bits in a byte.
60 indicates 60 seconds in a minute.
<SP> indicates the measurement period in minutes.
1 indicates one packet transmitted per TTI.
0.01 indicates the length (that is, 0.01s) of a PCH TTI.
6/7 indicates the payload ratio in a PCH frame.
168 indicates the size of a TB on the signaling plane of a FACH.
360 indicates the size of a TB on the user plane of a FACH.
Associated counters are as follows:
VS.CRNCIubBytesFACH.Tx
VS.CRNCIubBytesPCH.Tx
VS.CRNC.IUB.PCH.Bandwidth
If an SCCPCH only carries a FACH, the FACH usage is calculated using the following
formula:
FACH Usage = ((VS.SRBNum.FACH - VS.OneSRBTTINum.FACH)/2 +
VS.OneSRBTTINum.FACH + VS.IndepTRBNum.FACH)/(<SP> x 60/0.01)
where
2 indicates scenarios where two SRB TBs are transmitted within one TTI.
<SP> indicates the measurement period in minutes.
60 indicates 60 seconds in a minute.
0.01 indicates the length (that is, 0.01s) of a PCH TTI.
Associated counters are as follows:
VS.SRBNum.FACH
VS.OneSRBTTINum.FACH
VS.OneSRBTTINum.FACH
VS.IndepTRBNum.FACH
RACH Usage
Each cell has only one RACH. When signaling and user data coexist on the RACH, the
RACH usage is calculated using the following formula:
RACH Usage = ((VS.CRNCIubBytesRACH.Rx - VS.TRBNum.RACH x 360/8) x
8/168)/(<SP> x 60 x 4/0.02) + VS.TRBNum.RACH/(<SP> x 60 x 4/0.02)
where
360 indicates the size of a TB on the user plane of a FACH.
8 indicates 8 bits in a byte.
168 indicates the size of a TB on the signaling plane of a FACH.
<SP> indicates the measurement period in minutes.
60 indicates 60 seconds in a minute.
4 indicates that each TTI on the RACH can accommodate four UEs.
0.02 indicates the TTI of 0.02s (or 20 ms).
Associated counters are as follows:
VS.CRNCIubBytesRACH.Rx
VS.TRBNum.RACH
VS.TRBNum.RACH
Downlink Detailed in the following part. When the downlink transmit power is
resources insufficient, the following occurs:
The cell coverage shrinks.
The data throughput decreases.
The service quality declines.
New service requests are likely to be
rejected.
The downlink capacity of a cell is limited by its total available transmit power, which is
determined by the NodeB power amplifier's capability and the power configured for the cell.
The downlink transmit power consists of the following, as shown in Figure 2-9:
Common channel (CCH) power
Power for DPCH
HSPA power
Power margin
The mean utility ratio of the transmitted carrier power for non-HSPA users in a cell
(including non-HSPA users on CCHs) is calculated using the following formula:
MeanTCP (NonHS) Usage = MeanNonHSTCP/MAXTXPOWER x 100%
The mean utility ratio of the transmitted carrier power for all users in a cell is calculated
using the following formula:
MeanTCP Usage = MeanTCP/MAXTXPOWER x 100%
where
To obtain MAXTXPOWER, run the LST UCELL command to query the value of the
Max Transmit Power of Cell parameter, and convert the parameter value from the unit
"0.1 dBm" to "W".
Associated counters are as follows:
VS.MeanTCP
VS.MeanTCP.NonHS
VS.HSDPA.MeanChThroughput
If the peak-hour usage of a measurement item reaches the capacity expansion threshold within
n days (n is specified based the actual situation; 3 days by default) in a week, prepare for
capacity expansion as instructed in Figure 2-11.
Uplink RTWP reflects the interference to a If the RTWP value is too large, the cell
resources NodeB and indicates the signal coverage shrinks, the quality of
strength on the RX port of the RF admitted services declines, or new
module. service requests are rejected.
The relationship between the RoT and the uplink load factor
UL is as follows:
1
RoT 10 log( )
1 UL
For example, a 3 dB noise increase corresponds to 50% of the uplink load and a 6 dB noise
increase corresponds to 75% of the uplink load.
Figure 2-12 Relationship between RTWP, noise increase, and uplink load
A large RTWP value in a cell is caused by traffic overflow, hardware faults (for example, poor
quality of antennas or feeder connectors), or external interference.
If the value of the VS.MeanRTWP counter is greater than –90 dBm during peak hours
for n days (n is specified based on the actual situation; 3 days by default) in a week, there
may be hardware faults or external interference. Locate and rectify the faults and attempt
to eliminate the interference. If the value of the VS.MeanRTWP counter is still greater
than –90 dBm after hardware faults are rectified and external interference is eliminated,
enable the following features as required:
− WRFD-140215 Dynamic Configuration of HSDPA CQI Feedback Period
− WRFD-010712 Adaptive Configuration of Traffic Channel Power offset for HSUPA
If the uplink capacity of the cell still does not meet the requirements after the preceding
features are enabled, add carriers. If there are no additional UARFCNs available, add
NodeBs.
NOTE
For details about how to enable the WRFD-140215 Dynamic Configuration of HSDPA CQI
Feedback Period feature, see Dynamic Configuration Based on the Uplink Load Feature
Parameter Description in the RAN Feature Documentation.
For details about how to enable the WRFD-010712 Adaptive Configuration of Traffic Channel
Power offset for HSUPA feature, see Power Control Feature Parameter Description in the RAN
Feature Documentation.
If the number of uplink ENUs is insufficient and the amount of uplink power is sufficient,
run the MOD UCELLCAC command with the UL total equivalent user number
parameter set to a larger value. In addition, run the SET UADMCTRL command with
the AF of hsupa interactive service and AF of hsupa background service parameters
set to 10.
In a WCDMA system, channels are identified by codes. Two types of codes are used for each
channel. One is the scrambling code and the other is the Orthogonal Variable Spreading
Factor (OVSF) code.
In the uplink, each UE is allocated a unique scrambling code. In the downlink, each cell is
allocated a unique scrambling code; all UEs in a cell use the same scrambling code but each
of them is allocated a unique OVSF code. Therefore, OVSF codes distinguish the downlink
physical channels of different UEs in a cell.
In a WCDMA cell, different user data is distinguished by the CDMA technique, and all user
data is transmitted over the same central frequency almost at the same time. OVSF codes
provide perfect orthogonality, minimizing interference between different users.
Figure 2-13 shows an OVSF code tree.
The system reserves code resources for HSDPA services, and these code resources can be
shared among HSDPA services. Therefore, HSDPA services do not require admission control
based on cell code resources.
Figure 2-16 shows NodeB-controlled dynamic code allocation.
If the peak-hour usage reaches the capacity expansion threshold within n days (n is specified
based the actual situation; 3 days by default) in a week, prepare for capacity expansion as
instructed in Figure 2-18.
NOTE
For details about how to enable the WRFD-010631 Dynamic Code Allocation Based on NodeB feature
and the WRFD-010653 96 HSDPA Users per Cell feature, see HSDPA Feature Parameter Description in
the RAN Feature Documentation.
HS-PDSCH HS-PDSCHs are used to carry HSDPA service rates will be affected.
codes HSDPA services.
HS-SCCH HS-SCCH codes are used to carry Insufficient HS-SCCH codes will
codes HS-PDSCH-related control increase data transmission delay and
information. reduce the maximum number of UEs
The number of HS-SCCH codes that are performing delay-sensitive
determines the number of HSDPA services in a cell.
users that can be scheduled in each
transmission time interval (TTI).
Iub The Iub interface lies between the Iub bandwidth congestion will cause
bandwidth NodeB and the RNC. This interface RRC connection setup and RAB setup
uses ATM or IP transmission. failures. Table 2-19 describes Iub
In IP transmission, the BSC6910 bandwidth congestion scenarios.
supports only transmission resource
pool mode and does not support
resource groups.
ATM and IP transmission resources can be classified into physical resources, logical port (LP)
resources, resource groups, and link resources, as shown in Figure 2-19 and Figure 2-20.
Scenario Description
The physical transmission Admission control is performed based on the
resources are sufficient, but sufficiency of transmission resources. If
the admission fails. transmission resources are insufficient, the
admission fails. Admission control prevents
excessive service admission and ensures the
quality of admitted services.
The physical transmission The physical transmission bandwidth between the
bandwidth is insufficient. RNC and NodeB is insufficient.
IP Transmission
On an IP transmission network, the RNC and NodeB can monitor the average uplink and
downlink loads on their interface boards. The Iub/Iu/Iur bandwidth usage is represented by
the ratio of the average uplink or downlink load to the configured Iub/Iu/Iur bandwidth. For
the Iub interface, the NodeB can also monitor the uplink and downlink load on their interface
boards. In addition, the RNC and NodeB can dynamically adjust the bandwidth of a service
based on the QoS requirements of the service and user priority and improve the Iub bandwidth
usage using the reserve pressure algorithm on their interface boards.
1. Admission success rate (or IP connection setup success rate)
The IP connection setup success rate is calculated using the following formula:
IP connection setup success rate =
VS.ANI.IP.Conn.Estab.Succ/VS.ANI.IP.Conn.Estab.Att
Associated counters are as follows:
− VS.ANI.IP.Conn.Estab.Succ
− VS.ANI.IP.Conn.Estab.Att
− VS.ANI.IP.FailResAllocForBwLimit
2. Bandwidth usage
(1) Control plane
The uplink and downlink traffic volumes of the SCTP links (for NCP, CCP, and ALCAP)
on the control plane over the Iub interface are calculated using the following formulas,
respectively:
− SCTP UL KBPS = VS.SCTP.RX.BYTES x 8/<SP>/1000
− SCTP DL KBPS = VS.SCTP.TX.BYTES x 8/<SP>/1000
where
− 8 indicates 8 bits in a byte.
− <SP> indicates the measurement period in minutes.
− 1000 indicates 1 kbit/s.
Associated counters are as follows:
− VS.SCTP.TX.BYTES
− VS.SCTP.RX.BYTES
(2) User plane
The uplink and downlink Iub bandwidth usages on a transmission resource pool are
calculated using the following formulas, respectively:
− UL Iub/Iu/Iur Usage on User Plane = VS.IPPOOL.ANI.IPLAYER.RXBYTES x
8/<SP>/1000/RX BW_CFG
− DL Iub/Iu/Iur Usage on User Plane = VS.IPPOOL.ANI.IPLAYER.TXBYTES x
8/<SP>/1000/TX BW_CFG
where
− 8 indicates 8 bits in a byte.
− 1000 indicates 1 kbit/s.
− <SP> indicates the measurement period in minutes.
− TX BW_CFG indicates the configured transmit bandwidth.
Associated counters are as follows:
− VS.IPPOOL.ANI.IPLAYER.TXBYTES
− VS.IPPOOL.ANI.IPLAYER.RXBYTES
If ALM-21542 SCTP Link Congestion is reported on the Iub interface, bandwidth congestion has
occurred on the control plane.
If ALM-21532 SAAL Link Congestion is reported on the Iu interface, bandwidth congestion has
occurred on the control plane.
If the value of the VS.ANI.IP.FailResAllocForBwLimit counter is not zero, bandwidth congestion
has occurred on the user plane.
If the peak-hour Iub/Iu/Iur bandwidth usage exceeds 70% or the admission success rate is
lower than 99% within n days (n is specified based the actual situation; 3 days by default) in
a week, prepare for capacity expansion as instructed in Figure 2-22.
The following part uses the Iub interface as an example to introduce how to implement
capacity expansion.
Scenario 4: Admission Bandwidth Congestion on the ATM and IP User Planes, Not
Accompanied by Physical Bandwidth Congestion
Step 2 Decrease the activity factor for PS services to enable the system to admit more UEs. Query
the activity factor used by the adjacent node by checking the configuration data of the
following command:
ADD ADJMAP: ANI=10, ITFT=IUB, TRANST=IP, CNMNGMODE=SHARE,
FTI=OldIndex;
Step 3 Run the ADD TRMFACTOR command to add an activity factor table. The recommended
value for PSINTERDL, PSINTERUL, PSBKGDL, PSBKGUL, HDINTERDL, and
HDBKGDL is 10. The following is an example:
ADD TRMFACTOR:FTI=NewIndex, REMARK="IUB_USER", PSINTERDL=10,
PSINTERUL=10, PSBKGDL=10, PSBKGUL=10, HDINTERDL=10, HDBKGDL=10;
Step 4 Run the MOD ADJMAP command to use the new activity factor on the adjacent node. The
following is an example:
MOD ADJMAP: ANI=XXX, ITFT=IUB, FTI=NewIndex;
NOTE
The activity factor equals the ratio of actual bandwidth occupied by a UE to the bandwidth allocated to
the UE during its initial access. It is used to predict the bandwidth required by admission. Each NodeB
can be configured with its own activity factor. The default activity factor for voice services is 70%, and
the default activity factor for PS BE services is 40%.
----End
2.14 CE Usage
2.14.1 Monitoring Principles
Table 2-20 CE resource monitoring
Uplink CE resources can be shared in an uplink resource group, but not between uplink
resource groups. Downlink CE resources are associated with the baseband processing
boards where a cell is set up. CE resources allocated by licenses are shared among services on
the NodeB. (CE resources are shared on a per operator basis in MOCN scenarios.)
The NodeB sends the RNC a response message that carries its CE capability. The NodeB's CE
capability is limited by both the installed hardware and the configured software licenses.
The methods of calculating the credit resource usage of admitted UEs are different before and
after the CE Overbooking feature is enabled. Table 2-21 describes the details.
Table 2-21 Credit resources consumed by admitted UEs before and after CE Overbooking is
enabled
After CE Overbooking is The NodeB calculates the usage of credit resources for all
enabled admitted UEs at the cell and NodeB levels and periodically
reports the calculation results to the RNC through
measurement reports (MRs).
R99 UE: The NodeB calculates the usage of credit resources
for an R99 UE based on the MBR.
HSUPA UE using a 10 ms transmission time interval (TTI):
The NodeB adjusts the credit resource usage of such a UE
based on the UE's rate. After the adjustment, the credit
resources consumed by such a UE must not exceed the credit
resources required by Rateone RLC PDU.
HSUPA UE using a 2 ms TTI: The NodeB adjusts the credit
resource usage of such a UE based on the UE's rate and the
minimum number of CEs (specified by
CERSVFOR2MSUSER) reserved for admitting such a UE.
After the adjustment, the credit resources consumed by such
a UE must not exceed the credit resources required by
Rateone RLC PDU.
NOTE
The minimum number of CEs reserved for admitting an HSUPA UE
using a 2 ms TTI is 4 by default. The value range is 1 to 8.
NOTE
For details about CE Overbooking, see CE Overbooking Feature Parameter Description.
CCHs do not require extra CE resources because the RNC reserves CE resources for services
on these channels. Signaling carried on an associated channel of the DCH does not consume
extra CE resources, either. One CE can be consumed by a 12.2 kbit/s voice call.
For details about CE number consumed by different services, see CE Resource Management
Feature Parameter Description.
The value of UL NodeB Mean CE Used Number equals that used for calculating the
license-based uplink CE usage.
UL CE Capacity Number = VS.HW.ULCreditAvailable
The CE resource usage can be monitored by alarms. If the CE hardware capacity is exceeded,
ALM-28230 Base Station Service Overload is reported.
CNBAP CNBAP load is used to assess a CNBAP overload will cause radio link
NodeB's processing capability. setup failures, thereby decreasing the
RRC connection setup and RAB setup
success rates.
If the peak-hour CNBAP usage reaches the capacity expansion threshold within n days (n is
specified based the actual situation; 3 days by default) in a week, prepare for capacity
expansion as instructed in Figure 2-24.
NOTE
The features mentioned in Figure 2-24 refer to WRFD-010202 UE State in Connected Mode
(CELL_DCH, CELL_PCH, URA_PCH, CELL_FACH) and WRFD-020500 Enhanced
Fast Dormancy.
For details about how to enable the WRFD-010202 UE State in Connected Mode (CELL_DCH,
CELL_PCH, URA_PCH, CELL_FACH) feature, see State Transition Feature
Parameter Description in the RAN Feature Documentation.
For details about how to enable the WRFD-020500 Enhanced Fast Dormancy feature, see Enhanced
Fast Dormancy Feature Parameter Description in the RAN Feature Documentation.
The maximum CNBAP capability of a NodeB is 1500. When the CNBAP capability configured for a
NodeB is less than 1500, replace boards to expand the capacity if CNBAP overload occurs. For the
CNBAP capabilities of the WBBP boards, see 3900 Series Base Station Technical Description.
HSPA HSPA services are carried on the If BBP boards are overloaded with
users BBP boards in a NodeB. Therefore, HSPA users, new users may fail to
the number of HSPA users access the network.
determines BBP board loads.
NOTE
For details about how to enable the WRFD-150242 HSDPA Scheduler Pool feature, see HSDPA
Scheduler Pool Feature Parameter Description in the RAN feature documentation. For details about
how to enable the WRFD-170205 HSUPA Scheduler Pool feature, see HSUPA Scheduler Pool
Feature Parameter Description in the RAN feature documentation.
The number of HSPA users supported by a WBBP board varies according to board type. For detailed
numbers of HSPA users supported by different WBBP boards, see 3900 Series Base Station
Technical Description.
3.1 Possible Block and Failure Points in the Basic Call Flow
When network resources are insufficient, accessibility-related KPIs are likely to be affected
first.
Figure 3-1 uses a mobile terminated call (MTC) as an example to illustrate the basic call
flow, with possible block/failure points indicated. For details about the basic call process, see
3GPP TS 25.931.
Figure 3-1 Basic call flow chart and possible block/failure points
Step 5 If the RNC is congested when receiving the RRC connection setup request, the RNC may
drop the request message. See block point #3.
Step 6 If the RNC receives the RRC connection setup request and does not discard it, the RNC
determines whether to accept or reject the request. The request may be rejected due to
insufficient resources, as shown in block point #4.
Step 7 If the RNC accepts the request, the RNC instructs the UE to set up an RRC connection. The
UE may not receive RNC's response message or may find that the configuration does not
support RRC connection setup. See failure points #5 and #6.
Step 8 After the RRC connection is set up, the UE sends NAS messages to negotiate with the CN
about service setup. If the CN determines to set up a service, the CN sends an RAB
assignment request to the RNC.
Step 9 The RNC accepts or rejects the RAB assignment request based on the resource usage of RAN.
See block point #7.
Step 10 If the RNC accepts the RAB assignment request, it initiates an RB setup process. During the
process, the RNC sets up radio links (RLs) to the NodeB over the Iub interface and sends an
RB setup message to the UE over the Uu interface. The RL or RB setup process may incur
failures. See failure points #8 and #9.
----End
In most cases, the troubleshooting procedure includes detecting abnormal KPIs, selecting top
N cells, and analyzing abnormal KPIs.
In the case of system bottlenecks, accessibility-related KPIs are usually checked first because
most of the access congestion issues are caused by insufficient system resources.
Figure 3-3 shows key points for bottleneck analysis. The following sections then describe
these key points.
As shown in Figure 3-4, if the CP CPU load exceeds 50%, analyze the cause of the problem
and prevent the CPU load from increasing further. In addition, perform an in-depth analysis of
the high CPU load, for example, check whether the parameter configurations are appropriate.
If the high CPU load is caused by an increase in traffic volume, it is recommended that you
expand hardware capacity.
CP/UP flexible deployment can adjust the hardware resources in the CP and UP pools so that
these pools have basically the same average load. Because the non-pooled load in the CP
cannot be shared, dynamic cell allocation is required to balance this load in the CP pool.
If the traffic model changes, the load can be balanced between CP and UP pools to a certain
degree but cannot be completely balanced. For example, if the CP CPU load is lower than the
UP CPU load but the remaining CP resources are insufficient to bear new NodeBs and cells, it
is recommended that you reduce the number of cells in the RNC or add new boards.
If the UP CPU load exceeds 60%, analyze the cause of the problem and prevent the CPU load
from increasing further. If the high CPU load is caused by an increase in traffic volume, it is
recommended that you expand hardware capacity.
CE resources can be shared within a resource group. Therefore, CE usage on the NodeB must
be calculated to determine whether CE congestion occurs in a resource group or the NodeB. If
CE congestion occurs in a resource group, reallocate CE resources among resource groups. If
CE congestion occurs in the NodeB, perform capacity expansion.
Generally, adding a carrier is the most effective means of relieving uplink power congestion.
If no additional carrier is available, add a NodeB or reduce the downtilt of the antenna.
4 Metrics Definitions
5 Reference Documents
This chapter lists the documents referenced within the text and provides the document name,
document package, and document package download path at http://support.huawei.com.