Session Management

During global configuration, you can configure session management parameters that control global session limits per device, interface-specific session limits per device, error messages, and session recycling.

Session Types

MATRIXX Engine tracks the number of session objects in the activity database directly associated with a device. The sessions can be:
  • Charging Sessions (Gy/Ro for Diameter or Nchf_ConvergedCharging for 5G)
  • Policy Sessions (Sy/Gx for Diameter or Nchf_SpendingLimitControl for 5G)
  • Repository Sessions (Sh/Sp)
  • Application Sessions (Rx)
  • TCAP Sessions
A one-to-one relationship exists between the Diameter or 5G session created by the network and the session object in the database.
  • One policy session and one charging session exist for normal activity.
  • Other Gy sessions can be created by the network for use cases such as tethering.
  • During failure and timeout scenarios, old sessions might be present in the database while new sessions are created and used.
For TCAP sessions:
  • One TCAP session occurs per interaction (such as a voice call).
  • After a call is established, another charging session object is created and maintained by Call Control Framework (CCF). The TCAP session and the charging session both count against the configured maximum session limit.
  • By default, a TCAP session is maintained for 10 seconds. The TCAP session object continues to count against the total session count for any other interactions that occur. For this reason, assume three session objects per active voice call for sizing purposes.

Discarding Timed-Out Operations

You can configure Diameter Gateway to discard operations that have been in the system so long that the originator (end point) has given up, so replying has no result. This reduces the number of messages that must be recovered after a sudden system overload. Messages can be rejected at the start of processing by the Charging Server or at the start of processing by the Transaction Server. In either case, the result is set to 48 == TIMED_OUT, the result detail is set to 60 == DET_TIME_TO_LIVE_ENDPOINT_EXPIRED, and the MATRIXX Data Container (MDC) is passed back to Diameter Gateway.

A result of DIAMETER TOO_BUSY (3004) is returned to the Diameter client. The following fields in the MtxChrgMsg MDC control this behavior:
  • TimeToLiveEndpoint (datetime format) — Specifies the date/time after which replying to the end point has no result.
  • TimeToLiveResponseFlag (unsigned int32 format) — Indicates to MDC Gateway what to do if a message is discarded after timing out. A value of 0 means that MDC Gateway discards the stale request. A value of 1 means that MDC Gateway sends a TimeToLive-expired response.
  • TimetoLiveDeltaInSeconds (unsigned int32 format) — Specifies the number of seconds in addition to the TimeToLiveEndpoint. If this field is set, the value represents the time the message was received, plus the delta value. TimetoLiveDeltaInSeconds allows the rules for setting TimeToLiveEndpoint to be flexible. You can set TimetoLiveDeltaInSeconds using selective updates on Diameter Gateway. For more information, see the discussion about configuring selective updates in MATRIXX Installation and Upgrade.

You can configure this feature by answering the create_config.info questions described in the discussion about CAMEL Gateway configuration. If you answer 0 to any of the time-to-live questions, the TimetoLiveEndpoint is not set. The default values to these questions is 0, meaning that the discarding of timed-out operations is turned off by default.

The following question sets when the Charging Server clears its input queue until incoming messages are more than this number of milliseconds before the expiration time, to avoid rejection by the Transaction Server. The default is 200 milliseconds.

ChargingServer:What is the minimum remaining Time-to-Live window (in milliseconds) required to enable business logic processing of a request?