Smart Messaging Specification, version 2.0.0 ()affon.narod.ru/GSM/ssm200.pdf · changed substantially prior to final release. This document is provided for informational purposes

SMART MESSAGING

SPECIFICATION

Revision 2.0.0

1999-05-17 Subject to Change Without Notice

Smart Messaging iii

Revision 2.0.0 Copyright Nokia Mobile Phones Ltd. 1999

Disclaimer

The information in this document is provided ‘as is’, with no warranties whatsoever, including any warrantyof merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal,specification, or sample. Furthermore, information provided in this document is preliminary, and may bechanged substantially prior to final release. This document is provided for informational purposes only.

Nokia Mobile Phones Ltd. disclaims all liability, including liability for infringement of any proprietary rights,relating to implementation of information presented in this document. Nokia Mobile Phones Ltd. does notwarrant or represent that such use will not infringe such rights.

Nokia Mobile Phones Ltd. retains the right to make changes to this specification at any time, without notice.

1996, 1997, 1998, 1999 Nokia Mobile Phones Ltd.

Third party brands and names are the property of their respective owners.

License

A license is hereby granted to download and print a copy of this specification for personal use only. No otherlicense, express or implied, by estoppel or otherwise, to any other intellectual property rights is grantedherein.

Third Party Developer Support

Additional information on the Smart Messaging concept can be obtained by contacting Nokia Mobile PhonesLtd. at the following address:

Nokia Mobile Phones Ltd.ATTN: Third Party Developer Support

Smart Messaging

P.O. Box 68FIN-33721 TampereFinland

Phone: +358-10-5051 (main switchboard)

Fax: +358-10-505 6888(attn: Third Party Developer Support / Smart Messaging)

Email: [email protected]

Smart Messaging iv


< This page intentionally left blank >

Smart Messaging v


Contents

1. INTRODUCTION...............................................................................................................................................1-1

1.1 BACKGROUND ................................................................................................................................................1-11.2 DOCUMENT OVERVIEW ...................................................................................................................................1-2

2. SMART MESSAGING .......................................................................................................................................2-1

2.1 SMART MESSAGING ARCHITECTURE ................................................................................................................2-12.1.1 Narrow-Band Sockets.............................................................................................................................2-12.1.2 Wireless Datagram Protocol ..................................................................................................................2-22.1.3 Protocol Architecture.............................................................................................................................2-2

2.2 MESSAGE FORMATS ........................................................................................................................................2-42.3 PROTOCOL SPECIFICATIONS ............................................................................................................................2-4

3. MESSAGE FORMATS.......................................................................................................................................3-1

3.1 NOTATION......................................................................................................................................................3-13.1.1 Common Text Elements..........................................................................................................................3-2

3.2 TRANSFERRING CONFIGURATION MESSAGES....................................................................................................3-53.3 COMPACT BUSINESS CARD ..............................................................................................................................3-6

3.3.1 Syntax....................................................................................................................................................3-63.3.2 Informative Examples ............................................................................................................................3-7

3.4 GENERIC BUSINESS CARD ...............................................................................................................................3-83.4.1 Informative Examples ............................................................................................................................3-8

3.5 SERVICE CARD ...............................................................................................................................................3-93.5.1 Syntax....................................................................................................................................................3-93.5.2 Informative Examples ..........................................................................................................................3-10

3.6 INTERNET ACCESS CONFIGURATION ..............................................................................................................3-113.6.1 Basic Configuration Syntax..................................................................................................................3-11

3.6.1.1 Basic IAP .........................................................................................................................................................3-123.6.1.2 Basic Mail........................................................................................................................................................3-12

3.6.2 Informative Examples ..........................................................................................................................3-133.6.3 Extended Configuration Syntax............................................................................................................3-14

3.6.3.1 Extended IAP ...................................................................................................................................................3-143.6.3.2 Extended Mail..................................................................................................................................................3-153.6.3.3 WWW Hotlist Item Settings .............................................................................................................................3-163.6.3.4 Script Settings ..................................................................................................................................................3-173.6.3.5 SMS Settings....................................................................................................................................................3-173.6.3.6 Telnet Settings .................................................................................................................................................3-183.6.3.7 Terminal Settings .............................................................................................................................................3-183.6.3.8 WWW Settings.................................................................................................................................................3-193.6.3.9 TTML Settings .................................................................................................................................................3-193.6.3.10 FTP Settings.................................................................................................................................................3-193.6.3.11 Internet Settings ...........................................................................................................................................3-203.6.3.12 Telephone Settings .......................................................................................................................................3-203.6.3.13 WWW Autofetch Settings.............................................................................................................................3-20

3.7 CALENDAR ...................................................................................................................................................3-223.7.1 Informative Examples ..........................................................................................................................3-22

3.8 RINGING TONES............................................................................................................................................3-233.8.1 Syntax..................................................................................................................................................3-23

3.9 GRAPHICAL LOGOS AND ICONS......................................................................................................................3-30

Smart Messaging vi


3.9.1 OTA Bitmap Syntax..............................................................................................................................3-303.9.1.1 Coding Rules....................................................................................................................................................3-323.9.1.2 Image Data Structure ........................................................................................................................................3-32

3.9.2 CLI Icon Syntax ...................................................................................................................................3-323.9.2.1 Example of a CLI Icon Message........................................................................................................................3-33

3.9.3 Operator Logo Syntax..........................................................................................................................3-333.10 EMAIL NOTIFICATION ...................................................................................................................................3-34

3.10.1 Simple Email Notification ....................................................................................................................3-343.10.1.1 Syntax..........................................................................................................................................................3-343.10.1.2 Informative Examples...................................................................................................................................3-34

3.10.2 Extended Email notification.................................................................................................................3-353.10.2.1 Syntax..........................................................................................................................................................3-353.10.2.2 Description of the Fields...............................................................................................................................3-36

3.10.2.2.1 Number of New Mail Messages ...............................................................................................................3-363.10.2.2.2 From........................................................................................................................................................3-363.10.2.2.3 Subject.....................................................................................................................................................3-363.10.2.2.4 Size..........................................................................................................................................................3-373.10.2.2.5 UID..........................................................................................................................................................3-373.10.2.2.6 Server ID .................................................................................................................................................3-373.10.2.2.7 Attachments .............................................................................................................................................3-373.10.2.2.8 To............................................................................................................................................................3-373.10.2.2.9 Cc............................................................................................................................................................3-373.10.2.2.10 Date.......................................................................................................................................................3-373.10.2.2.11 Folder ....................................................................................................................................................3-373.10.2.2.12 Sender ...................................................................................................................................................3-373.10.2.2.13 Reply-To................................................................................................................................................3-373.10.2.2.14 UID Validity ..........................................................................................................................................3-38

3.10.2.3 Informative Examples...................................................................................................................................3-383.10.2.3.1 Restricted mode version for legacy phones................................................................................................3-383.10.2.3.2 Restricted Mode Version for Smart Phones ..............................................................................................3-383.10.2.3.3 Non-restricted Mode Version for a Legacy Phone .....................................................................................3-383.10.2.3.4 Non-restricted Mode Example for Smart Phones.......................................................................................3-38

4. PROTOCOL SPECIFICATIONS ......................................................................................................................4-1

4.1 NOTATION......................................................................................................................................................4-14.1.1 Common Elements .................................................................................................................................4-1

4.2 DYNAMIC MENU CONTROL PROTOCOL (DMCP) ..............................................................................................4-24.2.1 The DMCP Protocol Description ...........................................................................................................4-4

4.2.1.1 Menu Group Names ...........................................................................................................................................4-44.2.1.2 Authorization Schemes .......................................................................................................................................4-44.2.1.3 Protocol Primitives .............................................................................................................................................4-5

4.2.2 Item Primitive Definitions ......................................................................................................................4-54.2.2.1 Item Add ............................................................................................................................................................4-54.2.2.2 Item Remove ......................................................................................................................................................4-84.2.2.3 Item List.............................................................................................................................................................4-84.2.2.4 Item Capability...................................................................................................................................................4-84.2.2.5 Unsolicited Menu Response................................................................................................................................4-94.2.2.6 Unsolicited Menu Update Response....................................................................................................................4-9

4.2.3 Authorization Primitive Definitions......................................................................................................4-104.2.3.1 Authorization Add ............................................................................................................................................4-104.2.3.2 Authorization Remove ......................................................................................................................................4-104.2.3.3 Authorization List.............................................................................................................................................4-10

4.2.4 Device Capability Primitive Definitions...............................................................................................4-104.2.4.1 Device Capability .............................................................................................................................................4-10

4.2.5 Syntax..................................................................................................................................................4-114.2.5.1 Requests...........................................................................................................................................................4-114.2.5.2 Item Commands................................................................................................................................................4-124.2.5.3 Authorization Commands .................................................................................................................................4-16

Smart Messaging vii


4.2.5.4 Capability Commands.......................................................................................................................................4-164.2.5.5 Responses ........................................................................................................................................................4-16

4.2.6 Procedures...........................................................................................................................................4-184.2.6.1 Notation ...........................................................................................................................................................4-184.2.6.2 Handset FSM State Transition Table: Item primitives .......................................................................................4-184.2.6.3 Handset FSM State Transition Table: Authorization primitives .........................................................................4-204.2.6.4 Handset FSM State Transition Table: Device Capability primitives ..................................................................4-20

4.2.7 State Definitions ..................................................................................................................................4-204.2.8 Parameter Definitions..........................................................................................................................4-204.2.9 Event Descriptions...............................................................................................................................4-214.2.10 Action Descriptions..............................................................................................................................4-224.2.11 Informative Examples ..........................................................................................................................4-23

4.2.11.1 Protocol Action Examples.............................................................................................................................4-234.2.11.2 Phone UI Examples ......................................................................................................................................4-24

4.3 TAGGED TEXT MARKUP LANGUAGE (TTML).................................................................................................4-264.3.1 TTML Protocol Description .................................................................................................................4-26

4.3.1.1 Formal TTML Protocol Specification................................................................................................................4-264.3.1.2 TTML Protocol Rules .......................................................................................................................................4-304.3.1.3 Short Message Concatenation ...........................................................................................................................4-314.3.1.4 Examples .........................................................................................................................................................4-32

4.3.1.4.1 Hyperlink Usage ........................................................................................................................................4-324.3.1.4.2 Reducing Content.......................................................................................................................................4-344.3.1.4.3 Header Combinations .................................................................................................................................4-344.3.1.4.4 Service Access Point Presentation ..............................................................................................................4-35

5. APPENDIX A: RESERVED PORT NUMBERS................................................................................................5-1

5.1 INTRODUCTION...............................................................................................................................................5-15.1.1 NBS Protocol .........................................................................................................................................5-25.1.2 WDP ......................................................................................................................................................5-3

5.2 RESERVED PORT NUMBERS .............................................................................................................................5-4

Smart Messaging viii


Overview of changes from 1.0 to 2.0

A few minor errors in previous specification have been corrected, including some ambiguities inmessage format specifications. There are also many additions to Internet configuration messages.Extended Email Notification message has been introduced. WDP has been introduced as analternative to NBS.

This specification does not address product-specific differences. Each product should have its owndocumentation, which is intended to be read in conjunction with this specification.

Smart Messaging ix


References

GSM_03.38 Digital cellular telecommunications system (Phase 2+), Alphabets and language-specific information, GSM 03.38 version 5.4.0, ETSI, November, 1996.(http://www.etsi.org/)

GSM_03.40 Digital cellular telecommunications system (Phase 2+), Technical realization of theShort Message Service (SMS), Point-to-Point (PP), GSM 03.40 version 5.4.0,ETSI, November, 1996. (http://www.etsi.org/)

ISO_8601 ISO 8601, Data elements and interchange formats— Information interchange—Representation of dates and times, International Organization for Standardization,June, 1988.

ISO 8601, Technical Corrigendum 1, Data elements and interchange formats—Information interchange— Representation of dates and times, InternationalOrganization for Standardization, May, 1991. (http://www.iso.ch/)

ISO_8859 ISO 8859-1, Information processing — 8-bit single-byte coded graphic charactersets — part 1: Latin Alphabet No. 1, International Organization forStandardization, February, 1987. (http://www.iso.ch/)

ISO/IEC_10646 ISO/IEC 10646-1, Information technology — Universal Multiple-Octet CodedCharacter Set (UCS) — Part 1: Architecture and Basic multilingual plane, May,1993. (http://www.iso.ch/)

Unicode The Unicode Standard, Version 2.0. Unicode Consortium, 1993.

With the following addition: Unicode Technical Report #8: The Unicode Standard,Version 2.1. Unicode Consortium, 1998. (http://www.unicode.org/)

NBS_SPEC Narrowband Sockets Specification, Nokia Telecommunications, Intel Corporation,March, 1997. (http://www.intel.com/ial/nbs/)

RFC_822 RFC 822: Standard for the Format of ARPA Internet Text Messages, Dept. ofElectrical Engineering, University of Delaware, David H. Crocker, August 13,1982. (http://www.rfc-editor.org/)

RFC_1738 Network Working Group, Request for Comments 1738: Uniform Resource Locators(URL), CERN, T. Berners-Lee; Xerox Corporation, L. Masinter; University ofMinnesota, M. McCahill, December,1994. (http://www.rfc-editor.org/)

RFC_1766 Network Working Group, Request for Comments 1766: Tags for the Identificationof Languages, UNINETT, H. Alvestrand, March, 1995. (http://www.rfc-editor.org/)

RFC_2060 Network Working Group, Request for Comments 2060: Internet Message AccessProtocol - VERSION 4rev1, University of Washington, M. Crispin, December,1996. RFC 2060. (http://www.rfc-editor.org/)

RFC_2425 Network Working Group, Request for Comments 2425: A MIME Content-Type forDirectory Information. T. Howes, M. Smith, F. Dawson. September 1998.(http://www.rfc-editor.org/)

Smart Messaging x


RFC_2426 Network Working Group, Request for Comments 2426: vCard MIME DirectoryProfile. F. Dawson, T. Howes. September 1998. (http://www.rfc-editor.org/)

WAP_WDP Wireless Application Protocol: Wireless Datagram Protocol. Version 1.1. WAPForum, 1999. (http://www.wapforum.org/)

WAP_WTLS Wireless Application Protocol: Wireless Transport Layer Security. Version 1.1.WAP Forum, 1999. (http://www.wapforum.org/)

vCalendar vCalendar, The Electronic Calendaring and Scheduling Exchange Format, Version1.0, a Versit Consortium Specification, September 18, 1996. (http://www.imc.org/)

vCard vCard, The Electronic Business Card, Version 2.1, a Versit ConsortiumSpecification. (http://www.imc.org/)

Smart Messaging xi


Acronyms

AC Access Control

ASCII American Standard Code for Information Interchange

BCD Binary Coded Decimal

BNF Backus-Naur Form

CI Cell Identity

CLI Calling Line Identification

DCS Digital Cellular System

DMCP Dynamic Menu Control Protocol

DTMF Dual-Tone Multi-Frequency (tone)

FTP File Transfer Protocol

GPRS General Packet Radio Service

GSM Global System for Mobile Communications

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IANA Internet Assigned Numbers Authority

IAP Internet Access Point

IETF Internet Engineering Task Force

IMAP Internet Message Access Protocol

IMC Internet Mail Consortium

IMEI International Mobile Equipment Identity

ISDN Integrated Services Digital Network

ISO International Standards Organization

LAC Location Area Code

LAN 1. Local Area Network, 2. Language

LGS Localized GSM Services

MAP Message Access Protocol

MIDI Musical Instrument Digital Interface

MIME Multipurpose Internet Mail Extensions

MS Mobile Station

NBS Narrow Band Socket

NC Network Code

OTA Over The Air

PC Personal Computer

PCS Personal Communications Services

POP Post Office Protocol

Smart Messaging xii


RFC Request For Comments

RT Ringing Tone

SAP Service Access Point

SAR Segmentation And Re-assembly

SMS Short Message Service

SMSC Short Message Service Center

TCP Transmission Control Protocol

TTML Tagged Text Markup Language

UCS-2 Universal Multiple-Octet Coded Character Set, 16-bit representation

UDP User Datagram Protocol

UI User Interface

UID Unique Identifier

UP Unwired Planet

URL Uniform Resource Locators

USSD Unstructured Supplemental Services Data

UTC Universal Time Coordinated

UU User to User data

WAP Wireless Application Protocol

WDP Wireless Datagram Protocol

WTLS Wireless Transport Layer Security

WWW The World Wide Web

Smart Messaging 1-1


1. INTRODUCTION

1.1 BACKGROUND

The emphasis in cellular networks is changing from voice-only communication to a rich combination of voiceand messaging. Where voice communication once was accompanied only with circuit-switched data services,now various kind of (narrow-band) packet-switched communication means exist.

As the emphasis is moving in the direction of messaging, it is clear that close interaction is required betweenhandset vendors, infrastructure vendors, and operators. The quality of service the users receive dependscrucially on how successful this interaction is.

BaseProductsBaseProductsBaseProducts

StandardsStandards

IndustrySpecificationsIndustrySpecifications

Figure 1-1. The whole product model

Smart Messaging 1-2


In order to efficiently utilize the messaging capabilities of networks such as GSM/DCS/PCS1900, an openplatform is required which enables support for today’s communication needs, as well as those that are stillemerging. Today a set of tools and interfaces are needed to bring to the users the solutions they require, andtomorrow as requirements evolve, the tools and interfaces must be able to grow as well.

This document is the first part in a family of documents that cover the Smart Messaging concept. Theintention of this family of documents is to share up-to-date information within the telecommunicationindustry. Third parties are provided the means, i.e., the infrastructure on which they can build their services.Standards, were they official or agreed on within the industry, are an important part in the whole productmodel (Fig.1-1). They ensure on their part that the whole product fulfills the needs of the customer.

1.2 DOCUMENT OVERVIEW

This document is divided to four sections. First, the Introduction gives short overview on the basic ideologybehind the document family.

Second, Smart Messaging architecture is described. In that section an overview is given on what is involved inbuilding applications that seamlessly interface with the architecture. References are made to relevantspecifications that will delve deeper into the technical details of the architecture.

In the third section, the Message Formats are presented. That section describes the currently defined set ofSmart Message Formats. This set of formats enables operators to provide services that work with a variety ofhandsets.

In the fourth section, relevant Protocol Specifications are presented. Based on these formats it is possible tocreate services that enable users to browse the Internet using handsets, or enable dynamic update of menuitems in the handsets.

These sections are followed by an appendix on the reserved port addresses. This appendix presents informationon the reserved socket port address space, and the port assignments for the currently defined “well-known”protocols.

This document does not discuss the extent of smart messaging implementation in any handset or smart phone.Each manufacturer provides information on the support in their products separately.

Smart Messaging 2-1


2. SMART MESSAGING

2.1 SMART MESSAGING ARCHITECTURE

2.1.1 Narrow-Band SocketsOne of the main design criteria in Smart Messaging Architecture is to provide application developers with aflexible interface that hides communication channel idiosyncrasies. This is achieved by a joint effort of Nokiaand Intel, in Narrow-Band Socket (NBS) specification. The NBS specification [NBS_SPEC] enablesapplications to access various network data bearer services using standard socket interface. This interface isavailable both in high-end handsets as well as in server elements in the network, making it possible forapplication developers to utilize their existing knowledge and code base. Over the Air (OTA) applications thatrely on this architecture will benefit from the short time to market.

Depending on the needs of service providers, they may choose from several platforms to provide their serviceson. While smaller or specialized service providers might opt for a PC based system, service providers focusingon large scale service implementation can choose from the integrated systems available from networkinfrastructure vendors.

A solution in PC based systems is considered very important, as new markets are opened for small businesses,and PC platforms are challenging the performance of powerful workstations. Also the availability of aWinsock2 NBS interface in PC systems will help small businesses enter market.

For operators the main interests are how to integrate the new services with the existing infrastructure, and howto efficiently handle use of the air interface. For them, closely integrating new services with their existingservice centers is a clean and effective solution.

Smart Messaging 2-2


2.1.2 Wireless Datagram ProtocolSince the publication of the earlier versions of this specification, the ideas presented in NBS have been takeninto use in WAP Forum’s Wireless Datagram Protocol (WDP) [WAP_WDP]. In practice, the WDP protocoldoes not deviate far from NBS, and whenever NBS is mentioned as a suitable transport, it is possible to useWDP if the recipient implements this protocol layer of the Wireless Application Protocol (WAP) stack and iscapable of handling Smart Message payloads.

There are certain differences between NBS and WDP protocols when they are implemented over GSM ShortMessage Service. In practice, WDP capable peers can receive NBS datagrams, but NBS only capable peersmay not be able to receive WDP packets due to the differences how Short Messages are used underneath theseprotocols . Peers which have a TCP/IP stack may use UDP to carry Smart Messages, just as if they would useWDP. Therefore, WDP shares the TCP/UDP port number space. Therefore, some of the default port numbersmentioned in this specification differ between NBS and WDP implementations. The differences are listed witheach message type.

Please note: All future implementations of Smart Messaging protocol should use WDP and the WDP portnumbers, if full interoperability with old NBS implementations is not critical.

Please note: Security services can be added to Smart Messaging by utilizing the WTLS (Wireless TransportLayer Security) protocol, which offers security services for WDP. The use of WTLS [WAP_WTLS] is onlypossible when both communicating peers are using a WAP stack. WTLS cannot be used if either end is onlycapable of NBS.

Please note: NBS and WDP layers can be bypassed by using so-called “keyword headers”. In this model,normal GSM Short Messages start with a certain keyword. The recipient detects this keyword and processesthe rest of the Short Message as a Smart Message. All future Smart Messaging implementations should usekeyword headers only if interoperability with an old implementation is critical.

2.1.3 Protocol ArchitectureThe architecture is shown in Figure 2-1. The applications communicate with the NBS and WDP layers, whichprovide addressing capability and hide the packet boundaries of the underlying communication channel byproviding a segmentation and reassembly (SAR) functionality. The upper interfaces of NBS and WDP may beimplemented as sockets. The protocols are not bearer specific. If a peer supports a certain bearer, it does notimply that other bearers would be supported. A peer may support any combination of bearers. In addition toGSM’s Short Message Service, WDP can be adapted to work over, for example, USSD. As mentioned earlier,UDP (using a circuit switched data call or GPRS) can also be used. It should be noted that NBS and WDP arenot dependent of the network technology, and thus are not limited to GSM only.

Exchanging formats specified in the Message Formats section may be done by the applications at the portaddresses specifically reserved for this purpose. It is also possible to build tailored systems in which vendor-specific formats are exchanged. In the Smart Messaging model, vendors reserve a port number for their ownuse, and the port number identifies the target application. The NBS port number space is controlled by Nokia.The TCP/UDP port number space (and subsequently, the WDP port number space) is controlled by IANA. Formore information on the procedure on how to reserve a port number, please contact Nokia Third PartyDeveloper Support. For more information on the address space and reserved ports, please refer to Appendix A:Reserved Port Numbers.

Smart Messaging 2-3


WDP NBS

GS

M S

MS

UD

P/IP

Dat

a ca

ll

Oth

er b

eare

rs

Smart Messages

Ove

r WD

P

Key

wor

d he

ader

s

Ove

r UD

P

Ove

r NB

S

Figure 2-1. The Smart Messaging Architecture

Smart Messaging 2-4


2.2 MESSAGE FORMATS

The Smart Messaging architecture provides application developers with an extendible set of message formats .These formats enable any application to communicate with a wide variety of handsets. The addressingcapability of Narrow-Band Sockets enables easy implementation of client/server applications; a set of narrow-band socket addresses are reserved to be solely used for exchanging the known message formats. A list ofrelevant socket addresses can be found in Appendix A: Reserved Port Numbers.

A list of message formats is presented in the Message Formats section. This basic set enables a rich set ofapplications to be built in the OTA environment. The set of specifications currently covers the followingareas:

• Sending or receiving business cards.

• Sending or receiving service cards that enable easy access to touch tone (DTMF) based services.

• Sending or receiving Internet Access Configuration related information.

• Sending or receiving calendar items.

• Sending and receiving ringing tones and graphical information

• Enabling access to operator-specific supplementary services.

• Enabling access to a wide variety of value added services.

2.3 PROTOCOL SPECIFICATIONS

The Protocol Specifications section handles various kinds of protocols. These protocols, like the messageformats, function in certain NBS ports. In this version of the document three protocols are made available. Ashort overview is given on the protocols next.

Dynamic Menu Control Protocol (DMCP)The dynamic menu control protocol enables over the air update of the handset menu structure. Depending onthe handset implementation, applicable parts of DMCP are supported. Typical to all implementations is themenu structure, which is divided to sub-menus. The control of these sub-menus can be given to authorizedparties.

As users become familiar with the concept of dynamic menus, this capability is expected to be present in allhandsets. The dynamic menus enable customization of the menu structure based on the needs of the user orbased on the set of services that the operator provides.

Smart Messaging 2-5


When a menu item is selected, it may cause a number of different actions to take place. For example, a TTMLbased service can be started, a phone call can be initiated, or a message can be sent. Access to supplementaryservices can be made automatic, as users are shielded from the supplementary service string required to initiatea network service.

DMCP enables handsets to have any number of menus. The menus are divided into these basic categories:home operator, roaming operator, local, user’s favorite and manufacturer-specific menus.

Tagged Text Markup Language (TTML)The TTML specification enables users of legacy cellular phones, as well as users of browser capable phones toaccess services on the Internet. Enabling the legacy cellular phones to utilize the same concept enables theservice providers to target a large user base from day one. This user base is likely to use keyword-based TTMLservice, whereas users with a browser capable phone will fully utilize the TTML forms available to accessservices.

Services accessible by legacy phones do not need any modifications within the handsets already on the market.Thus only a TTML server is needed in the network to start services. The TTML server is capable of acquiringinformation from the Internet. This makes service setup a short process, as most service providers are alreadywell versed in setting up Internet based services.

Browser capable cellular phones provide the user with links to services, selection lists, text and numeric entryfields and the like. A combination of these plus free-form text give service providers a good ground to basetheir services on.

Smart Messaging 2-6



Smart Messaging 3-1


3. MESSAGE FORMATS

3.1 NOTATION

The notation used in the Message Formats section uses the common elements presented here. Backus-NaurForm (BNF) notation is used to describe the format of the messages. The BNF format and extensions used areas follows:

• In BNF notation “::=” means “definition”, where a non-terminal symbol is on the left side of theoperator “::=”, and the definition is on the right side.

• The symbol order in BNF notation is the same as the syntax symbol order.

• Terminal symbols are enclosed between quotes (“), and the symbols are written in bold.

• Non-terminal symbols are enclosed between < and > characters, and the symbols are written in italics.

• Textual definitions for non-terminal characters are enclosed between apostrophes (‘).

• Operator “|” is used as a delimiter between multiple choices.

• Grouping of items is expressed by enclosing them in meta symbols { and }.

• Optional parts are enclosed in meta symbols [ and ].

• Kleene’s “+” operator is supported, i.e., <A>+ means repetition of non-terminal <A> from 1 to ∞ times.

• Kleene’s “*” operator is supported, i.e., <A>* means repetition of non-terminal <A> from 0 to ∞ times.

• Semicolon symbol “;” means that the rest of the line contains comments.

Smart Messaging 3-2


3.1.1 Common Text ElementsThe used character literals, e.g. "5", represent the corresponding character values encoded according to thecurrently used character set. The currently used character set is either explicitly indicated as part of thedefinition of a Smart Message type, or is the default (“native”) character set for the used bearer service (forexample GSM Short Message Service). Note that the bearer’s native character set may be the only characterset which is usable on a particular bearer (for instance, because the bearer supports only 7-bit data). The nativecharacter set of the bearer should be used when there is no explicit information on the availability of othercharacter sets.

In GSM the native character set is the character set defined in [GSM_3.38] and [GSM_3.40]. Existingimplementations usually default to this character set unless another one has been explicitly specified.

Character Definitions

<line-feed> ::= ‘The line feed character of the currently used character set, corresponding to the character withISO 8859-1 value 10 decimal.’

<carriage-return> ::= ‘The carriage return character of the currently used character set, corresponding to thecharacter with ISO 8859-1 value 13 decimal.’

<line-delimiter> ::= <line-feed> | <carriage-return>

<space> ::= ‘The space character of the currently used character set, corresponding to the character with ISO8859-1 value 32 decimal’

<default-char> ::= ‘Any character in the character set which is currently being used.’

<default-char-not-lf> ::= ‘Any character in the currently used character set except <line-feed>.’

<default-char-not-ld> ::= ‘Any character in the currently used character set except <line-delimiter>.’

<default-char-not-space> ::= ‘Any character in the currently used character set except <space>.’

<unicode-char> ::= ‘Any 16-bit Unicode (see [Unicode] and [ISO/IEC_10646]) character in UCS-2 encoding(each encoded character is represented in a 16-bit quantity). Implies that the message transport must be eight-bit-clean.’

<ISO-8859-1-char> ::= ‘Any 8-bit ISO 8859-1 (ISO Latin 1, see [ISO_8859]) character. Implies that themessage transport must be eight-bit-clean.’

Dialing Definitions

<common-digit> ::= “1” | ”2” | ”3” | ”4” | ”5” | ”6” | ”7” | ”8” | ”9” | ”0”

<common-tel-char> ::= <common-digit> | “-“ | “#” | “*” | “W” | “w” | “P” | “p” | <space>

‘Character “W” / “w” commands the handset to wait for a dial-tone before dialing the rest of the sequence.Character “P” / “p” commands the handset to pause for a predefined interval prior to dialing the rest of thestring.’

<common-phone-number> ::= [ “+” ] <common-tel-char>*

Information Encapsulation Definitions

<common-information-content> ::= <information-content-length> “:” <information-content-char>*

<information-content-length> ::= ‘decimal value encoded in a character string in the currently used characterset, i.e., “42” for a message length of 42 when using ISO 8859-1. This value counts the number of 7/8-bitbytes, depending on the transmission channel setup. In case of Unicode characters, this value is twice thenumber of 16-bit Unicode characters (i.e. the number of octets). This strictly counts the number of<information-content-char>:s, this means that <information-content-length> and terminal character “:” areexcluded from the length.’

<information-content-char> ::= <default-char>

Addressing Definitions

<common-nbs-port> ::= “;” | ‘value in range [0..65535] decimal’ ; ‘ “;”, i.e., No port is given, handle as text only’

Smart Messaging 3-3


<common-source-nbs-port> ::= <common-nbs-port> ; ‘the NBS port from which the message originated’

<common-destination-nbs-port> ::= <common-nbs-port> ; ‘the NBS port to which the message will be sent’

<common-ms-isdn> ::= “;” | <common-phone-number> ; ‘ “;” means that no source address is given’

<common-destination-ms-isdn> ::= <common-ms-isdn> ; ‘the MS to send to’

<common-source-ms-isdn> ::= <common-ms-isdn> ; ‘the MS from which the message originated’

<common-smsc-ms-isdn> ::= “;” | <common-phone-number>

; ‘ “;” means that no SMSC is given, use default if available’

<common-source-smsc-ms-isdn> ::= <common-smsc-ms-isdn>

; ‘the SMSC through which message was received’

<common-destination-smsc-ms-isdn> ::= <common-smsc-ms-isdn> ; ‘the SMSC to send through’

Miscellaneous Definitions

<common-language> ::=

<default-char-not-ld>+ [ "-" <default-char-not-ld>+ ] | ; ‘For TTML’

<default-char-not-lf>+ [ "-" <default-char-not-lf>+ ] ; ‘For all others’

; ‘The language is as defined in RFC1766 [RFC_1766], with a language code followed by an optional countrycode. For example, US English is presented as “en-US”, whereas generic English is presented as “en”. Thelanguage codes and the country codes are case-sensitive.’

<common-boolean> ::= { “t” | “T” } <default-char-not-lf>* | ; ‘as in “True”’

{ “f” | “F” } <default-char-not-lf>* ; ‘as in “False”’

<common-flip-option> ::=

<common-flip-option-yes> | <common-flip-option-no> |

<common-flip-option-on> | <common-flip-option-off>

<common-flip-option-yes> ::= “Y” ; ‘case-insensitive’

<common-flip-option-no> ::= “N” ; ‘case-insensitive’

<common-flip-option-on> ::= “On” ; ‘case-insensitive’

<common-flip-option-off> ::= “Off” ; ‘case-insensitive’

<common-hex-digit> ::= <common-digit> | “A” | “B” | “C” | “D” | “E” | “F”

<common-charset-field> ::=

<common-charset-gsm-default> |

<common-charset-ascii> |

<common-charset-iso8859> |

<common-charset-ucs2>

<common-charset-gsm-default> ::= “GSM” ; ‘Refer to [GSM_03.38], [GSM_03.40]

<common-charset-ascii> ::= “ASCII” ; ‘US-ASCII: Deprecated’

<common-charset-iso8859> ::= “ISO-8859-1” ; ‘Refer to [ISO_8859]’

<common-charset-ucs2> ::= “UCS2” ; ‘Refer to [ISO/IEC_10646] and [Unicode]’

Smart Messaging 3-4


<common-version-field> ::= <common-digit>+ [ “.” <common-digit>+ ]

; ‘Version number. Format: major.minor version, i.e., “1.2“’

Date/Time Definitions

<common-date> ::= <year><month><day> [ <time> [ <type-designator> ] ]

;’The basic format of ISO 8601 for date and time. for example, 19971031T231210’.

<year> ::= <common-digit> <common-digit> <common-digit> <common-digit> ; ‘i.e., “1997”’

<month> ::= <common-digit> <common-digit> ; ‘i.e., “03”’ for March’

<day> ::= <common-digit> <common-digit> ; ‘i.e., “08”

<time> ::= “T” <hours> <minutes> <seconds>

<hours> ::= <common-digit> <common-digit> ; ’24-hour format’

<minutes> ::= <common-digit> <common-digit>

<seconds> ::= <common-digit> <common-digit>

<type-designator> ::= “Z” ; ’This means the time is Universal Time Coordinated (UTC)’

Smart Messaging 3-5


3.2 TRANSFERRING CONFIGURATION MESSAGES

Smart Messaging has been originally designed to operate over GSM Short Message Service. GSM ShortMessages are alphanumeric paging messages. When using keyword headers (that is, NBS or WDP is notused), all messages are transferred using GSM Class 1 Short Messages. If NBS or WDP are used, the bearerwill be selected and used according to the respective protocol specifications.

Some Smart Messaging-capable devices also support alternative methods of transport. It is possible to transferconfiguration messages and ringing tones as MIME objects over a suitable transfer protocol, such as HTTP(Hypertext Transfer Protocol) or email.

In order to transfer configuration messages or ringing tones over a MIME transport, the message is saved in afile having exactly the same syntax as a normal configuration message or a ringing tone. If the messagecontains textual information, the character set used must be the same character set which is used whentransferring the Smart Messages in GSM Short Messages. This text file is then sent to the client using one ofthe following MIME types:

application/vnd.nokia.configuration-message

application/vnd.nokia.ringing-tone

It is also highly recommended that the files have the suffix

.ncm

.rng

respectively. These identify the file types as Nokia configuration messages or ringing tones in a file systemwhich uses suffixes for file typing. The MIME transport should take into account that some Smart Messagesmay require a content encoding in order to be transferred over a 7-bit transmission channel.

For more information on MIME types in Nokia vendor tree (vnd.nokia), please contact Nokia Third PartyDeveloper Support.

Smart Messaging 3-6


3.3 COMPACT BUSINESS CARD

A business card containing typical contact information can be transmitted over the air interface using compactbusiness card format. Implementation of the service depends on the handset’s capabilities. Where a legacyhandset only shows the business card as a text message, high-end handset can extract the name and thenumber present in the business card and store them into the phone memory. With a smart phone the wholebusiness card can be stored in the contact directory.

In order to ensure compatibility with existing products on the market, the compact business card should not besent over NBS or WDP. However, receiving compact business cards should be enabled over NBS or WDP aswell.

The compact business card reader is listening to NBS port 5501decimal (157D hexadecimal).

The default usage of this format is on top of 7-bit transmission channel. The format can also be transmittedover wider than 7-bit transmission channels. In such cases the highest bits in the representation are set to zeroif there is a possibility for ambiguity.

3.3.1 SyntaxThe syntax of the compact business card is based on <line-feed> delimited presentation. The content isformatted as follows:

<compact-card-message> ::= <compact-card-keyword> <compact-card-body>

<compact-card-keyword> ::= “Business Card” <line-feed> ; ‘case-sensitive’

<compact-card-body> ::=

[ <name-field> ] <line-feed> ; ‘name’

[ <company-field> ] <line-feed> ; ‘company’

[ <title-field> ] <line-feed> ; ‘title’

[ <phone-item> ] <line-feed> ; ‘phone number’

[ <fax-item> ] <line-feed> ; ‘fax number’

[ <email-address> ] <line-feed> ; ‘email address’

[ <postal-address> ] <line-feed> ; ‘street address’

<name-field> ::= <default-char-not-lf>* ; ‘recommended contents: last-name first-name’

<company-field> ::= <default-char-not-lf>* ; ‘company name’

<title-field> ::= <default-char-not-lf>* ; ‘work title’

<phone-item> ::= ; ‘one or more phone numbers’

“tel” <space> [ <phone-number-item> ] |

“tel” <space> [ <phone-number-item> ] <line-feed>

<phone-item>

Smart Messaging 3-7


<phone-number-item> ::= [ <phone-number-item-identifier> ] <common-phone-number>

<phone-number-item-identifier> ::=

“(“ <default-char-not-lf>+ “)” <space> ; ‘identifier for the number, like “(GSM)”’

<fax-item> ::= ; ‘one or more fax numbers’

“fax” <space> [ <phone-number-item> ] |

“fax” <space> [ <phone-number-item> ] <line-feed>

<fax-item>

<email-address> ::= <default-char-not-lf>* ; ‘RFC822 based name@domain format ‘

<postal-address> ::=

<default-char-not-lf>* | ; ‘one or more lines of postal address information’

<default-char-not-lf>* <line-feed>

<postal-address>

Any of the supplementary information fields (<company-field> , <title-field>, <phone-item>, <fax-item>,<email-address>, <postal-address>) may be absent, but as the syntax shows, the field separators (<line-feed>)must exist.

The telephone numbers and fax numbers may have optional field labels (phone-number-item-identifier) inparenthesis to identify what kind of number is displayed. More than one telephone or fax number can bepresented with the compact business card format.

The postal address (<postal-address>) is always the last field in the format and can be more than one line.

3.3.2 Informative ExamplesFor example following messages are valid compact business cards:

Business CardJohn SmithNokia Mobile Phones Ltd.Design Engineertel +358 55 12345fax +358 55 [email protected]. Box 12FIN-12345 TAMPERE

Business CardJohn MillerSome Company Ltd.

tel +44 1 2345678tel (GSM) +44 123 123456fax +44 1 1234567fax (private) +44 123 456789

Smart Messaging 3-8


3.4 GENERIC BUSINESS CARD

Generic business card information transfer is based on Versit vCard specification. The vCard specificationdefines a format for electronic business cards. This format is suitable to be used as an interchange formatbetween applications or systems, and it is independent of the method used to transport it [vCard].

The vCard reader is listening to NBS port 226 decimal (E2 hexadecimal). When using a WAP stack, thevCard reader is listening to WDP port 9204 decimal (23F4 hexadecimal) or WTLS-secured WDP port 9206decimal (23F6 hexadecimal).

The default usage of this format is on top of 7-bit transmission channel, however, the vCard [vCard]specification enables transmission over both 7-bit and 8-bit transmission channels.

The set of supported fields and how they are interpreted may vary between different products. Please contactNokia Third Party Developer Support for more information.

Please note: It is strongly recommended that the vCard parser is also able to handle messages which conformto vCard 3.0, which is the text/directory MIME type specification [RFC_2425], [RFC_2426].

Please note: If interoperability with old NBS-only implementations is not critical, vCards should be sent to theWDP ports.

3.4.1 Informative ExamplesThe following message is an example of a valid generic business card:

BEGIN:VCARDVERSION:2.1N:Smith;MikeTEL;PREF:+55512345END:VCARD

Smart Messaging 3-9


3.5 SERVICE CARD

Service cards enable handset users to access easily services that normally require them to remember and toenter touch tone sequences. Businesses can provide their clients with the service cards that ease the use oftouch tone based services. In markets where touch tone based services are popular, like the US, service cardsmake greatly facilitate access to services as well as save people time and money. For example, rather thanentering the whole bank account number every time an individual calls the bank to hear balance information, aservice card entry can be selected to do this automatically. Other examples of service card possibilities includeaccess to a help desk or customer service, or template that a business might offer containing user-definedpersonal information like a bank account number.

In order to ensure compatibility with existing products on the market, service cards, like compact businesscards, should not be sent over NBS or WDP. However, as with compact business cards, it should be possible toreceive them over NBS or WDP. It is important to implement the service card reader in order to enablemessage reception without keyword checking (i.e. NBS only solutions).

The service card reader is listening to NBS port 5502 decimal (157E hexadecimal).

The primary use of this format is on top of 7-bit transmission channel. The format can also be transmittedover wider channels. In such cases the highest bits in the representation are set to zero if there is a possibilityfor ambiguity.

3.5.1 SyntaxThe service card syntax is the following:

<service-card-message> ::= < service-card-keyword> <service-card-body>

<service-card-keyword> ::= “Service Card” <line-feed> ; ‘case-sensitive’

<service-card-body> ::=

<provider-name-field> <line-feed> ; ‘name of the service provider’

<common-phone-number> <line-feed> ; ‘phone number’

<service-field> <line-feed> ; ‘service definition’

<provider-name-field> ::= <default-char-not-lf>* ; ‘name of the service provider’

<service-field> ::=

<service-definition> | ; ‘one or more service definitions’

<service-definition> <line-feed>

< service-field>

<service-definition> ::= <service-name> “:”<common-tel-char>* ; ‘the touch tone sequence to activate service’

<service-name> ::= <default-char-not-lf>*

The name (<name-field>) is the name of the service provider, and the phone number (<common-phone-number>) is its phone number. In service definition (<service-field>) the service name tells what service is

Smart Messaging 3-10


activated using this sequence. The DTMF-sequence will be sent to network when the service is selected. Thenumber of service-fields in a card is not limited.

In the DTMF-sequence character “w” commands the handset to wait dial-tone before dialing the rest of thesequence. Character “p” commands the handset to pause a predefined interval (typically 0,5 seconds) prior todialing the rest of the sequence.

3.5.2 Informative ExamplesAn example that shows how access to timetables and booking at Airline-number-one can be defined:

Service CardAirline-number-one+358 0 8823111Timetable: 123w2323Booking: 32p777

This example shows how to access National Bank phone bank account information:

Service CardNational Bank+15559886262Money Market Savings: 2p2p1p1234567890#1234#Checking: 2p2p1p1234567890#1234#



3.6 INTERNET ACCESS CONFIGURATION

Internet access point configuration information can be transmitted to handsets to enable automatic access pointconfiguration for the Internet email and Internet access used. The configuration support can be extended tocover also bookmarks, scripts, FTP, Telnet, terminal and WWW settings. Also GSM Short Message Centrenumbers and Voice Mail numbers can be configured similar way.

There are two flavours of Internet access point configuration messages. The simpler type is described in theBasic Configuration Syntax section, whereas the more complicated syntax is presented in the ExtendedConfiguration Syntax section.

If the message is not transferred over NBS or WDP, <iap-compatibility-header> should be used, and viceversa. When compatibility with older implementations is critical, the message should not be sent over NBS orWDP. Recipients should always be prepared to receive either variant of this message.

The Internet access point configuration data reader is listening to NBS port 5503 decimal (157F hexadecimal).

The default usage of this format is on top of a 7-bit transmission channel. The format can also be transmittedover wider than 7-bit transmission channels. In such cases the highest bits in the representation are set to zeroif there is a possibility for ambiguity.

Please note: When configuring Internet access, the configuration messages should only configure the set ofparameters which are crucial for the correct operation of the Internet access point. Some configurable featuresare user settings by nature and do not affect the operation of the Internet access point. Such settings shouldgenerally not be remotely configured.

Please note: Only use the smallest number of settings that you can. If a setting is not required, leave it out formaximum compatibility between different implementations, unless the product-specific documentationmandates its use.

Please note: Capabilities differ between different products. You should consult the appropriate developerdocumentation for the product you are planning to configure by using these messages. For information oncapabilities of a specific product, please contact Nokia Third Party Developer Support.

Please note: Service providers are recommended to take field length limits into consideration when designingconfiguration and setup of their devices. If a field identifier is present, but value of that field is left empty, thenthe empty value will be updated in the device; check for empty field values.

Please note: For security reasons, passwords should not be sent in the configuration messages.

3.6.1 Basic Configuration Syntax<iap-message> ::= [ <iap-compatibility-header> ] <notify-text> <info-body>

<iap-compatibility-header> ::= “//SIAP11” <line-feed> ; ‘optional compatibility header’

; ‘used without NBS headers’

<notify-text> ::= <default-char-not-lf>* <line-feed>

<info-body> ::= <basic-configuration-info>+ | <extended-configuration-info>

<basic-configuration-info> ::= <iap-info> | <mail-info>



3.6.1.1 Basic IAP<iap-info> ::= <iap-info-name> { <iap-parameter> <line-feed> }*

<iap-info-name> ::= “Iname:” <default-char-not-lf>* <line-feed> ; ‘maximum length 50 chars’

<iap-parameter> ::=

<iap-parameter-phone-number> |

<iap-parameter-user-name> |

<iap-parameter-prompt-for-password> |

<iap-parameter-password> |

<iap-parameter-modem-initialization> |

<iap-parameter-ip-address> |

<iap-parameter-primary-nameserver> |

<iap-parameter-secondary-nameserver> |

<iap-parameter-network-mask> |

<iap-parameter-default-gateway>

<iap-parameter-phone-number> ::= “Itel:” [ <common-phone-number> ] ; ‘maximum length 16 chars’

<iap-parameter-user-name> ::= "Iuid:" <default-char-not-lf>* ; ‘maximum length 50 chars’

<iap-parameter-prompt-for-password> ::= “Ipwp:” [ “Y” | “N” ] ; ‘whether to ask password from the’

; ‘user upon connecting’

<iap-parameter-password> ::= "Ipwd:" <default-char-not-lf>* ; ‘password’

; ‘password should not be included for

security reasons’

<iap-parameter-modem-initialization> ::= "Iini:" <default-char-not-lf>* ; ‘maximum length 50 chars’

<iap-parameter-ip-address> ::= "Iip:" [ <ip-string> ] ; ‘static IP address, if exists’

<iap-parameter-primary-nameserver> ::= "Idns1:" [ <ip-string> ] ; ‘primary name server (DNS)address’

<iap-parameter-secondary-nameserver> ::= "Idns2:" [ <ip-string> ] ; ‘secondary name server address’

<iap-parameter-network-mask> ::= "Imsk:" [ <ip-string> ] ; ‘network mask’

<iap-parameter-default-gateway> ::= "Idgw:" [ <ip-string> ] ; ‘default gateway’

<ip-string> ::= <byte-dec> "." <byte-dec> "." <byte-dec> "." <byte-dec>

<byte-dec> ::= <common-digit> [ [ <common-digit> ] <common-digit> ] ;‘value in range [0..255] decimal’

3.6.1.2 Basic Mail<mail-info> ::= <mail-iap-name> { <mail-parameter> <line-feed> }*

<mail-parameter> ::=

<mail-parameter-remote-mailbox-username> |

<mail-parameter-remote-mailbox-password> |

<mail-parameter-own-email-address> |

<mail-parameter-receiving-host> |

<mail-parameter-sending-host> |



<mail-parameter-remote-mailbox-protocol>

<mail-iap-name> ::= "Mname:" <default-char-not-lf>* <line-feed> ;‘used IAP name, max. 50 chars’

<mail-parameter-remote-mailbox-username> ::= "Muid:" <default-char-not-lf>* ; ‘remote mailbox user

name, maximum length

50 chars’

<mail-parameter-remote-mailbox-password> ::= "Mpwd:" <default-char-not-lf>* ; ‘remote mailbox password,maximum length 50 chars’

<mail-parameter-own-email-address> ::= "Madr:" [ <email-address> ] ; ‘the user’s email address,

maximum length 100 chars’

<mail-parameter-receiving-host> ::= "Mrcv:" [ <iaddress> ] ; ‘host name of the IMAP/POP server’

<mail-parameter-sending-host> ::= "Msnd:" [ <iaddress> ] ; ‘host name of the SMTP server’

<mail-parameter-remote-mailbox-protocol> ::= "Mpro:" <mail-protocol> ; ‘whether to use IMAP or POP’

<email-address> ::= <default-char-not-lf>* ; ‘RFC 822 based [email protected] format ‘

<iaddress> ::= <ip-string> | <hostname>

<hostname> ::= <default-char-not-lf>* ; ’a host name in DNS, maximum length 50chars’

<mail-protocol> ::= “IM” |

“PO” ; ‘IM = IMAP4, PO = POP3’

3.6.2 Informative ExamplesAn example with minimum information to setup:

Your RNET access granted !Iname:Provider nameIuid:UsernameIpwd:secretpwdItel:+123456789012345

Typical situation:

Welcome !Iname:ProviderIuid:UserIpwd:secretItel:+123456789012345Iip:123.123.123.123Idns1:123.123.123.123Idns2:123.123.123.123

A special situation that arises when no network mask autoconfiguration is available from the service provider.(The strings have to be shortened if all information is to be sent in one SMS):

Iname:ProvIuid:Us3



Ipwd:secr56Itel:+123456789012345Iip:123.123.123.123Idns1:123.123.123.123Idns2:123.123.123.123Imsk:255.255.255.252

Typical mail service information:

Note TextMname:Provider nameMuid:UsernameMpwd:secretpwMadr:[email protected]:imapserver.provid.netMsnd:smtpserver.provid.netMpro:IM

3.6.3 Extended Configuration SyntaxExtended configuration syntax enables more configuration message types.

<extended-configuration-info> ::=

<extended-iap-info> |

<extended-mail-info> |

<hotlist-item-info> |

<script-info> |

<sms-info> |

<telnet-info> |

<terminal-info> |

<www-info> |

<ttml-info> |

<ftp-info> |

<internet-info> |

<telephone-info> |

<www-autofetch-info>

3.6.3.1 Extended IAP<extended-iap-info> ::=

<iap-info-name> { <iap-parameter> <line-feed> | <extended-iap-parameter> <line-feed> }*

<extended-iap-parameter> :: =

<iap-parameter-extended-phone-number> |

<iap-parameter-http-no-proxy-for> |

<iap-parameter-http-port> |

<iap-parameter-http-proxy> |

<iap-parameter-login-customisation> |



<iap-parameter-compression> |

<iap-parameter-secure-proxy> |

<iap-parameter-secure-port>

<iap-parameter-extended-phone-number> ::=

“Itel:” [ <common-phone-number> ] ; ‘phone number of the dial-up pool,

maximum length 30 chars’

<iap-parameter-http-no-proxy-for> ::= “Inop:” <default-char-not-lf>* ; ‘domains for which no HTTP

proxy will be used’

<iap-parameter-http-port> ::= “Ippo:” <common-digit>* ; ‘HTTP proxy port, maximum length 5 digits’

<iap-parameter-http-proxy> ::= “Iprx:” <ip-string> ; ‘HTTP proxy address’

<iap-parameter-login-customisation> ::= “Ilgn:” <login-type> ; ‘whether to use login customisation’

<iap-parameter-compression> ::= " Icmp:" [ “Y” | “N” ] ; ' whether to use PPP compression'

<iap-parameter-secure-proxy> ::= "Isrx:" <ip-string> ; 'SSL tunneling proxy IP address'

<iap-parameter-secure-port> ::= "Ispo:" <common-digit> ; 'SSL tunneling proxy port,

maximum length 5 digits’

<login-type> ::= “0” | “1” | <default-char-not-lf>* ; ‘ “0” for none, “1” for manual,

; or name of the script.’

3.6.3.2 Extended MailExtended mail settings control the features of the device’s email client.

<extended-mail-info> ::=

[ <mail-info-name> ] { <mail-parameter> <line-feed> | <extended-mail-parameter> <line-feed> }*

<extended-mail-parameter> :: =

<mail-parameter-copy-to-own-email-address> |

<mail-parameter-delete-fetched> |

<mail-parameter-fetch-attachments> |

<mail-parameter-fetch-headers> |

<mail-parameter-mime-encoding> |

<mail-parameter-remote-mailbox-folder> |

<mail-parameter-selected-font> |

<mail-parameter-send-mail> |

<mail-parameter-show-header-fields> |

<mail-parameter-define-remote-mailbox>

<mail-parameter-copy-to-own-email-address> ::= "Mcpy:" <common-flip-option> ; ‘whether to send a copy to

own address’

<mail-parameter-delete-fetched> ::= "Mdel:" <common-flip-option> ; ’whether to delete fetched

mail from remote server’

<mail-parameter-fetch-attachments> ::= "Matt:" <common-flip-option> ; ‘whether to retrieveattachments’



<mail-parameter-fetch-headers> ::= "Mhdr:" <fetch-option> ; ‘which headers to retrieve’

<mail-parameter-mime-encoding> ::= "Mime:" <common-flip-option> ; ‘whether to use MIME

encoding in outgoing mail’

<mail-parameter-remote-mailbox-folder> ::= "Mbox:" <default-char-not-lf>* ; ‘remote mailbox folder name, maximum length 30 chars’

<mail-parameter-selected-font> ::= "Mfnt:" <font-selection> ; ‘mail editor typeface

; (use not recommended)’

<mail-parameter-send-mail> ::= "Msen:" <mail-send-option> ; ‘when to send mail’

<mail-parameter-show-header-fields> ::= "Mshf:" <mail-show-headers-option> ; ‘which header fields to show’

<mail-parameter-define-remote-mailbox> ::= "Mid:" <default-char-not-lf>* ; ‘remote mailbox name’

<fetch-option> ::= <fetch-option-all> | <fetch-option-recent>

<fetch-option-all> ::= { “a” | “A” } <default-char-not-lf>* ; ’as in “All”’

<fetch-option-recent> ::= { “r” | “R” } <default-char-not-lf>* ; ’as in “Recent”’

<font-selection> ::= <font-urw-mono> | <font-urw-roman> | <font-urw-sans>

<font-urw-mono> ::= { “m” | “M” } <default-char-not-lf>* ; ’as in “Mono”’

<font-urw-roman> ::= { “r” | “R” } <default-char-not-lf>* ; ’as in “Roman”’

<font-urw-sans> ::= { “s” | “S” } <default-char-not-lf>* ; ’as in “Sans”’

<mail-send-option> ::=

<mail-send-option-later> |

<mail-send-option-next> |

<mail-send-option-now>

<mail-send-option-later> ::= { “u” | “U” } <default-char-not-lf>* ; ’as in “Upon request”.’

<mail-send-option-next> ::= { “d” | “D” } <default-char-not-lf>* ; ’as in “During next connection”.’

<mail-send-option-now> ::= { “i” | “I” } <default-char-not-lf>* ; ’as in “Immediately”.’

<mail-show-headers-option> ::=

<mail-show-headers-options-none> |

<mail-show-headers-options-basic> |

<mail-show-headers-options-all>

<mail-show-headers-options-none> ::= { “n” | “N” } <default-char-not-lf>* ;’as in “None”.’

<mail-show-headers-options-basic> ::= { “b” | “B” } <default-char-not-lf>* ;’as in “Basic”.’

<mail-show-headers-options-all> ::= { “a” | “A” } <default-char-not-lf>* ;’as in “All”.’

3.6.3.3 WWW Hotlist Item SettingsWWW hotlist item settings control the addition of new items to the bookmark (hotlist) of the device’s WorldWide Web browser.

<hotlist-item-info> ::= <hotlist-item-group>+



<hotlist-item-group> ::=

<hotlist-item-name> <line-feed>

<hotlist-item-url> <line-feed>

[ <hotlist-autoselect-iap> <line-feed> ]

[ <hotlist-access-point> <line-feed> ]

[ <hotlist-folder> <line-feed> ]

<hotlist-item-name> ::= “Hname:” <default-char-not-lf>* ; ‘the name of the hotlist item’

<hotlist-item-url> ::= “Hurl:” <default-char-not-lf>* ; ‘location (URL) of the document’

<hotlist-autoselect-iap> ::= “Haap:” <common-flip-option> ; ‘whether to automatically select IAP

; when fetching’

<hotlist-access-point> ::= “Hiap:” <default-char-not-lf>* ; ‘which IAP to use’

<hotlist-folder> ::= "Hdir:" <default-char-not-lf>* ; ‘in which folder to place the hotlist item’

3.6.3.4 Script SettingsScript settings control the addition of new login scripts to log into an IAP.

<script-info> ::=

<script-name> <line-feed>

<script-type> [ <space> <script-version> ]<line-feed>

<script-data>

<script-name> ::= “Pname:” <default-char-not-lf>* ; ’filename, maximum length 32‘

<script-type> ::= “Ptype:” <script-type-identifier> ; ‘for what the script is used for’

<script-type-identifier> ::= “PPPS” | "PPP" | <default-char-not-lf-or-space>* ; ‘see product specific documentation’

<script-version> ::= <common-version-field> ; ‘script version number’

<script-data> ::= “Pdata:” <common-information-content> ; ‘the script itself’

<script-addition> ::= “Padd:” <common-information-content> ; ‘additional data for an existing script’

Sample script message:

Pname:script.datPtype:PPPSPdata:47:This is my script line1and this is the line2

3.6.3.5 SMS SettingsSMS settings control the features of the device’s Short Messaging application.

<sms-info> ::= {<sms-item> <line-feed> }+

<sms-item> ::= [ <sms-service-center-name> ] <sms-service-center-number>

<sms-service-center-name> ::= "Sname:" <default-char-not-lf>* ; ‘GSM SMSC name’

<sms-service-center-number> ::= “Stel:” [ <common-phone-number> ] ; ‘GSM SMSC telephone number’



3.6.3.6 Telnet SettingsTelnet settings control the features of the device’s Telnet application.

<telnet-info> ::=

{ <telnet-connection-name> <line-feed> { <telnet-item> <line-feed> }* }+

<telnet-connection-name> ::= “Tname:” <default-char-not-lf>* ; ‘Telnet connection name’

<telnet-item> ::=

<telnet-backspace-key> |

<telnet-destination-host> |

<telnet-internet-access>

<telnet-backspace-key> ::= “Tdel:” <backspace-key> ; ‘which backspace code to send’

<telnet-destination-host> ::= “Thst:” <default-char-not-lf>* ; ‘destination host name’

<telnet-internet-access> ::= “Tiap:” <default-char-not-lf>* ; ‘which IAP to use’

<backspace-key> ::= <key-backspace> | <key-del>

<key-backspace> = “BS” ; ‘send backspace (ISO 8859-1 810)’

<key-del> ::= “DEL” ; ‘send delete (ISO 8859-1 12710)’

3.6.3.7 Terminal SettingsTerminal settings control the features of the device’s terminal application.

<terminal-info> ::=

{ <terminal-connection-name> <line-feed> { <terminal-item> <line-feed> }* }+

<terminal-connection-name> ::= “Rname:” <default-char-not-lf>* ; ‘terminal connection name’

<terminal-item> ::=

<terminal-backspace-key> |

<terminal-data-bits> |

<terminal-line-end-convention> |

<terminal-local-echo> |

<terminal-modem-init> |

<terminal-parity> |

<terminal-phone-number> |

<terminal-stop-bits> |

<terminal-incoming-echo> |

<terminal-incoming-line-end>

<terminal-backspace-key> ::= “Rdel:” <backspace-key> ; ‘which backspace code to send’

<terminal-data-bits> ::= “Rdat:” <terminal-databits> ; ‘number of data bits’

<terminal-line-end-convention> ::= “Rend:” <terminal-line-end> ; ‘which line-end convention to use’

<terminal-local-echo> ::= “Rech:” <common-flip-option> ; ‘whether to locally echo characters’

<terminal-modem-init> ::= “Rini:” <default-char-not-lf>* ; ‘modem initialization string to use’



<terminal-parity> ::= “Rpar:” <terminal-parity> ; ‘parity to be used’

<terminal-phone-number> ::= “Rtel:” <common-phone-number> ; ‘phone number to call’

<terminal-stop-bits> ::= “Rstp:” <terminal-stopbits> ; ‘number of stop bits’

<terminal-incoming-echo> ::= " Reci:" <common-flip-option> ; ‘whether to locally echo characters during incoming data calls’

<terminal-incoming-line-end> ::=" Reni:" <terminal-line-end> ; ‘which line-end convention to use during incoming data calls’

<terminal-databits> ::= “7” | “8” ; ‘7 or 8 data bits’

<terminal-line-end> ::= “CR” | “LF” | “CRLF” ; ‘line end: CR (ISO 8859-1 1310), LF (ISO 8859-1 1010) or CR+LF pair’

<terminal-parity> ::= <terminal-parity-none> | <terminal-parity-odd> | <terminal-parity-even>

<terminal-parity-none> ::= { “n” | “N” } <default-char-not-lf>* ; ‘as in “None”’

<terminal-parity-odd> ::= { “o” | “O” } <default-char-not-lf>* ; ‘as in “Odd”’

<terminal-parity-even> ::= { “e” | “E” } <default-char-not-lf>* ; ‘as in “Even”’

<terminal-stopbits> ::= “1” | “2” ; ‘1 or 2 stop bits’

3.6.3.8 WWW SettingsWWW settings control the features of the device’s World Wide Web browser.

<www-info> ::= {<www-item> <line-feed> }+

<www-item> ::= <www-access-point>

<www-access-point> ::= “Wiap:” <default-char-not-lf>* ; ‘default IAP to use’

3.6.3.9 TTML SettingsTTML settings control the features of the device’s TTML browser.

<ttml-info> ::= {<ttml-access-point> <line-feed> }+

<ttml-access-point> ::=

“Bsap:” <default-char-not-lf>* <line-feed> ;’maximum title length 10 characters’

<common-destination-ms-isdn> “/“ <common-destination-smsc-ms-isdn>

3.6.3.10 FTP SettingsFTP settings control the features of the device’s File Transfer Protocol application.

<ftp-info> ::=

{ <ftp-connection-name> <line-feed> { <ftp-item> <line-feed> }* }+

<ftp-connection-name> ::= <ftp-parameter-name> ::= "Fname:" <default-char-not-If>*

; ‘FTP connection name’

<ftp-item> ::=

<ftp-parameter-access-point> ::= "Fiap:" <access-point> | ; ‘which IAP to use’

<ftp-parameter-ip-address> ::= "Fip:" <ip-string> | ; ‘IP address of the FTP server’

<ftp-parameter-password> ::= "Fpwd:" <default-char-not-If>* | ; ‘FTP server password’



<ftp-parameter-port> ::= "Fprt:" <common-digit> | ; ‘FTP server port’

<ftp-parameter-username> ::= "Fuid:" <default-char-not-If>* ; ‘FTP server user name’

3.6.3.11 Internet SettingsInternet settings describe the settings for the data connection.

<internet-info> ::= {<internet-item> <line-feed>}+

<internet-item> ::= <internet-parameter-compression> | <internet-parameter-modem-initialization>

<internet-parameter-compression> ::= "Iv42:" <common-flip-option> ; ‘whether to use V.42bis’

<internet-parameter-modem-initialization> ::= "Imdm:" <internet-modem> ; ‘modem type to use’

<internet-modem> ::=

"0" | ; ' for "Autobauding"

"2" | ; ' for "Fixed 9600 b/s"

"4" | ; ' for "Fixed 14400 b/s"

<default-char-not-If> ; ' for "Custom"

3.6.3.12 Telephone SettingsTelephone settings configure the voice mailbox number.

<telephone-info> ::= <telephone -item>

<telephone-item> ::= <telephone–voice-mailbox-number>

<telephone–voice-mailbox-number> ::= "Tbox:" <common-phone-number> ; ‘phone number to call’

3.6.3.13 WWW Autofetch SettingsWWW Autofetch settings control how the terminal downloads material from the World Wide Webautomatically, without user intervention.

<www-autofetch-info> ::=

{ <www-autofetch-url> <line-feed> { <www-autofetch-item> <line-feed> }* }+

<www-autofetch-item> ::=

<www-autofetch-body> |

<www-autofetch-headers> |

<www-autofetch-iap> |

<www-autofetch-method> |

<www-autofetch-name>

<www-autofetch-url> ::= "Aurl:" <default-char-not-If>* ; ‘location (URL) to fetch’

<www-autofetch-body> ::= "Abdy:" <default-char-not-If>* ; ‘send this data as HTTP POST

body part’

<www-autofetch-headers> ::= "Ahdr:" <default-char-not-If>* ; ‘additional HTTP headers’



<www-autofetch-iap> ::= "Aiap:" <default-char-not-If>* ; ‘IAP to use’

<www-autofetch-method> ::= "Amth:" <www-autofetch-method-parametres> ; ‘which HTTP method touse’

<www-autofetch-name> ::= "Aname:" <default-char-not-If>* ; ‘bookmark name’

<www-autofetch-method-parametres> ::= <method-get> | <method_post> | <method_put>

<method-get> ::= "1" ; ' default method (HTTP GET)'

<method-post> ::= "2" ; ‘HTTP POST (form submission)’

<method-put> ::= "3" ; ‘HTTP PUT’



3.7 CALENDAR

Calendar information transfer is based on Versit vCalendar specification. The vCalendar specification definesa format for electronic calendaring and scheduling. This format is suitable to be used as an interchange formatbetween applications or systems, and it is independent of the method used to transport it.

The vCalendar enables exchange of event and to-do types of calendaring and scheduling events. An eventrepresents a scheduled amount of time on a calendar, and a to-do item represents an action-item orassignment. [vCalendar]

The vCalendar reader is listening to NBS port 228 decimal (E4 hexadecimal). When using a WAP stack thevCalendar reader is listening to WDP port 9205 decimal (23F5 hexadecimal) or WTLS-secured WDP port9207 decimal (23F7 hexadecimal).

The default usage of this format is on top of 7-bit transmission channel, however, the vCalendar [vCalendar]specification enables transmission over both 7-bit and 8-bit transmission channels.

The set of supported fields may vary between different products. Please contact Nokia Third Party DeveloperSupport for more information.

Please note: If interoperability with old NBS-only products is not critical, the new WDP port numbers shouldbe used.

3.7.1 Informative ExamplesThis section shows some examples of how calendar data is presented.

A meeting in Portal on 6th of September 1996 from 10 am to 12 PM.BEGIN:VCALENDARVERSION:1.0BEGIN:VEVENTDESCRIPTION:Steering Group meeting in PortalDTSTART:19960906T100000DTEND:19960906T120000END:VEVENTEND:VCALENDAR

A project meeting in Portal on 3rd of October 1997 from 9 am to 12 PM with a reminder 15 minutes before.BEGIN:VCALENDARVERSION:1.0BEGIN:VEVENTDESCRIPTION:Project meeting in PortalDTSTART:19971003T090000DTEND:19971003T120000AALARM:19971003T084500;;;END:VEVENTEND:VCALENDAR



3.8 RINGING TONES

The ringing tone format enables ringing tones to be sent to a wide variety of handsets. Depending on thehandset implementation, it may be possible for the user to create ringing tones and then send them to otherhandsets.

The ringing tone format is handset independent, and describes only the audio related information. It enablestransmission of both basic songs and temporary songs. A basic song is intended to be saved in a handset whilethe temporary songs can be used together with an alert router to implement message notification with a specialringing tone.

The ringing tone reader is listening to NBS port 5505 decimal (1581 hexadecimal).

Ringing tones require 8-bit communication channel configuration. Please refer to NBS specifications[NBS_SPEC] on how to setup 8-bit channel if you are using NBS.

The default character set, if not otherwise indicated, is ISO 8859-1 [ISO_8859].

Building blocks of the ringing tone messages are expressed as bit strings (base-2 values). These areconcatenated and the resulting bit string is transferred in octets (8 bits in each byte).

3.8.1 Syntax<ringing-tone-programming-language> ::= <command>+

<command> ::=

<command-length> <command-part>+ |

<command-end>

<command-length> ::= ‘binary [00000001 .. 11111111], indicates how many command parts there are in thecommand. If necessary, filler bits are added to ensure that <command-part> is always octet-aligned.’

<command-end> ::= ‘binary [00000000]. This indicates the end of the ringing tone programming language.’

<command-part> ::=

<ringing-tone-programming> |

<unicode> |

<cancel-command> <cancel-command-specifier> |

<sound> <sound-command-specifier>

The Ringing Tone programming requires that the order of the command parts is the following: <ringing-tone-programming>, [ <unicode> ,] <sound>.



Table 3.8-1. Command-Part Encoding

Command Value (binary)<cancel-command> 0000 101<ringing-tone-programming> 0100 101<sound> 0011 101<unicode> 0100 010

<cancel-command-specifier> ::= <unicode>

<sound-command-specifier> ::=

<basic-song-type> <basic-song> |

<temporary-song-type> <temporary-song> |

<midi-song-type> <midi-song> |

<digitized-song-type> <digitized-song>

Table 3.8-2. Song Type Encoding

Song type Value (binary)<basic-song-type> 001<temporary-song-type> 010<midi-song-type> 011<digitized-song-type> 100

<basic-song> ::= <song-title> <temporary-song>

<song-title> ::= <text-length> <text>

<text> ::= <default-char>+ | ; ‘Unicode disabled’

<ISO-10646-char>+ ; ‘Unicode enabled’

<text-length> ::= ‘binary [0000 .. 1111] indicating how many characters are used for the following text. Forexample, in case of Unicode, this counts the number of 16-bit Unicode characters.’

<temporary-song> ::= <song-sequence-length> <song-sequence>

<song-sequence-length> ::= ‘binary [00000000 .. 11111111]; Indicates how many song patterns follow.’

<song-sequence> ::= <song-pattern>+

<song-pattern> ::=

<pattern-header> |

<pattern-header> <pattern-instruction>+

<pattern-header> ::= <pattern-header-id> <pattern-id> <loop-value> <pattern-specifier>



Table 3.8-3. <pattern-id> Encoding

Pattern ID ValueA-part binary 00B-part binary 01C-part binary 10D-part binary 11

<loop-value> ::= ‘binary [0000 .. 1111]; Indicates how many times the pattern should be repeated. Value zeromeans no repeat. Value binary 1111 means infinite.’

<pattern-specifier> ::= <already-defined-pattern> | <length-of-the-new-pattern>

<already-defined-pattern> ::= ‘binary [00000000]; This indicates that a already defined pattern is used again.’

<length-of-the-new-pattern> ::= ‘binary [00000001 .. 11111111]; Indicates how many pattern instructions thereare in the song pattern. Value zero is illegal.’

<pattern-instruction> ::=

<note-instruction> | <scale-instruction> | <style-instruction> |

<tempo-instruction> | <volume-instruction>

<midi-song-type> ::= ‘MIDI data. Reserved for future extension.

<digitized-song-type> ::= ‘Digitized sound data. Reserved for future extension.’

Table 3.8-4. Instruction Encoding

Instruction Sequence<note-instruction> <note-instruction-id> <note-value> <note-duration> <note-duration-

specifier><scale-instruction> <scale-instruction-id> <note-scale><style-instruction> <style-instruction-id> <style-value><tempo-instruction> <tempo-instruction-id> <beats-per-minute><volume-instruction> <volume-instruction-id> <volume>

Table 3.8-5. Instruction ID Encoding

Instruction ID Value (binary)<pattern-header-id> 000<note-instruction-id> 001<scale-instruction-id> 010<style-instruction-id> 011<tempo-instruction-id> 100<volume-instruction-id> 101



Table 3.8-6. Note-Value Encoding

Note value Value (binary)pause 0000C 0001Cis ‘i.e. Des’ 0010D 0011Dis ‘i.e. Es’ 0100E 0101F 0110Fis ‘i.e. Ges’ 0111G 1000Gis ‘i.e. As’ 1001A 1010Ais ‘i.e. B’ 1011H 1100RESERVED 1101RESERVED 1110RESERVED 1111

Table 3.8-7. Note-Duration Encoding

Note duration Value (binary)Full-note 0001/2-note 0011/4-note 0101/8-note 0111/16-note 1001/32-note 101RESERVED 110RESERVED 111

Table 3.8-8. Note-Duration-Specifier Encoding

Note duration specifier Value (binary)No special duration 00Dotted note 01Double dotted note 102/3 length 11



Table 3.8-9. Note-Scale Encoding

Note Scale Value (binary)Scale-1 (i.e. Note A is 440 Hz) 00Scale-2 (i.e. Note A is 880 Hz), default 01Scale-3 (i.e. Note A is 1.76 kHz) 10Scale-4 (i.e. Note A is 3.52 kHz) 11

Table 3.8-10. Style-Value Encoding

Style Value (binary)Natural Style (rest between notes), default 00Continuous Style (no rest between notes) 01Staccato Style (shorter notes and longer rest period) 10RESERVED 11



Table 3.8-11. Beats-per-Minute Encoding

Beats per Minute Value (binary)25, i.e., length of ¼ note = 2.40 sec. 0000 028, i.e., length of ¼ note = 2.14 sec. 0000 131, i.e., length of ¼ note = 1.90 sec. 0001 035, i.e., length of ¼ note = 1.70 sec. 0001 140, i.e., length of ¼ note = 1.51 sec. 0010 045, i.e., length of ¼ note = 1.35 sec. 0010 150, i.e., length of ¼ note = 1.20 sec. 0011 056, i.e., length of ¼ note = 1.07 sec. 0011 163, i.e., length of ¼ note = 0.95 sec, default 0100 070, i.e., length of ¼ note = 0.85 sec. 0100 180, i.e., length of ¼ note = 0.76 sec. 0101 090, i.e., length of ¼ note = 0.67 sec. 0101 1100, i.e., length of ¼ note = 0.60 sec. 0110 0112, i.e., length of ¼ note = 0.54 sec. 0110 1125, i.e., length of ¼ note = 0.48 sec. 0111 0140, i.e., length of ¼ note = 0.43 sec. 0111 1160, i.e., length of ¼ note = 0.38 sec. 1000 0180, i.e., length of ¼ note = 0.34 sec. 1000 1200, i.e., length of ¼ note = 0.30 sec. 1001 0225, i.e., length of ¼ note = 0.27 sec. 1001 1250, i.e., length of ¼ note = 0.24 sec. 1010 0285, i.e., length of ¼ note = 0.21 sec. 1010 1320, i.e., length of ¼ note = 0.19 sec. 1011 0355, i.e., length of ¼ note = 0.17 sec. 1011 1400, i.e., length of ¼ note = 0.15 sec. 1100 0450, i.e., length of ¼ note = 0.13 sec. 1100 1500, i.e., length of ¼ note = 0.12 sec. 1101 0565, i.e., length of ¼ note = 0.10 sec. 1101 1635, i.e., length of ¼ note = 0.09 sec. 1110 0715, i.e., length of ¼ note = 0.08 sec. 1110 1800, i.e., length of ¼ note = 0.07 sec. 1111 0900, i.e., length of ¼ note = 0.06 sec. 1111 1



Table 3.8-12. Volume Encoding

Volume Value (binary)tone-off 0000level-1 0001level-2 0010level-3 0011level-4 0100level-5 0101level-6 0110level-7, default 0111level-8 1000level-9 1001level-10 1010level-11 1011level-12 1100level-13 1101level-14 1110level-15 1111



3.9 GRAPHICAL LOGOS AND ICONS

The OTA bitmap format enables graphical information to be sent to a wide variety of handsets. Depending onthe handset implementation, it may be possible for the user to create graphical objects and then send them toother handsets. Various applications can use this information to create more illustrative and attractive outlookfor the application.

The OTA bitmap format is handset independent, and describes only the graphical information. In addition tothe OTA bitmap format two different applications using OTA bitmap format is specified here.

Calling Line Identification (CLI) icon is a bitmap which can be attached to some number or numbers in thehandsets phonebook (a caller group). When caller is identified, the attached CLI icon is shown alongside otherappropriate information like name and/or number of the caller. CLI icon format doesn’t contain anyphonebook information so the linking between phonebook entry and CLI icon must be done in handset.

CLI Icon Reader is listening to NBS port 5507 decimal (1583 hexadecimal).

Operator Logo is a bitmap which can be shown alongside with operator identification when the display of thehandset is in idle mode. Operator Logo format contains operator identification information and expirationdate. It is up to handset implementation how to this information is used.

Operator Logo Reader is listening to NBS port 5506 decimal (1582 hexadecimal). Both CLI Icon and OperatorLogo require 8-bit communication channel configuration. If you are using NBS, please refer to NBSspecifications [NBS_SPEC] on how to setup 8-bit channel.

The default character set is ISO 8859-1.

OTA bitmap is usually used as a building block in other Smart Messages. As the OTA bitmap may containpalette information whose length cannot be known in advance, the encapsulating short message should eitherplace the OTA bitmap at the end of the Smart Message or have a length field which can be utilized usingparsing to determine the end of the OTA bitmap.

3.9.1 OTA Bitmap Syntax<ota-bitmap> ::= <header> <image- data> [<palette>]

<header>::=<infofield> [<extfield>]* <width> <height> <depth>

<infofield>::= ‘Octet which is defined in table 3.8.1-2’

<extfield>::= ‘Octet which is defined in tables 3.8.1-3 and 3.8.1-4’

<width> ::= <common-hex-digit> <common-hex-digit>

[ <common-hex-digit> <common-hex-digit> ]

; ‘Horizontal width of the bitmap in pixels. Field width depends on <infofield> bit 4.’

<height> ::= <common-hex-digit> <common-hex-digit>

[ <common-hex-digit> <common-hex-digit> ]

; ‘Vertical height of the bitmap in pixels. Field width depends on <infofield> bit 4.’

<depth> ::= <common-hex-digit> <common-hex-digit> ; ‘Number of colors or gray shades’

<image-data> ::= <main-image> [<animated- image>]* ;’There can be 0 to 15 animated images’



<main-image> ::= ‘Bitmap formed according to image data structure description below’

<animated-image> ::= ‘Bitmap formed according to image data structure description below’

<palette> ::= ‘Optional palette information format, not defined in this version of the specification. Presentif <infofield> bit 5 is set.’

Table 3.88-1-1. Length of Header Parts

Data Type Length in BitsInfoField 8ExtField 8Width 8 or 16Height 8 or 16Depth 8

Table 3.88-1-2. Infofield description

InfoField, description BitConcatenation flag, 1 = More will follow, 0 = Last octet 7Compression, 1 = Compression, 0 = No compression 6External palette, 1 = Used, 0 = Not used 5Max. size of icon, 1 = 16 bit, 0 = 8 bit 4Number of animated icons, msb 3Number of animated icons 2Number of animated icons 1Number of animated icons, lsb 0

Table 3.88-1-3. Extended Field 0 description

ExtField 0, description BitConcatenation flag, 1 = More will follow, 0 = Last octet 7Bitmap Version information 6Bitmap Version information 5Bitmap Version information 4Reserved 3Reserved 2Reserved 1Reserved 0



Table 3.88-1-4. Extended Fields 1-15 description

ExtField 1..n, description BitConcatenation flag, 1 = More will follow, 0 = Last octet 7Reserved 6Reserved 5Reserved 4Reserved 3Reserved 2Reserved 1Reserved 0

3.9.1.1 Coding RulesThe format described here is a pure bitmap format, no data stream type handling is supported; bitmap isassumed to be accessible as a whole for the decoder. Also no error correction or checksums are included forthis format but the decoder is assumed to have an access to error free data.

In this version of the specification definition of Palette, Compression and Animation scheme is left open to bedefined in future. I.e. only static black and white images are fully defined in this version of the specification.

To ensure backward compatibility between today’s simple black and white only devices and more advanceddevices in the future following decoding and encoding recommendations are given:

• If bitmap fits into 8-bit boundaries, encoder must use 8-bit presentation

• Encoder takes care of color reduction so that the first plane of the multicolor bitmap containsthe black and white information.

• Pure black and white only capable decoders show only the first plane of the multicolor bitmaps.

• Decoders which are capable to process exclusively non-animated bitmaps show only the firstbitmap of animation sequence.

• Decoder not capable to decompress doesn’t show compressed icon at all.

• If the bitmap is bigger than display the bitmap is cropped so that bitmap is shown starting fromupper left corner to the lower right corner of the display.

3.9.1.2 Image Data StructureAn image comprises <Depth> planes where first plane is black and white mask and other planes givesadditional color information defined in the palette. Scanning of the pixels in a plane will be done row by row.Rows will be scanned from top to bottom and pixels inside the row will be scanned from left to right.

In order to fully utilize the available bandwidth no filler bits are used in the end of the row, fillers are put endof the whole bitmap if the size of the bitmap is not divisible with eight. Filler bits assume value zero.

3.9.2 CLI Icon Syntax<cli-icon> ::= <cli-header> <ota-bitmap>

<cli-header> ::= <cli-version> <cli-header-body>

<cli-version> ::= “0” ;‘Identifier for CLI icon version, current version is zero (0).



<cli-header- body> ::= ‘With current version 0 this field will be skipped altogether because no additional data issupported’

3.9.2.1 Example of a CLI Icon MessageThis logo is default logo for the “family” caller group. The recipient associates the given logo with one of thecaller groups in the phone.

00 Protocol IdentifierF5 Data Coding Scheme00 Validity Period8B User Data lengthUser Data (in hex):06 User Data Header Length05 IEI04 IEDL1583 Destination Port0000 Originator Port00480E01 Ota Icon Header0000000000000000 Ota Icon Data00038F71E0000000000004718E3000000000000921241800000000000A01401800000000000A0140180000000000080100180000000000040180300000000000020340600000000000010620C00000000000008C1180000000000000580B000000000000003006000000000000000000000000000000

3.9.3 Operator Logo Syntax<operator-logo> ::= <operator-logo-header> <line-feed> <ota-bitmap>

<operator-logo-header> ::= <operator-logo-Version> <operator-logo-header-body>

<operator-logo-version> ::= “0” ;‘Identifier for Operator Logo version, current version is zero (0). '

<operator-logo-header-body> ::= <operator-information> <validity-period>

<operator-information> ::= <mcc> “,” <mnc> ; ‘For GSM only; other systems have another version’

<mcc> ::= <common-hex-digit> <common-hex-digit> <common-hex-digit> <common-hex-digit>; ‘GSM Mobile Country Code, little-endian BCD, filled with F16’

<mnc> ::= <common-hex-digit> <common-hex-digit>

; ‘GSM Mobile Network Code, little-endian BCD,

filled with F16’

<validity-period> ::= <common-date> ; ‘Expiration date’



3.10 EMAIL NOTIFICATION

Email servers can use this message to notify cellular terminals of the existence of new messages in the mailserver. This message format is a legacy format.

When not transferring this message over NBS or WDP, <email-compatibility-header> must be used, and viceversa. If compatibility with existing products is critical, the message should not be sent over NBS or WDP.However, the recipients should be prepared to receive both variants of the message.

The email notification reader is listening to NBS port 5512 decimal (1588 hexadecimal).

The default usage of this format is on top of 7-bit transmission channel. The format can also be transmittedover wider channels. In such cases the highest bits in the representation are set to zero if there is a possibilityfor ambiguity.

Extended Email notification chapter specifies the format of smart message which can be used to build mailheadline view without establishing connection to the remote mailbox or just to notify the user of new mail, iflegacy phone is used. Two different modes are described: restricted mode and non-restricted mode. In therestricted mode, the total length of the smart message MUST NOT be more than 160 characters (or 140characters, if smart message contains 8-bit characters). This is achieved by cutting subject field so that the sizelimit is not exceeded and/or leaving unimportant fields out of mail notification. In the non-restricted mode, nosize limit is defined. There are no obligatory fields in either mode.

3.10.1 Simple Email Notification

3.10.1.1 Syntax<simple-notify> ::= <mail-header> <total-count-of-new-messages>

<mail-header> ::= <email-compatibility-header> | <nbs-header>

<email-compatibility-header> ::= “//MLAP11” <line-feed>

<nbs-header> ::= “//SCKL1588” <line-feed>

<total-count-of-new-messages> ::= <common-digit>+ ; ‘Total count of the messages in the server.’

3.10.1.2 Informative ExamplesIndication of 5 new email messages://MLAP115

Indication of 42 new email messages://SCKL158842



3.10.2 Extended Email notification

3.10.2.1 Syntax<extended-notify> ::= <header> <new-amount> [<extended-mail-notify-item>+ ]<header> ::= (<mail-header> | <nbs-header>) <line-feed>

<new_amount> ::= <nz-digit> <common-digit> * [<comment>] <line-feed>

<extended-mail-notify-item >::=

<from> |

<subject> |

<size> |

<uid> |

<server-id> |

<attachments> |

<to> |

<cc> |

<date> |

<folder> |

<sender> |

<reply-to> |

<uid-validity> |

<extension-field>

<from> ::= “from:” <ws-char>* <rfc822-address> <line-feed>

<subject> ::= “subject:” <ws-char>* <char>* <line-feed>

<size> ::= “size:” <ws-char>* <nz-digit> <common-digit> * <ws-char>* (“lines” | “kB”) <line-feed>

<uid> ::= <imap-uid> | <pop-uid>

<imap-uid> ::= “iuid:” <ws-char>* <nz-digit> <common-digit> * <line-feed> ; max 10 digits

<pop-uid> ::= “puid:” <ws-char>* <7-bit-char>+ <line-feed> ; max 70 chars

<server-id> ::= “sid:” <ws-char>* <common-digit><common-digit><common-digit><line-feed>

<attachments> ::= “att:” <ws-char>* <common-digit> + <line-feed>

<to> ::= “to:” <ws-char>* <rfc822-address> (“,” <rfc822-address>)* [<truncate-comment>] <line-feed>

<cc> ::= “cc:” <ws-char>* <rfc822-address> (“,” <rfc822-address>)* [<truncate-comment>] <line-feed>

<date> ::= ”date:” <ws-char>* <rfc822-date> <line-feed>

<folder> ::= “fldr:” <ws-char>* <7-bit-char>+ <line-feed> ; ' default INBOX '

<sender> ::= “sender:” <ws-char>* <rfc822-address> (“,” <rfc822-address>)* <line-feed>

<reply-to> ::= “reply-to:” <ws-char>* <rfc822-address> (“,” <rfc822-address>)* <line-feed>

<uid-validity> ::= “uidv:” <ws-char>* <nz-digit> <common-digit> * <line-feed>

<extension-field> ::= <extension-name> <colon> <extension-value> <line-feed>

<extension-name> ::= <field-name-char>+

<field-name-char> ::= ‘any char except <colon> and <line-feed>’

<extension-value> ::= <char>*

<comment> ::= <ws-char>+ <char>*

<username> ::= <7-bit-char>*



<port-number> ::= <nz-digit> <common-digit> *

<mail-header> ::= “//MLAP11”

<nbs-header> ::= “//SCKL1588” | “//SCKL15881588” <common-hex-digit> <common-hex-digit> <common-hex-digit> <common-hex-digit> <common-hex-digit> <common-hex-digit>

<colon> ::= “:”

<crlf> ::= <carriage-return> | <line-feed> | <carriage-return> <line-feed>

<char> ::= <default-char-not-lf>*

<7-bit-char> ::= ‘any 7-bit char except <line-feed>’

<non-digit> ::= ‘any char except <common-digit> and <line-feed>’

<nz-digit> ::= “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9”

<rfc822-address> ::= <mailbox> | <group> ; see RFC822

<rfc822-date> ::= [<day> “,”]<common-digit> [<common-digit>] <space> <email-notify-month> <space> <email-notify-year> <space> <email-notify-time>

<email-notify-year> ::= <common-digit> <common-digit> <commondigit> <common-digit>

<email-notify-month> ::= “Jan” | “Feb” | “Mar” | “Apr” | “May” | “Jun” | “Jul” | “Aug” | “Sep” | “Oct” | “Nov” |“Dec”

<email-notify-time> ::= <hour> <space> <zone> ; see RFC822

<email-notify-day> ::= “Mon” | “Tue” | “Wed” | “Thu” | “Fri” | “Sat” | “Sun”

<truncate-comment> ::= “(“ <char>* “)”

<ws-char> ::= <space> | ‘ISO 8859-1 code 910 ‘

Each field may appear only once within one mail notification smart message. Field names are case insensitiveand linear whitespace characters after colons (:) are allowed as well as folding of header fields (see RFC822).It is recommended that fields which contain information significant to user (I.e. from, subject, size and so on)are located as beginning of message as possible. Service provider can freely define its own fields, as long asthey match to field format defined in this specification (see <extension_field> in chapter 3). If different fieldformat is used, the different NBS port number MUST be used.

If mail headers contain quoted-printable or base64 encoded fields, it is highly recommended to decode andconvert them to ISO 8859-1 charset [ISO_8859], which is the default character set in this message type.

3.10.2.2 Description of the Fields3.10.2.2.1 Number of New Mail Messages

The <new-amount> field determines the number of new mail messages in the remote mailbox. The number ofnew mail messages is here for backward compatibility with older notification format which told only theamount of new mail messages and nothing more. There can be an optional comment after the number of newmessages.

3.10.2.2.2 From

The from field determines the sender of the mail message. When the length of the message matters, it is highlyrecommended that only the sender’s email address (username@domain) is used. Otherwise, all addressformats defined in RFC 822 can be used. This field is important to user, so it is highly recommended toinclude this field to the Mail Notification Smart Message.

3.10.2.2.3 Subject

The subject field determines the subject of the mail message. The length of the subject may have to be cut inorder to compress the whole message in a single Short Message. If the subject is truncated, it SHOULD be



indicated by three dots (… ) at the end of subject line. This field is important to user, so it is highlyrecommended to include this field to the Mail Notification Smart Message.

3.10.2.2.4 Size

This field determines the size of the body of the mail message in lines or kilobytes. This field containsimportant information to the user, so it is highly recommended that this field is included in the MailNotification Smart Message. The headers of mail message are ignored when calculating the size.

3.10.2.2.5 UID

These fields identify the mail message in the server. The name of this field defines the protocol to be used(IMAP or POP). This field provides one way to fetch or delete mail message without fetching all headers first.

3.10.2.2.6 Server ID

This field contains a hash value which identifies the server to which the message arrived.

Before hash value can be calculated, the characters must be converted to ISO 8859-1 [ISO_8859] charset.Hash value is calculated as follows:

• a concatenated string of length i: S is formed which contains the user name, host name and port number(port number being a string which expresses the port number in decimal), in this order. Si represents theISO 8859-1 character value of the ith character of string S.

• a 32-bit number N is created by multiplying the ISO 8859-1 value of the first character of S by one, the

second character value by two, and adding all of these together: ∑=

=i

jjjSN

1

• the hash value H is this number modulo 512: H=N (mod 512)

3.10.2.2.7 Attachments

This field determines the number of attachments in the mail message.

3.10.2.2.8 To

This field determines the recipients of the mail message (listed on the To: header line). This field can betruncated so that all To: addresses are not included to the Mail Notification Smart Message. This should beindicated by inserting comment in parenthesis as last address of To: field, for example ‘(...)’.

3.10.2.2.9 Cc

This field determines the recipients of the mail message (listed on the Cc: header line). This field can betruncated so that all Cc: addresses are not included to the Mail Notification Smart Message. This should beindicated by inserting a comment in parenthesis as last address of Cc: field, for example ‘(...)’.

3.10.2.2.10 Date

This field determines the date when the mail message was sent.

3.10.2.2.11 Folder

This field determines the folder from which the mail is fetched. If this field is missing, the default folder is“INBOX”.

3.10.2.2.12 Sender

This field determines the sender of the mail message.

3.10.2.2.13 Reply-To

This field determines the address to which replies are sent. If this field is missing the replies are sent toaddress on the From: line.



3.10.2.2.14 UID Validity

This field is used to determine if the UID is still valid or not.

3.10.2.3 Informative Examples3.10.2.3.1 Restricted mode version for legacy phones

//SCKL1588

1 new mail message

from: [email protected]

subject: test only

size: 42 lines

3.10.2.3.2 Restricted Mode Version for Smart Phones

//SCKL1588

1

subject:test only


size:42 lines

date:10 Oct 1997 11:42 +0000

iuid:1234567891

sid: 007

3.10.2.3.3 Non-restricted Mode Version for a Legacy Phone

//SCKL1588

1 new mail message

From: Messaging Smart <[email protected]>

Subject: test only, please ignore!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Size: 42 KB

att:1

To: Mark Smith <[email protected]>, Teemu Teekkari <[email protected]> (… )

Cc: John Doe <[email protected]>

Date:10 Oct 1997 +0000

sender: [email protected]

reply-to: [email protected]

fldr: user.smartme.this.folder.is.for.junk.mail

3.10.2.3.4 Non-restricted Mode Example for Smart Phones

//SCKL1588

1 new mail message received


subject: test only, please ignore

size: 4242 KB

date:10 Oct 1997 11:42 +0000



att: 42

to: Messaging Smart <[email protected]>, Another User<[email protected]>

cc: [email protected]

fldr: user.tester.this.folder.is.for.junk.mail

sender: [email protected]

reply-to: [email protected]

sid:007

iuid:1234567892

uidv:1020304050




Smart Messaging 4-1


4. PROTOCOL SPECIFICATIONS

4.1 NOTATION

The notation used in content specifications uses the common elements presented in this section.

4.1.1 Common ElementsRefer to the Message Formats section, 3.1 Notation for a list of common elements that also apply to theProtocol Specifications section.

Smart Messaging 4-2


4.2 DYNAMIC MENU CONTROL PROTOCOL (DMCP)

The Dynamic menu control protocol enables over-the-air updates of the handset menu structure. Depending onthe handset implementation, applicable parts of DMCP are supported. Typical to all implementations is themenu structure, which is divided to sub-menus that can grant control to authorized parties.

As users become familiar with the concept of dynamic menus, this capability is expected to be present in allhandsets. The dynamic menus enable the customization of the menu structure, based on the needs of the useror based on the set of services that the operator provides.

When a menu item is selected, it may cause a number of different actions to take place. For example, a TTMLbased service can be started, a phone call can be initiated, or a message can be sent. Access to supplementaryservices can be made automatic, as the supplementary service string required to initiate a network service ishidden from the user.

The DMCP protocol operates at NBS port 5508 decimal (1584 hexadecimal).

DMCP enables handsets to have any number of menus. The menus are divided into the basic categories: homeoperator, roaming operator, local, user’s favorite and manufacturer-specific menus. The usage of thesecategories is explained next.

The Operator Menus

The home and the roaming operator menus are two examples of the same concept. The operator menus aredescribed here in terms of the home operator menu.

The home operator menu provides the operator with a powerful tool to personalize the handsets theirsubscribers use. This concept is an operator-specific menu structure in the handset that may vary fromsubscriber to subscriber, and can be updated over the air without any user assistance.

Access to the home operator menu is limited to the home operator. This enables the operator to provide servicesets to their subscribers as a part of the basic service. Access to the roaming operator menu requires the homeoperator to authorize the roaming operator’s server to send menu items to the handset.

The following menu example shows how the home operator services can be provided to users. The name of thehome operator is also provided over the air to the handset.

MENU:Phone SettingsTele Services

Call Tele Customer ServiceDownload Ringing TonesNew OfferingsEnable Call WaitingDisable Call Waiting

Local ServicesPersonal ServicesMemory Settings

Smart Messaging 4-3


The following menu example shows how roaming operator services can be provided to the user. In thisexample both the home operator menu and the roaming operator menu exist in the handset. The roaming userhas arrived in a new network, and menu items have been sent over the air to the phone:

MENU:Phone SettingsCellnet ServicesRadiolinja Services

Roamer ServicesLocal phonebook

Local ServicesPersonal ServicesMemory Settings

The Local Services Menu

The local services menu enables local service providers who are not necessarily operators to advertise theirservices. The list of local services depends on the location of the user and/or on the demographically selectedgroup of users to which he belongs.

This facility provides an easy way to direct information or advertisements to handset users traveling through orwithin a geographical area. Technically, cell broadcasts can be used to send local service information to allusers in a certain area. An important point is that as such information flow increases, handsets will be requiredto support functions that enable the end user to block this flow when it is not desired.

The local services menu is not persistent in the handset. In practice, the persistence rules may differ fromhandset to handset. One handset might clear the volatile service list as a handover takes place, whereasanother does so only when the phone is turned off.

The following menu example shows how local services can be provided to users. As shown, a user is providedwith ‘pointers’ to more information. By selecting local news, a news server sends the news headers to thehandset, and based on the headers, main topics of the news article are then sent to the handset.

MENU:Phone SettingsRadiolinja ServicesLocal Services

Join Wal Mart Direct-ADTraffic at Dallas I-75Weather UpdateLocal News (courtesy of Nokia)

Personal ServicesMemory Settings

The Personal Services Menu

The personal services menu is equivalent to the bookmark list of a web browser. The handset user has theability to add and remove items from the menu. Menu items can be moved from other menus to the personalservices menu. If a menu item addition is received by a handset, the result is handset implementation-specific.The recommended action is for the handset to query the user as to whether the item should be added or not.

The following example shows how the personal services menu can be provided to the user.

Smart Messaging 4-4


MENU:Phone SettingsRadiolinja ServicesLocal ServicesPersonal Services

Stock NOK ASend EmailFind RestaurantHoliday Travel Inc.

Memory Settings

4.2.1 The DMCP Protocol DescriptionDMCP defines how the menu structure of the cellular handsets can be dynamically changed. The protocol isprovided as generic, being able to support any number of menus. However, in practice it depends on thecellular handset model and/or firmware version as to which menus are supported.

DMCP enables adding, removing, or querying existing menu items in a handset. The protocol enablesimplementation of menus with restricted access. In a handset, menu items are uniquely identified by each(<menu-group-name>, <menu-item-name>) pair. This means that all menu group names in a handset areunique, and each menu entry in a menu has a unique name.

4.2.1.1 Menu Group NamesA number of menu names have been reserved, in order to indicate which dynamic menu a command isintended for. The menu names and the menu descriptions are shown in Table 4.2-1.

Table 4.2-1. Reserved menu group names

Menu group name DescriptionOPER <operator name> Home-operator accessible menu. Access is restricted in

handsets, i.e., authorization list is enabled.ROAM <operator name> Roaming-operator accessible menu. Access is restricted in

handsets, i.e., authorization list is enabled.LOCAL Local area services list. Services that any services provider

may offer in the current geographical/ demographicallydivided area. Access to local services menu is open, butmenu item tokens are used to implement weakauthentication.

USER User’s favorite services list. Access is dependent on handsetcapabilities.

MANUF Manufacturer-specific menu. Access is restricted inhandsets, i.e., authorization list is enabled.

4.2.1.2 Authorization SchemesAccess control to menus is based on two schemes. These schemes are called strong and weak authentication.

Strong authentication is based on checking the originator address of the received menu command. In thisscheme only commands from authorized servers are accepted. In the case of GSM, the address pair

Smart Messaging 4-5


(<common-smsc-ms-isdn>, <common-ms-isdn>) is used to identify authorized servers. This system is assecure as the network is.

The list of authorized servers is stored in the handset, and it can be updated from an already authorized server.The first authorized server is entered by the user, or it is stored on SIM later on. After one authorized server isstored in the handset, no user intervention is required.

Weak authentication is available for all menus, regardless of the existence of an authorization list. Weakauthentication is based on checking a specific <menu-item-token>, when a menu command is received thatwould affect an already existing menu item. The token can always be omitted from the menu command whenthis security feature is not needed. Depending on the handset implementation, the token is set dynamically fora menu item (recommended practice), or it can be preset and stored in the handset.

The weak authentication enables preventing hostile changing of menu items, for example, in the local servicesmenu. Only a party with the token can change an existing menu item.

4.2.1.3 Protocol PrimitivesThe DMCP protocol primitives consist of request and response primitives (See Figure 4.2-1). Depending onhandset implementation, only a subset of these primitives may be supported. The primitives are described inthe following sections.

Request: Item Add, Remove, List, Capability

Response: generic

Response: Item List

Request: Authorization Add, Remove, List

Response: generic

Response: Authorization List

Request: Device Capability

Response: generic

Response: Device Capability

Request: Menu

handset Server

User selectslinked menu item

Figure 4.2-1. The DMCP protocol primitives

4.2.2 Item Primitive DefinitionsThere are four item primitives in the protocol: add, remove, list, and item capability.

4.2.2.1 Item AddThe item add command adds a new menu item to a menu in the handset.

Parameters: MENU-ITEM-TOKEN

Smart Messaging 4-6


MENU-GROUP-NAME

MENU-ITEM-NAME

MENU-ITEM-TYPE

MENU-ITEM-PROVIDER-INFORMATION

MENU-ITEM-HELP

MENU-ACTION-LIST

MENU-ITEM-TOKEN can be used by the server for authorization purposes. Once a menu item has been sentto a handset with a MENU-ITEM-TOKEN set, no command can be given to change or remove the existingMENU-ITEM without the same MENU-ITEM-TOKEN.

MENU-GROUP-NAME specifies the menu group into which the menu item with name MENU-ITEM-NAMEis put. If a menu item with the same (MENU-GROUP-NAME, MENU-ITEM-NAME) pair exists and theserver is authorized to update the menu item, then the existing menu item is replaced with the new one.

MENU-GROUP-NAME reserves the character “:” which has a special line-feed function inside the menugroup name. For example, the menu group name “phone:settings” will displayed on a handset as ‘phone’ onthe first line, and ‘settings’ on the second line.

MENU-GROUP-NAME reserves the character “;” which has a special function of indicating a change ofhierarchy level in multiple hierarchy menus. This feature is implementation-specific and may be limited tomanufacturer-specific menus in the handsets.

MENU-ITEM-NAME reserves the character “:” which has a special line-feed function inside the menu itemname. For example, the menu item name “phone:volume” will displayed on a handset as ‘phone’ on the firstline, and ‘volume’ on the second line.

MENU-ITEM-TYPE indicates the type of menu item. A menu item can be: normal, volatile, selected(volatile), or link. Depending on the handset implementation, only a subset of these may be supported, e.g.only the normal menu items.

NORMAL menu items are stored in the handset normally.

VOLATILE menu items are for multiple choice menu items which may vary from time to time. Thistype also indicates to the handset that a menu item may be discarded if the storage space limit in thehandset is reached. Volatile type is intended to be used for menu items that are returned as a response toa link request; using linked menu items and volatile menu items enables the creation of multiple choicemenus with a set of items that varies from time to time. The handset will always request the menu thatcurrently is in effect.

SELECTED (volatile) menu item indicates “the currently active” volatile menu item. This can be used toindicate the current state of a multiple choice menu item.

LINK menu items indicate to the handset that it must request the volatile selection items from the server.This type should be used for any menu items that have a varying set of sub-items, because link typeimplies that a request is always made for sub-items. A link menu item causes an unsolicited menuresponse to be sent to the server requesting the volatile menu items.

MENU-ITEM-PROVIDER-INFORMATION is a text string which contents is decided by the provider. Thisparameter can be used to store in the handset information concerning the version of the menu item stored etc.This is unstructured field, and the accepted length of the field is handset implementation dependent.

MENU-ITEM-HELP is a text string which is shown when the user needs help regarding the current menuitem. It is handset-specific, as to whether the handset automatically shows the help text when, for example, anidle timer expires. Menu item help reserves the character “:” which has a special line-feed function inside thehelp text.

Smart Messaging 4-7


MENU-ACTION-LIST is a list of actions. The actions can be of the following type: ACTION-SEND-MESSAGE, ACTION-CALL-CONTROL, or ACTION-PHONE-CONTROL. Any unknown type identifiersshould be ignored and the content skipped.

ACTION-SEND-MESSAGE causes an embedded message to be sent in one of several methods. The method isdependent on the message type, which can be SMS, USSD, UU, URL, or NBS. It is handset implementation-specific as to which of the message types are supported. At minimum, the SMS and NBS message types shouldbe supported.

Message type SMS causes the embedded message to be sent through the given SMSC (SMSC-MS-ISDN)to the given destination address (DESTINATION-MS-ISDN). The destination NBS port may bespecified, in which case the handset will generate the NBS header in front of the embedded message to besent.

If the SMSC address is replaced with “;”, then the handset should use its default SMSC number to sendthe message.

If the destination MS address is replaced with “;”, then the handset should prompt for an address whenthe action is executed.

If the NBS port is missing or it is replaced with “;”, then no NBS header is generated, and the message ishandled as text.

Message type USSD causes the embedded message to be sent to a given destination at a given NBS port.

Message type UU causes the phone to make a voice call to the given destination. When the circuit isopened, the handset will send the embedded information as user-to-user data to the destination. This canbe used to automatically provide subscriber identity as a business card to the called party.

Message type URL causes the phone to process the given URL with its default browser. It is handsetimplementation-specific in regards to whether it has a browser that will be able to process the URL.

Message type NBS causes the phone to redirect the embedded message to the given local (nbs-port) NBSport. No action external to the phone takes place. If the destination NBS port is missing or is replacedwith “;”, then no NBS header is generated, and the message is handled as text. It is possible to redefinethe source address for the NBS message, in order to enable a reply message to be sent over the air.

ACTION-CALL-CONTROL causes a call to be made in one of many methods. The method is dependent onCALL-CONTROL-TYPE, which can be VOICE, DATA, FAX, SS (supplementary services), AVD (alternatevoice/data), AVF (alternate voice/fax), or SVD (sequential voice/data). Any unrecognized types must beignored and skipped.

Call control type VOICE causes the handset to initiate a voice call to the given destination address.

Call control type DATA causes the handset to initiate a data call to the given destination address.

Call control type FAX causes the handset to initiate a fax call to the given destination address.

Call control type SS causes a supplementary service string to be sent to the network. Note: The GSMspecifications require that if the SS string is not recognized, then it is sent as USSD.

Call control type AVD causes the handset to initiate alternate VOICE/DATA call (GSM: BS61).Additional parameter indicates does the call start with VOICE or with DATA.

Call control type AVF causes the handset to initiate alternate VOICE/FAX call (GSM: TS61). Additionalparameter indicates does the call start with VOICE or with DATA.

Call control type SVD causes the handset to initiate sequential VOICE + DATA call (GSM: BS81).

ACTION-PHONE-CONTROL enables special control of phone functionality. The control is specified usingthe CONTROL-TYPE-IDENTIFIER, and parameters are provided using PHONE-CONTROL-TYPE-PARAMETER field.

Smart Messaging 4-8


Phone control type VAR causes the handset to place an internal value, such as IMEI code, or the languagecurrently in use into a variable. The name of this variable can then be used in actions sent in sequence, toplace the IMEI code or the preferred language into the body of the message to be sent. It is also possible torequest network related information such as the network code (NC), location area code (LAC), or cell identity(CI) to be placed into a variable.

A vendor-specific extension of the variable definition is supported. It can be done by prefixing the vendor-specific internal variable name with “X-“. It is recommended that prior to the actual variable name, the nameof the vendor is placed between the prefix and the internal variable name, i.e., “X-Nokia-status1”.

Phone control type MODE causes the handset to change state of a given internal function. If additional state isprovided, the internal function is set to ON or OFF depending on this state information. If the stateinformation is missing, then the MODE command toggles the internal state, advances it by one, triggers anevent, and so forth, depending on the nature of the internal function.

4.2.2.2 Item RemoveThe item remove command removes an item from a menu in the handset.


MENU-GROUP-NAME

MENU-ITEM-NAME

The item remove command causes a menu item identified by the (MENU-GROUP-NAME, MENU-ITEM-NAME) pair to be removed from the handset provided that authorization (based on MENU-ITEM-TOKENand/or on authorization list) does not fail.

4.2.2.3 Item ListThe item list command requests a handset to list the contents of a menu.


MENU-GROUP-NAME

When successful, this command will cause the handset to send a list of menu item names to the server fromwhich this command was originally sent. The server can specify the menu for which the list of items isrequested.

The item list command is a privileged command, and the availability depends on handset implementation. It isrecommended that the item list command be available for manufacturer and operator menus.

When menu-item-token is given, only those items with a matching token will be returned.

The handset will use MENU-ITEM-LIST-RESPONSE format and send a message back to the server fromwhich this command was originally sent. The MENU-ITEM-LIST-RESPONSE will contain the requestedMENU-GROUP-NAME, and depending on the handset implementation, a line-feed delimited list of

n (MENU-ITEM-PROVIDER-INFORMATION, MENU-ITEM-NAME) pairs, or

n MENU-ITEM-NAMEs

Refer to section 4.2.5.5 Responses for further information.

4.2.2.4 Item CapabilityThe item capability command changes the capability of a menu item in the handset.


Smart Messaging 4-9


MENU-GROUP-NAME

MENU-ITEM-NAME

MENU-ITEM-CAPABILITY

The item capability command can be used to add or remove extra capabilities from a menu item. Thiscommand can be used to add an icon to a menu item. This command is currently under study, and should beignored or skipped.

4.2.2.5 Unsolicited Menu ResponseThe unsolicited menu response can be used by the handset to request a linked sub-menu associated with themenu item indicated in the unsolicited menu response.

Parameters: MENU-GROUP-NAME

MENU-ITEM-NAME

This primitive can be used to request from the network the state of a function provided by the network. As thestate of the network service is not known to the handset, it is explicitly requested from the network. Based onthe sub-menu items received from the network, end user can request a change in the state of the service.

4.2.2.6 Unsolicited Menu Update ResponseThe unsolicited menu update response can be used by the handset to request a whole menu.


MENU-ITEM-PROVIDER-INFORMATION MENU-ITEM-NAME, …

This primitive enables end user to explicitly request update for a menu from the menu provider. Depending onthe handset implementation, it may use in the unsolicited menu update response only MENU-GROUP-NAME,or the MENU-GROUP-NAME together with menu item information. The menu item information may consistof

n MENU-ITEM-PROVIDER-INFORMATION only,

n (MENU-ITEM-PROVIDER-INFORMATION, MENU-ITEM-NAME) pairs, or

n MENU-ITEM-NAME only

This enables a variety of implementations for the menu providers. For example,

(i) when the menu provider only provides one version of a menu named MENU-GROUP-NAME, then onlythat name is required in the unsolicited menu update response.

(ii) when the menu contains menu items of which only one version exists, then only the MENU-ITEM-NAMEs are required to be sent along with the MENU-GROUP-NAME.

(iii) when the menu provider has several versions of menu items in a menu, i.e., the menu items in the menunamed MENU-GROUP-NAME have been updated separately, then the (MENU-ITEM-PROVIDER-INFORMATION, MENU-ITEM-NAME) pairs are required to be sent in order to be able to update themenu.

(iv) when the situation is as in case (iii), but the menu provider has assigned a unique ID in MENU-ITEM-PROVIDER-INFORMATION for each MENU-ITEM-NAME, it is possible to omit the MENU-ITEM-NAMEs, and only send the MENU-PROVIDER-INFORMATION.



4.2.3 Authorization Primitive DefinitionsThere are three authorization primitives in the protocol. They are add, remove, and list. In some cases theauthorization primitives are not implemented in the handset. In such cases some other means are provided toenter server information into the handset. It is recommended that authorization lists be enabled for operatorand manufacturer menus. Authorization primitives are implementation-specific as to how many entries thephone is capable of storing in the authorization list of each menu.

4.2.3.1 Authorization AddThe authorization add command adds new authorized server(s) for a menu in the handset.


MENU-AUTHORIZATION-SERVER-LIST

This command can be used to add one or more new authorized servers to the list of authorized servers for thegiven menu (MENU-GROUP-NAME). This command is privileged in the sense that it will be accepted onlyfor a menu with an authorization list active, and when sent from an already authorized server.

The MENU-AUTHORIZATION-SERVER-LIST consist of one or more lines of information, each definingone authorized server.

For GSM/SMS, an authorized server is defined by the pair (MS-ISDN of a SMSC, MS-ISDN of the server).

4.2.3.2 Authorization RemoveThe authorization remove command removes authorized server(s) from a menu in the handset.


MENU-AUTHORIZATION-SERVER-LIST

This command can be used to remove one or more authorized servers from the list of authorized serverswithin the given menu (MENU-GROUP-NAME). This command is privileged in the sense that it will beaccepted only for a menu with an authorization list active, and when sent from an already authorized server.

4.2.3.3 Authorization ListThe authorization list command requests the authorization list for a menu from the handset.


This command can be used to request the handset to send the list of privileged servers for a requested menu(MENU-GROUP-NAME). The availability of this command depends on the handset implementation. Thiscommand is privileged in the sense that it will be accepted only for a menu with an authorization list active,and when sent from an already authorized server.

The handset will use MENU-AUTHORIZATION-LIST-RESPONSE format and send a message back to theserver from which this command was originally sent. The MENU-AUTHORIZATION-LIST-RESPONSE willcontain the requested MENU-GROUP-NAME, and a line-feed delimited list of authorized servers.

4.2.4 Device Capability Primitive Definitions

4.2.4.1 Device CapabilityThe device capability command requests information from the handset.



Parameters: DEVICE-CAPABILITY-IDENTIFIER, …

This command can be used by a server to request device capability related information. This command is aprivileged command.

DEVICE-CAPABILITY-IDENTIFIER is used to specify what kind of information is returned.

Field DEVICE-CAPABILITY-IDENTIFIER with the value LAN causes the handset to return the ID of thecurrently active (i.e., preferred) language. The format is based on Internet RFC 1766 [RFC_1766].

Field DEVICE-CAPABILITY-IDENTIFIER with the value INFO causes the handset to return themanufacturer name, and handset model. The rest of the information is manufacturer/model specific, forexample, firmware version and date of the last firmware update could be indicated.

4.2.5 SyntaxAll lines that start with an unknown identifier should be skipped. All identifiers, i.e. reserved words orcommands, are written using uppercase characters. Menu and item names may contain any characters that areavailable in the current character set.

4.2.5.1 RequestsMenu control requests contain the optional menu meta information part and the control command list:

<menu-control-request> ::=

[ <menu-meta-header> ] “BODY:” <line-feed>

<menu-command-list>

Menu meta information can contain specific information on the character set encoding used in the controlcommand list. The version number of the menu control protocol supported may also be present:

<menu-meta-header> ::= { <menu-meta-information> <line-feed> }+

<menu-meta-information> ::=

“CH:” <menu-charset-field> | ; ‘character set in use’

“VER:” <menu-version-field> ; ‘version of the menu control protocol’

<menu-charset-field> ::= <common-charset-field>

; ‘If not present, defaults to network default character set (in GSM, the GSM character set from GSM 3.38/3.40specifications).’

<menu-version-field> ::= <common-version-field>

; ‘Defaults to version 1.0 set of primitives, if version is higher, the version meta information must be present. Ifthe version is 1.0, the meta information must NOT be present.’

<menu-command-list> ::=

<menu-control-command> <line-feed> |

<menu-control-command> <line-feed>

“--“ <line-feed>

<menu-command-list>

<menu-control-command> ::=



“IA:” <menu-item-token> <menu-item-add-field> | ; ‘add menu item’

“IR:” <menu-item-token> <menu-item-remove-field> | ; ‘remove menu item’

“IL:” <menu-item-token> <menu-item-list-field> | ; ‘list menu items’

“IC:” <menu-item-token> <menu-item-capability-field> | ; ‘change item capability’

“AA:” <menu-authorization-add-field> | ; ‘add trusted server’

“AR:” <menu-authorization-remove-field> | ; ‘remove trusted server’

“AL:” <menu-authorization-list-field> | ; ‘list trusted servers’

“DC:” <device-capability-request-field> ; ‘request capability’

4.2.5.2 Item Commands<menu-item-token> ::= <default-char-not-lf>* <line-feed>; ‘empty token or unique token to change menu item.’

<menu-item-add-field> ::=

<menu-group-name> <line-feed>

<menu-item-name> <line-feed>

<menu-item-type> <space> <item-provider-information> <line-feed>

<menu-item-help> <line-feed>

<menu-action-list>

<item-provider-information> ::= <default-char-not-lf-or-space>*

; ‘ The <item-provider-information> may contain version, language, etc. information that the menu providerwants to associate with this instance of the menu item. The information is also received by the provider with theitem list command.’

<menu-group-name> ::=

“OPER” [ <space> <operator-name> ] |

“ROAM” [ <space> <operator-name> ] |

“LOCAL” |

“USER” |

“MANUF” |

<default-char-not-lf>+

<operator-name> ::= <default-char-not-lf>* ; ‘name of the operator’

<menu-item-name> ::= <default-char-not-lf>*

<menu-item-type> ::=

“N” | ; ‘normal (default)’

“L” | ; ‘linked item - selection items will be requested’

“V” | ; ‘volatile selection item’

“S” ; ‘selected (volatile) item’

<menu-item-help> ::= <default-char-not-lf>* ; ‘help text associated with the menu item’



<menu-action-list> ::=

<menu-action> |

<menu-action> <line-feed>

<menu-action-list>

<menu-action> ::=

<action-send-message> |

<action-call-control> |

<action-phone-control> |

<default-char-not-lf>* ; ‘should ignore all other types’

<menu-item-remove-field> ::=


<menu-item-name>

<menu-item-list-field> ::= <menu-group-name> ; ‘list menu items in menu’

<menu-item-capability-field> ::=



<menu-item-capability>

SEND MESSAGE ACTION

<action-send-message> ::=

“M” <space> <message-type-identifier> <line-feed>

<message-address-field> <line-feed>

<common-information-content>

<message-type-identifier> ::= ‘depends on the network’

for GSM: <message-type-identifier> ::=

“SMS” | “USSD” | “UU” | “URL” | “NBS” | <default-char-not-lf>*

<message-address-field> ::= ‘depends on the message-type-identifier’

for GSM/ “SMS”: <message-address-field> ::=

<common-smsc-ms-isdn> “/” <common-destination-ms-isdn>

[ “/” <common-nbs-port> ]

for GSM/ “USSD”:<message-address-field> ::= ‘RESERVED’

for GSM/ “UU”: <message-address-field> ::=

<common-destination-ms-isdn> [ “/” <common-nbs-port> ]

for GSM/ “URL”: <message-address-field> ::= ‘full URL as specified in RFC 1738 [RFC_1738]’

for GSM/ “NBS”: <message-address-field> ::=

<common-destination-nbs-port> “/”

<common-source-smsc-ms-isdn> “/”



<common-source-ms-isdn> [ “/” <common-source-nbs-port> ]

CALL CONTROL ACTION

<action-call-control> ::=

“C” <space> <call-control-type> <line-feed>

<call-control-type-modifier>

<call-control-type> ::= “VOICE” | “DATA” | “FAX” | “SS” | “AVD” | “AVF” | “SVD” | <default-char-not-lf>+

<call-control-type-modifier> ::= ‘depends on the <call-control-type>’

for GSM/ “VOICE”: <call-control-type-modifier> ::= <common-destination-ms-isdn>

for GSM/ “DATA”: <call-control-type-modifier> ::= <common-destination-ms-isdn>

for GSM/ “FAX”: <call-control-type-modifier> ::= <common-destination-ms-isdn>

for GSM/ “SS”: <call-control-type-modifier> ::= <supplementary-service-string>

for GSM/ “AVD”: <call-control-type-modifier> ::= ;’Alternate: voice or data’

<call-control-type-alternate-start-mode>

<common-destination-ms-isdn>

for GSM/ “AVF”: <call-control-type-modifier> ::= ;‘Alternate: voice or fax’

<call-control-type-alternate-start-mode>


for GSM/ “SVD”: <call-control-type-modifier> ::= ;’Sequential: voice followed by data’


<supplementary-service-string> ::= <common-tel-char>*

<call-control-type-alternate-start-mode> ::=

“V” | ;’Voice, available in “AVD”, “AVF”, and “SVD”.’

“D” | ;’Data, available in “AVD”, and “SVD”.’

“F” ;’Fax, Available in “AVF”.’

PHONE CONTROL ACTION

<action-phone-control> ::=

"P" <space> <phone-control-type-identifier> <line-feed>

<phone-control-type-parameter>

<phone-control-type-identifier> ::=

"VAR" | ; ‘set variable to be used in other actions’

"MODE" | ; ‘change phone internal state’

<default-char-not-lf>*



<phone-control-type-parameter> ::= ‘depends on the <phone-control-type-identifier>’

for GSM/ "VAR": <phone-control-type-parameter> ::=

<phone-control-variable-name> <space>

<phone-control-internal-data-name> <space>

<phone-control-internal-data-value>

for GSM/ "MODE":<phone-control-type-parameter> ::=

<default-char-not-lf-or-space> [ <space> <phone-control-mode-state> ]

<phone-control-variable-name> ::= "%" <default-char-not-lf-or-percent> "%"

<default-char-not-lf-or-percent> ::= ‘Any character in the default character set (or in character set explicitlyindicated) except <line-feed> or "%". In GSM, the GSM character set from 3.38/3.40.’

<phone-control-internal-data-name> ::=

"CI" | ; ‘Cell identity’

"IMEI" | ; ‘IMEI of the handset’

"LAC" | : ‘Location area code’

"LAN" | : ‘The preferred language of the user’

"NC" | : ‘Network code’

<default-char-not-lf>*

<phone-control-internal-data-value> ::= ‘depends on the <phone-control-internal-data-name>’

for "CI": <phone-control-internal-data-value> ::= <common-hex-digit>+

; ‘Up to 8 hexadecimal digits of CI information’

for "IMEI": <phone-control-internal-data-value> ::= <common-digit>+

; ‘Up to 20 digits of IMEI information’

for "LAC": <phone-control-internal-data-value> ::= <common-hex-digit>+

; ‘Up to 4 hexadecimal digits of LAC information’

for "LAN": <phone-control-internal-data-value> ::= <common-language>

; ‘Preferred language’

for "NC": <phone-control-internal-data-value> ::= <common-hex-digit>+

; ‘Up to 6 hexadecimal digits of NC information’

<phone-control-mode-state> ::= “ON” | “OFF” ; ‘set mode ON/OFF. IF this is missing, then TOGGLE’

<menu-item-capability> ::= ‘RESERVED’



4.2.5.3 Authorization Commands<menu-authorization-add-field> ::=

<menu-group-name> <line-feed> ; ‘add authorization’

<menu-authorization-server-list>

<menu-authorization-server-list> ::=

<menu-server-address> | <menu-server-address> <menu-authorization-server-list>

<menu-server-address> ::= ‘Depends on the addressing scheme of the system’

for GSM/ “SMS”: <menu-server-address> ::=

<common-smsc-ms-isdn> “/” <common-ms-isdn> <line-feed>

<menu-authorization-remove-field> ::= ; ‘remove authorization’



<menu-authorization-list-field> ::= <menu-group-name> ; ‘name of the group to check authorizations for’

4.2.5.4 Capability Commands<device-capability-request-field> ::=

<device-capability-identifier> |

<device-capability-identifier> <line-feed>

<device-capability-request-field>

<device-capability-identifier> ::=

“LAN” | ; ‘request preferred language’

“INFO” | ; ‘request device information; manufacturer, model’

<default-char-not-lf>+

4.2.5.5 Responses<menu-control-response> ::=

[ <menu-meta-information> ] “BODY:” <line-feed>

<menu-control-command-response> <line-feed>

<menu-control-command-response> ::=

“RG:” <menu-generic-response> |

<menu-item-list-response> |

<menu-authorization-list-response> |

<unsolicited-menu-response> |

<unsolicited-menu-update-response> |

<device-capability-response>



<menu-generic-response> ::= “OK” | “ERROR” | “BAD-VERSION” | “BAD-TOKEN” | “BAD-SERVER”

<menu-item-list-response> ::=

“RIL:” <menu-group-name> <line-feed>

<menu-items>

<menu-items> ::=

<item-provider-information> <space> <menu-item-name> |

<item-provider-information> <space> <menu-item-name> <line-feed>

<menu-items>

<menu-authorization-list-response> ::=

“RAL:” <menu-group-name> <line-feed>


<unsolicited-menu-response> ::= ; ‘handset requires linked menu item’

“RM:” <menu-group-name> <line-feed>


<unsolicited-menu-update-response> ::= ; ‘handset requires menu update’

“RU:” <menu-group-name> <line-feed>

{ [ <item-provider-information> ] [ <space> <menu-item-name> ] <line-feed> }*

<device-capability-response> ::=

“RDC:” <line-feed>

<device-capability-response-parameter-list>

<device-capability-response-parameter-list> ::=

<device-capability-identifier> <space> <device-capability-value> |

<device-capability-identifier> <space> <device-capability-value> <line-feed>

<device-capability-response-parameter-list>

<device-capability-value> ::= ‘Depends on the <device-capability-identifier>’

for "LAN": <device-capability-value> ::= <common-language> ; ‘Preferred language’

for "INFO": <device-capability-value> ::=

<manufacturer-info> <line-feed>

<model-info> <line-feed>

<manufacturer-specific-info>

<manufacturer-info> ::= <default-char-not-lf>* ; ‘Manufacturer name.’

<model-info> ::= <default-char-not-lf>* ; ‘Handset model name.’

<manufacturer-specific-info> ::= <default-char>* ; ’One or more lines of manufacturer-specific fields.’



4.2.6 ProceduresThe dynamic menu item protocol has one state, which is called IDLE. This section provides information onhow handsets will handle protocol actions.

4.2.6.1 Notation

∧ Logical AND of predicates

⊂ Subset

⊄ Not Subset

<> Not Equal

== Equal

(a,b) Pair consisting of members ‘a’ and ‘b’

a->b Lookup of ‘b’ with ‘a’ as a lookup key

a.b Member of ‘a’ identified by ‘b’

∪ Set Union

∩ Set Intersection

4.2.6.2 Handset FSM State Transition Table: Item primitives

State Event Action Next State

IDLE

(entrystate)

recv IA:token:group-name:item-name:item-type:provider-information:item-help:action-list from smsc:ms:port ∧ (smsc,ms) ⊄ AuthorizedServers(group-name)

Unauthorized (server not accepted) IDLE 1

recv IA:token:group-name:item-name:item-type: provider-information:item-help:action-list from smsc:ms:port ∧ (smsc,ms) ⊂ AuthorizedServers(group-name) ∧(group-name, item-name) ⊂ StoredItems ∧token == StoredItems.(group-name, item-name)-> token

StoredItems := StoredItems ∩ (group-name, item-name) *remove old*

StoredItems := StoredItems ∪ (group-name, item-name)->token:group-name:item-name:item-type:item-help:action-list

IDLE 1

recv IA:token:group-name:item-name:item-type: provider-information:item-help:action-list from smsc:ms:port ∧ (smsc,ms) ⊂ AuthorizedServers(group-name) ∧(group-name, item-name) ⊂ StoredItems ∧token <> StoredItems.(group-name, item-name)-> token

Unauthorized (token not accepted) IDLE 1

recv IA:token:group-name:item-name:item-type: provider-information:item-help:action-list from smsc:ms:port ∧ (smsc,ms) ⊂ AuthorizedServers(group-name) ∧(group-name, item-name) ⊄ StoredItems

StoredItems := StoredItems ∪ (group-name, item-name)->token:group-name:item-name:item-type:item-help:action-list

IDLE 1



recv IR:token:group-name:item-name fromsmsc:ms:port ∧ (smsc, ms) ⊄AuthorizedServers(group-name)


recv IR:token:group-name:item-name fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name)∧ (group-name, item-name) ⊂ StoredItems ∧ token== StoredItems.(group-name, item-name)->token

StoredItems := StoredItems ∩ (group-name, item-name)

IDLE 1

recv IR:token:group-name:item-name fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name) ∧ (group-name, item-name) ⊂ StoredItems ∧ token<> StoredItems.(group-name, item-name)->token


recv IR:token:group-name:item-name fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name) ∧ (group-name, item-name) ⊄ StoredItems

Error (Item does not exist) IDLE 1

recv IL:token:group-name fromsmsc:ms:port ∧ (smsc, ms) ⊄AuthorizedServers(group-name)


recv IL:token:group-name fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name) ∧ (group-name, ANY) ⊂ StoredItems ∧ token ==StoredItems.(group-name, ANY)-> token

Generate reply to smsc:ms:port with listof items with matching token.

IDLE 1

recv IL:token:group-name fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name) ∧ (group-name, ANY) ⊂ StoredItems ∧ token <>StoredItems.(group-name, ANY)-> token


recv IL:token:group-name fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name) ∧ (group-name, ANY) ⊄ StoredItems

Generate reply to smsc:ms:port withempty item list.

IDLE 1



4.2.6.3 Handset FSM State Transition Table: Authorization primitives


IDLE

(entrystate)

recv AA:group-name:server-list fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name)

AuthorizedServers := AuthorizedServers∪ (group-name)->server-list

IDLE 1

recv AA:group-name:server-list fromsmsc:ms:port ∧ (smsc, ms) ⊄AuthorizedServers(group-name)


recv AR:group-name:server-list fromsmsc:ms:port ∧ (smsc, ms) ⊂AuthorizedServers(group-name)

AuthorizedServers := AuthorizedServers∩ (group-name)->server-list

IDLE 1

recv AR:group-name:server-list fromsmsc:ms:port ∧ (smsc, ms) ⊄AuthorizedServers(group-name)


recv AL:group-name from smsc:ms:port ∧(smsc, ms) ⊂ AuthorizedServers(group-name)

Generate reply to smsc:ms:port with listof AuthorizedServers(group-name)

IDLE 1

recv AL:group-name from smsc:ms:port ∧(smsc, ms) ⊄ AuthorizedServers(group-name)


4.2.6.4 Handset FSM State Transition Table: Device Capability primitives


IDLE

(entrystate)

recv DC:identifier from smsc:ms:port

∧ (smsc, ms) ⊂ AuthorizedServers(DC) ∧identifier == “LAN”

Generate reply to smsc:ms:port withcurrent language selected in handset

IDLE 1


∧ (smsc, ms) ⊂ AuthorizedServers(DC) ∧identifier == “INFO”

Generate reply to smsc:ms:port withhandset information (manufacturer,model, firmware version, date)

IDLE 1


∧ (smsc, ms) ⊄ AuthorizedServers(DC)


4.2.7 State DefinitionsIDLE. The device can receive frames from remote peer systems.

4.2.8 Parameter DefinitionsStoredItems. A set of dynamic menu items. This set contains the current dynamic menu structure of thehandset. Based on this information the handset builds the menu structure.



AuthorizedServers. A set of authorized servers. This set contains menu names associated with authorizedservers. If a menu name exists in the set of authorized servers, then commands concerning that menu will onlybe accepted from the list of servers associated with that menu name. If a menu name does not exist in theauthorized servers set, then any server may send commands concerning that menu.

4.2.9 Event Descriptionsrecv IA:token:group-name:item-name:item-type:provider-information:item-help:action-list fromsmsc:ms:port. Item add request has been received through given smsc (smsc) from ms-isdn address (ms), andfrom given NBS port (port). The request contains the token, group-name, item-name, item-type, provider-information, item-help, and action-list fields.

recv IR:token:group-name:item-name from smsc:ms:port. Item remove request has been received throughgiven smsc (smsc) from ms-isdn address (ms), and from given NBS port (port). The request contains thetoken, group-name, and item-name fields.

recv IL:token:group-name from smsc:ms:port. Item list request has been received through given smsc(smsc) from ms-isdn address (ms), and from given NBS port (port). The request contains the token, and thegroup-name fields.

(smsc, ms) ⊄ AuthorizedServers(group-name). The pair (smsc, ms) is not associated with the group-namein the AuthorizedServers set, i.e., the group is in the AuthorizedServers set (authorization is required), but themessage source address does not match any of the authorized servers. It should be noted that the group forwhich authorization is not required, should never be put into the AuthorizedServers set. The underlyingassumption is that if the group does not exist in the AuthorizedServers list, then no authorization is required.

(smsc, ms) ⊂ AuthorizedServers(group-name). The pair (smsc, ms) is associated with the group-name inthe AuthorizedServers set, or the group-name does not exist in the AuthorizedServers set, i.e., either the serveridentified with the pair is authorized, or no authorization is required.

(group-name, item-name) ⊂ StoredItems. A menu item which is uniquely identified by the pair (group-name, item-name), w, exists in the handset.

(group-name, item-name) ⊄ StoredItems. A menu item which is uniquely identified by the pair (group-name, item-name), does not exist in the handset.

token == StoredItems.(group-name, item-name)-> token. The authorization token received in the request isthe same as the one stored for the menu item identified by the pair (group-name, item-name), i.e.,authorization based on token matching is successful.

token <> StoredItems.(group-name, item-name)-> token. The authorization token received in the request isnot the same as the one stored for the menu item identified by the pair (group-name, item-name), i.e.,authorization based on token matching is not successful.

recv AA:group-name:server-list from smsc:ms:port. The authorization add request has been receivedthrough the given smsc (smsc) from the ms-isdn address (ms), and from the given NBS port (port). Therequest contains the group-name and server-list fields.

recv AR:group-name:server-list from smsc:ms:port. The authorization remove request has been receivedthrough the given smsc (smsc) from the ms-isdn address (ms), and from the given NBS port (port). Therequest contains the group-name and server-list fields.

recv AL:group-name from smsc:ms:port. The authorization list request has been received through the givensmsc (smsc) from the ms-isdn address (ms), and from the given NBS port (port). The request contains thegroup-name field.

recv DC:identifier from smsc:ms:port. The device capability request has been received through given smsc(smsc) from ms-isdn address (ms), and from given NBS port (port). The request contains the identifier field.



(smsc, ms) ⊂ AuthorizedServers(DC). The pair (smsc, ms) is associated with the special group-name fordevice capabilities in the AuthorizedServers set, or the group-name does not exist in the AuthorizedServersset, i.e., either the server identified with the pair is authorized, or no authorization is required. It is handsetimplementation-specific as to which servers are authorized to access the device capabilities. Therecommendation is to allow servers enabled to access operator and manufacturer menus to access devicecapabilities.

(smsc, ms) ⊄ AuthorizedServers(DC). The pair (smsc, ms) is not associated with the special group-name fordevice capabilities in the AuthorizedServers set, i.e., the server identified with the pair is unauthorized to usedevice capability request.

identifier == “LAN”. The server requests information concerning the current language in effect in thehandset.

identifier == “INFO”. The server requests information concerning the handset in general, i.e., thisinformation contains manufacturer name, model name, and may contain manufacturer-specific informationlike firmware version, and firmware update date.

4.2.10 Action DescriptionsUnauthorized (server not accepted). The server is not authorized to use the requested command, because theserver from which the command is sent is not found in the authorization list for the menu. It isimplementation-specific in that a generic error response is either sent back to the server or not. Because thehandset user incurs the cost of sending the error response, this should be limited to special cases.

Unauthorized (token not accepted). The server is not authorized to use the requested command, because thetoken used does not match the initial token used to add the item. It is implementation-specific in that a genericerror response is either sent back to the server or not. Because the handset user incurs the cost of sending theerror response, this should be limited to special cases.

StoredItems := StoredItems ∩ (group-name, item-name). Remove the menu item uniquely identified by thepair (group-name, item-name) from the set of StoredItems.

StoredItems := StoredItems ∪ (group-name, item-name)->token:group-name:item-name:item-type:item-help:action-list. Add the menu item uniquely identified by the pair (group-name, item-name) to the set ofStoredItems. After this addition, the handset will be able to show the menu item in its menu structure.

Error (Item does not exist). Access to an item that does not exist in the StoredItems. No action.

Generate reply to smsc:ms:port with list of items with matching token. Generate response to the Item listcommand with a list of menu items in the given menu which have a matching token, i.e., scan through themenu items that belong to the given menu, and have a matching token, and generate a reply based on thesecriteria.

Generate reply to smsc:ms:port with empty item list. No matching items, i.e., generate an empty responseto the item list command.

AuthorizedServers := AuthorizedServers ∪ (group-name)->server-list. Add to the set ofAuthorizedServers an association of group-name, server-list., i.e., make all servers listed in the server-listauthorized to access the menu-group.

AuthorizedServers := AuthorizedServers ∩ (group-name)->server-list. Remove from the set ofAuthorizedServers all associations between group-name and any server in the server-list, i.e., removeauthorization to access the group from all the listed servers.

Generate reply to smsc:ms:port with list of AuthorizedServers(group-name). Generate a response to theauthorization list request with all the servers that are associated with the given group.



Generate reply to smsc:ms:port with current language selected in handset. Generate a response to thedevice capability request concerning language.

Generate reply to smsc:ms:port with handset information (manufacturer, model, firmware version,date). Generate a response to the device capability request concerning generic device information.

4.2.11 Informative Examples

4.2.11.1 Protocol Action ExamplesMessage example that adds three entries to the home operator menu. The first item enables user to select the“Call Customer Service” menu item, and then a call will automatically be made to the operator’s customerhelp desk. The second item will cause a supplementary service string to be sent to the network. This string willcause all calls to be forwarded to the user’s voice mailbox. The third item is a linked item which prompts thehandset to send a SMS message that causes the operator’s server to send back volatile menu items associatedwith (“OPER Radiolinja”, “Billing:Info”) pair.

BODY:IA:OPER RadiolinjaCall:Customer:ServiceNAutomatically call Radiolinja customer service.C VOICE+35850123456w123--IA:OPER RadiolinjaAll calls:to voice:mail boxN

C SS**21*555123456789#--IA:OPER RadiolinjaBilling:infoL

M SMS+35850123/+358501234567/550838:BODY:RM:OPER RadiolinjaBilling:Info



4.2.11.2 Phone UI ExamplesThe first phone UI example (Fig 4.2-2.) shows two menu items in a operator-specific menu. The firstitem initiates a call to the operator’s customer help desk. The second item indicates the state of a serviceprovided in the network. This is implemented by an item linked with a selected (volatile) value. As thisvolatile value is found in the handset memory, it is shown to the user.

Select

OPERATOR MENU Select Quit

Select View options Quit

Call Customer Service Select Quit

Automatic caller ID On Select Quit

Select On Off Ok Quit

On Off Ok Quit

Automatic caller ID Requesting Select Quit

Ok

Serverconfirms

Automatic caller ID Off Select Quit

Calling +3 5840123456

Menu Item withcall control action:

Menu Item withvolatile selection listand known selected value:

Figure 4.2-2. Phone UI example 1.

The second phone UI example (Fig 4.2-3.) shows a situation in which the state of a service provided inthe network is not known. In order to provide to the user information on the selected (active) state of theservice, as well as the possible states available, the phone requests linked menu items from network.



Automatic caller ID unknownSelect Quit

Select

On Off Ok Quit

Automatic caller ID Requesting Select Quit

Serverconfirms

Menu Item withvolatile selection listand unknown state:

Figure 4.2-3. Phone UI example 2.



4.3 TAGGED TEXT MARKUP LANGUAGE (TTML)

TTML (Tagged Text Markup Language) makes it possible to use a HTML-like markup language in anenvironment with mixed terminals. It supports clients with limited capabilities, i.e. legacy mobile phones, aswell as advanced Value Added Services-enabled phones with browser functionality. The protocol and pagelayout conventions (conversion rules) support the requirements of this mixed terminal base to guarantee easydevelopment as well as solid implementation.

The TTML language provides means to

• enter text into fields

• make selections from different kinds of menus

• jump to links (using anchors)

At the end of the section there are a number of examples. These examples show the user interface in a legacyphone, i.e. the user will see the pages “as is”. The use of intuitive tags and layout in legacy phones requiresonly minor learning even for an untrained user. For even more user friendly applications a Browser (i.e. anadaptation of the phone UI) may be provided. The browser automates the editing otherwise done by the user.

The TTML Gateway or Server listens to the NBS port 5580 decimal (15CC hexadecimal).

4.3.1 TTML Protocol DescriptionThe TTML protocol has been optimized for use on SMS and USSD bearers. When implemented in GSM or insystems derived from GSM, the protocol has the following features specific to GSM Short Message Service:

• Concatenation of message fragments is supported.

• Only request forms “one SMS long” (160 characters, including possible headers) are supported in theuplink of TTML 1.0 , i.e. a filled form can reside on the first fragment

• The protocol implements a reverse logic. Selections are made by removing a single character (“*” or“#”). Selection list might have preselections done already in the downlink message.

• As opposite to other markup languages (for example HTML) only a single form can reside on a page.However, the form might contain several form-parts, intended to be interpreted by a single script in theserver.

4.3.1.1 Formal TTML Protocol SpecificationThe protocol is implemented according to the following definitions:

Downlink

; ‘downlink is messages from server to mobile device’

<downlink-TTML-page> ::= [ <header-line> ] <page-content>*



;’header line is mandatory if the page-content contains a form.

<page-identifier> ::= <default-char-not-ld-or-space>+

; ‘page-identifier is case-insensitive. Must not be sequence starting with “*#*#*#”.’

<header-line> ::= <header-esc> [<page-identifier> | <default-page-identifier>] <header-item>* <line-delimiter>;’the header-line enables the client and/or the server to exchange operational parameters. It can be used inuplink as well as in downlink.

<header-item> ::= <wait-indicator> |<client-protocol-version> | <client-buffer-size> | <ttml-SAP-information> | <future-header-extension>

<wait-indicator> ::= <comma>”w”<default-char-not-ld-or-space>*

;’ the characters after the “w” are for future protocol extensions

<client-protocol-version> ::= <comma> ” v” <protocol-version-number>

;’ when no version number is present, version 1 is defined.

<client-buffer-size> ::= <comma> “s” <byte-size-of-buffer>

;’ the buffer size defines the maximum page size the client can handle

<ttml-SAP-information> ::= <comma> “a” <common-destination-ms-isdn> “/“ <common-destination-smsc-ms-isdn>

;’ The Service Access Point defines the location (SMSC, destination number) of the available service

<protocol-version-number> ::= <default-char-not-ld-or-space>+

<byte-size-of-buffer> ::= <default-char-not-ld-or-space>+

<future-header-extension> ::= <comma> <default-char-not-ld-or-space>*

<default-page-identifier> ::=

“*#*#*#” [ <common-language> ] <line-delimiter> ; ‘Language’

;’the default-page-identifier is a language independent keyword used to request the “homepage” of theserver/gateway’

<page-content> ::= <default-char>* | <form-part> <line-delimiter>

<default-char-not-ld-or-space> ::= ‘Any character in the default character set (or in character set explicitlyindicated) except <line-delimiter> or <space>. In GSM, the GSM character set from 3.38/3.40.’

<form-part> ::=

<anchor-selection> |

<alpha-input-prompt> |

<numeric-input-prompt> |

<one-of-many-input-selection> I

<many-of-many-input-selection> |

<extension-escape-sequence>

<anchor-selection> ::= <anchor-selection-prompt> <anchor-selection-option>+

<anchor-selection-prompt> ::= <jump-list-esc> <prompt-text>

<anchor-selection-option> ::=

<loc-jump-esc> <char5> <prompt-text> |

<glob-jump-esc> <char5> <prompt-text>

; ‘the anchor-selection form part presents a list of hyperlinks’



<alpha-input-prompt> ::= <alpha-entry-esc>[ <input-field-length>]<prompt-text> <prompt-sentinel>[<space>*<entry-suggestion>]<space>*

<numeric-input-prompt> ::= <digit-entry-esc>[ <input-field-length>] <prompt-text> <prompt-sentinel>[<space>*<entry-suggestion>]<space>*

; ‘the input-prompt form-parts allow for entry of text or numbers’

<input-field-length> ::= <digit>+ ; ‘one or more digits defining the maximum size of the input field’

<entry-suggestion> ::= <default-char-not-ld>+

<prompt-text> ::= <default-char-not-ld>+ ; ‘input prompt text, not reserved char sequence. Cannot start with adigit’

<prompt-sentinel> ::= “:” | “?”

<one-of-many-input-selection> ::= <one-of-many-input-prompt> <one-of-many-input-option>+

<one-of-many-input-prompt> ::= <one-list-esc> <prompt-text>

<one-of-many-input-option> ::= <select-esc> [<char5>] <prompt-text>

;’form-part similar to radio buttons’

<many-of-many-input-selection> ::= <many-of-many-input-prompt> <many-of-many-input-option>+

<many-of-many-input-prompt> ::= <many-list-esc> <prompt-text>

<many-of-many-input-option> ::= <select-esc>[<char6>] <prompt-text>

;’form-part similar to checkboxes’

<extension-escape-sequence> ::= <extend-esc> <extend-string> <line-delimiter>

;’form-part for advanced and future features, provides protocol extension capability’

<extend-string> ::= <hidden-field> | <hidden-variable-field> | <request-prompt> | <default-char-not-ld>*

<hidden-field> ::= “H” <default-char-not-ld>+ <line-delimiter>

<hidden-variable-field> ::= “V” [ <hidden-presentation>”:” ] <default-char-not-ld>+ <line-delimiter>

<hidden-presentation> ::= <default-char-not-ld>+ ; ’name of hidden field’

<request-prompt> ::= “R”<default-char-not-ld>+ ; ‘The request-prompt (a user interface button) is used forvisual purposes as well as to define the prompt text before sending the request. The request-prompt isoptional’.

<header-esc> ::= [<line-delimiter>] <char1> <char1> ; ‘line-delimiter optional if first char on page, orimmediately after NBS header.’

<alpha-entry-esc> ::= <line-delimiter> <space>* <char3>

<digit-entry-esc> ::= <line-delimiter> <space>* <char3> <char3>

<select-esc> ::= <line-delimiter> <space>* <char1> <char2>

<loc-jump-esc> ::= <line-delimiter> <space>* <char2> <char2>

<glob-jump-esc> ::= <line-delimiter> <space>* <char3> <char2>

<extend-esc> ::= <line-delimiter> <space>* <char2> <char3>

<one-list-esc> ::= <line-delimiter> <space>* <char2> <char1>

<many-list-esc> ::= <line-delimiter> <space>* <char3> <char1>

<jump-list-esc> ::= <line-delimiter> <space>* <char1> <char3>

<char1> ::= “.”; ‘Hex value 2Eh’



<char2> ::= “>”; ‘Hex value 3Eh’

<char3> ::= “<”; ‘Hex value 3Ch’

<char4> ::= “=”; ‘Hex value 3Dh. Manipulation char, special meaning only when escaped by <line-delimiter><space>* { <char1> | <char2> | <char3> }.’

<char5> ::= “*”; ‘Hex value 2Ah. Manipulation char, special meaning only when escaped by <line-delimiter><space>* { <char1> | <char2> | <char3> }.’

<char6> ::= “#”; ‘Hex value 23h. Manipulation char, special meaning only when escaped by <line-delimiter><space>* { <char1> | <char2> | <char3> }.’

Uplink

<uplink-TTML-page> ::=

[ <header-line> | <page-identifier> | <default-page-identifier> ] <page-request-content>*

<page-request-content> ::= <default-char>* | <form-request-part> <line-delimiter>

<form-request-part> ::=

<anchor-selection-request> |

<alpha-input-reply> |

<numeric-input-reply> |

<one-of-many-input-selection-request> I

<many-of-many-input-selection-request> |

<extension-escape-sequence>

<anchor-selection-request> ::= [ <anchor-selection-prompt> ] <anchor-selection-option-request>+

<anchor-selection-prompt> ::= <jump-list-esc> <prompt-text>

<anchor-selection-option-request> ::=

<loc-jump-esc> <char5> <prompt-text> |

<loc-jump-esc> <prompt-text> |

<glob-jump-esc> <char5> <prompt-text> |

<glob-jump-esc> <prompt-text>

<alpha-input-reply> ::=

<alpha-entry-esc>[ <input-field-length>] <prompt-text> <prompt-sentinel><space>*

<default-char-not-ld>* <space>*

<numeric-input-reply> ::=

<digit-entry-esc>[ <input-field-length>] <prompt-text> <prompt-sentinel><space>*

<default-char-not-ld>*<space>*

<one-of-many-input-selection-request> ::= <one-of-many-input-prompt> <one-of-many-input-option-list>+

<one-of-many-input-option-list> ::=

<one-of-many-input-option> | ; ‘non-selected input options’

<one-of-many-input-option-request> ; ‘one selected input option’



<one-of-many-input-option-request> ::= <select-esc> <prompt-text>

<many-of-many-input-selection-request> ::= <many-of-many-input-prompt> <many-of-many-input-option-list>+

<many-of-many-input-option-list> ::=

<many-of-many-input-option> | ; ‘non-selected input option’

<many-of-many-input-option-request> ; ‘one or more selected options’

<many-of-many-input-option-request> ::= <select-esc> <prompt-text>

Strict interpretation of the above protocol description indicates that one line-delimiter immediately followinganother is needed in some situations. However, in these cases the second line-delimiter can be dropped.

The usage of edited forms causes the response message (to the gateway) to be long. The user (or the browser)is allowed to remove unnecessary (for the interpretation of the request form) text from the original message.Observe that an unidentified extension tag shall not be removed from the uplink message, since it might be ofvalue to the Gateway/Server.

4.3.1.2 TTML Protocol RulesAn element, i.e. an item in the text, can be either a plain text element (ending with a <line-delimiter>, or endof message) or part of a form or a link. The form/link element must start with an escape sequence followed bya name/value, ending with a line-delimiter. The escape sequence might be of variable length since it cancontain a number of space characters for indention purposes. The maximum length of

• a plain text element is 254 characters

• a form/link element is 20 characters

• an entry to a text field is 155 characters

These restrictions in element length are defined in order to facilitate browser implementations in terminalswith severe memory constraints.

A number of the definitions and variables defined above are explained:

• header-line. The header line contains a list of configuration parameters separated by commas. Parametersnot known to the browser (or server) shall be ignored. The header-line is mandatory in the downlink, if apage-identifier is needed.

• hidden-variable. The format, and interpretation, of the hidden variable is the same as for the text entryfield (alpha-input-reply). However, the client shall not display the content to the user. The hiddenvariable is intended to be used as, for example, a state variable.

• hidden-field. The text (up to a line-delimiter) after an hidden-field indicator is not to be displayed to theuser.

• ttml-SAP-information (Service Access Point). The Service Access Point is usually the same as theoriginator of the downlink page (i.e. the address of the server). By explicitly defining another SAP linksbetween servers can be created.

• wait-indicator. The TTML-Server can include a wait-indicator on the downlink page to indicate to theclient that the service is interactive. The user interface of the client is thus able to inform the user that itis waiting for a new page from the server.



• page-identifier. The page-identifier is similar to the URL of a HTML page. It is a unique identifier in thecontext of a TTML server (or gateway). It must be present whenever a TTML form is used. The page-identifier is often part of the header-line, but can also reside separately in the uplink.

• byte-size-of-buffer. If the buffer size is indicated by the client it must be able to handle concatenatedmessages as well as forms of the given size. The default size of the client buffer is 415 bytes. If therequest for a page has been done without a NBS port number then the server shall assume that the clientcannot handle forms on any but the first message fragment (160 characters). The plain text part of thedownlink message can still be longer.

• client-protocol-version. The default protocol version is “1”, and indicates that the client might notsupport more than 415 byte forms.

• Word. A word as part of a form must be unique in it’s context. A word representing a selection in aselection-list must be unique in this list, but it can be reused in another selection-list, even on the samepage. A word representing a hyperlink can occur several times on a page, but will reference the sametarget page.

• Local hyperlink. The word expressing a local hyperlink has a unique interpretation on the TTML page(page-identifier) where it is used, but it can be reused on other pages. The “anchor-selection-prompt” isfor descriptive purpose only, and is not valid in the uplink message.

• Global hyperlink. A global hyperlink must be unique in the TTML-server, i.e. the same hyperlink textcan not be reused to refer to other pages. The “anchor-selection-prompt” is for descriptive purpose only,and is not valid in the uplink message.

• extension-escape-sequence. The extensions enables for future enhancements of the TTML protocol. If thepage contains an element not identified by the browser it shall be hidden from the user, but sent back tothe server with the request.

• Form. A form is regarded to be equal to the form presentation in HTML (i.e. the items between <FORM>and </FORM>). Thus the form can include items such as selections lists, multi-selections lists andtext/digit entry.

• Page. A page is regarded as a TTML page as seen by the client. The page might consist of multiplefragments in the communications media (i.e. SMS).

4.3.1.3 Short Message ConcatenationConcatenation support in the browser is mandatory. The browser knows about long messages only usingconcatenation headers. In version 1 of the TTML protocol only the downlink supports multi-fragmentmessages.

• Plain text pages can be concatenated

• Forms can span over page boundaries. However, a few design recommendations should be taken intoaccount:

• When designing pages for legacy phones it is important to restrict the forms to a single messagefragment. Pages with operations (selections, forms) can then only have them on the firstfragment of a concatenated message.

• In order to optimise transfer and response times request pages must fit into one SMS fragment.Selections on pages longer than one short message fragment shall be supported by the phone, aslong as the request form fits the first fragment (also when text has been entered)

• If the browser is used on a concatenated message consisting of at least two message fragments, aresponse can contain only as much as fits into one SMS (truncated) back to the server.



4.3.1.4 ExamplesTTML is characterized by equal support for browser phones and legacy phones. The examples below picturethe use of pages in legacy phones, with only basic SMS viewing and editing capabilities. The user interface ofphones with browser capabilities might of course be very different.

The page might be a plain menu, with a single selection list. In the uplink direction the page is used bydeleting a selection identifier “*”. In this and in the following examples, <char1> is replaced with ‘+’character for readability.

++MENU>+OperatorChoices+>*Flight-any+>*Flight-one+>*Restaurants+>*News+>*Bus-service+>*Stock-Exchange+>*Currency+>*Movie+>*GSM-prices

Pages often combine both forms and explanatory text.

++INVENTORY <Code: <<Amount: <<Date:Use the codesof the inventorymanual! Date informat ddmmyy.

4.3.1.4.1 Hyperlink Usage

A jump list (hyperlinks) is used to access new information. The links are direct references to pages availablevia the TTML server.

The TTML protocol specified two kinds of hyperlinks, local and global. The local links use keywords that areunique in the context of the specific page, while the global hyperlink is unique in the context of the server.

Next is an example of a typical global hyperlink set-up. A keyword like “News” is prone to be reused as a localhyperlink on many pages, while a global hyperlink can be used only once. Therefore the Reuters news serviceis called “News-Reuters” rather than only “News”.



++MENUSelect one of our global+<services:<>*Flight-Finnair<>*Restaurants-Michelin<>*News-Reuters<>*Stock-Exchange<>*Currency-Merita<>*Movie-by-Rcity<>*Bus-serviceHave a good day!

The server will then interpret the above as a global keyword, or as a local (page-specific) keyword.

A link selection, for example “Bus-service” (<>Bus-service) could cause the whole (edited) page to be resentto the server. It is possible to reduce the content of the request in such a way that it contains only one word, i.e.the global keyword.

Bus-service

The TTML server will respond by sending the page referenced by the specific page-identifier.

Example of a typical local hyperlink service

++HA-MENUSelect one of HELSINKI AIRPORT+<services:>>*Flight-depart>>*Flight-arrival>>*Restaurants>>*Bus-service>>*Newsor select the service page of+<Radiolinja<>*GSM-050Have a good day!

A linked selection, for example “Bus-service” (>>Bus-service), could cause the whole (edited) page to beresent to the server. An alternative is to reduce the content, and send only the page-identifier (mandatory) ofthe page and the selected link.

HA-MENU>>Bus-service

or

++HA-MENU>>Bus-service

The hyperlink is not part of a form, but an independent selection.



4.3.1.4.2 Reducing Content

A user interface which automates the editing of the message, i.e. a browser, can optimize the usage of thebearer channel by reducing content for the uplink. A downlink page including free-text can be reduced in sizebefore it is sent to the Server. All free-text can be removed. Only the page-identifier, text entry fields andselections are valid uplink information. The page-identifier is a mandatory field if the uplink page contains aform or a local hyperlinks. If the uplink page contains a selection from a single- or multi-selection list thenthe “one-of-many-input-prompt” or the “many-of-many-input prompt” are also mandatory.

The downlink page:

++PIZZAORDEROrder the best pizzas in town fromManolo. Lots of cheese and toppings. >+pizza +>*Florida +>*Margarita +>*QuattroStagione <address:1/2 hour for delivery!.

might be edited and reduced for uplink as:

++PIZZAORDER>+pizza +>Florida <address: Village Circle 2 F 34

Using this method air time usage can be reduced, thereby reducing the cost involved.

4.3.1.4.3 Header Combinations

Headers can be combined in a number of ways. The following examples explain a number of these.

Downlink

//SCKL15CC CR++ page-identifier CR text

//SCKL15CC//SAP123-456 CR++ page-identifier CR text

//SCKL15CC14AA230201//SAP123-456 ++ page-identifier CR text

++page-identifier text

text

CR++ page-identifier text

Uplink

//SCKL15CC CR++ page-identifier,v2,s450 CR text

page-identifier text



page-identifier

The NBS port address can be presented in text format, as in the examples, but it can also be in binary format.In that case the <space> after the NBS header is equal to the end of the binary header.

//SCKL15CC15CC090201++NEWSfree-text +<newsjumps >>*SportNews >>*FinancialNews >>*NationalNewsfree-text

//SCKL15CC15CC090202 >>*RegionalNews >>*WeatherNewsfree-text,…

4.3.1.4.4 Service Access Point Presentation

The message can be defined to have a Service Access Point different from the sender. When the user replies tothe message/form the request is sent to the address defined as SAP. This makes it possible to create adistributed server architecture, as well as broadcast support.

The downlink page:

//SCK15CC++NEW_LINKS,a9919-35850123456Here are a number of links from anew content provider.+<services:>>*Movies>>*Theater>>*EatingEnjoy the information! Sponsored byNOKIA.




Smart Messaging END


5. APPENDIX A: RESERVED PORTNUMBERS

5.1 INTRODUCTION

The NBS specification enables port addresses in range of [0..65535] decimal. This range is divided intoreserved port address range and dynamic and/or private port address range.

Please note: In the earlier version of the specification, the port number space was not the same as IANA portnumber space. However, WAP Forum’s WDP protocol [WAP_WDP], when run over GSM SMS, is essentiallyidentical to NBS. If UDP is available, that can be used instead of WDP, in which case the UDP datagramshave the same port numbers as the WDP datagrams. Therefore, WDP port number space is the same asIANA’s TCP/UDP port number space. See section 2.1 for more information.

Usage of the reserved port address range of [0..49151] decimal is restricted, and assignment of a port in thisrange requires a port address assignment authority. The assuagement authority is either Nokia or IANA,depending on the protocol used (NBS or WDP). For more information on the registration procedure, contactNokia Third Party Support. The reserved port address range is further divided into ports for “Well-knownprotocols” (ranges [0..1023] decimal), and registered ports (range [1024..49151] decimal).

Port addresses in the dynamic/private address range of [49152..65535] decimal may be used freely by anyvendor. No registration is required and thus the ports can be used dynamically. These address ranges are notmoderated, so conflicts in port addressing may occur.

Smart Messaging END


5.1.1 NBS ProtocolThe NBS protocol is described in the Narrow Band Socket Specification [NBS_SPEC], available at Nokia andIntel World Wide Web sites. This section is only intended to describe some of the key features of the NBSprotocol.

NBS is intended to use the momentum of the Internet world to create a new set of applications in the extremenarrow band world. The NBS protocol is a datagram protocol, equal to UDP in the Internet world. Theparadigm has been adapted to the very narrow channel of SMS and USSD. It provides device addressing, i.e.phone numbers, and port addressing, i.e. application level addressing. The NBS protocol enables devices tohave multiple active applications, each identified by a port number.

The protocol allows for text headers as well as binary headers (using the concept of User-Data-Headers).Either one can be used depending on the infrastructure of the network and the devices used, as well as theapplication.

The NBS protocol is designed to be modular and expandable. New headers can be added as need arise, theyare concatenated to the end of the existing headers.

Text headers are positioned in the beginning of each short message. The NBS text header ends with a NBS-delimiter (space or line-delimiter) character. Text headers are specified as follows:

<NBS-text-socket-header> ::= <NBS-keyword> <NBS-port-information> [<NBS-other-header> ] <NBS-delimiter>

<NBS-delimiter> ::= <space>

<NBS-keyword> ::= “//SCK”

<NBS-port-information> ::=

<NBS-short-destination-address> |

<NBS-short-destination-address> <NBS-short-source-address> |

<NBS-short-destination-address> <NBS-short-source-address> <NBS-SAR-information> |

“L” <NBS-long-destination-address> |

“L” <NBS-long-destination-address> <NBS-long-source-address> |

“L” <NBS-long-destination-address> <NBS-long-source-address> <NBS-SAR-information>

<NBS-other-header> ::= “//” <default-char-not-space>*

<NBS-short-destination-address> ::= <common-hex-digit> <common-hex-digit>

; ‘Destination NBS port in ISO 8859-1 coded hexadecimal [00..FF], i.e., decimal [0..255]. When the shortdestination address presentation is used alone, then the source address of the message is defaulted to be thesame as the destination address.’

<NBS-short-source-address> ::= <common-hex-digit> <common-hex-digit>

; ‘Source NBS port in ISO 8859-1 coded hexadecimal [00..FF], i.e., decimal [0..255].’

<NBS-long-destination-address> ::=

<common-hex-digit> <common-hex-digit> <common-hex-digit> <common-hex-digit>

; ‘Destination NBS port as a string of ISO 8859-1 characters, hexadecimal [0000..FFFF].’

<NBS-long-source-address> ::=

<common-hex-digit> <common-hex-digit> <common-hex-digit> <common-hex-digit>

; ‘Source NBS port as a string of ISO 8859-1 characters, hexadecimal [0000..FFFF].’

<NBS-SAR-information> ::=

<NBS-SAR-reference> <NBS-SAR-total-fragments> <NBS-SAR-current-fragment>

<NBS-SAR-reference> ::= <common-hex-digit> <common-hex-digit>

; ‘Concatenated message reference number as a string of ISO 8859-1 characters, hexadecimal [00..FF].’

Smart Messaging END


<NBS-SAR-total-fragments> ::= <common-hex-digit> <common-hex-digit>

; ‘Concatenated message total fragment count as a string of ISO 8859-1 characters, hexadecimal [01..FF].’

<NBS-SAR-current-fragment> ::= <common-hex-digit> <common-hex-digit>

; ‘Concatenated message segment index as a string of ISO 8859-1 characters, hexadecimal [01..FF].’

For GSM, the binary headers use the concept of User Data Header as defined in [GSM_03.40]. Theinformation elements 00h for concatenation and 04h and 05h for port addressing are used.

5.1.2 WDPThe WDP (Wireless Datagram Protocol), defined by WAP Forum in [WAP_WDP], is essentially identical toNBS protocol when run over GSM Short Message Service. WDP specifications are available from WAPForum World Wide Web site.

Smart Messaging END


5.2 RESERVED PORT NUMBERS

An up-to-date listing of reserved TCP/UDP port numbers is available from IANA (http://www.iana.org/). Thefollowing port numbers have been reserved from the NBS port number space. For the latest list, please contactNokia Third Party Developer Support.

Smart Messaging END


Table 5-1. Reserved Port Numbers in NBS port number space

Port Number(decimal)

Port Number(hexadecimal)

Application/Protocol

0 0 Default port for transparent (legacy) messages80 50 WWW Server (HTTP)226 E2 Generic Business Card exchange (MIME vCard) Card

reader228 E4 Calendar Items (MIME vCalendar) Calendar reader5501 157D Compact Business Card reader5502 157E Service Card reader5503 157F Internet Access Configuration Data reader5504 1580 <RESERVED>5505 1581 Ringing Tone reader5506 1582 Operator Logo5507 1583 CLI Logo5508 1584 Dynamic Menu Control Protocol5509 1585 <RESERVED>5510 1586 <RESERVED>5511 1587 Message Access Protocol5512 1588 Simple Email Notification5513 1589 <RESERVED>5514 158A <RESERVED>5580 15CC Character-mode WWW Access (TTML)5601 15E1 <RESERVED>5603 15E3 <RESERVED>8500 2134 <RESERVED>8501 2135 <RESERVED>8502 2136 <RESERVED>

Table 5-2. Smart Messaging-Related Port Numbers in TCP/UDP Port Number Space

Port Number(decimal)

Port Number(hexadecimal)

Application/Protocol

9204 23F4 WAP vCard9205 23F5 WAP vCalendar9206 23F6 WAP vCard Secure9207 23F7 WAP vCalendar Secure

Smart Messaging END


Smart Messaging Specification

1996, 1997, 1998, 1999 Nokia Mobile Phones Ltd.

Documents

Smart Messaging Specification, version 2.0.0 ()affon.narod.ru/GSM/ssm200.pdf · changed substantially prior to final release. This document is provided for informational purposes