使用帮助
关注公众微信
 读懂通信 LTE学习大使 登陆 搜索

>> GSM、CDMA、WCDMA、LTE无线网络优化
空中接口学园空中接口技术的实施无线网络优化 → 被叫寻呼失败案例
  发表一个新主题  发表一个新投票  回复主题 您是本文的第 5534 个阅读者  浏览上一篇主题  刷新本主题   树形显示文章 浏览下一篇主题
 * 主题: 被叫寻呼失败案例 保存该页为文件  报告本帖给版主  显示可打印的版本  把本贴打包邮递  把本贴加入论坛收藏夹  发送本页面给朋友  把本贴加入IE收藏夹 
 BH-STL 离线,有人找我吗?
  
  
  等级:预备用户
  文章:1
  积分:56
  注册:2011-07-18
给BH-STL发送一个短消息 把BH-STL加入好友 查看BH-STL的个人资料 搜索BH-STL在无线网络优化的所有文章 点击这里发送电邮给BH-STL 引用回复这个文章 回复这个文章楼主
发文心情 被叫寻呼失败案例
对甬台温高速公路进行测试时,发现多次被叫寻呼失败的现象。分析PCMD数据发现,出现被叫寻呼失败的情况有一个共同点,都是在主被叫保持通话过程并跨局切换之后,主叫挂断并重新起呼,此时被叫寻呼失败。根据协议规定,手机在通话时不会做位置登记,因此判断被叫在跨局后没有及时做位置更新,因此导致寻呼失败。
    但是在空口信令中却发现,主叫在起呼建链完成前,被叫已经做了位置更新,空口信令分析如下:
主叫
06:48:40.193发送 Origination Message
06:48:40.401收到 Order -- Base Station Ack
06:48:42.197发送 Service Connect Completion
06:49:25.137发送 Order -- Release
被叫
06:48:39.977发送Sync Channel Message
06:48:41.229发送Registration Message
06:48:41.718收到Order
    从空口的信令可以看出,主叫在06:48:42发送Service Connect Completion完成建链,系统将下发对被叫的寻呼消息,而被叫在这个时间点之后一直是处于IDLE状态的,但是直到06:49:25.137主叫发送Order – Release为止,被叫一直没有收到Paging消息。
    由于空口信令的分析结果与我们的判断不相符,因此再次前往现场进行测试,并在通过UXcptrace抓取核心网的信令进行分析。通过UXcptrace抓取的信令发现,虽然被叫在寻呼之前完成了Registration请求,但是位置寄存器数据库并没有及时更新,导致系统向错误的寻呼区下发寻呼消息,引起被叫寻呼失败。
    通过该案例,我们发现主被叫在通话过程中发生跨局切换后,挂断电话后在一个很短的时间内是无法作为被叫被寻呼到的(大约1秒左右吧,这个数据还需要更多的测试来验证)
点击查看用户来源及管理<br>发贴IP:*.*.*.* 2011-08-06 17:44:02
  鲜花(0)  鸡蛋(0)
 tom 在线,有人找我吗?
  
  
  等级:LTE学习大使
  文章:4520
  积分:
  注册:2003-06-10
给tom发送一个短消息 把tom加入好友 查看tom的个人资料 搜索tom在无线网络优化的所有文章 点击这里发送电邮给tom 引用回复这个文章 回复这个文章2
发文心情 
这是路测的一种特例,平时应该很难遇到。这种情况应该从路测数据中拿掉,或者重新测试,但是应该去长呼另外的电话,而不是车内的电话。
  BTW,WCDMA也有类似的现象,看来天下核心网的更新是一般慢呀。

----------------------------------------------

点击查看用户来源及管理<br>发贴IP:*.*.*.* 2011-08-07 10:09:19

本主题文章数2,分页: [1]

管理选项锁定 | 解锁 | 提升 | 删除 | move | 固顶 | 总固顶 | 奖励 | 惩罚 | 发布公告

Powered by:Old version
Copyright ©2002 - 2019空中接口学园 , 页面执行时间:234.375毫秒