7.6 PCRF Discovery and Selection

23.2033GPPPolicy and charging control architectureRelease 17TS

7.6.1 General principles

This clause describes the underlying principles for PCRF selection and discovery:

– A single logical PCRF entity may be deployed by means of multiple and separately addressable PCRFs.

– The H‑PCRF must be able to correlate the AF service session information received over Rx with the right IP‑CAN session (PCC Session binding).

– The PCRF must be able to associate sessions established over the different reference points (Gx, Rx, S9, Gxa/Gxc, Sd, Np), for the same UE’s IP‑CAN session. The actual reference points that need to be correlated depend on the scenario (e.g. roaming, LBO etc.).

– It shall be possible to deploy a network so that a PCRF may serve only specific PDN(s). For example, PCC may be enabled on a per APN basis.

For the case 2a (as defined in clause 7.1), the same PCRF shall support all the PDNs for which PCC is enabled and for which there are potential users accessing by means of case 2a (as defined in clause 7.1).

It shall also be possible to deploy a network so that the same PCRF can be allocated for all PDN connections for a UE.

– A standardized procedure for contacting the PCRF is preferred to ensure interoperability between PCRFs from different vendors. The procedure may be specific for each reference point. The procedure shall enable the PCRF(s) to coordinate Gx, Rx and, when applicable, Gxa/Gxc, S9, Sd and Np interactions.

– It shall allow that entities contacting the PCRF may be able to provide different sets of information about the UE and PDN connections. For example:

– The AF has information about UE IP address and PDN but may not have user identity information.

– The PDN GW has information about user identity (UE NAI), the APN and the UE IP address(es) for a certain PDN connection.

– For case 2b as defined in clause 7.1, the S‑GW and trusted non-3GPP access has information about the user identity (UE NAI) and, the APN(s) but may not know the UE IP address(es).

– For case 2a as defined in clause 7.1, the trusted non-3GPP access has information about the user identity (UE NAI) and the local IP address (CoA) but may not know the APN or UE IP address(es) (HoA).

– The TDF (when the unsolicited application reporting applies) has the information about UE IP address, but may not have the UE identity.

– The RCAF has the information about the user identity (IMSI) and the APN.

– The DRA has information about the user identity (UE NAI), the APN, the UE IP address(es) and the selected PCRF address for a certain IP‑CAN Session.

When the DRA first receives a request for a certain IP‑CAN Session (e.g. from the PDN GW), the DRA selects a suitable PCRF for the IP‑CAN Session and stores the PCRF address. Subsequently, the DRA can retrieve the selected PCRF address according to the information carried by the incoming requests from other entities (e.g. the AF or the BBERF).

When the IP‑CAN Session terminates, the DRA shall remove the information about the IP‑CAN Session. In case of the PCRF realm change, the information about the IP‑CAN session stored in the old DRA shall be removed.

– All PCRFs in a PLMN belong to one or more Diameter realms. Routing of PCC messages for a UE towards the right Diameter realm in a PLMN is based on standard Diameter routing, as specified in RFC 3588, i.e. based on UE-NAI domain part. A Diameter realm shall provide the ability of routing PCC messages for the same UE and PDN connection to the same PCRF based on the available information supplied by the entities contacting the PCRF.

– A PLMN may be separated into multiple Diameter realms based on the PDN ID information or IP address range. In this case, the relevant information (PDN ID, IP address, etc) shall be used to assist routing PCC message to the appropriate Diameter realm.

– Unique identification of an IP‑CAN session in the PCRF shall be possible based on the (UE ID, PDN ID)-tuple , the (UE IP Address(es), PDN ID)-tuple and the (UE ID, UE IP Address(es), PDN ID).

– Standard IETF RFC 3588 mechanisms and components, e.g. Diameter agents, should be applied to deploy a network where the PCRF implementation specifics are invisible for Diameter clients. The use of Diameter agents, including Diameter redirect agents, shall be permitted, but the use of agents in a certain deployment shall be optional.

NOTE: For the use of private UE IPv4 address TS 29.213 [22] provides guidance.

7.6.2 Solution Principles

In order to ensure that all Diameter sessions for Gx, S9, Gxa/Gxc, Rx, Sd (when the unsolicited application reporting applies) and Np for a certain IP‑CAN session reach the same PCRF when multiple and separately addressable PCRFs have been deployed in a Diameter realm, an optional logical "Diameter Routing Agent (DRA)" function is enabled. This resolution mechanism is not required in networks that utilise a single PCRF per Diameter realm. The DRA has the following roles:

– When deployed, DRA needs to be contacted at first interaction point for a given GW and IP‑CAN session.

NOTE: How subsequent interactions work is described in TS 29.213 [22].

– When deployed, the DRA is on the Diameter routing path when initiating a session with a PCRF over Gx, Rx, Gxa/Gxc, S9 and Sd.

– The DRA is involved at IP‑CAN session establishment by the PDN GW.

– The DRA selects the PCRF at initial attach (IP‑CAN session or Gateway Control session establishment).

– The DRA is involved at Gateway Control session establishment by the S‑GW and trusted non-3GPP access.

– The DRA selects the PCRF at unsolicited service reporting over Sd.

– After IP‑CAN session or Gateway Control Session establishment, the DRA ensures that the same PCRF is contacted for Rx, Gxa/Gxc, Gx, S9, Sd and Np.

– The DRA keeps status of assigned PCRF for a certain UE and IP‑CAN session.

– It is assumed that there is a single logical DRA serving a Diameter realm.

– In roaming scenarios, there is only a single VPCRF for all the PCC sessions (IP‑CAN session, GW control sessions, AF session, etc.) belonging to a single PDN connection of the UE. The VPCRF shall be selected by a DRA in the visited PLMN.

Figure 7.6-1: PCRF selection and discovery using DRA

The DRA functionality should be transparent to the Diameter applications used on the Gx, Gxa/Gxc, S9, Rx, Sd or Np reference points.

In roaming scenario, home routed or local breakout, if the DRA is deployed, the vPCRF is selected by the DRA located in the visited PLMN, and the hPCRF is selected by the DRA located in the home PLMN.

The parameters available for the DRA to be able to determine the already allocated PCRF depend on the reference point over which the DRA is contacted, as described in clause 7.6.1.