UPF数据包转发原理基本已经写完了，后续修改整理一下错别字就没问题了。这两天会陆续发出来。这样，5G核心网方面的内容写到这里基本就算整理完了。

其实如果数据包转发原理部分都弄明白了，PDU Session创建流程的后续部分走马观花的看一看就可以了，无非是不同网元之间互相交互一下信息而已。

老铁们久等了！

稀稀拉拉的写公众号已经一年多了，从刚开始的一周多更，到一周一更，再到两周一更，最后一月一更……中途好多次都想放弃了，直接停又觉得不符合善始善终的性格，不断的再坚持。虽然公号没多少人关注，但是半路抛锚，又辜负了那些坚持一起学习的老铁，自己弄的虎头蛇尾，搞得别人也学的半截落块，所以不断的提醒自己坚持一下，至少要把整块内容整理完，好像自己给自己留了一道沉重的家庭作业一般，过几天就提醒自己该整理点东西了。

现在，终于见到曙光了，感谢各位老铁的关注和支持，给了我无限的动力，也让我自己学到了很多细节知识！

整理过资料的同学应该能理解写材料是多末耗时费力的一项工作，尤其是又想把材料整理的条理清晰一些，又想内容全面一些，需要大量阅读、多次修改补充才行，非常消耗精力。自己学东西好像很简单，但是整理成文档，非常折磨人。所以有条件还是要买实体书，多支持一下那些出书的作者！

转发原理部分的内容更完，会继续把会话创建的流程简单补充完整，这样核心网部分就大功告成了。后续会稀稀拉拉的更一些专题内容，比如5G LAN、IAB、差异化寻呼等等的内容。最近在深入学习NR方面的知识，内容很多，感觉自己需要补充的无线知识太多了，一起加油！

本篇内容目录：

3.1.4.2.3.3 PDR的定义

3.1.4.2.3.4 UL PDR的困惑

3.1.4.2.3.3 PDR的定义

PDR（数据包检测规则）分区为DL PDR和UL PDR。规范中介绍UPF数据包转发时更多使用的是DL PDR。规范文档中介绍比较多的也是DL PDR，因为DL PDR涉及到定位UE的PFCP Session及把数据包分类映射到不同的QoS Flow，对UPF的数据包转发参与度更高。UL PDR规范介绍的较少，主要用来进行QoS Flow Binding的验证，也就是校验UE使用QoS Rule分类上行数据包时是否和下行PDR映射的QoS Flow一致。

TS 29.244的7.5.2.2章节定义了PDR的内容，如下图所示：

从PDR的定义中可以看出来，PDR ID、优先级值和PDI是必选的字段，其它字段都是可选的字段。

重点信息介绍：

- PDR ID

PFCP Session关联的PDR的唯一标识。PDR ID是SMF分配的PDR标识。实际组网时UPF可能会被多个SMF控制，这样，在每个SMF中分配的PDR ID的值可能相同，但是因为他们分属于不同的PFCP Session，所以并不会冲突。

- Precedence

PDR的优先级。SMF会直接复制根据PCF下发的PCC Rule的优先级值。

- PDI

该字段是PDR中的关键信息，其中就包含用于匹配业务数据流的过滤器信息。TS 23.501的5.7.1.5 QoS Flow mapping章节所说的SDF template就包含在PDI中。SDF template一般用于检测内层包头，也就是原始IP数据包的包头（类似N6接口收到的普通IP数据包）。在PDI中还会包含CN隧道信息、Network instance、QFI、AppId等信息，这些都可以用来进行数据包检测，一般用来检测外层包头或者应用层业务。

当SMF从PCF收到流描述信息（Flow Description）时会将其转换成对应的PDI信息（对应PDI中的SDF Fileter字段）。

PDI具体包含的内容见上图。PDI各字段中唯一的必选项是Source Interface，其它匹配用户数据包的信息都为可选项。根据我们前面介绍的缺省QoS Flow绑定的PCC Rule是能匹配上所有业务的过滤器，也就是不包含任何其它信息，只能包含Source Interface。而且这样的PDI只能有一个。PDI在后面会有专门小节讲解。

- Outer Header Removal

UPF是否需要删除匹配上本PDR的数据包的外部包头，如GTP-U包头，而不是GTP-U内部的IP数据包的包头。

PDR中的Outer Header Removal需要根据具体场景进行定义，比如：如果数据包要直接转发到DNN，就需要将GTP-U/UDP/IP头删掉之后送到外部DNN；如果是4/5G切换场景，需要删除GTP-U头部的PDU Session Container扩展头；如果是UL CL的UPF，不需要删除该字段，因为锚点UPF还需要使用这些信息。Outer Header Removal的另一个作用时在UPF和SMF之间进行用户面数据包转发时会使用到，比如SMF缓存下行数据包等场景，具体可以参考TS 29.244的5.3章节。

- FAR ID/ URR ID/ QER ID/ MAR ID

PDR关联的FAR、URR等信息。对于匹配上的数据流采取相应操作，就是根据该关联信息来确定的。

- Activate Predefined Rules

PDR是否使用UPF中预定义的规则，即：预定义的PDR/ QER / FAR / URR。该值是Predefined Rules名称。

Predefined Rules一般定义在UPF中，SMF只需要在PFCP Session Establishment Request或者PFCP Session Modification Request消息的Activate Predefined Rules字段中下发相应的ID值就可以了，如果没有携带激活时间或者去激活时间，表示Predefined Rules会立刻生效。

TS 29.244中介绍了具体的匹配细节问题，但是最终如何匹配及处理和产品实现相关，对于华为设备来讲，动态Rule的匹配方式如下。

·动态Rule：SDF filter中携带转发匹配条件，不携带Application ID参数。匹配上该rule的PDR，UPF会按照PDR中对应动作执行转发。

·ADC Rule：携带Application ID，且SDF filter为“Permit out ip from any to assigned”。UPF会根据Application ID匹配UPF本地配置的过滤规则。命中该rule的PDR，UPF会按照本地配置的规则执行转发。

我们平时接触比较多的内容计费基本都是使用UPF中配置ADC Rule，之后关联具体的数据包转发规则。SMF下发PDR时在Application ID中引用该ADC Rule就可以了。

- Activation Time/ Deactivation Time

PDR激活或去激活的时间。该字段在需要延迟激活PDR的场景下使用。如果不包含该字段则表示UPF收到消息后，就立刻启用PDR。

- UE IP address Pool Identity

UPF上配置有IP地址池时需要包含字段。如果包含IPv4和IPv6的两个IP地址池信息，表示SMF请求UPF为该PFCP Session分配UE IPv4和UE IPv6两个地址。

如果SMF从外部服务器发收到Framed-Pool、Framed-Ipv6-Pool等信息时会将其直接拷贝到该字段中。

另外，从PDR的定义也可以看出来，BAR并不是PDR直接引用的。PDR能够直接引用的是FAR、URR、QER和MAR。

SMF只能给UPF提供一个具有相同匹配信息的的PDR，即：PDI中的匹配字段及其值均相同，但是可以提供其它包含这些匹配信息子集的PDR。同一个PFCP会话中的不同PDR，其中的匹配信息可能是重叠的。如果PDI中的某个IE类型有多个，如UE IP address类型的IE有多个，那么数据包匹配上其中任何一个都认为是匹配成功。

没有匹配上任何PDR的数据包，UPF会直接丢弃。

当删除一个PFCP session（会话建立时，每个UE都有一个独立的PFCP session）时，UPF会删除PFCP session context和所有与其关联的非预定义的规则。

3.1.4.2.3.4 UL PDR的困惑

DL PDR的作用比较容易理解，主要是用来检测和处理下行业务的，那么UL PDR有什么作用呢？初看起来，貌似UL PDR并没有什么作用，规范里也没有着墨太多，很容易让人有疑问。因为UPF的外侧直接通过N6接口连到DNN了，上行数据包通过UPF后执行的动作全部一致，就是把GTP-U的头部全部剥离掉，恢复成原始的IP数据包送到DNN。此时使用UL PDR过滤、匹配一下数据包实在没什么必要，反倒降低了数据包的转发效率。即使是存在I-UPF或者UL-CL UPF的场景，NG-RAN已经在数据包头中标记了QFI，UL PDR也起不到标记、过滤数据包的作用。

根据TS 29.244的介绍，UL PDR的作用是校验QoS Flow Binding的上下行数据包是否一致。TS 23.501中的介绍是：UPF verifies whether QFIs in the UL PDUs are aligned with the QoS Rules provided to the UE or implicitly derived by the UE in the case of Reflective QoS.翻译过来就是校验一下上行数据包携带的QFI和网络测经过QoS Flow Binding后的QFI是否取值相同，也就是同一类业务的上下行数据包是不是在同一条QoS Flow中承载。在TS 29.244中这个功能称为：UL QoS flow binding verification。UPF收到的上行数据包，如果没有匹配上UL PDR中的PDI信息，说明不是下行SDF所对应的上行业务数据。此时，UPF会直接将该数据包丢弃。这样对网络安全也有好处。

正常情况，同一类业务（同一SDF）的上下行数据会在同一条QoS Flow中承载。假如下行数据在QFI1中传输，而上行数据在QFI2中传输，就容易出现混乱，QoS的控制参数GFBR、MGBR等等就无法执行了。

接着我们就会想到：5G中有没有场景会导致出现上下行不对齐（即：上下行数据的QoS Flow ID不一致）的情况呢？如果不管何种场景，上下行数据全部都能对齐，那么，使用UL PDR校验上行性数据的QFI就没有什么意义了。

经过多方查找，在TS 23.501和TS 24.501中发现了两个上下行数据不对齐的场景：

（1）5.7.1.5 QoS Flow mapping章节的NOTE 1中描述到：If a DL PDR for an bidirectional SDF is associated with a QoS Flow other than the one associated with the default QoS rule and the UE has not received any instruction to use this QoS Flow for the SDF in uplink direction (i.e. neither a corresponding QoS rule is sent to the UE nor the Reflective QoS Indication is set in the PCC rule), it means that the UL PDR for the same SDF has to be associated with the QoS Flow associated with the default QoS rule.翻译过来是：如果用于双向SDF的DL PDR关联了一个QoS Flow（非Default QoS Flow）并且UE没有收到任何该SDF上行方向需要使用这条QoS Flow的指示（即：既没有下发给UE对应的QoS Rule，PCC Rule中也没有设置RQI标记），这就意味着UL PDR关联到了Default QoS Flow。这段话虽然没有直接指明同一条SDF上下行业务分在了不同QoS Flow中承载，但从上面的介绍可以看出来在这个场景下：下行数据在一条普通QoS Flow中传递，而上行数据却在Default QoS Flow中传递，下行数据和上行数据没有对齐。该场景下，网络没有下发上行QoS Rule，也没有启用Reflective QoS，此时该SDF的上行数据包在UE中最后只能匹配到“能够匹配上所有上行数据包”的Default QoS Flow上传递，这就出现上下行数据包不在同一条QoS Flow中传递的现象。

（2）TS 24.501的6.2.5.1.4.6 Ignoring RQI in the UE章节中有这样一段话：If the UE receives a DL user data packet marked with a QFI and an RQI and it is not possible to derive a packet filter for UL direction from the DL user data packet as specified in subclause 6.2.5.1.4.2, the UE shall ignore the RQI and shall handle the received DL user data packet.从这句话可以看出去，如果网络想启用反射QoS并下发了RQI标记，此时如果UE无法自行推到上行数据包过滤器（Packet Filter），此时UE会直接忽略RQI，那么这时候对应UE的上行数据包只能在Default QoS Flow中传输了，也会出现上下行不对齐的情况。

上面的叙述只是根据规范文件直接解读得到的一些知识点，对于开拓思路，理解5G技术细节会有一定的帮助。在实际网络中基本不会出现这种情况，通信设备产品实现时都会尽量避免这种不正常现象产生。

UL PDR除了上面规范中叙述的数据包校验的作用，个人认为UL PDR在转发数据包方面仍然具有一定的作用，因为UPF转发上行数据包时可以根据UL PDR关联的FAR、QER等信息对数据包进行更个性化的处理及进行QoS控制。

既然UL PDR中也包含PDI信息，那么我们想到：当N6接口链接多个DN网络时，我们是否可以使用UL PDR将数据业务进行分流，将同一个PDU Session的数据包分类路由到不同的DNN网络中呢？如果仅从原理上来讲，貌似也不会出现什么问题。因为规则都是人定义的，只要有这种需求UPF产品完全可以按照这种想法来实现，但是如果使用UL PDR分类路由业务也会面临一些问题：

（1）按照我们之前的介绍，通常到一个DNN会创建一个PDU Session，而使用UL PDR分类路由数据到不同的DNN，就会出现同一个PDU Session对应了多个DNN，与5G的设计思想有一定的冲突；

（2）目前UPF上配置的IP地址池是和DNN关联起来的，这样，当SMF或者UPF为UE分配IP地址时，会涉及到不同DNN之间的协调问题，也就是分配给UE的一个IP地址需要在两个DNN中使用，容易出现IP地址冲突的问题；

目前我个人想到的问题有这两个，肯定还有面临更多的问题。因为如果这样使用UL PDR，相当于5G数据包转发的基本设计思想发生了变化。

虽然3GPP规范只提到了使用UL PDR进行QoS绑定验证，但是实际上目前很多通信设备已经实现了使用UL PDR进行分流的功能，具体实现方法有多种，比如VPN、端口绑定等技术。