PFCP protocol

The core of session management is the PFCP protocol as defined in 3GPP TS 29.244, with BNG-specific extensions defined in BBF TR-459.

Protocol stack

The PFCP protocol runs on top of UDP/IP. The UDP destination port for a request message uses port 8805, which is the registered port number for the PFCP protocol.

The following figure shows the PFCP protocol stack for the control plane.

Figure 1. PFCP protocol stack for the control plane


Note: The maximum supported PFCP message size is 8192 bytes. If the PFCP link MTU size is limited to 1500 bytes, Nokia recommends enabling IP address reassembly.

Generic PFCP message header

The following table describes the format of the generic PFCP message header.

Table 1. Generic PFCP message header
Bits
Octets 8 7 6 5 4 3 2 1
1 Version Spare Spare Spare MP S
2 Message Type
3 Message Length (1st Octet)
4 Message Length (2nd Octet)
m to (m+7) If S=1, octets 5 to 12 contain the SEID If S=0, the SEID field is not present
n to (n+2) Sequence Number
n+3 Message Priority Spare
The following clarifies the fields in the message header.
  • MP indicates whether the Message Priority field is set. The Message Priority field is only set for messages related to a PFCP session.
  • S indicates whether the SEID field is present. Messages related to a PFCP session always contain a session ID.
  • Message Type indicates the type of the message and determines the content of the message beyond the header.
  • Message Length is the total length of the packet.
  • SEID is the session ID. When the session ID is not known (for example, for the first message in a session), the session ID is set to 0. During PFCP session establishment, both the BNG-UP and the MAG-c allocate an SEID and signal their SEID to the other peer. Any subsequent message must use the SEID of the peer in the message header. See PFCP session ID allocation and use for an example of SEID allocation and use.
  • Sequence Number is used to detect retransmission of PFCP packets.
  • Message Priority defines a relative strict priority for the message processing. See TS 29.244 for more information.
Figure 2. PFCP session ID allocation and use


PFCP messages overview

Table 2. PFCP messages overview
Message Description
PFCP Association Setup Request The BNG-UP or the MAG-c starts a PFCP association. Feature capabilities and node-wide parameters are exchanged.
PFCP Association Setup Response The BNG-UP or the MAG-c confirms the PFCP association.
PFCP Association Update Request The BNG-UP or the MAG-c updates feature capabilities or node-wide parameters.

The BNG-UP can request the MAG-c to gracefully tear down the PFCP association.
PFCP Association Update Response The BNG-UP or the MAG-c confirms the update.
PFCP Association Release Request The MAG-c tears down the PFCP association.
PFCP Association Release Response The BNG-UP confirms the teardown.
PFCP Heartbeat Request The BNG-UP or the MAG-c checks connectivity.
PFCP Heartbeat Response The BNG-UP or the MAG-c confirms connectivity.
PFCP Session Establishment Request The MAG-c creates a new PFCP session. The message contains all parameters necessary to correctly create the forwarding state or in-band control plane state.
PFCP Session Establishment Response The BNG-UP confirms the creation of the PFCP session. The message contains the value of related BNG-UP parameters, such as the SEID.
PFCP Session Modification Request The MAG-c updates parameters of a PFCP session or requests an update of the usage information (counters).
PFCP Session Modification Response The BNG-UP confirms the modification. The message can contain updated related BNG-UP parameters or usage information (counters) or both.
PFCP Session Deletion Request The MAG-c removes a PFCP session and its related state information. Possible reasons for removal include the following.
  • The subscriber session triggers removal (DHCP release or PADT).
  • The AAA service triggers removal (RADIUS Disconnect).
  • The operator triggers removal for administrative purposes (clear command).
PFCP Session Deletion Response The BNG-UP confirms the removal. The message includes a final usage update (counters).
PFCP Session Report Request The BNG-UP notifies the MAG-c of usage information updates (counters) or other state changes (for example, LCP keep-alive failures).
PFCP Session Report Response The MAG-c confirms receipt of the report.

Example call flows

Get a description of call flow examples, including PFCP association and session setup, CoA handling, MAG-c triggered updates, and PFCP connectivity failure.

Initial PFCP association and session setup

When either a MAG-c or a BNG-UP comes online, it sets up a PFCP association. The association request can be triggered either from the BNG-UP or from the MAG-c.

The following figure shows the initial PFCP association and session setup.

Figure 3. Initial PFCP association and session setup


Description of the call flow

  1. The MAG-c initializes the PFCP association setup and the BNG-UP responds. During the association setup, both the BNG-UP and the MAG-c exchange parameters.
  2. The MAG-c immediately initializes the BNG-UP with PDRs for the forwarding of initial in-band control plane packets using the PFCP session establishment procedure. For more information, see Default IBCP session.
  3. To monitor connectivity, periodic heartbeat messages are exchanged between the BNG-UP and the MAG-c.

IPoE session setup

When the BNG-UP receives a DHCP Discover message from an RG, it forwards the message to the MAG-c over the CPRi interface. The MAG-c initiates the setup of the IPoE session.

The following figure shows the IPoE session setup.

Figure 4. IPoE session setup


Prerequisites

  • The BNG-UP has a PFCP association with the MAG-c.
  • The MAG-c initialized the BNG-UP with PDRs for the forwarding of control plane packets over the CPRi interface (GTP-U).

Description of the call flow

  1. The BNG-UP forwards a DHCP Discover packet to the MAG-c over the CPRi interface (GTP-U, default IBCP tunnel).
  2. The MAG-c authorizes the IPoE session based on parameters in the DHCP message.
  3. The MAG-c initializes the PFCP session and creates data plane rules and per-session IBCP tunnels on the BNG-UP (PFCP session establishment procedure).
  4. The MAG-c sends a DHCP Offer over the CPRi interface (GTP-U, per- session IBCP tunnel) to the BNG-UP. The BNG-UP decapsulates the DHCP packet and sends the packet to the RG.
  5. The BNG-UP forwards the DHCP Request packet to the MAG-c over the CPRi interface (GTP-U, per-session IBCP tunnel).
  6. The MAG-c sends the DHCP Ack over the CPRi interface (GTP-U, per- session IBCP tunnel) to the BNG-UP. The BNG-UP decapsulates the DHCP packet and sends the packet to the RG.
  7. If accounting is provisioned, the MAG-c starts accounting for the session.

CoA handling

When the RADIUS server requests a change in client authorization for an active session, the MAG-c triggers the BNG-UP with the needed modifications.

The following figure shows the call flow process.

Figure 5. CoA handling


Description of the call flow

  1. The AAA server sends a CoA request directly to the MAG-c.
  2. The MAG-c processes the message and translates it to the necessary BNG-UP state changes. The state changes are signaled via a PFCP session modification procedure.

    If the MAG-c determines that no BNG-UP changes are required, the PFCP session modification procedure is skipped.

  3. The MAG-c sends the CoA Ack to the AAA server.

MAG-c triggered updates

To perform specific tasks, the OSS may send a trigger to the MAG-c. An example of a specific task is getting up-to-date forwarding statistics for a specific subscriber session.

The following figure shows a MAG-c triggered accounting update.

Figure 6. MAG-c triggered accounting update


Description of the call flow

  1. The OSS requests up-to-date forwarding statistics from the MAG-c.
  2. The MAG-c processes the message and sends a PFCP Session Modification Request to the BNG-UP. The request contains the Query URR IE.
  3. The BNG-UP sends the requested report in a PFCP Session Modification Response.
  4. The MAG-c sends up-to-date forwarding statistics to the OSS.

PFCP connectivity failure and headless mode

PFCP heartbeat messages check the connectivity of a PFCP path. When the heartbeat procedure fails, all state information for the corresponding path is removed and all sessions using that path are terminated. The association remains in place.

To protect against temporary failures, the MAG-c and the BNG-UP support a headless mode. When headless mode is enabled, the sessions are not removed when there is a heartbeat failure. Instead, a configured timer is started and heartbeats continue to be sent.

The following figure shows an example call flow of the heartbeat procedure with headless mode in case of a PFCP connectivity failure. In the example call flow, the path is restored and a PFCP audit procedure is started.

For more information, see MAG-c Control Plane Function Guide, section PFCP connectivity failure.

Figure 7. Example headless mode call flow


Description of the call flow

  1. The MAG-c discovers a connectivity failure on the PFCP path and starts the path-restoration timer.
  2. The MAG-c and the BNG-UP exchange heartbeat messages successfully before the path-restoration timer period ends.
  3. The MAG-c signals the start of an audit to the BNG-UP.
  4. The BNG-UP acknowledges the start of the audit. The MAG-c audits all known sessions on the path.
  5. The MAG-c signals the end of the audit to the BNG-UP.
  6. The BNG-UP acknowledges the end of the audit and removes all non-audited sessions on the path.