Académique Documents
Professionnel Documents
Culture Documents
Date 2019-04-15
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 expressed 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.
Email: support@huawei.com
Revision History
Issue Date Author Change Description
01 2019-04-15 Wang Zhizhong This is the first issue
00468588
Contents
4 Summary ....................................................................................................................................4-16
5 Suggestions .................................................................................................................................5-1
6 FAQ ...............................................................................................................................................6-1
6.1 Evaluation of Requested Bandwidth. ............................................................................................................ 6-1
6.2 Why was there no PING loss when the issue occurred? ............................................................................... 6-1
6.3 Why are the OMCH of other GBTS sites normal? ........................................................................................ 6-2
1 Basic Information
2 Problem Description
The site KOES_GU is a GU co-MPT satellite site, its UMTS cells suffer from call drop issue
and its OMCH has been intermitting frequently. Customer requests to analyze the reason and
provide a solution.
3 Problem Analysis
According to the RNC performance, the PING loss rate of different IP paths exceeded 5%
after activating UMTS cells on 15th April.
The reason of cell unavailability was UMTS Cell Common Channel Setup Failed, it was
related to IUB transmission discards which triggered Path Fault alarm too.
The call drop rate degraded when the transmission discards increased.
From PCHR log, the TOP 3 drop reasons were as below, the most of the reasons were cell
unavailability (CCH delete).
From trace, the top 2nd typical failure process IUB_TRANSMISSION_FAILURE was as
below, it was because of the path fault in figure 9.
Summary:
The top 3 reasons of UMTS call drops were related to the transmission discards due to
congestion, and the packet loss rate at IUB was much more than the requested transmission
quality at satellite scenario.
By taking statistic of the number of NE is Disconnected alarm at U2000 in hourly, it’s found
that the OMCH intermittent occurred more during busy hours as the above traffics graph.
The site’s throughput can be limited by SET LR command. The following operation log
showed there were several times of adjustment at the site.
Summary:
As above analysis, the lower TX throughput from the site, the less NE disconnection alarm.
The reason of the OMCH intermittent was the bandwidth insufficiency at the transmission
link which caused congestions at busy hours.
From 18:00, the packet which send from NodeB to RNC will be lost by transmission device
about 2.47%. The result is mapping to the ping check result. It was much more than RNC’s
IUB specification.
Consider the delay of IUB interface (average 700ms, MAX 1780ms, such high packet loss
rate will increase a lot re-trans packet, it will occupy extra bandwidth of satellite.
From NodeB performance logs, the NodeB KOES U900’s MAX uplink bandwidth was about
700kbps before activating the UMTS cells. After activating UMTS cells, the average uplink
bandwidth reach 1.1Mbps, and the MAX uplink bandwidth reach 4Mbps.
And check the RNC’s RX perk rate, the MAX uplink bandwidth reach 2Mbps. Consider that
from 18:00, the packet loss rate became high, the uplink re-transmission will also occupy
Summary:
After activating the UMTS cells, the uplink bandwidth increase a lot than before, the packet
loss rate increase along with the UMTS traffic increase. From the counter, it is suggest to
expand the KOES U900’s uplink bandwidth on satellite to 2Mbps at least.
And there were no any PS RAB Setup Fail because of admit bandwidth congestion. So it
meant the operation limiting the PS R99 services admittance bandwidth to 248Kbps did not
take effect because the PS active users were not enough.
Figure 24 PS RAB setup fail due to admittance bandwidth congestion after limiting the Uplink bandwidth
But GSM side also limited PS traffic to 100Kbps, and disable the HSUPA on 3G part, the total
uplink traffic of the site decrease from about 1.6Mbps to 1Mbps.
The R99 PS user’s total uplink traffic was about 500Kbps. Because the admittance bandwidth
limit did not affect the real traffic.
The packet loss rate on IPPATH which DSCP = 46 and used to carry voice and common
channel’s signaling decrease from 7% to 0 at busy hour.
From the callfault logs, all the call drop was caused by cell update message which caused by
RL fail (cause =5) overlap with RB_SETUP message. RL fail was caused by UE lose the UL
sync with NodeB. It only have 1 reason-- bad radio quality.
But the PS RAB success rate decrease. Because the bandwidth was limited, the RNC reject
part of PS RAB attempts.
Summary:
After limited the PS uplink bandwidth, the CS and PS call drop rate decrease, PS RAB setup
success rate decrease. And the HSDPA traffic kept the same as before. The OMCH channel
between U2000 and NodeB became much more stable than before.
It was suggested to enable the call re-establishment feature on the cell when the radio signal
was too bad. The feature will re-establish the radio connection to avoid the call drop.
ADD UCELLRLREESTSWITCH: CellId=54591,
OptimizationSwitch=CS_RL_SETUP_SWITCH-1&CS_SMC_RL_REEST_SWITCH-
1&CS_RB_SETUP_RL_REEST_SWITCH-1&CS_RB_RECFG_RL_REEST_SWITCH-
1&CS_NON_DCCC_RBRECFG_RL_REEST_SWITCH-
1&CS_PHY_RECFG_REEST_SWITCH-1&CS_ASU_RL_RESET_SWITCH-
1&CS_MC_RL_RESET_SWITCH-1&CS_IRATHO_HOCANCEL_RL_REEST_SWITCH-
1&SRB_OVER_HSPA_OPT_BASED_RLREEST_SWITCH-
0&CS_FP_FAILURE_RL_REEST_SWITCH-1&PS_FP_FAILURE_RL_REEST_SWITCH-
1;
Modify script:
4 Summary
5 Suggestions
6 FAQ
The average downlink bandwidth is more than 4Mbps, and the uplink bandwidth is more than
900Kbps.
6.2 Why was there no PING loss when the issue occurred?
The PING packets between U2000 and BTS, RNC and BTS are all based on ICMP protocol.
While the OMCH is based on TCP protocol and the IUB traffics are based on UDP protocol,
the priority of ICMP, TCP and UDP protocol packets may be different at the transmission
link, so there loss of different packets may be different too.
Protocol stack for an OMCH between co-MPT multimode base station and the U2000
Protocol stack for an OMCH between the GBTS and the BSC