1、EFLAG 济南 TD 项目组外场未接通事件处理经验总结济南移动 TD网络Sniper225LYL2010-11-29如何处理好平时路测中的未接通问题，是我们日常优化中一直关注的重点，本文将就济南 TD网络外场日常优化、测试过程中遇到的各类典型未接通案例进行分析归类，并总结相应的优化经验和手段1目 录概 述 .2一、 未接通基本分析 .21 导致未接通事件的原因分类 .22 未接通事件分析流程简述 .33 不同类型未接通基本描述及分析 3二、 典型案例 .81覆盖问题导致的未接通 .82干扰导致的未接通 123参数问题导致的未接通 .154终端/ 软件问题导致的未接通 .185站点/ 核心网问
2、题导致的未接通 .286位置区规划不合理 33三、 经验总结 .382概 述在日常的外场 DT 中，我们经常会遇到各种原因导致的未接通事件，而接通率不但与集团考核成绩息息相关，与用户实际使用感受也有密切的关系，因此如何处理好平时路测中的未接通问题，是我们日常优化中一直关注的重点，本文将就济南 TD 网络日常优化过程中遇到的各类典型未接通案例进行分析归类，并总结相应的优化经验和手段。一、 未接通基本分析1 导致未接通事件的原因分类目前我们在测试中经常遇到各种不同原因导致的未接通事件，我们根据原因的种类对未接通事件做了简单的分类如下：（1） 覆盖问题导致的未接通；（2） 干扰导致的未接通；（3）
3、参数问题导致的未接通；（4） 终端/软件问题导致的未接通；（5） 站点/核心网问题导致的未接通；（6） 位置区规划不合理；（7） 容量问题导致的未接通；以上是我们平时在日常拉网测试、CQT 测试时遇到未接通事件的主要原因，但在实际分析过程中，我们会发现每种原因之间均存在不同程度的联系，以覆盖问题为例，在覆盖重叠较为严重的区域容易形成到频污染，而到频污染区域的干扰通常会比较严重；又比如参数问题，当相邻小区的功率或者重选参数配置不合理时，在未接通事件点表象上会体现出较为严重的干扰或者弱覆盖（重选参数设置不合理，导致 UE 拖死） ，因此我们在实际的分析处理过程中应当充分利用所有信息，包括各种无线信
4、号质量测量值、前台测试软件信令、后台 CT、小区后台各类指标等，通过对各种信息的综合考量得出最准确的判断，并指定最高效的优化方案。32 未接通事件分析流程简述我们通过平时对各类未接通事件的处理，积累了大量的分析优化经验，特别是当拿到一个未接通事件时，从何着手进行分析，如何利用测试数据提供的信息，后台指标又可以提供哪些判断依据等，我们总结了基本的分析判断流程主要分为 4 步，其中多数未接通事件通过前两步的工作即可得到结果，但对于现象较为异常的事件，我们还需要进行随后的两步工作，以前后台结合，无线参数测量值与信令分析、参数检查相配合等综合手段进行分析判断，并最终的出准确的事件原因与高效合理的优化方
5、案，具体流程如下：3 不同类型未接通基本描述及分析对于各种不同类型的未接通问题，我们在上文已经提到其之间大多存在着关联，并且通常情况下一个未接通事件的发生是由多个原因共同作用所导致的，因此我们在对每种未接通现象进行描述时，大家需要联系其他类型的原因及优化方案综合分析。（ 1） 覆盖问题导致的未接通； 弱覆盖导致的未接通，在现象上主要表现为无线信号质量主要是 PCCPCH RSCP 值较低，并且在邻区表中也没有 PCCPCH RSCP 值更好的小区，此时 UE_Txpower 通常也会升高。4对于这种现象我们首先应该查看服务小区是否存在越区孤岛、以及邻区漏配情况，如果没有才能说这是弱覆盖区域，由
6、于覆盖是保证网络服务的基础能力，所以添加新站点事解决此类未接通的最有效方案，但往往由于周期较长因此我们处理提出新站需求外，还要对附近的小区进行功率的抬升，或者天线方位角、方向角的调整。另外一种手段是增加小区 FPACH 信道、PRACH 信道的发射功率，以及上/下行干扰余量，从功率的角度对问题进行优化。 重叠覆盖导致的未接通，通常情况下在重叠覆盖而没有主导小区进行覆盖的区域，会发生频繁的重选，在位置区边界则会造成频繁的位置区更新，导致被叫收到寻呼消息的概率大大下降，对于这种情况我们主要通过控制覆盖，使问题区域由一个较强的主导小区单独进行覆盖，主要采用天线调整的手段进行整改，另外可以有条件的结合
7、重选、功率参数等，也可以使终端在重叠区域稳定占用某个小区。 越区覆盖导致的未接通，其在现象上与弱覆盖问题产生的事件较为相似都表现为服务小区及邻区表小区 PCCPCH RSCP 值较低，但最主要的区别在于，越区覆盖的小区其邻区表中的各个小区均距离问题路段较远，且距离问题路段较近的小区没有出现在邻区列表中（如使用 DX188 手机进行测试，则直接可以通过邻区表判断是否存在邻区漏配，因为该型号手机有邻区测量功能，即使与周边小区没有配置邻区关系仍然可以进行测量） ，而弱覆盖区域中我们可以发现，即使覆盖问题路段的小区均出现在邻区表中，但其 PCCPCH RSCP 值都很低。解决越区覆盖的有效手段即对天线
8、下倾角进行优化，当遇到天线调整困难时，比如：美化天线、上不了天面等，我们还可以临时采取功率调整的手段进行覆盖控制，另外还要对其邻区配置做合理添加，尽量避免在覆盖没有得到完全控制前出现孤岛的概率。（ 2） 干扰导致的未接通 UP 干扰导致的未接通，当 UP 时隙存在干扰时会导致终端的 RRC 连接成功率严重下降， 从发生接入困难，UP 时隙的干扰理论上均是来自其他小区的 DWPCH 信道的上下行时隙交叉干扰，导致这种干扰的主要原因是由于远处小区的 DWPCH 信道由于传输时延落在了问题小区的 UPPCH 信道上，另外当某小区存在故障时，也可能会导致其周边小区的UP 干扰集体上升。通常解决 UP
9、干扰的方法是修改 UP 偏移，在默认设置下，可以将 UP偏移由目前的 POS16 修改为 POS53，这样就可以将 UPPCH 信道落在 TS1 的末端，同时我们需要修改 PRACH 信道及 SICH 信道的配置，在 UpPCH 移到 TS1 或 TS2 上之前，必须把PRACH 信道和 HS-SICH 信道先移到 TS2 或 TS3 上，因为 PRACH 信道、SICH 信道与 UPPCH5信道不能共时隙。当我们检查各个 POS 位的干扰时，如果发现 TS1 由于干扰过高已经不能满足优化效果时，可以尝试修改频点或者进一步做 UP 偏移至 70。 同频干扰导致的未接通，由于与 RRC 过程相关
10、的 FPACH 信道、PCH 信道、FACH 信道均配置在主频点的 TS0，因此当测试结果反映服务小区 PCCPCH RSCP 值较高而 PCCPCH C/I 较差时，其接通率通常会有比较明显的下降。另外当 RRC 连接建立后，终端会根据网络侧的相关判决占用主载波/辅载波的 DPCH 信道进行 RB 建立及其它直传消息，此时如果出现较为严重的干扰会导致 DPCH C/I 恶化，这也会使接通率降低。针对以上两种问题我们最常用的手段是严格按照频点规划方案，修改服务小区或者干扰小区的频点、扰码，以减轻或避免干扰。 上行干扰导致的未接通，当存在上行干扰时，从测试软件中我们会发现 UE_Txpower
11、值会抬升，而上行干扰源除了网内其它用户终端外，外部干扰源也会造成非常强的上行干扰，着点可以通过后台指标提取并结合实际区域周围的建筑物场所进行判断，通常存在上行干扰的区域，周边小区的所有上行时隙均会有较高的干扰电平，并且会存在一定的时间规律，在特定的时间段里周边小区的 KPI 指标均会较平时有较大幅度的下降，而且这样的区域多集中在考场、党政机关驻地等（济南市区内各类军事驻地和办公场所众多，容易发生上行干扰） 。对于上行干扰导致的未接通，如果是个别小区存在我们可以尝试修改频点或扰码，而对于外部干扰源，则应该当尽量掌握其规律，在测试路线的选取或测试路过时采取合理的规避手段。（ 3） 参数问题导致的未
12、接通； 重选参数设置不合理导致未接通，重选参数设置不合理会导致 UE 在非最优小区发起呼叫，在严重时甚至会发生终端迟迟不重选而造成孤岛假象，最终以终端拖死起呼失败而告终，另外在位置区边界区域由于为了避免终端频繁的进行跨 LAC 区重选，在部分场景情况下我们会特别设置小区的重选参数，但在制定修改方案时要周全考虑到终端要在两个小区间双向进行重选的问题，而不能只顾及其中一侧。 邻区漏配导致的未接通，从现象上来看与前面提到的越区孤岛、弱覆盖均有相似之处，当使用联芯 8142/8130 进行测试时，如果出现终端 PCCPCH RSCP 值降低，并且在邻区表中没有较好小区时，应该首先排查的就是是否存在邻区
13、漏配，我们可以通过对基站数据库及站点地理位置分布图相结合，查看终端在未接通点时其邻区表中的是否有更合理的小区没有出现，并可以通过后台或者系统消息 11 来检查邻区关系是否配置。当发现邻区关系漏配后应当立即补全。6 2/3G 参数设置不合理导致的未接通，对于部分场景我们可能会由于种种原因对 2/3G 参数进行相关的调整，使终端重选/切换至 2G 侧的条件降低，重选/切换至 2G 侧的概率与次数大大增加，但相应的 2G 侧对 3G 侧的重选参数没有进行相对应的调整，使得部分区域存在较频繁 2/3G 重选，而重选后进行的位置区更新使被叫 UE 被寻呼到的概率大大降低，接通率随之下降。（ 4） 终端
14、/软件问题导致的未接通 终端问题导致的未接通，测试终端由于经常每天连续工作数个小时，特别是在夏天容易发热影响终端性能，甚至会出现一些异常事件，另外终端自身的功能设置有时与网络的匹配存在一定的问题，也会造成频繁的未接通。对于终端问题造成的未接通在现象上多种多样，难点在于我们要通过各种技术手段去排除无线环境、站点等网络自身问题，而最终定位终端存在问题不但需要我们能提出强有力的证据，还需要终端厂家的技术人员提供相关的专业软件和工具，并且在确定为终端问题后应当与厂家人员及时沟通解决问题。 软件问题导致的未接通，在实际测试中经常遇到，并且表现形式很多，例如被叫 UE 自行挂机；终端在上发 CM 服务请求
15、后，立刻上发 CM 服务中止消息等，对于软件问题导致的未接通需要我们在测试时就要及时的注意到，并且立刻采取合理的规避手段，例如软件重启，设备重连等。（ 5） 站点 /核心网问题导致的未接通 站点故障导致的未接通，目前现网测试时经常会遇到由于站点故障导致的未接通，特别是一些经常断站的小区，当测试车辆经过时往往由于信号过差，而终端又无法重选至断站小区导致起呼失败，为此我们应当对经常出现故障的站点，配置其周边站点的邻区关系，使该站点发生故障时，终端仍然能够顺利的切换到其它较好的小区以保持业务连续性。 室分站点问题导致的未接通，主要有两个方面，一方面是由于室内泄漏至道路，导致终端经过此处时重选至该室分
16、小区，当测试车辆逐渐开远时终端又不能及时重选回室外宏站而导致拖死。另一方面是由于室分站点设计不合理，特别是在写字楼等建筑结构相对复杂的场景下，会在部分区域形成覆盖漏洞或者隔离度考虑不周而造成干扰。对于室分站点的问题我们均建议要尽快实施整改。 天线方位角、下倾角问题导致的未接通，随着城市化进程的加快以及经济的高速发展，部分小区按照当初的规划预案建设开通后，其覆盖方向上的无线环境可能出现了较大7的变化，典型的情况如在覆盖方向上出现了新的建筑物，会在一定程度上影响到小区的覆盖水平，甚至信号完全被遮挡，这种情况我们就需要及时评估新的无线环境并对天线方位角、下倾角做出调整。 核心网问题导致的未接通，核心
17、网问题导致的未接通发生的较少，但往往发生时经常伴随着一些较为异常的现象，例如我们在测试时曾经遇到过主叫 UE 由于干扰、覆盖等问题没有正常的接收到被叫 UE 发送的 connect 以及 alerting 消息，因此也就没有上发 ConnectAcknowage 消息给网络，而被叫 UE 收到核心网由于完整性保护而自行下发的 ConnectAcknowage 消息，该问题的根本原因还是无线质量问题，但核心网自身的某些功能可能会对我们的分析判断造成影响，因此还需要多加注意。（ 6） 位置区规划不合理导致的未接通 位置区规划不合理导致的未接通，大家知道位置区边界的分布对网络的接通率有着直接的影响，
18、从测试情况来看，被叫 UE 由于在做位置区更新而导致的无法接收寻呼消息进而引发起呼失败的案例比比皆是，因此合理的规划位置区边界、并通过多种手段避免在位置区边界发生频繁重选/切换，是我们日常优化过程中需要注意的重点之一，关于位置区如何做到合理规划有着统一的标准，这里不再赘述，我们所要说明的重点在于根据实际测试情况来了解各个站点的覆盖范围和特点，因为实际覆盖场景是规划软件无法准确预测的，因此就需要外场测试人员在测试时细致的分析排查 LAC 区边界各个小区的覆盖特点，以及重选带、切换带的分布，根据实际的情况进行参数优化或者提出合理的割接需求。 正常位置区更新导致的未接通，在测试过程中测试车辆不可避免
19、的会发生跨位置区重选/切换，除了上面说所的位置区规划不合理导致的未接通，在正常情况下由于合理的位置区更新导致未接通事件是难免会发生的，因此我们在测试路线的选取及规划上需要注意尽可能的避免使测试车辆顺着位置区边界行进，减少车辆横穿或跨越位置区边界的次数，这样即可有效的避免不必要的位置区更新而带来的未接通风险，保障拉网测试指标。 位置区更新不及时导致的未接通，此类未接通事件我们在路测中时有遇到，但由于终端在空闲状态下跨位置区重选后位置区更新不及时导致的未接通事件实际上很少，绝大都数都是在前一次呼叫过程中，被叫 UE 由于无线环境恶化发生小区更新，但小区更新后占用的新小区与源小区分属于不同的 LAC
20、 区，而主叫 UE 在被叫无线质量下降而发生掉话、小区更新的过程中已经转为空闲状态，并在软件设置的呼叫间隔到时后发起8了新的呼叫，而被叫 UE 此时占用新的小区还没来得及进行位置区更新当然无法响应寻呼。同理，如果主叫 UE 在前一次呼叫过程中发生跨 LAC 小区更新，而按照软件设置开始新的呼叫时，由于没有位置区更新因此会收到网络下发的 CM service reject 消息，原因为 VLR 中的 IMSI 号未被识别。（ 7） 容量问题导致的未接通 容量问题导致的未接通，这种情况在路测时遇到的并不多，但作为影响接通率的重要因素还是需要提到，当终端发起 RRC 连接请求试图接入网络并进行相关业
21、务时，如果此时网络通过 RRM 算法的相关流程，发现此时服务小区的无线资源已不满足新用户的接入，便会向终端回复 RRC 连接拒绝消息，原因值为拥塞，针对这种问题最好的手段是对有条件的小区进行扩容，对于已经配置为 6/6/6 的站点，我们还可以考虑采用多重手段进行话务分担等。二、 典型案例上文我们主要介绍了外场测试时所遇到的未接通事件的分类及各类未接通事件的基本现象和处理手段，下面我们将重点列举一些我们在平时工作当中遇到的比较典型的未接通事件，通过详细的现象描述、严谨的分析过程最终得出高效合理的优化方案。需要说明的是，大多数事件并不是由于一种原因而导致的，经常都是有由于多种因素共同作用最后才发生
22、未接通，并且在表象上的表现可能以覆盖差、干扰严重的现象居多，但实际上这只是种种原因共同作用后的实际表现，而并不一定是覆盖问题或干扰问题，因此请在审阅以下案例时注意区别。1覆盖问题导致的未接通案例 1问题描述：当测试车辆由北向南行驶在将军路高架路靠近高墙王庄站点附近时，此时车速较快，主叫 UE 先占用盖家庄 2 小区，而后切换至高墙王庄 1 小区，结束通过话后重选至山东新世纪 1小区，并在该小区上发起呼叫，且顺利完成了起呼的流程，等待被叫侧回应振铃消息，可在等待时间超时后发起了释放。被叫侧 UE 首先也占用盖家庄 2 小区做通话业务，但并没有从盖家庄 2 小区切换到正常顺序的高墙王庄 1 小区，
23、而是切换到了北方汽车 3 小区，且在结束通9话后也没有能够重选至高墙王庄站点的小区，同时车速较快，导致最后被叫侧 UE 的接收信号质量极差，无法正常的收到网络下发的寻呼消息而重选至 2G 网络。主叫 UE 被叫 UE问题分析：通过对测试数据的回放分析，我们认为导致以上异常事件的原因主要是由于北方汽车 3小区存在一定的越区覆盖问题，致使在问题路段当车速较快时容易发生重选或者切换的问题。10同时高墙王庄 2 小区与现代黄台东 2（主频均为 10112）存在一定的同频干扰情况，如下图所示：主叫 UE调整方案：调整北方汽车 3 小区的 PCCPCH 发生功率由目前的 33 调整为 27，高墙王庄 2
24、小区的主频点由目前的 10112 调整为 10063。案例 211问题描述：当测试车辆行驶至经四路纬六路附近时，主叫 UE 在无线环境很好的情况下发起呼叫，并顺利完成 RRC 建立与 RB 建立过程，随后进入 PROGESS 状态，在定时器超时后释放，计为一次未接通，观察被叫信令，发现被叫未收到寻呼消息，但在主叫释放后被叫收到短信息提示有未接来电，如下图所示：主被叫信令问题分析：通过上面对测试数据的初步分析，我们认为既然被叫能够在随后收到网络下发的未接来电提示，则主叫于网络侧的交互已经顺利完成，问题有可能处在被叫侧，通过对被叫 UE 相关时刻的信令分析我们发现，在主叫 UE 发送 call p
25、roceeding 时，被叫 UE 正在进行小区重选，由纬六路 1 小区重选至客服二中心宿舍 2 小区，而在小区重选而尚未收全系统消息时，UE 是无法正常接收寻呼消息的，故此时被叫无法被寻呼到，如下图所示：12被叫 UE 小区重选过于频繁整改方案：建议根据现场情况适当调整客服中心二宿舍 2 小区的天线方位角或下倾角，减轻问题路段信号杂乱的情况，或者根据测试情况调整纬六路 1 小区对客服中心二宿舍 2 小区的Qofficet 由目前的 0 改为 2，避免在该路段 UE 由纬六路 1 小区意外重选至客服中心二宿舍 2小区的概率。2干扰导致的未接通案例 1问题描述：测试车辆由西向东行驶至解放路历山东
26、路附近时，主叫 UE 占用机械厅（地质学校）1 小区开始尝试建立 RRC 链接以完成一次呼叫，但主叫 UE 在连续多次发送 RRC 连接请求后没有得到网络侧回复的 RRC 链接建立消息，当超出 N300 计数器的限定范围后，计为一次未接通。13主叫 UE问题分析：通过对测试数据的分析，我们人为这是典型的由于干扰导致无线链路质量恶化，UE 上发的 RRC 连接请求网络侧没有收到，或者网络侧下发的 RRC 建立消息 UE 没有收到，致使 UE 在发送 RRC 连接请求的次数超过 N300 后，计为一次未接通。如上图所示。调整方案 ：修改中心医院（室分站点）的主频点由 10055 改为 10063（
27、实际上就是将主辅载波对调） ，同时修改机械厅（地质学校）1 的主频点由目前的 10104 调整为 10063案例 2问题描述：当测试车辆由北向南高速行驶到二环东路高架靠近轻骑路交界处附近时，此时主叫 UE 占用甸柳集团 2 小区，并且无线信号质量均不错，PCCPCH-RSCP 达到-70dBm 左右，PCCPCH-C/I达到 10 左右，主叫 UE 顺利的完成了起呼的相关流程，并且进入 progress 流程等待 CN 回复Alerting 消息超时后，释放相关的链接。被叫 UE 先占用甸柳集团 2 小区，但随后重选到甸柳集团 3 小区，并且在重选过后出现了 PCCPCH-RSCP 值较高，但
28、 PCCPCH-C/I 较差的现象，而且始终没有收到主叫 UE 的寻呼 1 消息，而是在主叫 UE 释放前后收到了网络的未接来电的短信提示。14主叫 UE 信令被叫 UE 信令问题分析：通过对测试数据的分析，我们认为造成该问题的原因有可能是由于被叫 UE 由于占用甸柳集团 3 小区时下行干扰较大，导致没能正确的收到寻呼消息 1 而产生的未接通，结合数据库以及测试软件分析，干扰可能是陶然亭 3 小区（主频 10120）与甸柳集团 3 小区同频造成的。整改方案：15修改陶然亭 3 小区的主频点拥有目前的 10120 调整为 10080。3参数问题导致的未接通案例 1问题描述：当测试出车辆由东向西行
29、驶至二环东路与山大北路交界处时，主被叫均占用省图书馆 1小区，并且此时的无线环境良好，主被叫 PCCPCH RSCP 值在-70dBm 左右，PCCPCH C/I 保持在18dB 左右，但当车辆由二环东路向西拐进山大北路后，PCCPCH RSCP 值下降，此时 UE 也开始进行新的呼叫，但由于此时无线信号的质量严重下降，导致在切换的过程中与目标小区下行失步，最终造成了本次起呼的失败。如下图所示：问题分析：通过对测试数据的分析，我们发现导致该问题的主要原因是由于省图书馆 1 小区与艺术研究所 1、艺术研究所 2 小区邻区漏配导致，同时我们发现由于基站数据库的错误（经纬度错误）导致在邻区核查的过程
30、中为省图书馆配置了错误的邻区，并且有可能误删了部分必要的邻区，因此我们建议将该小区的邻区重新配置。调整建议：为省图书馆 1 小区配置以下双向邻区：艺术研究所 1、艺术研究所 2、陶然亭 1、百花小区 316删除省图书馆 1 小区与陶然亭 2、甸柳集团 3 小区的双向邻区关系案例 2问题描述：当测试车辆由南向北行驶至济泺路与提口路交界处时（车辆已经行驶到天政宾馆-天桥北站点下方） ，主叫 UE 占用天政宾馆-天桥北 2 小区，开始进行起呼，然而在 RRC 建立完成 UE分配到 DPCH 信道后，主叫 UE 的 DPCH C/I 发生严重恶化，并且距离站点越近 DPCH ISCP 值越高，最终生未
31、接通。被叫 UE 在整改过程中表现正常，如下图所示：主叫 UE17主叫 UE问题分析：通过对测试数据的详细分析，我们发现本次未接通应该是由于主叫 UE 没有及时从天政宾馆 2 小区重选或切换到天政宾馆 1 小区，而天政宾馆 1 小区的 R4 载波也只有 10104，从上面的截图中我们可以发现，在主叫 UE 呼叫前几秒占用天政宾馆-天桥北 2 小区相同业务载波（10104 频点）进行位置区更新时，其 DPCH C/I 和 DPCH ISCP 值就很正常，而行驶到问题点时，天政宾馆 1 小区的 PCCPCH RSCP 值为-40dbm，远高于天政宾馆 2 小区的-60dbm，由此也可以解释为何此时
32、主叫 UE 的 DPCH ISCP 值非常高的原因， 并且该站点查无告警。被叫 UE 在问题点占用天政宾馆 1 小区整改方案：修改天政宾馆 2 小区的辅载波 10104 为 10112案例 3问题描述及分析：当测试车辆由北向南行驶至顺河高架靠近丝绸厂站点时，主叫 UE 占用丝绸厂 3 小区发起呼叫，由于周围无线环境的因素以及起呼的时机问题，导致主叫 UE 在完成 RRC 连接后丝绸厂 3 小区的信号出现快速衰落，而人民商场 1 小区的信号变强，使 DPCH C/I 恶化，UE 上发测量报告后无法在下行收到网络侧发送的 RB 重配置消息，最终导致未接通。如下图所示：18主叫 UE 问题分析：通过
33、对测试数据的分析并结合后台告警与指标的检查， 我们发现本次未接通事件的主要原因是由于在切换带附近丝绸厂 3 小区与人民商场 1 小区的信号变化过于陡峭，因此我们认为应该通过参数调整来，使切换带的分布更加合理。整改方案：调整丝绸厂 3 小区对人民商场 1 小区的 Qofficet 由目前的 0 改为-4，同时建议修改人民商场 1 小区的 10120 频点为 10071，并设置该载波为 H 载波。4终端/软件问题导致的未接通案例 1问题描述：当测试车辆由西向东行驶至共青团路与普利街交界处附近靠近长话大楼站点时，主叫 UE占用长话大楼 1 小区在无线信号质量较好的情况下发起一次呼叫，在呼叫的过程中切
34、换至长话大楼 2 小区，随后完成 RB 建立进入 PROGESS 状态，等到被叫响应超时后释放，被叫占用长话大楼 1 小区接收到寻呼消息，并发起 RRC 连接请求，但在第一条 RRC 连接请求发送后进行了小区重选，占用新的长话大楼 2 小区每隔两秒连续 2 次发送 RRC 连接请求没有得到网络的响应，而后 3 秒再次接到网络的 寻呼消息 1，再次每隔两秒连续 3 次发送 RRC 连接请求均19没得到网络的回应，之后计数器/计时器满，计为一次未接通事件，如下图所示：主叫 UE被叫 UE问题分析：通过对测试数据的分析我们发现，在被叫第二次接收寻呼消息并触发 RRC 连接请求的时间段内主叫 UE 的
35、上行发射功率较低（ -15dB 左右） ，切被叫 UE 的下行 PCCPCH RSCP 以及20PCCPCH C/I 均价较好但仍然没有收到网络下发的 RRC 连接建立消息，同时我们提取了长话大楼 2 小区 7 月 18 日的 RRC 连接相关指标，发现全天共发生 RRC 连接失败 5 次（原因均为 NO REPLY） ，且 5 次均为非业务相关，在本次事件的时间段（10：04：36 ） 没有发生 RRC 连接失败，因此认定被叫 UE 占用长话大楼 2 小区发送的 RRC 连接请求消息网络没有收到，且提取长话大楼 2 小区全天 TS1、TS2 的时隙干扰统计以及 UPPCH 干扰统计（时间粒度
36、 15 分钟）在事件时间段的情况均正常，因此怀疑是否由于 8142 型号的手机在支持 RRC 建立阶段的重选方面机制是否存在问题。 开始时间 服务小区RRC 连接失败计数器congestionRRC 连接失败计数器unspecifiedRRC 连接失败计数器，NO REPLY2010-07-18 00:45:00 长话大楼 0 0 12010-07-18 10:15:00 长话大楼 0 0 12010-07-18 14:15:00 长话大楼 0 0 12010-07-18 15:15:00 长话大楼 0 0 12010-07-18 18:15:00 长话大楼 0 0 1长话大楼 2 小区 7
37、月 18 日全天 RRC 连接失败次数统计（全天共次）开始时间 服务小区 ID 载频 ID 时隙 ID 时隙 时隙间平均 干扰 时隙间最大 干扰2010-07-18 09:45:00 10062 2022.4 1 时隙 ID:1 -108.8889 -89.52010-07-18 09:45:00 10062 2022.4 2 时隙 ID:2 -108.8756 -1002010-07-18 10:00:00 10062 2022.4 1 时隙 ID:1 -108.3978 -962010-07-18 10:00:00 10062 2022.4 2 时隙 ID:2 -108.88 -97.52
38、010-07-18 10:15:00 10062 2022.4 1 时隙 ID:1 -108.4544 -93.52010-07-18 10:15:00 10062 2022.4 2 时隙 ID:2 -108.4556 -902010-07-18 10:30:00 10062 2022.4 1 时隙 ID:1 -108.5389 -103.52010-07-18 10:30:00 10062 2022.4 2 时隙 ID:2 -108.5656 -93.5长话大楼 2 小区发生未接通时间段内的上行时隙干扰统计开始时间服务小区小区UPPCH测量值POS6小区UPPCH测量值POS7小区UPPCH
39、测量值POS8小区UPPCH测量值POS9小区UPPCH测量值POS10小区UPPCH测量值POS11小区UPPCH测量值POS12小区UPPCH测量值POS13小区UPPCH测量值POS14()小区UPPCH测量值POS15()09:45 长话大楼 2 -101.833 -102.833 -103 -106.333 -107.667 -108.167 -108.5 -108.667 -108.833 -108.66710:00 长话大楼 2 -102 -102.667 -103.333 -106.333 -107.833 -108.333 -108.5 -108.833 -108.833 -
40、108.83310:15 长话大楼 2 -101.667 -102.167 -101.333 -103.833 -106.833 -108 -108.167 -108.333 -108.5 -108.510:30 长话大楼 2 -101.5 -102.833 -102.833 -106 -107 -108 -108.5 -108.5 -108.667 -108.5长话大楼 2 小区发生未接通时间段内的 UPPCH 干扰统计详细指标情况如下：21长 话 大 楼 RRC.xls 长 话 大 楼 TS.xls 长 话 大 楼 UPPCH.xls问题分析与结论：通过对上述在 RRC 连接过程中触发小区
41、重选，从而导致随后的 RRC 连接建立成功或失败案例的简要描述分析，我们发现在 RRC 建立失败的案例中，由于无线信号质量问题导致失败的可能性基本可以排除，同时由于源小区或者重选后的目标小区站点故障原因也可排除（后台告警查询均为发现异常，并且这些小区的 RRC 连接建立成功率指标较好） ，那么是什么原因在无线环境、参数配置、站点工作状态均没有问题时，而导致 RRC 建立失败的呢？为此我们进一步提取了测试时的后台 CT，如下图所示：7月 18日长话大楼 1小区被叫 UE起呼失败 CT截图通过上面测试 CT 截图，我们可以发现在失败的案例中，UE 在源小区上发送的第一条RRC 连接请求 RNC 均
42、成功收到，网络侧不但进行了 RL 的建立，而且向 UE 回复了 RRC 连接建立消息，但此时 UE 已经占用到新的小区，因此无法收到网络侧发送的 RRC 连接建立消息，当然就无法进行后续的 RRC 建立流程，问题到这一步还比较好理解，然而继续分析，我们发现当 UE 成功的重选至目标小区后，在新的小区上发送的 RRC 连接请求竟然也发送到了源小区。通过上面的描述我们初步推断，由于小区重选造成 RRC 流程失败的主要原因应该是，UE进行小区重选时，由于自身性能限制或处理时间过短，下行链路虽然已经转移到新的小区，但上行链路却仍然保持在源小区，从而导致虽然监听到新小区 PCCPCH 信道的系统消息，但
43、发送的 RRC 连接请求仍然使用的是源小区的 PRACH 信道。那么为什会产生这样的情况呢？我们查看并分析对比了成功案例与失败案例的事件列表，在提到事件列表时，我们应该明确测试软件与测试手机行为之间的关系，测试软件在测试过程中的任务，应该是控制手机何时开始发起呼叫，何时挂机，并记录手机在测试过程中的各22种行为，因此事件列表中手机在 RRC 连接建立或者起呼过程中的行为，均应该是手机自身的行为，而非软件控制，事件列表如下图所示：成功案例与失败案例的事件列表对比从上图中我们发现成功案例中，手机在 vioce dial 开始起呼流程，之后被记录到发送了RRC 连接请求消息，随后开始小区重选，但在失
44、败案例中，手机在 vioce dial 后并没有 RRC 连接请求消息的记录，而是直接开始小区重选（实际上手机也发送了 RRC 连接请求） 。失败案例中事件列表与信令流程对应图23成功案例中事件列表与信令流程对应图通过对 RRC 连接过程中，小区重选导致的起呼失败及成功案例的测试数据分析，并结后台 CT 的分析，我们认为产生这种现象的原因由于 8142 手机自身性能问题引起的可能性较大，因为失败案例无论从当时的无线环境、站点工作状态、主要参数设置（定时器/计数器）来看，均比较合理，特别是参数设置与成功案例无异，唯一的区别在于第一条 RRC 连接请求消息发送后，失败案例中的 UE 小区重选时，下
45、行链路接入到目标小区，但上行链路仍然保持在源小区，由此导致随后在新小区上发送的两次 RRC 连接请求均发送给源小区，而源小区下发的RRC 连接建立 UE 却无法收到，因为此时 UE 正在监听新小区的下行链路，由此导致一次 RRC连接失败，进而引发未接通的产生。我们将尽快联系 8142 手机厂家，共同核实我们的结论案例 2问题描述：主/被叫 UE 完成 RRC 连接过程后，开始进行初始值传消息的传送，在发送完 CMservice request 后，又马上（通常间隔 1 秒左右）发送 CM service abort 给网络，由此导致初始值传流程中断，造成未接通。并且出现该问题后，通常测试软件不
46、会再控制手机发起新的呼叫 ，使测试无法继续进行，直至测试人员将软件重启或者重新录制测试 LOG 为止。该问题在LC8142 以及 DX188 上均有出现，并且出现该现象时无线信号质量通常没有较大的波动或异常，而且复测从未复现，因此我们认为该问题应该为软件问题所致。24主叫 UE 11:51:25.083 起呼失败信令被叫 UE 14:00:44 起呼失败信令案例 3问题描述：当测试车辆由北向南行驶至山大路靠近经十路附近时，主被叫 UE 均占用千佛山医院 1 小区，而且无线信号质量良好，随后主叫 UE 发起一次呼叫，被叫 UE 正常响应寻呼并顺利完成RRC 连接，但在进行初始值传消息的发送后，被
47、叫 UE 突然上发 disconnect 消息，原因解码为user busy，由此导致呼叫中断，软件统计为一次未接通，如下图所示：25主被叫 UE 联合信令截图被叫 UE26主叫 UE问题分析与结论：通过对测试数据的分析并结合千佛山医院 1 小区指标和告警信息的提取，我们认为由于测试过程中手机终端的行为（起呼，挂机） ，主要是受测试软件的控制，而本例中主被叫 UE挂机均是上行发起，即主被叫 UE 几乎同时主动通知网络挂机，而不是由其中一方引起，因此本次未接通异常事件由测试软件不稳定引起的可能性较大。测试人员曾经在测试过程中直接观察到该类型未接通，当时在主叫发起呼叫后，被叫侧已经听到振铃，但在振
48、铃刚响起后马上停止，观察被叫手机会发现提示有未接来电。另外，一般网络问题导致被叫未收到寻呼而产生的未接通，通常会有漏接来电短信提示。由于类似案例中，大多数发生在 RRC 连接完成后，出现问题主要在 RAB 建立过程（空口体现在 RB 建立） ，或者 RB 建立完成后 Alerting 消息发送过程中，而后台指标的接通率反映的是 RRC 连接成功率*RAB 建立成功率，因此只要 RRC 连接过程以及 RAB 建立过程顺利完成，后台即统计为一次成功的呼叫，导致前台测试软件统计结果与后台结果不统一案例 4问题描述：当测试车辆由西向东行驶至大明湖路与县东巷交界处时，主被叫 UE 均刚从 GSM 网络重
49、选回 TD 网络，由此触发了一次位置去更新，此时主叫 UE 占用明湖南门 2 小区且无线信号质量很好，当主叫顺利完成了位置区更新的主要流程，开始进行 RRC 连接释放时，突然上行发送CM Service request 消息，导致软件统计为未接通事件，如下图所示：27主叫 UE主叫 rrcConnect Request 消息解码28主叫 UE CM service request 消息解码问题分析及结论：通过对测试数据的分析，我们认为主叫 UE 在位置区更新的过程中出现的 CM service request 信令应该是手机自身由于某种原因触发的异常信令，因为从上面的描述及分析中我们可以看到，本次 RRC 连接请求的原因时异系统重选无误，而相隔 3 秒后上发的 CM service request 消息的原因为主叫，上下矛盾，因此该问题为手机自身问题。5站点/核心网问题导致的未接通案例 1问题描述：当测试车辆由西向东行驶到二环北路万通物流站点附近附近时，此时主被叫 UE 均占用万通物流 2 小区，PCCPCH RSCP 保持在-60dBm 左右， PCCPCH C/I 保持在 18dB 左右，同时主叫开始进行起呼，整个起呼流程正常，但由于该路段位于位置区边界，导致主被叫 UE
