External Short Messaging Entity (ESME) is an external application that connects to a Short Message Service Center (SMSC) to engage in the sending or receiving of SMS messages. The term was coined by Aldiscon.
SME is a term used in many cellular circles to describe a network entity (mobile/cell phone) that can send/receive messages. ESME (pronounced EZ-mee) is essentially one of these but without all the wireless aspects; i.e. it is connected via TCP/IP, X.25 or similar. On SMPP 3.4 protocol specifications ESME refers only to external sources and sinks of short messages as Voice Processing Systems, WAP Proxy Servers or Message Handling computers, and it specifically excludes SMEs which are located within the Mobile Network, i.e., a mobile station (MS).[1]
Typical examples of ESMEs are systems that send automated marketing messages to mobile users and voting systems that process SMS votes (Pop Idol, Big Brother).
SMSC uses protocols such as SMPP, UCP, OIS, CIMD, SMCI all of which denote the concept of an ESME connecting to an SMSC. [2]
Relation between SMSC and ESME
ESME always connects to SMSC using a TCP/IP, X.25, etc. and then binds for the service it needs from SMSC.
For SMPP it can bind for Receiving only service, Transmitting only service or both (Transceiver service). Before SMPP 3.4 it was required to have two different connections, one for Transmitting and the other one for Receiving. Starting with SMPP 3.4 a Transceiver connection is enough for both.
The relation between ESME and SMSC is somehow a master-slave relation because SMSC is providing services to ESME, and usually ESME just uses these services from SMSC. One of the functions of the SMSC is to store and forward the messages while the ESME does not have this function. When a message is sent by an ESME to SMSC towards its destination, this message may stay in a SMSC queue until its destination will become available. During this time the ESME has the options to cancel the message in queue, to replace it or to check its status. ESME can also send a message to multiple destinations which will be handled by SMSC.
ESME are usually termination points of an SMS network while SMSC are the core of it. SMSC can connect between them while ESME only connects to an SMSC. SMPP protocol is designed exactly in this manner for connecting a small end of the SMS network (which is an ESME) to the entire SMS network (which is done through the SMSC)
ESME is submitting MTs to SMSC, while SMSC is delivering MOs to ESME.
Routing in SMSC for ESME
An example of how the routing can be done at SMSC level, but not mandatory as this depends a lot on the implementation of SMSC and the way the connection inside the SMSC is between routing part of the SMSC and SMPP interface can be as below: During the service agreement between ESME and service provider (SMSC side) one unique short code will be allocated to ESME. At the SMSC end smpp server will have list of all ESME address and active connection. When any message gets sent to short code, messages first comes to SMSC, SMSC decodes it according to GSM 3.4 spec, then one of the modules in SMSC checks the destination address and if it is short code then that module routes messages to SMPP server part of the SMSC. Now SMPP server will have all active connection, according to destination address it selects the ESME - SMPP server connection object, that object will be responsible to encode message according to SMPP protocol and forward to ESME.
Communication between SMSC and ESME can be on either SMPP or HTTP. If one has a SMPP account, they could connect to the SMPP IP+Port on TCP/IP and the SMPP will push MOs to ESME on SMPP connection, and ESME will push MTs on the same connection in reverse. If they have a HTTP account with the operator's SMSC, then the SMSC will submit MO to a given URL and to push MTs SMSC will be given on URL.
References
- ↑ SMPP Developers Short Message Peer to Peer Protocol Specifications v3.4. SMPP Developers Forum, 1999, p. 10.
- ↑ SMS Marketing for eCommerce