外场未接通处理经验总结.doc

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