梧桐山隧道口网问题分析报告.docVIP

梧桐山隧道口网络问题分析报告 1.问题概述 3月22日接到盐田唐总反馈，在深盐路梧桐山隧道出口至收费站入口处（往盐田方向，距离隧道出口约50米距离处）无信号。 2.问题核实 接到投诉后，我们立即对问题路段西东方向进行了测试。针对无网络信号问题，我们制定了分别采用空闲状态下及激活状态下的测试模式进行测试： 经过多次测试，我们发现在激活状态下，MS从梧隧M0-梧隧D4-园墩头D2-沙深D3，覆盖及质量良好： 在一次测试中，我们发现在空闲状态下，MS在问题路段占用梧隧M0往A小区（BCCH=60、BSIC=31）进行小区重选后位置更新失败，导致出现5~10秒的No Service Mode现象，之后重新启动网络选择流程至梧桐山三M3： 3.原因分析 根据测试的结果，我们通过以下几个步骤来分析定位问题： 分析位置更新失败信令流程； 小区及BCCH核查（BCCH=60、BSIC=31）； 更换BCCH频点进行验证； 3.1.信令分析 完整的位置更新流程主要包括立即指配、位置更新请求、身份请求、鉴权、加密、位置更新接受等，具体如下图所示： 而分析此问题的信令发现，MS发起位置更新请求后，经过身份请求后，未进行鉴权及加密、直接出现Location Updating Reject（原因：Roaming not allowed in this location area）： 3.2.小区及BCCH核查 在问题路段查无与A小区（BCCH=60、BSIC=31）同BCCH同BSIC小区，但存在同BCCH小区沙深M3（BCCH=60、BSIC=75）。从System Information Type 3信令中我们了解到A小区的CGI为460-00-1670-8，现网查无此小区。在问题路段中A小区的C2值高达60，导致MS易重选至此小区，另外从A小区的System Information Type 5信息中发现其active_balist配置与深圳一般小区的配置不一致： 为进一步验证A小区是否为深圳小区，我们对BCCH=60频点进行锁频测试，发现了四个奇怪的现象： BCCH=60、BSIC=31小区的CGI由460-00-1670-8变成460-00-535-8； 锁频后出现BCCH=59、61强邻小区； 测试软件信号强度为-40dBm左右，但测试手机显示”选择网络”选项，无法呼入呼出； 无法锁频至沙深M3（BCCH=60、BSIC=75）； 测试软件截图： 测试手机显示截图： 3.3. 更换BCCH频点验证 综上所述，我们怀疑问题现象是否与同BCCH的沙深M3有关。现场将沙深M3（BCCH=60、BSIC=75）调整为（BCCH=48、BSIC=75），再次在问题路段进行测试，发现空闲或激活模式的邻区中均不再出现BCCH=60频点，可初步判断不存在A小区： 空闲状态下，梧隧M0正常重选至沙深D3： 激活状态下，梧隧D4正常切换至沙深D3： 4.结论与思考 由于MS解码沙深M3（BCCH=60）错误，导致MS错误地发起了位置更新请求，在位置更新失败后造成5~10秒的No Service Mode现象，若同时在此时段起呼，那么MS呈现无网络现象时长将会更长，影响了客户感知。 经过更换沙深M3的BCCH后，经多次测试均未再次出现BCCH=60频点小区，未出现MS脱网现象。 但此问题留给我们一些需要思考的东西： MS为何出现错误解码现象，同时信令信息中可以解出不存在的小区的CGI； 位置更新为何可以通过身份验证，但为何无法鉴权跟加密； 梧桐山三M3在问题路段信号较强，存在干扰隐患，须控制其覆盖； PS: IMEISV跟IMEI的唯一区别就在于最后一位IMEI有15位，最后一位是Check digit，即检验位；IMEISV有16位，是去掉了Check digit，加上了两位SVN，即software version number。（从00 - 98，99备用）经仔细排查定位，初步确认是隧道管理处岗亭位置一私装发射装置造成，占用我司频点，对移动网络造成干扰影响，使得用户手机容易误选到问题小区导致无信号脱网。经咨询岗亭保安了解到该设备属于盐田公安局。目前我们已对周边的移动基站进行了频率调整，暂时避开了对方的干扰，复测验证基本不会误选到对方小区，通话正常。接下来我们会联系网络部、无委处理该私装发射设备问题。