Spending Limit SNRs
A spending limit policy session determines if a balance update can cause a policy change and if it can, the policy is recalculated and MATRIXX Engine sends an Spending-Status-Notification-Request (SNR).
Policies are not recalculated for every balance update, making MATRIXX Policy Application highly efficient. If a group balance updates and a balance range threshold is crossed, an SNR is only sent when a subscriber-specific policy is re-evaluated due to usage. All devices associated with a specific subscriber are updated at the same time and if the policy counter changes, an SNR is sent. MATRIXX Engine does not return an SNR if there is no policy profile associated with the device ID or if the policy tables all result in skips.
- If a policy changes, an SNR is sent.
- If an SNA is received, the SNR trigger and counter are reset. If an SNA is received and it includes a result code other than 2001 SUCCESS, the session is deleted.
- If the policy session is expired, MATRIXX Engine sends an SNR to the PCRF. An SNA can indicate that the session is still
in progress or that the session is not found (by the PCRF). If the session
is not found, it is removed.
MATRIXX Engine uses the last update timestamp on the session object to calculate the elapsed amount of time and compares the value to the session timeout value defined with the system configuration question:
Global:Session:Policy:Notify:How long (in seconds) to wait after the most recent activity before the first attempt?
- Sy SNRs are sent until an answer is received or
until the maximum number of requests set with the system configuration
question:
Global:Session:Policy:Notify:How many attempts?
The delay between requests is configured with the following system configuration question: Global:Session:Policy:Notify:How long (in seconds) to wait after each attempt?
- If MATRIXX Engine does not receive an SNA, the session is deleted.
- If MATRIXX Engine receives an SNA with a result code other than 2001 SUCCESS, the session is deleted.
You can specify a range used to generate a random delay (within the configured range) when sending SNRs for inactive Sy or Nchf_SpendingLimitControl sessions. The default range of 0 seconds specifies no delay when sending SNRs. More sessions require a larger range.
Set the following question: create_config.info question:Global:Session:Policy:Notify:How long (in seconds) to randomize the delay for sending Sy status notification?
You can set a time interval, in seconds, to randomize the delay of policy re-evaluation. The randomized delay is used to avoid packet storms. Zero seconds means no delay is needed.
create_config.info question: Global:Session:Policy:Notify:How long (in seconds) to randomize the delay of policy re-evaluation?
If you set this value to 0, you cannot set the answer to the following question to 0: Global:Session:Policy:Notify:How long (in minutes) is the delay time to trigger the policy re-evaluation?.
For more information about answering this question, see the discussion about look ahead window message timing configuration.
For more information about look ahead windows, see the discussions about look ahead windows for Sy policies and look ahead windows for Gx policies in MATRIXX Policy.
y
to this question, MATRIXX Engine sends an Abort-Session-Request (ASR) message to the GGSN for all Gy sessions on
the same device. - Global:Session:Policy:Notify:How long (in seconds) to wait after the most recent activity before the first attempt?
- Global:Session:Policy:Notify:How long (in seconds) to randomize the delay of policy re-evaluation?
Note: The specified range is used to generate a random delay (within the configured range) when sending SNRs for inactive Sy sessions. Configure the range to 0 (the default) to specify no delay in sending SNRs.
- Global:Session:Charging:Notify:How many attempts?
Policy RARs (Gx RAR or Sy SNR) are not generated for all members of a group when a shared balance changes. For details, see the discussions about re-authorization and abort-session requests in MATRIXX Diameter Integration.