Short Message Service (SMS)
http://www.gsmfavorites.com/documents/sms/
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.
Introduction to SMS
SMS appeared on the wireless scene in 1991 in Europe. The European standard for digital wireless,
now known as the Global System for Mobile Communications (GSM), included short messaging
services from the outset.
In North America, SMS was made available initially on digital wireless networks built by early
pioneers such as BellSouth Mobility, PrimeCo, and Nextel, among others. These digital wireless
networks are based on GSM, code division multiple access (CDMA), and time division multiple
access (TDMA) standards.
Network consolidation from mergers and acquisitions has resulted in large wireless networks
having nationwide or international coverage and sometimes supporting more than one wireless
technology. This new class of service providers demands network-grade products that can easily
provide a uniform solution, enable ease of operation and administration, and accommodate existing
subscriber capacity, message throughput, future growth, and services reliably. Short messaging
service center (SMSC) solutions based on an intelligent network (IN) approach are well suited to
satisfy these requirements, while adding all the benefits of IN implementations.
SMS provides a mechanism for transmitting short messages to and from wireless devices. The
service makes use of an SMSC, which acts as a store-and-forward system for short messages. The
wireless network provides the mechanisms required to find the destination station(s) and transports
short messages between the SMSCs and wireless stations. In contrast to other existing text-message
transmission services such as alphanumeric paging, the service elements are designed to provide
guaranteed delivery of text messages to the destination. Additionally, SMS supports several input
mechanisms that allow interconnection with different message sources and destinations.
A distinguishing characteristic of the service is that an active mobile handset is able to receive or
submit a short message at any time, independent of whether a voice or data call is in progress (in
some implementations, this may depend on the MSC or SMSC capabilities). SMS also guarantees
delivery of the short message by the network. Temporary failures due to unavailable receiving
stations are identified, and the short message is stored in the SMSC until the destination device
becomes available.
SMS is characterized by out-of-band packet delivery and low-bandwidth message transfer, which
results in a highly efficient means for transmitting short bursts of data. Initial applications of SMS
focused on eliminating alphanumeric pagers by permitting two-way general-purpose messaging and
notification services, primarily for voice mail. As technology and networks evolved, a variety of
services have been introduced, including e-mail, fax, and paging integration, interactive banking,
information services such as stock quotes, and integration with Internet-based applications. Wireless
data applications include downloading of subscriber identity module (SIM) cards for activation,
debit, profile-editing purposes, wireless points of sale (POSs), and other field-service applications
such as automatic meter reading, remote sensing, and location-based services. Additionally,
integration with the Internet spurred the development of Web-based messaging and other interactive
applications such as instant messaging, gaming, and chatting.
1. Benefits of SMS
In today's competitive world, differentiation is a significant factor in the success of the service
provider. Once the basic services, such as voice telephony, are deployed, SMS provides a powerful
vehicle for service differentiation. If the market allows for it, SMS can also represent an additional
source of revenue for the service provider.
The benefits of SMS to subscribers center around convenience, flexibility, and seamless integration
of messaging services and data access. From this perspective, the primary benefit is the ability to
use the handset as an extension of the computer. SMS also eliminates the need for separate devices
for messaging because services can be integrated into a single wireless device—the mobile terminal.
These benefits normally depend on the applications that the service provider offers. At a minimum,
SMS benefits include the following:
 Delivery of notifications and alerts
 Guaranteed message delivery
 Reliable, low-cost communication mechanism for concise information


Ability to screen messages and return calls in a selective way
Increased subscriber productivity
More sophisticated functionality provides the following enhanced subscriber benefits:
 Delivery of messages to multiple subscribers at a time
 Ability to receive diverse information
 E-mail generation
 Creation of user groups
 Integration with other data and Internet-based applications
The benefits of SMS to the service provider are as follows:







Ability to increment average revenue per user (due to increased number of calls on wireless
and wireline networks by leveraging the notification capabilities of SMS)
An alternative to alphanumeric paging services, which may replace or complement an existing
paging offer
Ability to enable wireless data access for corporate users
New revenue streams resulting from addition of value-added services such as e-mail, voice
mail, fax, and Web-based application integration, reminder service, stock and currency quotes,
and airline schedules
Provision of key administrative services such as advice of charge, over-the-air downloading,
and over-the-air service provisioning
Protection of important network resources (such as voice channels), due to SMS’ sparing use
of the control and traffic channels
Notification mechanisms for newer services such as those utilizing wireless application
protocol (WAP)
2. Network Elements and Architecture
External Short Messaging Entities
An ESME is a device that may receive or send short messages. The short message entity (SME)
may be located in the fixed network, a mobile device, or another service center.
 VMS—The VMS is responsible for receiving, storing, and playing voice messages intended



for a subscriber that was busy or not available to take a voice call. It is also responsible for
sending voice-mail notifications for those subscribers to the SMSC.
Web—The growth of the Internet has also affected the world of SMS. Therefore, it is almost
mandatory to support interconnections to the World Wide Web for the submission of messages
and notifications. The increasing number of Internet users has a positive impact on the SMS
traffic increment experienced in the last few years.
E-Mail—Probably the most demanded application of SMS is the ability to deliver e-mail
notifications and to support two-way e-mail, using an SMS–compliant terminal. The SMSC
must support interconnection to e-mail servers acting as message input/output mechanisms.
Others—There are several other mechanisms to submit short messages to the SMSC that
include, but are not limited to, paging networks, specialized software for PC–based messaging
and operator bureaus.
SMSC
SMSC is a combination of hardware and software responsible for the relaying and storing and
forwarding of a short message between an SME and mobile device.
The SMSC must have high reliability, subscriber capacity, and message throughput. In addition, the
system should be easily scalable to accommodate growing demand for SMS in the network.
Normally, an IN–based solution will allow for a lower entry cost compared to point solutions
because it can support other applications on a single hardware platform and share resources, thereby
spreading the deployment cost over several services and applications.
Another factor to be considered is the ease of operation and maintenance of the application, as well
as the flexibility to activate new services and upgrade to new software releases.
Signal Transfer Point
The STP is a network element normally available on IN deployments that allows IS–41
interconnections over signaling system 7 (SS7) links with multiple network elements.
HLR
The HLR is a database used for permanent storage and management of subscriptions and service
profiles. Upon interrogation by the SMSC, the HLR provides the routing information for the
indicated subscriber. Also, if the destination station was not available when the message delivery
was attempted, the HLR informs the SMSC that the station is now recognized by the mobile
network to be accessible, and thus the message can be delivered.
Visitor Location Register (VLR)
The visitor location register is a database that contains temporary information about subscribers
homed in one HLR who are roaming into another HLR. This information is needed by the MSC to
service visiting subscribers.
MSC
The MSC performs the switching functions of the system and controls calls to and from other
telephone and data systems. The MSC will deliver the short message to the specific mobile
subscriber through the proper base station.
Air Interface
The air interface is defined in each one of the different wireless technologies (GSM, TDMA, and
CDMA). These standards specify how the voice or data signals are transferred from the MSC to the
handset and back, as well as the utilization of transmission frequencies, considering the available
bandwidth and the system’s capacity constraints.
The Base Station System
All functions related to the transmission of electromagnetic radio signals between the MSC and the
mobile devices are performed in the base station (BS). The BS consists of base station controllers
(BSCs) and the base transceiver stations (BTSs), also known as cell sites or simply “cells.” The
BSC may control one or more BTSs and is in charge of the proper resource assignment when a
subscriber moves from one sector of one BTS to another, regardless of whether the next sector lies
within the same BTS or in a different one.
The Mobile Device
The mobile device is the wireless terminal capable of receiving and originating short messages.
Commonly, these devices have been digital cellular phones, but more recently the application of
SMS has been extended to other terminals such as POS, handheld computers, and personal digital
assistants (PDAs). The wireless network signaling infrastructure is based on SS7. SMS makes use
of the mobile application part (MAP), which defines the methods and mechanisms of
communication in wireless networks and employs the services of the SS7 transactional capabilities
application part (TCAP). An SMS service layer makes use of the MAP signaling capabilities and
enables the transfer of short messages between the peer entities. The capabilities of the terminal
vary depending on the wireless technology supported by the terminal. Some functionality, although
defined in the SMS specification for a given wireless technology, may not be fully supported in the
terminal, which may represent a limitation in the services that the carrier can provide. This trend,
however, is disappearing as service providers’ merger and acquisition activity demands uniform
functionality across all the constituents of the parent companies. Also, some manufacturers may
include additional functionality, not considered in the specification, attempting to offer a more
attractive product for service providers as well as end users. This will be the case more often as
service provider continue to incorporate SMS into their revenue-generating and customer-loyalty
strategies.
3. Signaling Elements
The MAP layer defines the operations necessary to support SMS. Both American and international
standards bodies have defined a MAP layer using the services of the SS7 TCAP. The American
standard is published by Telecommunication Industry Association and is referred to as IS–41. The
international standard is defined by the European Telecommunications Standards Institute (ETSI)
and is referred to as GSM MAP. The following basic MAP operations are necessary to provide the
end-to-end SMS:
 Routing Information Request—Before attempting delivery of a short message, the SMSC must
receive routing information to determine the serving MSC for the mobile device at the time of
the delivery attempt. This is accomplished by way of an interrogation of the destination
handset’s HLR, which is accomplished via the use of the SMSrequest and

SendRoutingInfoForShortMsg mechanisms in IS–41 and GSM, respectively.
Point-to-Point Short Message Delivery—The mechanism provides a means for the SMSC to

transfer a short message to the MSC that is serving the addressed mobile device. After the
address of said MSC has been obtained from the station’s HLR, the short message delivery
operation provides a confirmed delivery service. The operation works in conjunction with the
base station subsystem while the message is being forwarded from the MSC to the MS.
Therefore, the outcome of the operation comprises either success (such as delivery to the
mobile) or failure caused by one of several possible reasons. The point-to-point short message
delivery is accomplished via the use of the short message delivery–point-to-point (SMD–PP)
and forwardShortMessage mechanisms in IS–41 and GSM, respectively.
Short Message Waiting Indication—he operation is activated when a short message delivery

attempt by the SMSC fails due to a temporary failure, such as the station being unregistered,
and provides a means for the SMSC to request the HLR to notify the SMSC when the
indicated mobile device becomes available. This short message waiting indication is realized
via the use of the SMS_notification indicator and set_message_waiting_data mechanisms in
IS–41 and GSM, respectively.
Service Center Alert—The operation provides a means for the HLR to inform the SMSC,
which has requested a notification that a specific mobile device is now recognized by the
mobile network to be available. This service center alert is accomplished via the use of the
SMS_notification and alert_service_center mechanisms in IS–41 and GSM, respectively.
Service Elements
SMS is comprised of several service elements relevant to the reception and submission of short
messages:
 Message Expiration—The SMSC will store and reattempt delivery of messages for unavailable
recipients until either the delivery is successful or the expiration time—set on a per-message
basis or on a platform-wide basis—arrives.
 Priority—This is the information element provided by an SME to indicate the urgent messages
and differentiate them from the normal priority messages. Urgent messages usually take
priority over normal messages, regardless of the time of arrival to the SMSC platform.
 Message Escalation—The SMSC stores the message for a period no longer than the expiration
time (it is assumed that the escalation time is smaller than the expiration time associated with
the message), and after said escalation time expires, the message will be sent to an alternate
message system (such as a paging network or an e-mail server) for delivery to the user.
In addition, SMS provides a time stamp reporting the time of submission of the message to the
SMSC and an indication to the handset of whether or not there are more messages to send (GSM) or
the number of additional messages to send (IS–41).
Subscriber Services
SMS comprises two basic point-to-point services:


Mobile-originated short message (MO–SM)
Mobile-terminated short message (MT–SM)

Mobile-originated (MO) short messages are transported from the MO–capable handset to the
SMSC and can be destined to other mobile subscribers or for subscribers on fixed networks
such as paging networks or Internet protocol (IP) networks (including the Internet and private
e-mail networks). Mobile-terminated (MT) short messages are transported from the SMSC to
the handset and can be submitted to the SMSC by other mobile subscribers via MO–SM or by
other sources such as voice-mail systems, paging networks, or operators.
For MT–SM, a report is always returned to the SMSC either confirming the short message delivery
to the handset or informing the SMSC of the short message delivery failure and identifying the
reason for failure (cause code). Similarly, for MO–SM, a report is always returned to the handset
either confirming the short message delivery to the SMSC or informing of delivery failure and
identifying the reason. Depending on the access method and the encoding of the bearer data, the
point-to-point short messaging service conveys up to 190 characters to an SME in GSM networks
and from 120 to 205 in IS–41 networks. In GSM networks, the type of messaging service is
identified by the protocol identifier information element, which identifies the higher-level protocol
or interworking being used. Examples are telex, group 3 telefax, X.400 messaging, European Radio
Messaging System (ERMES), and voice telephone. In IS–41 networks, the service type is
distinguished by use of the teleservice identifier. Basic teleservices include the following:
 Cellular messaging teleservice (CMT)


Cellular paging teleservice (CPT)
Voice-mail notification teleservice (VMN)
CMT differs from the CPT due to the inclusion of a reply mechanism that enables a user or network
acknowledgment to be selected on a per-message basis. The user acknowledgment includes a
response code that paves the way for powerful interactive services between SMSCs. Many service
applications can be implemented by combining these service elements. Aside from the obvious
notification services, SMS can be used in one-way or interactive services providing wireless access
to any type of information anywhere. By leveraging new emerging technologies that combine
browsers, servers, and new markup languages designed for mobile terminals, SMS can enable
wireless devices to securely access and send information from the Internet or intranets quickly and
cost-efficiently. One of these technologies where SMS can provide a cooperative, rather than a
competitive, approach is the WAP, which allows transport of data for mobile wireless users.
Some of the potential applications of SMS technology, utilizing both MT–SM and MO–SM where
appropriate, include the following:
 Notification Services—Notification services are currently the most widely deployed SMS
services. Examples of notification services using SMS include the following:
 Voice/fax message notification, which indicates that voice or fax mail messages are
present in a voice mailbox





E-mail notification, which indicates that e-mail messages are present in an e-mail mailbox
Reminder/calendar services, which enable reminders for meetings and scheduled
appointments.
E-mail Interworking—Existing e-mail services can be easily integrated with SMS to provide
e-mail to short messaging and mobile e-mail and message escalation.
Paging Interworking—Paging services integrated with SMS allow digital wireless subscribers
to be accessible via existing paging interfaces, as well as escalation of messages.
Information Services—A wide variety of information services can be provided by the SMS,
including weather reports, traffic information, entertainment information (e.g., cinema, theater,
concerts), financial information (e.g., stock quotes, exchange rates, banking, brokerage
services), and directory assistance. SMS can support both push (MT) and pull (MO)
approaches to allow not only delivery under specific conditions but also delivery on demand,
as a response to a request.
WAP Integration—SMS can deliver notifications for new WAP messages to wireless
subscribers but can also be used as the transport mechanism for WAP messages. These
messages can contain diverse information from sources that include databases, the World Wide
Web, e-mail servers, etc.
Mobile Data Services
The SMSC can also be used to provide short wireless data. The wireless data may be in interactive
services where voice calls are involved.
Some examples of this type of service include fleet dispatch, inventory management, itinerary
confirmation, sales order processing, asset tracking, automatic vehicle location, and customer
contact management. Other examples may be interactive gaming, instant messaging, mobile chat,
query services, mobile banking, etc.
Customer Care and Management
The SMSC can also be used to transfer binary data that can be interpreted by the mobile device
without presentation to the customer. This capability allows the operators to administer their
customers by providing a mechanism for programming the mobile device. Examples of such
services include mobile device programming, which allows customer profiles and subscription
characteristics to be downloaded to the mobile device (customers can be activated/deactivated based
on the data downloaded) and advice of charge, which enables the SMS to be used to report charges
incurred for the phone call (e.g., calls made when roaming).
One interesting method to provide customer support is to offer a list of answers to frequently asked
questions via short message. SMS also can be used to distribute general information about other
products and services being offered by the service provider, thus guaranteeing maximum
penetration of the advertising over the existing customer base. In a different scenario, a service
provider may want to deliver short messages to subscribers to remind them of, for example,
past-due payments, instead of reminding them over traditional mail or courier delivery, therefore
reducing cost and ensuring that the message is delivered to its destination in a timely manner.
4. Mobile-Terminated Short Message Example
 The short message is submitted from the ESME to the SMSC.
 After completing its internal processing, the SMSC interrogates the HLR and receives the
routing information for the mobile subscriber.
 The SMSC sends the short message to the MSC using the forward short message operation.
 The MSC retrieves the subscriber information from the VLR. This operation may include an
authentication procedure.
 The MSC transfers the short message to the MS.











The MSC returns to the SMSC the outcome of the forwardShortMessage operation.
If requested by the ESME, the SMSC returns a status report indicating delivery of the short
message.
The short message is submitted from the ESME to the SMSC.
The SMSC sends an acknowledgement to the ESME, indicating reception of the short
message.
After completing its internal processing, the SMSC interrogates the HLR.
The HLR sends the routing information for the mobile subscriber to the SMSC.
The SMSC sends the short message to the MSC using the SMSDPP Invoke operation.
The MSC transfers the short message to the MS.
The MS returns an acknowledgement to the MSC.
The MSC returns to the SMSC the outcome of the SMSDPP operation.
If requested by the ESME, the SMSC returns a delivery receipt indicating successful delivery
of the short message.
5. Mobile-Originated Short Message Example
 The MS is powered on and registered with the network.
 The MS transfers the SM to the MSC.
 The MSC interrogates the VLR to verify that the message transfer does not violate the
supplementary services invoked or the restrictions imposed.







The MSC sends the short message to the SMSC using the forwardShortMessage operation.
The SMSC delivers the short message to the SME (and optionally receives acknowledgment).
The SMSC acknowledges to the MSC the successful outcome of the forwardShortMessage
operation.
The MSC returns to the MS the outcome of the MO-SM operation.
The MS transfers the SM to the MSC.
The MSC interrogates the home SMSC to verify that the message transfer does not violate the
supplementary services invoked or the restrictions imposed. The MSC sends the short message
to the home SMSC using the SMSPP Invoke operation.
The SMSC delivers an acknowledgment to the MSC.


The MSC returns order release to the MS.
The SMSC queries the HLR for the location of the destination MS.





The HLR returns the destination (MSC) serving the destination MS.
The SMSC delivers SM to the MSC serving the destination MS.
The SMSC delivers the short message to the MS.
The MS acknowledges to the MSC the successful outcome of the SMSDPP operation.
The MSC returns to the SMSC the outcome of the MO–SM operation (delivery successful).
6. SMS Applications
SMS was initially designed to support limited-size messages, mostly notifications and numeric or
alphanumeric pages. While these applications are and will continue to be widely used, there are
more recent niches that SMS still can exploit.
Short bursts of data are at the heart of many applications that were restricted to the world of data
networks with fixed terminals attached to a local-area network (LAN) or wide-area network (WAN).
However, many of these applications are better served if the data communication capabilities could
be added to the mobility of the station. Thus, a waiter who can charge a customer's credit card right
at the table, at any time, instead of going to a fixed POS terminal located by the register will be able
to help customers in a faster, more convenient way.
Also, the ability to track the location of a moving asset such as a truck or its load is very valuable
for both providers and clients. This application, again, just needs to interchange small amounts of
information, such as the longitude and latitude at a current time of the day, and perhaps other
parameters like temperature or humidity.
This application does not necessarily require the monitored entity to be in movement. The
requirements are basically short, bursty data and a location that has digital network coverage. For
example, in a neighborhood, it would be faster, easier, and cheaper to drive a truck from the local
power company, which interrogates intelligent meters to obtain their current readings and then
forwards them via short message to a central data processing center to generate the billing. Similarly,
delivery trucks could be alerted of the inventory of a customer running low, when the truck is close
to the customer’s facilities. The truck driver could place a quick phone call to the customer to offer
a short-time replenishment at a low cost for the distributor.
Another family of applications that can use SMS as a data transport mechanism is banking. It is no
secret that automated teller machine (ATM) and Internet transactions are less costly than
transactions completed at a branch. Internet transactions are even cheaper than ATM transactions.
Therefore, enabling wireless subscribers to check their balances, transfer funds between accounts,
pay their bills and credit cards is valuable, not only for the subscriber but also for financial
institutions.
Entertainment applications are also good drivers of SMS usage. Examples of these are simple short
message exchanges between two parties (“texting”) or between multiple participants (“chat”). Also,
delivery of information that the subscriber can tailor to his or her lifestyle represents an attractive
proposition for wireless users.
Wireless Web browsing allows the users to search for information without the physical restrictions
of a PC. College students certainly appreciate not having to go to the computer lab or their dorm to
check e-mail or find out what the required book is for the semester that is about to start.
E-mail continues to be by far the most used wireless data application. However, handsets are
evolving quickly and are including more and more functionality that supports newer applications at
the same time that user friendliness increases. Probably the next big success beyond wireless Web
will be Internet shopping and other e-commerce applications such as electronic coupons,
advertising, etc.
The potential for applications is enormous, and new needs appear to arise constantly, demanding a
solution that may travel over SMS.
Glossary
ATM
asynchronous transfer mode
BS
base station
BSC
base station controller
BTS
base transceiver station
CDMA
code division multiple access
CMT
cellular messaging teleservice
CPT
cellular paging teleservice
ERMES
European Radio Messaging System
ESME
external short message entities
ETSI
European Telecommunications Standards Institute
GSM
Global System for Mobile Communications
HLR
home location register
IN
intelligent network
IP
Internet protocol
LAN
local-area network
MAP
mobile application part
MO
mobile originated
MO–SM
mobile-originated short message
MSC
mobile switching center
MT
mobile terminated
MT–SM
mobile-terminated short message
PDA
personal digital assistant
POS
point of sale
PP
point to point
SIM
subscriber identity module
SM
short message
SMD
short message delivery
SMD–PP
short message delivery–point to point
SME
short messaging entity
SMS
short message service
SMSC
short message service center
SS7
signaling system 7
STP
signal transfer point
TCAP
transactional capabilities application part
TDMA
time division multiple access
VLR
visitor location register
VMN
voice-mail notification
VMS
voice-mail system
WAN
wide-area network
WAP
wireless application protocol
Introduction to SMS PDU Mode
The PDU mode offers to send binary information in 7 bit or 8 bit format. That is helpful if you have
to send compressed data, binary data or you you like to build your own encoding of the characters
in the binary bit stream. If you go back on the old encoding of a Fernschreiber, then there are only 5
bit needed to send an alphanumeric text. By 5 bit coding you can contain 224 characters instatt of
160 characters in 7 bit Text mode. An others reason could be the sending of integer data.
If you would like to have the full control of your transmited data in Text mode you have to
understand the PDU mode, because there are a few commands where you can set numeric
parameters that change the kind od send and receive of a SMS in text mode also.
Please note that there are a few differences of in the kind of implemetation of the PDU mode and by
the other AT commands.
The SMS message, as specified by the Etsi organization (documents GSM 03.40 and GSM 03.38),
can be up to 160 characters long, where each character is 7 bits according to the 7-bit default
alphabet. Eight-bit messages (max 140 characters) are usually not viewable by the phones as text
messages; instead they are used for data in e.g. smart messaging (images and ringing tones) and
OTA provisioning of WAP settings. 16-bit messages (max 70 characters) are used for Unicode
(UCS2) text messages, viewable by most phones. A 16-bit text message of class 0 will on some
phones appear as a Flash SMS (aka blinking SMS or alert SMS).
The PDU format
There are two ways of sending and receiving SMS messages: by text mode and by PDU (protocol
description unit) mode. The text mode (unavailable on some phones) is just an encoding of the bit
stream represented by the PDU mode. Alphabets may differ and there are several encoding
alternatives when displaying an SMS message. The most common options are "PCCP437",
"PCDN", "8859-1", "IRA" and "GSM". These are all set by the at-command AT+CSCS, when you
read the message in a computer application. If you read the message on your phone, the phone
will choose a proper encoding. An application capable of reading incoming SMS messages, can thus
use text mode or PDU mode. If text mode is used, the application is bound to (or limited by) the set
of preset encoding options. In some cases, that's just not good enough. If PDU mode is used, any
encoding can be implemented.
Receiving a message in the PDU mode
The PDU string contains not only the message, but also a lot of meta-information about the sender,
his SMS service center, the time stamp etc. It is all in the form of hexa-decimal octets or decimal
semi-octets. The following string is what I received on a Nokia 6110 when
containing "hellohello" from www.mtn.co.za.
07
91
7238010010F5
040BC87238880900F100009930925161958003C16010
sending the message
This octet sequence consists of three parts: An initial octet indicating the length of the SMSC
information ("07"), the SMSC information itself ("917238010010F5"), and the SMS_DELIVER
part (specified by ETSI in GSM 03.40).
Note: on some phones (e.g. Ericssson 888?) the first three (colored) parts are omitted when
showing the message in PDU mode!
Octet(s)
Description
07
Length of the SMSC information (in this case 7 octets)
91
Type-of-address of the SMSC. (91 means international format of the phone
number)
Service center number(in decimal semi-octets). The length of the
72 38 01 00 10 F5
phone number is odd (11), so a trailing F has been added to form proper
octets. The phone number of this service center is "+27831000015". See
below.
04
First octet of this SMS-DELIVER message.
0B
Address-Length. Length of the sender number (0B hex = 11 dec)
C8
Type-of-address of the sender number
72 38 88 09 00 F1
Sender number (decimal semi-octets), with a trailing F
00
TP-PID. Protocol identifier.
00
TP-DCS Data coding scheme
99 30 92 51 61 95 80
TP-SCTS. Time stamp (semi-octets)
0A
TP-UDL. User data length, length of message. The TP-DCS field
indicated 7-bit data, so the length here is the number of septets (10). If the
TP-DCS field were set to indicate 8-bit data or Unicode, the length would
be the number of octets (9).
E8329BFD4697D9EC37
TP-UD. Message "hellohello" , 8-bit octets representing 7-bit data.
All the octets above are hexa-decimal 8-bit octets, except the Service center number, the sender
number and the timestamp; they are decimal semi-octets. The message part in the end of the
PDU string consists of hexa-decimal 8-bit octets, but these octets represent 7-bit data
(see below).
The semi-octets are decimal, and e.g. the sender number is obtained by performing internal
swapping within the semi-octets from "72 38 88 09 00 F1" to "27 83 88 90 00 1F".
The length of the phone number is odd, so a proper octet sequence cannot be formed by this number.
This is the reason why the trailing F has been added. The time stamp, when parsed, equals
"99 03 29 15 16 59 08", where the 6 first characters represent date, the following 6 represents
time, and the last two represents time-zone related to GMT.
Interpreting 8-bit octets as 7-bit messages
This transformation is described in detail in GSM 03.38, and an example of the "hellohello"
transformation is shown here. The transformation is based on the 7 bit default alphabet , but an
application built on the PDU mode can use any character encoding.
Sending a message in the PDU mode
The following example shows how to send the message "hellohello" in the PDU mode from a Nokia
6110.
AT+CMGF=0 //Set PDU mode AT+CSMS=0 //Check if modem supports SMS commands
AT+CMGS=23 //Send message, 23 octets (excluding the two initial zeros)
>0011000B916407281553F80000AA0AE8329BFD4697D9EC37There are 23 octets in this
message (46 'characters'). The first octet ("00") doesn't count, it is only an indicator of the length of
the SMSC information supplied (0). The PDU string consists of the following:
Octet(s)
00
Description
Length of SMSC information. Here the length is 0, which means that the
SMSC stored in the phone should be used. Note: This octet is optional. On
some phones this octet should be omitted! (Using the SMSC stored in phone
is thus implicit)
11
First octet of the SMS-SUBMIT message.
00
TP-Message-Reference. The "00" value here lets the phone set the
message reference number itself.
0B
Address-Length. Length of phone number (11)
91
Type-of-Address. (91 indicates international format of the phone number).
6407281553F8
The phone number in semi octets (46708251358). The length of the
phone number is odd (11), therefore a trailing F has been added, as if the
phone number were "46708251358F". Using the unknown format (i.e. the
Type-of-Address 81 instead of 91) would yield the phone number octet
sequence 7080523185 (0708251358). Note that this has the length 10 (A),
which is even.
00
TP-PID. Protocol identifier
TP-DCS. Data coding scheme.This message is coded according to the 7bit
00
AA
default alphabet. Having "02" instead of "00" here, would indicate that the
TP-User-Data field of this message should be interpreted as 8bit rather than
7bit (used in e.g. smart messaging, OTA provisioning etc).
TP-Validity-Period. "AA" means 4 days. Note: This octet is optional, see
bits 4 and 3 of the first octet
TP-User-Data-Length. Length of message. The TP-DCS field indicated
0A
E8329BFD4697D9EC3 7
7-bit data, so the length here is the number of septets (10). If the TP-DCS
field were set to 8-bit data or Unicode, the length would be the number of
octets.
TP-User-Data. These octets represent the message "hellohello". How to do
the transformation from 7bit septets into octets is shown here
Introduction to SMS Text Mode
The Short Message Service SMS, as defined within the GSM 900 / 1800 / 1900 digital mobile
phone standard has several unique features:
A single short message can be up to 160 characters ( 7bit coded ) or 140 characters (8 bit coded) of
text in length. Those 140 / 160 characters can comprise of words or numbers or an alphanumeric
combination. Non-text based short messages (for example, in binary format) are also supported.
More about that binary mode you will find at the link PDU mode.
The Short Message Service is a store and forward service, in other words, short messages are not
sent directly from sender to recipient, but always via an SMS Center (SMSC) instead. Each
mobile telephone network that supports SMS has one or more messaging centers to handle and
manage the short messages. More about SMSC you can read at the link SMSC.
The Short Message Service 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. The default factory parameter of this acknowledge from
the transmitter of a SMS to the receiver of a message by most GSM modem is OFF, so that you
will get no confirmation from the receiver. If you turn it on. then you get an conformation that the
SMSC has got the message and after the delivery of the short message to the receiver you will get
an additional, second messsage (SMS backward) that the message is delivered to the a GSM phone
or modem. In this automatic generated message is the data and time of the delivery coded. The
acknowlege, the coding scheme the time of storage of a short message in the SMSC and a lot of
more will be set with the command AT+CSMP.
A other way is to send a prefix with the text message. This prefixes are not equal by the different
GSM opertors in the world. By the German GSM operator Vodafone you have to add *N# and by
the GSM operator T-Mobil you have to add *T#. The notation with AT+CSMP is equal in all SMSC.
The handling with the pefix *T# or *N# was or is neccary if you would like to get a acknowlege by
the send of a SMS with a mobile GSM handset. Not all mobile phones can switch on the bit for a
ackknowlege.
If you would like to understand the 3 parameters of this command, you have to understand the
SMS in PDU mode. An other important command is AT+CNMI. It tells the GSM modem how to
handle an incoming short message.
Short messages can be sent and received simultaneously with GSM 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. If you switch on the simultaneously receive of a SMS during a data call, then
you will get a SMS string during a fax or data call.
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. Not
all that possible featurs are implemeted by all GSM operatos worldwide. Single message should
work everywhere.
To use the Short Message Service, users need the relevant
specifically:
subscriptions and hardware,
A subscription to a mobile telephone network that supports SMS. By the German GSM operators is
that serive by every different kind of subscription included.
Use of SMS must be enabled for that user (automatic access to the SMS
is given by some mobile
network operators, others charge a monthly subscription and require a specific opt-in to use the
service). In Germany that is everytime included.
A mobile phone or GSM modem that supports SMS. Today this is supported by every GSM phone
or GSM modem.
Knowledge of how to send or read a short message using their specific model of mobile phone or
GSM modem. The implementateion is not equal by evwery unit. Not all GSM phones, PCMIA
modem cards or GSM modems offers all the features that are descriped in the ETSI.
A destination to send a short message to, or receive a message from. This is usually another mobile
phone but may be a fax machine or an Email address. In some GSM networks it is possible to
covert a short message to a fax or to an email.
SMS Packet Format
1. Introduction
To use the SMS you have to declare the number of the Short Message Service Centre (SMSC[1]) in
the Mobile Station (MS), provided that the MS supports Short Message Service-Mobile Orginated
(SMS-MO).
The M20 Terminal supports SMS-MO.
Network
SMSC-number (Australia)
Telstra
61418706700
Optus
Vodafone
61411990000
61415011501
At the M20 Terminal you enter the SMSC-number with the AT+Celular command:
at+csca = ”<SMSC-number>”
If the receiver of the SMS possesses a Telstra SIM card, the AT command has to be entered in the
following way:
at+csca = "+61418706700"
With the command
at+csca?
you can question the current SMSC-number.
Ask your network operator for the right SMSC-number !!
! Notice: In addition to the AT+CSCA command it is possible to enter the SMSC-number in front of
the Protocol Data Unit (PDU). Refer to section 3.1 for details!
-------------------------------------------------------------------------------2. Overview:
MS: Mobile Station
SME: Short Message Entity
SMSC: Short Message Service Centre
MMI: Man Machine Interface
PDUs: Protocol Data Units
SM-AL: Short Message Aplication Layer
SM-TL: Short Message Transport Layer
SM-RL: Short Message Relay Layer
SM-LL: Short Message Link Layer
The MMI is based on the command set of AT+Cellular, and could be realized by means of a
terminal (for example Win-Terminal, HyperTerminal, etc) or the display of a handy.
The SM-TL provides a service to the Short Message Application Layer. This service enables the
SM-AL to transfer short messages to its peer entity, receive short messages from its peer entity and
receive reports about earlier requests for short messages to be transferred. The SM-TL
communicates with its peer entity with six several PDUs (Protocol Data Units):
·
SMS-DELIVER, conveying a short message from the SMSC to the MS
·
SMS-DELIVER-REPORT, conveying a failure cause (if necessary)
·
SMS-SUBMIT, conveying a short message from the MS to the SMSC
·
SMS-SUBMIT-REPORT, conveying a failure cause (if necessary)
·
SMS-STATUS-REPORT, conveying a status report from the SMSC to the MS
·
SMS-COMMAND, conveying a command from the MS to the SMSC
The M20 Terminal supports the SMS-DELIVER and SMS-SUBMIT PDUs as described in the
following sections.
2.1 SMS-DELIVER (Mobile Terminated)
MTI
bit 1 = 0
bit 0 = 0
2.2 SMS-SUBMIT (Mobile Originated)
MTI
bit 1 = 0
bit 0 = 1
! Notice: Any unused bits will be set to zero by the sending entity and will be ignored by the
receiving entity !
SCA
Service Centre Address – information element
Telephone number of the Service Centre
PDU Type
Protocol Data Unit Type
MR
Message Reference
Sucessive number (0..255) of all SMS-SUBMIT Frames set by the M20
OA
Originator Address
Address of the originating SME
DA
Destination Address
Address of the destination SME
PID
Protocol Identifier
Parameter showing the SMSC how to process the SM (as FAX, Voice etc)
DCS
Data Coding Scheme
Parameter identifying the coding scheme within the User Data (UD)
SCTS
Service Centre Time Stamp
Parameter identifying time when the SMSC received the message
VP
Validity Period
Parameter identifying the time from where the message is no longer valid in the SMSC
UDL
User Data Length
Parameter indicating the length of the UD-field
UD
User Data
Data of the SM
RP
Reply Path
Parameter indicating that Reply Path exists
UDHI
User Data Header Indicator
Parameter indicating that the UD field contains a header
SRI
Status Report Indication
Parameter indicating if the SME has requested a status report
SRR
Status Report Request
Parameter indicating if the MS has requested a status report
VPF
Validity Period Format
Parameter indicating whether or not the VP field is present
MMS
More Messages to Send
Parameter indicating whether or not there are more messages to send
RD
Reject Duplicate
MTI
Message Type Indicator
Parameter describing the message type
00 means SMS-DELIVER
01 means SMS-SUBMIT
-------------------------------------------------------------------------------3. Parameter description
3.1 Service Centre address information element (SCA info element)
len:
The octet ”len” contains the number of octets required for the number of the Service Centre plus the
1 byte “type of number“.
type of number:
81H: the following number is national
91H: the following number international
(For further information see GSM 04.08 chapter 10.5.4.6)
octet:
One octet includes two BCD-digit Fields. If the called party BCD number contains an odd number
of digits, the last digit shall be filled with an end mark coded as ”FH”.
Example:
if you have the SC-number +61418706700 you have to type:
07911614786007F0
! Notice: If the “len“ field is set to Zero the M20 Terminal takes the default value of the Service
Centre address set by the AT+CSCA command!
3.2 Protocol Data Unit Type (PDU Type)
SMS-SUBMIT:
SMS-DELIVER:
! Notice: you have to write the PDU-type in Hex-Format, a possible example is ”11H” !
RP:
0
1
UDHI:
1
message
Reply Path parameter is not set in this PDU
Reply Path parameter is set in this PDU
0
The UD field contains only the short message
The beginning of the UD field contains a header in addition of the short
SRI: (is only set by the SMSC)
0
A status report will not be returned to the SME
1
A status report will be returned to the SME
SRR:
0
1
VPF:
A status report is not requested
A status report is requested
bit4
bit3
0
0
VP field is not present
0
1
Reserved
1
0
VP field present an integer represented (relative)
1
1
VP field present an semi-octet represented (absolute)
any reserved values may be rejected by the SMSC
MMS: (is only set by the SMSC)
0
More messages are waiting for the MS in the SMSC
1
No more messages are waiting for the MS in the SMSC
RD:
0
Instruct the SMSC to accept an SMS-SUBMIT for an short message still
held in the SMSC which has the same MR and DA as a previously
submitted short message from the same OA.
1
Instruct the SMSC to reject an SMS-SUBMIT for a short message still
held in the SMSC which has the same MR and DA as a previously
submitted short message from the same OA.
MTI:
bit1
0
0
by
bit0
Message type
0
0
SMS-DELIVER (SMSC ==> MS)
SMS-DELIVER REPORT (MS ==> SMSC, is generated automatically
the M20, after receiving a SMS-DELIVER)
0
1
SMS-SUBMIT (MS ==> SMSC)
0
1
SMS-SUBMIT REPORT (SMSC ==> MS)
1
0
SMS-STATUS REPORT (SMSC ==> MS)
1
0
SMS-COMMAND (MS ==> SMSC)
1
1
Reserved
(The fat-marked lines represent the features supported by the M20 Terminal)
! Notice: not every PDU Type is supported by the Service Centre !
3.3 Message Reference (MR)
The MR field gives an integer (0..255) representation of a reference number of the SMS-SUBMIT
submitted to the SMSC by the MS.
! Notice: at the M20 Terminal the MR is generated automatically, -anyway you have to generate it a possible entry is for example ”00H” !
3.4 Originator Address (OA) Destination Address (DA)
OA and DA have the same format explained in the following lines:
len:
The octet ”len” contains the number of BCD digits
type of number:
81H: the following number is national
91H: the following number international
(For further information see GSM 04.08 chapter 10.5.4.6)
BCD-digits:
The BCD-digit Field contains the BCD-number of the Destination e.g. the Originator.
If the called party BCD number contains an odd number of digits, the last digit shall be filled with
an end mark coded as ”FH”.
Example:
if you have the national number 1234567 you have to type:
0781214365F7
3.5 Protocol Identifier (PID)
The PID is the information element by which the Transport Layer either refers to the higher layer
protocol being used, or indicates interworking with a certain type of telematic device.
Here are some examples of PID codings:
00H: The PDU has to be treat as a short message
01H: The PDU has to be treat as a telex
02H: The PDU has to be treat as group3 telefax
03H: The PDU has to be treat as group4 telefax
(For further information see GSM 03.40 chapter 9.2.3.9)
! Notice: it is not guaranteed that the SMSC supports every PID codings!
3.6 Data Coding Scheme (DCS)
The DCS field indicates the data coding scheme of the UD (User Data) field, and may indicate a
message class. The octet is used according to a coding group which is indicated in bits 7..4. The
octet is then coded as follows:
Coding group:
Bits 7..4
bits 3..0
0000
Alphabet indication
Unspecified message handling at the MS
0000
0001-1111
Default alphabet (7 bit data coding in the User Data)
reserved
0001-1110
Reserved coding groups
1111
Data Coding/message class
bit 3 is reserved, set 0
bit 2
(message coding)
0
Default alphabet (7 bit data coding in the User Data)
1
8-bit data coding in the User Data
bit 1 bit 0 (message class)
0
0
Class0 immediate display
0
1
Class1 ME (Mobile Equipment)- specific
1
0
Class2 SIM specific message
1
1
Class3 TE (Terminate Equipment)- specific
Default alphabet indicates that the UD (User Data) is coded from the 7-bit alphabet given in
appendix A. When this alphabet is used, eight characters of the message are packed in seven octets,
and the message can consist of up to 160 characters (instead of 140 characters in 8-bit data coding)
In 8-bit data coding, you can relate to the INTEL ASCII-HEX table.
In Class 0 (immediate display) the short message is written directly in the display, as the M20
Terminal has no display the Class 0 message can be realised only in a roundabout way.
In Class 1 to Class 3 the short message is stored in the several equipments ME, SIM-card and TE.
In time the Class 2 is supported, if you choose Class 1 or Class 3 the short message is treated the
same way as a Class 2 message.
! Note: It is recommended to use the Class2 message, or the coding group ”0000 bin” !
3.7 Service Centre Time Stamp (SCTS)
The SCTS is the information element by which the SMSC informs the recipient MS about the time
of arrival of the short message at the Transport Layer entity of the SMSC. The time value is
included in every SMS-DELIVER being delivered to the SMSC, and represents the local time in the
following way:
The Time Zone indicates the difference, expressed in quarters of an hour, between the local time
and GMT (Greenwich Main Time).
3.8 Validity Period (VP)
The Validity-Period is the information element which gives an MS submitting an SMS-SUBMIT to
the SMSC the possibility to include a specific time period value in the short message. The Validity
Period parameter value indicates the time period for which the short message is valid, i.e. for how
long the SMSC shall guarantee its existence in the SMSC memory before delivery to the recipient
has been carried out.
The VP field is given in either integer or semi-octet representation. In the first case, the VP
comprises 1 octet, giving the length of the validity period, counted from when the SMS-SUBMIT is
received by the SMSC. In the second case, the VP comprises 7 octets, giving the absolute time of
the vality period termination. In the first case, the representation of time is as follows:
VP Value
Validity period value
0-143
(VP + 1) x 5 minutes (i.e 5 minutes intervals up to 12 hours)
144-167
12 hours + ((VP-143) x 30 minutes)
168-196
(VP-166) x 1 day
197-255
(VP - 192) x 1 week
In the second case, the representation of time is identical to the representation or the SCTS (Service
Centre Time Stamp).
The case of representation is set in the VPF (Validity Period Format) in the PDU-type.
3.9 User Data Length (UDL) and User Data (UD)
The UDL field gives an integer representation of the number of characters within the User Data
field to follow.
--------------------------------------------------------------------------------
4. PDU Examples
here are two examples of how to send a short message with AT+Cellular (refer to Appendix B for
more details on how to send the SMS messages):
First enter PIN-number and the Service Centre Address:
at+cpin="XXXX"
enter the PIN-number
OK
at+csca="+61418706700"
Service-Centre-Address (Telstra)
enter the
OK
1st example:
at+cmgs=18
enter ”send message”, 18 is the actual length of the PDU
message in octet
> 0011000A81409079344400000105E8329BFD06 type the PDU (SMS-SUBMIT) and finish
with ”ctrl Z” the thin-typed characters are the Destination Address e.g. the own
tel.-number(0409974344) the Service Centre address is the same as set via at+csca command
+CMGS: 0
OK
at+cpms?
are messages stored on the SIM-Card?
+CPMS: "SM" , 1 , 7 , "SM" , 1 , 7
on this SIM-Card
is 1 message stored
OK
you can store at most 7 messages
at+cmgr=1
read stored message in location 1
+CMGR: 0,,24
07911614786007F0040B911604994743F400009930139100406B05E8329BFD06
PDU (SMSOK
-DELIVER) sent by the
Service Centre
2nd example:
at+cmgw=18
write message in the memory of the SIM-card
This is a
> 07911614786007F011000781409079344400F6AA0568656C6C6F type the PDU
(SMS-SUBMIT) and finish with ”ctrl Z” the thin-typed characters are the Destination Address e.g.
the own tel.-number (0409974344). The Service Centre Address is „+61418706700“
+CMGW: 2
OK
at+cmgr=2
read stored message in location 2
+CMGR: 2,,18
07911614786007F011000A81407008090500F6010568656C6C6F
location 2
this is the PDU stored in
OK
at+cmss=2
send the message stored in location 2
+CMSS: 3
OK
at+cmss=2,“0407485455“,129
send the
message stored in location 2 to the national (129 = 81H) destination address „0407485455“
at+cmss=2,“+61419877302“,145
send the
message stored in location 2 to the international (145 = 91H) destination address „+61419877302“
at+cpms?
are messages stored on the SIM-Card?
+CPMS: "SM" , 3 , 7 , "SM" , 3 , 7
are 3 message stored
on this SIM-Card
OK
you can store at most 7 messages
at+cmgr=3
read stored message in location 3
+CMGR: 0,,24
07911614786007F0040B911604994743F400009930139100406B05E8329BFD06
PDU (SMSOK
-DELIVER) sent by the
Service Centre
-------------------------------------------------------------------------------Appendix
Appendix A - Default Alphabet
This is a
b7
0
0
0
0
1
1
1
1
b6
0
0
1
1
0
0
1
1
b5
0
1
0
2
0
1
0
1
0
1
2
3
4
5
6
7
SP
0
!
1
A
Q
A
q
2
B
R
B
r
b4
b3
b2
b1
0
0
0
0
0
0
0
0
1
1
0
0
1
0
2
0
0
1
1
3
3
C
S
C
s
0
1
0
0
4
4
D
T
D
t
0
1
0
1
5
%
5
E
U
E
u
0
1
1
0
6
&
6
F
V
F
v
0
1
1
1
7
‘
7
G
W
G
w
1
0
0
0
8
(
8
H
X
H
x
1
0
0
1
9
)
9
I
Y
I
y
1
0
1
0
10
*
:
J
Z
J
z
1
0
1
1
11
+
;
K
Ä
K
ä
1
1
0
0
12
,
<
L
Ö
L
ö
1
1
0
1
13
-
=
M
1
1
1
0
14
.
>
N
1
1
1
1
15
/
?
O
@
$
LF
CR
ß
abbreviations:
MS
SME
SMSC
Mobile Station
Short Message Entity
Short Message Service Centre
MMI
Man Machine Interface
PDUs
Protocol Data Units
SM-AL
Short Message Aplication
SM-TL
Short Message Transport
SM-RL
Short Message Relay Layer
Layer
Layer
P
p
M
Ü
N
O
ü
SM-LL
Short Message Link Layer
PDU Type Protocol Data Unit Type
MR
Message Reference
OA
Originator Address
DA
Destination Address
PID
Protocol Identifier
DCS
Data Coding Scheme
SCTS
VP
UDL
Service Centre Time Stamp
Validity Period
User Data Length
UD
User Data
RP
Reply Path
UDHI
User Data Header Indicator
SRI
Status Report Indication
SRR
Status Report Request
VPF
Validity Period Format
MMS
More Messages to Send
RD
Reject Duplicate
MTI
Message Type Indicator
ME
Mobile Equipment
TE
Terminal Equipment
SIM
Subscriber Identity Modul
error codes:
0
phone failure
1
no connection to phone
2
Phone-adaptor link reserved
3
operation not allowed
4
operation not supported
5
PH-SIM PIN necessary
10
SIM not inserted
11
SIM PIN required
12
SIM PUK required
13
SIM failure
14
SIM busy
15
SIM wrong
16
incorrect password
20
memory full
21
invalid index
22
not found
23
memory failure
24
text string too long (+CPBW)
25
invalid characters in text string
26
dial string to long
27
invalid characters in dial string
30
no network service
31
network timeout
100
unknown
265
PUK for theft protection necessary
266
PUK2 for SIM necessary
267
PIN2 for SIM necessary
Appendix B- SMS set up for the M20 Terminal
This document describes the process of sending SMS messages between a mobile phone and the
M20 Terminal. The mobile phone referred to in this document is the Ericsson GH688. However,
SMS message can be sent out or received in a similar fashion using other mobile phones.
Hardware Requirements
The following items are needed.
1.
A mobile phone that is capable of sending and receiving SMS messages
2.
A M20 Terminal
3.
Two SIM cards (one for the mobile phone and the other for the M20 Terminal)
4.
5.
6.
7.
A GSM antenna
A power cable for the M20 Terminal
A RS-232 cable
A PC running on Windows Terminal, HyperTerminal or equivalent.
Hardware Set Up
1.
Mobile Phone Set Up
Insert a SIM card into the mobile phone and turn the phone on. The phone is now ready for sending
and receiving SMS. Note that you need the phone number for SMS messages.
2.
M20 Terminal Set Up
Connect the M20 Terminal to a PC as shown in Figure 1. Then do the following:
1.
Turn on the PC and run Windows Terminal, or HyperTerminal.
2.
Connect the M20 Terminal to COM1 or COM2 of the PC.
3.
Insert a SIM card into the M20 Terminal and turn the M20 Terminal on.
4.
In Windows Terminal, select [Communications] from [Settings] and set the M20 Terminal
to the parameters in Table 1.
Table 1: Communications Settings
Baud Rate
19200 bps
Data Bits
8
Stop Bits
1
Parity
None
Flow Control
Hardware
Connector
COM1 or COM2
5.
Reset the M20 Terminal to factory default using AT&F, and hence configure the M20
Terminal for SMS using the following AT commands.
a)
AT+CMGF=0[ENTER][2]
M20 Terminal to PDU mode
AT+CMGF=1[ENTER]
Terminal to text mode[3]
b)
Set the
Set the M20
AT+CSCA=”+61418706700”[ENTER] Enter the SMS Centre Address
Note that the Service Centre Address only needs to be entered once for all SMS.
Figure 1: M20 Terminal Set Up
Sending a SMS Message
1)
Phone initiated SMS Message
A mobile phone that is capable of sending and receiving SMS messages can be used to send a SMS
message to the M20 Terminal. Note that the SIM card for the mobile phone must be on the same
network as the SIM card in the M20 Terminal for SMS messages. eg. both SIM cards must be
Telstra, or Optus.
To send a SMS message to the M20 Terminal, select [Send Messages] from the [Mail] menu and
then select [New]. Enter your text and when you have finished press the “YES” button. You will
then need to enter the destination number for the SMS message. This is the phone number on the
SIM card used by the M20 Terminal[4].
2)
M20 Terminal initiated SMS Message
a)
Send a PDU SMS
In PDU mode, to send a message like the word “hello”, initially, you have to convert it to a PDU
format message. Refer to section 3 (Parameter description) for details on how to construct the PDU
message. Note that the actual length of the PDU string (without the Service Centre Address) must
be specified for all SMS. Follow the steps below for sending the SMS message.
Step 1.
Enter the actual length of the SMS message in octets[5]
AT+CMGS=18[6]
Step 2.
Enter the SMS message in PDU format and terminate it with “CTRL Z”
>0011000A81409178699100000105E8329BFD06[CTRL Z]
The M20 Terminal should return
+CMGS: 12
OK
where 12 is the message reference MR, which is different for every SMS message sent.
b)
Send a text SMS
In text mode, to send a message, eg. “hello”, follow the three steps below.
Step 1:
Set the M20 Terminal for text SMS using
AT+CMGF=1[ENTER]
Step 2:
Enter the destination phone number in international format[7]
AT+CMGS=”+61419879619”[ENTER]
Step 3:
Enter the text message and terminate it with “CTRL Z”
>hello[CTRL Z]
The M20 Terminal should return
+CMGS: 1
OK
where 1 is the message reference MR, which is different for every SMS message sent.
Receiving/Reading/Deleting a SMS Message
1)
Mobile Phone
When there is a new SMS message arrived, the phone will beep and the SMS message indicator will
appear on the phone screen.
To read the SMS message, select [Read Messages] from the [Mail] menu using the left or right
arrow button and the new message is usually shown first. Press the “YES” button to read the
message. The message can be deleted using the “CLR” button.
2)
M20 Terminal
a)
Read a PDU SMS
In PDU mode, when the M20 Terminal receives a SMS message, the following message will appear
on the PC screen.
+CMTI: “SM”, 1
where 1 is the memory location in which the message can be read from.
To read a SMS message from a particular location in memory (eg. location 1) use the AT+CGMR
command as follow.
AT+CMGR=1[ENTER]
The M20 Terminal should return the PDU message as follow.
+CMGR: 0,,24
07911614786007F0040B911604994743F400009930139100406B05E8329BFD06
OK
where 0 is the status code indicating a received and already read message, 24 is the hexadecimal
number indicating the length of the message.
b)
Read a text SMS
Like PDU mode, when the M20 Terminal receives a SMS message, the following message will
appear on the PC screen.
+CMTI: “SM”, 1
where 1 is the memory location in which the message can be read from.
To read the SMS message use the AT+CGMR command as follow.
AT+CMGR=1[ENTER]
The M20 Terminal should return the text message as follow.
+CMGR: “REC READ”,“+61407809050”,“98/12/01,20:16:11+44”
hello
OK
c)
Delete a SMS message
The SMS message can be deleted from memory (eg. location 1) using the AT+CMGD command as
follow. Note that there is no AT command to delete all the SMS messages at once.
AT+CMGD=1[ENTER]
The M20 Terminal should return OK.
TELOCATOR ALPHANUMERIC PROTOCOL (TAP)
I Introduction
In order to decrease holding times on input lines to alphanumeric systems, it was desirable to
promote input devices which will allow off-line entry of paging information and dump this data
quickly after connection to the central paging terminal. This protocol was known as the IXO
alphanumeric protocol until it was adopted for the input of paging requests. It is now referred to as
the Telocator Alphanumeric Protocol (TAP).
Table 1. Call Delivery Sequence
| REM. ENTRY DEV. DOES | PAGING CENTRAL DOES | COMMENTS
|
+---+----------------------+----------------------+----------------------+
| 1 | Off hook-access DDD |
|
|
|
| line.
|
|
|
|
| Await dial tone.
|
|
|
|
| Dial stored access
|
|
|
|
| number
| Ring Answer
|
|
+---+----------------------+----------------------+----------------------+
| 2 | Carrier up
| Carrier up
|
|
+---+----------------------+----------------------+----------------------+
| 3 | "<CR>" [1]
|
| <CR> is repeated at |
|
|
|
| two second intervals |
|
|
|
| until paging central |
|
|
|
| responds with ID= at |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
correct baud rate or
until three transmissions have been
completed. (This
step exists to allow
for possible future
baud rate recognition).
Some systems have
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
chosen to send ID=
from the central if
they do not receive
<CR> in about two
seconds. This variation appears to be
acceptable as the
central continues to
respond to <CR>s
with ID= s.
|
|
|
|
|
|
|
|
|
|
+---+----------------------+----------------------+----------------------+
| 4 |
| "ID= "
| Request for ID re|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
turned within one
|
second of receipt of |
<CR>. Paging central |
may, at its option, |
send <CR> or <CR><LF>|
after ID=.
|
|
Paging central may
|
optionally choose to |
send ID= if it does |
|
|
|
|
|
|
|
|
|
| not receive <CR>
|
| after an appropriate |
| waiting time.
|
+---+----------------------+----------------------+----------------------+
[1] All quotation marks or the symbols <> shown are used for notation and are not transmitted.
Two options exist at this point:
 Automatic Mode (see section 5A)

Manual Mode (see section 5M)
| REM. ENTRY DEV. DOES | PAGING CENTRAL DOES | COMMENTS
|
+---+----------------------+----------------------+----------------------+
| 5A| For automatic remote |
| <ESC> signifies
|
|
| entry devices.
|
| entry device intends |
|
|
|
| to talk in automatic |
|
| "<ESC>SST"
|
| dump mode. SS is a
|
|
|
|
| set of two alpha|
|
| Typical Example:
|
| numeric characters
|
|
|
|
|
|
|
|
|
|
|
| "<ESC>PG1"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
signifying a type of |
service to be ac|
cessed.
|
|
For a paging service |
where:
|
Field 1 = 'Pager ID' |
and
|
Field 2 = 'Message'. |
|
|
|
|
|
|
|
| SS will be sent as
| 'PG'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Where T is a single |
alphanumeric char|
acter relate to the |
type of terminal or |
device attempting to |
send the message.
|
|
T = '1' is a cate|
gory using the same |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
protocol. The PETs
and IXO devices are
members of this
category.
T = '7,8,9' are reserved for wild card
terminals or devices
which may relate to
a specific users'
|
|
|
|
|
|
|
|
|
|
|
|
| system.
|
+---+----------------------+----------------------+----------------------+
| 6 | "PPPPPP<CR>"
|
| This 6-character
|
|
|
|
| alphanumeric pass|
|
| GL-3000 will ignore |
| word comes from
|
|
| password
|
| automatic terminals. |
|
|
|
| (Password is optional|
|
| Typical password for |
| and is, in general, |
|
| IXO is "000000"
|
| reserved for future |
|
|
|
| services. Password
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
may be interpreted
as either a caller
ID or a system entry
key. Length of password, when used, may
be different in some
systems.)
When an incorrect
logon sequence
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| beginning with <ESC> |
| is received, the
|
|
|
|
| paging central may
|
|
|
|
| respond with an ID= |
|
|
|
| if it requires a
|
|
|
|
| retransmission.
|
+---+----------------------+----------------------+----------------------+
|
|
| "Message sequence
| Logon accepted
|
|
|
| <CR><ACK><CR>"
|
|
|
|
|
|
|
|
|
| or
| or
|
|
|
|
|
|
|
|
| "Message sequence
| Requested again
|
|
|
| <CR><NAK><CR>"
|
|
|
|
|
|
|
|
|
| or
| or
|
|
|
|
|
|
|
|
| "Message sequence
| Forced disconnect
|
|
|
| <CR><ESC><EOT><CR>" |
|
+---+----------------------+----------------------+----------------------+
* GL-3000 Typical Message Sequence: "Processing - Please Wait" or
"4 pages sent"
or
"Bad Phone Line Call Again".
+----------------------+----------------------+----------------------+
| REMOTE ENTRY
| PAGING CENTRAL DOES | COMMENTS
|
+---+----------------------+----------------------+----------------------+
|
|
|
| A message sequence
|
|
|
|
| is defined as a
|
|
|
|
| series of short
|
|
|
|
| messages separated
|
|
|
|
| by <CR>s. A <CR>
|
|
|
|
| always follows a
|
|
|
|
| message sequence.
|
|
|
|
| Message sequences
|
|
|
|
| are totally optional.|
+---+----------------------+----------------------+----------------------+
| 6a|
| Optional message
| Central may insert
|
|
|
| sequence <CR>
| short message
|
|
|
|
| sequence between
|
|
|
|
| steps 6 and 7.
|
+---+----------------------+----------------------+----------------------+
| 7 |
|
|
| "<ESC> [p <CR>"
|
| Message go ahead is
| sent when paging
|
|
|
|
|
| central is ready for |
|
|
|
| new information.
|
|
|
|
| The 'p' is in lower |
|
|
|
| case.
|
+---+----------------------+----------------------+----------------------+
| 8 | TRANSACTION #1
|
| A block is up to 256 |
|
|
: "<STX>
|
| characters in length,|
|
|
: FIELD #1 <CR> |
| with up to 250 char- |
|
| BLOCK: FIELD #2 <CR> |
| acters of info, plus |
|
| #1
:
|
| 3 control characters |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
:
:
:
:
FIELD #N <CR>
<ETX>
<CHECKSUM>
<CR>"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
and a 3 character
checksum. The block
carries one transaction (one set of
fields 1 through N)
or a portion of one
transaction. A block
may be less than 256
characters to
|
|
|
|
|
|
|
|
|
|
|
|
| accommodate short
|
|
|
|
| transactions.
|
+---+----------------------+----------------------+----------------------+
|
|
|
| A field may be any
|
|
|
|
| length and where
|
|
|
|
| necessary may be
|
|
|
|
| continued in
|
|
|
|
| following blocks.
|
|
|
|
| A field always ends |
|
|
|
| with a <CR>. The
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<CR> field delimiter
suggests <CR> may
not be used within a
field.
|
|
|
|
|
A block always
|
begins with an <STX> |
and ends with a
|
checksum followed by |
a <CR>. The char|
|
|
|
|
|
|
| acters preceding the |
| checksum depends on |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
what, if anything,
is continued beyond
the block boundary.
|
|
|
|
The <ETX> is used as |
a block termination |
indicator if a given |
transaction (fields |
1 through N) ends
|
within the block
|
|
|
|
| currently being
|
|
|
|
| transmitted.
|
+---+----------------------+----------------------+----------------------+
|
| TRANSACTION #2
|
| The <ETB> is used as |
|
|
: "<STX>
|
| a block terminator
|
|
|
: FIELD #1 <CR> |
| if the transaction
|
|
| BLOCK:
|
| is continued into
|
|
| #2
: FIELD #J <CR> |
| the next block, but |
|
|
: <ETB>
|
| the last field in
|
|
|
|
|
|
|
|
|
|
|
|
: <CHECKSUM>
|
|
: <CR>"
|
|
|
|
: "<STX>
|
|
: FIELD #J+1<CR>|
| BLOCK:
|
| #3
: FIELD #L <US> |
|
: <CHECKSUM>
|
|
: <CR>
|
|
|
|
|
|
|
|
|
|
|
|
|
the current block is |
complete.
|
|
If the last field
|
within the current
|
block is to be
|
continued in the
|
next block, no <CR> |
is inserted at the
|
end of the first
|
|
|
|
|
|
|
|
|
|
|
|
: "<STX>
|
: FIELD #L
|
: (CONTINUED)
|
: <CR>
| BLOCK:
| #4
: FIELD <CR>
|
: <ETX>
|
: <CHECKSUM>
|
: <CR>
|
|
|
|
|
|
|
|
|
|
|
portion of the field
and the <US> character is used as a
block termination
character. The <CR>
terminating the
broken field is sent
at the end of the
field in whatever
block the field
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| actually terminates. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
No limit is established within the
protocol itself
regarding the number
of transactions, the
number of fields or
the number of blocks
per field; however,
a particular user
system may have
|
|
|
|
|
|
|
|
|
|
|
|
| LAST TRANSACTION
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
limits on any of
these items.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Each checksum is
computed by performing the simple
arithmetic sum of
the 7-bit values of
all values of all
characters preceding
it in that block.
(This means that the
STX and ETB/ETX are
|
|
|
|
|
|
|
|
|
|
|
|
|
Some systems may be |
limited to one block |
per transaction and |
one transaction per |
telephone connection.|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| included in the sum).|
|
|
|
| The checksum is then |
|
|
|
| the least signifi|
|
|
|
| cant 12 bits of this |
|
|
|
| resulting sum.
|
+---+----------------------+----------------------+----------------------+
|
|
|
| The checksum is
|
|
|
|
| transmitted as three |
|
|
|
| printable ASCII
|
|
|
|
| characters having
|
|
|
|
|
|
|
| values between HEX
| 30 and HEX 3F (the
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
characters 012345678
9:;<=>?). The most
significant four
bits of the sum are
encoded as the 4 LSB
of the third charcter. See example.
: "<STX>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
: FIELD #1 <CR>
| LAST :
| BLOCK: FIELD #N <CR>
|
: <ETX>
|
: <CHECKSUM>
|
: <CR>"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fields only:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A normal paging sys- |
tem will have two
|
|
|
Field 1 = Pager ID
|
(normally up to
|
eight digits. May
|
include function and |
check digit).
|
|
Field 2 = Message
|
Field 1 or field 2
may be empty. For
example, when a page
is tone only, field
2 will be empty.
Even when empty, a
field is followed by
a <CR>. Some systems
will reject trans-
|
|
|
|
|
|
|
|
|
|
|
|
|
| actions which have
|
|
|
|
| an empty field 2 for |
|
|
|
| a display page or
|
|
|
|
| transactions which
|
|
|
|
| have an empty field |
|
|
|
| 1. Other systems are |
|
|
|
| less restrictive.
|
+---+----------------------+----------------------+----------------------+
|
|
|
| The response to each |
|
|
|
| block is one of four:|
|
|
|
|
|
| "Message sequence
|
|
| <ACK><CR> = OK, send |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
next block.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| <CR> <RS> <CR>"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
current transaction |
and go to next. <RS> |
may occur when the
|
checksum is OK, but |
the current trans|
action violates a
|
system rule. At the |
option of the system,|
it may occur in
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
other cases.
<CR> <ACK> <CR>"
or
"Message sequence
<CR> <NAK> <CR>"
or
"Message sequence
or
"Message sequence
<CR> <ESC> <EOT>
<CR>"
|
|
|
|
<NAK><CR> = checksum |
or transmission
|
error, send last
|
block again.
|
|
<RS><CR> = abandon
|
|
|
|
<ESC><EOT><CR> =
|
begin disconnect.
|
|
Any of the responses |
may have an optional |
message sequence
|
before them,
|
|
|
|
| although the system |
|
|
|
| designer should
|
|
|
|
| understand the con- |
|
|
|
| sequences to the
|
|
|
|
| user with all
|
|
|
|
| planned entry
|
|
|
|
| devices.
|
+---+----------------------+----------------------+----------------------+
|
|
|
| It is expected that |
|
|
|
| many systems will
|
|
|
|
|
|
|
| save their message
| sequence responses
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
until immediately
before disconnect.
For some entry
devices, it may also
be desirable that
messages describing
non-checksum errors
associated with a
particular transaction in a PG
|
|
|
| service will begin
|
|
|
|
| with the letter ID
|
|
|
|
| followed by the
|
|
|
|
| contents of field 1 |
|
|
|
| for that transaction.|
+---+----------------------+----------------------+----------------------+
| 9 | "<EOT> <CR>"
|
| After reception of
|
|
|
|
| an <ACK> or <RS> for |
|
|
|
| the last transaction |
|
|
|
| in a given service, |
|
|
|
| the entry device
|
|
|
|
| sends <EOT> <CR>
|
|
|
|
| meaning there are no |
|
|
|
| more transactions
|
|
|
|
| remaining in this
|
|
|
|
| service.
|
+---+----------------------+----------------------+----------------------+
|10a|
| "<Message sequence> | An optional message |
|
|
| <CR>"
| may be sent at this |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
point to indicate
the degree of acceptability of information in all transactions received
during the current
interchange.
Although optional,
this message is
highly desirable.
|
|
|
|
|
|
|
|
|
|
+---+----------------------+----------------------+----------------------+
|10b|
| "<RS> <CR>"
| An <RS> <CR> should |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
be sent at this
point if the paging
central finds any
data <ACK> in step 8
to be unacceptable
because of content
(e.g. an invalid
pager number or a
message field inappropriate for the
|
|
|
|
|
|
|
|
|
|
|
|
|
| type of pages, etc.) |
|
|
|
| [2]
|
+---+----------------------+----------------------+----------------------+
|10c|
| "<ESC> <EOT> <CR>"
| <ESC> <EOT> = begin |
|
|
|
| disconnect.
|
|
|
| followed by dropping |
|
|
|
| of carrier and
|
|
|
|
| hanging up.
|
|
+---+----------------------+----------------------+----------------------+
|11 | Drops carrier and
|
| hangs up.
|
|
|
|
|
|
+---+----------------------+----------------------+----------------------+
[2] It is desirable to catch all types of errors in step 8, but practically, some systems will be too slow
to catch content errors as they happen.
Table 1 (continued). Call Delivery Sequence. Manual Entry procedure.
| REM. ENTRY DEV. DOES | PAGING CENTRAL DOES | COMMENTS
|
+---+----------------------+----------------------+----------------------+
| 5M| (For manual remote
|
| Lack of <ESC> at
|
|
| entry as opposed to |
| at beginning of
|
|
| Automatic Entry
|
| response to ID=
|
|
| shown previously in |
| signifies manual
|
|
| this table under 5A) |
| operation where
|
|
|
|
| applicable.
|
|
| "M <CR>"
|
|
|
+---+----------------------+----------------------+----------------------+
|
|
| "Enter pager ID(s): | Any manual operation |
|
|
| (Tone only or
| is user defined
|
|
|
| voice)"
or | after logon.
|
+---+----------------------+----------------------+----------------------+
|
| e.g.
|
|
|
| "1000 2000 1247 400 |
|
|
| <CR>"
|
|
+---+----------------------+----------------------+
|
|
| "Enter Alphanumeric |
|
|
| message (alpha):" or |
|
|
| "Enter Numeric
|
|
|
| message (numeric):" |
+---+----------------------+----------------------+
|
| "Message <CR>"
|
|
Echo transmission is
allowed after manual
conversation is
established. M <CR>
can be replaced by
any non-null
sequence ending in
<CR> and not
beginning with
<ESC>.
+---+----------------------+----------------------+
|
|
| "Can't Deliver Page |
|
|
| ID xxxxxx"
or |
|
|
| "Too Slow - Good
|
|
|
| Bye" (40 second
|
|
|
| timeout)"
or |
|
|
| "Too Many Errors |
|
|
| Good Bye" (occurs if |
|
|
| 3 or more errors) or |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| "Page Blocked"
|
|
+-----+-----------------------------------+-----------------------------------+-----------------------------------+
II Modems
For initial implementation of the protocol, it is recommended that Bell 103 compatible modems be
used to receive at 300 baud. Additional speeds or modem types may be used if desired.
The standard practice will be ASCII with <XON>/<XOFF> either direction using a 10-bit code (1
start, 7 data, 1 parity, 1 stop) with even parity.
In the case of delays, the paging central shall wait at least four seconds (eight seconds in steps 3 and
4) before disconnecting the remote entry device; the remote entry device shall wait at least ten
seconds for a character from the central before hanging up.
The paging central may, at its option, send <CR><LF> in place of <CR> at the end of any
sequence.
For initial use of the protocol, the paging central shall be equipped to receive full duplex using a
Bell 103 compatible modem at 300 baud. Optionally, certain inputs may be capable of receiving 110
baud Bell 103 full duplex, 300/1200 baud Bell 212 full duplex. No echo shall be employed in full
duplex mode. Any attempts at automatic baud rate determination shall be within the restraints of the
specified protocol.
Example:
Leaving a message TEST for customer #1 Data: 7 Bits/1 Stop Bit/No Even Parity
USER
GL-3000
<CR> every 1 second unit ...
ID=
<ESC>PG1<CR>
<ESC>[p<CR>
<STX>1<CR>TEST<CR><ETX>190<CR>
("TEST" is the message)
Processing - Please Wait<CR><ACK><CR>
("190" is the Checksum)
+++,,,,,,,,,,ATH0<CR>
Carrier Drop
III
Telocator Protocol (TAP) Checksum Example
The following table shows an example of a complete block containing a correct checksum which is:
<STX>123<CR>ABC<CR><ETX>17;<CR>
+---------+---------+---------+
| STX
*|
000 *|
0010 *|
|
1
|
011 *|
0001 |
|
2
|
011 *|
0010 *|
|
3
*|
011 |
0011 *|
| CR
*|
000 *|
1101 *|
|
A
*|
100 |
0001 *|
|
B
*|
100 *|
0010 *|
|
C
*|
100 *|
0011 *|
| CR
|
000 *|
1101 *|
| ETX
*|
000 *|
0011 *|
|
*+---------+---------+
|
*| 1 0111 |
1011 |
|
*| 1
7
|
; *|
+---------+---------+---------+
Checksum = 17;
ASCII control characters
+---------------------------------+----------------------------------+
| 00
| 01
| 02
| 03
| 04
| 05
| 06
| 07
| 08
00
01
02
03
04
05
06
07
08
<NUL> | 16
<SOH> | 17
<STX> | 18
<ETX> | 19
<EOT> | 20
<ENQ> | 21
<ACK> | 22
<BEL> | 23
<BS> | 24
10
11
12
13
14
15
16
17
18
<DLE> |
<XON> |
<DC2> |
<XOFF>|
<DC4> |
<NAK> |
<SYN> |
<ETB> |
<CAN> |
| 09
09
<HT> | 25
19
<EM> |
| 10
0A
<LF> | 26
1A
<SUB> |
| 11
0B
<VT> | 27
1B
<ESC> |
| 12
0C
<FF> | 28
1C
<FS> |
| 13
0D
<CR> | 29
1D
<GS> |
| 14
0E
<SO> | 30
1E
<RS> |
| 15
0F
<SI>
| 31
1F
<US> |
+--------------------------------+----------------------------------+
SMS Frequently Asked Questions
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?
Other uses for SMS are:
 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.
Glossary of SMS/GSM related terms
Air Interface
The standard operating system of a wireless network. Air interface technologies include: AMPS,
TDMA, CDMA and GSM.
AMPS- (Advanced Mobile Phone Service)
An analog cellular radio standard that serves as the foundation for the U.S. cellular industry. AMPS
represents the first generation of wireless networks.
Analog
The traditional method of modulating radio signals. Most U.S. cellular phones use analog but are
migrating to digital technologies. AM (amplitude modulation) and FM (frequency modulation) are
the two most common methods of analog modulation.
API- (Application Program Interface)
A language and message format used by an application program to communicate with the operating
system or some other system or control program such as a database management system (DBMS) or
communications protocol. APIs are implemented by writing function calls in the program, which
provide the linkage to the required subroutine for execution. Thus, an API implies that a program
module is available in the computer to perform the operation or that it must be linked into the
existing program to perform the tasks.
ASP- (Application Service Provider)
An organization that hosts software applications on its own servers within its own facilities.
Customers access the application via private lines or the Internet. ASP is also called a "commercial
service provider."
CDMA- (Code Division Multiple Access)
An air interface technology that was developed by the U.S. military and commercialized by the U.S.
company Qualcomm. CDMA supports SMS with a message length of 120 characters. With CDMA,
each conversation is digitized and then tagged with a code. The mobile phone receives a signal to
locate that particular code and it then deciphers the conversation off the airwaves. It codes each
conversation expanding it 128 times, making it easy to decipher at the receiving end.
CDMA2000
3G CDMA evolution from cdmaONE supported by cdmaONE operators. Phase 1 provides 144
Kbps data rate and Phase 2 up to 2 Mbps. See Third Generation.
CDMAONE
The name used by the CDMA Development Group (CDG) for CDMA networks (IS-95) using
2nd-generation digital technology.
CDPD- (Cellular Digital Packet Data)
An enhanced packet overlay on analog cell phone networks used to transmit and receive data. This
technology allows data files to be broken into a number of packets and sent along idle channels of
existing cellular voice networks. CDPD provides 19.2 Kbps and is deployed by AT&T among
several other carriers.
Coverage
Refers to the region within which a paging receiver can reliably receive the transmission of the
paging signals.
Digital
A digital signal is composed of electrical pulses representing either zero or one. Because digital
signals are made up only of binary streams, less information is needed to transmit a message.
Digital encoding therefore increases the capacity of a given radio frequency. Furthermore, only
digitized information can be transported through a noisy channel without degradation. Even if
corruption occurs, as long as the one zero pattern is recognizable, the original information content
can be perfectly replicated at the receiving end.
GPRS- (General Packet Radio Service)
Allows information to be sent and received across a mobile telephone network that makes Internet
connections easier. GPRS is used to boost wireless data transmission over GSM networks. GPRS
can achieve 171.2 kilobits per second (kbps), which is about three times as fast as the data
transmission speeds possible over today's fixed telecommunications networks and ten times as fast
as current GSM networks. Unlike existing digital wireless Net connections, no dial-up modem is
necessary.
GSM- (Global System for Mobile Communications)
A digital mobile phone standard used extensively in Europe, the Middle East, Africa, Asia and in
parts of America and Canada. First introduced in 1991, the GSM standard has been deployed at
three different frequency bands: 900 MHz, 1800 MHz and 1900 MHz. GSM 1900 is primarily
deployed in North America. Named after its frequency band around 900 MHz, GSM-900 has
provided the basis for several other networks using GSM technology. GSM uses narrowband
TDMA which allows eight simultaneous calls on the same radio frequency. Along with CDMA and
TDMA it represents the second generation of wireless networks.
HDML- (Handheld Device Markup Language)
A specialized version of HTML designed to enable wireless pagers, cell phones and other handheld
devices to obtain information from Web pages. HDML was developed by Phone.com (formerly
Unwired Planet) before the WAP specification was standardized. It is a subset of WAP with some
features, not included in WAP. AT&T Wireless launched the first HDML-based service in 1996.
I-mode
NTT DoCoMo's mobile Internet access, launched in February 1999. I-mode is an alternative to
WAP, though it is only implemented in Japan. It offers Internet access and email service. While
WAP uses HDML, I-mode relies on Compact HTML (C-HTML). Both languages are a simple
version of HTML, for use on mobile phones. Today more than 7000 sites are I-mode compatible
and offer a wide range of services over mobile phones: mobile banking, ticket reservation, cartoons
downloading, etc.
IDEN- (Integrated Digital Enhanced Network)
A wireless communications technology from Motorola that provides support for voice, data, short
messages (SMS) and dispatch radio (two-way radio) in one phone. Operating in the 800MHz and
1.5GHz bands and based on TDMA, iDEN uses Motorola's VSELP (Vector Sum Excited Linear
Predictors) vocoder for voice compression and QAM modulation to deliver 64 Kbps over a 25KHz
channel. Each 25KHz channel can be divided six times to transmit any mix of voice, data, dispatch
or text message. Used by various carriers around the globe, Nextel Communications provides
nationwide coverage in the U.S.
Messaging Gateway
A computer system that converts one messaging protocol to another. It provides an interface
between two store and forward nodes, or message transfer agents (MTAs).
Metadata
Data that describes other data. The term refers to any file or database that holds information about
another database's structure, attributes, processing or changes. Metadata surrounding the
Simplewire service and wireless device data includes whether a mobile device is turned on or off,
the geographic location, routing commands, screen size, the amount of characters a particular phone
can receive, character support, two-way capabilities and any other phone features.
One-Way Text-Messaging
Sending short (wireless data) messages to a smart phone, pager, wireless PDA or other handheld
device via the Internet. Text-messaging implies sending short messages generally no more than a
couple of hundred characters in length. In Europe, text-messaging was popularized by the GSM cell
phone system's Short Messaging Service (SMS), which supports messages of up to 160 characters.
PCS- (Personal Communication Services)
A second-generation digital voice, messaging and data cell phone system in the 2GHz range. PCS is
supported mostly by GSM.
PDC- (Personal Digital Communications)
A Japanese digital cellular standard that supports SMS.
SIM Card
Smart card that gives GSM phones their user identity. SIM cards make it easy for phones to be
rented or borrowed.
Smart Phone
A digital cellular phone that has text-messaging, web access and other data services along with
voice.
SMS- (Short Message Service)
The transmission of short text-messages to and from a mobile phone, fax machine and/or IP address.
Messages must be no longer than 160 alphanumeric characters and contain no images or graphics.
Once a message is sent, it is received by a Short Message Service Center (SMSC), which must then
get it to the appropriate mobile device. To do this, the SMSC sends a SMS Request to the home
location register (HLR) to find the roaming customer. Once the HLR receives the request, it will
respond to the SMSC with the subscriber's metadata: 1) inactive or active 2) where subscriber is
roaming. If the response is 'inactive' then the SMSC will hold onto the message for a period of time.
When the subscriber accesses the device the HLR sends a SMS notification to the SMSC, and the
SMSC will attempt delivery. The SMSC transfers the message in a Short Message Delivery
Point-to- Point format to the serving system. The system pages the device, and if it responds, the
message gets delivered and receives verification.
SMSC- (Short Message Service Center)
The hardware device submitting the messages. Currently, SMSC devices support binary formats. A
software module called the SMS gateway is used to give instructions to the SMSC. The protocol
described in this draft is proposed to provide a standard for service providers to interact with SMS
gateways or SMS centers.
SNPP- (Simple Network Paging Protocol)
A sequence of commands and replies where pages are delivered to individual paging terminals. The
most obvious benefit is the elimination of the need for modems and phone lines to produce
alphanumeric pages, and the ease of delivery of pages to terminals in other cities or countries.
TAP- (Telocator Alphanumeric Protocol)
An SMS standard. The pre-cursor to TDP, a simple protocol dedicated to the forwarding of
alphanumeric pages. Although the features and capabilities of TAP are in TDP, the TAP protocol
may co-exist with TDP. The TAP protocol may be utilized to forward binary data to RF linked
computers if input is formatted and processed.
TDMA- (Time Division Multiple Access)
A method of digital wireless communications transmission allowing a large number of users to
access a single radio-frequency channel without interference. Each user is given a unique time slot
within each channel. SMS Mobile Originate has now gone live on several TDMA networks around
the world including Telecom New Zealand, Midwest Wireless USA, Algar Telecom Brazil and
Cellcom Israel. Other TDMA network operators such as AT&T Wireless in the U.S. have launched
SMS MO nationally.
TDP/TME- (Telocator Data Protocol)
A suite of protocols used for sending messages from a computer, through a paging system, to a
mobile receiving computer. Together, these protocols define the flow of messages from input
devices through several processing steps until the entire message is received by an RF linked
computer. The set is compromised of several protocols including TME, TRT and TMC.
Text-Messaging
See One-Way Text-Messaging and Two-Way Text-Messaging
Third-Generation - (3G)
A new wireless standard promising increased capacity and high-speed data applications up to two
megabits. Implemented in Europe as UMTS and cdma2000 in North America. Goals are
high-quality multimedia and advanced global roaming (in house, cellular, satellite, etc.).
TNPP- (Telocator Network Paging Protocol)
A one-way paging networking standard. TNPP is supported by most one-way and two-way
messaging networks, but can only be used for one-way messaging. The TNPP protocol is used for
moving pages from one paging system to another over standard lines.
Two-Way Text-Messaging
Sending short (wireless data) messages to a smart phone, pager, PDA or other handheld device from
another web enabled device. Two-way implies that the device receiving the message is able to reply
via text-messaging as well. Text-messaging implies sending short messages generally no more than
a couple of hundred characters in length. In Europe, text-messaging was popularized by the GSM
cell phone system's Short Messaging Service (SMS), which supports messages of up to 160
characters.
VPN- (Virtual Private Network)
Private networks that are configured within a public network. Carriers build VPNs that appear as
private national or international networks to the customer, but physically share backbone trunks
with other customers. VPNs enjoy the security of a private network via access control and
encryption, while taking advantage of the economies of scale and built-in management facilities of
large public networks. VPNs have been built over X.25, Switched 56, frame relay and ATM
technologies. The VPN adds an extra layer of security. A huge growth in VPN use is expected.
WAE- (Wireless Application Environment)
The part of the WAP protocol that application and service developers use most in their work. The
WAE consists of the WML and WMLScript specs as well as the Wireless Telephony Application
Interface (WTAI) that specifies how WAP applications can access mobile phone functionality
(initiate a call, send an SMS).
WAP Alert
An exclusive Simplewire product that enables wireless devices to receive a reroute via text-message
to a url where the user can access more information than can be provided within the character limit
of a text-message.
WAP Stack
A set of protocols that covers the whole process of wireless content delivery: From the definition of
WML and WML Script for creating the actual layout of the content to the specifications of security
measures in the WTLS, and to the lowest parts of the stack dealing with the actual transport of
content.
WAP- (Wireless Application Protocol)
An open standard for communication between handsets and the Internet. WAP is a wireless
communications environment for delivering Web data to wireless terminals with minimal screen
display. An initiative started by Unwired Planet, Motorola, Nokia and Ericsson to develop a
standard for wireless content delivery on the next generation of mobile communicators. WAP strips
all but graphics for display on small screens, such as mobile phones. A mini-browser is an integral
part of WAP enabled phones. WAP enabled phones first appeared in Europe at the end of 1999.
WCTP- (Wireless Communication Transfer Protocol)
A protocol that transfers content between wireline and wireless devices. The protocol may operate
over any desired transport protocol that is block oriented. The protocol itself deliberately does not
address the issues of security or authentication of transactions in a highly secure manner.
WIM- (Wireless Instant Messaging)
Bridges the gap between wired and wireless networks. WIM seamlessly allows a desktop user to
instantly send a message to a handset.
WIN - (Wireless Intelligent Network)
Transaction processing infrastructure for wireless systems.
Wireless Bridge
A device used to transmit and receive radio frequencies over the air between two LANs.
Wireless LAN
A local area network that uses radio frequency transmission over the air. Works like a cellular phone
system with roaming between cells.
Wireless Modem
Modem and antenna for analog and digital cellphones, CDPD, ARDIS, BellSouth Intelligent
Wireless Network, etc.
Wireless Portal
A Web site that supports users with smart phones or alphanumeric pagers.
WMF- (Wireless Message Format)
A standard format for presenting data received through a paging system to mobile computers. The
application at the MED uses this format to encode binary data and control information sent to a
remote device. This information is received completely intact by the MCD.
WML/WMLScript- (Wireless Markup Language/Script)
The languages used to create WAP pages. WML is similar to the way HTML is used to create web
pages and WMLScript is based on JavaScript. Both are adapted and optimized for a wireless
environment (compression to save bandwidth).
WMP- (Wireless Message Protocol) Server
Simplewire's very own WMP server allows the Wireless Message Gateway to accept all requests
regardless of carrier, intelligently translate the information into the correct wireless protocol and
route the information to the correct wireless carrier. Simplewire's WMP server is able to provide
subscribers with a consistent and simple interface via the Internet to any wireless device. The WMP
Server is Simplewire's core technology and includes four layers of the text-messaging network.
They are the Acceptance and Delivery Layer, the Processing Layer, the Consolidation Layer and the
Carrier Routing Layer.
WSP- (Wireless Service Provider)
Any organization that delivers wireless services to its customers.
WTLS- (Wireless Transport Layer Security)
The security layer of the WAP which provides privacy, data integrity and authentication for WAP
services. WTLS, designed specifically for the wireless environment, is needed for the client and
server to be authenticated in order for wireless transactions to remain secure and also because the
connection needs to be encrypted. For example, a user making a transaction with a bank over a
wireless device needs to know that the connection is secure and private and not subject to a security
breach during transfer. WTLS is needed because mobile networks do not provide complete
end-to-end security.
Introduction to SMSC dial-in providers
SMSC Short Message Service Centre
Every Short Message has to pass the SMSC. There are different ways to tranfer the Short Message
to the Short Message Service Centre. A Short message can reach the SMSC by GSM modem /
module and can be transferred to an email or fax.
Manual reception
Make a call to a manual reception and tell them what you want to sent and
to whom. Not very
useful in industrial GSM applications.
Automatic answering service
Make a call to an automatic answering service and make a choice from a number of ready made
texts. Not popular in industrial applications also.
Typing on the keypad of your GSM phone
Use your own GSM phone with sending abilities and enter a message and send it. Can be useful,
if you have to send control commands from somebody to a machine, to change parameters. Most
GSM phone offers the storage of Short Messages so that you can send from memory of the SIM
card.
SMS program
Use a computer with a PSTN modem and a special SMS program. Popular for the sending of Short
messages to mobile GSM phones. There are a lot of local SMS programs available. A few of them
are freeware and others are shareware. In many countries the GSM operators offers light versions of
SMS programs as freeware. If you have a need for software that have more features, then you have
to buy it. If you use a local SMS software, then it is in local language and the parameters are set
for your GSM operators. The other technical problem are the different hardware interfaces like
PSTN modem or Datex P ( X.25) and the different software protocols like TAP and USP on the
SMSC. If you have to send only then TAP is OK, but if you have to send and to receive then UCP is
the right way. The UCP can send and receive Short Message. The easiest, but not fastest transmit
and receive you can reach with a GSM modem. A GSM modem can send / receive a Short Message
each 6 to 10 seconds. With a connect based on UCP you can reach 600 messages per minute.
SMS driver
For industrial applications you can not often not use ready SMS software. You have not to think
about the protocols, if you buy software drivers from third parties. That can save time and money.
SMS to fax
SMS to fax is available by a lot of GSM operators and by local third parties.
SMS to email
SMS to email is available by the GSM operators and by third parties too.
Email to SMS
Email to SMS is available by the GSM providers and by third parties. A few of them offers that serif
free of charge, but with advertising on the end of the message. Such free of charge services do
mostly not free of charge for commercial GSM solutions.
SMS to SMS
In the beginning of GSM it was not possible to send an SMS from GSM operator A to GSM
provider B. A few companies has developed special services to bridge that. They offer sending to
“foreign” German operators. Right now they offer a couple off other specials, that are not
supported by the local German operators.
Connect through GSM modem
There are different ways to send or to receive a SMS. The simplest with a GSM modem.
Unfortunately, a GSM-Modem can process only 6 to 10 SMS per minute. To increase the speed a
connect to a communication server with up to 32 GSM modem is neccesary. Then becomes
possible with it up to 320 SMS per minute. With this kind of SMS communication none direct
connect to SMSC is necessary. Some GSM operators offer no direct connect. Consequently, the
communication server with 32 GSM modem is a good alternative.
Direct link to SMSC
Faster and more comfortable is the direct link to the SMSC. With a direct acces you can reach up to
600 SMS per minute. Popular protocols are UCP, SMPP, CIMD2, OIS and TAP. TAP is an old
protocol to the send messages to a pager. Causes historically, TAP offers sent of messages from
server only.
With which hardware the SMSC can be connected is not the same by all the different operators. The
exact data must be asked at the GSM operator. The parameters are not equal also. Through the
variety, the likelihood of a mistake is very large.
Ready software that helps to connect
For the world wide market, there is a big number of software to ease the direct access to SMSC.
The offer is from Freeware, Open Sources up to software which almost all types of the
communications masters.
With Freeware, there is usually no support. The protocols named above are developed further
continually. So constantly changes on the software is necessary.
The following graphics shows an example for a software which at many companies in the usage.
Many settings of GSM operators already in the default parameters. Further new operators are added
by the developer usually free of charge. The functions of the software and service / support is
perfect.Whoever nevertheless thinks to save money with own drivers finds the sources of the known
protocols in the appendix. There are still students, which must develop drivers itself.