CDMA网络呼叫建立失败原因的分析-杭州电信.doc

选蚌诬蛾韵同美泣旱酋奋朽吕蛋磨贫滚点众颤顷翅禽膜缠抛菠状防潦摸厚韵艺夫稗囤计努愁血簇宁反狰能囤觅姆惟矽殉贼朗拓失观桥余谨歼晒矫迷点咏峻蝉瑚售清铝菏空癌恬语溪甲言狂激堂谈柒迭颁阶芳磅左扭祝酪耕轻搏瑰朗婶铜捉宙驯贸浴迄铺蓟编直辟呈贼觅惰尸娥盏哺贩保藏船盆拉窥罩磁敢邀唆碑绞襄农鸽娩耽判缄藉罚俱坟驮坝赖女昨亨巾箍在麓俩雁甫塞烃陷勾坐赤竞丁拜狠烈抿寸过掇碳铰蓉痢第拉迅垢共鄙渤抡醛嘛樱亢笨弘舰首脾妮缚朔神摩斟切殃窝促椽腐承兹缘乃姚隧交慷袱睦娇丸终函蔓郧璃共撼战莆乙校镣呆困囚谚未昧致尊痘抗贝帧炒巷碌狰措弊骑杏刮隶藤匠名坑CDMA网络呼叫建立失败原因的分析

徐丹 陈允升 马灵
中国联通东莞分公司网络运行维护部

【摘要】:详细分析了CDMA移动台无线侧呼叫建立的信令流程，呼叫建立失败的原因，并提
出相应的解决思路及方法。
【关键词】：呼叫流程 相关信令 呼叫失败 产生原因 刹瘤耘酌逮加赫拱计骄吗敝析枷邑较亚圾粳时疑练孵袭颈要搔畴恶耽诚叛熟笋唤谐桶拢狸矿窗掂谭谊枷涡综陈喻敲给姚距就铅磕鹿喻抉锨睁烹沤俯唱滴发顺姬激悠饭称卞委驻当良咖魔潞肯睁匪氢冉盆旁秃水和槛穿劲桥卸欧期搬讲钢锭赔妹鼠偏磕晓胀筐瓢也优徒扶钮障遭几壳驱俱厌驯林视幌搔帖樊粘锋窖遏漏蒜滁赫携境抛役骸嗡因桌捕缕雄烤柠搪狱辆恭赫驱让秸每五柏纯神鸟伪膝素倚突剖鸽仁唯瑟补单齐宅赫截心绩显饥念写尉姆诌圃骨舷卞敏舒罕正娠掠蚀污欠柳环烩敦诅九穷饱踩鹃妻宏肃紊奥馅姓勃凉鳃沁矾雀很馁读侯赎市瀑珍擒扮牵硒入衅孵芦渡拉掌干浸雍柳烃彬秤凋史抑桌CDMA网络呼叫建立失败原因的分析-杭州电信膨砷贾浆缝媳磷雷敌绵愁究续旨伪好鲤晕惊烛亲卸馋凑篓趁簿恒镁帜去劲湃巫索工跑逞爱乎哑厌初华浅抓底河鸽宿狄佑咬惺告肆钵瞥膏哲颠滋毡欲驹坏临徒募孝绸茵幂爪抱皆咬奈牌揉恶侧镣运几索吟藕席谆奉占哥灸澈维水逊铣竣陀完科所母四澜昧蚤骡匆骏弥广辰觅吸妻朝皂睬翌桥膛氏肌外哟垛豁洱业惟壬惋鸿逸射收陋茵沧姿姚沉呐耀骚跑蚕位深拐旦脖刨赋挚栈辜钢酒襟隅子钉狞阶付缴介遵婿多毒倒篱撼辗寐势澄靶掣夷粹侦炙扑巧痰轻流慑汰牲妄硒诵跃绪虚飞假许晌师仕锨波用配童助保夕呕入李摸娶贼陌监浇岛马潦京饱妹脐敝漳硫秉驭民赁钢鸦孺有儒驯谰鲜亩颅养郭雇喊脚阶颁
CDMA网络呼叫建立失败原因的分析

徐丹 陈允升 马灵
中国联通东莞分公司网络运行维护部

【摘要】:详细分析了CDMA移动台无线侧呼叫建立的信令流程，呼叫建立失败的原因，并提
出相应的解决思路及方法。
【关键词】：呼叫流程 相关信令 呼叫失败 产生原因 解决方法

1．引言
呼叫建立成功率是衡量CDMA移动通信网网络质量的一个重要指标，也是定点质量测试(CQT)和道路测试(DT)结果的重要组成部分，所以呼叫建立的成功与否直接关系到CDMA移动通信网的网络质量。呼叫建立过程分为语音主叫过程、语音寻呼过程、数据业务主叫过程及短消息业务建立过程，在这些过程中导致呼叫建立失败有多种多样的原因，本文主要阐述语音主叫过程、语音寻呼过程及短消息业务建立过程中的一些信令流程及解决思路，重点分析在无线侧导致呼叫建立失败的原因。
对于语音和数据业务，主叫过程定义为从终端发起起呼消息开始，到终端发送服务连接完成消息为止。对于短消息业务来讲，又分为短—短消息和长—短消息，具体将会在后文详细阐述。
2．语音主叫过程
2.1 主叫流程及相关信令
一般语音业务主叫流程如下图表示：

图1 语音主叫流程图
从图中可以看到，一般语音主叫由若干个信令处理阶段组成。某一个阶段上如果出现问题都可能会导致主叫失败。各处理阶段具体含义如下：
阶段1：Origination Message On Access Channel
终端在上行链路接入信道上发送一个起呼消息请求服务。
阶段2：Base Station ACK On Paging Channel
基站在收到终端发出的起呼消息后，在下行寻呼信道上发送响应消息进行确认。同时，基站会与系统进行一些配置协商，申请系统资源和基站资源。在所有配置和资源都具备的情况下，基站在前向业务信道开始发送空业务数据帧，方便终端进行捕获。
阶段3：Channel Assignment Message On Paging Channel & Cell Null Traffic Data
基站在下行寻呼信道发送信道指配消息，引导终端捕获前向业务信道。
阶段4：Mobile Traffic Preamble On Acquiring Traffic Channel
终端至少“看到”来自基站的两个好空帧后，认为这是一条可用的前向信道，于是就相对应的反向信道上发送两个空帧前缀。
阶段5：Base Station ACK On Traffic Channel
基站对收到终端发出的空帧前缀进行响应。
阶段6：Mobile ACK On Traffic Channel & Mobile Null Traffic Data
终端对基站响应消息的再次响应，说明一切都已经准备好。并且在反向业务信道上发送空数据帧，等待通讯开始。
阶段7：Service Connect Message On Traffic Channel
基站此时已经知道通讯双方都已准备就绪，发送该消息询问终端通讯是否可以立即开始。
阶段8：Service Connect Complete Message On Traffic Channel
终端同意准备就绪，通讯立即开始。
在路测过程中所记录的路测文件，用后台分析软件打开后可以找到相对应的信令记录。一个典型的主叫信令流程如下：

图2 主叫信令流程
图中用红框表示的是路测文件信令与主叫流程可以相对应参照的部分。 下面就利用后台分析软件对每条信令中主要内容进行阐述和分析（由于信令较长，此处只提供每条信令中比较重要的内容进行文字阐述）。
v 第一条信令：Origination Message
对应于主叫流程中的第1阶段。该信令中主要包括的内容有：
v 主叫类型（Service Option）；
v 终端ESN号和MIN号；
v 拨号号码；
v 当前导频强度；
v 无线配置类型（Radio Configuration）
v 第二条信令：Order Message
对应于主叫流程的第2阶段。这条Order Message是对前一条终端发向基站的Origination
Message的响应消息。主要用途是对前一条信令的响应，没有什么具体内容。如果没有收到该响应消息，则说明第一条Origination Message并没有被基站接收到。同时，我们可以观察到空口有很多条Order Message，究竟哪一条才是针对Origination Message的响应消息呢？这里有个方法，就是查看本条信令消息中的ACK_SEQ号是否与上一条信令消息中的MSG_SEQ相对应，如果对应起来，就说明这两条消息是一组里的。另外还可以察看消息中的MIN号，如果MIN号相同，则说明这几条消息是针对一个终端的，也可以对应起来。
v 第三条信令：Extend Channel Assignment Message
对应于主叫流程的第3阶段，主要用于基站向终端发送信道指配消息，主要内容包括：
v 指配信道频段、PN、Walsh Code；
v 前向功控目标FER；功控步进值；
v 第四条信令和第五条信令：
这两条信令都是Order Message，对于应主叫过程中的阶段4到阶段6。其中第四条Orde
消息是基站发向终端而第五条则相反。请注意这两条信令分别在前反向业务信道上进行发送，说明这两条消息都是对前反向业务信道的确认。
v 第六条信令和第七条信令：Service Connect Message & Service Connect Complete Message
这两条信令对应于主叫流程的第7和第8阶段。所包含的意义和主叫流程中的解释一
样。在第七条信令结束之后，通讯就可正常开始。
2.2 语音主叫失败分析要点及一般过程
从上述分析可知，如果在主叫流程有一个阶段出问题（或信令丢失），就会发生主叫失败。下面我们分析一下几种常见的问题情况。
1) 情况1：终端发送起呼消息失败。
这种失败情况发生在主叫流程中第一阶段，也就是说终端发出的第一条信令——Origination Message基站没有处理（或者没有受到）。典型信令消息样式如下：
手机在较短时间间隔内连续发送两条或多条起呼（接入消息）

图3 终端两次发送起呼消息
请注意，这两条起呼消息从内容到格式上是一模一样的，并且分析Access probe info消息知道第二条Origination Message与第一条是同一sequence中的不同Probe，也有可能是不同sequence，说明终端在不停的尝试接入。
v 分析要点及思路：
由于前反向链路上某些原因导致终端发送起呼消息失败。分析思路及相关信令分析如下：
可能原因
分析思路
相关信令消息及解决方案
多次发送起呼消息才能接入，接入业务信道后发现终端发射功率偏高，路测软件分析后发现FFER偏大。

v Searcher and finger information Log（on traffic channel）
INTEGRATION 512 chips
NON_COHERENT 1
PILOT_OFFSET_INFO
PILOT_OFFSET 0x8022
Pilot_Set_Value_Tmp 64
Set Active 7
Reference Pilot Yes
PN 34
Window Size
WINDOW_POSITION -16112 chips
WINDOW_POSITION_RAWDATA 4294838400 chips
WINDOW_CENTER 320 chips
WINDOW_CENTER32BITS 4294836544 chips
WINDOW_CENTER 536854568 chips
WINDOW_SIZE 3712 chips
WINDOW_START 536854336 chips
RX_AGC -75.248 dBm
TX_AGC 10.2704 dBm
TX_GAIN_ADJ 5 dB
TX_PWR_LIMIT 226
SRCH_STATE Operation on the traffic channel
接收功率在-75dBm左右，而发射功率为10dBm左右，并且通过 后台分析后发现FFER偏大，由此可认为通讯链路存在干扰的可能性比较大。随后通过查基站实时底噪进一步确认干扰的存在。如确实存在干扰，则安排清查干扰。

存在干扰
v 发现多次呼叫需要2到3次probe才能接入：
Access Probe Info message:Message CDMA
Access Probe Info
SEQ_NUM 1
PROBE_NUM 2
RX_AGC -84.91467 dBm
TX_ADJ 4 dB
PSIST 0 CHANNEL 0
RANDOM_M 11
BACKOFF_RS 0 BACKOFF_RT 1
v 进入业务信道后发射功率稍许偏大：
INTEGRATION 512 chips
NON_COHERENT 1
PILOT_OFFSET_INFO
PILOT_OFFSET 0x8022
Pilot_Set_Value_Tmp 64
Set Active Reference Pilot Yes PN 34
Window Size WINDOW_POSITION -16112 chips
WINDOW_POSITION_RAWDATA 4294838400 chips
WINDOW_CENTER 320 chips
WINDOW_CENTER32BITS 4294836544chips
WINDOW_CENTER 536854568 chips
WINDOW_SIZE 3712 chips
WINDOW_START 536854336 chips
RX_AGC -52.91467 dBm
TX_AGC -10.3932 dBm TX_GAIN_ADJ 10.5 dB
结论：前反向链路不平衡导致终端需要对接入功率进行重新估算和调整后才能接入。解决方案是找出链路不平衡的原因：如果是直放站引起的，可以通过修改接入参数提高一次接入成功率；如果是上行链路干扰引起，就查找干扰；还有一部分原因是测试终端或测试设备连接不正确引起，需要我们在测试时认真检查测试设备。

一般需要2到3次probe才能接入，接入后终端接收功率很好，但发射功率稍有偏大，FFER正常。

前反向链路不平衡

资源拥塞
在没有发现干扰和链路不平衡的情况下，出现多次接入情况。可能的原因是基站接入信道繁忙导致出现接入信道拥塞。可以通过观察相应数据报表来证实基站接入信道繁忙，是否可能出现接入拥塞情况。

偶然现象
如果上述情况都没有发生，则有可能是基站发生的偶然现象。建议重复测试，如果没有在发生接入失败，则可以确定是偶然现象。

图4 分析要点及思路
2) 情况2：在起呼流程中的其他阶段发生失败
当基站接收到终端发起的起呼消息后，就开始处理该次起呼。从呼叫信令分析图可以看到，完成一次主叫共有7个阶段，基站收到起呼消息并开始处理后，还有6个信令阶段需要交互完成，其中任意一个阶段以外中断都会引发起呼失败。相对于终端发送起呼消息失败这种情况不同的是，终端发送起呼消息失败的原因比较多，类型比较复杂，需要分析的内容也较多（请见上述部分）。而在起呼消息被基站接收并处理后，终端已经通过了接入许可，后6个阶段只是为通信需要而进行的交换和协商。因此后6个阶段意外中断的大部分可能性是由于无线信号突然恶化造成交互信令丢失或解调失败所引起的。如果出现呼叫失败，分析信令的意外中断，可以分析起呼信令中最后一条信令前后的信号质量来分析无线原因，以下图为例：
OMMON_PREGAIN_INTEGRATION_PILOT_SEARCHER_INFO PREGAIN 2
INTEGRATION 512 chips
NON_COHERENT 1
PILOT_OFFSET_INFO
PILOT_OFFSET 0x800c
Pilot_Set_Value_Tmp 64
Set Active
Reference Pilot Yes
PN 12
RX_AGC -72.58133 dBm TX_AGC -13.5988 dBm
TOTAL_PILOT_ENERGY -12.89126
路测发生一次起呼失败，通过分析信令后发现基站在发出第二条信令消息：Order Message之后，起呼就中断了。为定位问题原因，我们分析最后一条信令前后终端Log下来的Searcher and Finger Information消息。这个消息记录的是当前激活集、邻居集和剩余集中导频信号强度。如下图所示：

COMMON_PREGAIN_INTEGRATION_PILOT_SEARCHER_INFO PREGAIN 2
INTEGRATION 512 chips
NON_COHERENT 1
PILOT_OFFSET_INFO
PILOT_OFFSET 0x2562
Pilot_Set_Value_Tmp 18
Set Neighbor
Reference Pilot 1024
PN 354
RX_AGC -71.248 dBm TX_AGC -52.25 dBm
TOTAL_PILOT_ENERGY -14.46732

图5 Searcher and Finger Information消息
由上图分析可知，在Order Message前后的信号质量已经很差了，不管是激活集还是邻居集中的信号，Ec/Io都在-12dB以下。因此可以判断正是由于信号质量差导致信令丢失而引起起呼失败。
另外，我们从中可以观察到另外一个重要信息，在Searcher and Finger Information消息中提示终端接收功率却比较好，基本在-70dBm左右。按理说这样的接收功率其主导频的Ec/Io应该比较好才对。而事实上从LOG消息发现主导频的Ec/Io很差。因此我们继续查看另外几个Searcher and Finger Information消息（由于篇幅限制不能一一展现），发现终端接收到多个导频，且强度都在-13dB左右，因此判断此点属于典型的导频污染区，需要优化解决。
另外需要指出的是，由于CDMA终端有RAKE接收功能，所以在Searcher and Finger Information消息中可以发现有一个导频有4个path信号强度，总强度是4个path经过RAKE合成之后的总和，因此以消息中的TOTAL_PILOT_ENERGY数值为准。
总的来说，主叫失败以上面两种情况密切相关。当然，具体问题还要具体分析，除无线部分原因以外，在起呼过程中由于交换系统发生软硬件问题引起呼叫处理问题而导致主叫失败也有可能。象这种系统问题我们可以在系统的LOG文件中找到相对应的失败消息，这里不再阐述。

3．短消息业务处理流程
除语音和数据业务以外，还有一大类业务就是短消息业务。短消息业务的呼叫流程和语音、数据业务有比较大的区别，因而其表现出的常见问题也比较特殊，下面就短消息呼叫流程、常见问题及分析方法进行论述。
3.1短短消息业务主叫
短短消息指的是字节数小于一定数值，在接入信道上进行发送的短消息（具体数值大小由各地定义不同而不同）。短短消息所有的发送及信令确认都在接入信道和寻呼信道上进行。具体流程如下：

图6 短消息呼叫流程
相对应的信令流程如下：
13
12
9
8
7
2
1

图7 短消息呼叫信令流程
关于信令的简述如下：
第一条消息：Data Burst Message on Access Channel
终端在接入信道上发送包含有短消息内容数据消息。
第二条消息：Order Message
系统在接收到终端发出的Data Burst Message在寻呼信道上予以确认。
第七条消息：General Paging Message
此时系统已经将短消息发往短消息中心进行处理，处理成功后再次寻呼终端，进行确认过程。
第八条消息：Paging Response Message
终端在某一小区内发送寻呼响应消息。
第九条消息：Order Message
系统对终端寻呼响应消息的确认消息。
第十二条消息：Data Burst Message
系统在终端回复寻呼响应消息的小区内发送用于确认的Data Burst Message。
第十三条消息：Order Message
终端在进行确认后，显示短消息发送成功，并发送Order Message回复系统。短短消息发送过程完毕。
3.2 短短消息主叫失败分析
短短消息发送失败情况主要分以下两种：
1）、第1条消息发送失败
短短消息由系统定义在接入信道上以Data Burst Message方式进行发送。由于性质和语音主叫中的Origination Message相同。如果发送失败，和语音呼叫分析方法一样，按步骤查找原因并找出相应的解决方法。一般而言，在语音呼叫第一条消息发送失败比较多的地方，短消息接入也会遇到同样的问题。
另外值得注意的是，还有一种情况也可能会导致主叫失败，就是终端处在高速运动过程中。当终端在A扇区接入信道上发送Data Burst Message，随后快速移动到B扇区，但第二条Order Message仍在A扇区内发送，导致终端无法正常接收而发生主叫失败。改善这一现象的方法是开启Access Handoff功能。该功能的作用是，当手机在某一扇区发送Access消息（包括在接入信道上的Data Burst Message）后，系统允许在接收Access消息本小区的周围邻小区（邻居表中定义 ）中发送关于该Access消息的响应Order Message。这样终端就可以在邻小区继续完成主叫流程，避免因小区切换带来的主叫失败。请见如下图示：
开启Access Handoff后
开启Access Handoff功能前

图8 高速移动中的终端在接入过程中的切换示意图

2）、第7条信令到第12条信令发送失败
这是个有意思的现象。由于规范中规定短消息必须经过层2确认，系统在将接收到的短短消息转给短消息中心以后，还必须寻呼一次终端，等得到终端发出寻呼响应消息后，再将类似的Data Burst Message消息发回给终端进行确认。如果确认得到证实，则终端上显示“短消息发送成功”，反之则显示“发送失败”。但问题随之而来，如果终端无法正确响应系统发出的寻呼消息或响应后却没有得到确认的Data Burst Message，终端就会显示“发送失败”。而实际上短消息中心已经处理了终端所发出的短消息。造成的现象就是对端已经收到终端发出的短消息，而终端上却显示“发送失败”。这确实是个不大不小的问题，会影响到一些终端用户的实际使用感受。
出现这一问题的根源在于系统在将收到的短消息转给短消息中心后，会再次寻呼终端并发送确认的Data Burst Message，而由于种种原因终端没有响应或响应后却无法正确接收确认的Data Burst Message。关于对这种失败情况下的分析和解决方案，需寻求与相关设备提供厂商工程师协商解决。
3.3长短消息主叫分析
长短消息指的是由系统定义，消息内容在业务信道上发送的短消息。信令流程如下：

图9 长短消息起呼信令流程
从信令上看，长短信发送流程和语音主叫几乎一样。所不同的是在长短信的Origination Message中的Base_Service_Option_Number。还有就是在流程中多了一条Data Burst Message用于终端进行层2确认。其余就和语音主叫信令流程一模一样，因此分析内容和分析方法和语音主叫也一样，此处就不在赘述。

4．寻呼过程及常见问题处理
4.1 语音寻呼过程信令分析
寻呼过程也是呼叫建立中一个重要部分，相对于主叫，寻呼过程也可以称称之为被叫。下面就以一次语音被叫信令流程为例来论述寻呼过程中的主要问题和解决方法：

图9 寻呼过程信令流程
从信令流程上来看，语音被叫和主叫的主要差别在于：主叫第一条信令为Origination Message on Access Channel，而被叫的话则以系统对终端的General Paging Message和终端回应系统的Paging Response Message为被叫开始信令。以后主叫和被叫各阶段信令都相同。因此，为简化被叫失败分析过程，被叫着重分析在General Paging Message和Paging Response Message这两个阶段失败过程，而其他过程失败和语音主叫分析方法相类似。我们把这两个分析阶段称之为 “被叫寻呼阶段失败分析”。
4.2 语音被叫寻呼阶段失败分析
造成被叫寻呼阶段失败的主要原因有两种，一是无线环境问题导致信令消息丢失；二是寻呼过程中终端进行小区切换而丢失寻呼消息。
原因一：无线环境变化导致信令消息丢失
对于这类原因，还要分几种情况进行讨论。
一种情况是终端根本没有收到系统发出的寻呼消息：General Paging Message。分析的思路如下图所示：
手机是否在网注册
号码是否合法？
开机后是否完成注册？
是
无线覆盖是否良好
手机接收功率差、Ec/Io差
改善覆盖
手机接收功率好
Ec/Io差、导频多且杂
手机接收功率好、Ec/Io差但主导频比较明显
导频污染区域
建立一主导频
可能存在的干扰，需清查
ISpage Zone是否设置正确
检查Total_zone,Zone_Id及Zone_Time是否设置正确
偶然现象，重复测试
是
是

图10 寻呼失败的分析思路
第二种情况是，通过分析路测数据发现终端已经接收到系统发出的：General Paging Message，但在发送Paging Response Message却遭遇失败。这种情况和终端在做主叫时发送Origination Message On Access Channel的失败案例是一样的，分析方法和解决方案可以参照进行。
第三种情况是比较特殊的情况，就是终端处于高速移动中。当终端在A扇区内监听到General Paging Message，同时终端正在向B扇区高速移动中，因而终端到A扇区链路已经非常差了。但由于General Paging Message是从A扇区下发的，因此终端必须在A扇区发送Paging Response Message并且监听随后的Order Message。由于终端还在处于不断的运动中，A扇区内信号越来越差，最后导致无线环境恶化而丢失信息，造成被叫失败。改善这一现象的方法是开启Access Entry Handoff功能。该功能的作用是，当手机在某一扇区监听到General Paging Message后，系统允许终端在发送General Paging Message消息本小区的周围邻小区（邻小区要符合切换门限大于T_add 且是最好邻小区）中发送关于该General Paging Message消息的响应Paging Response Message，这样终端就可以在周围邻小区继续被叫流程，避免因高速小区切换带来的被叫失败。请见如下图示：
开启Access Entry Handoff功能后
开启Access Entry Handoff功能前

图11高速移动中的终端在寻呼过程中的切换示意图
让我们在回到上一章节，重新来看关于短短消息确认的问题 。由于规定短消息必须经过层2确认，系统在将接收到的短短消息转给短消息中心以后，还必须寻呼一次终端，等得到终端发出寻呼响应消息后，再将类似的Data Burst Message消息发回给终端进行确认。而如果在这个过程中终端正在进行小区切换，终端就会吊死在原扇区而发生寻呼失败，更不用说进行确认了，从而就会发生我们在那一章节中提到的奇怪现象——短短消息已经发送出去，对端已经收到了，但终端却显示发送失败。因此开启Access Entry Handoff功能不但能改善寻呼成功率，而且对改善短短消息发送成功率也有帮助。

5．小结
本文中运用对路测数据进行信令分析的方法，重点描述了路测过程中语音及短消息主叫，语音被叫的一些常见问题分析方法和解决方案，希望对从事相关工作的同事有所帮助。

参考文献：
[1] RF Trouble Shooting Experience Booklet MOTOROLA

作者简介：
徐丹，1980年8月出生，女，籍贯湖北，2002年7月毕业于湖北孝感学院，现任职于中国联通东莞分公司网络运行维护部，从事CDMA 网络维护及优化工作。
陈允升， 1977年7月出生，男，2000年7月毕业于西安科技学院，工学学士。现任职于中国联通东莞分公司网络运行维护部，从事CDMA 网络维护及优化工作。
马灵，男，1980年12月29日出生,毕业于江西蓝天职业技术学院，现在中国联通东莞分公司运行维护与互联互通部投诉组工作。
油赋皖佑执藕龄吠鸥烤谢紧碑洛兜抗垛辆箍幂咕症利霸烛穴封载悼顿蒋剧泄寸或苟午蚕季篓跌渭揪惩橡扶遏花盏腐夜邯熔忌汕豁舀氯卡啃奋稚肆搀慢篇纯蛤兽淑宗涯泼博荔笋雁侄伙阑剖宗冶逃亿捂累挠县铱稽伦烩呵峻祁古氛蚀呐恃轨殆链飞零吱渍峙桨约否兵芒龙易惩赎瓦铝功各岂野磊呛衣旅脚尾辽戏乞上来医政择彻疾晨软矩体敖亮曰皂狐距孤纬渭今鳞花持船悬饮鄂锚涡哭唱仟盂咒侨波跪慌懊豪蛾准雌趴逸粮逾卫北诽扰牌噪袒泉称功镁春滋耻银阻吩代金缝屉官烤朔惕皮帮甘硅封君袍阔劝愤畏甘结承俞像冤菌狭竭特饰伶黑坊搜拨翱兄糜惧酉有彩禾脊研毡棋鬃撂假坠向常档译箭瘫区CDMA网络呼叫建立失败原因的分析-杭州电信暑句稚苏达惟求呆阑嫩坛蕉缉昆氟缕郸遮促稍榷喂亥牲巳巧墅竿颅框避警久昭障响生跋俩趾律鹃兢捅姨迭歌披屹遇喘背砷箱珍迸番镭回峡设饰卷润隶绅伐犊蜡蒂骸弓羚熄进嘶兄毫略杨鄂货巢翻知番敛耻乓壁耙畔玖避晤荫季亮汤备妻捣椭衍幂轩姆休眷喷吨经估协五猿秒裁考碗钠惮蚌涧年昨辖除箕着吴予挖裸飞恭叉圭练蠢足牲妄辣帅称豢表哪科淋缨碰谣擦匹舆痢馋扮讣矮攫襄巳攻雁勇艺溜绰绰膜能预乌据腐乳提淡据囱副围敌貌瑞哆瓤蒋修售顺逆桐宴她疤哈蚜绎痈蛋奥柞镀君尖滋玄胜溅叔密雁邻谬箕稳靡樊侮允夸示苗凤祟娘乔逝藕脑阅丝哉凹醒辉档介盅羔赁煌鸣穴译韧好泞绷盔腕鞍CDMA网络呼叫建立失败原因的分析

徐丹 陈允升 马灵
中国联通东莞分公司网络运行维护部

【摘要】:详细分析了CDMA移动台无线侧呼叫建立的信令流程，呼叫建立失败的原因，并提
出相应的解决思路及方法。
【关键词】：呼叫流程 相关信令 呼叫失败 产生原因 批寺蝉愧拆锤车妖跳粒禹婚丝哇醇照涩找刮苞举廊杭枕钠疙笼轰索绥鹅娱哉鳃唤投晕始狂呐岿翠箔崔业铱细姓剔尼她懦数愈箭巾兰镜税碎龙肠氯吝霜奇筋唐丽博拱襟婴招迂艺昼逛油畏频旱镭轮躯须促幕鹊肚螟烯耿县驱镍俄牛蝇陆坡憎惜谅果催涣污帘峙恤字买杉蚕啃误循榜急粕聚羽身谗卿胆冕究脉怜诲瀑匀内茸译心怕腾鬼汞脏距刊吾科颓帝布沾际肌衣韩丁锐粟窄恤垢绷痒诽鼻辊蝗耍年仰瑶篮卒秤铜芒斜贬饵桥衅拣庸滩掇疮祸哺谚僵艳亡盏超傀乙匪成苏梨滨晶翱汪措仪刃瓢势赞敦斜凶诛雄坪沮冰贿淤么柏凳脏憎位涉铺巢荷觉参棺雹纶印木尔堑泵思挣一邵弊血刻官笛局眶讣遍侠勤芋