Packet Forwarding Control Protocol is a 3GPP protocol used on the Sx/N4 interface between the control plane and the user plane function, specified in TS 29.244. It is one of the main protocols introduced in the 5GNext GenerationMobileCore Network, but also used in the 4G/LTEEPC to implement the Control and User Plane Separation. PFCP and the associated interfaces seek to formalize the interactions between different types of functional elements used in the Mobile Core Networks as deployed by most operators providing 4G, as well as 5G, services to mobile subscribers. These 2 types of components are:
The Control Plane functional elements, handling mostly signaling procedures
The User-data Plane functional elements, handling mostly packet forwarding, based on rules set by the CP elements.
PFCP's scope is similar to that of OpenFlow, however it was engineered to serve the particular use-case of Mobile Core Networks.
Overview
Albeit similar to GTP in concepts and implementation, PFCP is complementary to it. It provides the control means for a signaling component of the Control-Plane to manage packet processing and forwarding performed by an User-Plane component. Typical EPC or 5G Packet Gateways are split by the protocol in 2 functional parts, allowing for a more natural evolution and scalability. The PFCP protocol is used on the following 3GPP mobile core interfaces:
Sxa - between SGW-C and SGW-U
Sxb - between PGW-C and PGW-U
Sxc - between TDF-C and TDF-U
N4 - between SMF and UPF
Note: Sxa and Sxb can be combined, in case a merged SGW/PGW is implemented.
Functionality
The Control-Plane functional element controls the packet processing and forwarding in the User-Plane functional elements, by establishing, modifying or deleting PFCP Sessions. User plane packets shall be forwarded between the CP and UP functions by encapsulating the user plane packets using GTP-U encapsulation. For forwarding data from the UP function to the CP function, the CP function shall provision PDR per PFCP session context, with the PDI identifying the user plane traffic to forward to the CP function and with a FAR set with the Destination Interface "CP function side" and set to perform GTP-U encapsulation and to forward the packets to a GTP-u F-TEID uniquely assigned in the CP function per PFCP session and PDR. The CP function shall then identify the PDN connection and the bearer to which the forwarded data belongs by the F-TEID in the header of the encapsulating GTP-U packet. For forwarding data from the CP function to the UP function, the CP function shall provision one or more PDR per PFCP session context, with the PDI set with the Source Interface "CP function side" and identifying the GTP-u F-TEID uniquely assigned in the UP function per PDR, and with a FAR set to perform GTP-U decapsulation and to forward the packets to the intended destination. URRs and QERs may also be configured. Per session multiple PDRs, FARs, QERs, URR and/or BARs are sent. Here are the main concepts used, organized in their logical association model:
PDRs - Packet Detection Rules - contain information for matching data packets to certain processing rules. Both outer encapsulation and inner user-plane headers can be matched. The following rules can be applied on positive matching:
* FARs - Forwarding Action Rules - whether and how the packets matching PDRs should be dropped, forwarded, buffered or duplicated, including a trigger for first packet notification; it includes packet encapsulation or header enrichment rules. In case of buffering, the following rules can be applied:
** BARs - Buffering Action Rules - how much data to buffer and how to notify the Control-Plane.
* QERs - QoS Enforcement Rules - rules for providing Gating and QoS Control, flow and service level marking.
* URRs - Usage Reporting Rules - contain rules for counting and reporting traffic handled by the User-Plane function, generating reports to enable charging functionality in the Control-Plane functions.
Messages
IEs are defined either as having a proprietary encoding, or as grouped. Grouped IEs are simply a list of other IEs, encoded one after the other like in the PFCP Message Payload. IE Types 0..32767 are 3GPP specific and do not have an Enterprise-ID set. IE Types 32768..65535 can be used by custom implementation and the Enterprise-ID must be set to the IANA SMI Network ManagementPrivate Enterprise Codes of the issuing party.
Messages
Transport
Very similar to GTP-C, PFCP uses UDP. Port 8805 is reserved. For reliability, a similar re-transmission strategy as for GTP-C is employed, lost messages being sent N1-times at T1-intervals. Transactions are identified by the 3-byte long Sequence Number, the IP address and port of the communication peer. The protocol includes an own Heart-beat Request/Response model, which allows monitoring the availability of communication peers and detecting restarts. For User-Plane packet exchanges between the Control and User Plane functional elements, GTP-U for the Sx-u interface, or alternatively a simpler UDP or Ethernet encapsulation for the N4-u interface.
