CSFB失败问题快速定位手册

1、CSFB失败问题快速定位手册 大唐移动 CSFB失败问题快速定位手册文档名称CSFB失败问题快速定位手册文档编号版 本 号1.0.0作 者张晚辰目 录1.准备工作32.主叫失败32.1定位技巧32.2定位流程32.3定位案例73.被叫失败83.1定位技巧83.2定位流程103.3定位案例104.附录131. 准备工作按照目前山西移动的拉网规范，CSFB拉网需要使用1部双待手机作为主叫，1部CSFB手机作为被叫，两部手机同时连接CDS路测软件进行拉网，所以在做CSFB拉网测试分析时，我们需要将主叫失败与被叫失败区分对待。同时，CSFB失败的现象可能各不相同，但是成功的现象基本是一致的，所以我们在

2、分析初期对信令不熟悉时，往往可以通过与正确流程进行比对，来确定失败的症结所在，此处也会尽量多介绍一些失败的案例，供大家分析参考。2. 主叫失败122.1 定位技巧由于主叫侧使用双待手机，所以可以认为主叫手机语音业务一直工作在2G，因此一旦发现主叫失败后，往往可以将问题收敛至2G，从而加快定位速度。2.2 定位流程1. 打开CDS后，新建标签页，命名为“主被叫比对”，在视图页拖动两个信令窗口放置在上方，然后再拖动两个事件窗口放置在下方，在左侧的信令和事件窗口点击右键，选择主叫终端，在右侧同样操作，选择被叫终端，如下图。2. 然后再点击统计-事件，新建一个标签页，然后在事件中，将“Call blo

3、cked”拖动至刚打开的统计页中，此时会显示总失败次数，将其打开，下方会显示失败对应的时间点，双击它，会直接跳到失败的时间点，如下图。3. 回到刚才打开的主被叫比对页面，可以在下方事件窗口中看到，每一个事件都有对应的关键信令，正确的信令流程如下图，可以看出，主叫侧已经上报呼叫建立，同时进入等待，这时主叫侧的起呼流程就走完了。此后，在收到核心网下发的Connect后，代表主叫侧呼叫建立。最后，主叫侧上报Disconnect，核心网下发拆链，拆链完成，一次完整的主叫呼叫流程就走完了。4. 接下来我们看被叫侧的信令，点击主叫侧Setup信令，记录此信令上报时间，在右侧找到此时间点稍后时间的寻呼消息（

4、滞后12S），双击它，可以看到寻呼原因是CS被叫，如下图所示。5. 此时的流程分为两类：1） 终端处于空闲态。这时终端会收到Paging，然后发起RRC连接建立请求，随后完保通过，基站侧下发RRCConnectionRelease，这条信令会携带2G频点信息，终端收到这条信令后开始回落2G，如下图。2） 终端处于连接态。这时终端会收到CS Service Notification，即CS服务通知，随后终端上报Extended Service Request，这时就省略了建立RRC连接，基站侧直接下发RRCConnectionRelease，终端回落2G，如下图。6. 经过步骤5后，终端回落至2

5、G，随后上报寻呼响应，核心网下发呼叫建立，终端上报呼叫响应，开始振铃，之后被叫接听，由于脚本设置，10S后主叫侧挂机，被叫侧收到Disconnect后上报拆链请求，最终核心网下发拆链完成，一次标准的被呼流程就完成了，此时对应的事件是Call hangup，也就是挂机。2.3 定位案例1.分析LOG时经常可以发现一些失败是由于主叫侧2G拥塞造成，如下图。立即指配拒绝，原因为SD信道拥塞，将出现拥塞的小区反馈给2G优化人员后，通过2G扩容，此问题可以解决。2. 由于2G网络处理channel release消息和handover command消息并发冲突，导致拆链失败，如下图，此问题的现象为无法

6、挂机。3. 被叫失败12333.1 定位技巧被叫失败是目前失败的重点，一旦确认主叫侧呼叫建立完成但是却未呼通时，通常需要从被叫侧寻找原因，而被叫侧失败的原因往往较多，这里记录典型原因如下。1. 被叫侧未收到寻呼消息，导致未呼通。4G核心网存在二次寻呼，二次寻呼的间隔各地不同，山西省目前设置为10S，我们在分析未呼通原因时需要分析两次寻呼都丢失的原因。原因：现阶段丢寻呼通常有三种原因。1） 被叫终端驻留在4G网络，此时正在进行TAU过程。2） 被叫终端驻留在3G网络，此时正在进行RAU或者LAU过程。3） 此时信道质量较差，寻呼丢在空口。分析方法：首先查看主叫侧终端LOG，找到主叫侧上报Setu

7、p的时间点，按照此时间点向下12S寻找被叫侧是否收到了一次寻呼。如果没有收到，再向下10S观察是否收到了二次寻呼。两次寻呼丢失的原因很可能并不相同，因此需要区分对待。如果确认寻呼丢失，需要提取被叫侧终端所驻留站点的CDL，查看主叫侧上报Setup后对应时间点被叫侧所驻留的小区是否收到了核心网下发的寻呼消息，此消息是否下发给终端了，如果确认已下发，则需要再深入分析究竟寻呼是丢在了基站侧底层处理上，还是丢在了空口。2. 除去寻呼，被叫侧的4G关键信令是RRCConnectionRequest、RRCConnectionSetupComplete和RRCConnectionRelease，如下图。在

8、分析LOG时经常发现关键信令丢失导致的被叫失败。建议：查看当时的无线环境，由于覆盖问题导致的丢消息需要提交优化人员处理，如果不是因为覆盖问题导致，则需要提取当时的基站侧CDL对照，进行重点关注。3. 4G侧漏配2G频点导致被叫失败。建议：添加2G频点。4. 在分析晋城CSFB失败问题时发现，存活检测的RRC Connection Release先于携带CSFB的RRC Connection Release发给终端（此时在nas层已经开始响应paging消息），则会出现丢失携带CSFB的RRC Connection Release消息导致CSFB失败，如下图。建议：此问题已经专家确认为版本BUG

9、，存活检测仅看DRB而未检测SRB2，导致了携带CSFB信息的RRC Connection Release被基站侧丢弃，需要通过升级版本解决。3.2 定位流程同2.2节定位流程。3.3 定位案例1. 4G侧漏配2G频点导致被叫失败，如下图。查看了主叫侧使用的2G频点，如下图。发现519 频点并未添加到4G侧的频点列表中，导致4G回落2G失败，添加2G频点后问题解决。2.在分析LOG时经常发现被叫丢寻呼导致的失败，如下图。此时查看被叫侧状态，发现无线环境已经很差，属于弱覆盖区域，如下图：查看了基站侧CDL，发现基站侧已经将寻呼消息下发给UE，据此判断是由于无线环境差导致寻呼消息丢在空口，此处弱覆盖需要由优化人员处理。3.由于2G网络处理LAU和TCH建立并发时冲突异常，导致呼叫失败，如下图，终端在发起语音业务时，需要先建立SD信道，再通过SD信道申请TCH信道，而如果在申请SD信道时，终端发起LAU，这时终端就会先响应LAU，重新为LAU申请新的SD信道，从而导致了呼叫失败，这是2G实现问题，属于正常情况。4. 被叫终端在2G网络通话结束后拆链失败， CN没有在nas层下发release消息导致被叫处在连接态，下一次呼叫失败。5.被叫侧终端在收到寻呼后会发起R