联合寻呼试验总结报告文档格式.docx

联合寻呼试验总结报告文档格式.docx

《联合寻呼试验总结报告文档格式.docx》由会员分享，可在线阅读，更多相关《联合寻呼试验总结报告文档格式.docx（7页珍藏版）》请在冰豆网上搜索。

一周平均寻呼量

一周平均挽救次数

寻呼挽救比

22337

791793

17657

2.23%

22470

888701

15918

1.79%

26578

677886

17185

2.54%

26591

593188

8659

1.46%

LAC下寻呼成功率

4个LAC区中有3个LAC区的寻呼成功率有明显提升，提升幅度在1%-2%左右。

其中LAC:

26591寻呼成功率没有明显提升。

经分析LAC的寻呼成功率波动较大主要原因可能是该LAC下的下行0_5级质量较差导致，具体分析见4.24节。

开通后BSC的负荷

开通联合寻呼的2个BSC的BCSU的负荷略有提升，比开启前的BCSU负荷高出10%不到，对BCSU处理能力基本没有影响。

开通后BSC的日常指标变化

开通联合寻呼的2个BSC日常指标无明显异常情况，具体指标见4.4节。

联合寻呼功能介绍

联合寻呼功能

网络操作模式1（NOM1）的情况下，如果对正进行数据业务的MS进行CS寻呼时，仅能通过在MSC和SGSN之间增加Gs接口的方式实现。

在网络操作模式2（NOM2）下，BSC将CS寻呼发送给相关的PCU，PCU通过查询内部建立的表格，察看MS是否在数据传输，若有则直接在PACCH信道上进行CS寻呼发送。

当网络操作模式为2（NOM2）且Pagingcoordinate功能开启时，网络会通过系统消息SI13和PSI14中的BSS_PAGING_COORDINATION来通知MS其是否支持联合寻呼，若支持则该消息设置为1，不支持则设置为0，其信令如下所示：

当网络满足所有联合寻呼条件后，PCU会对所有进行数据业务的MS进行建表，当BSC接收到A口的寻呼消息后，其先在PCH上进行发送，同时对进行数据业务的MS进行查询，若要寻呼的MS在PCU建立的表内，则将该寻呼发送给PCU，此时PCU会确认该被叫MS是否仍旧正在进行数据传输，若是，则其在PACCH上进行寻呼消息传送，若否，则忽略此寻呼消息。

联合寻呼功能软硬件要求

软件版本需求：

硬件需求：

网络需要激活GPRS/EDGE功能

网络需要支持网络操作模式2（NOMII）

功能作用小区必须下挂在PCU2下

联合寻呼激活MML命令流程

激活联合寻呼功能：

检查LIC开启情况

ZW7I:

LIC,FULL:

LIC=<

licensecode>

;

功能激活命令

激活：

ZW7M:

FEA=1802:

ON:

网络操作模式变更命令

网络操作模式有NOM1变为NOM2：

ZEGP:

19:

01;

测量开启

建立测量：

ZTPM:

GPRS,PCU:

<

measurementday>

<

measurementinterval>

outputinterval>

开始测量：

ZTPS:

GPRS,PCU;

注意：

如果功能激活失败会出现1374告警，CSPAGINGCOORDINATIONACTIVATION/DEACTIVATIONFAILED

去激活联合寻呼功能：

功能去激活命令

去激活：

OFF:

或者ZW7M:

CONF:

网络操作模式有NOM2变为NOM1：

00;

测量关闭：

ZTPE:

GPRS,PCU

联合寻呼功能测试验证

针对开启联合寻呼功能前后进行测试验证，测试过程如下所示。

未开启联合寻呼时寻呼数据业务用户

在未开通联合寻呼功能的BSC内进行功能性验证。

对在做FTP下载的用户进行寻呼。

测试后发现，在该种情况下，主叫语音会提示：

您拨打的电话暂时无法接通。

从信令侧来看，主叫释放原因为CALLREJECTED。

其信令如下所示：

开启联合寻呼时寻呼数据业务用户

在开通联合寻呼功能的BSC内进行功能性验证。

测试后发现，在该种情况下，主叫可寻呼到被叫，其信令如下所示：

在语音通话结束之后，被叫可继续进行数据业务，其信令如下所示：

联合寻呼功能开启前后指标变化情况

LAC下寻呼挽救次数

本次试验BSC22、BSC23开启联合寻呼功能，共涉及4个LAC区域，分别为22337、22470、26578、26591。

每个LAC区域下每天均有不同程度的寻呼能挽救，其寻呼挽救变化如下所示：

从上图可以看出，寻呼挽救次数基本与该LAC区域的寻呼数成正比关系，每个LAC下的寻呼挽救比如下所示：

从4个LAC的一周数据来看，一般开启联合寻呼功能后，约有1%-3%左右的寻呼的可以挽救。

基于之前的分析结果，开启联合寻呼功能后能挽救LAC区1%-3%左右的寻呼，故对LAC区的寻呼成功率有所提高。

对开启联合寻呼功能的4个LAC区的寻呼成功率进行对比（选取寻呼量与寻呼删除相差不多的时间进行对比，并去除周末指标），其对比结果如以下所示。

LAC:

22470寻呼成功率变化情况

从LAC：

22470开启联合寻呼后的寻呼成功率来看，在总体寻呼量相差不多，寻呼删除增多的情况下，寻呼成功率还是有一定提升。

其具体指标如下所示：

该LAC开启联合寻呼后平均寻呼挽救率约在1.79%，其寻呼成功率从指标上来看较之前有1%左右的提升，略差于寻呼挽救率，主要是由于寻呼删除增多的原因造成，若寻呼删除能解决，寻呼成功率能进一步提升。

22337寻呼成功率变化情况

22337开启联合寻呼后的寻呼成功率来看，在总体寻呼量相差不多，寻呼删除增多的情况下，寻呼成功率还是有一定提升。

该LAC开启联合寻呼后平均寻呼挽救率约在2.23%，其寻呼成功率从指标上来看较之前有1%左右的提升，差于寻呼挽救率，主要是由于寻呼删除增多的原因造成，若寻呼删除能解决，寻呼成功率能进一步提升。

26578寻呼成功率变化情况

26578开启联合寻呼后的寻呼成功率来看，在总体寻呼量相以及寻呼相差不多的情况下，寻呼成功率还是有一定提升。

该LAC开启联合寻呼后平均寻呼挽救率约在2.54%，其寻呼成功率从指标上来看较之前有2%左右的提升，与寻呼挽救率大致相当。

26591寻呼成功率变化情况

26578开启联合寻呼后的寻呼成功率来看，在总体寻呼量相以及寻呼相差不多的情况下，寻呼成功率并无明显提升。

该LAC开启联合寻呼后平均寻呼挽救率约在1.46%，但从指标上来看，寻呼成功率并未有明显提升。

对该LAC区域可能影响寻呼的指标进行分析看，其SD接入性、SD掉话率、位置更新数量来看，均正常，但该LAC的下行0_5级质量较差，说明下行干扰较大，可能导致空闲状态下解寻呼消息失败，故寻呼成功率波动较大，其具体指标如下所示：

date

lacid

位置更新数

SD掉话率

SD拥塞率

SD建立成功率

下行0_5级质量

上行0_5级质量

514271

0.29%

0.47%

99.92%

99.52%

537258

0.34%

0.00%

99.93%

99.51%

525239

0.24%

99.86%

99.53%

525735

0.02%

99.97%

99.54%

515557

0.22%

99.96%

507311

0.28%

99.95%

99.50%

520883

0.26%

515926

0.27%

546912

0.30%

0.08%

538725

开通后BSC负荷变化

由于开启联合寻呼功能后BSC需要承担额外负担，及与PCU之间进行寻呼消息的协调，可能会增加BCSU的符合。

目前开启的两个BSC的BCSU符合变化情况如下所示：

从BSC22、BSC23的BCSU变化来看，开启联合寻呼功能后，BCSU在话务量相差不多的情况下，比原先BCSU负荷约有10%左右的提升，由于现网BCSU处理能力较强，一般负荷都在20%以下，开启联合寻呼功能对BCSU处理能力的影响非常小，基本可以忽略不计。

开通后BSC日常指标变化

对BSC22、BSC23开启联合寻呼功能后的日常指标变化进行跟踪，其指标变化如下所示:

BSC22日常指标变化情况

语音类指标变化

从开启联合寻呼前后指标变化情况来看，BSC22的语音类指标没有明显变化。

数据类指标变化

从开启联合寻呼前后指标变化情况来看，BSC22的数据类指标没有明显变化。

BSC23日常指标变化情况

从开启联合寻呼前后指标变化情况来看，BSC23的语音类指标没有明显的变化情况。

从开启联合寻呼前后指标变化情况来看，BSC23的数据类指标没有明显变化。

总结

通过本次试验可以看出，开启联合寻呼功能可以寻呼到正在进行数据业务传输的用户，对提高用户感知有明显作用。

并且对LAC下的寻呼成功率有一定提高，并且没有负面的影响，故建议全网开启该功能。