Gy Re-Auth-Request (RAR) Message

MATRIXX Engine sends a Re-Auth Request (RAR) to the network for a subscriber-management (SubMan) request, when an open session is perceived as inactive, or on content quota expiration.

Diameter Gateway acts like a Diameter client when sending RARs. It uses the source host and realm information stored in a session to decide where to send each RAR for a session. When searching for an existing connection, Diameter Gateway looks for the connection based on the normalized host/realm so that common host names with different realms can co-exist. In this situation, normalized means that searches for host/realm names are case insensitive; a host/realm of FOO/BAR also matches foo/bar.

RAR Generation

The MATRIXX Engine generates RARs in the following circumstances:

SubMan requests — Re-authorizations are triggered when changes are made in MATRIXX Engine, such as when a subscriber purchases a catalog item. This includes SubMan requests such as offer purchase/cancel, object status modification, an explicit "validate-session" request, or a RAR retry.
The Charging Server checks if a RAR was sent and a RAA was received. If a RAA was not received, another RAR is not sent.
Session inactivity — Sessions are considered inactive after a configurable time has passed after the most recent request for further action has been received. This allows you to clean up open sessions that are invalid, for example, when the PCEF loses session state.
Context quota expiration — A configurable time after its quota Validity-Time (QVT) has elapsed.

RAR Settings

Integrators can configure the following behavior for Gy Re-Auth-Requests:

Disable Gy / N40 RARs during global configuration.
Important: Disabling RARs is not recommended in production systems.
Disable sending RARs for a specific service context type. When editing a service context type in My MATRIXX, you can set if RARs are disabled for a specific service context type.
Note: Some RARs do not consider the specific service context; to ensure all RARs are disabled,disable all service contexts by answering y to the following global configuration question:Global:Session:Charging:Notify:Disable Re-Authorization Requests (y/n)?
Send a RAR when quota expires.
The amount of time to wait before sending an initial RAR after the quota expires.
After sending the initial RAR, the amount of time to wait between sending each additional RAR.
The total number of RARs to send when no Re-Auth-Answer (RAA) messages are received, before cleaning up the session.
Send a RAR when a subscriber with an open session purchases a catalog item.
Send a RAR when a subscriber purchases a catalog item that is granted to a tier group for each open session of each subscriber in the group.
Note: This allows the recharge for a shared asset to be made immediately available to all subscribers in the group. In this context, a purchase is a grant component that performs a grant to the group tier. It can be invoked by an explicit catalog item purchase or by a first-use grant from an on-demand balance.
Send a RAR to each member in a group with an open session when the group purchases a catalog item.
Note: For subscriber or group catalog item purchases, a RAR is sent and the GGSN replies with the actual usage and quota reauthorization. The purchased catalog item rate is applied to any new quota. If the maximum request value is zero, only one RAR is sent and no more RARs are sent. An RAR is only triggered when a catalog item is purchased. An RAR is not triggered for a catalog item cancellation or expiration.
Send a RAR when a subscriber with an open session cancels a catalog item.
Send a RAR to each member in a group with an open session when the group cancels a catalog item.
Send a RAR after the status of a subscriber or a device is changed and the subscriber or device has open sessions.
Send a RAR after the status of a group is changed and one or more group members has open sessions.
How many subscribers per transaction are processed for the RAR on group purchase/cancel catalog item.
The session expiration time in seconds.
Note: RARs are enabled individually for quota expiration, subscriber catalog item purchases, and group catalog item purchases.

RAR Processing

The following scenario describes a typical RAR management process:

For session inactivity and SubMan requests, the Gy RAR is sent to the PCEF with a Session-Id but without a Rating-Group or Service-Identifier AVP. This causes a reauthorization of any sessions and contexts with outstanding quotas. The PCEF then replies with a RAA, followed by one or more CCRs to reauthorize the session, including MSCC AVPs to reauthorize those contexts.
- If RAR for Subscriber purchase offer is enabled, when a subscriber purchases a catalog item, a RAR is sent for every charging session of every device associated with the subscriber.
  Note: Charging Server sends a RAR when an offer is purchased or activated. If you purchase an offer in a pre-active state, you get one RAR at purchase time and one RAR when the offer is activated.
- If RAR for subscriber purchase offers granted in a tier group is enabled, if a catalog item is purchased by a subscriber and granted to a tier group, a RAR is sent for each open session of each subscriber in the group and in the subgroup. This allows the recharge of a shared asset to be made immediately available to all subscribers in the group. In this context, a purchase is a grant component that performs a grant to the group tier. It can be invoked by an explicit offer purchase or by a first-use grant from an on-demand balance.
- If RAR for group purchase offers is enabled, if a catalog item is purchased by or for a group, a RAR is sent for each open session of each subscriber in the group and in the subgroup after a catalog item is purchased by or for a group.
- If no messages have been received, no RARs have been sent, or RARs have timed out (no activity), and no quota is reserved on any of the contexts (for example, the QHT on the quota is expired) on the session after the configured session expiration time, a RAR is sent for the whole session without Rating Group and Service Id values.
If quota expiration is enabled and quota expires after a configured initial delay, the MATRIXX OCS sends a Gy RAR with the Rating-Group and/or Service-Identifier of the context whose quota is expired, and expects a RAA followed by a CCR with an MSCC AVP to reauthorize that context. This may result in multiple concurrent RARs if multiple quotas expire at once.
The RAR is sent up to the configured maximum number of RARs with each RAR sent after the configured delay until a RAA is received. If no RAA is received after the configurable number of times, the session is deleted.
If a RAA is received and is an acknowledgment of the session (the session is authorized), no more RARs are sent for that context in the session. If Rating Group is not defined in the RAA, no more RARs are sent for all contexts in the session. The MATRIXX Engine records the new timestamp so it knows the amount of time that has passed after the last message was received from the network and resets the RAR counter. This ensures that session cleanup occurs after the last usage or RAR is sent.
If a RAA is received and it includes a result code other than 2001 SUCCESS or 2002 LIMITED SUCCESS, the session is deleted.

RAR Configuration

By default, RAR functionality is enabled. During engine configuration, enable parameters for specific RAR functionality. RAR Configuration lists the create_config.info questions for enabling RAR functionality. To disable RAR functionality, answer y to the following question during engine configuration:

Global:Session:Charging:Notify:Disable Re-Authorization Requests (y/n)?

If you answer y to this question, configuration questions for additional RAR parameters are not asked. If you answer y, session RARs are not sent and if a session is expired, it is deleted after the configured value for the RAR session inactivity period.

Note: This setting does not affect the Policy Gx RAR and Sy SNR settings.

To control how many subscribers per transaction are processed for the RAR on group purchase offers, add the following to an sed file.

s@rar_group_subscribers_per_chunk>.*<@rar_group_subscribers_per_chunk>10<@

RAR Configuration lists the RAR configuration parameters, and the create_config.info file questions that set them.

Table 1. RAR Configuration
Parameter	Question	Default Value	Description
Notifications for Gy and 5G Charging — Disable	`Global:Session:Charging:Notify:Disable Re-Authorization Requests (y/n)?`	n	Controls whether 5G or Gy charging notifications are sent. Does not create additional questions, however you can still configure the "Gy RAR — Session Inactivity Period" question if you answer `y` to the following create_config.info question: `Global:Session:Charging:Notify:Disable Re-AuthorizationRequests (y/n)?` CAUTION: Disabling RARs is not recommended in production systems.
Notifications for Gy and 5G Charging — QVT Initial Wait Time	`Global:Session:Charging:Notify:How long (in seconds) to wait after the QVT expires?`	n	Sets a time interval, in seconds, for how long to wait after the quota validity time (QVT) expires to send the initial notification. When enabled, one RAR is sent after (QVT + Initial Wait Time). An RAR is sent after the Interval Size delay.
Notifications for Gy and 5G Charging — Subscriber Catalog Item (Offer) Purchases	`Global:Session:Charging:Notify:When an offer is purchased for a subscriber (y/n)?`	n	Controls whether a notification is sent after a catalog item (offer) is purchased by or for a subscriber and the subscriber has open sessions. An RAR is sent after the Interval Size delay.
Notifications for Gy and 5G Charging — Subscriber Catalog Item (Offer) Purchases	`Global:Session:Charging:Notify:When an offer is purchased for a subscriber (y/n)?`	n	Controls whether a notification is sent after a catalog item (offer) is purchased by or for a subscriber and the subscriber has open sessions. If a subscriber purchases a catalog item that is granted to a tier group, and the GroupReAuthPreference is enabled for the group, a RAR is sent for each open session of each subscriber in the group and in the subgroup (if the GroupReAuthPreference is enabled for the sub group). Note: This allows the recharge for a shared asset to be made immediately available to all subscribers in the group. In this context, a purchase is a grant component that performs a grant to the group tier. It may be invoked by an explicit offer purchase or by a first-use grant from an on-demand balance.
Notifications for Gy and 5G Charging — Group Catalog Item (Offer) Purchases	`Global:Session:Charging:Notify:When an offer is purchased for a group (y/n)?`	n	Controls whether a notification is sent after a catalog item (offer) is purchased by or for a group and one or more group members have open sessions. An RAR is sent for each open session of each subscriber in the group and in the subgroup (if the GroupReAuthPreference is enabled for the subgroup). An RAR is sent after the Interval Size delay. Important: If you answer `n` to this question, RARs are disabled globally for group purchases. You must answer `y` to this question to enable RAR on group purchases and also set the `GroupReAuthPreference` field value for a specific group with the SubMan APIs. For more information about setting the `GroupReAuthPreference` field value, see RAR Configuration Using the SubMan APIs.
Notifications for Gy and 5G Charging — Subscriber Catalog Item (Offer) Cancellations	`Global:Session:Charging:Notify:When an offer is cancelled for a subscriber(y/n)?`	n	Controls whether a notification is sent after a catalog item (offer) is purchased by or for a group and one or more group members have open sessions. When enabled, one RAR is sent immediately after a catalog item is canceled by or for a subscriber with open sessions. An RAR is sent after the Interval Size delay. Important: If you answer `n` to this question, notifications are disabled globally for group purchases. You must answer `y` to this question to enable notifications on group purchases and also set the `GroupReAuthPreference` field value for a specific group with the SubMan APIs. For more information about setting the `GroupReAuthPreference` field value, see MATRIXX Subscriber Management API.
Notifications for Gy and 5G Charging — Group Catalog Item (Offer) Cancellations	`Global:Session:Charging:Notify:When an offer is cancelled for a group (y/n)?`	n	Controls whether a notification is sent after a catalog item (offer) is canceled by or for a group and one or more group members has open sessions. An RAR is sent after the Interval Size delay. Important: If you answer `n` to this question, notifications (RARs for Gy) are disabled globally for group cancellations. You must answer `y` to this question to enable notifications on group cancellations and also set the `GroupReAuthPreference` field value for a specific group with the SubMan APIs. For more information about setting the `GroupReAuthPreference` field value, see MATRIXX Subscriber Management API.
Notifications for Gy and 5G Charging — Subscriber or Device Status Change	`Global:Session:Charging:Notify:When the status of a subscriber or a device is changed (y/n)?`	n	Controls whether a notification is sent after the status of a subscriber or device has changed and the subscriber or device has open sessions.
Notifications for Gy and 5G Charging — Group Status Change	`Global:Session:Charging:Notify:When the status of a group is changed (y/n)?`	n	Controls whether a notification is sent after the status of a group has changed and one or more group members has open sessions. Important: If you answer `n` to this question, RARs are disabled globally for group status changes. You must answer `y` to this question to enable RAR on group status changes and also set the `GroupReAuthPreference` field value for a specific group with the SubMan APIs. For more information about setting the `GroupReAuthPreference` field value, see RAR Configuration Using the SubMan APIs.

Customize Enabled RAR Behavior lists the questions that customize enabled RAR behavior.

Table 2. Customize Enabled RAR Behavior
Parameter	Configuration Question	Default Value	Description
Notifications for Gy and 5G Charging — Session Inactivity Period	`Global:Session:Policy:Notify:How long (in seconds) to wait after the most recent activity before the first attempt?`	172800	Sets a time interval, in seconds, for how long a session remains idle until a notification is sent. This question is important when a PCEF sends a Gy CCR-I that establishes a session but does not request quota. This is usually followed by a Gy CCR-U that does request quota. If it does not, a Gy RAR is sent for the session after this delay. MATRIXX Support recommends that the value be at least as long as the longest QVT plus the answer to the next question in this table. For example, if Gy RAR on quota expiration is enabled, a RAR is sent after the quota has expired. If a RAA is received from this point onward, the session is considered expired. At this point, a RAR is sent and, if multiple RAR retries are performed without receiving another RAA, the session is deleted without waiting for `session_expiration_time_in_seconds`. As another example, if a notification (for example, a Gy RAR) on quota expiration is disabled and a session has been inactive for the amount of time specified for this parameter, the session is considered expired and is removed. A Gy RAR is sent and after multiple RAR retries without receiving a RAA, the session is deleted. No RAR is sent before the session is expired in this case.
Notifications for Gy and 5G Charging — QVT Initial Wait Time	`Global:Session:Charging:Notify:How long (in seconds) to wait after the QVT expires?`	3600	Sets a time interval, in seconds, for how long to wait after the quota validity time (QVT) to expire to send the initial notification.
Notifications for Gy and 5G Charging — Interval Size	`Global:Session:Charging:Notify:How long (in seconds) to wait after each attempt?`	60	Sets a time interval, in seconds, to wait before sending another notification if the previous notification was not answered.
Notifications for Gy and 5G Charging — Retry Count	`Global:Session:Charging:Notify:How many attempts?`	The default and minimum value is 1.	Sets the maximum number of Gy RARs sent to try and obtain an answer before terminating the session. Note: If the number of attempts is 1, a Gy RAR is sent and if a Gy CCR or a Gy RAA indicating failure is not returned, the session is terminated. A Gy CCR maintains the session. A Gy RAA with Result-Code 2002 by itself does not terminate the session.

RAR Settings for Sessions

The create_config.info question Global:Session:Charging:Notify:How long (in seconds) to wait after the most recent activity before the first attempt?" (session_expiration_time_in_seconds) controls the overall session cleanup (after all RARs have tried and failed). The default value is 172800 seconds (two days). The impact of the setting is determined by the following settings:

RAR on quota expiration is enabled — After quota expires, a RAR is sent. After a RAA is received and the session is idle for the amount of time specified by session_expiration_time_in_seconds, the session is considered expired. A RAR is sent and after multiple RAR retries without receiving a RAA, the session is deleted. If after multiple RAR retries no RAA is received, the session is deleted without waiting for the session_expiration_time_in_seconds.
If RAR on quota expiration is disabled — After the session is idle for the amount of time specified by session_expiration_time_in_seconds, the session is considered expired. A RAR is sent and after multiple RAR retries without receiving a RAA, the session is deleted.
Note: No RAR is sent before the session expires in this case.

Note: MtxDiamRAMsg RARs and MtxDiamASMsg ASRs (Abort-Session-Request) for MtxLoginDeviceObjects use the default AccessId when populating the SubscriberName field if present. If the AccessId is not present, they use the LoginId field.

For more information about how to enable RARs and configure these options, see MATRIXX Configuration.

For a description of the supported Re-Auth command AVPs, see the discussion about supported AVPs in MATRIXX Diameter Integration.

RAR Configuration Using the SubMan APIs

The GroupReAuthPreference setting for a specific group configured with the SubMan APIs overrides the global values for the following RAR parameters:

Important: If you have enabled RARs for these settings, when using the GroupCreate or GroupModify SubMan APIs, you must configure the GroupReAuthPreference to enable RARs.

The GroupReAuthPreference bit field values for the SubMan APIs for group offer purchases, catalog item cancellations, and status changes are:

0 — Disable group RARs (Default).
1 — Enable RAR when a group purchases a catalog item.
2 — Enable RAR when a group cancels a catalog item.
4 — Enable RAR when a group status changes.

You must set the bit field for the options that you want to enable. For example, set the bit field to 5 to enable RARs for group status changes and group purchases.

For more information about the SubMan APIs, see MATRIXX Subscriber Management API.