寻呼被叫无响应
- 格式:pdf
- 大小:220.82 KB
- 文档页数:2
可能原因1)MSC从SGs接口下发寻呼消息中通过IMSI进行寻呼,导致UE在回到GU网络后,通过IMSI回复寻呼响应,无线BSC/RNC通过IMSI寻找到的MSC可能不是发起寻呼的MSC,从而导致被叫失败。
MSC通过软参P1156Bit7控制从SGs接口下寻呼时携带TMSI信元,确保寻呼响应时正确选择MSC Server 。
CPCI V100R007C10SPH711ATCA V200R009C02SPH113或者MSC开启CSFB MTRF特性(会增加时延)。
2)UE做了detach流程,MSC和MME上将用户状态置为detach,同时MME上会将UE之前的TMSI信息删除,然后UE发起了一次新的联合位置更新,发现MSC在SGs上回复的Location Update Response里没有分配TMSI,但是在做被叫时,MSC又是以TMSI发起寻呼,由于MME上此用户的TMSI信息已经删除,认为该TMSI不合法,转而以IMSI寻呼,导致UE在回落到GU网络后,IMSI的寻呼响应被随机分配到了MSC Pool 中的任意一台,出现概率性被叫失败。
但是测试发现三星S3与苹果iphone5的终端无问题,猜测其原因是虽然网络侧以IMSI寻呼,但是终端上存在TMSI,在CSFB回到GU后,仍然以TMSI做寻呼响应,所以可以寻找到正确的MSC。
MSC为异厂家设备,MME为华为设备。
USN V900R012C00SPC300+SPH316补丁解决,MME不检测TMSI合法性,直接转发寻呼。
3)MSC通过SGs接口发起TMSI寻呼失败,后续发起IMSI寻呼,寻呼成功导致UE回落到GU后无法发送paging response到正确MSC。
MSC为异厂家设备,MME为华为设备。
UE做联合位置更新时,MSC给MME发送的SGsAP-LOCATION-UPDATE-ACCEPT消息中的new-tmsi-or-imsi信元指示为IMSI,但是发送SGs接口paging request消息里却使用TMSI寻呼,导致UE无法匹配TMSI,无法响应CSFB paging。
VoLTE手机被叫未接通案例分析【摘要】VoLTE试商用时出现大概率被叫无法接通现象,通过现场测试排查和端到端信令分析,将问题锁定在核心网侧。
省NOC根据故障报告进行排查,针对核心网TLDN回落机制分析,最终确认核心侧TLDN数据配置不全。
【关键字】VoLTE 被叫TLDN 回落背景:随着网络优化和VoLTE商用的推进,安徽电信内部开通VoLTE用户预商用,要求各分公司试用并进行网络质量分析和疑难问题反馈,协助省公司完成VoLTE商用指导。
【故障现象】:省公司开通VoLTE测试卡后,概率性出现VoLTE测试卡作为被叫无法接通现象,未接通时主叫保持呼叫状态,被叫手机无响应,直至主叫手机提示“无声、空号、无法接通、未开通此项业务、增值业务被终止”等各种声音通话结束:图1:测试被叫无响应【告警信息】:登录基站无告警,网元测试,基站与MME、SGW等网元连接正常:图2:网元节点测试【原因分析】:(一)终端排查现场倒换终端进行测试验证,发现开通VoLTE功能终端在CS域做被叫出现大概率未接通,主叫正常:表1:终端排查(二)无线环境分析CQT测试,选取RSRP:-60dbm、SINR:30db覆盖正常,无线环境良好的测试点进行测试,依然出现被叫CS域无法接通现象:图3:无线环境(三)信令对比分析通过以上分析可以看出本次未接通与无线环境无关,只是VoLTE 功能终端在CS域被叫引起的未接通,计划通过CS域被叫正常通话和未接通信令对比来分析差异。
正常接通时:IMS域主叫发起INVITE Request后,2s∽5s左右被叫在C网收到寻呼消息,进而发起CSFB回落到C网通话,信令流程如下:图4:正常呼叫被叫CS域未接通时:信令来看IMS域主叫15:33:48发起INVITE Request请求,15:34:18发起呼叫取消,随后IMS下发呼叫取消确认,并下发INVITE 487呼叫终止,主被叫信令流程如下:此时,发起呼叫到终止经过30s时间,主叫超时释放,造成未接通,信令如下:图5:被叫无法接通主叫终端收到IMS下发的487呼叫终止消息,被叫未收到寻呼导致主叫超时终止通话,可以判断问题出在eNB上层网元IMS寻呼处理阶段。
贵阳联通4G用户作被叫无法接通故障分析报告一、问题描述6月27日12时许,贵阳联通接到部分用户反馈,主叫拨打贵阳联通用户听到炫铃音,但被叫方无任何反应,最终无法接通后通话释放。
故障发生后经现场处理人员测试发现,该故障只发生在4G用户作被叫时出现,2/3G 用户不会出现该故障。
二、问题处理接到故障反馈后,我司PS维护人员及时赶到现场,由于是4G用户出现故障, PS维护人员通过信令跟踪排除CSFB回落存在故障的可能,同时现场其他处理人员发现当故障出现时,贵阳MSCS1上发给MGW的H248消息发到了安顺MGW上(正常时是发到贵阳MGW1上),于是通过搭建远程环境,CS维护人员通过远程环境进行了故障定位,在贵阳MSCS1上配置贵阳MGW1和安顺MGW NB口之间的承载后,13点10分许,故障解决,经测试,即使建立通话时MSCS1把H248消息发到安顺MGW,通话建立不受影响。
三、问题分析本次故障从现象来看,只与4G用户有关,且都是作被叫时出现,故障出现时都是MSCS发送的H248消息没有发到被叫用户所在的MGW,该MGW 与被叫用户所在无线无任何拓扑关系,导致MGW不能建立承载导致通话建立失败,联想到6月26日凌晨进行的MSC组POOL Mc口互联操作,该故障可能与该操作有关,经进一步信令跟踪分析,在4G CSFB回落过程中,MSCS 建立H248消息与2/3G 用户通话过程中建立H248消息的时间点是不同的,在2/3G通话过程中,MSCS是在被叫用户寻呼响应后才下发H248消息让MGW 建立承。
而4G用户为了缩短CSFB回落过程中信令建立的时间,在接收到MME的业务请求回应,还没收到用户的寻呼响应时就开始发送H248消息要求MGW开始建立承载。
这样一来,对于2/3G用户,MSCS在收到用户寻呼响应后才建立H248消息,MSCS知道被叫用户所在的MGW,所以建立H248消息时始终选择正确的MGW,但对于4G用户,MSCS还没等到被叫寻呼响应就开始建立H248消息,当MSCS下有多个MGW注册时,MSCS就会随机选择一个MGW建立承载,当用户所在无线与MSCS所选择的MGW不存在拓扑关系,各个MGW间又没开启NB口承载时,承载建立就会失败,最终通话信令建立失败。
呼转语音信箱导致语音无响应处理案例
一、问题描述
XX用户在8月12日16点03分呼叫被叫,被叫侧无任何反应。
二、处理过程
查询CS单据,如下图所示:
1、查询问题时段单据,被叫用户1828870**** 16:03:30-16:03:45时段与其他用户通话中,于16:03:45时段结束通话。
2、主叫侧16:03:39时段对1828870****发起通话请求,由于被叫用户忙进行呼叫转移,呼转至12599语音信箱,导致被叫侧无任何反应。
3、2021-08-12 16:03:39.576 回铃音过长问题分析
2021-08-12 16:03:39 主叫发起INVITE,发起语音通话,被叫用户正在通话中,用户忙。
由于被叫手机设置为遇忙呼转,触发呼转流程
该通话呼转至12599语音信箱,由于该语音信箱异常原因导致被叫无响应。
三、问题根因
主叫侧16:03:39时段对1828870****发起通话请求,由于被叫用户忙进行呼叫转移,网络侧去CS域寻呼被叫号码,导致被叫侧无任何响应,主叫侧16:03:44时段取消通话。
四、解决方案
手机设置→通话设置→来电转接:重新进行设置,不转移至语音信箱。
五、建议与总结
无。
10分钟内改为2分钟内,这样统寻呼失败问题分析1.概述在寻呼无响应分析中,通常可以分为以下几个原因:位置更新原因:即当发生寻呼时,手机恰巧进行跨局位置更新,导致寻呼失败。
呼叫建立冲突:MS 在开始建立通话到 SDCCH 言道分配前的时间段,VLR 还未标记MS 状态,系统将寻呼 MS ,但MS 未监听寻呼消息。
终端断电:MS 非正常关机到 MSC/VLR 中隐关机计时器超时前的时间内,对该 MS 的寻呼,MS 无法相应,终端异常操作反映在终端发生寻呼失败后的第一个成功的网络事件 是 IMSI ATTACH弱覆盖或盲区:MS 处于弱覆盖或盲区内,造成 MS 的寻呼无响应。
根据后续发生业务 的时间,暂时起名为瞬间弱覆盖(10分钟内)或长期弱覆盖(10分钟后)。
其它:手机异常,手机死机,寻呼丢失,基站工作异常等G1寻呼失败错误原因统让■位置更新冲突 ■呼叫建立冲突 ■手机终端异常 ■瞬间弱覆盖 ■长期弱覆盖 ■其他原因从G1的寻呼失败错误分布看,其中弱覆盖或盲区的原因,占总寻呼失败的 90%以上,因此对弱覆盖的研究是寻呼失败的主要原因之一。
我们认为,引起这种弱覆盖的原因可能有以下两种情况:1. 手机进入弱覆盖区,容易脱网和入网的边界区2. 基站的paging 丢失、SDCCH 拥塞、AGCH 阻塞,导致无法分配到 SDCCH 信道,无法 上发 pagingresponse 消息。
前者,受限于现有网络的覆盖状况;后者,设备性能、配置、参数等设置有关。
为了更加精确的了解瞬间弱覆盖小区,我们将时间从 计的结果可能更加接近实际弱覆盖小区。
统计结果如下:寻呼失败后2分钟内发生新业务的小区排序如下:2寻呼失败后2-5分钟内发生新业务的小区排序如下:2.数据分析我们选择17157_1313和17157_6071两个小区为例,分析可能的产生原因。
2.1 RMS报告弱覆盖数据分析17157_1313:园丁花园 3上行:质量电平分布如下:上行弱覆盖(-95dBm以下)的比例为(67179+17380)/258038仁3.28%下行:质量电平分布如下:EBPinwoE丄EBPOW-G2.EBWGWO 0?一EBPO°?-S1EBPinror--丄EBPo\Gg丄EBPingJog丄-thh恤迂a6 5 4 3 2 di Ol丄EBPOCILGE■上行电平分布1+上行质量分布|DL_RXLEV (dBm) Qual|0 Qual|1 Qual|2 Qual|3 Qual|4 Qual|5 Qual|6 Qual|7 Tot_MEAS Avg_Qual [-47,-60) 47585 465 394 314 250 186 234 3266 52694 0.54 [-60,-65) 93958 1366 1060 895 598 426 369 369 99041 0.16 [-65,-70) 233301 2901 2241 1749 1267 1191 913 913 244476 0.15 [-70,-75) 749529 4982 3920 3910 2952 2952 2942 2942 774129 0.12 [-75,-80) 589858 6149 5837 3857 3203 2468 2323 2323 616018 0.14 [-80,-85) 375956 5589 5474 4452 3271 2451 1554 1480 400227 0.19 [-85,-90) 203862 4540 3813 3825 3066 2243 1315 853 223517 0.27 [-90,-95) 82239 3282 2918 2888 2580 1991 1305 625 97828 0.51 [-95,-100) 29111 1978 1953 2208 2007 1775 1170 569 40771 0.99 [-100,-110)122441378146817992044224919261299244072.04下行弱覆盖(-95dBm 以下)的比例为(40771+24407) /258038仁2.53%上行质量电平分布图: 步区名 fy¥_YuaiJ)ingHuaYuaii3_:3:31 ▼ |IACCI |1T15T_1313 三|TRX 信息小区信息上行口untEf 上行图形下行Counter 下行图形下行质量电平分布图:RXQLJAL 飓LEV 的详细分析上行-电平质量分布團从弱覆盖电平的比例看,该小区弱电平比例为2.53%。
FDD LTE网络被叫概率性无响应问题处理FDD-LTE网络开通后,语音业务的承载采取CSFB方式进行,在测试中发现被叫在CSFB 时概率性出现寻呼无响应现象。
主要现象为主叫无响应或提示“无法接通”。
为提升用户感知,分别在空口、RNC侧、MSC侧、MME侧进行了信令抓取及分析。
通过无线侧及核心网联合排查,最终发现导致问题的原因。
经过对调整后网络反复多场景测试验证,确定顺利解决该问题。
在FDD-LTE建网初期,基于网络改造代价及参数配置工作量最小化考虑,采取CSFallBack方式回落至GSM网络或UMTS网络进行语音、短信、定位等电路域业务。
在CSFB过程中出现网络问题。
在FDD-LTE网络中,被叫CSFB时概率性发生无法响应的现象。
主要现象有:1、主叫听到振铃音,同时被叫网络指示由LTE变为UMTS并快速返回至LTE,但未接通;2、主叫收到系统提示音“您拨的用户暂时无法接通”。
通过在不同网络环境、不同终端情况下的测试,排除无线信号及终端原因。
无响应的现象出现概率为10%左右。
分析与对策根据实际问题产生的情况,分别在无线侧及核心网侧进行了联合的排查及分析。
以找出导致问题的原因及解决办法。
处理过程第一步:核查参数设置结果:正常现网采用基于FDD到UMTS盲重定向的CSFB,经核查全网基站小区参数设置无误。
第二步:确认联合ATTACH成功结果:正常有Combine类型的A TTACH的请求,CS域和PS域均附着成功。
ATTACH ACCEPT无问题。
第三步:测试软件+被叫手机信令排查结果:异常以下为正常情况下信令:UE收到CS Service Notification然后发起Extended Service request之后在LTE网络下进行RRC连接释放,进入UMTS网络发起被叫会话类业务相关的RRC连接请求。
经过鉴权、加密、安全模式等直传消息后,先后收到setup、alerting,呼叫接通。
CSFB失败原因与信令特征对应表目录1概述 (4)1.1前言 (4)2失败类型:CSFB主叫失败 (4)2.1失败原因:终端回落到了弱覆盖的2G小区,终端在2G的接续过程中掉话 (4)A接口: (6)3失败类型:CSFB被叫失败 (7)3.1失败原因:用户处在2个TA重叠的覆盖范围, 经常在两个TA之间来回重选,做被叫时正在重选过程中导致的CSFB被叫时失败 (7)3.2失败原因:未部署MTRF功能情况下 UE跨MSC Pool回落,导致的CSFB被叫失败73.3失败原因:诺西ENodeB的CSFB功能未打开,导致的CSFB被叫失败 (8)3.4失败原因:阿朗ENodeB的CSFB LICENSE功能未打开,导致的CSFB被叫失败。
93.5失败原因:诺西MME软件缺陷,当用户正在进行X2切换时,MME并没有等待该切换完成后重新下发Paging消息,最终导致寻呼未正常下发.诺西计划在14年6月的NS31中解决。
(11)3.6失败原因:手机终端设置黑名单或来电防火墙引起CSFB被叫失败 (12)3.7失败原因:回落2G后发生LAC改变,改变后的LAC所属BSC(华为)的GSM小区未开启CSFB功能,导致主叫失败 (13)3.8失败原因:阿朗ENODEB采用BitMap方式下发GSM回落频点导致CSFB接通失败153.9失败原因: .回落邻区漏配、少配或者优先级不当引起回落失败 (16)3.10失败原因:诺西MME的BUG造成7108D等单卡双待手机存在联合附着. 引起双待手机被叫失败 (17)3.11失败原因: ENODEB将ESR(TAU)错误分发至另外一个SGSN,引起被叫无法接续(大唐、中兴ENDOBE) (17)3.12失败原因:伪基站干扰,CSFB手机做被叫时回落至伪基站,造成被叫失败193.13失败原因: 4G网络弱覆盖寻呼无响应造成被叫失败。
(20)3.14失败原因: 4G网络SINR值差,导致iPhone手机终端无法收到Paing消息造成被叫失败。
未接通原因归类未接通原因归类:导致未接通的常见的原因主要有:被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH 掉话、呼叫号码错误、CIC分配错误、寻呼失败。
1、RxLev连续小于-90dBm2、(GSM)RxQual连续5级-7级3、(GSM)No route to destination\拥塞\No circuit/channel available 主叫在起呼期间,被叫在位置更新,无法响应主叫寻呼,导致主叫呼叫建立超时(超过15S),上发Disconnect。
4、主叫起呼期间,完成了SDCCH信道以及TCH指配,但被叫一直处于空闲模式下。
(无线环境良好)Call rejected/CM Service Reject(如果信令解码有明确原因请归入前面类别)5、起呼期间,下行电平弱(BCCHLEV\Rxlevsub连续小于-90DBM) 起呼期间所指配的SDCCH信道或者TCH信道受到干扰。
6、无SDCCH或者TCH信道指配,导致呼叫建立超时,主叫上发disconnect;或者指配TCH信道时出现指配失败。
(RR Assignment Failure)原因1:是当前服务小区的Pch信道拥塞,无法下发寻呼消息;原因2:被叫收到寻呼寻呼消息,但无法占用SDCCH信道上发寻呼响应。
归为信道拥塞。
7、重选不及时会导致主叫起呼失败。
8、被作为被叫的时候分配了TCH后呼叫,会导致碰撞,进而无法接通;未接通主要原因如下:1、路段覆盖差1)本身覆盖差2)孤岛效应导致覆盖差3)重选不及时导致覆盖差4)硬件故障,TCH载频问题,跳线问题;2、参数设置问题1)重选关系2)接入电平门限3)呼入呼出限制等等3、容量问题:无空闲信道等4、硬件故障问题4、手机本身问题。
呼叫器无人应答的原因分析
可能是主机的原因,也可能是呼叫器的原因,这个不能单方面判断。
最简单的原因是电池没电了,还是要根据您主机和呼叫器的型号以及相应表现的问题做判断的。
1.看看呼叫器中间的显示的显示灯是否红色?如果没有亮或不是红色就需要检查电池接触是否完全或更
换新电池。
2.检查呼叫器和主机的对码(对频)是否正确?当然首先要你的呼叫器是不是所谓的记忆码(也就是说没有编码开关的光光一个呼叫器。
这种成本低稳定性也差些出现故障基本没得修的)如果以上都不是那就是真正的坏了,就只能再买了。
建议还是不要摊便宜买三无产品。
目前市面比较好的无论售前售后都有保障的。
还有可能是信号不够,一般的呼叫器的电池电量会越用越少,发射功率也会下降,信号就不够用了。
一分钱一分货,如果能用得住,还是得选择更加省电的调频呼叫器,用个几年都不会有问题。
移动通信寻呼信令流程下载温馨提示:该文档是我店铺精心编制而成,希望大家下载以后,能够帮助大家解决实际的问题。
文档下载后可定制随意修改,请根据实际需要进行相应的调整和使用,谢谢!并且,本店铺为大家提供各种各样类型的实用资料,如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等,如想了解不同资料格式和写法,敬请关注!Download tips: This document is carefully compiled by theeditor. I hope that after you download them,they can help yousolve practical problems. The document can be customized andmodified after downloading,please adjust and use it according toactual needs, thank you!In addition, our shop provides you with various types ofpractical materials,such as educational essays, diaryappreciation,sentence excerpts,ancient poems,classic articles,topic composition,work summary,word parsing,copy excerpts,other materials and so on,want to know different data formats andwriting methods,please pay attention!1. 主叫用户发起呼叫:主叫用户在其移动终端上输入被叫用户的号码,并按下呼叫按钮。
从正常的呼叫流程来分析手机一次未接通原因一、正常呼叫流程中被叫用户的信令图二、从信令流程的理论上分析一次未接通的原因因为所有一次未接通用户投诉都听到手机回铃音,因此主叫通路已经建立,未接通的原因都是被叫通路建立过程中出现问题而造成的,因此我们主要针对被叫手机信令进行详细分析。
被叫一次未接通都是寻呼无响应造成的,而寻呼无响应就是信令Paging Response没有正常上报,Paging Response没有上报的原因:1、空口Paging消息没有下发。
2、PCH过载,BTS没有下发Paging Request。
3、下行质量差以及空口质量差,MS在空口没有收到BTS下发的Paging Request。
4、空口质量差,MS没有在空口接入SDCCH信道。
5、SDCCH拥塞,MS没有接入SDCCH信道。
6、MS上行质量差,在SDCCH信道建立连接过程中失败。
7、BSC没有下发IMMEDIATE ASSIGN COMMAND消息。
8、BTS没有下发IMMEDIATE ASSIGN COMMAND消息。
9、由于空口原因,MS没有收到BTS下发IMMEDIATE ASSIGN COMMAND。
10、由于空口原因,MS收到BTS下发IMMEDIATE ASSIGN COMMAND没有上报Paging Response。
三、从现场拨测跟踪信令分析一次未接通原因现场我们针对多款手机进行大量的拨打测试,发现无论网络质量如何,都会出现这种一次未接通现象。
只是信号较弱、干扰较大、信道拥塞的情况下,一次未接通现象频繁出现。
我们发现一个共同的规律:所有的一次未接通现象的信令流程中,在A口没有看到Paging Response上报,即是在N侧三次寻呼下发之后,15s超时还没有寻呼到,也就是寻呼无响应或者寻呼响应超时导致。
因此我分析一次未接通主要细分原因就是空口质量、上下行质量、SDCCH拥塞、PCH过载等造成的,还有一部分主要原因是网络覆盖较弱时手机上下行接入参数设者不合理引起的。
问题现象主被叫均在4G侧,第26次呼叫主叫呼叫建立时长9.738秒,本次呼叫时延超长,对整个网格时延指标影响较重。
原因分析分段统计呼叫时延主叫INVITE→100trying之间时延(0.911s),100trying→183之间时延(8.005s),可以看出本次呼叫时延过长阶段是主叫从收到100tryging到183下发之间,核查现场无线环境,起呼阶段主叫占用海天花园-HLHF-2小区,RSRP=-96.56dBm,SINR=9.60dB无线环境良好,但随着车辆移动,RRC连接建立安全模式命令完成时,主叫电平衰减至-101.56dBm,SINR恶化至-11dB,无线环境开始变差,21:07:39.014主叫激活QCI1专载时,SINR质差到-17dB,RSRP=-98.31dBm,邻区中森林小镇-HLHF-1小区电平值为-85.18dBm,两者存在同频切换不及时问题,从被叫侧看被叫21:07:25.734 RRC release释放上一次会话后,就一直处于空闲态,21:07:42.308被叫还进行了一次小区重选,直到21:07:45.955被叫才收到MME下发的Paging寻呼消息进行RRC建立,此时距主叫起呼(21:07:38.260)已经过去了约7.695s。
结合主被叫呼叫信令流程分段分析,被叫寻呼响应过慢是导致本次呼叫建立时延过长的原因。
处理方法1)eNodeB侧进行最优参数组合优化,“开”寻呼信道干扰随机化开关、“降”寻呼码率、“增”寻呼下发次数,达到提升空口寻呼成功概率。
2)对起呼过程中发生切换问题,需要加快同频切换进程,可以修改海天花园-HLHF-2到森林小镇-HLHF-1的CIO由0dB改为3dB。
优化效果:该路段进行“寻呼参数及切换优化”调整后,整体切换顺畅(海天花园-HLHF-2切森林小镇-HLHF-1),在该路段拨测主叫呼叫建立时延降至在2s以下。
经验总结针对此类问题要根据呼叫时延的信令节点流程进行分段统计分析,确定高时延出现在那段流程,在通过测试数据详细分析导致高时延的原因,配合寻呼参数等。
GSM数据错误导致CSFB被叫无响应问题描述:在LTE室分测试时,发现室内拨打电话正常,上网正常,但经常接不到来电,只能收到来电提醒消息。
现场实地测试,发现问题确实如此。
原因分析:1.测试时,终端显示占用PCI为17,频点为38950的小区,经验证,该基站下LTE能正常占有该基站信号,确定该基站位置的准确性。
2.由于此站是LTE三期新开站,状态为“等待开通”,无法通过网管提取KPI。
于是先检查基站告警,查看历史告警信息,发现基站开通后未出现过告警。
3.再查看基站配置数据信息,该基站4→4、4→3、4→2数据配置齐全,基站基本参数配置与其他基站一致,未发现参数配置问题。
4.关闭该基站后再进行测试,终端占用室外宏站,主被叫均正常。
重新开启基站后复测,问题复出,确定为此新建站原因。
5.核查配置CSFB相关数据,终端始终占用频点为78的GSM小区。
怀疑是GSM小区存在问题,准备核查修改GSM小区数据。
解决措施:1、因为终端在回落到GSM时,固定占用频点为78的GSM小区,怀疑周围也有配置此频点的小区,但两个小区LAC不一致,导致LTE经常接收不到寻呼。
2、通过NASTAR导入GSM数据库,针对于频点78进行筛选,发现附近不远处却有频点号为78的小区,但是两个小区的LAC不一致,导致CSFB无响应。
3、将该基站的频点由78改为87后复测,通话正常,问题得到解决。
预防监控措施:1、新建站站点规划数据要准确,数据配置要准确无误。
2、新开站点测试要及时,如有问题及时与后台人员反馈,找出问题原因,立即解决。
3、定期性核查参数,确保参数的准确性。
用户主叫正常被叫困难问题解决案例单位中国电信广西分公司玉林无线网优中心摘要本文介绍通过现场测试与后台跟踪的方法对用户被叫异常问题进行分析、定位以及处理的过程。
1、问题描述用户投诉其手机近几天主叫正常,但被叫经常提示不在服务区,之前是正常的。
2、问题分析工作人员到用户处进行测试,信号良好且主被叫正常,初步排除是基站信号问题。
将用户的UIM卡换到工作人员手机机上测试:主叫正常,被叫如用户反映的情况一样。
排除了基站信号和手机终端的原因后,网管人员对用户号码进行业务和信令跟踪,业务跟踪如下:连续呼叫用户号码,一般5次呼叫只有一次成功,不成功时提示“号码不在服务区”,业务跟踪显示中断原因均为“ERR_SPS_RLSA_BSSAP_FchSetup_RcvSccpDisconnect”,查看中兴技术文档,其对中断原因的描述为:我们对导致失败的4种失败原因进行逐一分析:1、原因1基本排除;2、原因2基本排除3、原因3:再次经数据班检查,用户号码数据正常,排除;4、原因4:玉林目前正处于工程建设时期,很有可能由于MSC侧与BSC侧CI不一致导致呼叫失败,但为何用户只是被呼而起呼则没问题呢,同时工作人员的号码则没有任何问题?顿时一筹莫展。
再对业务跟踪数据进行详细查看,发现用户被呼成功时占用的是243-2小区,被呼失败时占用的是148-6小区,存在共性!随即针对243-2小区以及148-6小区进行分析:经查243-2小区是玉柴汽车城基站小区,是离用户处很近,接收其信号很正常,该站属于老站,开通运营很久了;148-6小区是华邦食品公司基站小区,距离用户处约2.3km,该站位置并不高,显然不应是用户能收到的信号。
该站点是几天前刚刚开通的,考虑到用户反映其之前使用一直正常,最近几天才有问题,我们对该小区进行业务观察,同时继续对用户进行拨打测试,结果见下图:除了投诉用户的业务不正常外,其余用户的呼叫均正常,148-6小区的数据应该是没有问题的。
寻呼成功率低问题处理专题指导版本:V1.0中兴通讯工程服务部GSM网规网优部发布声明本资料著作权属中兴通讯股份有限公司所有。
未经著作权人书面许可,任何单位或个人不得以任何方式摘录、复制或翻译。
侵权必究。
和是中兴通讯股份有限公司的注册商标。
中兴通讯产品的名称和标志是中兴通讯的专有标志或注册商标。
在本手册中提及的其他产品或公司的名称可能是其各自所有者的商标或商名。
在未经中兴通讯或第三方商标或商名所有者事先书面同意的情况下,本手册不以任何方式授予阅读者任何使用本手册上出现的任何标记的许可或权利。
本产品符合关于环境保护和人身安全方面的设计要求,产品的存放、使用和弃置应遵照产品手册、相关合同或相关国法律、法规的要求进行。
由于产品和技术的不断更新、完善,本资料中的内容可能与实际产品不完全相符,敬请谅解。
如需查询产品的更新情况,请联系当地办事处。
目录1概述....................................................................................................................... 1-1 2寻呼成功率公式................................................................................................... 2-2 3中兴BSS关于寻呼的计数器.............................................................................. 3-3 4寻呼原理和流程分析........................................................................................... 4-54.1 寻呼原理............................................................................................................... 4-54.2 无线寻呼的基本信令流程................................................................................... 4-5 5影响寻呼成功率的原因....................................................................................... 5-7 6优化步骤和方法................................................................................................... 6-9 7寻呼相关知识..................................................................................................... 7-127.1 手机所在寻呼组的计算..................................................................................... 7-127.2 BTS的寻呼能力计算 ........................................................................................ 7-137.3 寻呼方式............................................................................................................. 7-137.4 BTS的能够承载的消息数量 ............................................................................ 7-147.5 寻呼组、BS-PA-MFRMS、BS-AG-BLKS-RES(AGB)三者关系.............. 7-157.6 位置区与寻呼关系............................................................................................. 7-167.7 ZXG10-BSC的PAGING能力.......................................................................... 7-16 8典型案例............................................................................................................. 8-188.1 SDCCH拥塞引起的寻呼无响应....................................................................... 8-188.2 MSC流控导致的呼不通手机 ........................................................................... 8-188.3 T3212设置错误导致的寻呼无响应 ................................................................. 8-198.4 十堰联通GSM寻呼成功率指标优化 .............................................................. 8-201 概述寻呼成功率是GSM网络的一项重要网络质量指标,它直接影响来话接通率和无线系统接通率等其它网络指标。
GSM
0.5%
的差距。
DT 测试长期趋势见Figure-1。
Edward Ruan Page 1 of 2 Performance Improvement
Figure-3 寻呼响应失败时BCCH 下行BER 差
寻呼解码失败经常发生在BCCH 下行质量(BER)较差的情况下,同时有错误报告提示此时产生手机无法解码Paging 。
Call Attempts 7474 Call Connection Failure 112 98.50%Paging Timeout 53 47.32%SDCCH Loss 18
16.07%Data Source: TEMS logs from 4.23 to 6.23
Figure-2 TEMS 测试呼叫失败主要原因 寻呼无响应在移动网中较常见,主要发生在郊区盲区和弱覆盖区,对长途来话接通率(TICR )也有严重影响。
在市区覆盖良好的小区中,同样可能发生寻呼无响应,
原因是BCCH 下行C2I 较差的点上,因为BER 恶化,被叫解码包含寻呼消息的CCCH 帧连续失败,导致无法响应寻呼。
如Figure-3 所示,被叫驻留小区在BCCH 下行有较差的BER ,最终导致寻呼无响应即呼叫建立失败。
Figure-4 BCCH 的下行BER 差时不能解码paging
BCCH 下行信令质量无法通过任何统计和通话测试来得到准确计量,但可通过TEMS 的IDLE-MODE 模式来测试,MS 收到每4个BCCH_BLOCKS 即4个51复帧后送出一个idle mode report ,内即包含BCCH 的rxqual 。
如果有条件用TEMS3.1+RS320作IDLE 测试,每8个51复帧才给出一个测量值,可确保BCCH 下行信令质量测试结果的高可靠性。
被叫寻呼无响应(Paging Timeout )
减少寻呼无响应可能的方法
减少盲区;
减少弱覆盖区;
减少BCCH 上下行频率干扰; 增大T3113时长;
对BCCH 下行信令质量恶化作出快速躲避反
应:强制手机立即无条件重选小区;
BCCH 下行信令失败(Downlink Signalling Failure )是寻呼无响应的根本原因。
GSM 规范规定下行信令失败计数器DSC=inter(90/bs_pa_mfrms),当MS 能成功解码寻呼子信道,DSC 加1,当MS 解码寻呼子信道失败(Failed to decode paging 或BFI ),DSC 减4,若DSC<0,不论当前小区电平和C1、C2是多少,立即作一次小区重选以躲避当前小区的BCCH 下行信令失败。
比如BS_PA_MFRMS=3=5,那么DSC=18,MS 最坏时连续四次以上解码寻呼子信道失败,才作紧急重选;比如BS_PA_MFRMS=5=7,那么DSC=12,MS 最坏时连续三次以上解码寻呼子信道失败,就作紧急重选。
BS_PA_MFRMS 寻呼子信道设置越多,意味着DSC 门限越小,MS 遭遇BCCH 下行信令失败时作出躲避越快。
毕竟这个系统内BCCH 下行好的小区在时间和空间上比BCCH 下行差的小区要多得多,所以理论上设置较多的寻呼子信道对确保MS 能响应寻呼,对TICR 和对GPRS 的小区重选有统计意义上的好处。
但对小区重选的准确度有影响。
鉴于当前的情况,T3113增大会导致主叫用户提前挂机反而影响TICR ,以下三种方法可供参考用于减少被叫无响应进而提高路测接通率。
1. TEMS 的IDLE-MODE 测试BCCH 下行信令
质量(最好用RS320评估PCH) 2. Agilent GSM receiver IDLE-MODE 测试
BCCH 下行干扰和下行BER ;
3. 用以上两步识别BCCH 恶劣区域并整治覆
盖,干扰和频率,如1883/1871区域;
4. 将BS_PA_MFRMS 从3提高至5,牺牲小区
重选精度,减少寻呼无响应的几率;
5. MTC 尽最大可能驻留在最好的BCCH 上也
可减少SDCCH 的掉话几率。
Figure-5 TEMS2.0所测GSM900的BCCH 下行质量
TEMS2.0的IDLE 测试结果见Figure-5,红点表示CCCH 下行信令Qband 为7,即MS 连续4个51复帧不能解码,即在1秒内对该MS 的所有寻呼不能解码。
而对每一个被叫来说,最多被寻呼两次,寻呼消息分别包含在该MS 所属的前后间隔5秒的两个寻呼子信道内,即MS 在每一个红点和黄点处有很大的机会不能响应寻呼。
即MS 在红点处有可能错失第一次或T3113后的第二次寻呼,而导致成功响应寻呼的几率减少。
TEMS2.0的IDLE 测试结果可用于计量BCCH 、SDCCH 、PCH 下行的频率干扰特性,与计量C2I 是相关的,这是话务统计和通话测试无法完成的。
通过反复的IDLE 测试后,BCCH 下行信令恶劣的部分小区和地点可被识别,通过限制接入和覆盖、频率控制后,不但可以提高PCH 的性能,对提高路测C2I ,以及GPRS 下行质量也有帮助。
因MS 作LUP 时一定不能解码Paging , 此时产生的BER 应被去除掉。