CSFB异常点分析总结

1、文档名称文档密级1 问题现象1：R9盲重定向后读取3G系统消息接入如下图所示：UE发起CSFB后，接入3G后读取系统消息，说明R9的FLASH CSFB未生效分析LTE侧RRC连接释放消息，可以看到ENB只下发了频点，没有下发相应小区信息分析LTE侧SIB1消息，可以看到此时接入的LTE ENB为9，小区为1结论：9号enb为集锦饭店，此站的RIM流程有问题，DSP UTRANRIMINFO中，未包含最高优先级的3G邻区，由于测试版本BUG，导致rrc release消息中未携带系统消息，接入3G小区后读取了系统消息。2 问题现象2：CSFB至3G后发起LAU，并且无法快速返回4G，并且未发现

2、alerting问题如下所示，UE在3G侧发起LAU从呼叫开始分析，在16:16:40.135，LTE发起RRC连接释放触发CSFB动作，由于RRC连接释放消息中只携带频点，因此是R8的重定向CSFB，UE在3G侧读取系统消息接入UE在16:16:41.300发起RRC连接请求，此次RRC连接请求是CSFB的接入请求，可以看到RRC连接请求携带的原因为conversation callUE在16:16:42.957发送RB SETUP CMP消息完成CS RAB的建立，但从UE侧信令上看，过了6秒之后，UE进入空闲态UE在16:16:48.742发送cell update重新接入，携带原因为u

3、nrecoverableError，并且报AM-RLC在RB 2-3or4上错误指示为1，因此判断链路发生SRB复位掉话，UE后续通过cell update重新接入。从当时的信号强度和质量来看，下行Ec/Io较好，因此判断是上行失败导致UE掉话。怀疑RNC未收到UE发送的RB SETUP CMP消息。 由于UE掉话，后续UE接入后重新发起RRC连接请求，此时携带原因值为注册。表示此时UE认为该次RRC连接并非CSFB业务。UE在16:16:49.509发起RRC连接请求，原因为注册。由于前面UE也没有做过位置区更新，因此本次注册后，UE发起位置区更新并且由于此次UE认为并非CSFB业务，发起的

4、RRC连接请求里携带了pre-redirection信元，因此RNC判断此次UE接入并非CSFB业务，也就不会发起fastreturn了3 问题现象3：出现连续Reconfiguration及Measurement过程如下图所示：LTE发送ReconfigurationLTE下发Reconfiguration有两种作用，一种是RLC层参数的重新配置（类似于3G的RB重配），比如上图中的第一个RRCconnectionReconfiguration，里面携带的信元基本为RLC层参数配置及信道参数配置第二个RRCconnectionReconfiguration为下发的测量控制，包括系统内测量或系

5、统间测量4 问题现象4：未发送ESR，从4G重定向到3G该现象为基于覆盖的PS重定向，由于异系统切换未打开，因此移动性走重定向流程。ENB 16:25:27.655下发测量控制，携带A1/A2/A3事件相关参数从该测量控制中可以看出，A2测量事件的测量ID为3，门限为70（异系统），即为70测量ID为5，门限为40（异频），即为100通过信令，可以看到MS上报测量报告，上报A2事件，并且测量ID为3，说明启动异系统测量之后ENB下发测量控制，要求UE测量异系统（3G）邻区UE上报3G邻区后，ENB发起重定向流程，将用户重定向到3G邻区5 问题现象5：UE多次收到RRC CONNECTION S

6、ETUP消息这个是由于UE发送RRC CONNECTION REQUEST消息后，监听下行CCCH信道，如果收到是属于自己的RRC CONNECTION SETUP消息则响应，但也会收到其他用户的RRC CONNECTION SETUP消息，则不响应，区分是否为自己的RRC CONNECTION SETUP主要是看其中携带的TMSI。如下图所示：可以看到UE收到了两条RRC CONNECTION SETUP消息，只响应了第二条分析RRC CONNECTION REQUEST消息，可以看到其TMSI为0x06C83BC6第一条RRC CONNECTION SETUP消息中携带的TMSI为0x0A

7、B0A886，因此并非UE所发RRC CONNECTION REQ消息的响应，因此UE不回复而第二条RRC CONNECTION SETUP消息中携带的TMSI为0x06C83BC6，因此UE回复RRC CONNECTION SETUP COMPLETE6 问题现象6：切换失败，Fast Return失败，并出现TAU Reject重新附着流程首先看fastreturn为什么失败。CSFB走的基于测量的PSHO，但切换发起后，UE在3G同步上行信道失败，进入空闲态后重选到一个新的小区发起RRC连接请求首先我们看UE在LTE侧上报B1事件的测量报告里上报的小区为PSC=193但UE接入到3G后，

8、193小区信号很差（ECI0很差），导致UE切换接入失败UE后续重选到PSC=194小区重新接入但由于此时是重选重新接入，导致UE认为其并非CSFB用户，RRC连接请求中携带pre-redirection信元，因此后续fastreturn不成功TAU拒绝的流程，首先看到在LTE侧做TAU拒绝的原因为No EPS Bearer Context activated。协议里规定，UE在TAU REQ消息里必须携带一个缺省承载，如果不携带缺省承载的话，MME拒绝本次TAU请求，要求UE进行附着（Attach）23401 5.3.3.1If the MME has changed the new MME

9、 verifies the EPS bearer status received from the UE with the bearer contexts received from the old MME/old S4 SGSN. If the MME has not changed the MME verifies EPS bearer status from the UE with the bearer contexts available in the MM context. The MME releases any network resources related to EPS b

10、earers that are not active in the UE. If there is no bearer context at all, the MME rejects the TAU Request协议的意思是说，如果MME没有从UE中获取激活的MME CONTEXT并且改变其MME verifies EPS bearer status，MME则拒绝这次TAU Request分析TAU REQ消息，可以看到其中的EPS bearer context status均为INACTIVE，因此MME拒绝此次TAU REQ，要求UE进行附着而导致UE发这个的原因是因为在老侧的SGSN没

11、有激活相应的PDP连接，导致UE在老侧SGSN没有上下文报文，因此该值为空。分析信令，可以看到PDP连接被UE去激活，并且后续没有再激活。PDP承载去激活属于NAS消息，即属于核心网直接下发给UE的消息，无线侧只做转发，不解析其中任何内容，从协议上来看，当核心网不再为UE保持pdp连接的时候，即发起PDP去激活。UE下载再做数传业务的话，就需要重新激活PDP连接。7 问题现象7：鉴权失败的原因为同步失败根据协议描述，该原因值表示UE认为Authentication Req里携带的SQN超过范围而SQN包含在Authentication Req里的AUTN里核心网罗晓 分析猜测这种鉴权失败的如下

12、：CSFB 回落成功电话挂机后应该是手机发起TAU/LAU，在TAU 到MME 后MME 做了一次鉴权，鉴权成功后手机SIM卡上的SQN被改写，而MSC 上发送给手机的鉴权请求为MSC 先期到HLR 取的鉴权集中的SQN，所以吓到手机上出现不一致，手机会鉴权失败，MSC在收到手机的鉴权失败后，MSC发起向HLR 取新的鉴权集，之后MSC 再次向手机发起鉴权请求，此时鉴权成功，位置更新也成功；核心网龚华龙答复：1、 鉴权问题1） 少量的鉴权重同步在现网是非常正常的，只要鉴权重同步成功就不是问题。如果大量的重同步或者在某场景下必现问题请一线在HSS收集用户跟踪，发给研发定位。2） 只要HSS是2/

13、3/4G融合版本，并且当前测试用户都在这个HSS上，HSS就会分域处理，VLR/MSC和MME是不同的两个域，正常鉴权场景下，它们之间的SQN相互不影响，不会存在下面邮件中“猜测鉴权失败”的问题。3） GU互操作等场景都会触发域切换，这些场景在现网很多地方都有运用，在联通实验室也测试通过，这是基本功能，如果有问题早就发现了。一般出问题都比较异常场景，需要提供HSS消息跟踪、重现场景等定位信息，否则无法定位。现网出现鉴权失败（重同步后还失败的问题）的几种可能原因，以供参考：l MSC/SGSN鉴权请求未携带RequestingNodeType信元，导致HSS无法区分域信息l USIM卡中的L值设

14、置过小。l 4G的 HSS和2/3G HLR分离部署，不是融合部署。l HSS系统时间跳变。8 问题现象8：L到U基于覆盖的盲重定向在LTE建立RRC连接后，ENB下发测量控制，携带A2事件门限，A2事件的门限为40，且测量ID为3后续UE上报A2事件，可以看到测量ID为3（表示为A2事件），实际测量RSRP为39，小于A2门限，A2事件触发A2事件表示当LTE当前信号小于某一个值时，UE启动异系统测量，而由于盲切换打开，因此处走的是基于覆盖的盲重定向流程到3G。LTE侧直接RRC RELEASE，携带3G频点。9 异常时延分析【问题描述】10月19日测试数据总共两次异常时延，如下图所示：Lo

15、g名测量类型主被叫时延Probe_20131019114956-44主叫_1盲重定向主叫/MS212.643Probe_20131019114956-44主叫_1盲重定向主叫/MS29.708【问题分析】l 第一次异常点：ESR: 12:07:57.775 -> RRC release: 12:07:57.805LTE侧时延：30ms RRC release: 12:07:57.805 -> 3G RRC connection req: 12:07:58.2453G搜网时间: 440msRRC connection req: 12:07:58.245 -> RB setup

16、cmp: 12:07:59.785主叫RB建立时延：1540msRB setup cmp: 12:07:59.785 -> Alerting: 12:08:10.418等待被叫响应：10633ms分析主叫各段时延，主要是等待被叫响应时延过长导致。需要分析被叫行为，本次呼叫被叫也为LTE起呼。被叫MS收到ESR时间为12:07:59.564，分析信令，主要有两处导致被叫时延较长1、 被叫FLASH CSFB没有生效，在3G侧读取了系统消息（并非主要时延）分析系统消息3，其中Cellidentity表明接入的3G小区为18232，查询其扰码为19，下行频点为10713Cellidentity

17、后面16位表示cellid，计算得出为18232，分析LTE侧的RRC connection release，该小区并未被下发，查询配置，该小区并未添置为邻区从收到LTE的RRC connection release到在3G小区发起RRC连接请求，时延为1670ms2、 UE在3G的18232小区接入，后续该小区信号衰变，UE掉话脱网，发送cell update进行链路重建后在PSC=178小区重新建立CS业务，整段时延达到10秒左右（主要原因）如下图所示，UE在PSC=19小区响应寻呼后，进行相关NAS层交互（路由区更新和认证加密等），但在上报同频测量报告后进入空闲态，同频测量报告中178小

18、区Ec/Io较好，但19小区Ec/Io已经较差。分析怀疑此时RNC收到了测量报告，可能下发了ASU准备进行1A事件，但UE未收到。UE发送cell update进行重建，再建立CS业务查看工参，18232小区为CELLNAME="WD杭州华鸿科技大厦_2"，并不在该51号enodeb周边，怀疑可能是3G越区覆盖到此处，导致信号衰变引起该问题，建议RF调整。l 第二次异常点：LTE侧时延：28msUE搜网时延：1027ms 此处UE接入3G时读取了系统消息，说明FLASH CSFB未生效，导致时延较长主叫CSRAB建立时延：7012ms等待被叫时延：1641ms此次呼叫影响时延主要是2点，一个时f