The Gemini HyperScale® Messaging Center (HMC) is a flexible, multi-protocol and multi-technology messaging platform that applies its powerful routing and message transformation and analysis features to multiple types of messages. Among the messaging technologies mastered by the HMC are MMS, SMS, email, and WAP Push. The HMC is a fully-clustered, highly-available platform that receives messages over various standard interfaces, stores them, transforms them into another technology or transcodes them if necessary, and forwards them to their recipients. These features of the HMC can not only be exploited today to provide efficient and high performance SMS messaging, but also guarantee a future-proof solution for the messaging needs of tomorrow.

The Gemini SSG is an efficient barrier against SMS fraud, both in terms of identification and alarming when fraud occurs, and for fraud prevention. The SSG is effective against the following threats:

The Gemini HyperScale® Secure SMS Gateway (SSG) is a particular configuration of the HyperScale® Messaging Center (HMC) that exploits the HMC flexibility to provide high performance reception, filtering and routing of short messages. The Gemini SSG is designed to receive messages from an SS7 Signaling Gateway / Softswitch over SIGTRAN M3UA, filter them, and route them back to the Softswitch from where they will be forwarded to destination. Figure 1 is a diagram illustrating the Gemini SSG network configuration.

The functionality of the Gemini SSG is to receive MAP PDU over the SIGTRAN / M3UA association with the SG / Softswitch, count them, produce statistical logs, and analyze their content using a number of different filters that protect from different threats. Then, the PDU is either sent back to the SG / Softswitch unchanged if no threat was detected, or discarded / rejected if a definite threat was identified, or again quarantined for further inspection if the results of the analysis so demanded.

Gemini adopted a very flexible architecture for the SSG filtering functionality, taking into account the variable nature of the traffic and the possibility of evolving the filtering technology over time to adapt to changing network conditions and the emergence of new threats. For this reason, a multi-layered filtering architecture has been defined:

1. A basic layer that examines the MAP PDU received over M3UA and immediately sends back to the SG / Softswitch those that are of no interest. The types of MAP service that are accepted for further analysis is configurable as different types can be used for different filters.
2. A first statistical layer that counts different types of PDU, keeping track of this traffic in log files, and then immediately sends back to the SG / Softswitch those that by configuration are not to be transmitted to further filtering layers. This is important also not to run the risk to disrupt network traffic if the upper layer filtering takes substantial time. For instance, the timing constraints of a SRI_SM request are faster than those of a Forward_SM request.
3. A layer of local filters that may act on different fields of the incoming PDU. These filters are identified by name and sequenced through system configuration so that more than one can be applied to the PDU. These filters may both act on the PDU – specifying that a message should be rejected or quarantined, or simply collect statistics.
4. As a future development, Gemini plans to introduce an API for third parties to develop new filters to perform additional traffic analysis and counteracts additional threats. These filters will take the shape of a shared object that is inserted in the flow through the SSG configuration GUI and receives the message data through a standard interface. The filter is then given a standard callback API to return the results of the analysis.
5. Optionally, Gemini's MSCF node can be used to run more sophisticated and asynchronous filters that require for instance access to a remote database.

Back to Top