HTTP Interface for SMS - An Introduction

This section is only applicable to lab applications and the test application with a required feature license.
The HTTP interface in the test set provides an industry standard interface for interfacing the base station simulation capability of the test set with necessary external components for verifying SMS capability in a mobile station. The HTTP implementation in the test set also provides SMS routing capability, simulating a simple Short Message Service Center (SMSC).

Introduction to HTTP
HTTP is the client/server based protocol used to deliver virtually all files and data on the World Wide Web. If you'd like a more detailed description of HTTP protocol, refer to Internet RFCs `HTTP/1.0 - RFC 1945' and `HTTP/1.1 - RFC 2616', which can be downloaded from http://www.rfc-editor.org/rfc.php.
When you use HTTP in a web browser, you enter the "address" for the web page you wish to view. These addresses can be generalized into the following format:

In this example, the web browser is the HTTP client and it uses the information in this address to open a connection to an HTTP server and send a request.

"http://" is the protocol specifier, telling the browser what protocol to use for the request.
is the IP address of the server.
is the port number on which to communicate with the server. The default port for HTTP is 80.
provides information to the server on the location of the resource that's being requested and can also be used to provide information to the resource.

HTTP Interface for SMS verification
The test set acts as both a server and a client, depending on which operation it is performing.

The test set as the server:
If you have a PC and your test set connected to a network or directly connected together, you can open a web browser (client) and send a request to the test set using the test set's IP address and a correctly configured request URL. For example, you might send the following from the web browser if your test set's IP address was 111.111.111.112.



NOTE
It is not necessary to specify a port number because the test set uses 80, which is the default port for HTTP.

Sending the URL causes an SMS message to arrive at the mobile station attached to the test set's RF port. This message contains the text "hello".
The test set acts as the server for mobile terminated SMS messages. While this is a simple example, this same information is necessary to configure an SMS Gateway or proprietary software for interfacing with the test set via HTTP.
For configuration information see:

HTTP Interface Configuration for Mobile Terminated SMS .

The test set as the client:
SMS messages originating from the mobile station attached to the test set are sent out the test set's LAN port as HTTP requests to the IP address for the intended receiving entity.
For configuration information see:

HTTP Interface Configuration for Mobile Originated SMS

Related Topics

HTTP Interface Configuration for Mobile Terminated SMS
HTTP Interface Configuration for Mobile Originated SMS
HTTP SMS Router Web-based Configuration Interface

Source: http://wireless.agilent.com/rfcomms/refdocs/gsmgprs/gprsla_gen_bse_sms_http_interface.php

SMSC interface with ESME

SMSC Issues
http://www.nowsms.com/discus/messages/1/247.html

Following discussion shows how SMSC can be integrated with ESME through HTTP as well as SMPP interface.

http://www.telecomspace.com/forum/index.php?topic=851.0

NMS Troubleshooting links

Some important links for NMS Configurations

http://www.dialogic.com/den/forums/p/5509/22253.aspx#22253

SMS versus WAP

SMS is the short messaging service for GSM. It is also present on most other digital cellular networks and tends to operate in a similar fashion on each network. SMS enables 2-way short messages to be sent between GSM subscribers. Using gateways, it is also possible to interchange messages with other systems such as Internet email, the web etc. So, SMS is essentially a messaging transport service to enable reliable 2-way messaging.

WAP on the other hand is a "protocol set" aboard which various services can be delivered. Like any protocol, it states how devices can be made compatible ("speak the same language") in order to exchange information. Since SMS is a means for information to be transported, two devices could use SMS to exchange WAP-compliant data.

As well as being a transport service, SMS also has a protocol. However, as mentioned earlier, the SMS protocol is really only concerned with reliable 2-way messaging and so it is restricted to basic functionality. In protocol terms, this means a very basic command set such as "Send Message" and "Receive Message". Clearly for anything more sophisticated, this protocol is very limited. However, there's nothing to stop another protocol being added on top with more commands that just get sent using the Send and Receive of SMS. This is what WAP does.

So why does WAP do this? Well, to use the mobile phone to converse with any information-delivery system (such as the web or a database), the method of delivery needs to be tailored to the limitations of the phone - mainly the small text-only display, and the restrictive keyboard and navigation keys. So a part of WAP is concerned with sensible data formatting and navigation appropriate to these limitations. However, sending data over mobile air interfaces poses problems with delays and slow links. These can be overcome to an extent by optimizing the way in which the protocol is mapped to the interface (such as the SMS carrier or an ordinary GSM data call). Another part of WAP is concerned with efficient protocol transport.

So is SMS still needed after WAP? The answer is yes. Firstly there are many applications that simply do not need WAP. The simple send and receive primitives of SMS are sufficient. Also, there is often no need, or no context, to maintain an ongoing (connected) communications session over SMS and so SMS tends to get used in a connectionless mode, like sending a letter or an email - whereby immediate, or even any, response is not required (though it may be desirable at times).

Many SMS messages are alerts of one kind or another, used to notify the recipient of an event. These types of messages usually require follow-on action other than sending a reply using SMS. In these circumstances, SMS is sufficient and there is no need to move to WAP.

Secondly, WAP is not widely available yet and there are millions of phones that can handle SMS but not WAP. These will stay in circulation for some time.

WAP is particularly useful for interactive services on the handset. Interactive services can be realized using native SMS, but this is not as elegant as WAP. Using WAP, the user can be prompted for information and guided along the interactivity path, whereas while using only SMS, the user has to remember how to respond with any preset commands.

So, do we need SMS or WAP or both? The answer is both are needed and they have different uses and applications. SMS is particularly good for pushing out information to mobile phone users. In particular, Xsonic InTouch monitors a variety of data sources within the Microsoft Exchange messaging server and pushes out alerts, such as "new email from...", "appointment at..." etc. Xsonic DataNow also generates alerts from any data changes that occur within an SQL Server database.

Alerts can be followed up by a variety of actions. These may include SMS replies of one form or another. Additionally, SMS can be used to pull data from a database. This feature gets used in Xsonic InTouch to pull contact details from a user's personal contacts folder in the Exchange database. In this way a mobile worker could get the fax number of a customer, their address, home phone number etc. For many of these types of applications, the quick alert or prompt/pull operations of SMS are ideal. Indeed, an advantage of SMS is that it is quick.

The advantage of WAP is that it enables greater interactivity with the data source. This would be useful, for example in any operation that is multi-paged in nature (such as navigating through a hierarchy). Traversing an email Inbox is one such application. With Xsonic InTouch, a WAP phone could be used to receive SMS alerts (e.g. calendar reminders, email notification etc.) and the user could then elect to respond with short SMS commands and get a quick reply, or they could elect to connect to the server via a secure remote access point and navigate through the various Exchange folders.

SMS and WAP are different entities and are often complimentary. A well designed application would exploit the essential characteristics of SMS and WAP to suit the end-user requirements. For fast alert or quick-shot pull systems, SMS is a good solution. For any communications requiring ongoing interaction with a hierarchical data source, WAP is a good solution. Sometimes, both solutions can be used to get the best of both worlds.

SMS Faqs

SMS FAQ

What is SMS?

Short Message Service (SMS) is the ability to send and receive short alphanumeric messages to and from mobile telephones. SMS can also be used as a transport for binary payloads and to implement the WAP stack on top of the SMSC bear. SMS was created as part of the GSM Phase 1 standard.

Why use SMS?

SMS allows users to directly transmit messages to each other without the use of an operator (it is, however, necessary to have the underlying operator controlled wireless service). The first user can send a message to a mobile unit, via a direct connect computer. The SMS protocol of messaging is also "smarter" then standard paging. SMS is a store and forward method therefore, if the end user is not available, the mobile unit is powered off, or the unit is outside a service area, when the unit comes back on line the message will appear. A SMS message can also be sent "certified," where it will notify the message originator of the end user's receipt of the message.

How would you send an SMS Message over the Internet?

The front-end would simply be a section for the message (limit) and a destination address (mobile number). Then, based on your architecture, a lower layer would have to create the correct message based on the request or the message is generate server side. In the case of an end-user sending a message to a mobile unit, it would be a SMS-DELIVER message. Then entire message would then be "encapsulated" in a TCP/IP message and send to the appropriate Short Message Service Centre (SMSC). The MSC would then remove the TCP/IP layer from the message and process the message as if it were generated locally by an operator.



What are some other uses for SMS?

Voice/Fax Notifications

Delivery of Replacement Ringtones, Operator Logos and Group Graphics
Mobile users will select features or options for their phone (ideally from a web site). They enter their mobile number and the feature is sent to their phone via SMS message in a matter of seconds. The user then has the option to select and save or to delete.

Unified Messaging
Using a single interface, unified messaging users are able to access all forms of messages (voice mail, email, fax) from a single point.

Direct communication
End users can send and receive SMS messages without the use of an operator.

Does SMS support all languages?

SMS is able to support any language, but that language is dependent more on how the handset is configured than anything else. Every region supports different languages and each software build for every phone is different. In the Americas, phones typically support English, Spanish, and Portuguese. In Europe it is vastly different.

What are the two types of SMS?

Point-to-Point and Point-to-Omnipoint (cell broadcast)

What is Point-to-Point?

Point-to-Point uses a dedicated link between the network and the mobile station allowing bidirectional messaging without operator interaction.

What is the maximum length of a Point-to-Point short message?

Two-way data transport = 140 Octet Data Payload Supports Either: 140 bytes for binary data transport (PDU format) 160 characters for text messaging transport (7-bit ASCII).

What are the two types of Point-to-Point messages?

Mobile originated (MO) and Mobile terminated (MT).

What is SM-MT (short message - mobile terminated)?
SM-MT denotes the capability of the GSM system to send a message from the SC to an MS where the message is either received, or, if the recipient device is unavailable, stored for later delivery. A delivery report or failure report is then sent back to the SC. These messages may be input to the Service center by other mobile users (via a mobile originated short message) or by a variety of other sources, e.g. speech, telex, or facsimile.

What is SM-MO (short message - mobile originated)?

SM-MO denotes the capability of the GSM system to send a message from an M to an SME via an SC and to provide information to the MS about the delivery or failure of that message. These messages may be destined for other mobile users, or for subscribers on a fixed network.

What are the specific types of Point-to-Point messages?

SMS-DELIVER: sending a short message from the SC to the MS.
SMS-DELIVER-REPORT: replying with an error cause.
SMS-SUBMIT: sending a short message from the MS to the SC.
SMS-SUBMIT-REPORT: reply with an error cause.
SMS-STATUS-REPORT: sending a status report from the SC to the MS.
SMS-COMMAND: sending a command from the MS to the SC.

What is Point-to-Omnipoint?

Point-to-Omnipoint, or Cell Broadcast, sends messages to predetermined cell broadcast areas. Unlike Point-to-Point messaging, Cell Broadcast does not use a dedicated link. The network operator is where all messages originate and the recipients include all users within a given cell, area, or network. Also unlike Point-to-Point, CB messages do not provide any assurance that the message was recieved.

What is the maximum length of a Point-to-Omnipoint short message?

A Point-to-Omnipoint short message is a maximum of 93 charaters (82 octets) in length.

Where is it determined which MSs will receive which CB messages?

At the origination and termination points. At the origination point, the sender (or network operator) broadcasts messages on certain "channels". The sender indicates the frequency and duration of transmission. At the termination point, the user selects which "channels" will be displayed on his mobile station. If the MS is switched on and idle, it is able to identify and ignore re-broadcasts of messages that have already been received.

How do mobiles know to display only those messages desired by the MS user?

CB messages are assigned message classes that categorize the type of information contained in the message.

What are the error conditions that can return to an SC from an MS?

Unknown subscriber: message is rejected because there is no directory number for the mobile subscriber (GSM 09.02).
Teleservice not provisioned: message is rejected because the recipient MS has no SMS subscription (GSM 09.02).
Call barred: message is rejected due to barring of the MS (see GSM 09.02, description of the Barring supplementary service, GSM 02.04 and 03.11, and description of Operator Determined Barring, GSM 02.41 and 03.15).
Facility not supported: the message is rejected due to no provision of the SMS in the VPLMN (GSM 09.02).
Absent subscriber: The message is rejected because there was no paging response (GSM 04.08), the IMSI record is marked detached (GSM 09.02), or the MS is subject to roaming restrictions (GSM 09.02).
MS busy for MT SMS: The message is rejected because of congestion encountered at the visited MSC.
SMS lower layers capabilities not provisioned: message rejected due to MS not being able to support the SMS. The short message transfer attempt is rejected either due to information contained in the class-mark, or the MSC not being able to establish connection at SAPI (GSM 04.08 and 09.02).
Error in MS: message rejected due to an error occurring within the MS at reception of a short message (lack of memory or protocol error).
Illegal subscriber: message rejected because of failed authentication.
Illegal equipment: message rejected because the MS was black-listed.
System failure: message rejected due to network or protocol failure.
Memory capacity exceeded: message rejected because the MS doesn't have enough memory.
How can SMS be used to program phones?

Nokia has created a new protocol called Smart Messages which sends configuration messages to mobile phone units with header definitions stating that the message is a configuration message. These Smart Messages make use of the SMS protocol.

What are the classes of SM-MT (mobile terminated) messages?

Classes identify the message's importance as well as the location where it should be stored. There are 4 message classes.
Class 0: Indicates that this message is to be displayed on the MS immediately and a message delivery report is to be sent back to the SC. The message does not have to be saved in the MS or on the SIM card (unless selected to do so by the mobile user).
Class 1: Indicates that this message is to be stored in the MS memory or the SIM card (depending on memory availability).
Class 2: This message class is Phase 2 specific and carries SIM card data. The SIM card data must be successfully transferred prior to sending acknowledgement to the SC. An error message will be sent to the SC if this transmission is not possible.
Class 3: Indicates that this message will be forwarded from the receiving entity to an external device. The delivery acknowledgement will be sent to the SC regardless of whether or not the message was forwarded to the external device.

SMS -- an introduction

The Short Message Service (SMS) allows text messages to be sent and received to and from mobile telephones. The text can comprise words or numbers or an alphanumeric combination. SMS was created as part of the GSM Phase 1 standard. The first short message is believed to have been sent in December 1992 from a PC to a mobile phone on the Vodafone GSM network in the UK. Each short message is up to 160 characters in length when Latin alphabets are used, and 70 characters in length when non-Latin alphabets such as Arabic and Chinese are used.

There is no doubting the success of SMS. The market in Europe alone had reached over three billion short messages per month as of December 1999, despite little in proactive marketing by network operators and phone manufacturers. Key market drivers over the next two years, such as the Wireless Application Protocol (WAP), will continue this growth path.

Typical uses of SMS include notifying a mobile phone owner of a voicemail message, alerting a salesperson of an inquiry and telling a driver the address of the next pickup.

SMS TECHNOLOGY

SMS is essentially similar to paging, but SMS messages do not require the mobile phone to be active and within range, as they will be held for a number of days until the phone is active and within range. SMS messages are transmitted within the same cell or to anyone with roaming capability. They can also be sent to digital phones from a web site equipped with a PC Link or from one digital phone to another. An SMS gateway is a web site that lets you enter an SMS message to someone within the cell served by that gateway or acts as an international gateway for users with roaming capability.

The SMS is a store and forward service. In other words, short messages are not sent directly from sender to recipient, but via an SMS Center. Each mobile telephone network that supports SMS has one or more messaging centers to handle and manage the short messages.

The SMS features confirmation of message delivery. This means that, unlike paging, users do not simply send a short message and trust and hope that it gets delivered. Instead the sender of the short message can receive a return message back notifying them whether the short message has been delivered or not.

Short messages can be sent and received simultaneously with GSM (Global System for Mobile Communications) voice, data and fax calls. This is possible because whereas voice, data and fax calls take over a dedicated radio channel for the duration of the call, short messages travel over and above the radio channel using the signaling path. As such, users of SMS rarely, if ever, get a busy or engaged signal as they can do during peak network usage times.

Ways of sending multiple short messages are available. SMS concatenation (stringing several short messages together) and SMS compression (getting more than 160 characters of information within a single short message) have been defined and incorporated in the GSM SMS standards.

The network operator needs to purchase its first generation SMS Center as part of the network commissioning plan. The initial SMS Center may simply be a voice mail platform module or a stand-alone SMS Center. It is not possible to make the SMS available without an SMS Center since all short messages pass through the SMS Center.

RECENT SMS DEVELOPMENTS

Because simple person-to-person messaging is such an important component of total SMS traffic volumes, anything that simplifies message generation is an important enabler of SMS. Predictive text input algorithms significantly reduce the number of key strokes that need to be made to input a message. T9, from Tegic, anticipates which word the user is trying to generate. Widespread incorporation of such algorithms into the installed base of mobile phones will typically lead to an average uplift in SMS traffic of 25% per enabled user. These predictive text algorithms support multiple languages.

The introduction of standardised protocols such as SIM Application Toolkit and the Wireless Application Protocol (WAP) contribute to an increase in messaging usage by providing a standard service development and deployment environment for application developers and business partners. These protocols also make it easier for users to reply to and otherwise access messaging services through custom menus on the phone. While these protocols are only a means to an end and not new messaging destinations or services, they are likely to lead to a 10-15% uplift in total SMS volumes.

The introduction of more user-friendly terminals contributes to increases in messaging usage. Terminals such as smart phones make it easier for users to originate, reply to and otherwise access messaging services through the provision of a QWERTY keyboard, rather than the limited keypad on standard mobile phones.

References:

http://mobilecommunicationsfacts.blogspot.com/

http://wireless.agilent.com/rfcomms/refdocs/wcdma/wcdma_gen_bse_sms_mt.php

SMPP -- an insight

Introduction

SMPP stands for Short Message Peer to Peer Protocol SMPP is used to send and receive messages from and to GSM, UMTS, iDEN,CDMA and TDMA cell phones.
The protocol is a level-7 TCP/IP protocol, which allows fast deliver of SMS messages.
Using the SMPP protocol instead of sending messages using a GSM modem has the following advantages:

• The SMPP protocol is TCP/IP based, GSM hardware is not required;
• Users can send SMS to a simple shortcode, this is not possible when sending to a GSM phone;
• High throughput ( up to 200 msgs/second);
• Alphanumeric sender address can be assigned.

Applications

SMPP can be used for the following applications:

• Sending Voicemail alerts to mobile users;
• Sending SMS notifications to mobile users, for instance when a server is down, or to notify students that a lesson is cancelled;
• Information services : sending stock exchanges, traffic jam alerts or weather forecasts;
• Voting, process votes from mobile users (Requesting music on the radio;
• MMS notifications, when users pay for ringtones and Java applications, the download location is send by a MMS notification or WAP Push message;
• Telemetry applications.

Connections

SMPP is used by clients to connected to a SMSC (Short Message Service Centre). In SMPP terms, the client is called ESME (Extended Short Message Entity). SMSC's can also exchange data using a SMPP connection.

Messages Send to a SMSC are called MT (Mobile Terminated) messages, because they are sent to a mobile phone. Messages received from a SMSC are called MO (Mobile Originated) messages, because they were sent from a mobile phone.

When an ESME establishes a connection using SMPP, this can be done in three modes: Transmitter, the ESME can only submit messages to the SMSC; Receiver, the ESME can only receive messages or delivery reports from the SMSC; Transceiver, the EMSE can bot send and receive messages to and from the SMSC.

SMPP PDU's

The TCP packets between the ESME and the SMSC are called PDU's (Protocol Data Units). The following types of PDU's are used in SMPP connections:

Session Management PDU’s Connecting, disconnection and connection keep alive. Message Submission PDU’s Submitting messages to a mobile phone. Message Delivery PDU’s Delivery of messages to the SMPP client. Ancillary Operations PDU’s Message query, cancel and replacement. The following SMPP PDU's are used the most: bind_transmitter / bind_receiver / bind_transceiver Used to connect the client with the SMSC, in SMPP sessions a ‘system ID’ and password are used for authentication. submit_sm Used to submit a single message from the client to the SMSC ( MT ). This packet contains the sender and recipient address, message body and some optional parameters. deliver_sm When a messages has to be delivered to the client this packet is used ( MO ). It contains information about the sender of the message and the message body. This PDU is also used to send delivery reports to the ESME. query_sm To query the state of a previously sent message, this command is used. You need a message reference to query a message. Most provider require you to use delivery reports instead of querying the messages all the time. enquire_link This packet is sent once in every x minutes to check if the connection is still alive. If not, the connection is terminated. This packet is also used to keep dial-up connections alive ( for instance ISDN ). The most used timeout for SMPP connections is one minute. unbind Used to end the session and disconnect the TCP/IP connection. Connection examples Sending Messages Receiving Messages SMPP optional parameters To extend the SMPP protocol with extra parameters, TLV parameters, also called optional parameters were introduced in the SMPP protocol since version 3.4: TLV’s are used to make the existing PDU’s more efficient; TLV’s are used to enhance existing PDU’s with new features; TLV Stands for Tag-Length-Value field; TLV’s are supported in SMPP version 3.4 and higher. Some commonly used TLV's are: message_payload TLV Used to encode large messages. The submit_sm PDU can be used to messages up to 255 chars only. This PDU improves performance, for instance: when you need to send a message containing 315 characters you only have to send one packet instead of two. This doubles the throughput. sar_msg_ref_num, sar_segment_seqnum, sar_total_segments TLV’s Segmentation And Reassembly. These TLV’s are used to send a long message in multiple parts. sar_msg_ref_num - Reference of the concatenated message. sar_segment_seqnum - ID of the current segment. sar_total_segments - Total number of segments. Please note that not all SMPP providers implement all TLV parameters.

Following link has information on SMPP: http://code.google.com/p/jsmpp/