The Session Monitor architecture consists of the probe layer, Mediation Engine layer, and the Aggregation Engine layer (see the discussion about Session Monitor architecture in the Session Monitor Installation Guide for information about the functions performed in each layer).

The figure below depicts the Session Monitor architecture in a typical deployment that uses the Aggregation Engine layer (AE). The machines are deployed in high-availability (HA) pairs for redundancy reasons. Each Probe machine sends traffic to the two Mediation Engine, which are running as active-active from the point of view of the traffic.

The Mediation Engine parses the SIP and Diameter traffic, the list of the unique phone numbers (matching a regular expression), and IMSI numbers that respect the SAU and SAtU definition for each interval.

Once per hour, this list of users is sent from the Mediation Engine to the Aggregation Engine pair. The Aggregation Engine de-duplicate the lists and count the SAU and SAtU KPIs for each of the supported time intervals.

The figure below depicts the Session Monitor architecture in a smaller deployment that does not use the Aggregation Engine.

In this case, the RESTful API for exporting the KPIs is served directly by the Mediation Engine machines (no aggregation step is needed). The same RESTful API is used by both the Aggregation Engine and the Mediation Engine, so the application that interrogates it does not need to know if the Session Monitor setup is using an Aggregation Engine or not.

In all cases, the historical SAU and SAtU values are stored at both the Mediation Engine and Aggregation Engine level for a period of three months. The historical values are kept for all supported intervals.