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.
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 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.
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.
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.
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
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.
