This feature increments (or creates) a row in the Cassandra cluster for the current MSISDN, to be used as the RP Message Reference, writing the value into session state.

Feature cheat sheet

Feature Name Network Operator Data Used in PlanId(s) Stateful or Stateless POJO Feature or SBB Feature






Prerequisite features

This feature must run after Fetch Routing Info Cassandra.

Session input and output variables

Session input variables

Session State variable name Variable type



Session output variables

Session State variable name Variable type Comments



The int to use for the next outgoing RpDATA - from 0 to 255



The flag set to true whenever the feature fails to generate a message reference


The feature reads configuration from the Profile Table named IPSMGWGenerateMessageReferenceConfigProfileTable. The profile name is scoped according to Sentinel Selection Key.

Attributes Type Meaning


Cassandra consistency to be applied to the queries. Valid values are LOCAL_QUORUM (default), or QUORUM



The number of seconds to wait for a response from Cassandra (default 10)



The number of retries due to Compare and Set failure. Default 3



The minimum number of milliseconds between retries due to Compare and Set failure. Default 50, minimum of zero.



The maximum number of milliseconds between retries due to Compare and Set failure. Default 250.



The total number of geo-redundant sites in which IPSMGW will be running (1-16). Default 1, maximum of 16.



The unique ID number of this site within the set of geo-redundant sites. Default 1, maximum of TotalNumberOfSites.


The feature queries the Cassandra Database using a Primary Key of the MSISDN of the Served User and the schema detailed here. The resulting value is stored into the MessageReference session state variables for use by other features.

As multiple SMS may be delivered to the same MSISDN simultaneously, the feature uses an atomic Compare and Set (CAS) statement when creating/incrementing the message reference. The use of CAS is governed by a retry loop, so that a single failure to create/increment the message reference does not cause the message delivery to fail (as when simultaneous CAS operations execute, one operation succeeds and the others fail). The MaxRetries, MinRetryDelayMillis, and MaxRetryDelayMillis ensure that the loop is bounded in number of iterations, and is able to be tuned as desired. When a CAS operation fails, a random delay (between MinRetryDelayMillis and MaxRetryDelayMillis) occurs before the executing thread will attempt another CAS operation. A value of zero for MinRetryDelayMillis means that the thread will immediately attempt the next CAS operation.

If IPSMGW is running across multiple geo-redundant sites, then TotalNumberOfSites and SiteId are used to partition the generated message reference numbers into non-overlapping ranges. Within a single site, the above CAS operation will be used to ensure unique message reference numbers. Between different sites, the uniqueness depends on the SiteId being unique amongst the total number of sites and the TotalNumberOfSites accurately reflecting how many sites there are in total. The feature will then constrain its generated message reference numbers to the range calculated for that particular site.

The feature has Configuration controls around the Compare and Set loop.

If the feature fails to generate the message reference for any reason, it resumes the SMSC leg and sends back an error response, while flagging the failure in session state.


IPSMGWGenerateMessageReference statistics are tracked by the sentinel.ipsmgw SBB and can be found under the following parameter set in REM:
SLEE-Usage → sentinel.ipsmgw service → sentinel.ipsmgw SBB → feature → IPSMGWGenerateMessageReference
or with rhino-stats:

Statistic Incremented when…​

A cassandra query could not be executed successfully - could be caused by the RA or the Database - turn on finer tracing for details


This is not a cassandra exception as in the case of FailedToExecuteCassandraStatement - instead it implies that the insert was not applied, probably due to the row already existing


This implies that the UPDATE failed, either due to the CAS condition failing (ie the existing value was not as expected, implying that another session had already updated the field, or the row having already been removed since the last read)


The configured number of compare and set retries has been reached without successfully setting the message reference counter in cassandra


The number of compare and set re-attempts


Even after successfully incrementing the counter, no value could be retrieved - this could only occur if the Database was modified


The message reference counter was successfully incremented and retrieved from Cassandra

Previous page Next page
Sentinel IP-SM-GW Version 4.1