厦门联合寻呼试验_加指标情况.docVIP

厦门联合寻呼实验 地区：厦门 时间: 2010年1月27日 接收： 目录 1. nokiA 联合寻呼功开启 3 2. nokiA 联合寻呼功能实现及作用 3 3. 选择试验BSC及小区 4 4. 测试情况及存在问题 4 5. 其它问题 6 6. PACCH说明 7 7. 指标情况 7 7.1 联合寻呼数 7 7.2 无线寻呼成功率 8 7.3 交换机寻呼成功率 8 7.4 话务量 9 7.5 数据流量 9 7.6 无线接入性 10 7.7 TBF上行建立成功率 11 7.8 TBF下行建立成功率 11 7.9 数据掉线率 12 nokiA 联合寻呼功开启 如果网络开启联合寻呼，可以通过 ZW7I：LIC，FULL:;查看联合寻呼开启情况，如下是联合寻呼在BSC里激活。 在当前网络模式下（NMO2），联合寻呼开启后。网络会通过系统消息13中的BSS_PAGING_COORDINATION来通知MS网络否支持联合寻呼，如果支持则该消息在系统13中设置为1：具体如下： nokiA 联合寻呼功能实现及作用 网络操作模式处于2（NMO2）情况下，网络开启联合寻呼后（Paging coordinate），PCU会对所有进行数据业务的MS进行建表，当BSC接收到A口的寻呼消息后，其先在PCH上进行发送，同时对进行数据业务的MS进行查询，若要寻呼的MS 在PCU建立的表内，则将该寻呼发送给PCU，此时PCU会确认该被叫MS是否仍旧正在进行数据传输，若是，则其在PACCH上进行寻呼消息传送，若否，则忽略此寻呼消息。联合寻呼的主要作用是解决用户在进行数据业务过程中（正在占用TBF时）无法被寻呼的情况。 选择试验BSC及小区 1月26号晚上，BSC2D1和BSC2D4开启网络寻呼，我们分别选择BSC2D4和BSC2D1的中莲屯、软件园49号做CQT测试，测试内容如下： BSC2D1和BSC2D4 DT FTP 测试，在FTP下载过程中做响应主叫（通话过程控制在120秒内） 测试情况及存在问题 在CQT及DT测试过程中，数据在下载过程中能够响应网络通过PACCH下发的寻呼，中断数据下载支持语音通话，通话结束恢复数据下载。具体的信令流程如下： 在CQT及DT测试过程发现，在下载过程中响应主叫而中断数据下载（当通过时长达到120秒以上时）。后出现PING失败超时造成的FTP下载失败，下载数据不能恢复，具体情况如下： 如果数据下载过程中响应主叫，通过时长小于120秒。通过结束后数据FTP下载可以恢复。具体如下： 小结： 在做FTP数据下载过程中响应主叫，通话时长大于120秒后。会造成PING失败超时FTP下载失败。数据无法恢复。 PACCH说明 分组随路控制信道（PACCH）：传送包括功率控制信息、测量数据等信息。PACCH还携带资源分配和再分配信息，PACCH以数据块为单位动态分配，但PACCH和PDTCH之间保持相对固定的关系。如果MS指配了一个PDTCH，其相对应的PACCH应处于同一物理信道上。在多时隙操作下指配了多条PDTCH（目前EDGE下行是4个PDTCH信道），此时PACCH会分配在其中的一条物理信道上。 指标情况 联合寻呼数 开启联合寻呼功能后，相关BSC的便产生了联合寻呼数。 无线寻呼成功率 从上图可以看出，开启联合寻呼功能后，无线寻呼成功率略有上升。 交换机寻呼成功率 由上图可以看出,开启联合寻呼后，交换机侧的寻呼成功率均有提高。 话务量 开启联合寻呼后，相关BSC的话务量并无明显变化。 数据流量 开启联合寻呼后，相关BSC的数据流量并无明显变化 无线接入性 开启联合寻呼后，相关BSC的无线接入性指标并无明显变化 TBF上行建立成功率 开启联合寻呼后，相关BSC的TBF上行建立成功率并无明显变化。 TBF下行建立成功率 开启联合寻呼后，BSC2D1的TBF下行建立成功率上升；BSC2D4的TBF下行建立成功率下降。与联合寻呼开启的关系需进一步观察。 数据掉线率 开启联合寻呼后，BSC2D1的数据掉线率略下降；BSC2D4的数据掉线率由2.0%上升至2.3%。与联合寻呼开启的关系需进一步观察。 上下行TBF响应主叫释放次数 开启联合寻呼功能后：上下行TBF响应主叫释放次数明显增加，这些是预料之中，具体如下： 总结 测试表明，在CQT及DT测试过程中，数据在下载过程中能够响应网络通过PACCH下发的寻呼，中断数据下载支持语音通话，通话结束恢复数据下载。但在做FTP数据下载过程中响应主叫，通话时长大于120秒