Short Message Services

• Forwarding messages to the correct SME.
• Storing and forwarding messages for unavailable SMEs based on mobile station (MS).

• Applying originating and terminating supplementary services such as delayed delivery, repeated delivery, or distribution list delivery.

• Providing optional interworking with other network elements such as a web server or Instant Messaging (IM) gateway.

The message carrying services provided by SMS support several basic application categories such as:

• Person-to-person. The most common service when people talk about SMS — the wireless equivalent of Instant Messaging.
• Agent-to-person. Automated agents originate notifications when subscriber-configured events occur. For example, an agent watches a certain stock, then sends out an SMS message when that stock hits a certain price.

• Information broadcast services. These include news and weather information broadcast services.

• Advertising. This service sends out messages containing advertising information.

• Voicemail/e-mail notification. Notification of the arrival of a voicemail or e-mail message.

• Mobile terminal software updates. Some devices support updating or configurating the embedded software in the MS-SME. In this service, your cell-phone software can be updated or configured on the fly by the service provider.

Common Transport Environments

SMS is a service that is offered across multiple networks and topologies, the most common being ANSI/TIA/EIA-41, GSM, and 3GPP and 3GPP2.

ANSI/TIA/EIA-41 Networks

Until recently, ANSI/TIA/EIA-41 was referred to as "Interim Standard #41" (IS41) and was the work product of the TR45.2 Committee of the Telecommunications Industry Association (TIA). Its original purpose was to define procedures for intersystem handoff and automatic roaming, but it has grown to include things such as SMS. ANSI/TIA/EIA-41 has been the standard protocol for intersystem communications in North America for some time.

In ANSI/TIA/EIA-41, the basic network elements are those in Figure 2. The base station (BS) is the element in control of the radio interface to the MS. It is connected to the mobile switching center (MSC), which performs voice switching and protocol interworking. The home location register (HLR) is where a given MS's subscriber record and configuration are stored. It is typically the entity that defines the concept of "home" for the MS. The visitor location register (VLR) is the temporary data store in each MSC where information about roaming (visiting) subscribers is stored. The VLR contacts the subscriber's HLR when they roam into its area, then downloads relevant information needed to offer service to the MS.

In protocol diagrams and message-flow discussions, MSCs are often designated using letters to identify current roles in the given scenario. For instance:

• O. Originating system, originator of a transaction.
• T. Terminating system, destination or target of the transaction.

• S. Serving system, system currently serving the MS. This is used to demonstrate logic used in MS-roaming scenarios. The special case occurs when the Home system is also the Serving system.

• H. Home system, where SME's MC is located and MS's HLR record is stored. The concept being that any given MS is at home when being served by a given MSC, and is not considered to be roaming while at home. It is becoming more common for service providers to decouple the HLR from the MSC, giving rise to a network element called an "External HLR" (E-HLR).

ANSI/TIA/EIA-41 was initially devised to offer intersystem handoff, automatic roaming, and service qualification. It allowed regional cellular carriers to interconnect systems, and allowed automatic roaming of their subscribers onto each other's networks.

A mobile terminal makes itself known to the network by sending an over-the-air protocol message that causes a RegistrationNotification (REGNOT) or QualificationRequest (QUALREQ) to be issued from the serving system to the HLR. Assuming the appropriate positive response is received, the MS is now online.

To originate a regular voice call (see Figure 3), the mobile terminal sends the call origination information (dialed digits and so on) to the S-MSC using the over-the-air protocol of choice. The S-MSC issues a LocationRequest (LOCREQ) to the HLR to find the location of the called party. The HLR sends a RoutingRequest (ROUTREQ) to the called party's S-MSC (S-MSC-T). The S-MSC-T allocates a temporary local directory number (TLDN — a phone number temporarily associated with the called party. Any call destined for the assigned TLDN number that arrives at this S-MSC-T within the timeout period rings the called party's phone. The S-MSC-T returns the TLDN information to the HLR, which in turn returns it to the S-MSC-O. The S-MSC-O can then originate a call to the TLDN that was returned.

SMS transactions use a model similar to this. Figure 4 shows an SMS message delivery between two mobile SMEs (as with a person-to-person chat). In this scenario, an MS-based SME issues an SMD-REQ (an implementation-dependent air interface message indicating a short message delivery request). The S-MSC-O issues an SMSDeliveryPointToPoint (SMDPP) to the MC (see Table 1). Sometime later, the MC issues an SMSRequest (SMSREQ) to the HLR. If the HLR doesn't have a current temporary SMS routing address and status for the destination, then the HLR forwards the SMSREQ on to the VLR. This causes a lookup similar to the TLDN lookup just described. Basically, the authoritative VLR is queried and asks the serving system to allocate a valid temporary SMS address. The MC then sends the SMDPP to the S-MSC-T using the temporary SMS address. The SMS message is then delivered to the MS via the over-the-air protocol.

The ANSI/TIA/EIA-41 specification identifies six SMS address parameters that are valid in the SMDPP message:

• SMS_OriginalOriginatingAddress.
• SMS_OriginalOriginatingSubaddress.

• SMS_OriginatingAddress.

• SMS_OriginalDestinationAddress.

• SMS_OriginalDestinationSubaddress.

• SMS_DestinationAddress.

It also defines four classes of address valid in each of these parameters: ITU-T E.164, ITU-T X.121, private numbering plans, and Internet Protocol (TCP/IP) formats.

Programmatic access for SMEs that are not MS based is not standardized and depends on the service provider. Systems bridging from the Web to the wireless network (gateways) frequently utilize ANSI/TIA/EIA-41 directly to enable SMS functionality. GSM, on the other hand, defines several access protocols for use by fixed SMEs.

GSM Networks

In 1982, the Conference of European Posts and Telecommunications (CEPT) formed the Groupe Speciale Mobile (GSM) to define a standard European mobile cellular radio system. (The GSM acronym was later changed to mean "Global System for Mobile" communications.) In 1989, CEPT passed the ownership of the standard over to the European Telecommunications Standards Institute (ETSI). GSM Phase I was published in 1990. The technology's main differentiation is that it is built on a digital wireless infrastructure. Figure 5 illustrates the GSM network. It is now the international standard for personal wireless communication, and wireless access carriers in North America are starting to adopt it.

There are essentially four major components of the GSM network:

• The mobile station (MS) — that is, the wireless phone. It contains the radio interface as well as the subscriber identity module (SIM) — a smartcard device that identifies the subscriber. It contains the international mobile subscriber identity (IMSI) and associates it with the wireless device's international mobile equipment identity (IMEI).
• The base station subsystem (BSS), which contains the radio equipment used to implement the over-the-air communication to the MS.

• The network and switching subsystem (NSS), which contains the MSC, HLR, VLR, EIR, AuC, and SMSC among others.

• The operation and support subsystem, which contains all of the systems required to enable surveillance, serviceability, provisioning, and other support systems.

GSM SMS Protocol

The GSM mobile application part (MAP), defined in GSM 09.02, is used by the elements within the NSS portion of the GSM network (see Figure 5) to communicate with one another. MAP contains functionality for moving short messages around the GSM network in much the same way as ANSI/TIA/EIA-41. However, GSM is further along in the definition of interfaces to the SMSC. Therefore, it is relevant to talk about interfaces other than the GSM MAP when discussing GSM.

According to GSM 03.39, there are several APIs for communicating between the External Short Message Entities (ESME) and the SMSC for SMS messaging, including:

• Short Message Peer-to-Peer Protocol (SMPP) (http://www.smpp.org/).
• Computer Interface to Message Distribution (CIMD) (http://www.forum.nokia.com/download/cimdspec2.pdf).

• External Machine Interface/Universal Computer Protocol (EMI/UCP), an extension of the ETSI European Radio Messaging System (ERMES) (http://www.cmgtelecom.com/).

• Open Interface Specification (OIS) (http://www.semagroup.com/m&t/telecoms.htm).

• Ericsson Computer Access Service and Protocol (http://www.ericsson.com/).

GSM 03.39 goes on to say that:

GSM 03.40 states that the functionality of the Short Message Service Center (SMSC) is outside the scope of the GSM Technical Specifications. As a result, no standardized interfaces have been specified for the connection of SMEs to the SMSC. In the absence of a prevailing standard, SC (Service Centre), developers have devised their own protocols which have not necessarily been based on any existing standards and are therefore largely incompatible with one another. It has been recognized by TC-SMG, that the development of a single European Telecommunication Standard (ETS) at this stage, would be of little value as these proprietary standards are now in extensive use in many networks.

TC-SMG has concluded that the publication by ETSI of the various de facto protocols, will limit the further proliferation of proprietary standards and will benefit new SC/SME developers who may then adopt one or more of the existing protocols outlined in the present document.

GSM has gone through several revisions since the release of Phase I in 1990 (see the accompanying text box entitled "GSM and 3GPP Specification Numbering Schemes"). These ongoing revisions are necessary to meet the demands of new requirements. It has passed through the 2G and 2G+ sets of requirements (where "G" stands for "generation") and it is well into the definition of standards to meet the 3G set of requirements.

3GPP and 3GPP2

The Third Generation Partnership Project (3GPP) (http://www.3gpp.org/) and Third Generation Partnership Project 2 (3GPP2) (http://www.3gpp2.org/) are standards efforts that substantially change the way that wireless networks operate. Their goal is to facilitate rapid specification and development of wireless network technology standards to evolve GSM and ANSI/TIA/EIA-41, respectively.

The big news from the 3G efforts for messaging-type services is the evolution of standardized high-data-rate wireless packet services that will come out of these efforts, such as General Packet Radio Service (GPRS) and Enhanced Data for GSM Evolution (EDGE), which allow a packet connection directly to the endpoint. This enables technologies such as Wireless Application Protocol (WAP) to provide the endpoints with richer content that requires higher bandwidth. This will have a significant impact on the use of SMS technology.

Common Programmatic Access Mechanisms for SMS

Programmers wishing to make use of SMS to offer a service have a few options. The most common option is to use an existing e-mail or web-based gateway to bridge the Internet to the wireless network. This limits your flexibility but is generally the simplest method to implement. Specifications for these interfaces vary widely.

The second option is to use available APIs such as those already mentioned in our discussion of GSM. And there are others, such as simplewire (http://www.simplewire.com/). The third option is to use the ANSI/TIA/EIA-41 or GSM MAP directly. This is often used when constructing web-based or API-enabling gateways, WAP gateways, or specialized applications.

SMPP Example

To illustrate how you can write applications that make use of SMS, I'll use the Short Message Peer-to-Peer (SMPP) Protocol as an example because it is widely used and supports various network topologies.

Assume you want to build a small application to send SMS messages to users when they receive new e-mail messages. You would use the messaging model in Figure 6, adapted from the SMPP specification.

To initiate messages using SMPP, you need to make yourself known to the SMSC. This is called a "BIND" operation, and involves authentication and protocol-version negotiation. Since you want to be an originator of SMS messages and receiver of just the responses to those messages, you need to send a BIND_TRANSMITTER (see Listing One). The positive response to this is a BIND_TRANSMITTER_RESP, which contains the SMSC identifier, and optionally, the protocol version supported by the SMSC (if different from the one requested). For a two-way connection where both SMEs can send and receive SMS messages, use BIND_TRANSCEIVER instead.

Now that you are registered, you can send messages at will. Listing Two is logic for sending a short message. As you can see, I chose to use the transaction-messaging mode, which provides for end-to-end message disposition reporting on a transactional basis.

Listing Two illustrates the sending of the DATA_SM PDU in the DoNotify method. In that method, I create a DataSM object and fill in the parameters appropriately. Some key ones are esm_class, registered_delivery, and of course, message_payload.

The esm_class parameter contains a bit-field that indicates any special handling requests I may have. Specifically, it lets you select from among the SMPP's three messaging modes (store/forward, datagram, or transaction). The registered_delivery parameter lets you specify whether you want a return receipt or not. And finally, the message_payload parameter contains the actual message.

In this model, it is possible to query the status of a previously submitted short message using the QUERY_SM. Because this is just a "You have new mail" message, you don't need to track the status as long as it is eventually delivered. QUERY_SM would make more sense in a Store and Forward transaction model, letting you check the delivery status of a message.

When you're all done sending messages and ready to clean up gracefully, send the UNBIND PDU (Listing Three).

Where Does WAP Fit?

SMS is a transport or bearer service. Its function is to communicate data between two addressable devices. Interpretation of the contents, either by teleservice identifier or other means, is up to the specific application. For example, the Enhanced Messaging Service (EMS) and Multimedia Messaging Service (MMS) allow the communication of sounds and animations between endpoints for interpretation as such by the applications at those endpoints.

In the same way as EMS and MMS, the Wireless Application Protocol (WAP) is a set of rules that define the interpretation of the data delivered by the bearer service (SMS, GPRS, EDGE, and so on) at the application level. It is up to the Mobile Terminal to determine the meaning of the contents of the bearer data package.

In fact, one of the challenges for WAP until Version 1.2 was how to push information out to the devices. In preWAP 1.2, the device needed to request the WAP document as there was no push operation. But using SMS, a preWAP1.2 document could be pushed out to the device, assuming the device had support for the interpretation of the content as a WAP document.

What's Next?

Because SMS is a service that offers the delivery of messages between addressable endpoints, it would nicely integrate with other technologies that do the same. One such technology is Jabber (http://www.jabber.org/ or http://www.jabber.com/). On the surface, Jabber is an instant messaging system enabling users to chat. But if you dig deeper, it turns out that Jabber is really an infrastructure for delivery of messages across multiple transports. Several efforts are underway to add SMS transport support to Jabber. This will help to bridge the gap between the HTTP/XML world and the wireless one, allowing seamless transmission of XML data between endpoints regardless of whether they are IP based or wireless based. Among other things, this will enable the ubiquitous chat application between me on my cell phone and my wife at home on her computer.

It will also enable SIP presence management on wireless devices (http://www.ietf.org/; see RFC 2543). Presence management is a concept wherein various methods that may be used to contact individuals are advertised and stored in an accessible repository. This lets others quickly locate an individual for the purposes of conducting transactions or initiating sessions. The enabling of this service over wireless networks is especially likely in light of some of the 3GPP all-IP-network efforts. It may soon be possible to have an enhanced service configured on your mobile phone that integrates into your other SIP-based presence services.

Finally, SMS could be used in other interesting ways. It could be used to enable alarming and monitoring of remote computers, for example. It could be used to relay SNMP/CMIP information and perhaps even be used to receive corrective instructions back from an operator.

Conclusion

The delivery of packet data to a wireless endpoint over a wide area is a powerful capability. SMS is a good place to start as it offers a capable transport for some initial, nonbandwidth-intensive services. While 3G services like GPRS that are coming out of the 3G efforts may eventually overshadow SMS as the transport of choice for delivery of packet data to wireless endpoints, for now SMS offers the best choice for developers of wireless applications, both in terms of supported terminals and deployed capability.

DDJ

Listing One

Err Connection::ConnectToSMPPServer ( Server *server, Config *config )
{
    Err rc = SUCCESS;
    /* BindTransmitter inherits from PDU Base class which contains 
                                                         header members */
    BindTransmitter *bind_transmitter = new BindTransmitter();

    /* Open the transmitter connection */
    TCPIP_Connection TCPIPConnection = new TCPIP_Connection;
    rc = TCPIPConnection->Connect ( server->hostname, server->port );
    if ( rc != SUCCESS )
    {
        ( void ) ProcessRC ( rc );
        delete TCPIPConnection;
        delete bind_transmitter;
        return ( rc );
    }
    setState ( CONNECTED );

    /* fill in BIND_TRANSMITTER PDU and send */
    ( void ) bind_transmitter->setSystemId ( config->getSystemId() );
    ( void ) bind_transmitter->setPassword ( config->getPassword() );
    ( void ) bind_transmitter->setSystemType ( config->getSystemType() );
    ( void ) bind_transmitter->setAddressRange ( config->getAddressRange() );
    ( void ) bind_transmitter->setAddressType ( ( unsigned char ) NULL );
    ( void ) bind_transmitter->setAddressNPI ( ( unsigned char ) NULL );
    ( void ) bind_transmitter->setInterfaceVersion ( ( unsigned char ) 0x34 );
    
    /* fill in the header */
    /* reset sequence number */
    setSequenceNumber ( 1 );
    ( void ) bind_transmitter->setSequenceNumber ( nextSequenceNumber() );

    /* Pack the PDU into buffer */
    ( void ) bind_transmitter->Pack ( );
    if ( ( rc = TCPIPConnection->Send ( bind_transmitter->Payload(), 
                           bind_transmitter->PayloadSize() ) ) != SUCCESS )
    {
        ( void ) ProcessRC ( rc );
        ( void ) TCPIPConnection->Disconnect();
        setState ( IDLE );
        delete TCPIPConnection;
        delete bind_transmitter;
        return ( rc );
    }
    /* put on outstanding transactions list - waiting for response */
    SMPPList.add ( bind_transmitter, config->getResponseTimer(), 
                                                   ConnectToSMPPCallback );
    return ( ( Err ) SUCCESS );
}

Back to Article

Listing Two

Err Connection::DoMailCheck ( UserProfile *user, Config *config )
{
    Err rc;
    unsigned int num_msg;

    /* check if user has mail */
    if ( ( rc = CheckForNewMail ( user, &num_msg ) ) != SUCCESS )
    {
        /* some error occurred */
        ( void ) ProcessRC ( rc );
        return ( rc );
    }
    /* how many messages are there ? */
    if ( num_msg > 0 )
    {
        rc = DoNotify ( user, config, num_msg );
        return ( rc );
    }
    /* none? ok - return */
    else /* num_msg == 0 */
    {
        rc = ( Err ) NO_MAIL;
        return ( rc );
    }
    /*NOTREACHED*/
    return ( ( Err ) SUCCESS );
}
Err Connection::DoNotify ( UserProfile *user, Config *config, 
                                                   unsigned int number )
{
    
    /* DataSM inherits from PDU which contains the header member accessors */
    DataSM *msg = new DataSM();

    /* fill in DATA_SM PDU and send */
    /* set teleservice identifier */
    ( void ) msg->setServiceType ( config->getServiceType() );
    
    /* set source address properties */
    ( void ) msg->setSourceAddressType ( config->getAddressType() );
    ( void ) msg->setSourceAddressNPI ( config->getAddressNPI() );
    ( void ) msg->setSourceAddress ( config->getSourceAddress() );
    
    /* set destination address properties */
    ( void ) msg->setDestAddressType ( user->getAddressType() );
    ( void ) msg->setDestAddressNPI ( user->getAddressNPI() );
    ( void ) msg->setDestAddress ( user->getAddress() );

    /* turn on any special attributes                                      */
    /* ( we set transaction mode here by using the ESM_FORWARD_MODE flag ) */
    /* following causes 00000010 to be encoded, as follows:                */
    /* 00xxxxxx  No GSM Specific Features                                  */
    /* xx0000xx  Default message type                                      */
    /* xxxxxx10  Forward (transaction) mode                                */
    ( void ) msg->setESMClass ( ESM_GSM_FEAT_NONE | 
                                  ESM_DEFAULT_MSG_TYPE | ESM_FORWARD_MODE );
    /* no delivery receipt (the default) option - 0x00 */
    ( void ) msg->setRegisteredDelivery ( 0x00 );

    /* data encoding is ASCII */
    ( void ) msg->setDataCoding ( CODING_IA5 );

    /* optional parameters */

    /* how long for SMSC to hold onto msg */
    if ( user->msg_time_to_live != 0 )
    {
        ( void ) msg->setTimeToLive ( user->msg_time_to_live );
    }
    /* indicate how many new emails are waiting */
    /* 99 is the max value for this parameter */
    if ( number > 99 ) number = 99;
    ( void ) msg->setNumberOfMsgs ( number );

    /* alert MS on message delivery - turn on */
    ( void ) msg->setAlertOnDelivery ( TRUE );

    /* the message... */
    ( void ) msg->setPayload ( "You have new mail" );
    
    /* fill in the header */
    ( void ) msg->setSequenceNumber ( nextSequenceNumber() );

    /* Pack the PDU into buffer */
    ( void ) msg->Pack ( );

    /* send message */
    if ( getState () == BOUND )
    {
        if ( ( rc = TCPIPConnection->Send ( msg->Payload(), 
                                      msg->PayloadSize() ) ) != SUCCESS )
        {
            ( void ) ProcessRC ( rc );
            delete msg;
            return ( rc );
        }
    }
    else
    {
        delete msg;
        return ( ( Err ) NOT_BOUND );
    }
    /* put on outstanding transactions List - waiting for response */
    SMPPList.add ( msg, config->getResponseTimer(), DataSMCallback );
    return ( ( Err ) SUCCESS );
}

Back to Article

Listing Three

Err Connection::DisconnectFromSMPPServer ( Config *config )
{
    Err rc; 
    /* UnBind inherits from PDU which contains the header member accessors */
    UnBind *unbind = new UnBind();

    /* fill in UNBIND PDU and send */
    /* fill in the header */

    unbind->setSequenceNumber ( nextSequenceNumber() );
    unbind->setCommandLength ( 16 );    

    /* send the message */
    if ( getState() == BOUND )
    {
        if ( ( rc = TCPIPConnection->Send ( unbind->Payload(), 
                                  unbind->PayloadSize() ) ) != SUCCESS )
        {
            ( void ) ProcessRC ( rc );
            ( void ) TCPIPConnection->Disconnect();
            setState ( UNBOUND );
            setState ( IDLE );
            delete unbind;
            delete TCPIPConnection;
            return ( rc );
        }
    }
    /* put on outstanding transactions queue - waiting for response */
    SMPPList.add ( unbind, config->getResponseTimer(), 
                                              DisconnectFromSMPPCallback );
    return ( ( Err ) SUCCESS );
}
Err Connection::DisconnnectFromSMPPCallback ( UnBind *unbind, 
                              UnBindResp *resp, unsigned short timer_flag )
{
    /* set connection state to UNBOUND */
    setState ( UNBOUND );

    if ( timer_flag == TRUE )
    {
        /* response timer expired - timeout */
        ( void ) LogError ( INFO, UNBIND_TIMEOUT );
        /* continue tearing down connection anyway... */
    }
    /* disconnect socket */
    ( void ) TCPIPConnection->Disconnect ( );

    /* free up objects */
    delete unbind;
    delete resp;        
    delete TCPIPConnection;

    /* set connection state to IDLE */
    setState ( IDLE );
    return ( ( Err ) SUCCESS );
}

Back to Article

DDJ