Zain RNC30 SPU CPU Overload Alarms

Analysis Report
Namedengzhuang 00176097/Huawei

Date2011-02-18

1 Description
CPU of SPUs in RNC30 overload alarms show up frequently.

2 Version
WCDMA RNC V2.11.0.1.0040C

3 Conclusion
Cause: Essentially the mean value of CPU load is high, and High traffic lead to CPU
overload alarms. Its mostly two kind of traffic UU_ORIG_BACKGROUND_CALL and

1 , 6

UU_TRMNT_STREAM_CALL. Please confirm it.

Solutions: Expansion[ADD SPUa Boards].

4 Analysis
4.1

CPU overload alarm mechanism

1. Alarm
If CPU load > Load Alarm Threshold [70%]
&&
Standing time > 3s
2. Clear Alarm
If CPU load < Load Alarm Clear Threshold [60%]
&&
Standing time > 10s

4.2

Alarm 2010-02-16 18:11:09

Randomly choose a alarm to analyse, like 18:11:09.

We can see Alarm is from 2011-02-16 18:11:09 to 2011-02-16 18:11:20. According to alarm
mechanism, it really should be from 2011-02-16 18:11:06[18:11:09-3s] to 2011-02-16
18:11:10[18:11:20-10s] when CPU load is higher than Load Alarm Threshold about 4s.
According to CHR datas of Subrack NO.0, we can get the graph below. It shows that RRC
connection times increase sharply at 18:11:06 at 3s early before alarmtime 18:11:09. Its cause of
CPU overload alarm. But what cause increasing of RRC connection times?

2 , 6

According to CHR datas of Subrack NO.0 again, we get three 10s statistics[before
alarm/include alarm/after alarm]. See graph below, we can know the main cause of increasing of
RRC

connection

times

are

UU_ORIG_BACKGROUND_CALL

and

UU_TRMNT_STREAM_CALL.

4.3

Alarm 2010-02-16 18:54:54

Randomly choose another alarm to analyse, like 18:54:54.

3 , 6

We can see Alarm is from 2011-02-16 18:54:54 to 2011-02-16 18:55:08. According to alarm
mechanism, it really should be from 2011-02-16 18:54:51[18:54:54-3s] to 2011-02-16
18:54:58[18:55:08-10s] when CPU load is higher than Load Alarm Threshold about 7s.
According to CHR datas of Subrack NO.0, we can get the graph below. It shows that RRC
connection times increase sharply at 18:54:51 at 3s early before alarmtime 18:54:54. Its cause of
CPU overload alarm. But what cause increasing of RRC connection times?

According to CHR datas of Subrack NO.0 again, we get three 10s statistics[before
alarm/include alarm/after alarm]. See graph below, we can know the main cause of increasing of
RRC

connection

times

are

UU_ORIG_BACKGROUND_CALL

and

UU_TRMNT_STREAM_CALL.

4 , 6

I already checked other alarms, the result is same. Lets check CPU state.

4.4

Check CPU state

We can see that the mean value of CPU load is pretty high. In case traffic comes sharply and
quickly, its very easy to lead to overload.
Whether or not transfer cause, lets check transfer alarm.

5 , 6

4.5

Check transfer alarm

We can see this alarm times is few, and the alarm time doesnt match with CPU overload
alarm time. So this can be excluded.

6 , 6