About the IP Short Message Gateway

The IP Short Message Gateway (IP-SM-GW) 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

Topics

This document includes the following topics:

Topic Explains…​

Sentinel IP-SM-GW in an LTE network

How the IP-SM-GW fits into a network

Key Flows

Illustrative flows for key behaviour

Major Components

Major functional components

Support for GSM MAP

Versions of GSM/3GPP MAP in the IP-SM-GW

Overview of the TCAP Leg Manager

The TCAP Leg Manager subsystem of the Sentinel IP-SM-GW service

Sentinel IP-SM-GW in an LTE network

The IP-SM-GW interfaces to several network elements.

ipsmgw in network

Once a UE is IMS registered, and indicates support for receipt of SMS over IP, it may send and receive SMS through the IP-SM-GW. That is, the UE may use SMS over IP when registered via PS access networks, not only when registered via LTE. The IP-SM-GW also supports mobile-initiated USSD reports over IMS.

The IP-SM-GW performs a similar role to the VMSC, but for IMS registered UEs, rather than CS registered.

In order to aid understanding of the role of the IP-SM-GW, refer to Key Flows.

Major Components

The diagram below shows the major components for the Sentinel IP-SM-GW.

slee service view

The Sentinel Registrar and Sentinel IP-SM-GW are services running on the Rhino TAS platform, written using the Sentinel Framework. Third Party Registration support is provided by the Sentinel Registrar service. The core SMS flows of the IP-SM-GW are provided by the Sentinel IP-SM-GW service. The Cassandra DB appears in the diagram for each role it fulfills in the architecture (routing correlation, registration ownership tracking, and registrar data storage).

  1. to correlate the IMSI and Circuit Switched Routing Information,

  2. to track the most recent site a subscriber registered at in a multi-site geo-redundant setup, and

  3. to store Third Party Registration information. For more information refer to Sentinel Registrar Overview and Concepts

IMSI and Circuit Switched Routing Information correlation

The Sentinel IP-SM-GW uses a Cassandra Database to store and retrieve CS Routing Information. This means that any IP-SM-GW cluster member can process the MT Forward Short Message request regardless of the cluster member that processed the Routing Information for SM query.

This ensures that a deployment is simple from an SS7 addressing perspective, as only a single GT address is required.

Third Party Registration ownership tracking

The Sentinel IP-SM-GW uses a Cassandra Database to store and retrieve registration ownership information. This means that if IP-SM-GW is running in a multi-site geo-redundant setup, the site at which the subscriber most recently registered is tracked across all the sites. This ensures that subscribers can register at one site and re-register at a different site, with network-initiated de-registrations at sites previously registered at suppressing the AMT de-registration.

Support for GSM MAP

The Sentinel IP-SM-GW supports GSM/3GPP MAP Phases 1, 2 and 2+ for MT SMS. It uses MAP Phase 2 for Mobile Originated SMS submission into the SMSC.

Protocol support is provided through the use of OpenCloud CGIN and OCSS7 stacks. For protocol compliance statements refer to CGIN Protocol Compliance and OCSS7 Compliance Matrix.

Key Flows

This page presents illustrative flows for the major behaviours of the Sentinel IP-SM-GW product.

Flow area Summary

presents illustrative flows for the Mobile Originating SMS Submission path. This path is where the UE submits an SMS over IP.

presents illustrative flows for the MT SMS delivery path.

presents illustrative flows for the MT Online Charging.

presents illustrative flows for the Status Report path. This path is where the SMSC sends a Status Report after it has received a Delivery Report.

presents illustrative flows for the Short Message Memory Available path. This path is where the UE indicates that it has memory available to receive Short Messages, having previously refused SMS for delivery indicating that it did not have sufficient memory available.

presents illustrative flows for the Registration path.

presents illustrative flows for the UE Reachability path.

presents illustrative flows for USSD requests initiated by a UE

MO Submission Flows

This page presents illustrative flows for the Mobile Originating SMS Submission path. This path is where the UE submits an SMS over IP.

For details related to the features involved refer to Mobile Originated Features in the Administration Guide. Also see MT Online Charging Flows for more information about online charging.

This graph illustrates the normal MO submission flow with online charging enabled. If online charging is disabled for MO submissions, no CreditControlRequest will be sent and the initial MESSAGE will be accepted immediately.

sms-submission-full

In case there was an error submitting the SMS, a refund will be requested from the OCS.

sms-submission-full-refund

If online charging is enabled for MO submissions, but the subscriber is out of credit, the initial MESSAGE will be rejected with a 402 response. If there was a problem interacting with the OCS, for example if the CreditControlRequest timed out, a 403 will be sent as the response instead.

sms-submission-full-charging-fail

MT Delivery Flows

This page presents illustrative flows for the MT SMS delivery path.

About SMS delivery

The MT Delivery path has the IP-SM-GW invoked from the SMS-C. The SMS-C thinks it is signalling an MSC, but is actually signalling the IP-SM-GW.

The Sentinel IP-SM-GW attempts to deliver an SMS over the IMS network (using SIP) or the circuit-switched network (using MAP) depending on the following factors:

  1. the terminating UE is IMS Registered, and

  2. indicates that it supports receipt of SMS over IP during registration

  3. the content of the DeliveryOrder configuration field in the Shared Configuration Profile, which determines the preference for access network when delivering an SMS.

The product supports four delivery orders:

  1. PS (packet-switched/IMS) then CS (circuit-switched) - meaning that PS is first attempted, and if unsuccessful CS is attempted

  2. CS then PS - meaning that CS is first attempted, and if unsuccessful PS is attempted

  3. PS only - meaning that CS is not used

  4. CS only - meaning that PS is not used

Note PS then CS is the default delivery order

If delivery through either access is successful, the IP-SM-GW acknowledges the SMS-C. If delivery fails the IP-SM-GW sends an error response to the SMS-C. The IP-SM-GW may report the outcome of the final attempt to deliver the SMS by sending a MAP ReportSM_DeliveryStatus to the HLR.

When using PS then CS, the IP-SM-GW will attempt to deliver by PS if the destination user is IMS registered, and indicates support for receipt of SMS over IP. Assuming these two conditions are met, it will attempt to deliver the SMS via PS, and will try CS if:

  1. there was a timeout waiting for a response

  2. the SIP Message request containing the RP_DATA was responded to with an error response, and that error response was not an RP-Error whose cause code matched a configured RPErrorFallbackAvoidanceCodes value

When using CS then PS, the IP-SM-GW will attempt to deliver the SMS via the CS network. It will try to use the PS network if:

  1. the MAP MT Forward SM it sends towards the MSC/SGSN times out, or

  2. the MSC replies with an error response, and that error response is not a SM-DeliveryFailure whose Delivery Failure Case is configured to stop fallback to PS Delivery (as per DeliveryFallbackAvoidanceCodes)

  3. the destination user is both IMS registered and indicates support for receipt of SMS over IP

For details related to the features involved refer to Mobile Terminated Features in the Administration guide. When delivering via the CS network, TCAP Application Context Negotiation may occur.

Flows for SMS delivery

In the scenarios on this page, "Bob" is the receiver of the SMS.

Routing Information for Short Message flows

When the SMS-C attempts to deliver a set of one or more Short Messages, it first queries via the Send Routing Info for Short Message operation.

On initial registration, the IP-SM-GW informs the HLR that an IP-SM-GW is present, and sets it to be active.

PS Then CS Delivery

If the IP-SM-GW is configured for PS then CS delivery, then it is not necessary to query the HLR for the subscriber’s IMSI immediately.

If the subscriber is IMS registered, the correlation IMSI is generated and stored without CS routing information.

sri-sm-ps-then-cs-ims-registered-flow

If the subscriber is not IMS registered, then the HLR needs to queried for the subscriber’s IMSI.

sri-sm-ps-then-cs-not-ims-registered-flow

PS Only Delivery

If the IP-SM-GW is configured for PS only delivery, then it is not necessary to query the HLR for the subscriber’s IMSI.

If the subscriber is IMS registered, the correlation IMSI is generated and stored without CS routing information.

sri-sm-ps-only-registered-flow

If the subscriber is not IMS registered, SMS delivery is impossible and an AbsentSubscriber error will be generated.

sri-sm-ps-only-not-registered-flow

CS Only and CS Then PS Delivery

If the IP-SM-GW is configured for CS only or CS then PS delivery, the HLR is immediately queried for the subscriber’s IMSI.

sri-sm-flow

If the HLR responds to the SRI_SM with an AbsentSubscriber user error, the correlation IMSI is generated and stored without CS routing information.

sri-sm-absent-subscriber-flow

Forward Short Message flows

Now that the SMSC has a successful SRI for SM response, it can deliver Short Messages.

The first case shows the behaviour for PS then CS delivery (the default delivery order). The destination user is registered on the PS network, and receives the SMS appropriately. As a side note, this flow would also occur if the IP-SM-GW is configured for PS only delivery, or the correlation data did not include CS routing info as would follow from the AbsentSubscriber case in the Routing Information for Short Message flows above.

mt-fsm-user-ps-registered

In the case that the IP-SM-GW is configured for PS then CS delivery, and the destination user is not IMS Registered (or is IMS registered but does not support receipt of SMS over IP), the IP-SM-GW delivers via CS. As a side note, the same flow results if the product is configured as CS only.

mt-fsm-user-ps-not-registered

This flow illustrates the use of the Sh SubscribeNotificationRequest. In this flow, the the product is configured with the default delivery order (PS then CS). The destination user is IMS registered (indicating support for SMS over IP), but the IMS delivery fails. The IP-SM-GW then attempts a CS delivery. Depending on the reason why the IMS delivery fails the IP-SM-GW may request a notification for UE reachability for IP from the HSS. For the precise cases the notification is requested, please refer to Requesting a UE Reachability for IP Notification.

mt-fsm-user-ps-error-then-cs

This flow illustrates the product configured for CS then PS delivery, where the CS delivery indicates a suitable error code for attempting delivery via PS. The destination user is PS registered (indicating support for SMS over IP):

mt-fsm-cs-then-ps

MT Online Charging Flows

This page presents illustrative flows for the MT Online Charging.

About MT Online Charging for SMS in the IP-SM-GW

MT Online Charging uses the Diameter Ro protocol. The IP-SM-GW acts as the Charging Trigger Function, and uses Immediate Event Charging. MT Online Charging is triggered from the MT Delivery path. In Sentinel IP-SM-GW, the use of MT Online Charging is optional, and is selected during installation.

MT Delivery can either use the CS network (MSC and/or SGSN) or the PS Network (IMS core). Delivery related charging can be enabled separately for each network. If charging is disabled for a particular network, it is assumed that the network itself will take over this responsibility.

The PS network is used for delivery for two cases:

  1. An SMS being sent to the UE. In this case the IP-SM-GW sends a SIP Message request with body containing RP-DATA where the RP-User Data contains an SMS_DELIVER.

  2. An SMS Status Report sent to the UE. In this case the IP-SM-GW sends a SIP Message request with body containing RP-DATA where the RP-User Data contains an SMS_STATUS_REPORT.

The Online Charging System is able to distinguish these cases according to the AVPs sent by the IP-SM-GW. Details of the precise AVPs used is documented in the IPSMGWChargingInstanceToCCR mapper.

MT Online Charging is implemented by the IPSMGW IEC Feature.

If online charging is enabled for both the PS and CS networks, and the DeliveryOrder attribute in the UNRESOLVABLE BXREF: shared-configuration-profile[Shared Configuration Profile] is set to PS_THEN_CS or CS_THEN_PS, then the charging session will carry over to the fallback session in the case of a delivery failure. This means that the IEC feature will not request a refund after the first failure, and it will not initiate a new charging session for the fallback delivery attempt. A refund will only be requested if the delivery attempts over both networks fail.

Flows for MT Online Charging

In the scenarios on this page, "Bob" is the receiver of the SMS.

All MT Online Charging related logic in the IP-SM-GW is triggered from the receipt of a MAP MT Forward Short Message operation.

This flow shows that:

  1. A PS delivery will be attempted, and therefore

  2. immediate charging request occurs, and is granted successfully

  3. the PS delivery fails, and therefore charging is refunded as CS charging is disabled

The product default is that if PS delivery fails, CS delivery is attempted. This is a different set of functionality than charging. For more information on delivery order please refer to MT Delivery Flows.

mt-fsm-user-ps-error-iec

The next flow shows default behaviour for when the charging request is refused, as the credit limit has been reached.

mt-fsm-user-ps-credit-limit-reached-iec

The next flow shows a delivery order of CS_THEN_PS, with charging enabled for both. Both delivery attempts fail, so a refund is initiated after the failed PS delivery.

mt-fsm-cs-then-ps-charging

Additional Sentinel capabilties for Online Charging

The Sentinel framework (IP-SM-GW is built on top of the Sentinel framework) allows different models for units being requested and granted than that shown in the above flow. These capabilities are often used for various "OCS failure handling" policies.

For example Sentinel can be configured such that:

  1. There are pools of units that are locally granted if the OCS request times out, once the pool is expired, further reservations against the pool are refused

  2. Certain classes of users are always granted credit, and the OCS is not requested

  3. other combinations of local pool use with user distinctions

For more information about such capabilities please refer to Promotions.

Registration Flows

This page presents illustrative flows for the Registration path.

For details related to the features involved refer to Registrar Features in the Administration Guide.

On initial registration, the IP-SM-GW informs the HLR that an IP-SM-GW is present, and sets it to be active. IP-SM-GW also informs the HLR the user is ready to receive short messages.

registration-flow

On deregistration, the IP-SM-GW informs the HLR that the IP-SM-GW is not active for this user.

sms-deregistration

Short Message Memory Available Flows

This page presents illustrative flows for the Short Message Memory Available path. This path is where the UE indicates that it has memory available to receive Short Messages, having previously refused SMS for delivery indicating that it did not have sufficient memory available.

For details related to the features involved refer to Short Message Memory Available Features in the Administration Guide.

smma-full

Status Report Flows

This page presents illustrative flows for the Status Report path. This path is where the SMSC sends a Status Report after it has received a Delivery Report.

The flows are essentially the same as the MT Delivery Flows. The distinction is that they are triggered by the SMSC when it receives a Delivery Report, rather than an SMS.

UE Reachability for IP Notification Flows

This page presents illustrative flows for the UE Reachability path.

Prior to this flow, an SMS delivery via IMS failed with a particular reason, and the IP-S-MGW has subscribed to receive UE Reachability for IP notifications. This path is where the HSS sends a Sh Push Notification Request indicating that the UE has attached to Packet Radio. The specific cases where the IP-SM-GW requests a UE Reachability for IP notification is described Requesting a UE Reachability for IP Notification.

For details related to the features involved refer to the Fetch IMSI and Ready For SM features.

ue-reachability-flow

Triggered by a Push Notification Request (PNR) from the HSS indicating the UE has attached to Packet Radio. The IPSMGW retrieves the associated IMSI and informs the HLR that the UE is Ready for SM delivery.

USSD requests initiated by a UE

This page presents illustrative flows for USSD requests initiated by a UE . The USSI features are described in the administration guide.

A balance query example

A signalling diagram for a balance query operation is shown below.

ussi-ue-initiated-full

1 - The INVITE has an SDP offer as per TS 24.390 section 4.5.2. The INVITE body is as per 24.390. It is a multi-part body with both an SDP and a USSD message. An example of a USSD message is

Content-Type: application/vnd.3gpp.ussd+xml

<?xml version="1.0" encoding="UTF-8"?>
<ussd-data>
    <language>en</language>
    <ussd-string>*100*1#</ussd-string>
</ussd-data>

2 - An iFC is used to match USSD requests. An example is shown in INVITE Request containing USSD content

3 - A 2xx to the INVITE is sent, confirming the dialog. The SDP answer reflects the offer. The response contains a Recv-Info header field set to g.3gpp.ussd

4 - Forwarded to the UE

5 - ACK

6 - Forwarded to the IPSMGW/USSIGW

7 - A MAP Process-Unstructured-SS-Request containing the USSD message is sent to the HLR addressed using the MSISDN

8 - The HLR sends it towards the Prepaid SCP

9 - The SCP responds with the balance information in a USSD message

10 - Forwarded to the IPSMGW/USSIGW

11 - The IPSMGW/USSIGW converts the USSD message in the response into an XML document. It is placed in the body of the BYE request

An example is

Content-Type: application/vnd.3gpp.ussd+xml

<?xml version="1.0" encoding="UTF-8"?>
<ussd-data>
    <language>en</language>
    <ussd-string>
        Hello, your credit is $175.50. Thanks for your query.
        We are happy to assist. Your operator
    </ussd-string>
</ussd-data>

12 - Proxied to the UE

Overview of the TCAP Leg Manager

This section includes the following topics:

Topic Explains…​

What is the TCAP Leg Manager

what the TCAP leg manager is

Introducing the TCAP Leg Manager API

the Application Programming Interface (API) available to features using the TCAP leg manager (and TCAP legs)

TCAP Messages

TCAP messages and how they relate to the TCAP leg manager and TCAP legs

TCAP Leg Manager Statistics

the statistics collected by the TCAP leg manager

What is the TCAP Leg Manager

The TCAP leg manager is a new type of event manager that is used within the IPSMGW.

The TCAP Leg Manager

The TCAP leg manager is used within the IPSMGW to manage GSM MAP 'legs'. Each TCAP leg corresponds to a Dialog between the IPSMGW and an external network element such as an SMSC, MSC or HLR.

tcap leg manager
Figure 1. The TCAP Leg Manager

1

The IPSMGW interconnects with a number of external network elements, such as an SMSC, MSC and HLR

2

Features (such as the MAP Proxy), running within the IPSMGW, interact with these external network elements by using the TCAP Leg Manager and TCAP Legs

3

The TCAP Leg Manager is responsible for managing all TCAP Legs that exist within the IPSMGW.

4

The TCAP leg manager provides an API (Application Programming Interface) that Features (such as the MAP Proxy) may use to create, remove and find TCAP Legs. In this particular example, the MAP Proxy feature in interested in two TCAP legs incoming and proxied

5

Each TCAP Leg is associated with a Dialog. The Dialog represents a real protocol session between the IPSMGW and an external network element. Features use the API of the TCAP Leg to operate on the Dialog. For example if the MAP Proxy feature calls refuseDialog() on a TCAP Leg, then the underlying Dialog will be refused by sending an OpenRefuse to the external network element.
Tip

To learn more about the TCAP leg manager and TCAP leg APIs see Introducing the TCAP Leg Manager API
Tip

See What is an Event Manager? to learn more about event managers.
Note

The TCAP leg manager may be used in future releases of Sentinel for other protocols such as INAP and CAP.

Events Processed by the IPSMGW

The IPSMGW receives events from several sources:

Source Received from Examples

GSM MAP

an external MAP network element (such as an SMSC or HLR)

TC-Begin (such as a DialogOpen)
TC-Continue (such as a DialogOpenAccept)
TC-End (such as a DialogOpenRefuse)

SIP

an external SIP network element (such as an S-CSCF)

SIP MESSAGE request

Diameter

the Sentinel mediation layer (related to events from an external OCS)

Extension

external network elements for sessions initiated by features within Sentinel

Timer

timers that features raise using the ServiceTimerProvider

Local

raised internally by Sentinel, as a result of processing other events and instructions

EndSessionEvent, when the Sentinel session has ended (that is, no more TCAP legs, SIP legs or charging instances remain active)

InstructionExecutionFailedEvent, when one or more event manager instructions failed during processing

IPSMGW event-processing algorithm

The IPSMGW extends Sentinel SIP by adding the TCAP Leg Manager. The following diagram is an overview of how the IPSMGW processes events:

ipsmgw event model
Figure 2. Processing Events in the IPSMGW
Tip

See: Sentinel SIP event-processing algorithm for additional detail related to SIP.

As shown above:

1

The IPSMGW receives a real event, such as an DialogOpen request from the SMSC or a SIP MESSAGE and starts an event loop:

Loop

Update Event Managers …​ Process Feature Script Execution Points …​ Process Event Manager Instructions

Until the local event queue is empty.

2

Event managers process the received event. They:

  • update their own state

    For example, the TCAP Leg Manager creates a new leg for an initial DialogOpen request

  • determine if one or more feature script execution points should be triggered for the event

3

If there are any feature script execution points to trigger, then process them; otherwise see if event managers have any instructions to carry out.

4

Process each feature script execution point in turn. Features may update the state of the Charging, TCAP and SIP Leg Managers as they execute. For example, a feature might create a new TCAP leg, or link two TCAP legs.

Once all feature script execution points have been processed, then check if the event managers have any instructions to carry out.

5

Ask each event manager in turn to carry out any pending instructions that have accumulated while processing the event.

Each event manager manages a set of instructions while features are executing. For example, if a feature calls issueOpenRequest(openRequest) on a TcapLeg, then the TCAP leg manager will record a pending instruction of sendTcapMessage.

Once all pending instructions have been processed, then see if there are any events in the local event queue. If the local event queue is empty, then wait for the next real event. Otherwise, de-queue a local event and process it.

6

Event processing ends once the session ends.

Introducing the TCAP Leg Manager API

There are three aspects to the TCAP Leg Manager APIs:

  1. The TcapLegManager interface — Feature developers use this interface to create, release and detach TcapLegs. Feature developers also use this interface to find a TcapLeg by name, Dialog or ActivityContextInterface. For more information see: Managing TCAP Legs

  2. The TcapLeg interface — Feature developers use this interface to send messages on a TcapLeg, inspect any pending messages and inspect the latest received or sent message on a leg. For more information see: Operating on a TCAP Leg

  3. The TcapMessage and TcapComponent hierarchies — The classes and interfaces in these hierarchies are the TCAP messages that are send and received on a TcapLeg. For more information see: TCAP Messages

Tip

See: Sentinel IP-SM-GW API Javadoc

TCAP Messages

The TCAP message and TCAP component hierarchies represent the TCAP messages sent and received between the IPSMGW and remote TC-Users. These objects are POJOs (Plain Old Java Objects) that may be created and updated as needed and stored in CMP fields.

TCAP Messages - The Dialog Message Hierarchy

The IPSMGW receives events from the CGIN MAP resource adaptor and builds message objects the correspond to whole TCAP messages received on the wire.

Tip

See: CGIN Connectivity Pack to learn more about SS7 interfaces in the Rhino TAS platform.
dialog messages
Figure 3. The Dialog Message Hierarchy

At the top of the hierachy is the DialogTCAPMessage interface, which has operations that you use to:

  • find out if the message is a TC-Begin, TC-Continue or TC-End

  • find out if the message is a DialogOpenRequest, DialogOpenAccept, DialogOpenRefuse, DialogUserAbort, DialogProviderAbort or a DialogMessage

  • see if the message contains any components.

The concrete classes include:

  • DialogOpenRequestTcapMessage — The initial message for a new dialog (always a TC-Begin). An open request includes source and destination address, a TCAP Application Context to use for the new dialog and may optionally include components.

  • DialogOpenAcceptTcapMessage — A first response on a new Dialog, which indicates the remote TC-User has accepted the new Dialog (a TC-Continue or a TC-End). An open accept may optionally include components.

  • DialogOpenRefuseTcapMessage — A first response on a new Dialog, which indicates the remote TC-User has refused the new Dialog (always a TC-End). An open refuse contains a refuse reason, (optionally) a peer abort cause and (optionally) a suggested alternative TCAP Application Context

  • DialogUserAbortTcapMessage — A message indicating the fatal ending of a Dialog (always a TC-End).

  • DialogProviderAbortTcapMessage —  A message indicating the fatal ending of a Dialog related to the local TC provider (always a TC-End).

  • DialogMessageTcapMessage — Every other type of message received on a Dialog (a TC-Continue or a TC-End). This type of message may optionally include components.

Tip

The DialogTcapMessage interface and concrete classes API can be found in the “com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage” section of the Sentinel IP-SM-GW API Javadoc
Tip

See Using The Leg Manager in the IP-SM-GW SDK guide to learn more about using these objects during the development of your own features.

TCAP Components - The Operation Component Hierarchy

components
Figure 4. The Operation Component Hierarchy

Storing TCAP Messages in CMP fields

The TCAP messages are POJOs (Plain Old Java Objects) that may be created and updated as needed and stored in CMP fields. Whilst these objects are all Serializable it is far more efficient to use the DialogTcapMessageCodec as in the following example.

package com.opencloud.sentinel.ipsmgw.myfeature;

import com.opencloud.rhino.cmp.codecs.DatatypeCodecType;
import com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage.DialogTcapMessage;
import com.opencloud.sentinel.ipsmgw.eventmanager.tcapmessage.persist.DialogTcapMessageCodec;

public interface MyFeatureCMP {

    /** * Set the 'MyTcapMessage' cmp field * @param message cmp field value */
    @DatatypeCodecType(DialogTcapMessageCodec.class)  1
    void setMyTcapMessage(DialogTcapMessage message); 2

    /** @return 'MyTcapMessage' cmp field value */
    DialogTcapMessage getMyTcapMessage(); 3

    /** @return true if 'MyTcapMessage' cmp field is set */
    boolean hasMyTcapMessage(); 4

    /** Clear 'MyTcapMessage' cmp field */
    void resetMyTcapMessage(); 5
}
1 DatatypeCodecType annotation tells Rhino to use DialogTcapMessageCodec to encode/decode DialogTcapMessage objects
2 set operation for the MyTcapMessage CMP field
3 get operation for the MyTcapMessage CMP field
4 (optional) has operation for the MyTcapMessage CMP field
5 (optional) reset operation for the MyTcapMessage CMP field
Tip

See: Rhino TAS > CMP Field Enhancements to learn more about using CMP fields in Rhino

TCAP Leg Manager Statistics

The TCAP Leg Manager collects a number of statistics that can be monitored and used to create Threshold based alarms.

Tip

See: Rhino TAS > Monitoring and System-Reporting Tools to learn how to monitor statistics in the IPSMGW See: Rhino TAS > Threshold Alarms to learn how to create your own threshold based alarms
Statistic When incremented

LegCreated

A TCAP leg has been created successfully

CreateLegFailed

A failure happened whilst trying to create a TCAP leg

DialogImportedAsNewLeg

A TCAP leg has been created from an existing Dialog

ImportDialogAsNewLegFailed

A failure occured creating a new TCAP leg from an existing Dialog

OtherLegExistsOnImportDialogAsNewLeg

A new TCAP leg failed to be created from an existing Dialog because there already exists a TCAP leg related to the Dialog

LegAlreadyExistsOnImportDialogAsNewLeg

A new TCAP leg could not be created as there already exists a TCAP leg with the requested name

LegReleased

A TCAP leg was released successfully

ReleaseLegFailed

A TCAP leg failed to be released

LegDetached

A TCAP leg was detached successfully

DetachLegFailed

A TCAP leg failed to be detached

EndSession

The session was ended successfully

AbortOnError

The session was ended in response to an AbortOnErrorEvent

LegSuspended

A TCAP leg was suspended successfully

LegResumed

A TCAP leg was resumed successfully

EventOnUnknownLegNotOpenRequest

The first event processed in the context of Dialog for which there is no TCAP leg was not a DialogOpenRequest

FailedToProcessOpenRequest

A failure occured processing a DialogOpenRequest

UnsupportedEventReceived

An type of event that is unknown to the TCAP leg manager was received

UnsupportedTcapApplicationContext

A DialogOpenRequest was received with a TCAP Application Context that is not supporte by the TCAP leg manager

FailedToProcessTcapMessage

A message received on an existing TCAP leg failed to be processed

FailedToSendTcapMessage

A sendTcapMessage instruction was unsuccessful because a message failed to be sent