Uniting behind EMSUniting behind EMS

Barry Jones

April 2001

3GPP Ad HocHeathrow London 3-5 April 2001T2E-010013

Introduction 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 yearsBackward integration of existing technology and

content formatsSupport of current service requirementsFlexibility to meet the needs of new technology

advances

EMS - SWOT AnalysisEMS - SWOT AnalysisStrengths Opportunities

Weaknesses Threats

•Currently a de jure Standard•Provides basic point to point facilities for graphics and ringer tone•Pre-eminence of SMS as VAS bearer

•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

•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

•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 -FunctionalityLinear Progression -Functionality

EMS

SMS

MMS

Magic4

Digiplug

Fun

ctio

nal it

y

Time

GSM Standards vs FunctionalityGSM Standards vs Functionality

Standard

Proprietary

Highly FeaturedLow features

Magic4 Content formatsNokia smart messaging

Motorola Jade ringer formatDigiplug Ringer Format

SMS EMS

MIDI Sound

MP3 Sound

MPEG2

Polyphonic Sound

Integration of Existing TechnologiesIntegration 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 Comparison – Content formats (1)

Feature EMS Smart Messaging

Magic4 Others

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 Comparison – Content formats (2)Feature EMS Smart

MessagingMagic4 Others

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 Comparison – Content formats (3)Feature EMS Smart

MessagingMagic4 Others

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 RequirementsSupport 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 TechnologiesFlexibility : 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 EMSKey Functional additions to EMS

Addition of support for New Format typesCompression of data within the User Data

HeaderSupport for Larger messages with Data

greater than 1 packet.Enhancement of existing Features within the

current Specification.

Proposal(2)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)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)Proposal (2)

Ringer Frame 9 TextFrame1 Frame 2 Picture 1Frame 3 Frame4 Frame 5 Frame 6 Frame 7 Frame 8

Currently requires 10 concatenated messages so not practical

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

Compression Header

00 No Compression01 CM102 CM203 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 Creating a Framework for Inclusive Development (Step1)Development (Step1)

Use of PID value EMSInclusion of generic IEI’s for large format EMS

messagesAddition 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 Creating a Framework for Inclusive Development (Step2)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 provisionIdentify the opportunities to create a flexible

delivery medium via SMS for future requirements.

Report back to the next meeting.