Gx CCR-T replays

Termination of the subscriber-host on the node without termination of the corresponding Gx session in PCRF results in a state mismatch between the node and the PCRF, whereby the host Gx session is present in the PCRF while it is removed from the node.

Some PCRFs can cope with such out-of-sync condition by periodically auditing all existing Gx sessions. For example, a probing RAR can be sent periodically for each active Gx session. The sole purpose of this probing RAR is to solicit a response from the PCEF (node) and provide indication on whether the corresponding Gx session is alive on the node or is vanished. The ‛probing’ RAR can contain an Event-Trigger that is already applied on the node, or if none is applied, then the Event-Trigger can contain NO_EVENT_TRIGGER. In either case, the probing RAR does not cause any specific action to be taken in the node and it is used only to solicit reply from PCRF.

To minimize the impact on performance, probing RARs are sent infrequently; therefore, it may take days to discover a stale Gx session on the PCRF. The node supports a mechanism that can clear the stale session in the PCRF sooner. It does this by replaying CCR-T messages until the correct response from the PCRF is received (CCA-t). The CCR-T messages are replayed up to 24 hours. Both the interval at which the CCR-T messages are replayed and the max-lifetime period are configurable. If the max-lifetime period expires before a valid answer is received, the CCR-T is deleted and a log is generated. The log contains Gx session ID.

The T-bit (retransmission bit) is set in all replayed CCR-T messages.

The following command clears all orphaned sessions on the node for a specified Diameter application policy:

clear subscriber-mgmt diameter-session ccrt-replay diameter-application-policy gx-policy-name sessions