uniting behind ems 2

8/8/2019 Uniting Behind EMS 2

1/19

Uniting behind EMSUniting behind EMS

Barry Jones

April 2001

3GPP Ad HocHeathrow London

3-5 April 2001T2E-010013


2/19


3/19

EMSEMS -- SWOT AnalysisSWOT Analysis

Strengths Opportunities

Weaknesses Threats

Currently a de jure StandardProvides basic point to point

facilities for graphics and ringer tone

Pre-eminence of SMS as VAS

bearer

Foundation for an ongoing standard whichtransends 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 applicationsdevelopment

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

EMSA 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


4/19

Linear ProgressionLinear Progression --FunctionalityFunctionality

SMS

Magic4

Digiplug

Time


5/19

GSM Standards vs FunctionalityGSM Standards vs Functionality

Standard

Proprietary

Highly FeaturedLow features

Magic4 Content formats

Nokia smart messagingMotorola Jade ringer format

Digiplug Ringer Format

SMS EMS

MIDI Sound

MP3 Sound

MPEG2

Polyphonic Sound


6/19

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 ofstandards to support the challenge of user and application developerrequirements as handset usage changes

Standardisation needs to reflect the current situation and embraceexisting data formats as well providing a route for harmonizing dataformats and allowing innovators to enhance new service creation withinthe existing standards framework

If standards bodies do not embrace the challenge there will be agreater fragmentation as handsets vendors, content vendors andapplications developers seek to meet the needs of end-usersindependently of the standards bodies.

The server technology exists to deliver compelling services over SMS


7/19

Feature ComparisonFeature Comparison Content formats (1)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


8/19


Feature EMS Smart

Messaging

Magic4 Others

User Prompt indicator

Combination Messages

Animation

Ringtone

Formatted text

FormsMulti part combination

message

SMS Message arrival

Indicator replacement

Message compression

Text elementsMulti-media elements

Huffman

LZSS

Downloadable Dynamic

Service Menus

Operator Logoreplacement


9/19


Feature EMS Smart

Messaging

Magic4 Others

Media License lock

Individual content elements

Complete message

Graphics

Picture MessagingLarge 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


10/19

Support for Current RequirementsSupport for Current Requirements

Current service delivery requirements extend beyonddownloading new ringtones, replacement operator logos, andsimple embedded graphics.

There are significant number of multi-national companieslooking for the opportunity to provide both horizontal and verticalservices to the consumer market, provided that the medium isrich enough in features to enhance their brand.

The display capacity of the phone is sufficient, if there are dataformats and a display engine capable of managing the contenton the handset.

Data Formats which we need to incorporate include

Service ID, variable sized graphics, Text positioning ,Graphics

positioning, Forms Dynamic menus, Subscription /Unsubscribe to services

Browser settings, URL Launch for browsers

Compression, Multiple medium messages, Content Copyrightprotection.


11/19

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.


12/19

Key Functional additions to EMSKey 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.


13/19

Current Standardization Status (1)Current Standardization Status (1)

There exists a PID valuefor EMS

There exist 10 content

types defined under

current EMS structureusing iei codes

There are 11 available

iei numbers available for

future allocation

OA Text Formatting

0B Predefined Sound

0C User Defined Sound

0D Predefined Animation

0E Large animation

0F Small animation

10 Large Picture

11 Small Picture

12 Variable Picture

13 User Prompt Indicator

14 - 1F reserved for future EMS

Information Elements

Identification codes

The current number of reserved iei values are insufficient to meet the

variations in content available today without new formats which will be

required the future which will lead to proliferation of proprietary solutions

outside the standardised coding schema.


14/19

Proposal (1)Proposal (1)

Maintain the existing 10 iei format assignments (0A-13) for reasons ofbackwards compatibility

Utilise additional reserved numbers as generic formats

Create a series of Format tags which reference specific format types

enabling the inclusion of current and future format types within aninclusive schema

If a particular Format is not supported within the phone throws away thedata and displays an error message MIDI format not supported

The important point is that the schema recognises that legacy formatsexist alongside new formats and allows them to be delivered within the

EMS delivery schema

14 Large EMS 14 Sound 01 Predefined sound

02 User Defined Sound03 Nokia format Ringtone

04 M4 format Ringtone

05 Jade format Ringtone

06 MIDI

07 Polyphonic08 MP3

Example:iei Format code


15/19

Proposal(2)Proposal(2)

In addition to creating 5 generic classes which support format

tags we suggest the creation of a group of ieis to enhance the

delivery of Value Added Services to the handset.

IEI No Title Description Reference

19 Compressed Byte Stream Enables all data types withinmultiple part messages to be

compressed for delivery to the

handset

1A Predefined form Enables delivery of predefinedforms 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 thehandset


16/19

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 alldata 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


17/19

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 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.


18/19

Creating a Framework forInclusiveCreating a Framework forInclusive

Development (Step1)Development (Step1)

Use of PID value EMS

Inclusion of generic IEIs 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


19/19

Creating a Framework forInclusiveCreating a Framework forInclusive

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 provision

Identify the opportunities to create a flexible

delivery medium via SMS for future requirements.

Report back to the next meeting.

uniting behind ems 2

Documents