5G切片中NSSAI定义与传递
admin
2023-09-27 21:01:07
0

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的签约信息包含如下内容:

  1. 一个签约DNN list和一个默认的DNN
  2. S-NSSAI的默认签约S-NSSAI指示
  3. S-NSSAI是否接受特定于网络片的身份验证和授权以及关联的AAA服务器地址等信息指示。

网络侧将收到的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配置包括如下两类:

  1. AMF确定并提供的接入和移动性管理相关参数。这包含配置NSSAI及配置NSSAI到签约S-NSSAI的映射,允许NSSAI和允许NSSAI到签约S-NSSAI的映射,服务间隔时间。
  2. PCF提供的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分析,敬请期待!。



相关内容