未接通总结
TDRRC建立成功率低原因(个人总结)
1.干扰导致的接入问题。
呼叫中发送RRC Connection Request后无响应，RRC不能正常连接。
当UE发送RRC Connection Request后，RNC应该回复RRC Connection setup，如果未回复就有可能存在干扰。
处理定位：首先看是否存在硬件故障，然后在问题小区下作拨打测试后台观察是否存在干扰（如ISCP），再次观察该小区参数（如SIR、干扰余量）与其它小区的区别。
综合定位问题根据定位解决问题。
2. 同步失败。
信令分析每次呼叫无法接通时反馈消息都是同步失败即NODEB发NBAP RL FAIL IND。
双击该信令我们就会看到他所携带的同步失败的信息：Cause为radio Network：synchronlsation-failure。
处理定位：首先看是否存在硬件故障，后台观察是否存在干扰（如ISCP），观察该小区参数（如SIR、干扰余量）与其它小区的区别。
定位解决问题。
3. 扰码规划错误导致终端无法接入网络。
呼叫建立失败消息的Cause值为Non synchronization。
处理定位：测试时发现邻区列表中出现一同扰码邻小区（CPI相同）。
UE无法正确解调来自同扰码的两个小区的信号，而无法起呼。
4. 上行期望功率设置过低导致接通率低。
UE发送RRC_CONNECT_SETUP_COM，但RNC没有收到。
后台信令跟踪发现错误原因提示为：network out of order。
检测后台UPPCH的ISCP值过高存在干扰。
可以提高UPPTS的期望接受功率或进行UP偏移来解决，上行干扰余量ULINTERFERERSVP配置为-3改为指导书中要求的3。
5. 数据配置错误导致覆盖正常H业务无法建立。
发现在终端建立业务前（connect），一切正常，在被叫测量报告下发1秒后RNC下发DISCONNECT，应该是业务信道建立异常，针对业务信道核查参数。
检查发现初始SIR设置过低导致初始发射功率过低，无法进行业务信道的正常建立。
电话回访总结范文四篇
电话回访总结电话回访总结范文四篇电话回访总结范文四篇电话回访总结一为加强与我院各岗位医生的沟通，了解他们思想、生活和学习情况，我们对本科、专科各岗位医生进行电话回访，更好的了解了我院员工思想动态和员工入职前折现出的一些问题。
一、调查总结此次确定电话回访人数140人（本科人数76人，专科人数64人）。
其中回访人数112人，无法回访人数28人，回访率80%，其中明确意向的99人、不来12人、辞退1人（因年龄过大）、停机13人、空号13人、未接来电2人。
共流失人员40人，人员损失比率为28.5%，非可抗拒因素占20%，实际人员损失比率为8%。
从通过电话回访效果来看，缩短了我院和员工的距离，加强了与员工的情感沟通。
在回访中，受访员工表示感到我院对员工的关心及人性化的管理模式，表示对参加工作的期待，并表示以后的工作中和大家一起努力把医院做好、做强、做大。
二、情况分析在此次电话回访112人中，确定不来的有12人（应届生为5人，占流失总数的42%），通过交流影响其主要原因主要是：1、应届生待业时间长，在毕业和正式入职时间有4个月的时间差距，这造成就业的真空阶段，应届生在此阶段因为家庭的压力及更好的工作机遇，而选择先就业。
2、原有单位不放人，原有单位为留住相关稀有人才，会选择不办理手续，不给于档案，让人员走不了，动不了的状态。
3、原单位为留住人员而相关采取措施，原单位通过提高待遇，提高级别来留住那些确定来我院工作的骨干成员，而造成他们思想的动摇或则改变想法。
如一些确定来我院工作的科主任、骨干成员出现了思想上的动摇4、家庭原因，在确定未来的人员中，有1位是因为照顾小孩、夫妻两地分居的原因，而放弃来我院工作。
5、对进入风险的担忧，这是指有固定工作，但未正式入职的人员，这类人员通过分析主要为对工作环境和能否医院对业务技能发展的需要的担忧。
从无法回访情况来看：1、出现了拒绝回访：在回访的过程中有连续几天都未接回访电话，此类人员属于国内知名大学，通过可能性分析为此类人员应是已有工作，应这类岗位归为缺岗人员。
VOLTE优化经验总结
VoLTE的一些优化经验总结1优化经验总结1.1日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE 的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3.导致NAS 的层3消息已经比MR要早，但是因为优先级比MR和SIP低，未及时发送。
优化措施：降低QCI5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3QCI5PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5PDCP DiscardTimer由300ms修改为无穷大优化效果：VoLTE无线接通率提升明显1.4SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481invite486invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
精品案例_TAC设置不合理导致VoLTE未接通
TAC设置不合理导致VoLTE未接通目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (5)四、经验总结 (6)TAC设置不合理导致VoLTE未接通【摘要】随着VoLTE业务的不断推广，VoLTE用户数逐步增加，VoLTE业务的感知成为关注的焦点。
经过几个月的不断优化，铜陵VoLTE网络掉话率逐步减少，但是未接通现象仍时有发生。
为提高用户的VoLTE通话感知，需时刻关注未接通发生的原因，逐步解决，提升接通率，保障用户通话感知。
【关键字】VoLTE 未接通【业务类别】VoLTE、参数优化一、问题描述RCU设备在铜陵铜官区北京东路上进行VOLTE路测时，主叫起呼发出Invite消息后，在收到核心网响应Trying 100之前,先收到了核心网下发的RRC Connection Release消息,RRC连接释放后,接续被终止，出现了未接通事件。
二、分析过程通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从TL-市区-康复中心-HFTA-448900-53小区（PCI：210）重选至TL-市区-市二院-HFTA-448913-54小区（PCI：356小区），由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：在主叫上发TAU请求后，未等网络回复ATU Accept，主叫已开始了起呼，上发Invite消息。
然而Invite上发0.172s后，主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫同时释放，从而导致了Blocked Call事件的发生。
三、解决措施由于TL-市区-康复中心-HFTA-448900-53小区的TAC设置为28035，TL-市区-市二院-HFTA-448913-54小区的TAC为28039，两个小区之间正好处于TAC边界。
该路段是一段长距离的连续下坡，车速较快，TAC更新引起此次未接通。
经典案例_UE不活动定时器设置较小导致VOLTE未接通
无线-UE不活动定时器设置较小导致VOLTE未接通目录一、问题描述 (4)二、分析过程 (4)三、解决措施 (5)四、经验总结 (6)UE不活动定时器设置较小导致VOLTE未接通【摘要】在eNodeB L2 MAC检测到DRB上下行都没有数据接收/发送之后，启动计时器计数，在当该计数器满足UE不活动定时器配置值后，L2上报L3发起释放（L3在S1口会向核心网发送“S1AP_UE_CONTEXT_REL_REQ”消息，且消息内携带的原因值为“User-inactivity”）；当计数器未满足UE不活动定时器配置值时L2 MAC又检测到DRB有数据发送/接收后，计时器重新计数。
由于UE不活动定时器超时导致RRC异常释放，然后上报CANCEL，导致为未接通，影响用户感知。
【关键字】UE不活动定时器VoLTE【业务类别】VoLTE一、问题描述网优人员接到用户投诉在市区金隆公司附近打电话时，几乎每天都会遇到别人打自己电话，自己手机没反应，接不到电话。
为此在现场展开测试分析优化。
起呼过程中主被叫手机一直占用金隆公司基站，4G无线环境良好。
二、分析过程主要的几个事件过程如下：（1）起呼过程中主被叫手机一直占用金隆公司基站，无线环境良好。
（2）先是主叫挂机，RRC被释放，主叫上报INVITE，主叫收到INVITE100，主叫建立EPS 专用承载。
（3）主叫RRC被释放，主叫RRC建立，收到INVITE183，收到INVITE180。
（4）主叫RRC被释放，主叫RRC建立，收到INVITE183，收到INVITE180。
（5）主叫RRC建立，主叫收到INVITE200同时上报ACK，主叫上报BYE。
（6）网络侧连续4次下发INVITE200，上报ACK和BYE，主叫收到网络侧下发的CANCEL481，原因为Cancel request received after dialog active state，收到BYE500，原因为Unexpected message received。
GSM未接通总结
路侧过程中未接通现象总结未接通主要是在手机向系统发送呼叫请求，但是在呼叫过程中由于某种原因，主叫或被叫手机没有分配到TCH信道，导致未接通。
路测(DRIVE TEST) 当中考察的一项重要指标, 接通率一直是优化中要应对的一个重要工作.在日常的测试当中, 我们经常遇到各种各样的未接通情况。
原因也是多种多样。
导致未接通的常见的原因主要有：被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH 拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH 掉话、呼叫号码错误、CIC分配错误、寻呼失败。
路测过程中L3信令流程：从测试中主叫与被叫的信令流程分析，要完成一个完整的接续过程，一共有以下几步的信令流程：主叫的信令流程：MS BTS 说明RACH Channel requestAGCH Immediate assignmentSDCCH CM service requestSDCCH CM service acceptSDCCH Authentic requestSDCCH Authentic responseSDCCH Ciphering commandSDCCH Ciphering completeSDCCH SetupSDCCH Call proceedingSDCCH Assignment commandFACCH Assignment completeFACCH ProgressFACCH AlertingFACCH ConnectFACCH Connect acknowledge被叫的信令流程MS BTS 说明PCH Paging RequestRACH Channel requestAGCH Immediate assignmentSDCCH Paging responseSDCCH Authentic requestSDCCH Authentic responseSDCCH Ciphering commandSDCCH Ciphering completeSDCCH SetupSDCCH Call proceedingSDCCH Assignment commandFACCH Assignment completeFACCH ProgressFACCH AlertingFACCH ConnectFACCH Connect acknowledgeTCH Speech相比多了主叫，被叫在交换机一侧以下几步流程，在无线上多了PAGING 这个流程：E|GMSC -> HLR UDT(BEG(INV(Send Routing Info)))D|HLR -> VLR UDT(BEG(INV(Provide Roaming Number)))D|VLR -> HLR UDT(END(RES-L(Provide Roaming Number))) Roaming NumberE|HLR -> GMSC UDT(END(RES-L(Send Routing Info))) Roaming NumberA|MSC -> BSS UDT(Paging)在路测过程中，L3接续流程和故障判断流程：导致未接通的常见的原因将结合实际情况，根据信令流程，一步一步对未接通的原因进行分析：1. channel request 拒绝channel request 拒绝在路测中很少遇到，如果小区被BAR 的情况下，会出现手机channel request 发送不出的现象。
中兴VoLTE优化经验的总结及案例
VoLTE优化经验总结及案例分享1 优化经验总结1.1 日常优化总结日常优化工作主要从无线覆盖优化、参数优化、系统内外邻区优化，功能优化四个方面着手，与ATU路网、工程建设紧密配合，提升整体网络质量。
1.2 RLC优先级优化现象：呼叫建立与切换过程冲突，专载被MME释放。
呼叫建立过程中专载建立与切换几乎同时发生，MME未收到NAS专载完成消息导致释放专载，终端回复invite580（也有上发CANCLE的情况），专载丢失形成未接通事件。
原因分析：QCI5设置的RLC优先级为2，高于SRB=2(传送NAS层消息)配置为3. 导致NAS的层3消息已经比MR要早，但是因为优先级比MR 和SIP低，未及时发送。
优化措施：降低QCI 5优先级，确保SIP消息及时上传，修改后此类问题改善明显。
1.3 QCI 5 PDCP DiscardTimer时长优化现象：终端业务建立过程中，出现SIP信息传递丢失的问题，导致收到网络下发的INVITE500或者580等原因值释放。
原因分析：UE在无线信道较差的情况下，SIP信令发送或接收不完整或者无法及时传递，导致IMS相关定时器超时而发起会话cancel。
经过分析，由于QCI5的pdcp 丢弃时长过小，在无线覆盖较差的地方，上行时延会变大，容易导致QCI5信令丢包。
优化措施：QCI5 PDCP DiscardTimer 由300ms 修改为无穷大优化效果：VoLTE无线接通率提升明显1.4 SBC传输协议TCP重传次数优化背景：被叫从2G返回4G后，主叫起呼，被叫首先bye消息，紧接着接连收到多条上一次呼叫的invite，被叫回复bye481\invite486\invite580，呼叫失败。
优化措施：爱立信SBC对TCP配置进行了修改：最大重传次数从15次改为5次，最大重传隔间从十几分钟改为15s，此类问题已解决。
1.5 系统间邻区优化LTE网络的GSM邻区关系根据工程参数、共站2G邻区同向小区继承进行规划，同时根据4G、2G道路测试数据匹配进行邻区补充：4G弱信号路段与2G拉网服务小区匹配：利用第三方拉网测试数据，将4G和2G拉网信号强度、经纬度、服务小区等信息导出。
掉话问题的简单总结以及掉话与未接通的关系结
掉话问题的总结以及掉话与未接通的关系掉话的分类:一般以通信阶段来分可分为: SDCCH 信道上的掉话和TCH 信道上的掉话SDCCH 信道上的掉话是指BSC 给手机分配了SDCCH 信道但是还没有分配成功之前而形成的掉话.TCH 掉话是指BSC 已经成功给手机分配了TCH 后所产生的掉话.产生掉话的原因主要有三条:一是无线链路故障,二是切换失败T3103超时,三是设备硬件故障.需要注意的是掉话和未接通为两个不同的概念.未接通的定义是以信令中是否出现连接和连接确认为判定标准.而掉话定义下行是以无线链路计数器超时为判定标准.(SD 掉话一定会产生未接通,未接通不一定是SD 掉话,也可能是TCH 掉话,但是TCH 掉话不一定会产生未接通)图示:常见掉话分类:质差掉话和切换掉话.(设备故障掉话为硬件原因不加讨论) 质差掉话主要是因为覆盖不合理和强干扰引起.其中覆盖不合理包括弱覆盖和覆盖畸形(越区,波导效应等)引起的手机拖死.干扰主要包括网内干扰和往外干扰.网内有同邻频干扰(包括BCCH 和TCH),有来自其他系统干扰,互调干扰等.网外主要是其他无线电发射设备的频率干扰. 切换掉话主要指邻区配置不合理和切换参数设置不合理.邻区配置不合理包括邻区多配,漏配,错配导致不能切换到合理的小区而使得手机拖死. 参数设置不合理包括切换门限不合理,切换层级不合理,T3103设置不合理. 在切换参数中需要特别主要的是层间切换:当触发的是层间切换的时候,不管源小区电平是否比切入小区的强,只要当切入小区的电平值到达它的切换门限便会触发切换(华为算法的16比特排序).切换引起的掉话其中还有一种是由于无线环境突然变差或者硬件(如传输)突发故障,引起的手机不能正确解码消息而导致切换失败也不能回到原来小区的情况.(有时候在信令中会发现手机发了一个切换完成信令然后紧接着会发一个切换失败,这一般都是犹豫无线环境突然恶劣引起的异常现象)以上情况都可能引起掉话实际分析中要结合实地环境综合分析.2012年8月27日 --庞勋。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
路侧过程中未接通现象总结未接通主要是在手机向系统发送呼叫请求，但是在呼叫过程中由于某种原因，主叫或被叫手机没有分配到TCH信道，导致未接通。
路测(DRIVE TEST) 当中考察的一项重要指标, 接通率一直是优化中要应对的一个重要工作.在日常的测试当中, 我们经常遇到各种各样的未接通情况。
原因也是多种多样。
导致未接通的常见的原因主要有：被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH 掉话、呼叫号码错误、CIC分配错误、寻呼失败。
路测过程中L3信令流程：从测试中主叫与被叫的信令流程分析，要完成一个完整的接续过程，一共有以下几步的信令流程：主叫的信令流程：MS BTS说明RACH ChannelrequestAGCH ImmediateassignmentSDCCH CM servicerequestSDCCH CM serviceacceptSDCCH AuthenticrequestSDCCH AuthenticresponseSDCCH CipheringcommandSDCCH CipheringcompleteSDCCH Setup SDCCH Callproceeding SDCCH Assignmentcommand FACCH Assignmentcomplete FACCH CallProgceeding FACCH Alerting FACCH Connect FACCH Connectacknowledge TCH Speech被叫的信令流程MS BTS说明PCH PagingRequestRACH ChannelrequestAGCH ImmediateassignmentSDCCH PagingresponseSDCCH AuthenticrequestSDCCH AuthenticresponseSDCCH CipheringcommandSDCCH CipheringcompleteSDCCH SetupSDCCH CallproceedingSDCCH AssignmentcommandFACCH AssignmentcompleteFACCH ProgressFACCH AlertingFACCH ConnectFACCH ConnectacknowledgeTCH Speech相比多了主叫，被叫在交换机一侧以下几步流程，在无线上多了PAGING 这个流程：E|GMSC -> HLR UDT(BEG(INV(Send Routing Info)))D|HLR -> VLR UDT(BEG(INV(Provide Roaming Number)))D|VLR -> HLR UDT(END(RES-L(Provide Roaming Number))) Roaming NumberE|HLR -> GMSC UDT(END(RES-L(Send Routing Info))) Roaming NumberA|MSC -> BSS UDT(Paging)在路测过程中，L3接续流程和故障判断流程：导致未接通的常见的原因将结合实际情况，根据信令流程，一步一步对未接通的原因进行分析：1. channel request 拒绝channel request 拒绝在路测中很少遇到，如果小区被BAR 的情况下，会出现手机channel request 发送不出的现象。
如下图，在L3 的信息里面不会出现channel request 的信息。
路测中如果主叫手机在一个启动了流量控制的小区发起呼叫，可能不会出现channel request 消息。
根据最新的测试规范，只有channel request和CM SERVICE REQUEST 同时出现时，才计算一次试呼，所以，主叫没有channel request 不会影响接通率。
如果是被叫，则会在小区里收到PAGING 消息，但是建立不了呼叫，造成一次未接通。
值得注意的是在路测过程中，有时会出现连发多次channel request 的情况（连发的次数由小区参数max_retran 决定，大同的max_retran ＝3，表示可以连发7次）。
如果是由于SDCCH 本身时隙的问题或者手机在弱覆盖地带收不到SDCCH，在信令上不会出现IMMEDIATEASSIGNMENT。
2． SDCCH 拥塞对于主被叫，SDCCH拥塞的一个重要标志是信令上出现IMMEDIATE ASSIGNMENT 和IMMEDIATE ASSIGNMENT REJECT 两条信息，如下图：如果是主叫SDCCH 拥塞，用户的感受是电话拨出以后马上退回，没有任何的提示音。
如果是被叫SDCCH 拥塞，主叫一方听到的是“暂时无法接通”的录音通知。
主叫DISCONET 的cause value 是16。
分析现网的数据，SDCCH 拥塞率大的小区，应该通过修改SDCCH 数目来减少SDCCH 拥塞，实际路测当中，碰上的SD CCH拥塞很少。
3． TCH 拥塞对于主叫手机TCH 拥塞的是在SETUP 以后直接DISCOONECT的消息，cause value 是34，显示没有信道资源，用户的感受时在电话拨出以后4－5秒内，听到连续的嘟嘟嘟嘟音。
如果是被叫TCH拥塞，主叫一方听到的是“暂时无法接通”的录音通知。
主叫DISCONET 的cause value :16，被叫的release 的原因也是cause value :34. 应该说，TCH 拥塞是日常路测中发现的主要原因。
4． SDCCH 掉话SDCCH 掉话是在SDCCH 分配以后，到TCH分配之前的掉话。
SDCCH 与无线环境和覆盖有很大的关系。
SDCCH 掉话引起的DISCONET 的cause value 是 TEMP FAILURE。
5． Paging(寻呼消息)在测试过程中，我们多次发现，有的未接通是由于没有paging 消息而造成的（主要根据被叫手机接收到的IMSI 和TMSI 号进行查找，被叫手机只要不做TMSI RELOCATION，它的TMSI号与上一次呼叫一致，而IMSI号是固定的）。
PAGING消息的发送流程如下：E|GMSC -> HLR UDT(BEG(INV(Send Routing Info)))D|HLR -> VLR UDT(BEG(INV(Provide Roaming Number)))D|VLR -> HLR UDT(END(RES-L(Provide Roaming Number))) Roaming NumberE|HLR -> GMSC UDT(END(RES-L(Send Routing Info))) Roaming NumberA|MSC -> BSS UDT(Paging)Paging 消息由交换机产生以后，通过MSC 送到被叫小区的LAC 区所在的BSC, 在由BSC 所在的BTS 通过PCH 进行paging.Paging 消息丢失，有以下几种可能：空中接口，由于PCH 配置不合理造成PAGING 信息的丢失，但是统计数据表明：所有小区的pch_page_q_discrd 的数目都为 0，这表示，在空中接口的PAGING 能力是足够的。
MSC到BSC 到 BTS,从每个小区的统计项page_request_from_msc 来看相同LAC下面的每一个小区的page_request_from_msc 数目基本相同，差异仅仅为万分之一或者十万分之一。
因此，在BSC到BTS 这一段丢失paging的可能性很小。
MSC 到BSC这一段由于受到BSC处理能力的影响，有可能造成paging溢出，一般来说，在PAGING 溢出的小区，在基站的MCUF的swfm 里面有以下的告警：(如何看告警：在bsc内进入3级状态，3stooges 4beatles，set_mmiexec_mon,rlogin 2(站号) 1015h，swmf l a,swmf r a ) Full Mailbox: this and all subsequent messages will be discarded 5d until the mailbox is no longer full. No further notices will be5d given for discarded messages or the full condition.Full Mailbox的告警消息与基站本身的话务没有关系，基站本身的话务不足以使它的MAILBOX 满掉，它主要和收到的PAGING信息有关系。
网络规划合理与否，可以通过检查BSC 的PAGING 溢出是否严重，检查PAGING信息量最大的LAC区下的BSC和BTS 的MAILBOX , 均没有出现溢出的现象，认为是比较合理的网络。
MSC 没有下发paging 消息：需要MSC 配合进行几项统计的对比：要求MSC下发paging 的数目：包括短消息中心，BSC，PSTN 等不同路由的paging 要求。
实际下发的paging 消息数目和BSC一侧收到的paging 消息数目。
6．号码错误在路测中，有时会发现号码错误引起的未接通，在L3信令中release 消息的cause value 为28 ，Invalid number format出现号码错误时，主叫的感受是听到许许多多的杂音，然后听到多来米的声音，并且直接收到下行的release 消息。
没有DISCONNECT 消息。
可能是由于测试卡为VPN 短号码卡的原因或者检查交换机（由于号码的判断和识别属于交换机一侧的功能，建议对交换数据进行检查）。
7．呼叫无应答路测当中，会出现呼叫无应答的现象，Cause value 18: alerting,but no answer. 我们认为这些情况应该从未接通中间扣除，原因是被叫用户可能在进行通话。
建议在测试中使用专用测试卡以避免被叫接听主叫号码以外的电话。
8．协议错误:测试当中，可以看到主叫有时会出现协议错误的diconnect 的消息，一般出现的几率较小，一次全网路测中有1次到2次，causevalue = 111， Protocol error 。
我们认为可能与MSC 到 BSC 之间的电路复位有关(RESET CIRCUIT)，另外，可能与MSC 分配的时隙是一个已经被BLOCKED 的时隙有关，在BSC的SWFM里面，会出现以下的告警：SWFM Log Entry 601cf Nonfatal SWFM Error Routine: cp_messages.c1cf Area: 0x00008000 Error: 0x0000000b PC: 0xc0002c0e PID: 0x40 (SM BSC)1cf BSS Release: 1.6.2.7.0 Obj Version: 1.6.2.7.4 Exec Version: 1.6.2.7.91cf 05-Apr-2004 14:34:24.455 Subsystem: 0x01 CPU: 0x0115 Board: GPROC2 RAM1cf1cf SM Error [0xb]: Old CIC was Not Active1cf detected in file cp_transf.c at line:2871cf > _old_circuit_id = 0x641cf > _old_cic_node->operational_state = 0x01cf SM Error: CP Transfer Failed.在主叫用户一侧，可以听到系统的提示音。