联合寻呼试验总结报告.docx

上传人:b****6 文档编号:5860934 上传时间:2023-01-01 格式:DOCX 页数:7 大小:18.96KB
下载 相关 举报
联合寻呼试验总结报告.docx_第1页
第1页 / 共7页
联合寻呼试验总结报告.docx_第2页
第2页 / 共7页
联合寻呼试验总结报告.docx_第3页
第3页 / 共7页
联合寻呼试验总结报告.docx_第4页
第4页 / 共7页
联合寻呼试验总结报告.docx_第5页
第5页 / 共7页
点击查看更多>>
下载资源
资源描述

联合寻呼试验总结报告.docx

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

联合寻呼试验总结报告.docx

联合寻呼试验总结报告

文稿归稿存档编号:

[KKUY-KKIO69-OTM243-OLUI129-G00I-FDQS58-MG129]

 

联合寻呼试验总结报告

 

概述

目前网络中,网络操作模式设置为网络操作模式2(NOM2),在这种情况下,数据业务用户在传输数据的时候,语音是无法寻呼到该用户。

联合寻呼功能可以在不需要进行硬件改造的情况下,使用户可以被语音寻呼到。

从用户的角度看,该Feature使用户可以接收寻呼消息,提升用户感知;从网络端来看,可以避开Gs端口的建设,而达到寻呼用户的目的,减少网络复杂度。

联合寻呼功能测试验证

开启联合寻呼之前

数据业务在ready状态下,语音无法寻呼到,release原因为callreject

开启联合寻呼之后

数据业务在ready状态下,语音可寻呼到。

在语音释放后,可继续数据业务

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

寻呼挽救次数

开通联合寻呼功能的4个LAC区平均挽救寻呼数如下所示:

LAC

一周平均寻呼量

一周平均挽救次数

寻呼挽救比

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=;

功能激活命令

激活:

ZW7M:

FEA=1802:

ON:

;

网络操作模式变更命令

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

ZEGP:

19:

01;

测量开启

建立测量:

ZTPM:

GPRS,PCU:

,,;

开始测量:

ZTPS:

GPRS,PCU;

注意:

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

去激活联合寻呼功能:

检查LIC开启情况

ZW7I:

LIC,FULL:

LIC=;

功能去激活命令

去激活:

ZW7M:

FEA=1802:

OFF:

;或者ZW7M:

FEA=1802:

CONF:

;

网络操作模式变更命令

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

ZEGP:

19:

00;

测量关闭:

ZTPE:

GPRS,PCU

联合寻呼功能测试验证

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

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

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

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

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

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

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

其信令如下所示:

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

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

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

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

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

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

LAC下寻呼挽救次数

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

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

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

LAC

一周平均寻呼量

一周平均挽救次数

寻呼挽救比

22337

791793

17657

2.23%

22470

888701

15918

1.79%

26578

677886

17185

2.54%

26591

593188

8659

1.46%

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

LAC下寻呼成功率

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

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

LAC:

22470寻呼成功率变化情况

从LAC:

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

其具体指标如下所示:

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

LAC:

22337寻呼成功率变化情况

从LAC:

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

其具体指标如下所示:

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

LAC:

26578寻呼成功率变化情况

从LAC:

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

其具体指标如下所示:

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

LAC:

26591寻呼成功率变化情况

从LAC:

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

其具体指标如下所示:

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

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

date

lacid

位置更新数

SD掉话率

SD拥塞率

SD建立成功率

下行0_5级质量

上行0_5级质量

26591

514271

0.29%

0.47%

99.92%

99.52%

26591

537258

0.34%

0.00%

99.93%

99.51%

26591

525239

0.24%

0.00%

99.86%

99.53%

26591

525735

0.24%

0.02%

99.97%

99.54%

26591

515557

0.22%

0.00%

99.96%

99.52%

26591

507311

0.28%

0.02%

99.95%

99.50%

26591

520883

0.26%

0.00%

99.97%

99.51%

26591

515926

0.27%

0.00%

99.96%

99.50%

26591

546912

0.30%

0.08%

99.96%

99.50%

26591

538725

0.24%

0.00%

99.97%

99.53%

开通后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下的寻呼成功率有一定提高,并且没有负面的影响,故建议全网开启该功能。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 经管营销

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1