图4- 8 测试区域TAC与TA List分布示意图

因此，本案例中CSFB被叫失败，是由于4G网络MME将UE的Last Visited TA加入到给UE下发的TA List中，导致UE再次移动到Last Visited TA区域时不会发起TAU请求， 也就无法更新终端联合附着/位置更新的LA以及对应的MSC，从而导致跨MSC Pool回落，被叫失败。

3. 问题分类：核心网设备实现 4. 解决方案

根据3GPP协议，引入CSFB后，TA List尽量不要跨多个LA区域，而MME设备将UE Last Visited TA加入到TA List中的方式，会造成TA List跨多个LA区域，从而可能导致回落跨MSC Pool。

因此，通过规范MME实现，即不将UE的Last Visited TA加入TA List，从而避免本案例问题再次发生。

5. 效果评估

升级MME版本，通过软参配置方式关闭Last Visited TA加入TA List功能。之后的测试过程中，未发生因TA List跨多个LA导致回落跨MSC Pool，导致被叫失败案例发生。

4.2.8 案例8：回落至GSM后，鉴权失败

1. 现象描述

现象1：杭州外场，使用诺西USIM卡，回落2G建立语音业务，会出现第一次鉴权失败，第二次鉴权才成功的现象

现象2：青岛外场，4G网络使用46008网号，主叫回落后，终端不发起CM service request，

33

无法发起CSFB呼叫 2. 问题分析

杭州外场：

在跨LA场景中，回落过程中需要进行LAU。测试发现呼叫总是有鉴权失败的场景，经分析发现CSFB主叫侧100%成功，但CSFB被叫侧100%失败。后分析因呼叫流程不同，导致鉴权的场景不同，最终导致鉴权的失败、之后的重同步过程。 步骤 流程 1 2 3 联合位置更新 注1:MME每次要一组向量并使用 注2:MSC在联合位置更新阶段就下载5组Vector 回落 回落后执行MSC LAU流程 呼叫结束后BSC能否触发FR给UE （基于BSC的FR方案） SGSN RAU流程 UE发起Modify PDP context request 返回LTE MME TAU流程 CSFB MO √ 鉴权 √ √ 鉴权 100%成功 FR X X √ √ 不鉴权 CSFB MT √ 鉴权 √ √ 鉴权 100%失败 non-FR √ 但不鉴权 √ √ √ 鉴权 4 5 6 7 8

USIM卡可以根据网络侧下发的鉴权参数（RAND、AUTN）计算出网络下发的SQN，其中SQN = SEQ || IND， 与终端中存储的SQNMS做比较，验证时以IND做为索引值，即新收到的SEQ只与SEQMS（IND）进行比较，若超出其允许的范围将返回鉴权失败消息。 比较的关键是：L和Δ。

? L 表示USIM允许的可接受序列号的最大寿命，即新接收到的SQN和SQNMS之间的最

大允许数值差，要求SEQ > SEQMS – L。

? Δ 表示USIM可接受的序列号跳跃的最大值，即USIM只接受满足条件SEQ-SEQMS ≤ ?

的SQN。

怀疑卡商提供的卡和厂家提供的HLR/HSS/AuC中数据不一致，或卡中参数设置有问题，问题交给厂家和卡商共同研究和解决。

青岛外场：

34

青岛外场有2个特点：1) 4G网络与2/3G网络广播使用不同的网号：4G为46008，2/3G为46000。2) 4G HSS/AuC与2/3G HLR/AuC分设，用户的鉴权数据同时存储与2/3G HLR/AuC和4G HSS/AuC中。

终端在4G鉴权成功且联合注册成功， 但是主叫回落后，终端无法发起CM service request消息。 经分析UE侧log发现终端在2/3G网络鉴权总是失败，2/3G网络对应的网络46000已经在终端侧为roaming not allowed网络，但4G网络依然可以接入。

经分析，认为测试用USIM卡的鉴权参数与2/3G HLR/AuC中的设置应该不一致，导致2/3G网络的鉴权失败，在网络侧发起Authentication reject消息后UE会自动将网络设置为禁止，因为2/3G使用与4G不同的网络号，所以依然可以接入4G网络。需要卡商、设备厂商和省公司共同检查核对USIM卡和HLR/AuC中的参数设置。 3. 问题分类：核心网参数设置 4. 解决方案

杭州外场：卡商认为是旧COS中，Delta和L值设置与HLR/HSS/AuC中不同，造成同步失败无法登录网络。重新做卡后，问题基本得到解决。

青岛外场：卡商定位为USIM卡中R值与现网HLR/AuC中R值不符， 但是与HSS/AuC中R值相符。为了修改R值，与现网HLR/AuC中一致，需要重新做USIM卡，同时修改HSS/AuC的R值。新做的USIM卡最终在2/3G网络鉴权通过，证实确为R值问题。 5. 效果评估

问题基本得到解决。

4.2.9 案例9：UE在TAU流程中拨打电话导致呼叫失败

1. 现象描述

某城市外场测试过程中，4G UE拨打4G UE，L2L共拨打了60次，出现8次呼叫不成功，主叫在20s-30s左右的时延后听到“被叫无法接通”的录音通知。 2. 问题分析

检查终端侧和网络侧MME跟踪和记录的log，发现

(1) 在快速拨打的过程中，因TA-LA匹配，终端在呼叫前没有发起LAU流程，因此SGs

接口状态在MSC依然保持为associated；挂机后，终端支持自主快速返回功能，在UE返回LTE网络过程中，被拨打当被叫时，MSC依然会在SGs接口下发寻呼消息

35

(2) 虽然用户在MME状态设置为悬挂，但MME依然在空口下发寻呼

(3) UE返回LTE网络，尚未发起TAU流程，但看到空口的寻呼消息后，会立即发起寻

呼响应消息

(4) 接收到UE的寻呼响应消息后，MME给MSC返回SGs-ServiceRequest消息。但MME

因UE尚在悬挂状态，立即给UE返回Service Reject消息，同时给MSC发送SGs-IMSI-detach消息

(5) 因为接收到Service Reject， UE发起Attach request消息

(6) 接收到Attach消息后，MME在SGs接口发送SGs-LAU request消息

(7) MSC因为内部实现的bug，会一直悬挂入呼叫，直至超时（大约20s）释放呼叫

3. 问题分类：核心网设备实现 4. 解决方案

从问题分析中可看出，MME在用户悬挂状态时寻呼了用户， 之后又因用户悬挂状态拒绝用户的寻呼响应，并先后给MSC返回SGs-ServiceRequest和SGs-IMSI-detach消息，导致MSC内部的bug被激活，处理异常。

在此场景下，有两种可能的实现方式

方式1） 因用户悬挂，MME直接给MSC返回SGsAP-UE-UNREACHABLE消息，这样的话，本次呼叫失败，因为寻呼无响应，但MSC中用户SGs接口和状态都不会被修改， 不影响下次呼叫

方式2）MME依然在S1接口寻呼用户，增加LTE网络寻呼量，寻呼后可能失败，也可能寻呼成功。若用户返回寻呼响应，MME正常处理后续呼叫，呼叫正常。

两种实现方式均可，各有优缺点，需商讨。 5. 效果评估

36