系统容量研究的主要思路

steven_wang

系统容量研究的主要思路

系统容量研究的模块分为三大类：
1.
业务（Bear Load）趋势发展预测；
利用一种数学趋势分析的方法：比如线性拟合；外推法等确定近期一段时间内可能达到的业务承载量（远期预测的精准度是非常困难的）；该部分的研究工作主要是为了给出一个大致的趋势，并大致确定在距离当前的一个时间点上，可能到达的业务量是否突破了警戒门限；
工作内容：
l
确定对哪些业务进行监测；
PS/CS话务量空口（Iu口）、寻呼量（Iu口）、和业务相关的话务量在各个口流量情况（或者用空口近似各个接口）；

WANG RUI: Iu DL traffic the 16pOC3/STM1 PQC has a maximum capacity of 310 Mbps

(at applicative level)

In term of number of internal dimensioning figures, the maximum numbers of contexts

are the following for a 9370 RNC with 12 PSFP:

CS RRC Contexts: 6048,

PS RRC Contexts: 8640,

DCH RRC Contexts: 9600,

FACH RRC Contexts: 7020,

Cell_PCH
RRC Contexts: 7020

URA_PCH + Cell_PCH
RRC Contexts: 32040

For configurations with lower number of PSFP or DCPS boards, the number of

contexts available can be got from the above values proportionally to the number of active PMC-TMUs

It has to be noticed that these border limits are maximum values, but most of the time

(with an operational usage of the RNC) some other bottlenecks will prevent reaching

these limits as explain in the following chapter (nevertheless, the screening 6 of the

counter #631 VS.RadioBearerEstablishmentUnsuccess allows to detect if some

Radio Bearer Establishment are rejected due to lack of internal RNC contexts).
l
这些业务的统计counter如何获得；

l
使用哪些计算方法进行预测；
l
目前各个现场这些业务的趋势如何；

2.
系统（Offered load）承载能力设定；
这个部分和系统本身或者空口极限的承载能力相关，需要识别出系统瓶颈所在，并针对这个瓶颈设定为系统的整体offerd load，这个为告警门限。这个能力是系统的极端能力，突破了这个能力，意味着故障的产生（丢弃信令，或者其他不良的表现会出来）；
       主要工作内容：
l
针对每项业务对应的系统承载能力的定义；
??????????????????????????????????????

for instance for a 9370 RNC with 12 PSFP, 3900 Erlang can not be

got with 176 Mbps on Iu interface
l
针对系统承载能力，定义为空中接口Iur的限制；Iub口和Iu口的限制，并对应到相关的NODEB,RNC,核心网；LAC；RAC；
l
这些承载能力如何计算得到，阀值是多少；这个部分需要和产品/研发一同讨论，了解各个接口的情况

This engineering margin corresponds to a CPU load of 70% in average for

the most loaded type of RNC module involved in traffic processing. Note that from

UA06, the engineering limit considered for the RAB is now 80% (the limit for the other

PMC remains at 70%).

This does not mean that above this CPU load value the RNC will enter in overload, but

it corresponds to a margin taken to ensure the RNC will be able to handle some

variations of traffic while keeping a good Quality Of Service (QOS) for the end users.

To have a view on the capacity margin of an operational RNC, a monitoring of the

different RNC boards loads involved in traffic processing should be done. From

UA05.0 a counter allows to monitor the different PMC loads: this counter is the

counter:

#20202 VS.ApCpuUtilizationAvg

Thus from a real time activity perspective, we may have unfortunately some most

loaded NodeB collocated on the same TMU during the Busy Hour. Thus the CPU load

between the different PMC-TMU could be not perfectly balanced.

From UA06.0 it is possible to modify this distribution: NodeB are indeed set into

Service Groups. There are as many Service Groups possible as the number of active

TMU. The RNC distributes the different Service Groups on the different active TMU.

Associated to this global recommendation, it is

recommended to correlate the CPU load observed on the most loaded PMC type, with

the counters:

#0404 NT_Rrc_Connection_Reject (screening 6),

#0810 NT_Unhandled_paging_request_CS (screening 4).

#0811 NT_Unhandled_paging_request_PS (screening 4).

These counters indicate the number of RRC connection requests and paging requests

rejected due to overload conditions. Some acceptable levels of ratio of RRC

connection requests and paging request rejected should be targeted (according to

customer objective in term of QOS). If these targets are not respected, actions should

be taken to decrease the load on the RNC boards (see some proposals in next

chapter).

From UA05 some other counters should also be observed to have a view on other

rejections performed:

#1521: NT_Ovin_CnAccLa_Discard (screening 0, 1 and 2)

Number of Downlink or uplink messages discarded at “CN Access

La” on PMC-RAB.

#1522: NT_Ovin_Ni_Discard

Number of Core Network messages received in PMC-NI

(screening 0 and 1) with amount of discarded messages (screening 2 and 3)

#1523: NT_Ovin_Rab_Rrc_Conn_Req_Discard

Total RRC connection messages dropped due to panic overload
l
突破offerd load的阀值之后，系统会有什么样的反映，也需要一并列出；

3.
系统警戒门限和冗余度的确定，以及应急预案的确定；
根据安全冗余的系数，冗余量为20%；则由此推测出各个offerd load的预警门限；这样，我们针对每一类业务，都会有两个门限，预警门限和告警门限；并根据预警和告警门限进行应急预案的确定工作。
              主要工作内容：
l
预警门限的计算和确定；
l
突破预警门限的扩容方案（这个扩容方案针对单个网元，为网优的扩容方案，可以给予ND参考，但不作为公司提供售前支持的正式数据）
l
告警门限突破后的临时应对措施清单，这个清单可以放到重大活动保障项目中去；

POSSIBLE ACTIONS FOR CAPACITY ENHANCEMENTS

The intent of this chapter is not to propose an exhaustive list of the actions that may

improve the RNC capacity, but to provide some proposals to help enhancing the RNC

capacity. This list is to be completed based on returns on experience received.

Thus, the following possible actions may be considered:

- Enabling of features that improves RNC capacity like “Iub Silent Mode”, “Full

Event Trigger”… (The engineering recommendation is to have them enabled by

default).

- Decrease some event frequencies like Measurement Reports if it is compatible

with QOS aspects,

- Modify AO timers to limit some release and establishment of Data calls,

- Limit the usage of call trace feature

- Study if some reorganization of LAC and RAC boundaries may help in decreasing

RNC loads

- Addition of new Packet Server boards inside the RNC if it is possible to work with

a bigger Market model.

- Migration from a RNC market model using PS-FP boards to a market model using

DCPS boards if the RNC is not already equipped with DCPS.

- If the RNC is equipped with 16pOC3STM1 PQC boards, it has to be verified that

these boards are not reaching their limitation (310 Mbps Iu DL traffic). Else they

should be replaced by 16pOC3STM1 MS3 boards.

- Reparenting of some NodeB to less loaded RNC

- Addition of new RNC on the network

-

4.
根据上述1,2,3形成一套计算软件，用以采集现场数据，监测业务趋势并提前预警和告警；
可以围绕这个软件平台，发布网络风险预测和预警，并通知售前，提前准备销售方案。