图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