Professional Documents
Culture Documents
11
Contents
Typical cases
Summary
22
Modules of Nastar:
Performance analysis
Coverage analysis
Interference analysis
Adjacent cell analysis
Configuration analysis
Access analysis
33
The above functions are often used during analysis and their specific applications are described in the typical cases that will
follow. Below is a brief introduction to the operations for various functions. Please refer to the online help or relevant
operation guide of Nastar for details.
Note: The TOP N Query in the above figure is also a traffic statistics analysis function of Nastar . It can automatically
complete some sorting & analysis work, but it can only analyze cell measurement indices rather than RNC and SPU
measurement indices. This limitation makes it inconvenient to use and so we do not describe this function for the time being.
You may refer to the online help of Nastar if you are interested in it.
44
55
What follows are the specific operation steps of making and querying analysis themes (here
we take Cell TOPN monitoring as an example)
Note: A table composed of relevant traffic measurement indices is called an analysis theme.
66
Step 1: Right click Performance Query and then select New Perf
Func, as shown in the right figure.
77
Step 3: Input the name of the analysis theme in the Name text box
and then click Query List Setting, as shown in the right figure.
Step 4: Select the indices involved in the analysis theme from the
left index tree in the Query List Setting dialog box and then click
>, as shown in the right figure.
88
Step 5: The Query List box shows the selected indices. Click OK,
99
Step 8: Select the begin date and end date of the data to be
analyzed as well as the time granularity on the Time Range tab
page, as shown in the right figure.
10
10
10
Step 10: Click the ALL icon to display all the query
results. Select a certain cell in the first line and then
click the ZA icon to sort the output data
according to the selected cell (or you can sort the
output data by other cells you select). Finally, click the
X icon to convert the outputs into Microsoft Office
Excel for display, as shown in the right figure. Till now,
11
1111
12
12
12
Step 2: In the dialog box that pops up, select the path to save the report,
the analyzed object and the start date and end date of the data to be
analyzed, as shown in the right figure. Finally, click OK. The program
will immediately generate a report and the operation thus ends.
13
13
13
14
14
14
Step 2: In the dialog box that pops up, select the start date and
time of the data to be analyzed, end date and time, abnormal
case, UE ID, procedure (by default all are selected) and the
analyzed object, and then click OK, as shown in the right
figure.
15
15
15
16
16
16
Contents
Typical cases
Summary
17
17
17
Network-wide
KPI monitoring
Cell analysis
Parameter configuration analysis
Clearly
located?
Yes
No
CHR
analysis
Clearly
located?
Yes
Solution
18
18
18
No
causes by cause analysis in the traffic statistics; analyze if the specific network conduct is abnormal or not, for
example, analyze if such network conducts as the proportion of RRC setup request types, RAB setup
distribution, RB distribution and DCCC rise/fall are abnormal or not.
19
19
19
Parameter configuration analysis: Analyze if the relevant parameter configuration is abnormal or not.
CHR analysis: Further analyze the causes unknown in cell analysis, e.g. Other causes; or analyze if the
specific procedure is abnormal or not when the specific failure cause is known through cell analysis but the
correlation analysis results indicate that the cause may be wrong (possible due to statistical error or other
problems).
Problem location test and signaling trace analysis: Perform the location test on the severest cell(s), trace the
signaling of various interfaces and all the other data that may help problem analysis & location, and then
comprehensively analyze the collected data till the problem is solved. This process is called troubleshooting.
Solution: Put forward the solution.
20
20
20
Network-wide
KPI monitoring
Cell TOPN
monitoring
Cell analysis
CHR analysis
Note: The red lines indicate the major analysis functions.
21
21
21
Contents
Typical cases
Summary
22
22
22
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
As can be seen from the above table, the number of non-service RRC setup requests is 33 times
(112391/3389=33) that of service RRC setup requests. This ratio may be abnormal.
23
23
23
Cell analysis
According to the types of RRC setup requests for all cells, the number of RRC connection setup requests for
registration in some cells accounts for over 99% of the total RRC connection setup requests, as shown in the
following table:
Note: You can get the above table via custom report or Performance Query of Nastar.
Through the above cell analysis, we are sure that the ratio of non-service RRC setup requests to service RRC
setup requests is abnormal.
24
24
24
25
25
25
setup requests will arise and consume plenty of power, code, transport and other resources and may cause congestion.
26
26
26
Solution
Modify the cause value of CN denial from #17 (network failure) to #15 (no suitable cells in LA). After the
modification, the ratio of non-service RRC setup requests to service RRC setup requests in the entire network
becomes 3467/15912 = 4.59, which is normal (the normal ratio should be less than 10 according to the data
statistics of various commercial offices), as shown in the following table:
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
27
27
27
89.17%(10700/12000)
91.05%(118396/130038)
Access
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
28
28
28
Cell analysis
As can be seen from the right
table, the major cause of RRC
connection setup failure is that
plenty of RRC connection
requests are denied when Cells
0, 1 and 2 are busy and the RRC
connection denial rate is up to
62%. In most cases, the denial
cause is due to AAL2 setup
failure. According to routine
29
29
29
The two pairs of E1 in IMA bearer mode can provide 1860 * 2 = 3720 kpbs ATM transport capability. Excluding the common
bandwidth occupied by NCP, CCP, ALCAP and IPOA, they should be able to provide 3720 - 302 = 3418 kbps bandwidth for
traffic channels. Moreover, there are two AAL2 paths and the sharing mode should be configured between AAL2 paths, that is,
the bandwidth of each AAL2 path should be set to the maximum transport capability of traffic channels.
Therefore, the bandwidth of HSDPA and that of R99 AAL2 paths should be both set to 3418 kbps. Obviously, the bandwidth of
R99 AAL2 paths is set to 891 kbps (too small). Even without considering soft handover, 891 kbps cannot satisfy the access
needs of two 384 kbps services (R99 services), so transport congestion may occur.
30
30
30
Solution
Configure the AAL2 path bandwidth of HSDPA and that of R99 to 3418 kbps. After the modification, the service
RRC connection setup success rate and the non-service RRC connection setup success rate both reach the
normal KPI requirement and the problem is thus solved, as shown in the following table:
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
31
31
31
Note: You can get the above table via RNC Weekly Report of Nastar.
Moreover, users say that the paging response time is rather long.
32
32
32
Moreover, we know from the CN side that the CS paging resend count is set to 3, the interval between the first
paging and the second paging is 3 seconds, and the resend interval of the third paging is 4 seconds.
33
33
33
(discontinuous reception) cycle is 2^8 = 2.56s. Each paging message from the CN will be sent twice in the
RNC and the paging interval is 2^8 = 2.56s. In other words, at least 22^8 = 5.12s is needed before each
paging resent by the RNC can be responded by the UE. Generally, the paging resend count and resend
interval of the CN must be considered along with the resend of the UTRAN. If the UTRAN resends the paging
once, then the resend interval of the CN should be more than two DRX cycles. Obviously, the resend interval of
the CN (3s) is less than two DRX cycles (5.12s) and so the CN starts to resend the next paging message
before the UTRAN finishes sending and resending the preceding paging message. Therefore, no paging
response is obtained and this problem is shown as paging failure in the traffic statistics of the RNC.
For the UE in the idle mode, the DRX cycle is 2^8 = 2.56s and the UEs paging response time is more than
2.56s, so the paging response time is longer than we actually feel.
34
34
34
Solution
Modify the paging cycle coefficient of the CN domain DrxCycleLenCoef from 8 to 6 (baseline). After the
modification, the DRX cycle is reduced from 2.56s to 0.64s and the paging success rate of the entire network is
larger than 85%, as shown in the following figure. The problem is thus solved.
Note: You can get the above table via RNC Weekly Report of Nastar.
35
35
35
Note: You can get the above table via RNC Weekly Report of Nastar.
36
36
36
Site investigation
Because the paging success rate kept being rather low for a number of days, we preliminarily determined that
there was little possibility of weak coverage. We checked the CN and found that the 2G&3G combined paging
policy was set in the MSC, that is, any paging message destined to 2G or 3G would be initiated to all the LACs
in the 2G and 3G networks so as to guarantee paging response.
37
37
37
The 2G/3G combined paging policy may be used in some scenarios to improve the paging response
probability to some extent, but it may also bring the following troubles:
1.
2.
3.
In sum, the 2G&3G combined paging policy has little gain but may easily bring other severe performance
problems. It is seldom used.
38
38
38
Solution
Change the CN paging policy to the normal policy, that is, paging by LAC. After the modification, the paging
success rate of the entire network is higher than 85% and the problem is solved, as shown in the following
figure:
Note: You can get the above table via RNC Weekly Report of Nastar.
39
39
39
40
40
40
Whats more, the load of some cells empty-loaded is very little, e.g. 3%, which is also abnormal. We may conclude through
calculation that such cells cannot be accessed due to pilot Ec/Io deterioration when the load of these cells is about 30%, so the
maximum load of such cells will be about 30%. Again because for the admission algorithm (Algorithm 1), load control algorithm and
other algorithms it is necessary to compare the current load with the corresponding threshold value (e.g. 75%) so as to decide
whether to start the corresponding algorithm, possibly the current load cannot be more than the corresponding threshold value and
the algorithms may fail.
We further check the script configuration and find that the following problems exist for the power ratio configuration of the cells with
abnormal load:
1.
The pilot power configuration is from 27 dBm to 37.8 dBm whereas the maximum transmit power of the cells is
mostly set to 44.8 dBm.
2.
The power ratio configuration of common channels such as PSCH, SSCH, PCH and FACH is far larger than the
baseline configuration.
41
41
41
will result in capacity loss as mentioned above, whereas too low pilot power will cause the algorithms to fail and may bring other problems
such as mute. If we need to reduce the pilot power in special cases, we should also lower the configured maximum transmit power of that
cell, so that the pilot power is 10 dB less than the maximum transmit power of the cell. For instance, suppose we set the pilot power to 27
dBm, then we should configure the maximum transmit power of the cell to 37 dBm.
In some guidance documents about RF optimization, we are often told to modify pilot channel power as an optimization means. We do not
recommend this. Because the modification of pilot power in a large scope will result in numerous problems such as uplink-downlink
unbalance, service coverage void in the soft handover area and severe adjacent cell interference in the uplink. Therefore, we should start
with antenna parameters to solve RF problems such as weak coverage and pilot pollution. We should not adjust the pilot power unless in
special cases.
When the power ratio configuration of common channels such as PSCH, SSCH, PCH and FACH is far larger than the baseline
configuration, the load of cells empty-loaded may be too high. The baseline configuration of power ratio for common channels has been
verified in Beta tests and commercial offices. We should not modify the baseline configuration as a routine RF optimization means.
Moreover, we should use the smaller power ratio to attain a better balance between common channel coverage and traffic channel coverage
during the optimization, so that the common channel power ratio after the optimization is not far larger than the baseline configuration.
42
42
42
Solution
Take the following measures:
1.
Optimize the configurations of the pilot power and cell maximum transmit power, so that the pilot power
is 10 dB or more less than the cell maximum transmit power, for example, Pcpich = 27 dBm, TCP = 37
dBm, Pcpich = 34.8 dBm and TCP = 44.8 dBm.
2.
Restore the power ratio configuration of common channels (PSCH, SSCH, PCH, FACH, etc. )t to the
Note: You can get the above table by combining Performance Query of Nastar and Excel.
43
43
43
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, the cells with a high average RTWP have normal services (they are not
out of service) and very little traffic, so very probably external interference may cause the RTWP to raise.
44
44
44
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, the cause of RRC setup failure is that the UE does not reply and for the
cells whose failure rate is high with many failures, the average RTWP is above 95 dBm (rather high).
Moreover, there is very little traffic in these cells. Therefore, very probably the abnormal raise of RTWP may
cause plenty of RRC setup failures.
45
45
45
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, the cause of CS RAB setup failure is air interface failure (mostly RB no
response) and for the cells whose failure rate is not high but with many failures, the average RTWP is above
92 dBm (very high). Moreover, there is very little traffic in these cells. Therefore, very probably the abnormal
raise of RTWP may cause CS RAB setup failure.
46
46
46
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, the cause of CS call drop is RF failure (mostly uplink synchronization
failure and UU interface no response). For the cells whose failure rate is high with many failures, the average
RTWP is above 92 dBm (very high). Moreover, there is very little traffic in these cells. Therefore, very
probably the abnormal raise of RTWP may cause CS call drop.
47
47
47
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, the cause of PS call drop is RF failure (mostly uplink synchronization
failure and UU interface no response). For the cells whose failure rate is high with many failures, the average
RTWP is above 95 dBm (rather high). Moreover, there is very little traffic in these cells. Therefore, very
probably the abnormal raise of RTWP may cause PS call drop.
48
48
48
For this reason, we carefully surveyed the radio environment at the site and searched for interference.
Through tests and problem location, we found that the strong interference came from the radio equipment
of the army. With our efforts, the customer requested the local radio commission to remove the existing
interference source or lower the power of the radio equipment. These external interference was gradually
reduced. The latest statistics show that the number of cells with abnormal raise of RTWP will decrease
with the weakening of abnormal raise of the average RTWP.
49
49
49
Solution
Continue to push the customer and the local radio commission to shut off the interference source or reduce the
transmit power of the interference source so that the interference is within the acceptable range.
50
50
50
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, power congestion mainly occurs in the PS RAB setup phase and
accounts for over 50% of all congestions. The congestion rate during PS RAB setup is as high as 16.55%.
Obviously, power congestion is quite severe.
51
51
51
Therefore, the power threshold for access denial of PS services is 10lg (20000*75%) = 41.76 dBm. We can
see from the above table that the transmit power of the cells with power congestion is above 41.92 dBm,
which is more than the admission threshold 41.76 dBm. Thus we know that the power congestion is normal.
Moreover, the maximum number of CEs in the downlink reaches 97 when congestion occurs, indicating that
there is indeed big traffic and power resource congestion is a fact.
52
52
52
Solution
Solve power resource congestion by the following means:
1.
2.
3.
4.
Cell splitting
5.
Introduce HSDPA
6.
Other means
53
53
53
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, code congestion mainly occurs in the PS RAB setup phase and accounts
for 100% of all congestions. The congestion rate during PS RAB setup is as high as 7.78%. Obviously, code
54
54
54
code congestion occurs. Therefore, code congestion may easily occur. Moreover, the maximum number of CEs
in the downlink reaches 105 when the congestion occurs, indicating that there is indeed big traffic and code
resource congestion is a fact.
55
55
55
Solution
The same as power resource congestion, we may solve code resource congestion by the following means:
1.
2.
3.
4.
Cell splitting
5.
Introduce HSDPA
6.
Other means
56
56
56
Note: You can get the above table via custom report or Performance Query of Nastar.
As can be seen from the above table, IUB transport congestion mainly occurs in the PS RAB setup phase and
accounts for over 90% of all congestions. The congestion rate during PS RAB setup is as high as 31.33%.
57
57
57
The Node B to which the cell belongs has a pair of E1s and the bearer type is UNI
There is one AAL2 path for R99 services and the bandwidth is 1812 kbps
As can be seen from the above configuration, the IUB bandwidth configuration of the Node B is OK for the
physical bandwidth of one E1. However, we can see from the right green part in the above table that the
average downlink throughput is as high as 104.85 kbps when IUB transport congestion occurs to the cell and
so the cell traffic is rather high. Moreover, the Node B has two cells and the traffic of the two cells together will
be even higher. Therefore, one E1 cannot satisfy the actual bearer requirements and thus IUB transport
congestion may easily occur.
58
58
58
Solution
Solve transport resource congestion by the following means:
1.
2.
3.
4.
Other means
59
59
59
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
60
60
60
Cell analysis
RRC connection setup failure mostly occurs to such cells as 30843, 30863, 30252 and 30382. It is nearly 100%
for these cells and the major failure cause is that the UE does not reply, as shown in the following table:
Note: You can get the above table via custom report or Performance Query of Nastar.
61
61
61
62
62
62
Open the RRC CONNCET REQ message, as shown in the following figure:
As can be seen from the above figure, the downlink Ec/No is about (44-49)/2 = -2.5 dB when the RRC
connection setup request is initiated. Therefore, the downlink signal quality is OK and there should be no
downlink weak coverage or downlink interference problem.
63
63
63
Try deactivating the cells and then activating them. The cells can be connected, as shown in the following figure:
The R&D confirmed that the problem was due to software version (V16 041) defect of Node B of BTS3812E
type and could be solved by upgrading the software version to V16 061.
64
64
64
Solution
Upgrade the software version of the Node B of BTS3812E type to V16 061. After the software version upgrade,
the RRC connection setup success rate in the network reaches the normal KPI requirements and thus the
65
65
65
66
66
66
Comparing the above with the baseline configurations and the corresponding settings of various
commercial offices, we can see that the values of the above call admission thresholds are too small.
67
67
67
Solution
Change the downlink thresholds of conversational AMR voice service, conversational non-AMR voice service
and other services respectively to 80%, 80% and 75% (the baseline values of RNC1.5). Then the power
congestion problem disappears.
68
68
68
Note: You can get the table on the right via custom report or Performance Query of Nastar.
69
69
69
Note: You can get the above table via Performance Query of Nastar.
70
70
70
Further analysis reveals that the actual average RB traffic of PS high-speed service is not high:
Note: You can get the above table via custom report or Performance Query of Nastar.
71
71
71
Note: You can get the above table via custom report or Performance Query of Nastar.
72
72
72
We recommend that the DCCC switch be on (the DCCC-related parameters may temporarily use the default
ones or they can be optimized as needed so as to ensure that the users will not obviously feel the change).
When the DCCC switch is on, the code resources that do not need to be occupied will be released and the
corresponding power resources will also be released. In this way, code congestion and power congestion can
be alleviated to a certain extent.
73
73
73
Note: You can get the above table via Performance Query of Nastar.
74
74
74
Note: You can get the above table via Performance Query of Nastar.
75
75
75
2560 (2560 ms), which will make it hard to trigger the 1B event.
When the 1B event cannot be timely triggered, some links cannot be timely released and as a result some
code resources that do not need to be occupied will be occupied, thus easily causing code congestion.
Moreover, transport congestion and power congestion are likely to occur, too.
Lets have a look at Hong Kongs settings:The relative threshold of RNC-level 1B is set to 14 (7dB) but the
trigger time is set to 640 (640 ms). The ratio of 1A events to 1B events is within 2 and so the set values are
reasonable.
76
76
76
Solution
Take the following measures:
1.
2.
Modify 1B parameters with reference to Hong Kongs relevant parameter configuration: the
relative threshold of RNC-level 1B is 14 (7 dB) and the trigger time is 640 (640 ms).
77
77
77
78
78
78
The RNC soft handover 1D hysteresis is set to 10 (5 dB) and the 1D trigger time is set to 1280
(1280 ms), which will make it hard to trigger the 1D event. So the list of best cells cannot be timely
updated,
causing the UE unable to obtain the appropriate adjacency and ultimately resulting in no
handover at all or delayed handover, which will further cause call drop (e.g. RLC reset, uplink outof-sync, UU interface no response , etc.). The below soft handover failure due to UE no response is
a case of call drop due to UU interface no response:
Note: You can get the above table via custom report or Performance Query of Nastar.
79
79
79
Lets have a look at the settings in Hong Kong and Brunei: 1D hysteresis is set to 8 (4 dB) and the
1D trigger time is set to 640 (640 ms), so the 1D event is more easily to trigger, which can be
verified by the ratio of 1D events to 1A events. In Hong Kong and Brunei, 1D events are about half
of 1A events,
but in this case the ratio is 1/8. So we recommend that the settings be changed to
the same as in Hong Kong and Brunei so that soft handover becomes more smooth and the call
drop rate can be improved.
2.
In inter-system handover, RSCP is used as the measurement (RNC level) and the compressed
mode enable threshold INTERRATPSTHD2DRSCP is set to -115 dBm. This threshold value is
too low, as a result the compressed mode may not be enabled before the call drop or call drop
may occur very easily in the inter-system handover after the compressed mode is enabled. These
call drop causes are also shown as RLC reset, uplink out-of-sync and UU interface no response.
Therefore, we recommend that the value of INTERRATPSTHD2DRSCP be changed to -105 dBm
or larger.
80
80
80
Solution
Take the following measures:
1.
Modify 1D parameters with reference to relevant parameter configuration in Hong Kong and
Brunei: 1D hysteresis is set to 8 (4 dB) and the 1D trigger time is set to 640 (640 ms).
2.
After the above are done, both the CS call drop rate and the PS call drop rate are improved, as shown in
the following table:
Note: You can get the table on the right via custom report or Performance Query of Nastar.
81
81
81
custom report or
Performance Query of
Nastar.
82
82
82
CDL analysis
Because the call drop cause is Other, we should first check the relevant CDL log.
Below is the log of Cell 1403 on May 3:
======No. 57======
Interface: RNCAP_NBM_NBAP_INTERFACE
Msg: NBAP_RL_RECFG_READY
======No. 58======
Interface: RNCAP_INTRA_INTERFACE
Msg: RNCAP_RL_SYNC_RECFG_RSLT
RL
reconfiguration is
complete
======No. 59======
FSM ID:RNCAP_RB_FSM_ID
CSS:RB SETUP
CS:RNCAP_CSS_RB_WAIT_UE_RB_SETUP_FAIL
======No. 60======
Alarm in RNCAP_AlcfgAlSetupConnType1Rsp:Received Iub AAL2 type1 setup responce message
from AL but result is 85 not success!
======No. 61======
Interface: RNCAP_INTRA_INTERFACE
Msg: RNCAP_MAIN_RUNTIME_ABNORMAL_MSG
83
83
83
AL configuration failed
RB setup begins
======No. 64======
Interface: RNCAP_RNCAP_RRC_INTERFACE
Msg: RRC_RB_SETUP_CMP
======No. 65======
Interface: RNCAP_INTRA_INTERFACE
Msg: RNCAP_RB_SETUP_SUCC
RB setup is
complete
======No. 72======
Interface: RNCAP_INTRA_INTERFACE
Msg: RNCAP_RAB_SETUP_RSLT
======No. 73======
RAB Setup Procedure Succeed.
======No. 74======
FSM ID:RNCAP_IDLE_FSM_ID
CSS:IDLE
CS:RNCAP_CSS_IDLE
84
84
84
======No. 75======
ENTER RNCAP_MainBackupRabSetupD2D . usCcbIndex = 127
======No. 76======
Err in RNCAP_CcbCheckAbnormalFlags: User Plane Fail!RAB Fail Cn Domain id = 1, Rab Id = 5
======No. 77======
Err In RNCAP_CcbCheckAbnormalFlags: User Plane Fail! Table Type is : 9, Table Index is 2252
======No. 78======
Err In RNCAP_CcbCheckAbnormalFlags: User Plane Fail! Cause is 184945367
======No. 79======
Enter in RNCAP_RabRelReq for PS: Cause = 184945367, enRabRelReqType = 4.
According to the above CDL procedure analysis: a) the RNC returns the RAB setup success message to the CN after completing
RL reconfiguration and RB setup (this is merely the setup success in the NBAP signaling plane); b) the limited transport bandwidth
caused the user plane setup failure during the NBAP user plane setup, so the RNC then initiates the RAB release procedure. The
Other cause in the above traffic statistics means the abnormal release here.
85
85
85
The R&D has confirmed that this is a known bug of the current RNC version (R005C03B065) and it can be
avoided by installing the SP05 patch.
86
86
86
Solution
After the SP05 patch is installed for the RNC, almost all the call drops with the cause being Other have
disappeared and the PS call drop rate is obviously lower, as shown in the following table. The problem is thus
solved.
Note: You can get the table on the right via custom report or Performance Query of Nastar.
87
87
87
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
88
88
88
Cell analysis
The cell analysis results show that the PS RAB setup failure mostly occurs to such cells as 8881, 8882
and 25282 and the major failure cause is power congestion, as shown in the following table:
Note: You can get the above table via custom report or Performance Query of Nastar.
89
89
89
90
90
90
Solution
Open the HSDPA measurement switch, as shown in the following figure to solve the problem.
Note: The NCP bandwidth should be above 100 kbps if we want to open the HSDPA measurement switch.
After the switch is on, the PS RAB setup success rate of the entire network reaches the normal KPI
requirements and the problem is solved, as shown in the following table:
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
91
91
91
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
92
92
92
Cell analysis
The cell analysis results show that the cells with severe call drop are 24181, 3783, 19083, etc. and the major
causes of call drop are RLC reset, uplink synchronization failure, UU interface no response or other RF
problems, as shown in the following table:
Note: You can get the above table via custom report or Performance Query of Nastar.
93
93
93
checking and analyzing the MML script show that the 2G cell support capability needed for inter-system
handover of PS services in the network is EDGE (ADD TYPRABBASIC REQ2GCAP= EDGE whereas it is
GPRS (ADD GSMCELL RATCELLTYPE=GPRS) in GSM cell attribute configuration. Because the capability
required by the services is higher than the support capability of GSM cells, PS services will not start the
compressed mode for inter-system handover. Therefore, PS service call drop may easily occur at the edge of
the network with the call drop cause being RF problems.
94
94
94
Solution
Change REQ2GCAP=EDGE in the PS service attributes to REQ2GCAP=GPRS. The PS service call drop
rate is improved to a certain extent, as shown in the following table:
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
95
95
95
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
96
96
96
Cell analysis
The cell analysis results show that the PS inter-system handover failure mostly occurs to such cells as 45552,
5552, 25652 and 45151 and the major failure cause is Other, as shown in the following table:
IRATHO.FailOut IRATHO.FailOut VS.IRATHO.Fail
VS.IRATHO.FailO VS.IRATHO.AttO
PSUTRAN.Cfg PSUTRAN.Phy OutPSUTRAN.
utPSUTRAN.Cell
utPSUTRAN
Unsupp
ChFail
Other
44
44
0
0
44
RNCId
Cell Id
Cell Name
Date
72
45552
CELL:45552
2006-4-17
72
5552
CELL:5552
2006-4-17
38
38
37
72
5553
CELL:5553
2006-4-17
32
32
31
72
16033
CELL:16033
2006-4-17
29
29
29
72
2333
CELL:2333
2006-4-17
22
22
21
72
5243
CELL:5243
2006-4-17
22
22
21
72
23543
CELL:23543
2006-4-17
21
21
20
72
44552
CELL:44552
2006-4-17
19
19
19
72
26741
CELL:26741
2006-4-17
16
16
16
72
23541
CELL:23541
2006-4-17
13
13
13
RNCId
Cell Id
Cell Name
Date
74
25652
CELL:25652
2006-4-17
74
45151
CELL:45151
2006-4-17
24
24
24
74
20451
CELL:20451
2006-4-17
18
18
18
74
18492
CELL:18492
2006-4-17
12
12
10
74
22352
CELL:22352
2006-4-17
12
12
12
74
11892
CELL:11892
2006-4-17
11
11
74
25292
CELL:25292
2006-4-17
10
10
10
74
25393
CELL:25393
2006-4-17
10
10
74
25291
CELL:25291
2006-4-17
74
45152
CELL:45152
2006-4-17
Note: You can get the above table via Performance Query of Nastar.
97
97
97
statistics). At present, our CN will send the SRNC CONTEXT REQUEST message, so we failed to discover this
problem during the test of V15 office. (On the earlier days, the RNC would directly judge the cause value of IU REL
CMD but later we discovered in Uruguay Beta Test that the CN (not our CN) would always send the release command
even if the 2G system did not support inter-system handover and the RNC would count the handover as being
successful as long as the release cause value was Normal Release , so we changed the rule to the present way so
as to avoid incorrect measurement: the RNC will not count the handover as being successful unless it receives the
SRNC CONTEXT REQUEST message).
It is not stipulated in the protocols that the CN should send the SRNC CONTEXT REQUEST message during PS intersystem handover. Instead, the CN does not need to send this message if it is not necessary to restore the PDP
context.
Therefore, the PS inter-system handover success rate being 0 is due to the incorrect traffic measurement method of
RNC.
98
98
98
Solution
Change the measurement method of PS inter-system handover success as follows: During the PS inter-system
handover, if the RNC receives the IU RELEASE COMMAND message after sending the CELL CHANGE
ORDER FROM UTRAN message and if the cause value in the IU RELEASE COMMAND message is
Successful Relocation or Normal Release or an other normal cause value, then it indicates that the PS
inter-system handover procedure succeeded and the success should be counted. Merge this change into the
RNC V17 version.
There still exists this problem: When the CN sends the IU RELEASE COMMAND message that carries the
normal cause value in the case of inter-system handover failure, the RNC will also count the handover as being
successful. This problem cannot be avoided and at present our RNC cannot solve it.
99
99
99
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
100
100
100
Note: You can get the above table via custom report or Performance Query of Nastar.
101
101
101
102
102
102
Solution
Close the BE service state transition switch. The PS service call drop rate is greatly lowered, as shown in the
following table:
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
103
103
103
Note: You can get the above table via custom report or Performance Query of Nastar.
104
104
104
Till now, we were sure that the problem was caused by 2G MSC.
105
105
105
Solution
Because the 2G network was provided by our competitor E, we asked the customer to push E to handle the
problem. After then, the CS inter-system handover failure rate obviously decreased and the problem was thus
solved, as shown in the following table:
Note: You can get the above table via custom report or Performance Query of Nastar.
106
106
106
Case 20 High VP Service Call Drop Rate due to Too High Logic
Channel Priority
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
107
107
107
Case 20 High VP Service Call Drop Rate due to Too High Logic
Channel Priority (Continued)
Cell analysis
The cell analysis results show that VP call drops are randomly distributed in space and time and the call drop is
due to RF problems. The cells are in normal service and the RTWP is also normal when the call drop occurs,
as shown in the following table:
Note: You can get the above table via custom report or Performance Query of Nastar.
108
108
108
Case 20 High VP Service Call Drop Rate due to Too High Logic
Channel Priority (Continued)
Through troubleshooting, we found that BSC6800V100R003 and BSC6800V100R005 had slight difference in the specific
implementation: In RNC V1.3, the priority allocation of logical channels is implemented in the codes and cannot be modified via
any command, whats more, signaling priority is higher than service priority; in RNC V1.5 and later versions, flexibility is added
and the priority allocation is configurable via the background with such factors as service type differentiation fully considered,
meanwhile default configurations are provided for priority parameters.
We found through the verification test on the simulation platform that the service priority in the default configurations of RNC
V1.5 was too high and the logical channel priority of some services was even higher than signaling priority, which caused cell
coverage edges. When the transmit power of the UE is close to the maximum value, the UE will enter the uplink TFC selective
sending state and then the uplink signaling cannot be sent, thus causing call drop. The relationship between logical channel
priority and transport channels is not clarified in the protocols. According to the test results, it is this parameter that helped the
VP call drop rate of various commercial offices to decrease.
109
109
109
Case 20 High VP Service Call Drop Rate due to Too High Logic
Channel Priority (Continued)
Solution
Change the default value of logical channel priority of VP service RB in BSC6800V100R005 from 1 to 4 (SET
LOCHPRIO: CSCONVLOCHPRIO=4 ), so that the service priority is not larger than the signaling priority. The
VP call drop rate obviously decreases and the problem is thus solved, as shown in the following table:
Note: You can get the above table via RNC Daily Report/RNC Weekly Report or custom report of Nastar.
110
110
110
Contents
Typical cases
Summary
111
111
111
Experience Summary
The Help file of RNC traffic measurement provides the structure diagram of traffic measurement indices (index tree) as
well as a description of the index meanings and measuring time. We should understand all the indices covered in this
Help file. Of all the indices, the indexes of cell measurement and RNC overall performance measurement are
especially important. We must completely master them.
The raw traffic measurement indices in Nastar
come from the RNC product and the index
trees of the two are the same, as shown in the
right figure (the left is the index tree of RNC
and the right is that of Nastar). Therefore, you
will be familiar with the traffic measurement
index structure of Nastar and find it easy to
112
112
112
113
113
113
analysis theme function of Nastar is a powerful weapon to expand your thoughts and bring into play your wisdom and potentials. It
enables your experience to be conveniently shared to others.
Below are some common analysis themes based on a summary of past experience. There are already report templates accordingly for
your reference, which provide the basic information needed for routine monitoring and analysis of performance problems and help you
efficiently complete performance monitoring & analysis.
A link to
report
template. It is
for your
reference only.
Example of Analysis
Theme Report Template of
Nastar
114
114
114
115
115
115
116
116
116
117
117
117
Experience 3: Get familiar with auxiliary problem analysis & location methods
As we have mentioned before, Nastar supports network-wide KPI monitoring, cell TOPN monitoring, cell
analysis and CHR analysis. However, we can only discover problems and preliminarily troubleshoot them by
merely these monitoring and analysis methods. Still plenty of other means, e.g. IOS, CDR, alarm and other
problem location tests and data collection & analysis means, are needed to solve some hard-to-crack problems.
Moreover, we may improve the problem analysis efficiency through use of more auxiliary analysis tools, for
instance, OMStar can clearly display the network topology and transport layer configuration, and can quickly
complete the comparative check of radio layer parameters; Microsoft office excel has many functions and the
macro function that can greatly help improve the analysis efficiency.
We should be familiar with these auxiliary analysis means. For details, please refer to the relevant guidance
book or online help document.
118
118
118
There are quite many documents for guiding parameter configuration. You can consult them if necessary.
119
119
119
PS policies of the whole network) before analyzing the specific problem in the global point of view.
Always viewing problems from the system perspective will help you avoid detours during problem analysis and help
you efficiently solve problems.
120
120
120
121
121
121
122
122
122