TD-LTE中大数据完整性保护0算法导致UE无法鉴权.docVIP

实用文档 标准文案 TD-LTE中数据完整性保护0算法导致UE无法鉴权 TOC \o 1-3 \h \z \u 一、 概述 2 二、 现场测试问题如下： 2 三、 原因分析： 3 四、 解决方案： 8 五、 验证结果： 9 概述 新购买的TD-LTE测试终端型号E5776S,软件版本号为B161、B211为目前最新版本测试终端，在上海现场进行LTE测试时发现无法正常鉴权附着失败，导致无法进行正常测试。 现场测试问题如下： Security mode reject EMM cause显示为24 Security mode rejected,unspecified Attach reject EMM cause:Protocol error,unspecified 原因分析： 根据上面的测试截图我们发现，EPS已经下发Security mode command,而且UE侧发起Security mode reject，此行为为UE侧拒绝导致attach reject. security mode command，一个是NAS层的，一个是PDCP的，我们需要对比的是authentication完成后的security mode command，也就是NAS层的。 1、对比正常的测试流程Security mode command（B120版本）与B211、B161版本的UE侧拒绝的Security mode command： 正常B120版本的NAS层Security mode command B211版本的NAS层Security mode command 发现B120与B211版本的Security mode command无任何差异，故怀疑此B211版本UE存在故障。 2、为了确定UE故障，我们将此款UE在南京现场进行业务测试发现同款UE在南京现场测试正常，测试如下： PDCP层Security mode command 再次对比南京现场测试的NAS层Security mode command与上海现场的信令Security mode command信息 南京现场的Security mode command信息 上海现场的Security mode command信息 南京路测的截图，与上海的差别就是Type of integrity protection algorithm不一样，南京是128-EIA1，上海是EIA0，为数据完整性保护算法不相同，eNODEB侧参数设置完全一至均为EIA2。 所以可以确定为核心网侧integrity protection algorithm设置存在差异。但从UE上报的能力来看EIA0算法是可以支持的如下图UE信息： 3、参照规范：3GPP 33.401 关于完整性保护算法 MME应该包含3GPP定义了的所有的完整性和加密算法(核心网三种都支持), NAS层建立连接时，终端上报安全能力，那么MME根据终端能力选择算法。 我们的问题在于MME上配置的 lists of algorithms 和UE上报的security capabilities列表没交集，所以发生鉴权失败了。 同时hisi芯片厂家反映：芯片硬件本身是支持EIA0的，现在用新协议要求不允许只使用0算法（Null Integrity Protection algorithm），E1AO主要针对紧急呼叫的，安全性无法保障，目前统一用A1算法 南京MME Algorithm selected如下： 经分析，UE及网络侧如下配合更为合理： 如果UE只是用紧急呼叫的话，应该只带上来EIA0； 如果UE 3个都带了，那对于核心网来说，应该选择非EIA0的完整性保护算法； 解决方案： 给出3点解决建议，满足一项即可： 1.对华为新出的终端也是对EIA0做限制，在终端在上报支持能力时就不上报了EIA0了 2. MME侧把NAS security algorithm 中EIA0改成128-EIA1 3.如果终端上报支持EIA0，在核心网做完整性保护算法选择时，也不会优先选择EIA0，应该是EIA1或者EIA2，同时打开3个完整性保护算法开关。 验证结果： 最终用户协调经华为对核心网算法的修正（方案3），经测试验证，同款UE（UE前后的能力没有改变）已经可以接入网络了， MME下发的完整性保护算法为EIA2，附着成功。