G.4 DRA Diameter Overload Behavior

29.2133GPPPolicy and charging control signalling flows and Quality of Service (QoS) parameter mappingRelease 17TS

The DRA may optionally incorporate agent behavior specified in IETF RFC 7683 [33].

G.4.1 DRA reacting to Host Reports

The procedures defined in this clause are only applicable to the proxy DRA (PA1 and PA2) as the redirect DRA is not in the path of application answers and as such does not have access to overload reports from other nodes.

The proxy DRA shall use host reports as one of the inputs when making routing decisions for realm-routed requests, i.e. requests that do not contain a Destination-Host AVP. This is needed because entities sending such requests are not aware of the final recipient of the request (e.g. specific PCRF instance).

The following scenarios shall be addressed:

– No binding exists for the request and the request can result in a new binding (e.g. IP-CAN session establishment); in this case the DRA is selecting the PCRF that will handle the binding. The DRA should use any active and relevant Diameter overload host reports as one of the inputs to the selection of the PCRF. If all PCRFs are in an overload state, the DRA should reduce traffic sent to each of the PCRFs based on the individual host requested traffic reduction. This may result in the DRA rejecting the request.

– A binding already exists for the request – In this case the DRA should reduce the traffic sent to the overloaded node by the host requested traffic reduction. This may result in the DRA rejecting the request.

NOTE: Result-Code when rejecting a request in the above cases need to be used according to the IETF RFC 7683 [33].

How the DRA achieves any requested traffic reduction is implementation dependent and/or based on operator policy.

Annex H (normative):
Access specific procedures for 3GPP EPS