Session Monitor Deployments with SAU Extension
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 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 Engines, 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 Engines 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.
![Session Monitor architecture in a deployment that does not use the Aggregation Engine Session Monitor architecture in a deployment that does not use the Aggregation Engine](img/GUID-08CC2B9F-5319-4614-B4BC-109B3DC405A4-default.png)
In this case, the RESTful API for exporting the KPIs is served directly by the ME machines (no aggregation step is needed). The same RESTful API is used by both the AE and the ME, so the application that interrogates it doesn't need to know if the Session Monitor setup is using an AE or not.
In all cases, the historical SAU and SAtU values are stored at both the ME and AE level for a period of three months. The historical values are kept for all supported intervals.