S-NSSAI:Single Network Slice Selection Assistance Information
可译为“网络切片选择辅助信息”。注意不是以前的NSAPI啊,大不同的概念。5G用户在开户时候会在UDM上签约一个或者多个S-NSSAI,可以认为就是签约一个或者多个切片。5G中断接入网络时候携带这些S-NSSAI,网络根据情况将将终端接入相应切片。
如上所述,S-NSSAI用于标识一个网络切片,其包含两部分,如下图:
标准化的SST值为建立切片的全局互操作性提供了一种方法,以便PLMN能够更有效地支持最常用切片/服务类型(SST)的漫游用例。SST在3GPP规范文本中进行了规定如下:
标准化的SST值
需要提到的一点是在一个PLMN网络内并不需要支持所有的标准化的SST值。上表中所列出的SST值所指示的业务也可通过其他SST支持。UE在MSG5中指示其请求的S-NSSAI,这个可作为gNB侧为UE选择合适的支持该切片的AMF,具体参考文章:
5G SA中RAN侧AMF的选择
MSG5中的体现:
协议文本中S-NSSAI的结构为:
核心网侧之后会为每个UE的每个PDU Session指示使用的S-NSSAI,例如:
也就是说,UE可能同时使用多个S-NSSAI。而且切片是端到端实现的,拓扑示意图如下:
网络切片信息首先在SIM/eSIM(per PLMN签约)予以预配置,RAN侧支持网络切片的选择机制,实现UE与核心网侧协商。RAN会支持针对不同网络切片刀不同业务的处理。
这里有需要澄清的几个切片类型的概念,规范文本中定义的切片类型:
请求的NSSAI示例:
请求的NSSAI,
允许的NSSAI:
配置的NSSAI:
另外3GPP还定义了一类叫做Rejected NSSAI(Registration Accept),用于表示被拒绝的S-NSSAI的信息(协议规定不超过8个):
上述这三类NSSAI都是Serving PLMN的,Serving PLMN可以是VPLMN,也可以是HPLMN。而签约的默认配置的NSSAI则是属于HPLMN。允许的NSSAI基于UE请求的NSSAI,而配置NSSAI只和UE签约有关。
S-NSSAI在系统中的相关网元中的配置处理如下:
其中①是UDUM中UE关于切片的注册信息应该包括一个或者多个S-NSSAI,比如Subscribed S-NSSAIs。基于运营商的策略,这些一个或者多个S-NSSAI可以当做默认S-NSSAI来用。当UE没有给网络发送任何可用的S-NSSAI(在Registration Request的Requested NSSAI)时就会采用这个默认的S-NSSAI。每个S-NSSAI的签约信息包含如下内容:
网络侧将收到的Request S-NSSAI信息与签约的S-NSSAI进行比较。在漫游场景中,UDM应仅向VPLMN提供签约的S-NSSAI及HPLMN允许VPLMN中使用的UE。
在②中的NG接口处理中,相关的几条消息如下,这里其实包含了两类相关的IE,第一是TAI Slice Support List,表示每个TA中所支持的切片列表。第二是slice support list,表示的是每个PLMN中所支持的切片列表。
在③中与邻居gNB沟通时候包含S-NSSAI内容的Xn消息如下:
Xn中有个重要的IE包含了切片及其他的信息:
这个IE在XnAP的消息中传递:
还有,5G NAS规范文本还定义了一个重要的UE Configuration update的流程:
利用这个流程,网络可以在任何时候更新UE配置,这里的UE配置包括如下两类:
以初始接入为例说明一下S-NSSAI的传递过程(AS层各部分):
Step5,也就是msg5包含了S-NSSAI(可选IE)提供给gNB,在AS层为gNB选择AMF提供输入条件。
Step7&Step8,NGAP上的第一条承载NAS的消息InitialUEMessage及InitialContextSetupRequest中都包含了Allowed S-NSSAI(以InitialUEMessage为例):
InitialContextSetupRequest : {
protocolIEs {
{
id 10,
criticality reject,
value AMF-UE-NGAP-ID : 166xxx
},
{
id 85,
criticality reject,
value RAN-UE-NGAP-ID : 7yy
},
{
id 28,
criticality reject,
value GUAMI : {
pLMNIdentity '22f600'H,
aMFRegionID '10001001'B,
aMFSetID '0000000110'B,
aMFPointer '101110'B
}
},
{
id 0,
criticality reject,
value AllowedNSSAI : {
AllowedNSSAI-Item {
s-NSSAI {
sST '01'H,
sD '100001'H
}
}
Step9和14的E1AP消息Bearer Context Setup Request/Bearer Context Modification Request:(以前者为例)
BearerContextSetupRequest : {
protocolIEs {
{
id 2,
criticality reject,
value GNB-CU-CP-UE-E1AP-ID : 66xxxx
},
.........................
value PDU-Session-Resource-To-Setup-List : {
PDU-Session-Resource-To-Setup-Item {
pDU-Session-ID 1,
pDU-Session-Type ipv4,
sNSSAI {
sST '01'H,
sD '100001'H
}
Step11的F1AP的UE Context Setup Request消息
UEContextSetupRequest : {
protocolIEs {
{
id 40,
criticality reject,
value GNB-CU-UE-F1AP-ID : xxx
},
{
id 41,
criticality ignore,
value GNB-DU-UE-F1AP-ID : 667y
},
{
id 63,
criticality reject,
value NRCGI : {
pLMN-Identity '22f600'H,
nRCellIdentity '000001110101011110011000000110000011'B
}
.................................
{
id 35,
criticality reject,
value DRBs-ToBeSetup-List : {
{
id 34,
criticality reject,
value DRBs-ToBeSetup-Item : {
dRBID 1,
qoSInformation choice_extension : {
id 164,
criticality reject,
value DRB-Information : {
dRB-QoS {
qoS-Characteristics non_Dynamic_5QI : {
fiveQI 6
},
nGRANallocationRetentionPriority {
priorityLevel 3,
pre-emptionCapability shall-not-trigger-pre-emption,
pre-emptionVulnerability pre-emptable
}
},
sNSSAI {
sST '01'H,
sD '100001'H
}
本文后续会继续关注切片的log分析,敬请期待!。