Sentinel IP Short Message Gateway Administration guide

The IP Short Message Gateway (IPSMGW) implements transport layer interworking for SMS over IP. It is based on 3GPP TS 24.341, and implements suitable SMS interworking as part of GSMA IR.92 version 9.0

This document is primarily for support purposes to assist with low level configuration tasks. Customers should refer to the Rhino VoLTE TAS Configuration and Management Guide to configure the Appliances rather than this documentation.

This document includes the following topics:

These are common features that are used in several flows

These features relate to the SMS Submission path from the UE to the network.

These features relate to the SMS Delivery path from the network to the UE.

The SIP B2BUA feature can be configured to preserve the Call-ID header across both legs of a B2BUA’d session. Certain MT flows require the correlation of an incoming request with an existing IP-SM-GW session. This is achieved using the In-Reply-To header of the incoming request. Depending on network configuration this may require the preservation of the Call-ID header when B2BUA’ing the MESSAGE request onwards. By default and in typical deployments, this behavior is not configured. It should only be configured if required. For more information on this configuration option read the B2BUA Feature Configuration documentation.

These features relate to the Short Message Memory Available Submission path from the UE to the network. This occurs when the UE indicates that it has memory available to receive short messages, having previously indicated that it did not have available memory.

These features relate to Third Party Registration

These features relate to processing USSI requests.

This features uses the information from the session state fields mentioned above and constructs a protobuf message out of it for output. See AVP CDR Format for the format of these messages.

Also see Charging Information for general information about the contents of CDRs and CCRs.

The feature uses the Shared Configuration Profile. The following attributes are used:

This feature instructs the Sentinel core to accept the incoming dialog.

The feature has no statistics.

The feature has no configuration.

The feature examines incoming SIP and TCAP messages and extracts information from them. This information is saved in session state fields to make it available to the AVP CDR feature that runs at the end of a session.

IPSMGWDetermineIsSMSOverIP 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 → IPSMGWDetermineIsSMSOverIP
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWDetermineIsSMSOverIP"

The feature has no configuration.

If the SIP Message Request body does not include an SMS, the default product configuration has the IP-SM-GW act as a Routing B2BUA, thereby sending the SIP Message request towards the S-CSCF.

The Content-Type header is checked to see if it is application/vnd.3gpp.sms, and if so this indicates that the request is SMS over IP related. The session state field IsSMSOverIP set to true. If the Content-Type header does not match the feature finishes execution.

Next the body of the SIP Message Request is parsed as an RP Message. If parsing is unsuccessful the feature sends a 403 response, increments the SentError statistic and finishes execution.

Assuming that parsing is successful, the feature then checks the RP Message Type Indicator for directionality of MS to Network. If the direction is Network to MS it is a message type that the IP-SM-GW does not process, so the feature finishes execution and the IP-SM-GW will act as a Routing B2BUA.

Assuming the direction is MS to Network, the following occurs:

IPSMGWDetermineSessionPlan 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 → IPSMGWDetermineMSISDN
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWDetermineMSISDN"

The feature has no configuration.

The feature checks if the trigger message is a TCAP OpenRequest message or a Sh UEReahabilityForIP Push Notification Result. In each case the MSISDN session state field is set to the extracted MSISDN.

The IPSMGW Determine Network Operator Feature sets the network operator element of the Sentinel selection key for use in the selection of:

The feature will set the Network Operator element of the Sentinel selection key, based on the value returned by the DetermineNetworkOperator function below.

The following logic is used for determining the Network Operator

The use of the destinationSccpAddress GT information is dependent on the subscriber’s HPLMN network configuration. It is possible that some networks may not pass the GT information set in the subscriber’s o-CSI or t-CSI.

Here is an example of SCCP address routing which includes the GT information:

For subscribers who are configured for intra-PLMN only, it is possible that the CSI may contain a gsmSCP address containing only PC/SSN. In this case, the feature cannot operate, as no GT information will be available.

Network Operator Destination Global Title SCCP Address Lists Selection Table:

Example table:

The default network operator is stored in the Sentinel configuration table.

The feature reads the following fields in Session State

The feature sets the following fields in Session State

The feature has no statistics.

The feature checks if the trigger message is a TCAP Message, if it is then it analyses the components to determine if the Tcap Message contains a SRIForSM response and sets the following session state fields:

Both are used subsequently in feature scripts to control behaviour, LookupIMSRegistration is used to indicate whether subscriber data should be read from Cassandra (IMS Registration). If the subscriber is IMS registered or the SRIForSM result indicated success then delivery will be attempted.

The feature reads the following fields in Session State

The feature sets the following fields in Session State

IPSMGWDetermineSessionPlan 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 → IPSMGWDetermineSessionPlan
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWDetermineSessionPlan"

The feature has no configuration.

The feature checks if the trigger message is a TCAP OpenRequest message or a Sh UEReahabilityForIP Push Notification Result.

If it is a TCAP OpenRequest message, then the PlanId selection key field is set to SRI4SM, MOFSM, MTFSM_<DeliveryOrder> ^[1] or UnknownACN. The configured DeliveryOrder is set in the MTFSMDeliveryOrder session state field unless MTFSMDeliveryOrder was already set.

If it is a Sh Push Notification Result, then the PlanId selection key field is set to Sh_PNR.

Otherwise, the feature does not set the PlanId field of the SentinelSelectionKey session state field.

In some cases the feature will also set the CallType in session state if it has not already been set by another feature.

IPSMGWDetermineSessionType 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 → IPSMGWDetermineSessionType
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWDetermineSessionType"

The feature has no configuration.

The feature checks if the trigger message is a TCAP message or a Sh UEReahabilityForIP Push Notification Request. If it is a TCAP message, then the session state field SessionType is set to map. If it is a Push Notification Request, then the session state field PlanId is set to Sh_PNR. Otherwise the feature leaves the SessionType session field state unset.

The feature has no session input variables.

The feature sets the following fields in Session State

The feature has no statistics.

The feature has no configuration.

The feature checks if the trigger message is a TCAP Message,if it is then it analyses the components to determine if the Tcap Message contains either a SINGLE_COMPONENT_TYPE or MULTIPLE_COMPONENT_TYPES (TCOperationResult and TCOperationInvoke) and sets a session state field. The value of the session state field can then be used subsequently in feature scripts to select which features to run. The following excerpt demonstrates how the feature and session state field can be used in feature scripts.

The feature has no configuration.

This feature instructs the Sentinel core to immediately clear all pending requests, and enqueue an EndSession instruction on all legs.

The Fetch IMSI feature supports the following parameters that may be passed in a feature execution script run statement:

The feature reads the following fields in Session State

The feature sets the following fields in Session State

IPSMGWFetchIMSI 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 → IPSMGWFetchIMSI
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWFetchIMSI"

The feature is configured with configuration scoped according to a Sentinel Selection Key. The Profile Table used to hold feature configuration is IPSMGWSharedConfigProfileTable.

The following attributes are available

The feature uses MAP Application Context shortMsgGatewayContext_v2_ac. This application context was added in GSM MAP Phase 2.

When run with mode fetch the FetchIMSI feature will read the MSISDN out of session state. It is then used to send a SendRoutingInfoForSMRequest to the HLR. The request always has the SM-RP-PRI flag set to TRUE, and optionally has smDeliveryNotIntended set to "only IMSI requested" (based on the SriSmDeliveryNotIntended configuration flag).

When run with mode response the feature will look for the receipt of the SendRoutingInfoForSMResponse, it extracts the IMSI and sets it in session state. If the SendRoutingInfoForSMRequest results in an error response then it will set the SRI4SMResult and SRI4SMError session state fields instead.

If the feature is run without a mode parameter it returns a Feature Error.

The feature can be inhibited if the IPSMGW is configured to suppress HLR Interaction (see Suppression of HLR Interaction)

For SIP message triggers only:

This feature uses all of the session state fields of its parent feature. For a list of these, see that features documentation.

In addition, it uses the following fields:

IPSMGWExtractNetworkInfo 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 → IPSMGWExtractNetworkInfo
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWExtractNetworkInfo"

This feature uses the same configuration profiles as the Extract Network Info feature. See:

The IPSMGW IEC feature covers immediate event charging using a charge/refund model. The feature is responsible for:

The general use case is that an SMS will be delivered by one of IPSMGW’s delivery or submission features. On the incoming MO SIP MESSAGE, or MT-FSM DialogTcapMessage, the IEC feature will trigger a direct debit, suspending the outgoing message until a charging response is received, before allowing the message to be sent. If a response to the message is received which indicates failure, a refund will be issued, unless a fallback is attempted that also has charging enabled.

For a high level overview of Sentinel charging see Sentinel SIP Charging Architecture

The charging API interactions fall under the following categories:

This feature relies on two mappers:

The MAP proxy acts as an intermediary between two network elements, typically an SMSC and MSC. The MAP proxy manages two TCAP legs, one to each network element, and forwards messages received on each leg to the other linked leg.

The SCCP address of the destination network element is found by searching the feature configuration using the Sentinel Selection Key and the TCAP Application Context of the initial Dialog Open Request.

The feature reads the following fields in Session State

IPSMGWMapProxy statistics can be found under the following parameter set in REM:
SLEE-Usage → sentinel.ipsmgw service → sentinel.ipsmgw SBB → feature → IPSMGWMapProxy
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWMapProxy

The IPSMGWMapProxy can proxy to different destinations based on the triggering TCAP Application Context and the value of the Sentinel Selection key.

The first Profile Table used to hold feature configuration is Shared Configuration Profile. The following attributes are used:

The second Profile Table used to hold feature configuration is IPSMGWMapProxyConfigProfileTable. Entries in the table are indexed by a Sentinel Selection key that is qualified by a TCAP Application Context. The following attributes are available

In the example below, the IPSMGWMapProxy feature is configured so 'shortMsgGatewayContext' triggers for MAP 1, 2 or 3 are proxied to 'type=C7,ri=pcssn,pc=5,ssn=6'.

The Modify SRI Leg feature acts as an intermediary between two network elements, typically an SMSC and MSC. The feature modifies outbound Send Routing Info for SM requests, and/or discards outbound InformSC requests based on configuration. This is primarilly intended for use with the Map Proxy Feature to ensure that outbound SendRoutingInfoForSM messages have SM RP PRI set to true, and to ensure InformSC requests are not proxied.

IPSMGWModifySRILeg statistics can be found under the following parameter set in REM:
SLEE-Usage → sentinel.ipsmgw service → sentinel.ipsmgw SBB → feature → IPSMGWModifySRILeg
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWMapProxy

The feature configuration is in a Profile Table called IPSMGWModifySRILegConfigProfileTable. Entries in the table are indexed by a Sentinel Selection key. The following attributes are available

In the example below, the IPSMGWModifySRILeg feature is configured so InformSC messages are discarded, but SendRoutingInfoForSM messages are sent unmodified.

The feature reads the following fields in Session State

The feature sets the following fields in Session State

IPSMGWReadyForSM 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 → IPSMGWReadyForSM
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWReadyForSM"

The feature is configured with configuration scoped according to a Sentinel Selection Key. The Profile Table used to hold feature configuration is IPSMGWSharedConfigProfileTable.

The following attributes are available

The feature uses MAP Application Context mwdMngtContext_v2_ac. This application context was added in GSM MAP Phase 2.

When triggered on a TCAP message the feature checks that an IMSI is present in session state field named IMSI. It then initiates a ReadyForSM operation to the HLR with an alert reason of:

When the ReadyForSM operation completes, the feature sets the ReadyForSMResult session state field based on the response, SUCCESS if the ReadyForSM operation is successful, FAILED if the ReadyForSM operation returns an error or a timeout. It also sets the ReadyForSMError session state field with the TcapError if the response was a failure.

It can be inhibited if the IPSMGW is configured to suppress HLR Interaction (see Suppression of HLR Interaction)

The feature has no configuration.

This feature instructs the Sentinel core to reject the incoming dialog.

The IPSMGW SCCP Allowlist Feature rejects OpenRequests from SCCP addresses it does not recognize based on a provisioned allowlist.

Request from non-GT addresses will be allowed without checking the allowlist. If an allowlist is not found, the feature ends immediately, allowing call processing to continue. If the allowlist is then found to be empty, the feature ends, allowing call processing to continue. If the originating address contains GT digits, it will match those against the provisioned allowlist using the list’s configured address search mode. If a match is not found, the incoming leg is released via endSession.

The feature uses the following profile table to configure IPSMGWSCCPAllowlist.

MOSubmission 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 → IPSMGWMOSubmission
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWMOSubmission"

The feature is configured with configuration scoped according to a Sentinel Selection Key. The Profile Table used to hold feature configuration is IPSMGWSharedConfigProfileTable.

The following attributes are available

The feature uses MAP Application Context shortMsgMO_RelayContext_v2_ac. This application context was added in GSM MAP Phase 2.

The feature is triggered upon receipt of a SIP Message request.

The feature first checks that the SIP Message request’s Content-Type header is "application/vnd.3gpp.sms". If not, the feature finishes execution.

If the SIP Message request has a Content-Type header of "application/vnd.3gpp.sms" the feature extracts the body and parses it into an RP Message of the appropriate type. If the RP Message can be parsed, the feature extracts the SMSC address from the parsed RP Message. The feature then extracts the SMSC Address from the parsed RP Message. The further behaviour of the feature depends on whether online charging is enabled or not. If online charging is not enabled the feature immediately sends a 202 Accepted response to the SIP Message request, otherwise it will only send it after a successful online charging response.

Once the SMS has been accepted, the feature passes the SMS into the SMSC. This is through the use of the MAP MO Forward SM operation, on the shortMsgMO_RelayContext_v2_ac MAP Application Context.

A general overview of the feature behaviour is depicted in the diagram below.

This feature must run after:

MOSubmissionLocation 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 → IPSMGWMOSubmissionLocation
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWMOSubmissionLocation"

The feature is configured with configuration scoped according to a Sentinel Selection Key. The MOSubmissionLocation feature refers to two tables for configuration. The Profile Table is used to hold feature configuration is MOSubmissionLocationProfileTable.

The following attributes are available

The second Profile Table CapChargingProfileTable holds CAP Charging specific configuration. The following attributes are used:

The feature retrieves the TCAP leg IPSMGWMOSubmission created by the MO Submission feature. If the leg is available the feature attempts to generate a Charging GT using the ChargingGTFormatString and sets the OrigAddress of the outboud TCAP message with the generated value. If this fails, the feature uses the UnknownLocationChargingGT for the OrigAddress.

MOSubmitReport 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 → IPSMGWMOSubmitReport
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWMOSubmitReport"

The feature is configured with configuration scoped according to a Sentinel Selection Key. The Profile Table used to hold feature configuration is Shared Configuration Profile. The following attributes are used:

The feature is triggered after the MO Submission feature has finished.

The feature checks session state to determine the outcome of MO Submission to the SMSC.

In the case that MO Submission was successful it formulates a SIP Message request containing an RP-ACK towards the initiating UE. In the case that there were parsing or other issues in MO Submission it formulates a SIP Message request containing an RP-ERROR towards the initiating UE (SM-over-IP sender).

The details of these requests are as follows.

The SIP B2BUA feature can be configured to preserve the Call-ID header across both legs of a B2BUA’d session. Certain MT flows require the correlation of an incoming request with an existing IP-SM-GW session. This is achieved using the In-Reply-To header of the incoming request. Depending on network configuration this may require the preservation of the Call-ID header when B2BUA’ing the MESSAGE request onwards. By default and in typical deployments, this behavior is not configured. It should only be configured if required. For more information on this configuration option read the B2BUA Feature Configuration documentation.

The feature is configured using the IPSMGW Service configuration. The Profile Table used to hold feature configuration is Shared Configuration Profile. The following attributes are relevant

The feature is triggered upon receipt of a third-party response message. The message is unmodified if it is not a successful Send Routing Info For SM response. The feature handles the following application contexts: shortMsgGatewayContext_v1_ac, shortMsgGatewayContext_v2_ac, shortMsgGatewayContext_v3_ac

When processing a v1/v2 MAPSendRoutingInfoForSMRes, the feature will set the MSC address in the outgoing message to the value of the SentinelIPSMGWAddress configured in the IPSMGW service config profile. When processing a v3 MAPRoutingInfoForSM_Res, the feature will set outgoing message’s 'GPRS Supported' indicator to false and set the NetworkNodeNumber and AdditionalNumber to the value of the SentinelIPSMGWAddress.

This ensures that the MAP MT Forward Short Message is then delivered to the IPSMGW.

The feature can be triggered by MAP Forward Short Message on the terminating path, for MAP Phases 1, 2 and 2+. This is referred to as MT Forward Short Message or MT-FSM for short.

The MAP Phases 1, 2 and 2+ are sometimes referred to as "v1, v2 and v3" however such language is not strictly correct.

From a TCAP Application Context perspective:

IPSMGWCSDelivery 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 → IPSMGWCSDelivery
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWCSDelivery"

The feature is configured with configuration scoped according to a Sentinel Selection Key. Two Profile Tables are used for configuration. The first profile Table used to hold feature configuration is Shared Configuration Profile. The following attributes are used:

The second Profile Table used to hold feature configuration is IPSMGWCSDeliveryConfigProfileTable. The following attributes are used:

This feature is responsible for Circuit Switched delivery of a Short Message.

CS delivery is triggered in two ways:

After validating configuration and session state inputs, the CS Delivery feature takes the received ForwardSM (regardless of whether or not PS Delivery was attempted) and begins the TCAP Application Context Negotiation Flows.

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 → IPSMGW Delivery Report Handover Feature SBB
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=ipsmgw-delivery-report-handover-feature,vendor=OpenCloud,version=4.1]"

The feature has no configuration.

The Delivery Report Handover feature is run as part of the PS delivery leg in the MT SMS flow. The PS Delivery feature will send an SMS over IP message. The call id of this message will be used to store the activity context of the session, using the Activity Context naming facility. On receipt of the message, the endpoint will generate a delivery report (with a message-type-indicator of RP_ACK or RP_ERROR) to indicate success or failure of the MT message. This delivery report message will be classified by the Determine Is SMS Over IP feature, and will trigger the Delivery Report Handover feature.

When the Delivery Report Handover feature is triggered on an incoming SIP Delivery Report, the feature extracts the value of the 'InReplyTo' header from the incoming SIP MESSAGE and searches for Application Contexts registered against that value in the ACI Naming Facility.

The feature reads the following fields in Session State

The IPSMGWFetchRoutingInfoCassandra feature populates the following fields in the Session State

IPSMGWFetchRoutingInfoCassandra 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 → IPSMGWFetchRoutingInfoCassandra
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWFetchRoutingInfoCassandra"

The feature uses the IPSMGWRoutingInfoCassandraConfigProfileTable profile to configure whether tracing is enabled for Cassandra queries.

The feature is triggered on MAP MT Forward Short Message (MT-FSM) requests. The IMSI in the MT-FSM is used as the 'mtcorrelationid' primary key field when querying Cassandra. The contents of the query result are written into session state, and used to facilitate delivery of the SMS.

If a row is not found, an UnidentifiedSubscriber error is returned to the SMSC and the feature ends.

If a row is found, the Store Routing Info Cassandra feature has written all available CS routing data to Cassandra using the schema detailed here.

If the row includes circuit switched routing information for SMS (i.e. the SRI request and response), the feature ends. If the row does not include CS routing info or the any of the CS routing info fields such as the arg or the res could not be decoded, but PS is one of the options in the current MTFSMDeliveryOrder session state field, the plan Id in the selection key is set to MTFSM_PS and the MTFSMDeliveryOrder is set to PS_ONLY - otherwise an unidentifiedSubscriber error is sent in response to the MT-FSM.

The feature is triggered by a SRI_SM response (Version 1, 2 or 3) from the HLR. In the successful case, it extracts the MCC and MNC from the IMSI in the SRI_SM response. Once the MCC and MNC are extracted, PLMN ID Analyser Component is used to check that the PLMN ID (MCC + MNC) is configured as a home PLMN ID, then the feature requests a correlation IMSI from the Correlation Resource Adaptor, providing the PLMN ID. If the SRI_SM failed, it uses the FakeMCC and FakeMNC configured in the IPSMGWGenerateMTCorrelationIdConfigProfileTable. If the Correlation RA allocates an IMSI successfully, the feature checks if the correlation IMSI is already in use by querying the Cassandra database. If the correlation IMSI is not in use, the feature stores the correlation IMSI into Session State and finishes execution. If the correlation IMSI is in use, the feature requests another correlation IMSI from the Correlation RA. The process is retried up to MaxGenerationAttempts number of times.

An SMSC may use a correlation IMSI for some period of time after the SRI-SM transaction completes. However the correlation IMSI will be returned to the pool after a configured time period. Therefore the "in-use" check is performed by this feature. See Store Routing Info Cassandra to understand when the correlation IMSI is erased from the database.

The feature uses the IPSMGWGenerateMTCorrelationIdConfigProfileTable and the SIP Sentinel Configuration for its configuration.

IPSMGWGenerateMTCorrelationId 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 → IPSMGWGenerateMTCorrelationId
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWGenerateMTCorrelationId"

This feature must run after Fetch Routing Info Cassandra.

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

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:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWGenerateMessageReference"

The IPSMGWGenerateSRIResult feature reads the following fields from Session State:

This feature depends on configuration from the IP-SM-GW shared configuration profile table.

Specifically, it reads these fields:

See the Shared Configuration Profile page for additional information about these fields.

IPSMGWGenerateSRIResult 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 → IPSMGWGenerateSRIResult
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWGenerateSRIResult"

The feature will be invoked on receipt of a SRI for SM request from the SMSC. Its purpose is to generate a SRI for SM response towards the SMSC when it is not necessary to consult the HLR for routing information (i.e. The IP-SM-GW is configured for PS delivery only).

When invoked it will check the IMS registration state for the subscriber (as determined by the Registration Lookup From Cassandra feature).

If the subscriber is IMS registered, the feature will generate and send an SRI for SM response that is appropriate for the MAP application context used by the request. The response will identify the IP-SM-GW as the MSC for the subscriber to the SMSC, and provide the correlation IMSI for the SMSC to use when delivering messages. The correlation IMSI is generated by the Generate MT Correlation Id feature.

If the subscriber is not IMS registered will generate and send an Absent Subscriber error instead.

If for any reason the IP-SM-GW fails to generate a correlation IMSI, then the feature will generate and send a MAP System Failure error.

IPSMGWPSDelivery 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 → IPSMGWPSDelivery
or with rhino-stats:
"SLEE-Usage.Services.ServiceID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=4.1].feature.IPSMGWPSDelivery"

The IPSMGWPSDelivery feature configuration is scoped according to a Sentinel Selection Key. The IPSMGWPSDelivery feature refers to three Profile Tables for configuration.

The first Profile Table is Shared Configuration Profile. The following attributes are used:

The second Profile Table is IPSMGWPSDeliveryConfigProfileTable. The following attributes are used:

The third Profile Table (IPSMGWPSDeliveryPerNodeURIConfigTable) holds node-specific feature configuration. The following attributes are used:

The feature can be triggered by any of the following MAP Application Contexts: shortMsgMT_RelayContext_v3_ac shortMsgMT_RelayContext_v2_ac shortMsgMT_RelayContext_v1_ac

The feature is triggered upon receipt of a mt_ForwardSM in any of the above three MAP Application Contexts.

After validating configuration and session state inputs, it then takes the ForwardSM argument and creates an RpDATA that it can send in a SIP MESSAGE to the ICSCF

The SIP MESSAGE is created as follows:

For example flows, see MT Delivery Flows

The IPSMGWPSDelivery feature arms a service timer (with the value of FallbackTimer attribute in the IPSMGWPSDeliveryConfigProfileTable) when it sends the SIP MESSAGE. If this timer expires, then PS Delivery has taken too long and the PSDeliveryStatus session state field is set to FAILED (default is NOT_ATTEMPTED.)

The following tables explains the behaviour during MT PS delivery.