On this page

What it does

The IP Short Message Gateway (IP-SM-GW) translates SMS traffic between GSM and LTE networks.

The Rhino VoLTE TAS IP-SM-GW is based on 3GPP TS 24.341, and implements suitable SMS interworking as part of GSMA IR.92 version 9.0.

Note The IP-SM-GW only supports MAP-based SS7 protocols. CDMA networks are not supported.

MO and MT

The IP-SM-GW handles both Mobile Originating (MO) and Mobile Terminating (MT) messages. In MO scenarios, the short message is received over a packet-switched (PS) network and submitted to a Short Message Service Center (SMSC) over a circuit-switched (CS) network. In MT scenarios, the short message is received from a Gateway Message Switching Center (GMSC) and delivered to the subscriber over either the PS or CS network.

Charging

The IP-SM-GW can control Diameter Ro charging for both MO and MT scenarios. The IP-SM-GW acts as the Charging Trigger Function, and uses Immediate Event Charging. Charging can be enabled separately for each of MO, PS MT, and CS MT traffic scenarios.

Routing modes

The IP-SM-GW supports four different modes which determine how it will prioritize its attempts to deliver MT traffic.

Table 1. IP-SM-GW delivery modes
Parameter value Behavior
PS_THEN_CS

Try packet-switched network first, then fall back to the circuit-switched network.

CS_THEN_PS

Try circuit-switched network first, then fall back to the packet-switched network.

PS_ONLY

Only try delivery over the packet-switched network.

CS_ONLY

Only try delivery over the circuit-switched network.

In the case of the CS_THEN_PS and PS_THEN_CS modes, message delivery can be controlled further through the use of avoidance codes, which allow you to avoid fallback based on the response to the initial delivery attempt.

PS fallback avoidance codes

When PS delivery fails, the CP-Cause parameter in the resulting RP-Error is checked against the entries in the avoidance-codes-ps-to-cs list. The numeric causes and their meanings can be found in TS 24.011 Section 8. If the CP-Cause received is present in the configured list, CS delivery will not be attempted.

The table below lists the avoidance values.

Table 2. PS to CS fallback avoidance codes
Cause Value

UNASSIGNED_NUMBER

1

OPERATOR_DETERMINED_BARRING

8

CALL_BARRED

10

RESERVED

11

SHORT_MESSAGE_TRANSFER_REJECTED

21

MEMORY_CAPACITY_EXCEEDED

22

DESTINATION_OUT_OF_ORDER

27

UNIDENTIFIED_SUBSCRIBER

28

FACILITY_REJECTED

29

UNKNOWN_SUBSCRIBER

30

NETWORK_OUT_OF_ORDER

38

TEMPORARY_FAILURE

41

CONGESTION

42

RESOURCES_UNAVAILABLE

47

REQUESTED_FACILITY_NOT_SUBSCRIBED

50

REQUESTED_FACILITY_NOT_IMPLEMENTED

69

INVALID_SHORT_MESSAGE_REFERENCE_VALUE

81

INVALID_MESSAGE

95

INVALID_MANDATORY_INFORMATION

96

MESSAGE_TYPE_NONEXISTENT_OR_NOT_IMPLEMENTED

97

MESSAGE_NOT_COMPATIBLE_WITH_SHORT_MESSAGE_PROTOCOL_STATE

98

INFORMATION_ELEMENT_NONEXISTENT_OR_NOT_IMPLEMENTED

99

PROTOCOL_ERROR

111

INTERWORKING

127

CS fallback avoidance codes

When CS delivery fails, the SM-EnumeratedDeliveryFailureCause parameter in the error response is checked against the entries in the avoidance-codes-cs-to-ps list. The numeric causes and their meanings can be found in TS 29.002 Section 17.7.7 Error data types. If the value is present in the list, PS delivery will not be attempted. The values of the avoidance codes used when avoiding fallback from CS to PS are listed below.

Table 3. CS to PS fallback avoidance codes
Cause Value

memoryCapacityExceeded

0

equipmentProtocolError

1

equipmentNotSM_Equipped

2

unknownServiceCentre

3

sc_Congestion

4

invalidSME_Address

5

subscriberNotSC_Subscriber

6

UE reachability notifications

The IP-SM-GW supports UE Reachability Notifications in the case where an MT message sent over a PS network cannot be delivered due to the UE becoming unavailable. In this situation, the IP-SM-GW will request a notification from the HSS in the event that the UE comes back online. When this notification is received from the HSS, the IP-SM-GW will notify the HLR that UE is ready for SM delivery.

Multiple sites and geo-redundancy

The IP-SM-GW can be deployed at multiple geographically distributed sites. To configure full geographic redundancy including cross-site failover, contact support.

Networking considerations

The IP-SM-GW interfaces with network elements from a variety of different vendors. A number of configuration options are available to control the interactions with these elements, particularly the HLR and MSCs.

Modifying SCCP-layer addressing

When accepting an OpenRequest, the SCCP responder address in the OpenAccept will, by default, be set to the value of the SCCP called party in the OpenRequest. If use-gt-as-calling-party is set to true, and if the received sccp-called-party contains a global title, the responder address will be modified in the following way:

  • the Translation Type is set to 0

  • the Routing Indicator will be set to gt

  • the Point Code will be unset

  • the National indicator will be set to false.

This is useful when the inbound sccp-called-party has been modified by a network element to use PC/SSN routing, but GT routing is required for establishing the TCAP dialog.

Use allow listing for incoming SCCP global titles

The IP-SM-GW can filter incoming SCCP messages on global title prefix, to help control the network elements permitted to initiate CS connections.

Suppress HLR interaction

The IP-SM-GW supports the suppression of all HLR interactions. This removes the CS capability and dependencies from the product, allowing it to work as a purely PS to PS platform.

Content size threshold

During MO message delivery, the IP-SM-GW will either include the ForwardSM in the TC-BEGIN message, or send the ForwardSM separately. This determination is configurable based on message content size.

Setting DeliveryNotIntended during SMMA flows

When the IP-SM-GW sends a SendRoutingInfoForSM request to the HLR which is not part of an MT delivery flow, the DeliveryNotIntended flag may be used to indicate that the HLR should not expect follow-up messages. This should be adjusted based on HLR capabilities.

Configuration

Example IP-SM-GW configuration can be found in the example for sentinel-ipsmgw-config.yaml and in the example for hlr-config.yaml.


What you need

  • ❏ The number of geographically distributed sites in use.

  • ❏ The SCCP addressing format in use.

  • ❏ The externally-visible global title of the SMO cluster.

  • ❏ The domain to use for outgoing SIP messages.

  • ❏ Whether all HLR interaction should be suppressed.

  • ❏ The PLMN ID ranges in use.

  • ❏ The MT message delivery order, and any fallback avoidance codes.

  • ❏ A DNS record pointing at all SMO node signalling interfaces.

  • ❏ The Ro charging configuration in use.

Setting up network integration

Initial configuration

Network integration must be configured before further configuration of the system can take place.

1. Adjust the georedundancy setting to suit your deployment

In the georedundancy section, uncomment the georedundancy and total-sites lines, and set total-sites to 2.

        # The number of IPSMGW sites
        total-sites: 2
Note To configure full geographic redundancy, including cross-site failover, contact support.
2. Configure the SCCP address format used when connecting to an SMSC.

The template-smsc-address is used to specify the non-digit string portions of the SMSC’s SCCP address, which MT CS messages will be sent to.

In the map-messaging section, set the template-smsc-address as appropriate for your network.

        template-smsc-address: "type=C7,ri=gt,digits=0,ssn=8,national=false,nature=INTERNATIONAL,numbering=ISDN,gti=4,tt=0"
3. Set the SCCP address used as the calling party address in SS7 messages initiated by the IP-SM-GW.

In the map-messaging section, set the originating-address as appropriate for your network.

        originating-address: "type=C7,ri=pcssn,pc=5,ssn=148"
Warning If the originating-address contains a pc= parameter, that parameter’s value must be the same as the point-code value in sgc-config.yaml. See M3UA interface configuration.
4. Set the address that GMSCs will use to contact the IP-SM-GW

The ipsmgw-as-msc-address is the address that the IP-SM-GW will return to the GMSC during the SendRoutingInformation phase of the MT message procedure, so that subsequent messages will be delivered to the IP-SM-GW. TCAP messages with this address should be routeable to an IP-SM-GW node.

In the map-messaging section, set the ipsmgw-as-msc-address to an address which will route to the IP-SM-GW.

        ipsmgw-as-msc-address: "address=653333333,nature=INTERNATIONAL,numberingPlan=ISDN"
5. Configure how to determine the address of the HLR

When processing MT messages, the IP-SM-GW can determine the address of an HLR in two ways. The HLR address can be fixed and set in the hlr section of hlr-config.yaml, or alternatively the MSISDN of the called party can be used as the digit portion of the HLR address.

  • If you are using a fixed HLR address:

In hlr-config.yaml, confirm that the hlr-address is set correctly.

hlr-config.yaml
        hlr-address: "type=C7,ri=gt,digits=123456789,ssn=8,national=false,nature=INTERNATIONAL,numbering=ISDN,gti=4,tt=0"

In sentinel-ipsmgw.yaml, in the map-messaging section, set use-msisdn-as-hlr-address to false.

sentinel-ipsmgw-config.yaml
        use-msisdn-as-hlr-address: false
  • If you are using dynamic routing for the HLR address:

In hlr-config.yaml, in the hlr section, ensure that the hlr-address field is set to use global title addressing.

hlr-config.yaml
        hlr-address: "type=C7,ri=gt,digits=0,ssn=8,national=false,nature=INTERNATIONAL,numbering=ISDN,gti=4,tt=0"

In sentinel-ipsmgw.yaml, in the map-messaging section, set use-msisdn-as-hlr-address to true.

sentinel-ipsmgw-config.yaml
        use-msisdn-as-hlr-address: true
6. Configure the terminating SIP URI domain

Outbound SIP messages generated by the IP-SM-GW require a configured value to use as the domain portion of the SIP URI. Set this to a network-appropriate SIP domain.

Set the terminating-domain value to an appropriate SIP domain.

    terminating-domain: example.com

I want to…​

Deploy the IP-SM-GW in an environment without an HLR

In hlr-config.yaml, in the hlr section, ensure that the hlr-address field is set to the default value.

hlr-config.yaml
        hlr-address: "type=C7,ri=pcssn,pc=5,ssn=6"

In sentinel-ipsmgw.yaml, set delivery_order to PS_ONLY. In sentinel-ipsmgw.yaml, in the map-messaging section, set suppress-hlr-interaction to true.

sentinel-ipsmgw-config.yaml
    map-messaging:
        use-msisdn-as-hlr-address: true
    delivery-order: PS_THEN_CS
Prefer GT addressing for SCCP calling party in OpenResponse messages

In the map-messaging section, set the use-gt-as-calling-party value to true.

        use-gt-as-calling-party: true
Send ForwardSM messages with 120 characters in a separate TCAP message

In the map-messaging section, set the sms-content-size-threshold value to 119.

        sms-content-size-threshold: 119

Related section: Content size threshold

Disable the delivery-not-intended flag in SendRoutingInformationForSM requests

In the map-messaging section, set the sri-sm-delivery-not-intended value to false.

        sri-sm-delivery-not-intended: false
Set the PLMN ID used when generating correlation IMSIs

The PLMN ID used when generating correlation IMSIs must be part of the Home Network PLMN ID set. See Set the PLMN IDs for my network for details.

Setting up Mobile Terminating scenarios

I want to…​

Attempt delivery over PS first, falling back to CS unless there are network problems

First, reference the table in PS fallback avoidance codes to determine the numeric codes relevant to the fallback avoidance scenarios. In this case, codes 42 and 38 are appropriate (CONGESTION and NETWORK_OUT_OF_ORDER respectively).

Set the delivery-order to PS_THEN_CS. In the fallback-settings section, set avoidance-codes-ps-to-cs to a list containing these values:

    delivery-order: PS_THEN_CS
    fallback-settings:
        avoidance-codes-ps-to-cs:
          - 42
          - 38

Related section: :Routing modes

Attempt delivery over CS first, falling back to PS unless there are network problems

First, reference the table in CS fallback avoidance codes to determine the numeric codes relevant to the fallback avoidance scenarios. In this case, code 4 is appropriate (sc_Congestion).

Set the delivery-order to CS_THEN_PS. In the fallback-settings section, set avoidance-codes-cs-to-ps to a list containing 4.

    delivery-order: CS_THEN_PS
    fallback-settings:
        avoidance-codes-cs-to-ps:
          - 4

Related section: Routing modes

Subscribe to UE reachability notifications

In the ue-reachability-notifications section, set the notification-host parameter to an appropriate hostname value. This hostname must be configured in DNS to point at the signalling IPs of all SMO nodes in the cluster.

        notification-host: smo.site1.mnc123.mcc530.3gppnetwork.org

Setting up charging

I want to…​

Configure charging for MO and MT PS traffic

In the charging-options section, uncomment and configure the diameter-ro section.

        # You must also specify the per-node-diameter-ro configuration in smo-vmpool-config.yaml
        diameter-ro:
            diameter-ro-release: Vcb0
            origin-realm: metaswitch.com
            destination-realm: metaswitch.com
            destination-peers:
                - destination-hostname: peer.metaswitch.com
                  port: 3868
                  protocol-transport: aaa
                  metric: 1

In the charging-options section, set mt-ps-enabled and mo-ps-enabled to true.

        mt-ps-enabled: true
        mt-cs-enabled: false
        mo-ps-enabled: true

In smo-vmpool-config.yaml, you must ensure that all per-node-diameter-ro sections are present and not commented out.

          # Uncomment this if diameter-ro is enabled
          per-node-diameter-ro:
              diameter-ro-origin-host: smo1.smo.site1.mnc123.mcc530.3gppnetwork.org

Related section: Charging

Previous page Next page
Rhino VoLTE TAS Version 4.1