结合层3信令分析路测问题.doc

GSM Um接口第三层RR子层 作者:linjundong 时间:2006-11-11 14:07:25 信令跟踪数据分析： 通过对BSC05 PCM45/46/47/48下16时隙的所有呼叫进行分析发现：BSC收到Assignment Request 20至30ms后向MSC回送Assignment Failure， 问题处理结果： 检查BSC05、MSC A接口电路配置发现：BSC05和BSC53的A接口电路中， 16时隙除了用作信令链路外都不进行配置，而在MSC侧将新增加的8条电路的16时隙配置的TCH信道，导致在MSC指配到16时隙而BSC侧并不识别产生分配失败。 在MSC侧将新增加的8条电路的16时隙锁定后，问题解决。 作者:xlj96009 时间:2006-10-31 18:33:31 在LAC39280下的BSC126进行针对寻呼的测试，该BSC挂接在华为软交换下，测试中发现下列两次异常情况。两次呼叫情况相同，在被叫响应寻呼后，一直到connect都正常进行，可是接下来没有ACKnowledge而直接Disconnect。其中拆链原因为：Switching equipment conqestion (交换设备拥塞)，具体情况如下所示： 时间：12：28：46.25问题描述：Disconnect提示交换设备拥塞 问题分析：如下图所示，在12：28：39.62 MS1 占用小区40361（六团砖场-1）的信号呼叫MS2 ，此时MS2占用小区40363（六团砖场-3）的信号，此时MS1接收电平较高，而MS2 接收电平较差，只有-92dbm，呼叫未正常拆链。 下面从信令流程来看，如下图所示，MS2在收到寻呼消息后，立即申请信道， 接着下行发送Immediate Assigment ,MS2上行寻呼相应paging response. 一直到上行发送Connect都很正常，然而在MS2发送connect 后没有ACKnowledge直接Disconnect，而Disconnect的原因是Switching equipment conqestion (交换设备拥塞) 被叫MS2信令流程如下图所示： 主叫MS1信令流程如下图所示：MS1在完成Assignment Complete之后Alerting接着紧跟着一个切换，然后下行Channel release。Channel release为正常事件。 2. 时间：17：15：04.61 问题描述：Disconnect提示交换设备拥塞 问题分析：如下图所示，MS1 占用小区40133的信号呼叫MS2 ，MS2占用小区40022的信号，接收电平及话音质量良好，呼叫未正常拆链。 作者:linjundong 时间:2006-11-11 13:43:24 信令流程可以看到MSC（SPC=255-5-253）发送UDT格式的MAP_PREPARE_HANDOVER消息后，直接以UDTS格式的同一消息作为应答，并且SCCP层的弹回原因如下： SCCP_RETURN_CAUSE = no translation for an address of such nature (0) 说明该消息在对端交换机（SPC=255-5-248）的SCCP分析过程中存在一定的问题，即对端交换机无法做正确的GT翻译。 可以看到被叫号码的格式为13090953，而SPC=255-5-248相关的GT数据只定义了格式为8613090953，而没有定义不加 86的数据。由此可以看出该问题的根本原因还是数据原因导致的 作者:linjundong 时间:2006-11-11 13:42:20 某地优化工程中发现SPC=255-5-253到SPC=255-5-248无法切换的问题，从信令流程可以看到MSC（SPC=255-5-253）发送UDT格式的MAP_PREPARE_HANDOVER消息后， SCCP_RETURN_CAUSE = no translation for an address of such nature (0) 作者:bluealways 时间:2006-11-1 16:46:59 接上页成功起呼： DL: CONNECT（呼叫成功的标志,） UL: CONNECT ACKNOWLEDGE DL: SYSTEM INFORMATION TYPE 5（5bis，5ter）：邻近小区BCCH频点描述（扩展邻近小区BCCH频点描述）DL: SYSTEM INFORMATION TYPE 6：CI，LAI，小区参数设置UL: MEASUREMENT REPORTDL:Handover CommandDL:Physical InformationUL:Handover Complete(切换成功的标志) DL:Physical InformationDL: SYSTEM INFORMATION TYPE 6UL: MEASUREMENT REPORTDL:Disconnect（收到该条消息或Release中的任何一条，则视为正常释放，如果两条消息均未收到，而是直接收到System Information Type1，则视为一次掉话） UL:Release DL:Release CompleteDL:Channel ReleaseUL:Release Complete 作者:xlj96009 时间:2006-10-31 18:34:31 怎么贴得图都不见了！ 作者:sjzxjs2004 时间:2006-11-1 8:14:13 以下是引用xlj96009在2006-10-31 18:34:31的发言：怎么贴得图都不见了！ 把图作为附件上传吧 作者:cmcc_cmcc 时间:2006-10-28 17:00:41 MS1 Uplink Channel Request MS1 Downlink Immediate Assignment MS1 Uplink CM Service Request MS1 Downlink CM Service Accept SDCCH分配成功 MS1 Uplink Setup MS1 Downlink Call Proceeding MS1 Downlink Assignment Command MS1 Uplink Assignment Complete TCH分配成功 MS2 Uplink Channel Request MS2 Downlink Immediate Assignment MS2 Uplink Paging Response SDCCH分配成功 MS2 Downlink Setup MS2 Uplink Call Confirmed MS2 Downlink Assignment Command MS2 Uplink Assignment Complete TCH分配成功 MS2 Uplink Alerting MS1 Downlink Alerting MS2 Uplink Connect MS2 Downlink Connect Acknowledge MS1 Downlink Connect MS1 Uplink Connect Acknowledge MS1 Uplink Disconnect MS1 Downlink Release MS1 Uplink Release Complete MS2 Downlink Disconnect MS2 Uplink Release MS1 Downlink Channel Release MS2 Downlink Release Complete MS2 Downlink Channel ReleaseMS1&MS2的流程 作者:lyp_swit 时间:2006-10-23 14:49:29 对于L3的信令问题,本人认为重要的不是信令本身而是应该了解这个信令是说明了什么东西.所以最重要的还是需要大家在工作过程中学习呼叫流程以及GPRS等数据业务的信令过程,然后才能够更加准确的分析问题,而不是简单的去认识几个缩写是什么英语单词这么简单. 作者:sjzxjs2004 时间:2006-10-24 20:59:23 以下是引用lyp_swit在2006-10-23 14:49:29的发言：对于L3的信令问题,本人认为重要的不是信令本身而是应该了解这个信令是说明了什么东西.所以最重要的还是需要大家在工作过程中学习呼叫流程以及GPRS等数据业务的信令过程,然后才能够更加准确的分析问题,而不是简单的去认识几个缩写是什么英语单词这么简单. 本议题是结合路测的层三信令,分析实际问题. 目的是通过实际问题,深入理解层三信令. 就是要用理论指导实践,用 实践加深理论. 作者:linxiaolu 时间:2006-10-19 12:18:40 掉话（既没有Disconnect，也没有Release，则视为掉话）： Paging RequestChannel RequestImmediate AssignmentCM Service RequestCM Service AcceptSetupAssignment CommandAssignment CompleteConnect/AlertingSystem Information Type1 通话正常结束(Disconnect和Release都有或只有其中一个都视为通话正常结束)：Paging RequestChannel RequestImmediate AssignmentCM Service RequestCM Service AcceptSetupAssignment CommandAssignment CompleteAlertingDisconnectReleaseRelease CompleteChannel Release 呼叫失败： Paging RequestChannel RequestImmediate AssignmentCM Service RequestSystem Information Type1（在一次呼叫过程中，若连续出现多个CM Service Request，则视为一次呼叫失败） 呼叫成功：Paging RequestChannel RequestImmediate AssignmentCM Service RequestCM Service AcceptSetupAssignment CommandAssignment CompleteConnect/Alerting 切换成功：Handover CommandHandover Complete 切换失败：Handover CommandHandover Failure 作者:songlipo 时间:2006-10-18 17:00:57 一次正常的LAR&RAU信令流程如下：Direction TypeLayer 3 MessageULRRChannel RequestDLRRImmediate AssignmentULMMLocation Updating RequestULRRClassmark ChangeULRRGPRS Suspension RequestDLMMAuthentication RequestULMMAuthentication ResponseDLMMIdentity RequestULMMIdentity ResponeDLMMLocation Updating acceptULMMTMSI Realocation CompleteDLRRChannel ReleaseULGPRS MMRouting Area Update RequestULRRChannel RequestDLRRImmediate AssignmentDLGPRS MMRouting Area Update AcceptULGPRS MMRouting Area Update Complete 作者:lihj 时间:2006-10-12 15:37:31 我觉得这个议题太大了一点，而且复杂的例子也很难贴出来。建议换个小一点的议题！ 作者:sjzxjs2004 时间:2006-10-12 22:45:45 以下是引用lihj在2006-10-12 15:37:31的发言：我觉得这个议题太大了一点，而且复杂的例子也很难贴出来。建议换个小一点的议题！ 这是本板块第一次讨论信令方面的问题. 就先定了个大范围. 以后在具体,详细分析.Thank you for your suggestion 作者:PeterLiu 时间:2006-10-19 14:57:43 我们遇到了一个问题， 在天津进行静态测试， 发现MO呼叫30秒后自动中断，网络发送disc消息給MS，后面进行正常的拆除过程。MT呼叫时，MS可以看到incoming call，连接后显示进入连接状态，但主叫端仍然只能听到提示音，不能进行正常通话。MO过程如下MS netCM req-setup-call proceding-alerting-after 30s-disc-因为connect ack是在FACCH上发送的， 怀疑网络未能收到ack消息， 因为发送connect消息后，网络端将启动一个为期30秒的定时器等待MS的确认，出于某种原因，ack消息未能到达网络， 此定时器超时， 网络进行呼叫释放 作者:yyying 时间:2006-10-12 13:01:19 在DT FTP下载测试中，MS已成功登陆FTP Server，并已经开始下载数据，FTP下载进度为9，在经过一次小区重选后，发现在事件列表中有PDP Deactivated的消息，在层三消息中可以看到是手机发起的上行消息，之后的FTP下载不能继续进行，在一系列的Ping fail后，FTP掉线。层三信令显示如下： Direction Type Layer 3 Message UL GPRS SM Deactivate PDP Context Request DL RR System Information Type 13 UL RR Channel Request DL RR Immediate Assignment DL GPRS SM Deactivate PDP Context Accept发生这种情况可能有3种原因：一是手机在测试过程中电缆的某个接口发生了松动，这样手机可能会发出PDP去激活申请。二是手机本身存在一些问题也可能导致这个问题。三是测试用的笔记本电脑可能存在一些问题 作者:砖头 时间:2006-10-16 11:35:52 MS呼叫失败.经检查信令发现有立即指派拒绝(immediate assignment reject)消息 系统发现无可用信道.很可能是因为系统拥塞引起的 作者:yyying 时间:2006-10-15 12:29:21 某地主要由4173、4081小区覆盖，上述两个小区及相邻小区同属于LAC：13588。DT测试过程中，MS当前服务小区为4173，当检测到有Level 更强的邻区时，BSC指示MS切换（发起DL：HANDOVER COMMAND），此时发生了连续的三次切换失败（UL：HANDOVER FAILURE）。虽然本例中经历了连续三次切换失败，MS仍然没有掉话（MS还在发送测量报告），但是对连续的切换失败应该给予很大的重视。导致连续的切换失败的原因可能是目标小区的TCH信道拥塞，也可能是目标小区的BCCH载频与TCH载频的发射功率没有调平，导致BCCH与TCH的Level值相差很大而造成切换失败。第三层信令消息流程:DL：HANDOVER COMMANDUL：HANDOVER ACCESSUL：HANDOVER COMPLETEUL：MEASUREMENT REPORTUL：HANDOVER FAILUREDL：SYSTEM INFORMATION TYPE 5从切换的两个小区来看，4173向4081切换，是不同步切换，所以BSC应该在MS发出UL：HANDOVER ACCESS消息后，接着发出DL：PHYSICAL INFORMATION，指示MS切换至目标小区的Timing Advance，即MS与切换目标小区的距离。同时，在MS发出UL：HANDOVER COMPLETE之后，再发一条DL：PHYSICAL INFORMATION。在本例中BSC没有发出这两条消息，这也是导致发生切换失败的原因之一。 作者:bluealways 时间:2006-11-1 16:46:12 一次完整的主叫流程（含切换）IDLE： DL: SYSTEM INFORMATION TYPE 1：包括小区信道描述和RACH控制参数DL: SYSTEM INFORMATION TYPE 2（2bis，2ter）：邻小区BCCH频点描述，RACH控制信道，允许的PLMN（扩展邻小区BCCH频点描述+RACH控制信道；扩展邻小区BCCH频点描述2）DL: SYSTEM INFORMATION TYPE 3：CI，LAI，控制信道描述，小区选择，小区选择参数，RACH控制参数DL: SYSTEM INFORMATION TYPE 4：LAI，小区选择参数，RACH控制参数，CBCH信道描述，CBCH移动配置DL: SYSTEM INFORMATION TYPE 7：小区重选参数DL: SYSTEM INFORMATION TYPE 8：小区重选参数UL: Channel requestDL: Immediate assignment（SDCCH）试呼： UL:CM service request（如果后面直接收到System Information Type1，则视为起呼失败） DL: CM service RequestDL: CM service acceptDL: AUTHENTICATION REQUEST UL: AUTHENTICATION RESPONSE DL: CIPHER MODE COMMAND UL: CIPHER MODE COMPLETE DL: TMSI REALLOCATION COMMAND UL: TMSI REALLOCATION COMPLETE UL: SETUPDL: CALL PROCEEDING DL: ASSIGNMENT COMMAND UL: ASSIGNMENT COMPLETE （TCH） DL: ALERTING 接下页 作者:callboy001 时间:2006-10-24 10:22:43 常见Disconnect / Release Cause Value: Cause Value Reason 31 BSS or MSC problem 34(beforeAssignmentCommand) TCH Blocking 34(after Assignment Complete) MSC Blocking 41(after Assignment Command) BSS problem, especially DRI problem 41(after Assignment Complete) MSC problem 42 MSC Congestion 44 BSS problem, especially the CIC blocking 111 BSS or MSC problem 作者:rifly 时间:2006-10-23 14:25:29 某次路测中发现手机每当起呼占用（BCCH：554，BSIC：52，LAC：9488，CI：29403），其只能一直切换到DCS1800网，通话过程中无法测量到GSM900的频点，一直不能向GSM900网切换，在测试时不单该小区自己本身不能测量到GSM900的频点，在本次通话过程中的所涉及的所有小区都不能测量到GSM900的频点，导致在该路段出现弱信号和质差最后导致掉话（虽然在CDD中该小区的MBCCHNO中有GSM900的频点）；但如果测试时，起呼占用的不是本小区，而是由起它小区起呼，再切换到该小区，则在该小区仍然能测量到GSM900的频点。切换正常；说明问题出在该小区。经仔细检查路测试数据的第三层信息，发现在该小区起呼时，第三层信息没有出现 UL-CLASSMARK CHANGE这条信令且在该小区的SYSTEM INFORMATION TYPE3中发现 EARLY SENDING ：EXPLICITY FORBIDDEN，导致系统认为手机为1800单频手机；经检查BSC数据，发现该小区的ECSC 参数设为 NO，其它小区该参数设为 YES。通过调整该参数，问题得到解决。 作者:yyying 时间:2006-10-12 12:57:32 一次正常的LAR&RAU信令流程如下：Direction TypeLayer 3 MessageULRRChannel RequestDLRRImmediate AssignmentULMMLocation Updating RequestULRRClassmark ChangeULRRGPRS Suspension RequestDLMMAuthentication RequestULMMAuthentication ResponseDLMMIdentity RequestULMMIdentity ResponeDLMMLocation Updating acceptULMMTMSI Realocation CompleteDLRRChannel ReleaseULGPRS MMRouting Area Update RequestULRRChannel RequestDLRRImmediate AssignmentDLGPRS MMRouting Area Update AcceptULGPRS MMRouting Area Update Complete 作者:yyying 时间:2006-10-12 12:45:48 某次测试中发现DT测试路段有无覆盖地段，导致MS数据吞吐量变为0，没有与GPRS网络的连接，但是该路段做GSM网络DT测试时并没有发现有无覆盖地段，经过分析，其原因可能是MS执行了一次跨路由区的小区重选（在显示图的信令部分可以明显的看出该MS正在做位置更新）。跟踪当前信令为：DL：SYSTEM INFORMATION TYPE 1UL：LOCATION UPDATING REQUESTUL：CHANNEL REQUEST 作者:capacitor 时间:2006-10-10 20:51:14 哇！上次500，这次一下就升到2500个金币啊！大家赶紧献计献策得金币啊 作者:crazysoda 时间:2006-10-10 11:53:59 位置更新信令消息： DL：CHANNEL RELEASEUL：CHANNEL REQUEST（开始位置更新）DL：IMMEDIATE ASSIGNMENTUL：LOCATION UPDATING REQUESTDL：AUTHENTICATION REQUESTUL：AUTHENTICATION RESPONSEDL：LOCATION UPDATING ACCEPTUL：TMSI REALLOCATION COMPLETEDL：CHANNEL RELEASE结合此例的第三层信令消息来看，例子中MS发出了UL：CM SERVICE REQUEST，并不是UL：LOCATION UPDATING REQUEST，由此可以判断出此例并非是位置更新。由于字节限制，只能简单点。align=rightcolor=#000066此贴子已经被sjzxjs2004于2006-10-10 15:59:34编辑过/color/align 作者:crazysoda 时间:2006-10-10 11:50:45 抛砖引玉！例：MS呼叫未接通：在做DT测试过程中发生了一次未接通，地点是LAC区交接处，在DT测试的行程中，可能发生数次跨LAC区的切换，极易发生掉话或未接通情况。主要有以下三条信令消息：UL：CHANNEL REQUESTDL：IMMEDIATE ASSIGNMENTUL：CM SERVICE REQUEST在上行的CM SERVICE REQUEST信令发出后，没有下行的响应，通话状态由起呼直接转为空闲模式（IDLE），由此可以断定发生了一次未接通。由于上行UL：CM SERVICE REQUEST是MS发起的对SDCCH的申请，发出申请后没有应答，没有出现标志呼叫接通的信令消息，可以断定发生了一次未接通情况。其原因可能为该服务小区的SDCCH信道拥塞，也可能是由于无线环境的恶化造成SDCCH信令丢失。因为此次DT测试发生在跨数个LAC的路段，而且是上一个通话刚刚结束，起初判断可能是发生了一次位置更新。align=rightcolor=#000066此贴子已经被sjzxjs2004于2006-10-10 15:56:40编辑过/color/align 作者:yyying 时间:2006-10-11 10:14:51 以下是引用crazysoda在2006-10-10 11:50:45的发言：抛砖引玉！例：MS呼叫未接通：在做DT测试过程中发生了一次未接通，地点是LAC区交接处，在DT测试的行程中，可能发生数次跨LAC区的切换，极易发生掉话或未接通情况。主要有以下三条信令消息：UL：CHANNEL REQUESTDL：IMMEDIATE ASSIGNMENTUL：CM SERVICE REQUEST在上行的CM SERVICE REQUEST信令发出后，没有下行的响应，通话状态由起呼直接转为空闲模式（IDLE），由此可以断定发生了一次未接通。由于上行UL：CM SERVICE REQUEST是MS发起的对SDCCH的申请，发出申请后没有应答，没有出现标志呼叫接通的信令消息，可以断定发生了一次未接通情况。其原因可能为该服务小区的SDCCH信道拥塞，也可能是由于无线环境的恶化造成SDCCH信令丢失。因为此次DT测试发生在跨数个LAC的路段，而且是上一个通话刚刚结束，起初判断可能是发生了一次位置更新。既然判断不是位置更新，那么是什么原因呢？希望楼主继续分析。15