华为2012年移动宽带PS维护宝典-EPC网络相关原理和案例-20121228-B-V1.0

华为2012年移动宽带PS维护宝典—EPC网络相关原理和案例华为技术有限公司版权所有侵权必究修订记录目录EPC网络相关原理和案例 (1)第一章用户访问安全原理和案例 (5)1.EPC网络用户访问安全原理 (5)1.1 EPC网络用户访问安全整体框架 (5)1.2 EPC网络AKA（Authentication and Key Agreement）流程 (6)1.3 EPC网络完整性保护和加密 (7)2.EPC网络用户访问安全相关案例 (7)2.1 开户配置错误案例 (8)2.1.1 用户接入4G网络，附着成功后MME马上对用户发起分离，分离原因是no-EPS-bearer-context-activated。

......................................... 错误！未定义书签。

2.1.2 OP/OPc开户错误导致终端鉴权上报MAC-failure (9)2.1.3 FAQ 附着拒绝中带有原因值llegal UE 常规解决方法 (10)2.2 安全算法配置错误相关案例 (11)2.2.1 鉴权关闭导致Initial_Context_Setup流程失败 (12)2.2.2 因在使能SMC功能下MME未配置完整性保护算法导致用户附着4G网络失败 (14)2.3 终端问题相关案例 (16)2.3.1由于终端不支持EEA2&EIA2算法导致加密鉴权失败 (16)2.3.2FAQ如何解决手机鉴权返回同步失败的问题 (17)第二章DNS解析和网元选择及案例 (21)1.DNS解析和网元选择原理 (21)1.1 EPC网络中的DNS域名解析服务 (21)1.2MME选择功能 (21)1.3S-GW选择功能 (22)1.4P-GW选择功能 (23)1.5网元优选策略 (23)2.DNS解析服务和网元选择相关案例 (24)2.1HSS APNOI与USN FQDN不匹配导致DNS解析失败 (24)2.2USN的Hostfile解析S-GW IP配置错误导致初始化EPS失败，手机无法正常附着网络 (26)2.3USN的S-GW本地DNS数据中，TAI配置错误导致附着失败 (28)2.4PGW Blacklist timeout interval导致DNS解析失败 (30)2.5RAU或P-TMSI附着所带old rai中LAC大于0x8000导致用户RAU失败或身份识别失败 (32)第三章专有承载建立原理及案例 (34)1.EPC网络专有承载建立流程 (35)2.EPC网络专有承载建立流程相关案例 (36)2.1大小写问题造成的专有承载创建失败 (36)2.2 播放器设置错误导致UGW无法创建专用承载 (37)第四章EPC QoS架构原理及案例 (40)1.EPC QoS架构原理 (40)1.1 EPC QoS架构模型 (40)1.2 EPS网络相关概念 (40)1.3 EPS网络中系统实现 (41)2. EPC QoS架构原理相关案例 (42)2.1 签约APN对应的QCI值错误导致用户接入4G网络失败 (42)2.2 FAQ-更改各QCI数据流对应PHB和DSCP 值的设置方法 (44)第1章用户访问安全原理和案例1 EPC网络用户访问安全原理1.1 EPC网络用户访问安全整体框架Homestratum/ServingStratumTransportstratumMEApplicationstratum User Application Provider Application(IV)(III)(II)(I)(I)(I)(I)(I)SNAN(I)USIM(II)HEEPC安全架构包含5方面内容：1、网络访问安全1)用户标识保密：MSIN、IMEI和IMEISV需要保密，NAS安全机制建立之前，UE不能发送IMEI和IMEISV，除了在UE设有IMSI/GUTI/PTMSI的紧急呼叫场景。

2)鉴权3)加密：协议推荐RRC信令、NAS信令和UP用户面数据加密，其中RRC信令和UP用户面数据加密在UE和eNB之间PDCP层执行，NAS信令加密在UE和MME之间NAS层执行。

目前支持的加密算法有EEA0（0000，不加密）、128-EEA1（0001，Snow3G）和128-EEA2（0010，AES）。

使用128比特密钥作为输入，将来可能扩展到256比特密钥。

4)数据完整性：NAS信令和RRC信令需要做完整性保护（除了TS24.301和TS36.331中明确要求不保护的信令消息），UE和eNB之间的UP用户面数据不需要完整性保护。

UE 和eNB之间执行RRC信令保护，UE和MME之间执行NAS信令保护，一旦NAS安全交互建立后，所有的NAS消息都必须通过完整性保护，否则即使进行了加密也将被丢弃。

目前支持的加密算法有EIA0（0000，不保护）、128-EIA1（0001，Snow3G）和128-EIA2（0010，AES）。

使用128比特密钥作为输入，将来可能扩展到256比特密钥。

EIA0仅用于紧急呼叫的特殊场景。

2、网络域安全3、用户域安全4、应用域安全5、安全的可视化和可配置1.2 EPC网络AKA（Authentication and Key Agreement）流程EPS AKA主体流程图如下：EPS AKA关键流程1 - MME从HE获取鉴权向量1)MME发送鉴权请求给HSS，携带IMSI、服务网络标识SNI、接入网类型（E-UTRAN等）；注：建议每次AKA 过程中MME 仅索取一组鉴权向量，因为EPS采用了更精细的密钥分层架构，AKA执行的次数相应减少。

可以用存储的K ASME对后续服务请求进行认证，而不需要AKA 过程。

另外，通过TS33.102描述的UMTS序列号管理机制来避免重同步问题，是一种可选方案，重同步问题来源于多组鉴权向量的交叉使用。

除了序列号管理机制之外可以通过立即从HSS 获取一组鉴权向量用于UE 和MME之间的鉴权，来避免重同步问题。

2)HE/HSS返回鉴权向量4元组：RAND、AUTN、K ASME、XRES，其中计算AUTN所用的AMF比特位0是Separation比特，如果接入网类型为E-UTRAN，则需要置为1，表示该鉴权向量只能用于EPS；如果接入网类型为GERAN/UTRAN，则置为0。

MME与ME进行双向鉴权流程图如下：EPS AKA关键流程2 - MME与ME/USIM进行双向鉴权1)MME向UE发起鉴权请求，携带RAND、AUTN、KSI ASME，其中KSI ASME用于标识此次鉴权所使用的K ASME；2)ME需要检查AUTN的AMF中Separation比特位（比特0）的值是否为1，如果不是1，ME认为该网络不是EPS网络，将拒绝接入；3)类似于UMTS，USIM计算并比对MAC/SQN，如果比对失败，则返回鉴权失败；如果比对成功，说明USIM对网络侧鉴权成功，USIM计算RES，返回给MME；4)MME将ME返回的RES与本地保存的XRES进行比对，如果相同，则鉴权通过。

1.3 EPC网络完整性保护和加密加密及完整性保护流程中涉及到的所有密钥产生流程图如下所示：加密和完整性包括分为3个层面：NAS层的加密和完整性保护（用户UE和MME之间）、RRC 层的加密和完整性保护（用于UE和eNodeB之间）以及用户层面的加密（用于UE和eNodeB之间）。

鉴权四元组中的KASME，即用于上述完整性保护。

4G中采用密钥分离，每种加密密钥、完整性保护密钥均由KASME衍生出来，但是各自的产生算法不同。

鉴权流程完成之后，MME 和UE侧均保留有相同的KASME。

1.NAS层的加密及完整性保护。

MME和UE均会以KASME为输入，通过双方协商的加密及完整性保护算法，分别计算出KNASenc和KNASint。

前者用于NAS层加密，后者用于NAS层完整性保护。

2.RRC层与用户层的加密及完整性保护。

RRC层以及用户层的加密和完整性保护，用于UE和eNodeB之间，但是eNodeB没有相应的密钥，如何获取呢？MME会根据KASME计算出一个提供给eNodeB用于加密及完整性保护的密钥，也就是KeNB，MME将其发送给eNodeB。

UE侧存有与MME侧相同的KASME，可以计算出相同的KeNB。

eNodeB收到KeNB之后，会根据与UE协商的加密及完整性保护算法，计算出KRRCenc、KRRCint及KUPenc。

同样，UE也会计算出上述3个密钥。

KRRCenc用于RRC层加密，KRRCint 用于RRC层完整性保护，而KUPenc用于用户层加密，用户层没有完整性保护。

至此，加密与完整性保护流程所需要的密钥生成完毕。

2 EPC网络用户访问安全相关案例2.1 开户配置错误案例2.1.1 因MME在上下文中保留的用户签约数据与HSS不一致导致用户附着后立即被分离现象描述：户接入4G网络，附着成功后MME马上对用户发起分离，分离原因是no-EPS-bearer-context-activated。

原因分析：查看用户跟踪，发现MME在下发Attach accept后给HSS发了Notify Request消息，此为正常流程，但HSS回复的Notify Response消息携带的原因值却是diameter-unable-to-comply，导致MME发起了用户分离（先向SGW发起删除承载请求，再向UE发起了分离请求），分离原因是no-EPS-bearer-context-activated。

经HSS侧分析，HSS回复该原因值是因为MME在Notify Request消息中带上来的用户签约数据与当前HSS中储存的数据不一致，而造成这个不一致的最终原因是HSS侧未配置订阅通知信息（BE侧：ADD NOTIFYCFG），导致在HSS修改用户签约数据后HSS并未立即将相关的更新发给MME（用户在该MME非初次附着，因此MME 在上下文中保留有用户签约数据）。

告警信息：无处理过程：解决问题可在MME侧用RMV USER删除用户，再次接入后MME便会重新去HSS取签约数据，用户即可顺利接入。

从根本上解决问题需要在HSS BE侧增加ADD NOTIFYCFG的订阅通知配置，保证每次在HSS修改签约数据后都会立即向MME发起更新。

解决问题可在MME侧用RMV USER删除用户，再次接入后MME便会重新去HSS取签约数据，用户即可顺利接入。

从根本上解决问题需要在HSS BE侧增加ADD NOTIFYCFG的订阅通知配置，保证每次在HSS修改签约数据后都会立即向MME发起更新。

案例点评：关于HSS BE侧ADD NOTIFYCFG命令：1、如果不配置，不影响用户基本接入功能，但在HSS签约数据修改后，只存储在HSS中，MME无法得到最新数据，也不知道数据已经修改。