The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: January 21, 2003
XML Encoding for SMS (Short Message Service) Messages

[January 21, 2003]   SMS Forum Releases Review Draft for the Mobile Message Access Protocol Specification (MMAP).    A communiqué from Kieran Dolan reports on the release of an initial public review draft for Mobile Message Access Protocol Specification (MMAP), produced by the SMS Forum XML Protocol Group. Mobile Messaging Access Protocol (MMAP) is a "SOAP protocol that provides a framework for web application access to mobile messaging services. It provides a mechanism whereby applications can initiate 'one-shot' requests or more complex peer sessions over SOAP and HTTP. MMAP provides support for service identification and billing and defines a standard way of supporting session-oriented communication. MMAP is a generic access protocol which now subsumes and extends the SMS Forum's original XML protocol specification, called SMAP. SMAP is now an application part of MMAP, providing a transport-independent set of XML primitives for handling Short Messages. SMAP provides XML operations for: (1) Submission of short messages to a short message centre; (2) delivery of short messages and delivery receipts to an application; (3) managment of messages after submission." XML Schemas for the MMAP Modules and SMAP modules are provided in section 9 of the specification. A pre-release draft of this new MMAP XML-based Message Protocol is available for download; the SMS working group requests feedback from application developers on this draft.

[June 11, 2001] Short Message Service (SMS) messages have become very popular among mobile phone users. However, the service providing is still relatively awkward. This draft presents an encoding and a simple protocol for describing and submitting SMS messages over the Internet. The protocol is aimed to be used between service providers and SMS gateways. The SMS messages are encoded in XML and the corresponding Document Type Definition (DTD) for the message structure is described... This draft describes an interface between an SMSG and an SP. The SMSG and SP may reside at different physical locations and may be connected over the Internet. In other words, the interface proposed here is a straightforward way to connect SMS messages to the Internet. The purpose is to make becoming a service provider as easy as possible. If the mobile operators would provide a standard way to connect to their SMS centers via standard SMS gateway interfaces, the only thing required for becoming a wireless service provider would be a server capable of delivering and transmitting XML-encoded SMS messages. As the wireless services are maintained at the SPs servers, it is easy to connect the wireless services to the Internet-based services and databases hosted by the SP... [April 2001 draft]

[January 15, 2001] IETF Internet Draft abstract: "The Short Message Service (SMS) messages have become very popular. However, the service provisioning is still relatively awkward. This draft presents an encoding and a simple protocol for describing and submitting Short Message Service (SMS) messages over the Internet. The protocol is aimed to be used between SMS Centers and service providers. The SMS messages are encoded in XML and the corresponding Document Type Definition (DTD) for the message structure is described."

"This draft describes an interface between SMSC (Short Message Service Center) and SP (Service Provider). The SMSC and SP reside at different physical locations and are connected over the Internet. In other words, the interface proposed here is a straightforward way to connect SMS messages to the Internet. The purpose is to make becoming a service provider as easy as possible. If the mobile operators would provide a standard way to connect to the SMS Centers, the only thing required for becoming a wireless service provider would be a server capable of delivering and transmitting XML encoded SMS messages. As the wireless services are maintained at the SPs servers, it is easy to connect the wireless services to the Internet based services and data bases hosted by the SP."

"SMS (Short Message Service) is a relatively simple messaging system provided by the mobile phone networks. SMS messages are supported by GSM, TDMA and CDMA based mobile phone networks currently in use. Although services based on SMS have been feasible for many years, the recent mobile phone penetration and large scale user adoption of the existing services have made the SMS based services even more attractive to service providers. Although services enabled by WAP (Wireless Application Protocol) and UMTS (Universal Mobile Telecommunications System) will most propably replace SMS messages as the most popular media for wireless aplications, there will still be a very large user base still for a long time. The great market interest related to WAP and the so-called mCommerce (mobile commerce) has made also SMS more interesting as a service delivery channel. Operators and service providers are creating many new services. Wireless Application Service Provision (WASP) is a recent, interesting service architecture for providing SMS based services. The basic principle is that there is only one SMSC (SMS Center) which encodes the messages to be submitted through the GSM network. The basic difficulty in developing SMS based services is the variety of protocols used in SMS Centers. European Telecommunication Standards Institute (ETSI) has approved four SMSC protocols, SMPP (by Logica), CIMD (by Nokia), UCP/EMI (by CMG) and SMS2000 (by SEMA). All these protocols have a slightly different functionality and quite different character conversions. Supporting all these protocols is a demanding task for a service provider. There are several SMS gateways able to interact with some or all of the SMS protocols. However, there is no standard way for service providers to interact with the SMS gateways. Also, only few of the SMS gateways support all the SMSC protocols. This draft proposes a solution by introducing an easily adoptable interface to SMS Centers or SMS gateways for service providers."

[December 20, 2001] Compare:    SMS Forum Publishes Version 1.0 of the XML-Based Short Message Application Protocol (SMAP).    A communiqué from Kieran Dolan (Logica Mobile Networks; SMS Forum XML Working Group Chair) announces the release of a draft XML specification for SMS messages, together with an invitation for comments from application developers and protocol users. Supported by a number of operators and telecoms equipment manufacturers, the SFS Forum "is developing an XML specification for sending and receiving SMS ['Short Message Service'] messages. Version 1.0 of the Short Message Application Protocol is now available for public review, though the protocol is still under design and the draft released is by no means frozen. SMAP (Short Message Application Protocol) is an XML-based protocol designed to support SMS submission, delivery and administration. It provides equivalent functionality to a binary protocol such as SMPP V3.4 but using an XML schema as opposed to binary PDU format of SMPP. The protocol has been designed to meet market needs for XML-based applications, but is not intended to be a replacement for SMPP; instead the protocol is an XML alternative and may prove more applicable in certain circumstances. The specification is intended principally for designers and implementers of an SMAP v1.0 interface between a Short Message Gateway (SMG) or a Short Message Centre (SMSC) and an external Application." Formal definition of the protocol is provided in section 5, 'XML/SMPP Document Schema Specification'. [Full context]

References:

  • SMS Forum website

  • SMS Forum Protocol Specifications

  • [April 15, 2002] "XML Encoding for SMS Messages." Reference: 'draft-koponen-sms-xml-03.txt'. April 15, 2002, expires October 15, 2002. "This draft presents an encoding and a simple protocol for describing and submitting SMS messages over the Internet. The protocol is aimed to be used between service providers and SMS gateways. The SMS messages are encoded in XML and the corresponding Document Type Definition (DTD) for the message structure is described..." [cache]

  • [June 11, 2001] "XML encoding for SMS messages." IETF Internet-Draft 'draft-koponen-sms-xml-01.txt'. April 18, 2001. Expires: October 17, 2001. By Juha P. T. Koponen, Teemu Ikonen, and Lasse Ziegler (First Hop Ltd.). See the XML DTD. Note: "This draft (01) has been evolved rather much from the first version (00). There are two major refinements. Firstly, the concept of SMSC in previous version (00) covered both the actual SMS center and the SMS gateway. In this version (01), the difference is underlined and more traditional GSM parlance is used. Secondly, the XML specification is altered to a certain extent in order to correlate more with the GSM specifications. The experience with an SMS gateway in production use led the authors to simplify the messaging protocol a lot... [cache]

  • XML Encoding for SMS Messages. Internet-Draft 'draft-koponen-sms-xml-00.txt'. November 16, 2000. Expires: May 17, 2001. By Juha P. T. Koponen, Teemu Ikonen, and Lasse Ziegler (First Hop Ltd.). [cache]

  • SMS XML DTD - Specification Appendix A. Examples of XML encoded messages, Appendix B. Full DTD of the messages. From Draft 'November 16, 2000' (draft-koponen-sms-xml-00.txt).

  • Escio Message Gateway (EMG). First Hop's 'Escio Message Gateway (EMG)' is "a messaging solution that provides flexible and operator-independent routing of messages between mobile terminals and mobile services. Escio Message Gateway was developed to meet the needs of mobile operators, service providers, ISPs (Internet Service Providers) and ASPs (Applications Service Providers). In the design, special attention was paid to the usability of the programming interfaces. The basic features of EMG include push and pull delivery of messages, batch messaging and timed delivery. The system can be extended with several value-added packages, for example a smart messaging package that enables the sending of operator logos, picture messages and ringing tones. The architecture of the product is highly modular: the system is available in configurations ranging from an OEM edition to a full scale high availability version. Escio Message Gateway supports all ETSI-approved SMS center interfacing protocols and can easily be integrated into a wide array of application programming environments."

  • [February 11, 2002] "Smart and Simple Messaging. Discover the Hidden Potential of SMS as a Killer App Builder." By Wes Biggs (Senior Software Engineer, kpe). IBM developerWorks, Wireless Zone. February 2002. ['Myriad challenges face developers who want to undertake wireless projects today. While the rosy glow of a wireless future beckons, working with widespread technologies like the Short Messaging System (SMS) requires a different mindset. In this article, Wes Biggs outlines the difficulties facing developers tackling wireless today, and explains how SMS-based solutions could have greater killer app potential than many realize.'] "How can you make your mark in wireless technology today? To answer that question, we'll take a look at what's really happening in wireless right now. In particular, we'll explore the uses of Short Messaging System (SMS) in wireless solutions, both on its own and in combination with emerging technologies such as VoiceXML. I'll explain why SMS has more killer-app potential than you may realize, and offer several concrete examples of how that potential could be applied today... In many cases, the user's caller ID information is available to the VoiceXML service; in others, the user could request a text message by stating his or her phone number and provider. VoiceXML scripts could then feed this data, converted by a speech-recognition tool, to an e-mail engine, which would generate and send the data in SMS format... Similar applications exist in many areas. For example, a phone service might be able to tell you who won the game, but wouldn't it make more sense to read the box score for yourself? VoiceXML combined with SMS could also be used for purchase or trade confirmation on the go (call in, get a text confirmation), dial-up, message-based driving directions, and more. Together, the two technologies can bridge the gap between the limited user interface of a cell phone and the rich interfaces users are accustomed to for data retrieval on the Web... SMS reminders can capitalize on the 'push' nature of the medium to inform people of changes in itineraries and provide other time-sensitive information. Travel booking site Travelocity.com, for example, allows you to receive SMS-based updates to flight times as the airlines change them... Combining VoiceXML and the callback feature makes for a full-circuit input-output loop. Users request data quickly and easily by connecting to a voice-enabled service. They receive information in the form of one or several SMS messages, which they can respond to by calling back the number sent as the sender. The callback number connects them again to the VoiceXML system, where they can request additional data... Until ubiquitous, standardized wireless device user interfaces are a reality, you should keep your applications small and simple. Build for today, but keep the future in mind. Create internal architectures that can be applied to tomorrow's devices, but work with the simple messaging-based applications that are viable now. When building an SMS-enabled service, focus on getting the right data to your audience, not on the presentation of that data. After all, if the hardest piece of your application to develop is the wireless client interface, chances are you're not really providing much value. Don't focus on a 'wow' user interface today, unless you really want to impress the limited audience that has the technology to be wowed. Instead, let your wireless solution be a peephole into the high-value machinery of your Internet application or Internet-enabled business..."

  • What is SMS? From Webopedia: "Short Message Service (SMS) is 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 alpha-numeric 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 status: 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 his 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. The SMSC receives verification that the message was received by the end user, then categorizes the message as 'sent' and will not attempt to send again. The number of mobile-phone users expects to reach 500 million worldwide by 2003, and with the help of SMS, 75 percent of all cellular phones will be Internet-enabled..."

  • Wireless Short Message Service (SMS) Tutorial. From IEC Resources: Tutorials. "...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 specifications. See Diffuse "Mobile Data Communication Standards."

  • [February 10, 2000] "Sun-Netscape Alliance Goes Wireless." By Stephanie Sanborn. In InfoWorld (January 31, 2000). "The Sun-Netscape Alliance on Monday unveiled the iPlanet Wireless Server, which gives service providers the ability to offer customers wireless e-mail, calendar, and directory services customized to specific devices. Using XML-based style sheets, the Wireless Server provides device-appropriate content, formatting the information to fit a device's particular specifications, such as screen size. A plug-in for the iPlanet Messaging Server will enable sending of Short Message Service (SMS) alerts and notes to wireless devices."

  • [September 29, 2000] "Microsoft to air wireless server. Mobile Information 2001 Server to make its debut." By John Fontana. In Network World News (September 22, 2000). "Microsoft next week will introduce a server designed to give companies a way to wireless-enable applications for access from any number of handheld devices. The Mobile Information 2001 Server is middleware that transforms output from corporate applications into formats that can be displayed on mobile phones and other handheld devices. The server, which was code-named Airstream, also is a platform for building new wireless-enabled applications. The server will be a central point for establishing what devices can connect to the network, managing user access and security across the corporate firewall, and setting content-delivery preferences for devices such as Palm Pilots, Windows CE computers and mobile phones...Mobile Server works by taking in application data from servers and transforming it into formats such as the Wireless Markup Language or compact HTML for presentation on wireless devices. Key to the data transformation is the Extensible Stylesheet Language, which provides information to identify what type of device is requesting information and what kind of network it is running on. Mobile Server also includes support for a number of services for building mobile applications, including XML, Web Distributed Authoring and Versioning (WebDAV) and Wireless Markup Language. The server also supports standards based mobile specific transports and security mechanisms including, IETF DAV, Handheld Devices Markup Language, HTTP/HTML, XML, Secure Sockets Layer, Secure Hypertext Transport Protocol, Wireless Access Protocol, Wireless Markup Language, Active Directory Services Interface, Lightweight Directory Access Protocol and Short Message Service. The server also includes Microsoft Message Queuing to support asynchronous delivery of data to devices without a persistent connection."

  • [August 29, 2000] Wireless apps streamlined." By Roberta Holland. In eWEEK (August 27, 2000). "New wireless server solutions are being rolled out that prom ise to make it easy for corporations to build and launch applications for smart phones and other mobile devices. BEA Systems Inc. and Nokia Mobile Phones Inc. have teamed to develop the BEA WebLogic M-Commerce Solution. The package, which combines BEA's WebLogic Server and WebLogic Commerce Server with Nokia's WAP (Wireless Application Protocol) Server, allows developers to build scalable e-commerce services on a single platform, regardless of whether a user is accessing the information via a PC or a personal digital assistant. . . Pricing for the server starts at $6,500 for a starter development kit. A 50-user deployment kit, which includes a four-CPU clustering license for WebLogic Commerce Server, costs $268,600. Another wireless server, produced by Bluestone Software Inc., of Philadelphia, and New York-based Zyglobe Inc., is slated for release next month. The Zy-MobileServer incorporates Bluestone's J2EE-compliant and XML (Extensible Markup Language)-based platform with Zyglobe's wireless expertise built on top. The server will be able to automatically detect the protocol and device making a request and generate appropriate content back, whether it is intended for Wireless Markup Language or Short Message Service."

  • [June 2000] "SMS sets new records." "The SMS-wave is reaching new records - an estimated 8 billion text messages were received during May. The Short Message Service (SMS) is the ability to send and receive text messages to and from mobile telephones. The first message is believed to have been transmitted as early as 1992. Each short message is up to 160 characters. SMS-sceptics claimed that mobilephone keyboards would be too small for efficient communication. However recent data have proved them wrong. Not only do users chat among each other, SMS is also popular for receiving tailored information services as weather-reports etc."


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/xml-sms.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org