5G初始NAS消息保护

协议要求针对TS 24.501 cl.5.3.1.1中定义的初始NAS消息进行保护，以将明文发送的信息减少到只有UE标识（已加密的SUCI或5G GUTI）。也就是说，在相关安全层激活之前，信息不会发送。特别是对于NAS层，这意味着当没有NAS安全上下文时，注册的S-NSSAI在接收注册请求时将不可用。

上次访问TAI

根据TS 23.502第4.2.2.2条：“如果可用，最后访问的TAI应包括在内，以帮助AMF为UE生成Registration Area”。

考虑到注册区域仅在注册接受中提供给UE，没有理由说明最后访问的TAI不能成为加密参数的一部分。一旦AMF获取了UE的安全上下文并破译了整个消息，它就可以继续生成注册区域，然后在Registration Accept中将其发送给UE。

Requested  NSSAI

根据TS 23.502，当AMF需要向AMF重新分配执行注册时，请求的NSSAI由AMF使用。

具体而言，在步骤4a中，请求的NSSAI用于查询NSSF。

然而，此时AMF应该能够解密整个消息，因为步骤2包括从旧AMF检索UE上下文。

RRC层加密S-NSSAI

无线规范仅应包括RRC层中的S-NSSAI加密。在相关安全层激活之前，信息不会发送。特别是对于NAS层，这意味着当没有NAS安全上下文时，注册的S-NSSAI在接收 Registration Request 时将不可用。

当前，S-NSSAI在RRCSetupComplete消息中发送。由于消息是在UE和RAN中建立访问层安全上下文之前发送的，因此该消息的整个内容都被取消了。

NG-RAN使用RRC级别的S-NSSAI选择AMF，因此在接入层安全上下文之前，不能推迟传输。注意，这一事实也适用于UE确实具有NAS安全上下文（例如，在移动注册的情况下）。除非使用公钥加密方案，否则即使UE具有NAS安全上下文，也不可能在RRC级别对S-NSSAI进行加密。

考虑到核心网决定不考虑使用公钥加密来保护Rel-15中的初始NAS消息，建议接受在Rel-15中在RRC层发送的S-NSSAI不会被加密的事实。注意，相同的结论适用于RRCSetupComplete中发送的其他信息（例如GUAMI或S-TMSI）。

现在，Rel-15中没有明确发送RRC级别的S-NSSAI的解决方案，建议在Rel-15中，应尽量减少RRC级别的S-NSSAI暴露，即不应将S-NSSAI作为Service Request 或Periodic Mobility Update程序的一部分在RRC级别显示。

如果将来的版本中也可以作为RRC级别的S-NSSAI加密解决方案，那么在RRC级别指示S-NSSAI的Service Request 的需要可以在以后的版本中进行评估。