|
这一篇谈PDR（Packet
Detection Rule）和FAR（Forward Action Rule）。前面提到，从CUPS（Control and User Plane Separation）的角度看，UPF最重要的工作，是从各个接口（N3、N6、N9和N4-u）接收“用户面”的“数据”，找到匹配的PFCP会话（PFCP Session）和PDR，根据PDR关联的其他“Rule”处理“数据”，相对应的，SMF最重要的工作，则是指示UPF建立、修改和删除PFCP Session Context，其中包含PDR和其他“Rule”—— 在其他“Rule”之中，最重要的就是FAR。简单的理解，UPF是“用户面”路径上的转发节点，自身不产生“数据”，只负责转发“数据”，UPF就像快递公司的中转站，自身不产生“货物”，只负责转发“货物”（我们不生产水，我们只是大自然的搬运工），协议把“转发”拆开为关联的两个部分来实现，PDR负责“接收”（Packet in），FAR负责“发送”（Packet out）。
UPF为什么需要PDR和FAR呢？设想一下，如果网络只有一个用户，且只有一种业务（如果只看协议的5GS拓扑图，容易产生这种错觉），UPF确实不需要PDR和FAR，只要将从AN（Access
Network，接入网络）接收的上行数据发送到DN（Data Network，外部的数据网络），将从DN接收的下行数据发送到AN，就万事大吉了。但实际情况是，5GS是为多用户、多业务场景设计的公共网络，UPF接收的上行数据，可能来自不同的AN和UE，需要送往不同的DN，反过来，UPF接收的下行数据，可能来自不同的DN，需要送往不同的AN和UE—— UPF和快递公司的中转站一样，收到的“货物”可能来自不同的用户，需要送往不同的目的地。为了确保数据送往正确的目的地（DN或UE），UPF接收数据后，需要先根据PDR进行识别（区分），UPF发送数据前，需要先根据（PDR关联的）FAR（和QER）进行封装 —— 以帮助下游节点（检测）识别数据。
举个例子，示图中共有4个UE：A、B、C、D，3个DN：X、Y、Z。在上行方向的N3接口，UPF X（连接DN X）收到的数据可能来自同一基站（M）的不同UE（A或B），UPF Z（连接DN Z）收到的数据可能来自不同基站（M或N）的不同UE（B、C或D）。对于UE A
DN Y组合，如果UPF I角色为UL CL（Uplink Classifier）或BP（Branching Point），则同时存在两个PSA（Y1和Y2，都连接DN Y），在上行方向的N9接口，UPF I根据（PDU
Layer）目的地址（UL CL场景）或源地址（BP场景）发送到不同PSA（Y1或Y2）。可以想象，在下行方向的N6接口（示图没有呈现），UPF X收到的数据可能需要发送到UE A或UE B，UPF Z收到的数据可能需要发送到UE B、UE C或UE D，在发送之前，UPF（X和Z）需要根据（PDU Layer）目的地址（即UE IP）进行识别 —— 如果某个（物理）UPF同时连接多个DN，UPF还需要根据Network Instance进行区分（即使只有一个DN，通常Network Instance也是存在的，3GPP TS 29.244: Network Instance - It shall
be present if the CP function requests the UP function to allocate a UE IP
address/prefix and the Traffic Endpoint ID is not present）。
在5GS内部，同一UE（或不同UE）的不同业务通过不同的PDU会话（PDU Session）进行区分，对于“用户面”的某个特定的接口，不同的PDU会话体现为不同的GTP-U隧道（GTP-U Tunnel）。从UPF的角度看，在5GS内部，N3接口和N9接口都使用GTP-U协议，UPF接收数据时，通过GTP-U报文的F-TEID（Fully Qualified Tunnel Endpoint Identifier）识别GTP-U隧道（识别PDU会话），UPF发送数据时，根据PDU会话对应GTP-U隧道的F-TEID，添加GTP-U包头（TEID）和IP包头（IP地址），以帮助下游节点识别GTP-U隧道。在5GS外部，N6接口上传送的就是业务数据（如果PDU会话类型是IP，业务数据就是IP报文，UE IP是IP报文的源地址或目的地址），UPF接收数据时，通过Network Instance和目的地址（即UE IP）进行区分，UPF发送数据时，则不需要进行GTP-U封装。有意思的是，SMF通过PDR将UE IP传递给UPF（PSA），作为N6接口接收数据的识别条件，但这个UE IP通常就是UPF分配的（协议允许UE IP由SMF或UPF分配，国内运营商通常选择UPF分配方案，3GPP TS 29.244: A UE IPv4 address or
IPv6 prefix may be allocated by the CP function or the UP function），在现网中，SMF在PFCP会话建立时（通过过渡的PDR）要求UPF（PSA）分配UE IP，SMF从UPF获得UE IP后，在PFCP会话修改时（通过新建的PDR）将UE IP又传递给UPF。
相似的，作为N3接口或N9接口接收数据的识别条件的Local F-TEID，也是UPF自己分配的 —— 且只能由UPF分配（3GPP TS
29.244: For EPC and 5GC, F-TEID shall be only allocated by the UP function, see
clause 5.8.2.3 of 3GPP TS 23.501[28]. The UP function shall set
the FTUP feature flag in the UP Function Features IE (see clause 8.2.25)
and the CP function shall request the UP function to allocate the F-TEID），SMF从UPF获得F-TEID后，通过“控制面”消息传递给GTP-U隧道的对端，后续对端发送数据时将这个F-TEID添加到GTP-U包头。以上图为例，从I-UPF的角度看，对于特定的PDU会话，I-UPF分配N3接口的F-TEID，通过N4、N11、N2接口传递给AN，后续AN发送上行数据时将这个F-TEID添加到GTP-U包头，相似的，I-UPF分配N9接口的F-TEID，通过（两个）N4接口传递给PSA，后续PSA发送下行数据时将这个F-TEID添加到GTP-U包头。可以想象（示图没有呈现），对于特定的PDU会话，AN分配N3接口的F-TEID，通过N2、N11、N4接口传递给I-UPF，后续I-UPF发送下行数据时将这个F-TEID添加到GTP-U包头；PSA分配N9接口的F-TEID，通过（两个）N4接口传递给I-UPF，后续I-UPF发送上行数据时将这个F-TEID添加到GTP-U包头。
只对PDU会话进行区分还不够，更进一步的，在PDU会话内部，部分节点可能需要区分不同的QoS流（QoS Flow），以进行相应的QoS控制。和PDU会话相似，QoS流是UE到PSA（UPF）之间的“端到端”管道，以QFI（QoS Flow Identifier）作为标识，在N3和N9接口的GTP-U隧道内，不同的QoS流通过GTP-U包头的QFI进行区分。SMF分配QFI后，通过“控制面”消息将QFI分别传递给QoS流的两端 —— UE和PSA。在上行方向，SMF通过N1接口将QFI传递给UE，UE（在Uu接口）发送“用户面”数据前将QFI封装进SDAP包头，gNB从SDAP包头获取QFI后，再封装进N3接口的GTP-U包头；在下行方向，SMF通过N4接口（通过PDR关联的QER）将QFI传递给PSA，PSA将QFI封装进N3接口（或N9接口，取决于是否存在I-UPF）的GTP-U包头。PSA以外的UPF（即I-UPF），不一定会从SMF获得QFI ——
可见QFI是可选的识别条件。实际上，I-UPF作为转发节点，只需要将接收报文的QFI“复制 粘贴”到发送报文，在PSA和AN之间的承载网络，进行差异化处理也不是基于QFI，而是基于FAR插入的DSCP—— 这里DSCP是SMF根据5QI、Priority Level和ARP确定的（3GPP TS 29.244: For 5GC, transport level marking is performed on a
per QoS flow basis. Transport level marking refers to the process of marking
traffic at the UPF with a DSCP value based on the mapping from the 5QI, the
Priority Level (if explicitly signalled) and optionally the ARP priority level
configured at the SMF）。
在上述认识的基础上，我们粗略看一下PDR和FAR。由图可见，每个PDR和FAR都有自己的PDR ID或FAR ID，用于区分不同的PDR或FAR。对于PDR来说，最重要的构成是PDI（Packet Detection Information），包含各种包检测信息，除了上面提到的Network Instance、UE IP address、Local F-TEID和QFI，还可能包含Source Interface、Traffic Endpoint ID、SDF Filter和Application ID等，这为包检测提供了丰富的组合。由于一个数据包可能同时匹配多个PDR，PDR还需要定义Precedence（优先级），帮助UPF确定PDR。随后，UPF通过PDR包含的FAR ID找到对应的FAR。对FAR来说，最重要的构成是Apply Action，其中BUFF、FORW和DROP的取值（三者只能有一项为1）指示如何处理匹配PDR的数据，是缓存、转发还是丢弃—— 如果缓存，根据FAR关联的BAR（Buffering Action Rule）指示如何缓存；如果转发，由Forwarding Parameters指示如何转发。另外，由于GTP-U隧道是“点到点”（Endpoint to Endpoint）之间建立的，即F-TEID是“点到点”有效的（或更准确的说，只在某个“点”有效），因此，在N3接口和N9接口，对应的PDR会包含Outer Header Removal，PDR关联的FAR（的Forwarding Parameters）会包含Outer Header Creation，这意味着，UPF在N3接口或N9接口接收数据后会先剥去旧的GTP-U包头、UDP包头和IP包头，发送数据前会再添加新的GTP-U包头、UPD包头和IP包头。
由上，从UPF的角度看，从特定某个接口接收的数据，可能匹配不同的PDR，因为数据可能和不同的UE相关，比如说，UPF（PSA）从N6接口接收的数据，会和包含不同UE IP的PDR匹配，UPF从N3接口或N9接口接收的数据，会和包含不同F-TEID的PDR匹配。更进一步的，对于特定的UE，从特定某个接口接收的数据，也可能匹配不同的PDR，以上图的A处为例，UPF（UL CL）从N3接口接收的数据，可能匹配不同的PDR（ID分别为0x
401和0x 1403），通过不同的FAR（ID分别为0x
2030 0001和0x 2050 0002）向不同的PSA发送。另外，PDR和FAR不是“一一对应”的关系，一个PDR可以关联多个FAR（我没见过实例），不同PDR也可能关联同一FAR（这些必须PDR属于同一PFCP会话，3GPP TS 29.244: A FAR, a QER, a URR
and a MAR shall only be associated to one or multiple PDRs of the same PFCP
session context），以上图的B处为例，UPF（UL CL）从N9接口的数据来自不同的PSA，可能匹配不同的PDR（ID分别为0x 802和0x 1804，F-TEID的IP相同，TEID不同），但通过相同的FAR（ID为0x 2040 0003）向gNB发送。关于PDR和FAR的更多细节，详见下一篇。
|
