联合寻呼试验总结报告

浙江宁波移动2G无线网络咨询优化服务SERVICE EXCELLENCE NPO/MS Optimization Service2010宁波移动联合寻呼功能试验 Nokia Siemens Networks诺基亚西门子网络优化部宁波移动咨询项目组 2011-03-0413 / 15目 录1.概述12.联合寻呼功能介绍22.1联合寻呼功能22.2联合寻呼功能软硬件要求32.3联合寻呼激活MML命令流程33.联合寻呼功能测试验证43.1.1未开启联合寻呼时寻呼数据业务用户43.1.2开启联合寻呼时寻呼数据业务用户44.联合寻呼功能开启前后指标变化情况64.1LAC下寻呼挽救次数64.2LAC下寻呼成功率74.2.1LAC:22470寻呼成功率变化情况84.2.2LAC:22337寻呼成功率变化情况84.2.3LAC:26578寻呼成功率变化情况94.2.4LAC:26591寻呼成功率变化情况104.3开通后BSC负荷变化114.4开通后BSC日常指标变化115.总结131. 概述目前网络中，网络操作模式设置为网络操作模式2（NOM2），在这种情况下，数据业务用户在传输数据的时候，语音是无法寻呼到该用户。联合寻呼功能可以在不需要进行硬件改造的情况下，使用户可以被语音寻呼到。从用户的角度看，该Feature使用户可以接收寻呼消息，提升用户感知；从网络端来看，可以避开Gs端口的建设，而达到寻呼用户的目的，减少网络复杂度。 联合寻呼功能测试验证l 开启联合寻呼之前数据业务在ready状态下，语音无法寻呼到，release原因为call rejectl 开启联合寻呼之后数据业务在ready状态下，语音可寻呼到。在语音释放后，可继续数据业务 联合寻呼功能开启前后KPI指标变化l 寻呼挽救次数开通联合寻呼功能的4个LAC区平均挽救寻呼数如下所示：LAC一周平均寻呼量一周平均挽救次数寻呼挽救比22337791793176572.23%22470888701159181.79%26578677886171852.54%2659159318886591.46%l LAC下寻呼成功率4个LAC区中有3个LAC区的寻呼成功率有明显提升，提升幅度在1%-2%左右。其中LAC:26591寻呼成功率没有明显提升。经分析LAC的寻呼成功率波动较大主要原因可能是该LAC下的下行0_5级质量较差导致，具体分析见4.24节。l 开通后BSC的负荷开通联合寻呼的2个BSC的BCSU的负荷略有提升，比开启前的BCSU负荷高出10%不到，对BCSU处理能力基本没有影响。l 开通后BSC的日常指标变化开通联合寻呼的2个BSC日常指标无明显异常情况，具体指标见4.4节。2. 联合寻呼功能介绍2.1 联合寻呼功能网络操作模式1（NOM1）的情况下，如果对正进行数据业务的MS进行CS寻呼时，仅能通过在MSC和SGSN之间增加Gs接口的方式实现。在网络操作模式2（NOM2）下，BSC将CS寻呼发送给相关的PCU，PCU通过查询内部建立的表格，察看MS是否在数据传输，若有则直接在PACCH信道上进行CS寻呼发送。当网络操作模式为2（NOM2）且Paging coordinate功能开启时，网络会通过系统消息SI 13和PSI 14中的BSS_PAGING_COORDINATION来通知MS其是否支持联合寻呼，若支持则该消息设置为1，不支持则设置为0，其信令如下所示：当网络满足所有联合寻呼条件后，PCU会对所有进行数据业务的MS进行建表，当BSC接收到A口的寻呼消息后，其先在PCH上进行发送，同时对进行数据业务的MS进行查询，若要寻呼的MS 在PCU建立的表内，则将该寻呼发送给PCU，此时PCU会确认该被叫MS是否仍旧正在进行数据传输，若是，则其在PACCH上进行寻呼消息传送，若否，则忽略此寻呼消息。2.2 联合寻呼功能软硬件要求l 软件版本需求：l 硬件需求：v 网络需要激活GPRS/EDGE功能v 网络需要支持网络操作模式2（NOM II）v 功能作用小区必须下挂在PCU2下2.3 联合寻呼激活MML命令流程 激活联合寻呼功能：l 检查LIC开启情况ZW7I:LIC,FULL:LIC=;l 功能激活命令激活：ZW7M:FEA=1802:ON:;l 网络操作模式变更命令网络操作模式有NOM1变为NOM2：ZEGP:19:01;l 测量开启建立测量：ZTPM:GPRS,PCU:,;开始测量：ZTPS:GPRS,PCU;注意：如果功能激活失败会出现1374告警，CS PAGING COORDINATION ACTIVATION/DEACTIVATION FAILED 去激活联合寻呼功能：l 检查LIC开启情况ZW7I:LIC,FULL:LIC=;l 功能去激活命令去激活：ZW7M:FEA=1802:OFF:;或者ZW7M:FEA=1802:CONF:;l 网络操作模式变更命令网络操作模式有NOM2变为NOM1：ZEGP:19:00;测量关闭：ZTPE:GPRS,PCU3. 联合寻呼功能测试验证针对开启联合寻呼功能前后进行测试验证，测试过程如下所示。3.1.1 未开启联合寻呼时寻呼数据业务用户在未开通联合寻呼功能的BSC内进行功能性验证。对在做FTP下载的用户进行寻呼。测试后发现，在该种情况下，主叫语音会提示：您拨打的电话暂时无法接通。从信令侧来看，主叫释放原因为CALL REJECTED。其信令如下所示：3.1.2 开启联合寻呼时寻呼数据业务用户在开通联合寻呼功能的BSC内进行功能性验证。对在做FTP下载的用户进行寻呼。测试后发现，在该种情况下，主叫可寻呼到被叫，其信令如下所示：在语音通话结束之后，被叫可继续进行数据业务，其信令如下所示：4. 联合寻呼功能开启前后指标变化情况4.1 LAC下寻呼挽救次数本次试验BSC22、BSC23开启联合寻呼功能，共涉及4个LAC区域，分别为22337、22470、26578、26591。每个LAC区域下每天均有不同程度的寻呼能挽救，其寻呼挽救变化如下所示：从上图可以看出，寻呼挽救次数基本与该LAC区域的寻呼数成正比关系，每个LAC下的寻呼挽救比如下所示：LAC一周平均寻呼量一周平均挽救次数寻呼挽救比22337791793176572.23%22470888701159181.79%26578677886171852.54%2659159318886591.46%从4个LAC的一周数据来看，一般开启联合寻呼功能后，约有1%-3%左右的寻呼的可以挽救。4.2 LAC下寻呼成功率基于之前的分析结果，开启联合寻呼功能后能挽救LAC区1%-3%左右的寻呼，故对LAC区的寻呼成功率有所提高。对开启联合寻呼功能的4个LAC区的寻呼成功率进行对比（选取寻呼量与寻呼删除相差不多的时间进行对比，并去除周末指标），其对比结果如以下所示。4.2.1 LAC:22470寻呼成功率变化情况从LAC：22470开启联合寻呼后的寻呼成功率来看，在总体寻呼量相差不多，寻呼删除增多的情况下，寻呼成功率还是有一定提升。其具体指标如下所示：该LAC开启联合寻呼后平均寻呼挽救率约在1.79%，其寻呼成功率从指标上来看较之前有1%左右的提升，略差于寻呼挽救率，主要是由于寻呼删除增多的原因造成，若寻呼删除能解决，寻呼成功率能进一步提升。4.2.2 LAC:22337寻呼成功率变化情况从LAC：22337开启联合寻呼后的寻呼成功率来看，在总体寻呼量相差不多，寻呼删除增多的情况下，寻呼成功率还是有一定提升。其具体指标如下所示：该LAC开启联合寻呼后平均寻呼挽救率约在2.23%，其寻呼成功率从指标上来看较之前有1%左右的提升，差于寻呼挽救率，主要是由于寻呼删除增多的原因造成，若寻呼删除能解决，寻呼成功率能进一步提升。4.2.3 LAC:26578寻呼成功率变化情况从LAC：26578开启联合寻呼后的寻呼成功率来看，在总体寻呼量相以及寻呼相差不多的情况下，寻呼成功率还是有一定提升。其具体指标如下所示：该LAC开启联合寻呼后平均寻呼挽救率约在2.54%，其寻呼成功率从指标上来看较之前有2%左右的提升，与寻呼挽救率大致相当。4.2.4 LAC:26591寻呼成功率变化情况从LAC：26578开启联合寻呼后的寻呼成功率来看，在总体寻呼量相以及寻呼相差不多的情况下，寻呼成功率并无明显提升。其具体指标如下所示：该LAC开启联合寻呼后平均寻呼挽救率约在1.46%，但从指标上来看，寻呼成功率并未有明显提升。对该LAC区域可能影响寻呼的指标进行分析看，其SD接入性、SD掉话率、位置更新数量来看，均正常，但该LAC的下行0_5级质量较差，说明下行干扰较大，可能导致空闲状态下解寻呼消息失败，故寻呼成功率波动较大，其具体指标如下所示：datelacid位置更新数SD掉话率SD拥塞率SD建立成功率下行0_5级质量上行0_5级质量20110222265915142710.29%0.47%99.92%99.15%99.52%20110223265915372580.34%0.00%99.93%99.10%99.51%20110224265915252390.24%0.00%99.86%99.11%99.53%20110225265915257350.24%0.02%99.97%99.13%99.54%20110226265915155570.22%0.00%99.96%99.14%99.52%20110227265915073110.28%0.02%99.95%99.11%99.50%20110228265915208830.26%0.00%99.97%99.12%99.51%20110301265915159260.27%0.00%99.96%99.09%99.50%20110302265915469120.30%0.08%99.96%99.07%99.50%20110303265915387250.24%0.00%99.97%99.11%99.53%4.3 开通后BSC负荷变化由于开启联合寻呼功能后BSC需要承担额外负担，及与PCU之间进行寻呼消息的协调，可能会增加BCSU的符合。目前开启的两个BSC的BCSU符合变化情况如下所示：从BSC22、BSC23的BCSU变化来看，开启联合寻呼功能后，BCSU在话务量相差不多的情况下，比原先BCSU负荷约有10%左右的提升，由于现网BCSU处理能力较强，一般负荷都在20%以下，开启联合寻呼功能对BCSU处理能力的影响非常小，基本可以忽略不计。4.4 开通后BSC日常指标变化对BSC22、BSC23开启联合寻呼功能后的日常指标变化进行跟踪，其指标变化如下所示: BSC22日常指标变化情况l 语音类指标变化从开启联合寻呼前后指标变化情况来看，BSC22的语音类指标没有明显变化。l 数据类指标变化从开启联合寻呼前后指标变化情况来看，BSC22的数据类指标没有明显变化。 BSC23日常指标变化情况l 语音类指标变化从开启联合寻呼前后指标变化情况来看，BSC23的语音类指标没有明显的变化情况。l 数据类指标变化从开启联合寻呼前后指标变化情况来看，BSC23的数据类指标没有明显变化。5. 总结通过本次试验可以看出，开启联合寻呼功能可以寻呼到正在进行数据业务传输的用户，对提高用户感知有明显作用。并且对LAC下的寻呼成功率有一定提高，并且没有负面的影响，故建议全网开启该功能。