EMG 3.1.5 - User's Guide

Table of ContentsPreviousNextIndex

2. Overview

Enterprise Messaging Gateway (EMG) is a messaging platform that can act as a SMS/MMS gateway, protocol converter or some other kind of mediation gateway.

Usually the job of EMG is to relay messages, performing message conversion and translation depending on the connectors used to receive and send the message.

2.1 Licensing

Enterprise Messaging Gateway licensing is based on number of messages per second per server. More specifically it is the total number of messages that all incoming connectors, server-wide, will accept per second. If, for example, there are two incoming connectors in a system licensed for 30 messages per second and they are fed with 20 messages per second each, the EMG server will impose a small delay so that in practice the connectors will process on average 15 messages per second each.

EMG is also licensed per server so that one license permits installation of EMG on one specific server. The license is generated for a specific server identity (hostid). For Solaris systems this equals to the output from the command hostid and for Linux it is the MAC, or hardware, address for the first network adapter in the system, interface eth0.

There is no license-related limitation as to how many connectors can be defined or how many clients or SMSC connections an EMG server can handle. One server can handle multiple client and SMSC connections using different protocols.

In order to be able to move a license from one server to another a new license needs to be generated by Nordic Messaging Technologies AB or one of its representatives.

2.2 Messages

The message is the most important entity in EMG. A message is represented as a unique object, identified by its unique message id, that is assigned a number of properties of which some can be set by the user and some are set by the system. Each property is a key-value pair, where the numeric key identifies the property. Usually a message are assigned at least the following, user-level, properties:

ID, unique message id (key value 1)
DESTADDRESS, destination address or recipient (8)
MESSAGE, message data (16)

These properties are referred to as MGP options, where MGP stands for the Messaging Gateway Protocol. A list of key values can be found in the chapter "MGP options".

2.3 Binary messages and User-Data Header (UDH)

EMG supports binary, or 8-bit, messages including User-Data Header (UDH). This enables sending of ringtones, logos, WAP push, OTA and other messages containing other information than plain text. When converting from one protocol to another message and optionally splitting messages, UDH properties are preserved.

2.4 Long messages

According to the GSM specification one message (SMS) cannot exceed 160 septets or 140 octets in length. However, sometimes it is necessary to send more information than that in one message. This is solved by splitting the message into multiple messages and indicate that they belong together by using the GSM 3.40 UDH feature "concatenated message". EMG handles both splitting of messages and setting the corresponding UDH option automatically. In EMG one message is translated into one or more Physical Data Units (PDUs). Each PDU corresponds to one transferred SMS.

2.5 MMS

Starting with EMG 3, EMG also supports sending and receiving multimedia messages, MMS. Protocols such as MM7, EAIF and PAP are supported. Basic convserion functionality is also included, for example e-mail to MMS and MMS to e-mail conversion.

2.6 Connectors

Messages are sent and received through so called connectors in the server. Each connector is of type incoming and outgoing, exists in one or more instances and implement one of the supported protocols. Outgoing connectors support failover and load balancing via the routing table.

2.7 Routing

The process of passing a message from one connector to another in order for it to reach its final destination is referred to as routing. The routing decision is based on the information in the routing table and message and connector properties.

2.8 Message life cycle

A message that is relayed through EMG passes a number of stages:

Message is received via a connector and its attached parameters are parsed.
A routing decision is made dependant on message information, connector information and the routing table. An outgoing connector is selected.
Message is placed in the queue for the selected connector OR if an outgoing connector could not be selected the message is considered an orphan.
Message is delivered through the connector if possible. If the connector fails, failover options are checked and the message may be re-routed correspondingly to another connector.

When a message is deleted or queried, first the routing log is checked. If the message has been relayed (usually to an SMSC) the endpoint is queried if possible. Message status RELAYED indicates that the message has been relayed but the final result is unknown. However, status DELIVERED indicates that the message has been delivered to the recipient. When a message is sent to an SMSC the message status is RELAYED until further information is available while if for example a HTTP connector delivers the message the status will be DELIVERED.

Messages placed in connector queues, or orphaned, can be made to expire when the validity period, if present for the message, is reached.

When running without message persistence option messages are stored in RAM during their life cycle and will be lost if server is stopped ungracefully. With the message persistence option messages, DLRs and keyword sessions are persisted on file for their life time.

2.9 Routing log

When a message is processed by EMG it is entered into the routing log. The routing log is used to keep track of the most recent messages, their state and what connector they were received and sent out at. The maximum number of entries in the routing log is defined by the keyword ROUTELOGSIZE. When the log exceeds the maximum size the oldest entry will be discarded.

2.10 Orphans

When an incoming message cannot be routed or is routed to a connector that does not exist it will be added to a special queue for so called orphaned messages. The maximum size of this queue is defined by the keyword ORPHANSSIZE. When the queue exceeds the maximum size the oldest entry will be discarded. If the value for this keyword is set to 0 orphaned messages will be discarded directly.

When the server is refreshed the queue for orphaned messages will be processed and if, for example, the routing table has changed orphaned messages may be successfully re-routed to a destination connector.

2.11 Protocol conversion

The different protocols supported by EMG differs somewhat in functionality and possibilities. This is especially true when going from an older version of a protocol to a newer version. This implies that some kind of conversion must take place. Some parameters may need to be added, some converted and some maybe even removed.

2.11.1 CIMD2 (Nokia)

CIMD2 supports two different types of Message Centers, SMSC and USSD. Some options are specific for one of the message center types.

The SMSC distinguishes between three types of SME:s (Short Message Entities, in this case the EMG application):

1 Send-only, the SME can only send messages
2 Querying, the SME requests delivery of messages or polls for messages
3 Receiving, the SME is always ready to receive a message. The querying type setup seems to be quite common and in this case the POLLRECEIVE keyword needs to be specified so that the SMSC will deliver messages.

EMG supports CIMD2 2-0en.

2.11.2 SMPP (SMS Forum)

This protocol, in version 3.4, is designed to support a variety of different messaging centers in different network types and hence is the protocol that provides the largest amount of options. However, for SMS in a GSM network many of the options are not used. SMPP has evolved to be the number one messaging standard and is getting more and more widely used.

EMG can be configured to use both the submit_sm and the data_sm SMPP operations depending on protocol version (specified by INTERFACEVERSION) and the value of DEFAULT_SMSCOP. The submit_multi_sm operation is currently not supported.

SMPP 3.4 is a much more thorough specification than SMPP 3.3.

EMG supports SMPP 3.3 and SMPP 3.4.
It is implemented by the Logica SMSC and others.

2.11.3 UCP/EMI (CMG)

There a number of different operations for sending a message that remain from earlier versions of the protocol but which are now obsolete. The default operation and the operation that should be used is the Submit Short Message (51) operation.

EMG supports UCP/EMI 3.5 and UCP/EMI 4.0.

2.11.4 OIS (Sema)

OIS is supported over TPC/IP. No authentication is used for these connections but full support for text, binary and messages using UDH is available.

EMG supports OIS according to the version 5.8 specification.

2.12 Performance

EMG is licensed based on messages per second. Above 200 messages per second the license is unlimited. The achieved performance depend on a number of factors: Hardware, operating system, protocol used, clients, SMSC etc. However, connectors using the messaging protocols supported (CIMD2, SMPP and UCP) are capable to process more than 4.000 messages per second in an ideal environment.

In benchmarks where we short-circuit SMPP connectors (that is we use one server which provides both the outgoing and incoming connectors) and a message is looped, we achieve 200+ messages per second on a low-end Sun Sparcstation 5 with 256 MB RAM running Solaris 8. This indicates that EMG is capable of very high throughput on relatively basic hardware.

Moreover, EMG on Linux generally outperforms EMG on Solaris probably due to the fact that the TCP/IP implementation on Linux is very efficient. On the other hand we prefer Solaris as a stable and reliable platform for business-critical applications.

2.13 Support

Support is available from your reseller and requires a valid support agreement. If you are missing information about your reseller, please contact Nordic Messaging Technologies via e-mail: support@nordicmessaging.se.

Make sure you include a detailed problem description, your license or serial number and detailed contact information. If you want us to call you make sure you indicate your geographical location and time zone.

Nordic Messaging Technologies is located in Stockholm, Sweden (CET).

Table of ContentsPreviousNextIndex