通信｜5G，NSSAI的小总结

学习永无止境，记录相伴相随！ —— 琉璃康康

5G的强大，一个是速度的提升，一个是诸多场景的切分，不像2/3/4G里的大杂烩(GW还是可以通过APN区分的，4G的DECOR/eDECOR也实现了MME的业务分离)，5G可以通过切片的定义将不同的业务分发到指定的网络设备中进行处理。

切片是通过定义NSSAI来实现的，一个NSSAI是由8 bits的SST+24 bits的SD构成，不过多赘述。

这里主要是关于几类NSSAI定义的来源汇总。

Requested NSSAI：UE ---> AMF

这个是UE提供给AMF表明UE想要申请接入的切片信息，在Security Mode Complete(Registration Request)的NAS-PDU里出现。

关于它的来源大概两类：一个是通过LTE获取，另外一个就是上次接入5G时候的Allowed NSSAI或者Configured NSSAI的汇总。

问题：怎么通过LTE获取？这个就要说到4-5G互操作了，比如将来要做4G到5G的IWK流程，那么就要求UE在4G附着的时候申请相应的5G资源，所以对于一个5G手机(选择了NR/LTE)+5G Sim卡在只有LTE覆盖的下发起LTE attach的时候就会带有N1 Mode Support的能力，同时也会在PCO里增加PDU Session ID的申请，在完善的网络定义下，这些申请就会到达支持SMF功能的PGW，因此PGW(SMF)通过N10(SMF-UDM)接口从UDM中拿到apn对应的切片信息后通过Create Session Response中的ePCO发给SGW/MME，最终通过MME转给UE。

所以对于一个5G手机是可以通过LTE拿到5G的切片信息的，那么这个就会作为5G注册时候的Requested NSSAI发给AMF。

Subscribed NSSAI：AMF <--- UDM <--- UDR

这个很好理解，就是网络中针对此用户签约的切片信息，定义在UDR中，通过UDM提供给AMF。

Allowed NSSAI：UE/gNB <--- AMF

这个是AMF在Registration Accpet中发给UE，表示网络侧允许UE可以使用的切片信息；同时AMF也通过Initial Context Setup Request的消息发给gNodeB。

Allowed NSSAI怎么来？它是一个诸多信息汇总到AMF后取的交集：

• A-UE的Requested NSSAI；
• B-UDM/UDR提供的Subcribed NSSAI；
• C-AMF配置支持的NSSAI；
• D-gNodeB上报的TAC支持的NSSAI(Slice信息是TAC based，同一个TAC下的所有gNodeB需要保持一样的切片定义)。

可以看到AMF下发的Allowed NSSAI和UE Requested NSSAI是可以不一样的，也就是说网络侧可以考虑UE的意见，但是不一定要听UE的或者可以部分听取。

如果UE requested NSSAI不在Subscribed NSSAI里，并且Subscribed NSSAI在AMF配置的切片和UE当前使用的TAC的切片有交集，那么Allowd NSSAI就会跟UE Requested NSSAI完全不一样，读起来有点儿绕口，其实就是B-UDM/UDR提供的Subcribed NSSAI、C-AMF配置支持的NSSAI、D-gNodeB上报的TAC支持的NSSAI这三个取交集E后，再考虑跟A-UE的Requested NSSAI取交集，如果有交集F，那么F就作为Allowed NSSAI发给UE，如果E和A没有交集，那么E就作为Allowed NSSAI发给UE。

Rejected NSSAI：UE <--- AMF

Rejected NSSAI多出现在UE Requested NSSAI和Allowed NSSAI不一致的时候，因为UE Requested NSSAI没有被网络侧接受而导致的，它表示网络侧告诉UE申请的切片没有被认可，所以Rejected NSSAI是UE Requested NSSAI减去Allowed NSSAI的结果，AMF在Registration Accpet中发给UE。

Configured NSSAI：UE <--- AMF

Configured NSSAI也多出现在UE Requested NSSAI和Allowed NSSAI不一致的时候，AMF在Registration Accpet中发给UE，这个也是一个交集：

• A-UDM/UDR提供的Subcribed NSSAI；
• B-AMF配置支持的NSSAI。

了解了这几个NSSAI之后，分享一个最近的PDU Establishment Reject的案例，Cause code是91 DNN not supported or not subscribed in the slice，经过抓包看到UE发PDU establishment request后，AMF没有做任何的NRF查询直接使用CC91 reject此PDU建立请求，最终定位是此用户使用的dnn所属的切片(smf-selection-data)不在allowed NSSAI列表里，导致PDU建立失败；大致信令如下(懒的画了，左右滑动凑乎看吧)：

AMF config Slice 11-1, 22-2, 33-3
gNodeB <---> AMF NGSetup TAC1 with NSSAI 22-2
UE -----> AMF Registration Request in TAC1
UE <----> AMF <-----> AUSF Authentication
UE <----- AMF Security Mode Command
UE -----> AMF Security Mode Complete(Registration Request): Requested NSSAI(11-1, 22-2)
AMF<-----> UDM <-----> UDR Get NSSAI: 11-1(default), 22-2
AMF<-----> UDM <-----> UDR Get smf-selection-data: dnn1 with slice 11-1
UE <---- AMF Registration Accept: Allowed NSSAI 22-2
UE -----> AMF PDU sesion establishment request with dnn1
UE <---- AMF PDU session establishment reject with CC91 DNN not supported or not subscribed in the slice
解决方案：
1. 将NSSAI 11-1加入TAC1
2. 更新用户的数据：将dnn1的slice更改成22-2

以上就是针对切片定义的一个小总结，如有误或有更多更好的信息欢迎留言讨论。