MME修改IMSI号段状态为visitor导致附着失败。ESM CC27+EMM CC19

MME修改IMSI号段状态为visitor导致附着失败。ESM CC27+EMM CC19。

案例概述：

MME上修改IMSI号段状态为visitor导致附着失败。MME回附着拒绝，原因代码为：ESM CC27（missing or unknown APN）+EMM CC19（system failure）。

预置条件：

MME上已经配置了所属的PLMN ID，本例为46000。已经配置了IMSI号段460000001000001的漫游状态为home，代表是归属地用户。UE能够正常附着。

步骤和现象：

1）在MME上修改测试用户的IMSI 460000001000001状态为visitor（正常配置为home，表示归属地用户）。

2）UE上发起附着，MME给UE回了附着拒绝消息，EMM cause=ESM failure（CC19），同时NAS消息还包含了一个ESM的PDN Connectivity Reject消息，包含了ESM Cause=Missing or Unknown APN（CC27）。

完整的失败流程如下图：

完整流程如下：

可以看到，失败流程中。鉴权是过了的，安全流程也过了，到HSS的位置更新也过了，收到了HSS下发的ULA以及包含的签约数据（含签约APN）。

接下来，MME给UE回attach reject。

EMM cause=ESM failure（CC19），同时NAS消息还包含了一个ESM的PDN Connectivity Reject消息，包含了ESM Cause=Missing or Unknown APN（CC27）。

并且在附着拒绝之后，还给HSS发了purge request，HSS回了purge answer。

并且给eNodeB发了UEContextRelaseCommand，cause值为NAS。如下图：

这个也是符合规范的。

延伸思考：

Q1：为什么漫游状态，却选择了和本地用户相同的HSS并发起了位置更新请求？

— 因为MME里配置了PLMN ID是46000，因此根据这个PLMN并且对应的IMSI号段的配置，是可以寻址HSS的。

Q2：为什么漫游状态设置为Visitor，却回的是CC27？

最开始怎么都没想到修改了MME的UE IMSI状态为Visitor（即该IMSI为漫游用户）会导致CC27，但经过仔细思考，觉得也是合理的。

MME收到HSS返回的Update Location Answer，包含了UE的签约数据（含签约APN），正常流程接下来就会根据签约APN里的缺省APN发起S11口的缺省承载建立流程了。但此时，MME经过比对发现，该UE的IMSI所配置的漫游状态为visitor。而HSS返回的是home用户的签约数据。这一对比就矛盾了，也就是MME认为无APN可用。因此直接给UE回了CC27：Missing or Unknown APN。

其他说明：

– 因条件限制，抓包可能不全。例如没有抓到Update Location Request消息和Purge Request，但肯定是存在的。只不过没抓到而已。