PFCP（一）

这个系列介绍PFCP。PFCP是Packet Forwarding Control Protocol的简称，顾名思义，是对“数据转发”（Packet Forwarding）进行“控制”（Control）的协议。PFCP是CUPS（Control and User Plane Separation，“控制面”和“用户面”分离，简称CU分离）的副产物 —— 在EPC早期版本中，SGW和PGW在“控制面”（Control Plane）参与“会话管理”（Session Management），也在“用户面”（User Plane）参与“数据转发”（Packet Forwarding），对“数据转发”的“控制”属于SGW或PGW内部实现（网元可视为黑盒子），不需要通过协议约束；在5GC中，“控制面”（C）和“用户面”（U）分离，“会话管理”和“数据转发”分别由SMF和UPF负责（对运营商来说，理想情况是SMF和UPF完全解耦，实际情况是SMF和UPF依然在使用同一厂家产品），凭空多出一个N4接口，相对应的，3GPP需要设计一个控制协议，就是PFCP。

实际上，CUPS和PFCP不是什么新鲜事物，3GPP早在R14就引入CUPS —— EPC的SGW分离为SGW-C和SGW-U，PGW分离为PGW-C和PGW-U，增加Sxa接口和Sxb接口（3GPP TS 23.214 Architecture enhancement for control and user plane separation or EPC nodes）—— Sxa接口和Sxb接口也使用PFCP。SMF、SGW-C和PGW-C统称为Control Plane Node，UPF、SGW-U和PGW-U统称为User Plane Node，因此，更全面的说，PFCP是Control Plane Node和User Plane Node之间的控制协议。PFCP描述详见3GPP TS 29.244（本文以V17.1.0为参考），不同接口还略有差异，这个系列只关注5GC的N4接口，忽略EPC的Sxa接口和Sxb接口（以及LI in EPC相关的Sxa′接口和Sxb′接口，LI in EPC架构详见3GPP TS 33.107。LI in 5GC不涉及PFCP，LI in 5GC架构详见3GPP TS 33.127）。

在EPC中，对于特定的PDN连接（PDN Connection），“用户面”路径上只存在一个SGW和一个PGW（逻辑网元，物理网元可以是Co-Located的SAE-GW）；在5GC中，对于特定的PDU会话（PDU Session），“用户面”路径上可能存在多个UPF —— 可能是终结N3接口的UPF（协议没有定义专有名称），终结N6接口的PSA（PDU Session Anchor，一个PDU会话可能存在多个PSA），实现UPF串联的I-UPF（Intermediate UPF），实现数据分流的UL CL（Uplink Classifier）和BP（Branching Point）。无论是上述哪种角色，UPF都只负责在“用户面”路径进行“数据转发”，至于具体如何转发，由对应的SMF（示图没有呈现I-SMF）“控制”。由上，每个UPF都有各自的N4接口，以和SMF交互PFCP消息。不过，SMF和UPF不是“一一对应”关系，特定的SMF可能和多个UPF交互，特定的UPF也可能和多个SMF交互。

顺带一提，SMF和UPF之间不仅存在“控制面”数据（PFCP消息），也可能存在“用户面”数据。个人理解，N4接口（N4-u）存在“用户面”数据包括以下几种场景：1、5GC为UE分配IPv6地址，为了传递IPv6 Prefix，UE和SMF在“用户面”发送ICMPv6的RS（Router Solicit）和RA（Router Advertisement）消息，RS和RA消息需要通过N4接口转发；2、在EPS中，IoT（Internet of Things，物联网）数据在UE和MME之间可通过NAS消息传送，在MME和IoT AS之间可通过SCEF或SGW / PGW转发 —— 如果通过SGW / PGW转发，则会经过S11-u接口，相似的，在5GS中，IoT数据在UE和SMF之间可通过NAS消息传送，在SMF和IoT AS之间可通过N4接口转发（但N4-u和S11-u不是对等的概念）；3、SMF和外部RADIUS服务器（比如二次鉴权场景）或DHCP服务器等交互，相关数据可通过N4接口转发。由上，在5GC中，N4接口存在“控制面”和“用户面”两个协议栈，底层都是UDP / IP，上层分别是PFCP和GTP-U —— 本文主要关注“控制面”的PFCP，但PFCP消息也需要指示“用户面”（N4-u）的GTP-U数据如何处理。PFCP注册端口号为8805，即PFCP请求消息UDP目的端口为8805（3GPP TS 29.244: The UDP Destination Port number for a Request message shall be 8805. It is the registered port number for PFCP）。

PFCP源于CUPS，很容易理解，PFCP的主要作用，就是向UPF传递各种“Rule”（规则），帮助UPF确定如何进行“数据转发”。上图为3GPP TS 29.244 Clause 5.2的UPF处理示意图。从CUPS的角度看，UPF最重要的工作，就是从各个接口（包括N6、N3、N9、N4-u等）接收“用户面”的“数据”（对应图中的Packet In），找到匹配的PFCP Session和PDR（Packet Detection Rule），根据PDR关联的FAR（Forwarding Action Rule）处理“数据” —— 可能是丢弃（Discarding），缓存（Buffering，根据FAR关联的BAR），或转发（Forwarding，通常在另一个接口发送，对应图中的Packet Out）。同时，UPF根据PDR关联的QER（QoS Enforcement Rule）进行QoS控制，以及URR（Usage Reporting Rule）进行用量上报。相对应的，从CUPS的角度看，SMF最重要的工作，就是指示UPF建立、修改和删除PFCP Session Context —— 包含PDR、FAR、BAR、QER和URR等“Rule”。在5GC中，通常一个PFCP Session Context对应一个PDU会话（3GPP TS 29.244: The CP function controls the packet processing in the UP function by establishing, modifying or deleting PFCP Session contexts and by provisioning (i.e. adding, modifying or deleting) PDRs, FARs, QERs, URRs, BAR and/or MAR or by activating/deactivating pre-defined PDRs, FARs, QERs, URRs, per PFCP session context, whereby a PFCP session context may correspond: - for EPC, to an individual PDN connection, a TDF session, or a standalone session not tied to any PDN connection or TDF session used e.g. for forwarding Radius, Diameter or DHCP signalling between the PGW-C and the PDN. - for 5GC, to an individual PDU session or a standalone PFCP session not tied to any PDU session）。理解PFCP的重点，就是理解上述各种“Rule”。不过，这一篇不谈“Rule”的细节，先关注“Rule”的载体 —— PFCP Association和PFCP Session。

SMF和UPF之间先建立PFCP Association，再建立PFCP Session（3GPP TS 29.244: A PFCP Association shall be set up between the CP function and the UP function prior to establishing PFCP sessions on that UP function）。不太严格的说，PFCP Association（PFCP偶联）是SMF和UPF之间的“大管道”，和特定的UE、特定的PDU会话无关，SMF和UPF通过建立PFCP偶联交换Node ID、特性和配置。Node ID可使用FQDN或IP地址作为取值 —— 如果使用IP地址，表示SMF或UPF只有一个用于PFCP偶联建立的IP地址。在后续交互中（PFCP会话建立），SMF和UPF可通过对端的Node ID识别PFCP偶联（3GPP TS 29.244: A CP function or a UP function shall be identified by a unique Node ID. A Node ID may be set to an FQDN or an IP address (see clause 8.2.38). When set to an IP address, it indicates that the CP/UP function only exposes one IP address for the PFCP Association signalling）。PFCP偶联的建立、更新和释放过程详见3GPP TS 29.244 Clause 6.2。PFCP Session（PFCP会话）是SMF和UPF之间的“小管道”，（通常）和特定的UE、特定的PDU会话相关，用于传递各种具体的“Rule”。SMF和UPF通过PFCP会话建立交换F-SEID（Fully Qualified Session Endpoint Identifier），在后续交互中（比如PFCP会话修改），SMF和UPF通过（接收PFCP消息包含的）本端（分配的）的F-SEID识别PFCP会话。PFCP会话的建立、更新和释放过程详见3GPP TS 29.244 Clause 6.3。

关于PFCP偶联的描述详见3GPP TS 29.244 Clause 5.8。通常来说，在特定的SMF UPF之间只建立一个PFCP偶联，即使SMF或UPF存在（暴露）多个用于PFCP偶联建立的IP地址。对于支持SSET特性的场景，在SMF Set（多个SMF组成的集合）和一个UPF之间也可能只建立一个PFCP偶联（3GPP TS 29.244: Only one PFCP association shall be setup between a given pair of CP and UP functions, even if the CP and/or UP function exposes multiple IP addresses. A single PFCP association may also be setup between a SMF set and a UPF (see clause 5.22.2)）。特定的SMF可以和多个UPF建立PFCP偶联，特定的UPF可以和多个SMF建立PFCP偶联。SMF和UPF都可以触发PFCP偶联建立 —— SMF触发是“协议规定动作”，详见3GPP TS 29.244 Clause 6.2.6.2；UPF触发是“厂家自选动作”，详见3GPP TS 29.244 Clause 6.2.6.3（3GPP TS 29.244: A CP function may have PFCP Associations set up with multiple UP functions. A UP function may have PFCP Associations set up with multiple CP functions. The CP function and the UP function shall support the PFCP Association Setup procedure initiated by the CP function (see clause 6.2.6.2). The CP function and the UP function may additionally support the PFCP Association Setup procedure initiated by the UP function (see clause 6.2.6.3)）。示图为SMF触发的PFCP偶联建立场景，SMF和UPF交换Node ID作为PFCP偶联的标识，同时交换支持的可选特性（optional feature，比如PSUCC（Partial Success）或IPUPS（Inter-PLMN User Plane Security）），这会影响SMF和UPF的后续行为。另外，UPF可能向SMF发送UE IP地址池信息（如果UE IP地址由UPF分配）和NF实例ID。

和PFCP偶联的建立不同，PFCP会话的建立只能由SMF触发。SMF和UPF会在消息（PFCP Session Establishment Request / Response）中携带各自的Node ID，以指示发送消息的网元（指示PFCP会话对应的PFCP偶联）。SMF和UPF还会在消息中携带各自的F-SEID（IP SEID），用于UPF和SMF后续识别PFCP会话。此外，SMF会在消息中携带各种“Rules”（以及Recovery Time Stamp），如果UPF保存并应用所有下发的“Rules”，UPF返回“Success”和“Created PDRs”。只要存在一个“Rule”没有保存和应用，UPF返回（第一个）导致失败的Rule ID和原因，除非SMF和UPF都支持PSUCC —— 如果SMF和UPF都支持PSUCC，UPF按照3GPP TS 29.244 Clause 5.2.9描述返回“部分接受”（3GPP TS 29.244: if the CP function indicated support of the PSUCC feature (see clause8.2.58) during the PFCP association setup or update procedure, and if this feature is also supported by the UP function, the UP function should accept the request partially, if possible, and return a response indicating a partial acceptance of the request as specified in clause 5.2.9）。

更具体的，PFCP会话是在SMF的PFCP实体和UPF的PFCP实体之间建立的。SMF或UPF都可能包含一个或多个PFCP实体（Either a CP function or an UP function supporting one or more PFCP entities），通过IP地址进行区分 —— PFCP实体的IP地址和Node ID包含的IP地址可以相同，也可以不同（PFCP entity - An endpoint in a CP (or UP) function supporting PFCP, that is identified by the IP address. The IP address of a PFCP entity may or may not be the IP address included in the Node ID）。每个PFCP会话在SMF和UPF各对应一个Session Endpoint（会话端点），在PFCP会话建立时，SMF的PFCP实体分配本端的SEID（Session Endpoint Identifier），和PFCP实体的IP地址一起构成CP F-SEID，通过PFCP Session Establishment Request发送给UPF，在（同一PFCP会话）后续交互中，UPF发送PFCP消息时会在包头携带CP F-SEID包含的SEID，使用CP F-SEID包含的IP地址作为目的IP地址。反过来，UPF的PFCP实体分配本端的SEID，和PFCP实体的IP地址一起构成UP F-SEID，通过PFCP Session Establishment Response发送给SMF，在（同一PFCP会话）后续交互中，SMF发送PFCP消息时会在包头携带UP F-SEID包含的SEID，使用UP F-SEID包含的IP地址作为目的IP地址。PFCP的F-SEID作用和GTP的F-TEID（GTP可参考《EPS是什么鬼？（四）》）相似，SMF或UPF通过接收的（PFCP会话相关的）消息的F-SEID（自己分配的），就可以识别不同PFCP会话。不同PFCP实体分配的SEID可能重合（各自独立分配的），但F-SEID（结合PFCP实体的IP）是唯一的（3GPP TS 29.244: The SEID uniquely identifies a PFCP session at an IP address of a PFCP entity. The F-SEID is the Fully Qualified SEID and it contains the SEID and IP address. The PFCP endpoint locally assigns the SEID value the peer PFCP side has to use when transmitting message. The SEID values are exchanged between PFCP endpoints using PFCP messages. The PFCP entity communicates to the peer PFCP entity the SEID value at which it expects to receive all subsequent control plane messages related to that PFCP session via the 'F-SEID' IE）。

为了降低SMF故障对PFCP会话的影响，3GPP引入了SMF Set，允许SMF接管（Take over）同一SMF Set其他SMF控制的PFCP会话 —— 对于特定的UPF，如果每个SMF各自建立PFCP Association，称为MPAS（Multiple PFCP Association）特性，行为详见3GPP TS 29.244 Clause 5.22.3；如果所有SMF共用一个PFCP Association，称为SSET特性，行为详见3GPP TS 29.244 Clause 5.22.2（3GPP TS 29.244: A PFCP session may be controlled by different SMFs of an SMF Set using either one PFCP association per SMF Set and UPF as described in clause5.22.2 (called SSET feature), or with each SMF of the SMF set establishing its own PFCP association with the UPF as described in clause 5.22.3 (called MPAS feature)）。MPAS是“协议规定特性”，SSET是“厂家自选特性”。支持MPAS或SSET的SMF需要接管其他SMF的PFCP会话（如果收到UPF发送的SMF Change请求），而支持MPAS或SSET的UPF需要支持UE IP地址 /前缀分配（3GPP TS 29.244：A UPF complying with this version of the specification and that supports being controlled by an SMF set shall support the procedures specified in clauses 5.22.3 (i.e. MPAS feature) and may support the procedures specified in clause 5.22.2 (i.e. SSET feature). An SMF supporting the SSET feature or the MAPS feature shall be ready to take over the control of a PFCP session from another SMF within the same SMF SET, upon receiving a request from a UPF requiring an SMF change, if possible）。

对于MPAS场景，SMF Set内各个SMF分别和UPF建立PFCP偶联，SMF在消息中指示自己支持MPAS特性，使用SMF的FQDN或IP地址作为Node ID，同时，SMF在消息中携带（同一）SMF Set ID。另外，SMF可以提供同一SMF其他PFCP实体的IP地址作为备用（简单的理解，就是备胎啦）。对于SSET场景，由SMF Set内的某个SMF和UPF建立PFCP偶联，SMF在消息中指示自己支持SSET特性，并使用代表SMF Set的FQDN作为Node ID（和MPAS相比，SMF不能使用IP地址作为Node ID，但也不需要携带SMF Set ID）。另外，SMF可以提供同一SMF Set内其他SMF的IP地址，或同一SMF其他PFCP实体的IP地址作为备用（备胎）。无论MPAS场景还是SSET场景，在建立PFCP会话时，同一SMF Set中，各个SMF分配的SEID可以是唯一或非唯一的，但F-SEID必须是唯一的（3GPP TS 29.244: When establishing a PFCP session, the SEID that the SMF assigns in the CP F-SEID of the PFCP Session Establishment Request may be unique or not within the SMF set. However the assigned CP F-SEID shall be unique within the SMF set）。UPF不知道（不需要知道）SEID在SMF Set中是不是唯一的。对于MPAS场景，SMF和UPF各自通过自己（分配）的F-SEID识别PFCP会话（3GPP TS 29.244: The UPF does not (need to) know whether the SEID in the CP F-SEID is uniquely assigned in the SMF set or not. The SMF and the UPF identifies the PFCP session by its own CP F-SEID and UP F-SEID respectively）。

如果PFCP会话对应PFCP实体出现状况，UPF会向其他PFCP实体“求救”，包括以下三种场景：场景1，CP F-SEID包含的IP地址无响应（3GPP TS 29.244: the IP address included in the CP F-SEID assigned to the PFCP session is not responsive）；场景2，UPF从SMF收到N4-u隧道相关的GTP-U错误指示（3GPP TS 29.244: the UPF receives a GTP-U Error Indication from the SMF over the N4-u tunnel assigned to the N4 session for data forwarding）；场景3，CP F-SEID包含的IP地址心跳中断（3GPP TS 29.244: heartbeat failure towards IP address of the CP F-SEID assigned to the PFCP session，仅适用于MPAS场景）。UPF向同一SMF的其他PFCP实体，或同一SMF Set的其他SMF发送PFCP Session Report Request —— 如果向其他SMF发送：对于MPAS场景，UPF只能向此前已经建立PFCP偶联，且SMF Set ID相同的SMF发送（3GPP TS 29.244: another SMF in the SMF set with which the UPF has established associations with the same SMF Set ID）；对于SSET场景，UPF可以使用PFCP偶联建立 / 更新获得的（备用）IP地址作为目的地址，如果此前没有获得（备用）IP地址，则UPF使用SMF Set的FQDN向DNS或NRF查询（3GPP TS 29.244: The UPF shall use the IP addresses of alternative SMFs within the SMF Set and the IP addresses of alternative PFCP entities pertaining to the same SMF received during the PFCP association setup or update procedures, if any, or other PFCP entities pertaining to the same SMF. Otherwise the UPF shall use the SMF set FQDN in the CP Node ID to discover alternative SMFs within the SMF Set, e.g. by querying the DNS or by performing a discovery request towards the NRF）。

UPF向新的PFCP实体发送PFCP Session Report Request时，将PFCP消息头部的SEID设置为0，并携带前一个SMF（previous SMF）分配的CP F-SEID（3GPP TS 29.244: When sending the request to the new entity, the UPF shall set the SEID field to zero in the PFCP header of the PFCP request and include the CP F-SEID assigned by the previous SMF in the request）。通常来说，如果SMF从UPF收到的请求中SEID为0，且包含前一个SMF分配的CP F-SEID，SMF会接管PFCP会话，向UPF返回PFCP Session Report Response，并携带自己分配的CP F-SEID。

不过，如果SMF负荷过高，或PFCP会话已经由同一SMF Set的其他SMF接管，SMF会将UPF请求重定向到其他SMF（3GPP TS 29.244: When receiving a request from a UPF with the SEID field set to zero and CP F-SEID assigned by previous SMF, the SMF shall take over the control of the PFCP session from the previous SMF, unless it is needed to redirect the request to a different SMF (e.g. due to high load or because the corresponding session context has already been taken over by a different SMF in the same SMF set)）。重定向有两种方式 —— 第一种方式：SMF直接拒绝UPF请求，并携带原因（Redirection Requested）和新的PFCP实体的IP地址，UPF向新的PFCP实体（再次）发送请求，（依然）将PFCP消息头部的SEID设置为0，并携带前一个SMF分配的CP F-SEID（3GPP TS 29.244: An SMF may redirect a UPF initiated PFCP session related request to another PFCP entity pertaining to the same SMF or to a different SMF in the SMF set by rejecting the request with the cause 'Redirection Requested' and with the IP address of the new entity to contact. When sending the redirected request to the new entity, the UPF shall set the SEID field to zero in the header of the PFCP request and include the CP F-SEID assigned by the previous SMF in the request）。第二种方式：SMF将UPF请求转发另一个PFCP实体（可能属于同一SMF，或同一SMF Set的其他SMF），如果新的PFCP实体接受请求，直接向UPF返回响应，并携带新的CP F-SEID（包含新的PFCP实体的IP地址，以及相同或不同的SEID），可能同时携带用于N4-u隧道的新的F-TEID（3GPP TS 29.244: Alternatively, an SMF may forward the UPF request to another PFCP entity pertaining to the same SMF or to a new SMF in the SMF set; the new PFCP entity or the new SMF answers to the UPF, including the CP F-SEID IE with the IPv4 or IPv6 address of the new entity respectively and the same or a modified SEID, and optionally including the N4-u F-TEID that the UPF shall use for sending data towards the new entity）。