# Packet Forwarding Control Protocol

## Summary


Packet Forwarding Control Protocol (PFCP) is a protocol used for communicating between control plane (CP) and user plane (UP) functions in 4G (Release 14 onwards) and 5G networks.  In these networks, the concept of **Control and User Plane Separation (CUPS)** separates the two planes. However, there's a need for these two planes to communicate across the newly defined interfaces. For this purpose, PFCP was defined.

PFCP sits on top on UDP/IP. It functions only in the control plane. A control plane node uses PFCP to associate with one or more user plane nodes and subsequently configure PDU sessions for the user plane. PFCP consists of node-related or session-related messages. Messages and IEs are encoded in TLV format. 

Open source implementations of PFCP are available.

## Discussion

### Where does PFCP fit in?

In 4G EPC, PFCP is used on the **Sx interfaces**. In particular, these are Sxa (SGW-C and SGW-U), Sxb (PGW-C and PGW-U) and Sxc (TDF-C and TDF-U). Due to CUPS, traditional Serving Gateway (SGW) and PDN Gateway (PGW) were split into SGW-C and SGW-U, and PGW-C and PGW-U respectively. PFCP was defined to help these split entities to communicate. The Traffic Detection Function (TDF) is an optional function and it was also split. Its parts also use PFCP.  

It's also possible to combine SGW-C and PGW-C into a single control plane node. Likewise, SGW-U and PGW-U can be combined. These combined entities can communicate using PFCP. 

In 5G, CUPS was applied from the outset, that is, in Release 15. The equivalent control plane and user plane nodes are Session Management Function (SMF) and User Plane Function (UPF). These are connected via the **N4 interface**. PFCP is used on this interface. 

In some scenarios, user plane data packets may be sent on these interfaces between CP and UP functions. However, such packets don't use PFCP. They're sent using GTP-U over UDP/IP. 


### Which are the main procedures in PFCP?

The figure shows the list of PFCP messages, which follow the procedures that PFCP needs to perform: 

    + **Node-related**: Heartbeat (to know if the peer node is alive); Load Control (UP sends CP its current load); Overload Control (UP informs CP that it's overloaded); Association Setup/Update/Release (relate to associating UP with CP); Packet Flow Description (PFD) Management (provision PFDs to UP); Node Report (UP reports non-session-related information to CP).
    + **Session-related**: Session Establishment/Modification/Release (configure rules in the UP to handle packets on a per-session basis); Session Report (UP reports session-specific information to CP).PFCP runs on top of UDP, which doesn't guarantee packet delivery. For this reason, PFCP **retransmits** every request for which a response is not received within a defined timeout. Timeout value and number of retransmissions are implementation specific. A request-response pair share the same sequence number. 

For efficiency, many session-related messages targeting the same peer PFCP entity can be **bundled** together. If bundled messages remain unacknowledged, they may be retransmitted individually. Bundling is not applicable for node-related messages. 


### What's meant by PFCP Association?

Before a UP function can carry packets, it must first be configured by a CP function. It's for this purpose that PFCP exists. However, even before CP configures UP for a session, it must first select a suitable UP. This is exactly what the association procedure achieves. A CP associates with a UP before establishing sessions on the UP. Association allows CP to subsequently use the resources of the UP.  

The association setup procedure may be initiated by either CP or UP. Support for UP-initiated association is optional. Either way, CP and UP exchange their support for PFCP optional features during the association procedure. 

Either CP or UP may initiate the association update procedure. Only CP may initiate the association release procedure. When UP receives a release request message, it shall delete all PFCP sessions and then delete its association with the CP. 

A CP node may be associated with many UP nodes and vice versa. However, a CP-UP pair shall have only one association. 


### What's the packet forwarding model in PFCP?

The CP function configures an associated UP function with Packet Detection Rules (PDRs) for each session. Each PDR contains Packet Detection Information (PDI). A PDI can include UE IP address, SDF filter, QFI, Ethernet packet filter, etc. Each PDR also has associated rules that specify how a packet should be treated, that is, if or how should the packet be forwarded, buffered, dropped, etc. No two PDRs shall have the same PDIs. 

When a data packet comes into the UP function, first task is to identify the packet's PFCP session using provisioned PDRs. Then UP identifies all matching PDRs of the session. PDR with the highest precedence is selected. Finally, the associated rules of this PDR are applied on the packet. 

Packets unmatched by any PDRs are dropped. However, CP may configure UP with a separate session with a PDR containing wildcarded fields. Such a PDR shall have lowest precedence. Such packets may be configured to be dropped or forwarded to CP. 


### Which are the rules signalled by PFCP?

A PFCP session is configured with the following:  

    + **Packet Detection Rule (PDR)**: PDIs are used to identify the PFCP session.
    + **Forwarding Action Rule (FAR)**: Apply Action IE informs UP function if packets are to be forwarded, duplicated, dropped or buffered.
    + **QoS Enforcement Rule (QER)**: QoS enforcement includes gating control, QoS control, DL flow level marking, service class indicator marking and reflective QoS.
    + **Usage Reporting Rule (URR)**: UP function sends traffic reports to CP function. Reports may be volume-based, time-based or both.
    + **Buffer Action Rule (BAR)**: Specifies buffering parameters for FARs whose Apply Action IEs indicate buffering.
    + **Multi-Access Rule (MAR)**: Applicable for multi-access PDU sessions if UP function supports the Access Traffic Steering, Switching, Splitting (ATSSS) feature.FAR, QER, URR and MAR are association with PDRs of the same PFCP session. Only PDR and FAR are mandatory for a session. These rules are configured during session establishment or modification procedures. However, to reduce signalling load, the UP function may be asked to activate pre-defined PDRs. This is permitted for a UP function that has pre-defined FAR, QER and/or URR. 


### How are messages and IEs encoded in PFCP?

PFCP messages and IEs are encoded using **TLV format**. TS 29.244 defines message formats in section 7.2 and IE formats in section 8.1. A PFCP message consists of a PFCP header and zero or more IEs. 

The header is of variable length with flags in the first byte signalling the presence/absence of fields. Session-related messages contain a Session Endpoint Identifier (SEID) that's omitted in node-related messages. 

Message type is signalled with a single byte. Message length takes up two bytes. The length value excludes the first four bytes (which are mandatory) of the PFCP header. 

For each IE, the IE type is signalled with two bytes. IE length takes up two bytes. The length value excludes the first four bytes of the IE. Such an encoding enables forward compatibility. Some IEs are extendable. A legacy receiving entity should ignore extra bytes that it doesn't understand. 

Some IEs can contain other IEs. These are called **Grouped IEs**. Messages carry these grouped IEs. 


### Are there open source implementations of PFCP?

The Open5GS project has C language-based implementation of PFCP. Open5GS is a well-known project with 1300+ stars on its codebase. 

Less well-known implementations include free5GC's PFCP and go-pfcp, both in Go language. A C++ implementation is OpenAirInterface Software Alliance's PFCP. It's associated openair-uml project gives useful class, sequence and activity diagrams. 

The Open Mobile Evolved Core (OMEC) project has Go implementations of UPF, SMF and PFCP simulator. The simulator simulates 4G SGW-C or 5G SMF. It can be used for UPF testing. 


### Which are the patents concerning PFCP?

We note a few patents pertaining to PFCP (though possibly not standardized by 3GPP):

    + WO2021009166A1 (2021): CP configures UP to enable Network Address Translation (NAT) for one or more Service Data Flows (SDFs). An IE for NAT can be part of FAR.
    + 20210297535 (2021): 5G specifications allow UPF to report only traffic volume to SMF. It's foreseen that data analytics may become more important in 5G (NWDAF). By enhancing Reporting Rule, we can report latency, jitter, QoE, etc.
    + WO/2021/254645 (2021): Layer-specific volume reporting would give operators flexibility to charge based on application payload only or include L3/L4 headers.
    + EP3697171B1 (2020): UP-initiated Association Release procedure could be useful when UP functions are shut down for maintenance, prior to which usage reports need to be sent to CP. Correct reporting is needed for policy control and charging.
    + 20200059992 (2020): Using Deep Packet Inspection (DPI), a UP determines if a PDR associated with a PFCP session context needs to be modified or a new PDR created. UP then initiates this change towards CP.
    + US20210281664A1 (2021): This talks about negotiating and compressing PFCP messages on the N4 interface.


## Milestones

Jul  
2015

At the SA WG2 Meeting #S2-110, a study item titled *Feasibility Study on Control and User Plane Separation of EPC nodes* is proposed. This is subsequently approved in September at the 3GPP TSG SA Meeting #69. 

Jun  
2016

3GPP publishes **TR 23.714** titled *Study on control and user plane separation of EPC nodes* as part of Release 14. The document identifies the different issues and possible solutions. The selected solution is a functional split of user plane and control plane functions, including the case of combined SGW/PGW. 

Sep  
2016

3GPP publishes **TS 23.214** that specifies the architectural changes to support CUPS in LTE EPC. This is for Release 14. This evolves for other releases: V15.0.0 (Sep 2017), V16.0.0 (Jun 2019) and V17.0.0 (Jun 2021). 

Mar  
2017

3GPP publishes **TS 29.244**, v1.0.0, titled *Interface between the Control Plane and the User Plane nodes*. This is the main document giving details of PFCP. In June, this is approved for Release 14 as v14.0.0. 

May  
2017

At the IANA (Internet Assigned Numbers Authority), **port number 8805** is assigned to PFCP over UDP. This is destination port number for a PFCP request message. The source port may be any locally assigned number. 

Dec  
2017

As part of 5G Release 15, 3GPP publishes PFCP document TS 29.244, v15.0.0. 

Jun  
2019

As part of 5G Release 16, 3GPP publishes PFCP document TS 29.244, v16.0.0. This update includes Enhanced PFCP Association Release, Deferred PDR activation/deactivation, Activation/Deactivation of pre-defined PDRs, Multi-Access Action Rule, ATSSS support, and more. With v16.1.0 (September 2019), PFCP messages bundling is introduced. 

Mar  
2021

As part of 5G Release 17, 3GPP publishes PFCP document TS 29.244, v17.0.0. This includes support of Radius, Diameter or DHCP communication via UPF, and partial failure handling over the N4 interface. With v17.1.0 (June 2021) there's support for multi-access PDU sessions and per QoS flow performance measurement. 

Mar  
2022

3GPP publishes **TR 29.820**, v17.0.0, titled *Study on Best Practice of PFCP*. These best practices lead to better interoperability such as when SMF is deployed centrally at the operator side while UPF is deployed locally at the customer side. Over the N16a interface, I-SMF and SMF have to be interoperable since PFCP IEs are sent over this interface.