3GPP Ad Hoc

Heathrow London
3-5 April 2001
T2E-010013

Uniting behind EMS

Barry Jones
April 2001
 Introduction
 The mobile industry faces a number of key
issues in establishing an all embracing
standard capable of future expansion to meet
the needs of the coming years
 Backward integration of existing technology and
content formats
 Support of current service requirements
 Flexibility to meet the needs of new technology
advances
 EMS - SWOT Analysis
Strengths
•Currently a de jure Standard
•Provides basic point to point
facilities for graphics and ringer tone
•Pre-eminence of SMS as VAS
bearer
Weaknesses
•Some elements are not optimised for
GSM bearers.
•Limited scope in terms of content support
•Lack of support for third party applications
development
•No support for multi-media compression
•Current iei structure will not support
growth of content formats required in next
2 years
Opportunities
•Foundation for an ongoing standard which
transends bearer services
•Embraces all content needs within a single
extensible format
•Provides a seamless link to MMS by
engaging Content application providers to
build services today which will challenge
the existing boundaries
Threats
•Fails to provide sufficient support for ASP
and NO VAS aspirations
•Failure of handset vendors to implement
EMS
•A de facto standard will emerge and
supercede EMS
•Format War because EMS fails to recognise
and embrace the content formats which are
required by users and service providers
 Linear Progression -Functionality

M S
M
Functionality

Magic4

S Digiplug
EM

SMS

Time
 GSM Standards vs Functionality
Standard

SMS EMS

Low features Highly Featured

Motorola Jade ringer format Magic4 Content formats
Digiplug Ringer Format Nokia smart messaging
MIDI Sound
Polyphonic Sound
MP3 Sound
MPEG2

Proprietary
 Integration of Existing Technologies
 There are many existing formats for representing UI interaction with
graphics, animation and sounds
 Some of them are unsuitable for use with GSM because of
 low bandwidth
 Limited resolution display devices(screen and buzzer)
 Limited memory and processing power
 A new class of data formats has been developed independently of
standards to support the challenge of user and application developer
requirements as handset usage changes
 Standardisation needs to reflect the current situation and embrace
existing data formats as well providing a route for harmonizing data
formats and allowing innovators to enhance new service creation within
the existing standards framework
 If standards bodies do not embrace the challenge there will be a
greater fragmentation as handsets vendors, content vendors and
applications developers seek to meet the needs of end-users
independently of the standards bodies.
 The server technology exists to deliver compelling services over SMS
 Feature Comparison – Content formats (1)
Feature EMS Smart Magic4 Others
Messaging
Animation   
Pre defined   
Small (8x8 )pixels   
Large (16x16) pixels   
Any size   
Ringtone Download    Jade, Digiplug,MIDI, MP3
Forms Definition   
Language
Formatted Text   
Size   
Bold  

Underline  

Italic  
Strikethrough   
Alignment   
Wrap around   
Text Positioning   
Scrolling   
Tickertape   
 Feature Comparison – Content formats (2)
Feature EMS Smart Magic4 Others
Messaging
User Prompt indicator   
Combination Messages   
Animation   
Ringtone   
Formatted text   
Forms   
Multi part combination   
message
SMS Message arrival   
Indicator replacement
Message compression   
Text elements   
Multi-media elements   
Huffman   
LZSS   
Downloadable Dynamic  
Service Menus
Operator Logo   
replacement
 Feature Comparison – Content formats (3)
Feature EMS Smart Magic4 Others
Messaging

Media License lock   

Individual content elements   
Complete message   
Graphics   
Picture Messaging   
Large Picture   
Small Picture   
Variable sized Picture   
Colour Picture    Gif,JPEG
Business Card (vCard)   

Calendar Reservation (vCal)   

Service identification   

Phone Specific Command   

WAP Browser Settings   

Non-specific Binary Data   

 Support for Current Requirements
 Current service delivery requirements extend beyond
downloading new ringtones, replacement operator logo’s, and
simple embedded graphics.
 There are significant number of multi-national companies
looking for the opportunity to provide both horizontal and vertical
services to the consumer market, provided that the medium is
rich enough in features to enhance their brand.
 The display capacity of the phone is sufficient, if there are data
formats and a display engine capable of managing the content
on the handset.
 Data Formats which we need to incorporate include
 Service ID, variable sized graphics, Text positioning ,Graphics
positioning, Forms
 Dynamic menu’s, Subscription /Unsubscribe to services
 Browser settings, URL Launch for browsers
 Compression, Multiple medium messages, Content Copyright
protection.
Flexibility : Support for New Technologies
 The structure of EMS format must be flexible enough to enable
the integration of support for new hardware or performance
capability in the phone ie
 the addition of a polyphonic/MIDI ringer or MP3 player in the phone.
 Introduction of a colour screen
 It must also reflect the capacity to embrace Network changes
such as SMS over GPRS
 If the structure is flexible it is easier to model what is required in
the real world so that it is not a standards issue each timer a
new technology or application step is made.
 Key Functional additions to EMS

 Addition of support for New Format types

 Compression of data within the User Data
Header
 Support for Larger messages with Data
greater than 1 packet.
 Enhancement of existing Features within the
current Specification.
 Proposal(2)
 In addition to creating 5 generic classes which support format
tags we suggest the creation of a group of iei’s to enhance the
delivery of Value Added Services to the handset.
IEI No Title Description Reference
19 Compressed Byte Stream Enables all data types within
multiple part messages to be
compressed for delivery to the
handset
1A Predefined form Enables delivery of predefined
forms to support data capture to be
delivered to the handset and
displayed
1B Dynamic Menu Defines a dynamic menu format for
storing registered services in the
handset
 Current Standardization Status (2)

 There is support for compression of Text

within the SMS packet
 There is no support for compression of all
data within the UDH

EMS scope is limited by its lack of support for compression of images and
Other elements within the SMS packet, Compression of all data within an
SMS combined with concatenation of the total bytestream enables richer
services to be delivered to handsets
 Proposal (2)
Ringer Frame1 Frame 2 Frame 3 Frame4 Frame 5 Frame 6 Frame 7 Frame 8 Frame 9 Text Picture 1

Currently requires 10 concatenated messages so not practical

Hdr Ringer Frame1 Frame 2 Frame 3 Frame4 Frame 5 Frame 6 Frame 7 Frame 8 Frame 9 Text Picture 1

Compression Header
00 No Compression
01 CM1
02 CM2
03 Reserved

Compression of all data leads to significant reduction in the overall message

size and richer service delivery to the handset.
 Creating a Framework for Inclusive
Development (Step1)

 Use of PID value EMS

 Inclusion of generic IEI’s for large format EMS
messages
 Addition of a group of second level tags for specific
formats
 Modification of EMS to include a compressed Byte
stream option
 Creating a Framework for Inclusive
Development (Step2)

 It is proposed that we establish an ad hoc

working group to examine the enhancement of
EMS
 Support for existing content formats
 Extension of its scope to meet the needs of current
service provision
 Identify the opportunities to create a flexible
delivery medium via SMS for future requirements.
 Report back to the next meeting.