Introduction to PFCP and CUPS concepts

The interfaces between the MAG-c and the BNG-UP that are related to PFCP are the SCi, CPRi, Sx, N4, Sx-u, and N4-u interfaces. Get a brief overview of those interfaces and of general CUPS and BNG concepts, including PFCP association and path, PFCP session, and PDR.

PFCP in the CUPS architecture

The interfaces between the MAG-c and the BNG-UP that are related to PFCP are the SCi, CPRi, Sx, N4, Sx-u, and N4-u interfaces.

The following lists the interfaces between the MAG-c and the BNG UP.

  • SCi, Sx, N4

    The MAG-c creates traffic forwarding rules and related states on the BNG-UP via these interfaces. When the rules and states are created, the BNG-UP forwards subscriber data traffic according to the rules. The Sx interface is defined by 3GPP for 4G sessions, while the N4 interface is defined for 5G sessions. 3GPP defines these interfaces mainly in TS 29.244. The SCi interface is an extension added for pure BNG sessions as defined in TR-459 and is based on TS 29.244.

  • CPRi, Sx-u, N4-u

    The BNG-UP and MAG-c use these interfaces to forward and tunnel control packets; for example, DHCP discovery, PPPoE PADI. All these interfaces use GTP-U as the tunnel transport layer and these tunnels are configured using the PFCP protocol. Sx-u and N4-u are the 3GPP terms defined in TS 29.244 in context of 4G and 5G sessions, while CPRi is the BBF term defined in TR-459, but all imply the same concept. Nokia often using the term in-band control plane (IBCP) to indicate any of these interfaces.

CUPS concepts

Get a brief overview of general CUPS and BNG concepts. See 3GPP TS 29.244 for more information about the CUPS concepts.

PFCP association and path

The PFCP association and path define the connectivity between the MAG-c and BNG-UP.

To send a session to a BNG-UP, a PFCP association needs to be established. While establishing this association, the BNG-UP and the MAG-c exchange capabilities, functional features, and parameters; for example, a BNG-UP sends functional features such as PPPoE support, IPoE support, and LCP Keep-alive Offload support. Capability exchange can influence the IE applicability in PFCP session messages.

  • PFCP association

    A PFCP association must be set up before sessions can be established between the BNG-UP and the MAG-c. Only one association per MAG-c and BNG-UP pair is allowed. The identifiers of the association are the MAG-c and the BNG-UP node IDs, which can be IP addresses or domain names. Provisioning commands specific to PFCP associations allow to enable the PFCP protocol.

  • PFPC path

    Multiple paths are possible per PFCP association. The identifier of a PFCP path is the pair of IP addresses used to communicate between the MAG-c and the BNG-UP. Paths are not negotiated but are learned while using PFCP signaling. Each IP address is called a PFCP entity. Each pair of MAG-c and BNG-UP IP addresses is called a PFCP path.

Note:

  • The Nokia MAG-c uses only one IP address per association, although in general a MAG-c or BNG-UP (also called a PFCP node) could use multiple IP addresses for communication within the same PFCP association. Because the Nokia MAG-c and BNG-UP use only one PFCP path per association, the terms path and association are often used interchangeably.

  • Both the MAG-c and BNG-UP verify that all known paths are alive using PFCP heartbeat messages. The heartbeat parameters are configured in the context of the PFCP profile. When a path fails, all related sessions are removed.

PFCP session

A session is the basic operational object of the BNG and represents the connectivity of a single device such as a residential gateway. Address assignment, authentication, accounting, and BNG-UP communication are all done in the scope of a single session. A PFCP association is needed to create a PFCP session.

Packet data rule

Packet data rules (PDRs) are the building blocks to create a correct forwarding state on the BNG-UP.

The PFCP sessions are containers for PDRs. Each PDR defines a unidirectional traffic flow and the rules associated with that flow. The BNG-UP adheres to the PDR rules when treating the traffic for the defined traffic flow.

A PDR consists of the following sub-objects and references.

  • PDI

    The packet detection information (PDI ) is a sub-object and specifies the match criteria for the packet. It also contains a reference to a traffic endpoint.

  • FAR ID

    The forwarding action rule (FAR) specifies the action (for example, drop, forward, mirror) for matching packets. The PDR refers to one FAR. FARs can be shared between multiple PDRs within a session.

  • QER ID

    The QoS enforcement rule (QER) specifies the QoS treatment for matching packets (for example, GBR, MBR). The PDR refers to one or multiple QERs. QERs can be shared between multiple PDRs within a session and between sessions.

    Multiple PDRs of one session share the same QER using the QER ID, while multiple PDRs of different sessions share the same QER using the QER correlation ID.

  • URR ID

    The usage reporting rule (URR) specifies the usage reporting and charging for matching packets. The PDR refers to one or multiple URRs. URRs can be shared between multiple PDRs within a session.

Note: The Nokia BNG CUPS solution supports only one QER and one URR per PDR.