NR 终端侧PDU建立过程以及数据包的过滤和映射

【5G NAS】NR 终端侧PDU建立过程以及数据包的过滤和映射-LMLPHP

一、终端发送PDU SESSION ESTABLISHMENT REQUEST消息

我们知道5G中终端的SM消息需要封装到MM消息中发送，也就是所谓的piggyback。所以终端需要首先构建SM的消息，然后构建用于piggyback的MM消息。

1.1 关键参数准备

终端为了建立PDU session，需要发送 PDU SESSION ESTABLISHMENT REQUEST 消息，这需要终端：

分配一个当前未被使用的PDU session ID；
分配一个当前未被使用的PTI，用于标识当前的PDU会话建立流程；
DN-specific identity，当终端接入外部网络时，用于验证和鉴权；
SSC mode，可选的值包括“SSC mode 1”、“SSC mode 2”、“SSC mode 3”；
- 如果PDU session type为“IPv4”、“IPv6”、“IPv4v6”，那么可选的SSC mode可以是“SSC mode 1”、“SSC mode 2”、“SSC mode 3”；
- 如果PDU session type为“Ethernet”、“Unstructured”，那么可选的SSC mode可以是“SSC mode 1”、“SSC mode 2”；
- 如果是将一个已经建立的PDU从EPC切换到5GC，则可选的SSC mode可以是“SSC mode 1”；
PDU session type，可选的值包括“IPv4”、“IPv6”、“IPv4v6”、“Ethernet”、“Unstructured”；
RQoS参数，表示终端是否支持反向QoS映射；
最大packet filters，告诉核心网此PDU session所支持的最大包过滤器数量；
- 如果PDU session是新建立的，且PDU session type是“IPv4”、“IPv6”、“IPv4v6”、“Ethernet”，那么最多支持16个packet filter；
- 如果是EPC中一个已经建立的PDU session且类型为“IPv4”、“IPv6”、“IPv4v6”、“Non-IP”，向5GC转换，则最多支持16个packet filter；
最大完整性保护数据速率；
MH6-PDU，向核心网指示是否支持多归属IPv6功能；
always-on pdu，向核心网指示此PDU是否是“永久在线PDU”；

1.2 构建UL NAS TRANSPORT消息并发送

1.1中描述了PDU SESSION ESTABLISHMENT REQUEST消息中的参数。然后终端将使用UL NAS TRANSPORT消息发送，UL NAS TRANSPORT中的参数如下：

PDU SESSION ESTABLISHMENT REQUEST消息；
对应创建、切换或转换的PDU session ID；
设置请求类型，可选的包括“初始请求”、“存在的PDU session”、“初始紧急请求”、“存在的紧急PDU session”；
选择S-NSSAI，如果PDU session的请求类型为：
- 初始请求，并且终端决定根据USRP（其中包含了一个或多个S-NSSAI）或者本地策略来建立一个新的PDU session；
  - 如果是非漫游场景，则S-NSSAI参数可以从匹配的USRP、默认的USRP或者终端本地配置的S-NSSAI中选择，但其必须属于allowed S-NSSAI;
  - 如果是漫游场景：
    1. 则S-NSSAI参数可以从匹配的USRP、默认的USRP或者终端本地配置的S-NSSAI中选择，但其必须属于mapped S-NSSAI；
    2. 与1中选择的S-NSSAI相关联的且属于allowed S-NSSAI的S-NSSAI;
- 存在的PDU session，则S-NSSAI参数是与这个已经存在的PDU session相关联的S-NSSAI。如果是漫游场景，则其也必须是一个mapped S-NSSAI；
设置DNN，如果初始请求的类型是“初始请求”或者“存在的PDU session”，则使用指定的DNN而不使用默认DNN；
当终端收到一条PDU SESSION MODIFICATION COMMAND消息且cause值为“#39 reactivation requested”时，会包含当前已经建立的PDU session的old PDU session ID;

当UL NAS TRANSPORT发送之后，会启动T3580定时器。

二、网络接受终端的PDU SESSION ESTABLISHMENT REQUEST

当SMF收到PDU SESSION ESTABLISHMENT REQUEST消息，会检查是否可以建立与终端请求的DN之间的连接，这中间可能会包含一些鉴权过程。当SMF确认可以与DN建立连接，则会向终端回复PDU SESSION ESTABLISHMENT ACCEPT。

2.1 PDU SESSION ESTABLISHMENT ACCEPT中的关键参数

authorized QoS flow descriptions IE，这个字段不是必选的，如果满足下面条件中的一个，则需要构建：
- authorized QoS rules IE中至少包含一个GBR QoS flow；
- 分配的QFI与其QoS flow的5QI中的QFI不一致；
- 此QoS flow可以被映射到EPS bearer；
如果此PDU session支持与EPS的交互，则还会构建Mapped EPS bearer contexts IE，并记录每个QoS flow与mapped EPS bearer context之间的映射关系；
SSC mode IE，如果：
- PDU SESSION ESTABLISHMENT REQUEST中没有包含SSC mode，则会根据DN的签约信息、对应SMF的配置信息来选择一个默认的SSC mode；
- PDU SESSION ESTABLISHMENT REQUEST中包含了SSC mode，则会根据PDU session type、用户签约信息、以及SMF配置信息从上报的SSC mode中选择一个；
S-NSSAI IE，选择PDU SESSION ESTABLISHMENT REQUEST中上报的S-NSSAI或者mapped S-NSSAI（漫游场景下）；
PDU session type IE，如果PDU SESSION ESTABLISHMENT REQUEST消息中包含了一个设置为：
- “IPv4v6”的PDU session type IE, SMF将选择“IPv4”、“IPv6”或“IPv4v6”作为该PDU会话所选择的PDU session type IE。如果签约信息、SMF配置或两者都被限制为仅支持IPv4或仅支持IPv6的请求DNN，则SMF应在PDU SESSION ESTABLISHMENT ACCEPT消息的5GSM causeIE中分别包含5GSM原因值 #50“PDU session type IPv4 only allowed”或#51“PDU session type IPv6 only allowed”；
- 如果选择的PDU会话类型为“IPv4”，SMF将在PDU SESSION ESTABLISHMENT ACCEPT消息中包含PDU address IE，并将PDU address IE设置为在PDU会话中分配给UE的IPv4地址；
- 如果选择的PDU会话类型为“IPv6”，SMF将在PDU SESSION ESTABLISHMENT ACCEPT消息中包含PDU address IE，并将PDU address IE设置为在PDU会话中分配给UE的IPv6链路本地地址的接口标识（低64bit）；
- 如果选择的PDU会话类型为“IPv4v6”，SMF将在PDU SESSION ESTABLISHMENT ACCEPT消息中包含PDU address IE，并将PDU address IE设置为IPv4地址和IPv6链路本地地址的接口标识，在PDU会话中分配给UE；
对于非紧急的PDU session，还会包含一个DNN IE;
Session-AMBR;
如果终端上报支持RQoS，则SMF认为这个PDU中的所有QoS flow都能够支持RQoS，并可能配置一个RQ timer IE。如果SMF将RQ timer设置为“deactivated”或者0，则表示并不启动RQoS功能；
Always-on PDU session requested IE

当终端收到PDU SESSION ESTABLISHMENT ACCEPT消息后，终端会停止T3580定时器，并释放PTI，此时终端认为PDU session已经建立成功。终端会存储“authorized QoS rules”，以及PDU SESSION ESTABLISHMENT ACCEPT消息中接收到的“Session-AMBR”和“authorized QoS flow descriptions”。

终端也会对配置的“authorized QoS rules”、“authorized QoS flow descriptions”进行语义和句法错误检查，详细过程可以参考。

三、终端可以建立的最大PDU session数量

一个终端可以在一个PLMN中建立的最大PDU会话数受以下最小值的限制：

协议允许的最大PDU session ID（3GPP TS 24.007-11.2.3.1b中规定）；
对应PLMN的最大PDU session数；
UE实现特定的最大PDU session数；

四、APP数据的转发

当PDU session建立成功之后，终端的APP可以发送数据了，那么数据是如何从APP映射到对应的QoS Flow上的呢？当然是通过对应的QoS rules，检测DL/UL的数据包，根据匹配到的QoS rule查找数据要映射到哪个QoS Folw上，也就是哪个QFI上。
协议没有规定在哪里执行APP数据包的过滤过程，我认为可以在AP侧实现，例如，通过AT Command查询网络配置给终端的QoS rules，然后实施过滤，最后将匹配的QFI和数据包一起发送给SDAP，如果没有匹配到任何QoS rules，则根据协议规定终端应该丢弃数据包。

关于QoS rules和数据包过滤的内容，我会单独再写一篇博文介绍，敬请期待。