|This article needs additional citations for verification. (February 2013)|
||This article uses abbreviations that may be confusing or ambiguous. (December 2010)|
External Short Messaging Entity (ESME) is a term originally coined by Aldiscon to describe an external application that connects to an Short Message Service Center (SMSC) to engage in the sending and/or receiving of SMS messages.
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).
Typical examples of ESMEs are systems that send automated marketing messages to mobile users, voting systems that process SMS votes (Pop Idol, Big Brother), etc. Basically, anytime a mobile user sends or receives a message where the other party was not another real mobile user, it is likely that the other sender/receiver is an ESME.
Relation between SMSC and ESME
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 Tranceiver 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 doesn't 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 you send any message to short code, messages first comes to SMSC, SMSC decodes it according to GSM 3.4 spec, then one of module in SMSC checks the destination address 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 you have SMPP account, you could connect to the SMPP IP+Port on TCPIP and the SMPP will push MOs to ESME on SMPP connection. and ESME will push MTs on the same connection in reverse. If you have HTTP account with the operators SMSC, then the SMSC will post the MO onto an URL given by you and to push MTs SMSC will give you on URL.
- SMPP Developers Short Message Peer to Peer Protocol Specifications v3.4. SMPP Developers Forum, 1999, p. 10.