SMPPApp

SMPP Application Configuration

The SMPP Application is responsible for sending and receiving SMPP short messages as an SME or SMSC.

The SMPP Application does not initiate any user content itself. It exists only as an agent to send/receive requests (e.g. deliver_sm or submit_sm) on behalf of another application.

Typical uses of the SMPP Application are:

• As an outbound SMPP Gateway, the LogicApp Lua scripting logic can use SMPPApp to initiate outbound SMPP requests (via the SMPPLuaAgent agent plugin).
• As an inbound SMPP Gateway, inbound SMPP requests are handed over to the LogicApp to invoke Lua scripting logic (via the SMPPLuaService service plugin).
• As an outbound SMPP Gateway, a TesterApp script can use the smpp.smsc_to_esme.Request Test operation to request SMPPApp to initiate outbound SMPP requests.
• As an inbound SMPP Gateway, inbound SMPP requests can be handed over to the TesterApp (assuming that a currently executing Test Script is waiting to receive them).

See the N2SVCD Configuration Overview for more information on how the SMPP Application interacts with other components.

An example SMPP Application configuration (without connection details; see SMPP Application Connection Modes below ) might be:

<?xml version="1.0" encoding="utf-8"?>
<n2svcd>
  ...
  <applications>
    ...
    <application name="SMPP-App" module="SMPPApp">
      <include>
        <lib>../apps/smpp/lib</lib>
      </include>
      <parameters>
        <parameter name="trace_level" value="1"/>
        <parameter name="password" value="MYPASS"/>
        <parameter name="ping_interval" value="300"/>
        <!-- connection details -->
        <parameter name="flash_encode_mode" value="smpp_strict"/>
        <parameter name="flash_decode_alphabet_7bit" value="gsm7bit-default"/>
        <parameter name="flash_decode_alphabet_8bit" value="gsm8bit-default"/>
        <parameter name="flash_decode_alphabet_16bit" value="ucs2"/>
      </parameters>
      <config>
        <handlers>
          <handler application="IN Tester"/>
        </handlers>
        <data_coding_mapping>
          <mapping encoding="gsm8-default" value="0" />
          <mapping encoding="ascii" value="1" />
          <mapping encoding="ucs2" value="8" />
        </data_coding_mapping>
      </config>
    </application>
    ...
  </application>
  ...
</n2svcd>

SMPP Application Connection Modes

The SMPP Application may connect to SMSCs as an SME client (connect mode) or may be connected to by SMEs as an SMSC server (listen mode).

Connections to and from the N2SVCD SMPP Application are made via the SMPP bind_* operations. The SMPP outbind operation is not supported.

The following example parameters could be used for an SMPP Application TCP Server instance.

<?xml version="1.0" encoding="utf-8"?>
<n2svcd>
  ...
  <applications>
    ...
    <application name="SMPP-Server" module="SMPPApp">
      ...
      <parameters>
        ...
        <parameter name="num_client_connections" value="2"/>
        <parameter name="socket_mode" value="listen"/>
        <parameter name="local_host" value="0.0.0.0"/>
        <parameter name="local_port" value="4001"/>
      </parameters>
      ...
    </application>
    ...
  </application>
  ...
</n2svcd>

The following example parameters could be used for an SMPP Application TCP Client instance.

<?xml version="1.0" encoding="utf-8"?>
<n2svcd>
  ...
  <applications>
    ...
    <application name="SMPP-Server" module="SMPPApp">
      ...
      <parameters>
        ...
        <parameter name="socket_mode" value="connect"/>
        <parameter name="reconnect_interval" value="60"/>
        <parameter name="remote_host" value="localhost"/>
        <parameter name="remote_port" value="4001"/>
      </parameters>
      ...
    </application>
    ...
  </application>
  ...
</n2svcd>

Configuration Details

The application element attributes for an SMPP Application instance may include the below.

For details of the various parameter types used, refer to Common Configuration.

SMPP Handlers

Handler rules define which application is used to process inbound submit_sm and deliver_sm operations. Each handler Object in the config.handlers Array is configured as follows.

The handlers will be checked in order, and the first matching handler will be used.

SMPP Data Coding

Available Alphabets

When defining Data Coding Alphabet Mapping or Inbound Flash Message Decoding, several alphabets are available for use:

Data Coding Alphabet Mapping

When sending or receiving SMPP messages, the N2SVCD SMPP Application must have a mapping provided in order to correctly tie on-the-wire data coding values with the encoding alphabet used by either side of the message. This is specified in the data_coding_mapping configuration block with each mapping taking the following parameters:

If no data coding alphabet mapping configuration is provided, the following will be used by default:

        <data_coding_mapping>
          <mapping encoding="gsm8-default" value="0" />
          <mapping encoding="ascii" value="1" />
          <mapping encoding="iso-8859-1" value="3" />
          <mapping encoding="ucs2" value="8" />
        </data_coding_mapping>

Note that if any data coding alphabet mapping is provided, the default mappings will not apply. Data coding alphabet mappings must be provided in full.

Flash Messaging

Note that the reference information given here is minimal; for further details please refer to the Short Message Peer to Peer Protocol Specification v3.4 / v5.0 and/or GSM TS 03.38 / ETSI TS 123 038 (3GPP TS 23.038).

When SMPP short messages are created by N2SVCD or external entities, it is possible to specify that the message is a “flash” message (AKA GSM “message class 0”). Such messages are displayed on the user’s handset, but are not saved.

Different flash message modes options are provided by the SMPP Application because a strict interpretation of the SMPP standard supports only 7-bit and 8-bit text via GSM message class control using a data_coding value of 1111xxxx. The remaining bits are then filled according to GSM 23.038 in the format 0zaa, where:

• z refers to the data coding, either 0 for GSM 7-bit or 1 for 8-bit.
• aa is the message class, which will always be set to 00 for flash.

However, as this format does not allow for 16-bit encoding, there is an alternate encoding method from the same GSM standard that is sometimes used, despite being explicitly outside the SMPP defined values. This alternate encoding has a data coding value of 00xyzzaa, where:

• x refers to message compression. For N2SVCD, this will always be set to 0 (uncompressed).
• y is a flag for a defined message class. This will always be set to 1 as a message class is present in the aa bits.
• zz refers to the encoding used: 00 for GSM 7-bit, 01 for 8-bit, or 10 for 16-bit.
• aa is the message class, which will always be set to 00 for flash.

Finally, the SMPP standard alternately suggests using the TLV dest_addr_subunit to carry the message class, with the values:

• 0 as an unknown message class.
• 1 equivalent to “flash”.
• 2 equivalent to a normal message.

Outbound Flash Message Encoding

For the reasons given under Flash Messaging, the SMPP Application offers the following modes for flash message data coding when creating outbound short messages:

Note that none of these options have any impact for the data coding value generated for non-flash short messages, which is always set according to the standard SMPP data coding format of 0000xxxx based on the data coding mapping used.

Outbound short messages are created using the SMPP-C-REQUEST message type. Refer to the specific message type documentation for full details of this message type, including how to specify the message class and non-encoded text in input to the SMPP Application.

Inbound Flash Message Decoding

When SMS are received for processing by the SMPP Application, the data coding value is analyzed to determine the appropriate alphabet to use for the message text decode.

For normal messages, the configured mapping mechanism described under Data Coding Alphabet Mapping is used.

For flash messages, the SMPP Application will determine which of the flash message modes (as described under Flash Messaging) the external entity has used to signal the message class. This includes the encoding alphabet character width that was used. The SMPP Application will then decode the received message text according to the configured flash decoding alphabet parameters:

For all flash decoding alphabet parameters, the possible values are as specified under Available Alphabets.

Inbound short messages are sent to handling applications using the SMPP-S-REQUEST message type. Refer to the specific message type documentation for full details of this message type, including how the message class and text are specified in input to the handling application.

Message Handling

In addition to the common Application management messages, the SMPPApp uses the following messages:

• SMPP-C Messages (SMPP-C-REQUEST outbound).
• SMPP-S Messages (SMPP-S-REQUEST inbound).