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 includes the following topics:

To get the latest Sentinel IPSMGW SDK package go to https://repo.opencloud.com/artifactory/opencloud-sentinel-ipsmgw-3.1.0/opencloud/sentinel-ipsmgw/3.1.0/ipsmgw-sdk/ Choose the version with the highest release number.

The SDK package contains an installer, that can install Sentinel IPSMGW as an out-of-the-box system. It is also an SDK allowing customisation of the product.

You’ll need the following software to run Sentinel IPSMGW:

Optionally you can install and configure Rhino and the JVM for use with Sentinel IPSMGW. This is recommended for production deployments, and clustered setups.

Alternatively for Proof of Concept and lab functional testing it is recommended to use the Installer documented in Installing Sentinel IPSMGW Services

If you allow the installer to install both Rhino SDK and Sentinel IPSMGW for you, it will prompt you for the location of the license file.

If you prefer to set up Rhino manually, then you need to install the license file prior to installing Sentinel IPSMGW.

To install your license file:

If using the standard configuration, the following ports need to be open on the IPSMGW TAS host’s firewall.

If using other configuration the firewall should be configured for those non-standard ports. Other ports may be opened as needed. For example if ssh is used to administer a node, then port 22 would be opened

Install and configure a Cassandra Storage with the opencloud_thirdparty_reg, opencloud_ipsmgw_routing_info, and opencloud_ipsmgw_registration_ownership keyspaces.

Install and configure an OCSS7 stack. Refer to OCSS7 Quick Start.

Sentinel IPSMGW is built on top of other OpenCloud products. The IPSMGW series depends on the following:

To unzip ipsmgw-sdk.zip:

The install program is split into several "phases".

These are:

NB: the installer captures full logging from the various tools that it uses, and writes these logs into the ipsmgw-sdk/build/target/log directory.

To run the installer:

To run the installer in non-interactive mode a properties file is passed to the installer program

During installation SIS and CGIN versions are extracted into the SDK directory structure. This is so that SIS can be configured as necessary.

The CGIN connectivity pack is extracted into the ipsmgw-sdk/cgin/cgin-connectivity-full-CGIN_VERSION directory. The SIS is extracted into the ipsmgw-sdk/sis/SIS_VERSION directory. Here CGIN_VERSION and SIS_VERSION are the release versions for each product respectively (e.g. 2.0.0.0 and 2.7.0.0)

The SIS console command is located at ipsmgw-sdk/sis/SIS_VERSION/admin/sis-console.

The installer captures full logging from the various tools that it uses, and writes these logs into the ipsmgw-sdk/build/target/log directory. This output is more verbose than the user sees when running the installer.

Each time an install is done, a file called install.log is created in this directory. If there is a previous install.log file, that it is moved to install_date.log. The value of "date" is the time of the last write timestamp in the file. i.e. running the installer three times results in three installer log files.

There are two required configuration values in SIP Sentinel Configuration which must be configured by hand after installation.

The MCC and MNCs fields are used by Generate MT Correlation Id when a real IMSI could not be retrieved from the HLR.

These can be set through either REM or the rhino-console.

There are two init.d scripts for Ubuntu Linux which make starting and stopping Rhino and REM easier (linked below):

Note: These are illustrative and useful for Proof of concept rather than production environments.

To set these up:

Finally, restart Rhino by executing the following commands in a terminal, from the Rhino install directory.

To set up Apache Tomcat for the IPSMGW Element Manager module:

Download Sentinel IPSMGW EM Plugin, from Artifactory

To install the REM plugin for the IPSMGW Element Manager Module:

This can also be done using the REM web UI.

Below are recommendations for securely running the IPSMGW Element Manager Module.

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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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:

This feature is needed for multi-tenancy scenarios. This feature is intended to be used in the direct access case.

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 is provisioned using the Sentinel Features REST API.

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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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.

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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].feature.IPSMGWExtractNetworkInfo"

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

The feature is provisioned using the Sentinel IP-SM-GW feature REST API.

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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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 Whitelist Feature rejects OpenRequests from SCCP addresses it does not recognize based on a provisioned whitelist.

Request from non-GT addresses will be allowed without checking the whitelist. If a whitelist is not found, the feature ends immediately, allowing call processing to continue. If the whitelist 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 whitelist 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 IPSMGWSCCPWhitelist.

The feature is provisioned using the Sentinel Sentinel Core REST API.

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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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.

The feature is provisioned using the Sentinel IP-SM-GW feature REST API.

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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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=3.1.0].SbbID[name=sentinel.ipsmgw,vendor=OpenCloud,version=3.1.0].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.