Subscriber Policy Management (Gx)

Overview

Subscriber Policy Management enables service providers to enforce dynamic, scalable policies for subscriber traffic using the Policy and Charging Rules Function (PCRF) and Policy and Charging Enforcement Function (PCEF) architecture. It integrates with the Gx Interface using the Diameter protocol, allowing centralized policy enforcement in real-time for telecommunications networks.

Why Subscriber Policy Management (Gx)

Subscriber Policy Management ensures that the service provider’s network:

• Delivers services that adhere to Quality of Service (QoS) rules.

• Complies with subscriber agreements and business policies.

• Dynamically enforces policies, such as bandwidth prioritization or application control, across the network.

• Scales to handle a growing number of concurrent subscribers and sessions.

Configuring policies from a PCRF rather than locally on each PCEF provides:

Benefit	Description
Centralization	Manage all policies from a single control point
Scalability	Add enforcement points without duplicating configuration
Flexibility	Dynamically update policies without touching individual nodes
Consistency	Apply uniform rules across your entire network

How policies are fetched and applied

When the CNF is configured to get policies from the PCRF (dynamically), the Cloud-Native Function (CNF) establishes Diameter connectivity to the PCRF. During subscriber session creation, the Policy and Enforcement Module (PEM) retrieves policy information through Gx and stores it in the PEM subscriber session. When subscriber traffic arrives, PEM evaluates the stored policies and applies the appropriate actions on specific flows.

Architecture

System Design

The Subscriber Policy Management system leverages the following key components, interfaces, and protocols:

• PCRF: Centralized policy decision-making engine that dynamically manages rules to enforce QoS, charging, and bandwidth limits for subscribers. It is responsible for:

  • Provisioning rules to the PCEF via the Gx Interface.

  • Managing real-time session status and policy enforcement for millions of subscribers.

  • Ensuring consistency and scalability across multiple nodes in the network.

• PCEF: Packet flow analysis and enforcement engine that applies PCRF-defined policies to subscriber traffic flows. It ensures real-time application of QoS rules.

• Gx Interface: A crucial Diameter protocol-based communication reference point located between the PCRF and PCEF. Functions of the Gx Interface include:

  • Provisioning and removal of PCC rules.

  • Real-time updates to subscriber session status.

  • Transmission of traffic plane events for policy evaluation.

Communication between the PCEF and PCRF uses the Diameter protocol in a peer-to-peer architecture. In a typical deployment, the PCRF acts as the server and the PCEF acts as the client.

Data Flow and Communication

Policy Flow

• When a subscriber session is created, the PEM requests policy information from the PCRF through the Gx interface. In operational terms, subscribers can be treated as known or unknown:

  • Known subscriber

    • A subscriber for which the CNF/PEM can derive a stable Subscriber ID (for example IMSI/NAI/E.164) and establish a normal subscriber session.

    • PEM performs Gx session establishment and policy retrieval (for example, CCR-I → CCA-I) using the configured subscriberId mapping in the Diameter protocol profile.

    • Retrieved policy rules are stored in the PEM session and applied to subsequent subscriber flows.

  • Unknown subscriber

    • A subscriber/flow that arrives without sufficient subscriber identity/session context to map it to a known subscriber session (for example, missing/invalid subscriber identifier, subscriber not yet provisioned, or identity not available at the time traffic arrives).

    • The system may still create a minimal/temporary session representation (implementation dependent) and can attempt Gx policy retrieval using whatever identity is available.

    • If PCRF requires a valid Subscriber ID and the CNF cannot provide it, Gx policy retrieval may fail or be skipped, and default/local handling applies until the subscriber becomes known.

• PCRF can provide dynamic rules (non-referential rules) or refer to the rules configured on the CNF (referential rules) based on subscriber’s profile (IMSI ID, username, and so on). The received policy information is stored as part of the PEM session.

• The PCEF evaluates each received packet against the service data flow filters of PCC rules, in order of precedence. When a packet matches a service data flow filter, the corresponding PCC rule is applied.

• Multi-pod scale-up and scale-down behavior:

  • Scale-up behavior: During scale-up operations, newly provisioned pods may fail to synchronize active PCRF session contexts associated with AF identifiers (such as IP, IMSI, NAI, or E164). This lack of synchronization disrupts session binding and results in inconsistent RAR processing across pods. As a result, duplicate or fragmented credit management sessions may be established with the OCS, since PCRF interactions are distributed without coordinated session state sharing.

  • Scale-down behavior: During scale-down events, the persistence of session bindings is compromised when pods hosting active sessions are terminated. This can lead to the loss of session state for active IP CAN bearers, thereby disrupting credit pooling mechanisms and re-authorization workflows. Consequently, credit control anomalies may arise, including unaccounted termination actions, failed re-authorizations, and fragmented pooling for charging keys.

PCC rule types

There are two types of PCC rules:

• Dynamic rules (non-referential) — The PCRF provisions these rules to the PCEF through the Gx interface. You can install, modify, and remove them at any time.

• Predefined rules (referential) — These rules are preconfigured on the PCEF. The PCRF activates or deactivates them as needed. You can group predefined rules to activate a set of them simultaneously.

Custom Resource Definitions (CRDs)

CRDs are deployed on Kubernetes to define objects for Diameter configuration:

• F5DiameterAvp: Defines AVPs used in Diameter messages.

• F5DiameterProtocolProfile: Configures protocol-specific settings for supported Diameter messages.

• F5DiameterEndpoint: Defines endpoint-specific Diameter parameters.

Subscriber Policy Management Flow Architecture Diagram

Prerequisites

Before you configure subscriber policy management with the Gx interface, ensure that you have:

• A working PCRF deployment in your network

• Network connectivity between the PCEF and the PCRF over the Diameter protocol

• Familiarity with PCC rules and QoS concepts

Procedures

Create Diameter AVPs (only if missing)

If your environment does not provide default AVPs (or you need vendor-specific additions), create AVPs.

1. Copy the following example into the diameter-avp.yaml file.

2. Run the following command to create diameter AVPs:

   kubectl apply -f diameter-avp.yaml -n <namespace>
   

3. Verify that the diameter AVPs are created.

Note

Ensure that avpCode, vendorId, and dataType align with the 3GPP/RFC definitions and your PCRF implementation. For grouped AVPs, utilize dataType: grouped along with parentAvp to accommodate message structures that require grouping.

Apply Diameter Protocol Profile for Gx

A Diameter protocol profile describes which messages and AVPs are used for Gx.

1. Copy the following example into the diameter-protocol-profile-gx.yaml file.

2. Run the following command to apply the diameter protocol profile for Gx:

   kubectl apply -f diameter-protocol-profile-gx.yaml -n <namespace>
   

3. Verify that the diameter protocol profile for Gx is applied.

Note

Include all required message types for data exchange with the PCRF, such as initiation messages (ccr-i, cca-i), update messages (ccr-u, cca-u) if the PCRF supports session updates, watchdog messages (dwr/dwa) for connection monitoring, and capabilities exchange (cea) if required. Configure the flagMandatory parameter in accordance with your PCRF specifications.

Apply Diameter Endpoint Profile (PCRF connectivity)

The endpoint profile represents the PCRF peer and how CNF behaves when sending Diameter messages.

1. Copy the following example into the diameter-endpoint-profile-gx.yaml file.

2. Run the following command to apply the diameter endpoint profile for Gx:

   kubectl apply -f diameter-endpoint-profile-gx.yaml -n <namespace>
   

3. Verify that the diameter endpoint profile for Gx is applied.

Note

Verify that the destinationHost and destinationRealm parameters correspond to the PCRF configuration. Similarly, ensure that originHost and originRealm are set to values accepted by the PCRF. Use msgMaxRetransmits and msgRetransmitDelay to adjust retry behavior in cases of PCRF slowness or packet loss. Configure fatalGraceTime to define system behavior during fatal peer failures.

Apply Diameter Endpoint Profile to the Secure Context

Create (or update) a secure context for the Diameter TCP connection to PCRF and attach the endpoint profile.

1. Copy the following example into the secure-context-diameter-gx.yaml file.

2. Apply the Secure Context CR:

   kubectl apply -f secure-context-diameter-gx.yaml -n <namespace>
   

3. Verify that the diameter secure context is applied.