[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]

IBM Everyplace Wireless Gateway:
Short-messaging support in the WebSphere Everyplace Suite

Table of Contents

Introduction
Messaging gateway overview
Messaging functions

Security
Accounting and billing
Supported networks
Messaging services and push toolkit
Scalability and performance
Glossary
Appendix A: Protocol specifications and levels
Appendix B: Referenced websites

Tim Rich and Roger Wilson
Pervasive Computing Division
April 2001

Introduction

The Everyplace™ Wireless Gateway, a component of the IBM WebSphere® Everyplace Suite, is a distributed, scalable, multipurpose UNIX® communications platform that supports optimized, secure data access by both Wireless Application Protocol (WAP) clients and non-WAP clients over a wide range of international wireless network technologies, as well as local area (LAN) and wide area (WAN) wire line networks. The IBM Everyplace Wireless Gateway (hereafter referred to as the Wireless Gateway) is available as part of the IBM WebSphere Everyplace Suite.

Beginning with Everyplace Wireless Gateway, Version 1.1.4, the Wireless Gateway may be used as a messaging gateway. The messaging gateway supports push technology to transmit information to client devices without previous end user action and also supports processing messages sent from a client device.

This document focuses on using the Wireless Gateway as a messaging gateway. The information in this document pertains to Everyplace Wireless Gateway, Version 1.1.4. Product availability and pricing models are not covered in this document; for more details, please contact your IBM representative or the IBM Pervasive Computing website.

After reading this document, you should have a better understanding of the functions provided by the messaging gateway, and of how the messaging gateway fits into a comprehensive wireless solution.

Important terms and acronyms used in this document include:

Message Transfer Agent (MTA)
The network agent to which the messaging gateway delivers push messages. Each supported network has a different MTA. Examples of MTAs include: SMS-Cs, SMTP servers, and SNPP servers.
Messaging Gateway
The messaging and push services provided by the Wireless Gateway.
Mobile Network Connection (MNC)
The interface between the Wireless Gateway and a specific MTA. There is a different MNC for every type of MTA. An MNC is sometimes referred to as a bearer or bearer network.
Wireless Gateway
The entire Everyplace Wireless Gateway product, which may be configured as a messaging gateway.

For more definitions, please see the Glossary.

Messaging gateway overview

The messaging gateway is the Wireless Gateway component that provides messaging support. By using the APIs provided with the Messaging Services and Push Toolkit (hereafter referred to as the Toolkit), you can create applications that use the messaging gateway to send short messages to and receive short messages from a variety of client devices.

Figure 1. Messaging gateway solution architecture.
Messaging gateway solution architecture.

One of the advantages of using the messaging gateway is the set of APIs provided as part of the Messaging Services and Push Toolkit. The messaging APIs provide a unified interface to many different types of networks and client devices. An application programmer can write an application to push a message to an e-mail client or to a GSM-SMS phone by simply specifying different address types. The APIs hide the complex details of how that message is encoded, the specific protocols for each network, maintaining connections to the network providers, and other device and network-specific activity. The application programmer can concentrate on creating and directing messages.

For example, an application might use the messaging gateway APIs to send stock quote alerts to a user's e-mail client during regular working hours and to the user's phone after hours. Other examples of typical short messages are airline flight status updates, news, traffic and weather reports, and e-mail arrival notifications.

The Wireless Gateway supports a variety of client devices including:

  • Wireless Application Protocol (WAP) client devices (for example, WAP-enabled mobile phones)
  • Global System for Mobile Communications Short Messaging System (GSM-SMS) mobile phones
  • Simple Mail Transfer Protocol (SMTP) e-mail clients
  • Simple Network Pager Protocol (SNPP) supported pagers and phones
  • Mobitex client devices

The messaging gateway is a configurable resource of the Wireless Gateway and is automatically installed when you install the Wireless Gateway. The messaging gateway takes advantage of the accounting, logging and tracing, network management, and security subsystems of the Wireless Gateway. Additionally, the messaging gateway is configured using the Wireless Gateway's administration console, the Wireless Gatekeeper.

Messaging functions

The messaging gateway adds short messaging support to the Wireless Gateway. This section covers, in more detail, the types of messaging functions available to applications using the Messaging Services and Push Toolkit:

Sending WAP push messages

The Wireless Access Protocol (WAP) is a protocol standard established by the WAP Forum, a consortium of wireless carriers and software providers. WAP is an optimized version of the standard TCP stack and is designed to support small client devices such as mobile phones. For more detailed information on WAP, see the WAP Forum website.

The Wireless Gateway can be configured as a fully functional Wireless Access Protocol (WAP) gateway. The messaging gateway uses the Wireless Gateway's WAP services to send WAP push messages. The WAP services module processes the push messages and sends those messages across a WAP bearer to a WAP-enabled client device. The Wireless Gateway's implementation of a WAP bearer is referred to as a mobile network connection (MNC).

The WAP protocol specifies an architecture for pushing messages to WAP-enabled client devices. Specifically, the WAP specification includes the Push Access Protocol (PAP), a communications protocol over which WAP push messages are submitted from a push initiator (PI) to a push proxy gateway (PPG). For more information about these specifications, see WAP-164, Push Access Protocol Specification and WAP-165, Push Architectural Overview. For WAP push messages, the messaging gateway functions as a PPG and the application using the API to push messages functions as a PI.

Application developers can use the Messaging Services and Push Toolkit to send WAP push messages to WAP-enabled client devices. The Toolkit APIs provide a layer of abstraction that insulates the application developer from the WAP details.

Figure 2 below shows an example flow for a WAP push message.

Figure 2. Sending a WAP push message through a UCP SMS network.
Sending a WAP push message through a UCP SMS network.

Sending non-WAP push messages

Currently, few WAP-enabled client devices exist beyond simulators and prototypes. Therefore, IBM has extended the messaging gateway support beyond WAP to include the commercially successful short messaging networks such as GSM and SNPP. Applications can take advantage of the IBM extensions by using the Toolkit to send push messages to client devices such as email clients, pagers, GSM-SMS phones, and other non-WAP client devices.

For messages that are not WAP-related, the messaging gateway delivers the message directly to the appropriate Wireless Gateway MNC without passing through the Wireless Gateway's WAP services. See Figure 3 below for an example of a non-WAP push.

Applications initiating a push can specify a specific MNC to process a message. If the application does not specify an MNC, the messaging gateway selects an MNC based on attributes of the push message, such as the address type. If no MNC is specified and there are multiple MNCs that can handle the push message type, the messaging gateway will load-balance messages across all of the matching MNCs.

Messages pushed from the messaging gateway to a client device are often referred to as "mobile-terminated messages." Mobile-terminated messages can be further categorized as either confirmed or unconfirmed.

  • Confirmed - The message transfer agent (MTA) confirms delivery of the push message to the client device. The messaging gateway forwards this result confirmation to applications that require message confirmations. Support for confirmed push messages depends on the MTA selected to transport the message.
  • Unconfirmed - The simple case in which an application does not request a delivery confirmation. Applications will not be able to determine if a message was successfully delivered. All MNCs support unconfirmed push messages.

An example of a mobile-terminated push solution is a stock alert application. For example, a user configures an alert on a particular stock at a specific price threshold. When the stock price exceeds the threshold, the application uses the Toolkit APIs to push an alert to the end user's GSM phone. An example short message in this case might be "IBM is now trading at > 150."

Figure 3 below shows an example flow for a non-WAP mobile-terminated message.

Figure 3: Sending a non-WAP push message through an SMPP SMS network.
Sending a non-WAP push message through an SMPP SMS network.

Receiving mobile-originated messages

More and more client devices now have the ability to compose and send short messages. These messages are known as "mobile-originated." Everyplace Wireless Gateway, Version 1.1.4 adds support for receiving mobile-originated messages.

To maintain an open and flexible design, the messaging gateway does not interpret mobile-originated messages. Instead, the messaging gateway posts these messages to a pre-configured URL for processing by an application. The URL is set as part of the MNC configuration, so each MNC can have a different forwarding URL. The incoming message will be forwarded to the URL associated with the MNC that receives the message.

The processing application makes use of the Toolkit APIs to extract the original mobile-originated message from the HTTP post. Application designers can specify any type of format for mobile-originated messages without changes to the Wireless Gateway configuration.

An example of a mobile-originated messaging solution is the ubiquitous stock quote application. Users enter a stock quote query in a predefined format such as "STOCK IBM." The messaging gateway receives this message and posts it to the pre-configured URL. The stock quote application receives the message using the Toolkit and pushes a response back through the messaging gateway to the client device.

Figure 4 below illustrates an example flow for a mobile-originated message.

Figure 4: Receiving a mobile-originated push through an SMPP SMS network.
Receiving a mobile-originated push through an SMPP SMS network.

Canceling push messages

Applications can use the Toolkit APIs to cancel previously submitted push messages. Only messages queued for delivery in the messaging gateway can be canceled; that is, only messages sent with a "deliver after" time may be canceled. The cancel request will succeed if the message has not yet been delivered to the MTA. After a message has been delivered to a MTA, it cannot be canceled even though the message may still be in transit between the gateway and target client device.

Querying the status of push messages

Applications can use the Toolkit APIs to request the status of a previously submitted push message. The level of detail in the status returned is dependent on the MNC that processed the message.

Over-the-air provisioning

Many wireless providers support over-the-air (OTA) provisioning of client devices (most often phones). This function is important because it allows the provider to distribute client devices without first activating them on their network. The end user can then connect to a special number or site and configure the client device over the air.

The messaging gateway supports over-the-air provisioning, but does not handle the provisioning itself. The Toolkit API supports applications that provision client devices by allowing the applications to receive mobile-originated messages and to respond with provisioning messages. This solution allows a single application to provision any type of client device.

Security

Version 1.2 of the WAP push protocol specification does not provide any inherent security mechanism for end-to-end security between a Push Initiator (PI) and a client device. However, the messaging gateway can use secured connections with PIs using Secure Socket Layer (SSL). The SSL environment must be configured at the PI and at the messaging gateway. The messaging gateway acts as an SSL server and the PI acts as an SSL client.

Result notifications and mobile-originated messages transferred between the messaging gateway and applications using the Toolkit will also be sent over a secured link if the application's URL begins with HTTPS rather than HTTP. Management of the necessary SSL certificates is covered in the Wireless Gateway Administrator's Guide.

Administration of the messaging gateway can also be performed over SSL connections. In addition, the Wireless Gateway administration console (the Wireless Gatekeeper) implements access control lists (ACL). Using ACLs, you can limit the access of various administrative users to subsets of the Wireless Gateway's configuration.

Several of the MNCs are implemented over X.25 connections that are inherently more secure than typical IP connections. For more details, see Table 1 and Table 2.

Accounting and billing

The messaging gateway takes advantage of the Wireless Gateway's accounting subsystem to track usage. An accounting record is created for each message processed by the messaging gateway. If configured for accounting, the Wireless Gateway will write the records to a relational database.

The database schema is documented in the Wireless Gateway Administrator's Guide. Billing systems can access the data by querying the relational database.

Supported networks

The Wireless Gateway manages network connections using mobile network connection (MNC) modules. There is a different type of MNC for each network supported. To create a connection to a specific network, you would configure an MNC for that network with the specific parameters for the connection. You can configure as many MNCs as you have available connections.

If you need more than one connection to the same network provider, you can define multiple MNCs of the same type. For example, you might want to double your throughput by using two X.25 lines to a network provider instead of just one X.25 line.

Applications sending messages can select a specific MNC for each message. If no MNC is specified, the messaging gateway load-balances the messages between the available MNCs.

Table 1 and Table 2 list the network types supported by the messaging gateway. This list will continue to grow, as customer needs change. If you are interested in a specific network not listed, please contact your IBM representative.

Table 1 below shows the networks supported by the messaging gateway for non-WAP messaging, along with the operations supported.

Table 1: Non-WAP MNCs supported by the messaging gateway

MNC Description Mobile-
originated
Mobile-
terminated
Confirmed Unconfirmed Cancel Status Query
sms-ucp Short message service using universal computer protocol/external machine interface (UCP/EMI). See Appendix A for more details. yes yes yes yes yes yes
sms-smpp Short message service using short message peer-to-peer protocol (SMPP). See Appendix A for more details. yes yes yes yes yes yes
sms-ucp-x25 Short message service using UCP/EMI over X.25. See Appendix A for more details. yes yes yes yes yes yes
sms-smpp-x25 Short message service using SMPP over X.25. See Appendix A for more details. yes yes yes yes yes yes
smtp Simple mail transport protocol, as specified in RFC 821. Note that extensions to the RFC, such as MIME support or mail server authentication, are not supported. See Appendix A for more details. no yes no yes yes yes
snpp Simple network paging protocol, as specified in RFC 1861. Note that all function of Level 1 and required elements from Level 2 are supported. SNPP Level 3 is not supported. See Appendix A for more details. no yes no yes yes yes
mobitex Mobitex international standard connection using X.25. no yes no yes yes yes
mobitex tcp Mobitex using TCP, such as Mobitex Internet application server (IAS). no yes no yes yes yes
all WAP MNCs All WAP MNCs (bearers) support the same operations. no yes no yes yes yes

Table 2 below shows the networks supported by the messaging gateway for WAP pushes. Note that all WAP bearers have the same capabilities and quality-of service settings, which are shown in the last row of Table 1 above.

Table 2: WAP bearers supported by the messaging gateway

MNC Description
dial-isdn Integrated services digital network, only using native-PPP connections
dial-pstn Public switched telephone network, only using native-PPP connections
dial-tcp Dial connection through an IP-attached modem server, only using native-PPP connections
ip-wdp IP/UDP bearer adapter using wireless datagram protocol
mobitex Mobitex international standard connection using X.25
mobitex tcp Mobitex using TCP, such as Mobitex Internet application server (IAS)
sms-smpp Short message service using short message peer to peer protocol (SMPP)
sms-ucp Short message service using universal computer protocol/external machine interface (UCP/EMI)
sms-ucp-x25 Short message service using UCP/EMI over X.25
sms-smpp-x25 Short message service using SMPP over X.25

Messaging services and push toolkit

The IBM Everyplace Wireless Gateway Messaging Services and Push Toolkit is an SDK that provides APIs, technical documentation, and samples that help you write applications that work with the messaging gateway. APIs are provided for both Java™ and C.

Using the API, you can write applications that:

  • create and send push messages to client devices
  • receive and process confirmation messages indicating the success or failure of a push operation
  • cancel previously submitted messages
  • query the status of previously submitted messages
  • receive and process mobile-originated messages

The Toolkit provides a unified programming interface that allows application writers to distribute information to a wide variety of client devices from the same application. For example, an airline may allow customers to register their client devices on a web page so that they may receive notification of flight delays or cancellations. An application can use the Toolkit APIs to deliver notifications to cell phones, pagers, email addresses, and other short messaging client devices. Because the messaging gateway can be configured to work with multiple mobile network connections, all of the notifications can be delivered through a single messaging gateway

The toolkit comes with an extensive Developer's Guide that guides you through a tutorial for creating a simple push application. Detailed C API specifications and detailed Java API specifications as well as sample programs are also included.

The Java API was developed using JDK 1.1.8 and prerequisites 1.1.8 or later levels of the JRE.

The C API is currently available on:

  • IBM AIX®
  • Microsoft® Windows® 32-bit platforms

The Messaging Services and Push Toolkit APIs are based on the WAP Push Access Protocol (PAP) specification, which specifies an API-to-gateway XML flow. The APIs were designed to hide the XML flows from the application writer by wrapping the XML flows with the APIs. The messaging gateway extends the PAP specification to add support for non-WAP devices (such as a GSM-SMS phone or an e-mail client). If you are using the APIs to send only non-WAP push messages, you may find that many API features do not apply.

Scalability and performance

The Wireless Gateway is a scalable enterprise solution, supporting multiple-processor servers and clustering of servers. As part of the Wireless Gateway, the messaging gateway benefits from many of the Wireless Gateway's performance and scalability features. The messaging gateway relies on the Wireless Gateway for many basic functions (for example, configuration, logging, accounting, and communications), and thus benefits from the scalability of those functions within the Wireless Gateway. The Wireless Gateway will take advantage of multiple processors by spreading its workload across all available processors.

The Wireless Gateway can also be configured in clusters to distribute work. The messaging gateway can reside on a server that is part of a cluster, but there are no messaging gateway performance gains as a result of clustering.

To achieve messaging performance improvements similar to that of clustered Wireless Gateways, use the IBM Network Dispatcher in concert with multiple messaging gateways. The IBM Network Dispatcher is available as a component of the IBM WebSphere Edge Server.

Figure 5 below shows an example installation that takes advantage of the Network Dispatcher. In this example, there are three push initiators using the Messaging Toolkit to generate and send push messages. Network Dispatcher is installed between the push initiators and the two messaging gateways. The Network Dispatcher load-balances the traffic between the push initiators and the two messaging gateways. Each of the two messaging gateways has the same configuration, with two mobile network connections (MNCs) defined, one for each of the MTAs. Each messaging gateway load-balances the number of push messages sent to each MTA.

Figure 5: Using the Network Dispatcher to distribute traffic among multiple messaging gateways.
Using the Network Dispatcher to
                                  distribute traffic among multiple messaging
                                  gateways.

 

There is a known limitation when using Network Dispatcher and the messaging gateway in this fashion. Status queries and cancel requests should be sent to the same gateway that handled the original request. However, when using Network Dispatcher to load-balance among gateways, status queries and cancel requests may be routed to a messaging gateway other than the one that handled the original request. In this case, status queries and cancel requests may incorrectly return failure codes.

IBM's testing has shown that the connection to the network provider is often the gating factor in performance results, particularly with SMS carriers and SMTP servers. If the physical connection to the network provider is limiting performance, adding additional physical connections on the same messaging gateway may help improve performance. By defining multiple MNCs of the same type, the total throughput of messages to the same network can be increased. The messaging gateway will allow you to configure any number of MNCs, of the same or different network types. If multiple MNCs of the same type exist, the messaging gateway load-balances by distributing messages among the MNCs.

Glossary

Message transfer agent (MTA)
The network agent to which the messaging gateway delivers push messages. Each supported network has a different MTA. Examples of MTAs include: SMS-Cs, SMTP servers, and SNPP servers.
Messaging gateway
The messaging and push services provided by the Wireless Gateway.
Mobile network connection (MNC)
The interface between the Wireless Gateway and a specific MTA. There is a different MNC for every type of MTA. An MNC is sometimes referred to as a bearer or bearer network.
Push access protocol (PAP)
A communications protocol over which WAP push messages are submitted from a push initiator (PI) to a push proxy gateway (PPG). For more information about these specifications, see WAP-164, Push Access Protocol Specification and WAP-165, Push Architectural Overview.
Push initiator (PI)
An application that submits WAP push messages, as defined in the WAP specification.
Push proxy gateway (PPG)
When the messaging gateway processes WAP PAP traffic, it functions as a PPG, as defined by the WAP Forum (see WAP-151, Push Proxy Gateway Service Specification). When it processes other kinds of message traffic, it functions more generally as a messaging gateway.
SMS-C
Short messaging service center. In SMS networks, the SMS-C is the MTA to which the messaging gateway delivers push messages.
Short Message Peer-to-Peer (SMPP), Version 3.4
An open, industry standard protocol that supports GSM, IS-95 (CDMA), ANSI-136 (TDMA), and iDEN Digital Cellular Network technologies. This protocol is implemented to run over TCP/IP and X.25 networks.
Simple Mail Transport Protocol (SMTP)
The standard Internet mail delivery protocol. The Messaging Services and Push Toolkit offers seamless integration of e-mail recipients along with the direct device addressing provided by the other protocols. WAP messages are not supported over this protocol. This protocol is implemented to run over TCP/IP networks and requires an accessible SMTP mail server.
Simple Network Paging Protocol (SNPP)
An open, industry standard protocol similar to SMTP for delivery of text pages. This is the primary protocol supported by the service providers in the US. WAP messages are not supported over this protocol. This protocol is implemented to run over TCP/IP networks.
Universal Computer Protocol (UCP), sometimes referred to as External Machine Interface (EMI)
A protocol designed for delivery of short messages to SMS centers (SMS-Cs) for delivery over GSM SMS networks. This is the primary protocol used by European network providers. This protocol is implemented to run over TCP/IP and X.25 networks.
Wireless Access Protocol (WAP)
An open industry standard for mobile Internet access. WAP allows mobile users with wireless devices to easily and instantly access and interact with information and services.
Wireless Gateway
The entire Everyplace Wireless Gateway product, which may be configured as a messaging gateway.

Appendix A: Protocol specifications and levels

Protocol Relevant specifications and supported Levels
SMS-UCP Sometimes referred to as External Machine Interface (EMI) - A protocol designed for delivery of short messages to SMS centers (SMS-Cs) for delivery over GSM SMS networks. This is the primary protocol used by European network providers. This protocol is implemented to run over TCP/IP and X.25 networks.

The messaging gateway supports UCP/EMI Level 3.5
.
SMS-SMPP An open, industry standard protocol that supports GSM, IS-95 (CDMA), ANSI-136 (TDMA), and iDEN Digital Cellular Network technologies. This protocol is implemented to run over TCP/IP and X.25 networks.

The messaging gateway supports SMPP Level 3.4
.
SMTP The standard Internet e-mail delivery protocol. Our Push Toolkit API offers seamless integration of e-mail recipients along with the direct device addressing provided by the other protocols. WAP messages are not supported over this protocol. This protocol is implemented to run over TCP/IP networks and requires an accessible SMTP mail server.

The messaging gateway supports all required SMTP protocol elements specified in RFC 821.
SNPP An open, industry standard protocol similar to SMTP for delivery of text messages. This is the primary protocol supported by the service providers in the US. WAP messages are not supported over this protocol. This protocol is implemented to run over TCP/IP networks.

The messaging gateway supports all Level 1 SNPP protocol elements as specified in RFC 1861, and all the minimum requirements in Level 2, and none of the Level 3 elements. In practical terms, the messaging gateway implements one-way paging with no acknowledgments from the target pager. The messaging gateway supports multi-line pages.
WAP An open industry standard for mobile Internet access. WAP allows mobile users with wireless devices to easily and instantly access and interact with information and services.

The messaging gateway supports Version 1.2 of the WAP specification.

Appendix B: Referenced websites

Site Name Site URL
IBM Pervasive Computing http://www.ibm.com/pvc
IBM Wireless Gateway Administrator's Guide http://www-3.ibm.com/PVC/tech/library.shtml
C API Reference http://www-3.ibm.com/PVC/tech/downloads.shtml
Java API Reference http://www-3.ibm.com/PVC/tech/downloads.shtml
Messaging Services and Push Toolkit Developer's Guide http://www-3.ibm.com/PVC/tech/downloads.shtml
IBM WebSphere Everyplace Suite http://www-3.ibm.com/PVC/products/wes/
WAP Forum http://www.wapforum.org/
WAP-151, Push Proxy Gateway Service Specification http://www1.wapforum.org/tech/terms.asp?doc=WAP-151-PPGService-19990816-a.pdf
WAP-164, Push Access Protocol Specification http://www1.wapforum.org/tech/terms.asp?doc=WAP-164-PAP-19991108-a.pdf
WAP-165, Push Architectural Overview http://www1.wapforum.org/tech/terms.asp?doc=WAP-165-PushArchOverview-19991108-a.pdf
IBM Network Dispatcher http://www-4.ibm.com/software/network/dispatcher/
IBM WebSphere Edge Server http://www-4.ibm.com/software/webservers/edgeserver/

Top of page

Tim Rich is a software engineer for IBM in Research Triangle Park, North Carolina. He has been developing wireless middleware since he joined IBM in 1995 and has been on the WebSphere Everyplace Wireless Gateway team for five years and four product name changes. You can reach Tim at tsrich@us.ibm.com.

Roger Wilson is a software engineer for IBM in Research Triangle Park, North Carolina, working on the WebSphere Everyplace Suite team. He has been with IBM for ten years, spending the last six developing wireless middleware. Roger received his Master's degree in Computer and Information Engineering Sciences from the University of Florida in 1991 and is a fanatical Florida Gator! You can reach him at rawilson@us.ibm.com.


AIX, Everyplace, IBM, and WebSphere are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windlows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, and service names may be trademarks or service marks of others.

IBM copyright and trademark information

© 2001 International Business Machines Corporation. All rights reserved.

[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]