0 © - Confidential, all rights reserved July 2005 OMTP Presentation OMTP LIMITED This document contains information confidential and proprietary to OMTP

1© - Confidential, all rights reserved

July 2005

OMTP Presentation

OMTP LIMITED

This document contains information confidential and proprietary to OMTP Limited. The information may not be used, disclosed or reproduced without the prior written authorisation of OMTP Limited, and those so authorised may only use this information for the purpose of

evaluation consistent with the authorisation.


July 2005

Content

1. OMTP Overview– Membership Structure– Relations with SDOs

2. Areas of Focus– Use Cases– Hardware– Application Platform– Application Security– Platform Technology Assessment

3. Deliverables 2005


July 2005

OMTP - Overview• Voce telephony and SMS are the only User Experiences

with mass market penetration today• Next generation of enablers facilitate new services but do

not in themselves create User Experiences to drive value propositions

• Creation of consistent User Experiences must contain:– Elements linking Operator Service Provisioning to Terminal UI and

Customisation– Usability (through simplicity, consistency, and where applicable,

differentiation) delivers Common UE requirements– Security for applications, content and transport

• Operator experiences show customisation drives usage and ARPU


July 2005

OMTP Members & Participants

MEMBERS

• SPONSORS

• ADVISORS

• ASSOCIATES

PARTICIPANTS:

• Only mobile network operators • Board to be elected by members

•2 year term in 2nd year • Participate in Board committees and Operations

Committee (TPC)• Participation in projects as contributor or reviewer

• Any entity willing to contribute to the OMTP activities • Right to be included in marketing, PR and/or website • Participation in projects as contributor or reviewer

• Any entity including platform providers as well as handset manufacturer and software/hardware suppliers etc.

• Participation in projects as contributor or reviewer

• Right to be included in selected communication and information flow

• No right to participate in projects


July 2005

PROJECT 1

PROJECT 2

PROJECT 3

PROJECT 4

PROJECT 5

OMTPMOBILE

OPERATORS

OMTPPARTICIPANTS

Relations with Vendors & SDOs

Standardisation Requirements

Technology and vendor agnostic sourcing

requirements

TECHNOLOGY VENDORS

STANDARDS BODIES

Approved standards

Technology

Technology

Common requirements


July 2005

Areas of Focus

UE Definition

Hardware and Defragmentation

Application Platform Reqt.

Application Security

Technology assessment

OMTP Driving principle:

OperatorBusinessRequirement

Drives

Use Cases

Define functional requirements for look & feel UE customisation

Define common operator requirements on hardware components and defragmentation

Define functional requirements for logical UE customisation

Define an Operator controlled Trust Environment for applications and content

Assess use cases against technology platforms


July 2005

Use cases drive terminal platform requirement

1. Message Composer: A customer can create and send a message in a single consistent way albeit there being many types of messaging methods (MMS, SMS, IM, email, etc)

2. Browser Interactions: A customer shall be able to seamlessly interact between the browser and other applications on the terminal (e.g., media player, contact database).

3. Basic Phone Functions: All terminals shall provide common core functionalities for basic phone functions; e.g., uniform use patterns of basic device functionalities

4. UI Customisation: An operator should be able to tailor the look and feel of the device menu structure to its own needs and requirements. This includes setting wallpaper, colour scheme of menus, selection of applications accessible from the top menu list, and applications accessible from the stand by screen.

5. Device management: An operator can download, configure, and update a client based (off line) operator menu structure over the air to a device in a seamless and non-intrusive way for the customer (i.e. no repeated questions if the customer want to accept the updates etc.). The menu structure can call operator defined applications that also can be managed over the air in the same way as the off-line operator menu

6. Contact data transfer: A customer can easily transfer contact data across multiple terminals (e.g., from old to new terminals)

Some identified key Use Cases:


July 2005

WS 1: Common requirementsUse Case Example - CustomisationAdd Basic Branding Elements

• Brand basic elements of a terminal UI in a consistent manner across all terminals, OTA updates possible

• E.g., background, menu items, wallpapers, colour scheme, start-up/shutdown sequences, ringtones, logo, screensaver, etc.

Simple Look and Feel Customisation

• Customise simple look and feel aspects of a terminal UI in a consistent manner across all terminals, OTA updates possible

• E.g., splash screens, sounds, status indicators, animations, softkey area, etc. plus level 4A elements

Deep Look and Feel Customisation

• Define the look and feel of all UI components and their layout in a consistent manner across all terminals and all applications, OTA updates possible

• E.g., scroll bar, text entry boxes, buttons, list boxes, notifications, etc. plus level 4B

cust

om

isa

tion

Le

vel

Application Interworking Customisation

• Customise the structure of Application Interworking Workflows across all terminals to define a seamless integration. OTA possible

• E.g. define application interworking workflows (AIW), plus 4E

Basic Menu Customisation

• Customise the ordering and labelling of the device menu structure and define device shortcuts and soft-keys, OTA updates possible

• E.g., emphasise and prioritise terminal features, lock specific menu items, define idle screen shortcuts, etc

Simple Application Integration

• Define the structure of the menu of a terminal UI across all terminals, including the addition of links to operator applications and services. OTA possible

• E.g., add an offline operator menu structure, access operator application from idle screen, plus 4D

4A

4B

4C

4D

4E

4F

R1

R2+

Provides Operator control of User Interface, across all terminal platforms


July 2005

Hardware & Defragmentation Approach

• Goal Reduce the number of variants, drive consistency and take unnecessary costs out of the industry

• Challenge Without stifling innovation

• Areas in focus:- Display- Camera- Codecs- Powering- Communication- Application


July 2005

Hardware Example - Displays

X-pixels

with

Y- colours

Resolution Physical Resolution of the display: 'A' x 'B' pixels

It represents the physical resolution of the display. The display SHALL be able to be configured to support this resolution

Pixel Aspect Ratio

Ratio of the pixel.

The display SHALL have this pixel aspect ratio

Colour Depth Number of colours. The display subsystem SHALL be able to be configured to support this number of colours

Frame Rate fps (frames per second)

Display hardware SHALL be able to support a minimum fps bandwidth available for sending data to display. i.e. content of that frame rate should be able to be processed by the hardware.


July 2005

Defragmentation Example - Codecs

• Audio classes• Video classes• Imaging class• Summer 05 release

• Codec profile definition

• Next release• Codecs performances and use cases scenario


July 2005

A generic format (XML) for customisation requirements

...

OPERATORS MANUFACTURERS

Handset 1

L&F Config(xHTML, DB, Plain text...)

OperatorA

OperatorB

OperatorX

...

Op A Reqs OMTP Format

OPERATORS MANUFACTURERS

Handset 1

L&F Config(xHTML, DB, Plain text...)

OperatorA

OperatorB

OperatorX

Op X Reqs OMTP Format

Op B Reqs OMTP Format

Manual Processing

Op B ReqsOp B Format

Op X ReqsOp X Format

Op A ReqsOp A Format

Manual Processing

Manual Processing

CURRENT SITUATION OMTP VISION

SemiAutomaticprocessing

PlatformAdaptation 1


July 2005

WS 1: Common requirementsApplication Platform Reqt. ExampleCustomisation of Simple Branding Elements

Add Simple Branding Elements

Define consistent specification

Define standard file structure Manage OTA

•Operators MUST be able to customize the following UI elements:-Wallpaper / Background graphics and Set of icons & Animations-Wake up/start up/shut down graphics and Operator Logo network identifier

• Visual attributes that can apply to each UI element might include:-Size, orientation, position, colour, graphics, transparency

• It MUST be possible for the operator to enrich defined operational icons / indicators - e.g.

-Battery charging, network search, message sending, • It MUST be possible for the operator to customize sounds, e.g:

-User actions (e.g. take a photo)-Notification messages (e.g. Low battery)-Events (e.g. Incoming messages)


July 2005

WS 1: Common requirementsApplication Platform Reqt. ExampleCustomisation use case translated into a formal file specification.




• The handset MUST offer a service to configure the basic branding elements with an OMTP customisation file

• The file MUST be an XML file compliant with the DTD defined by OMTP

• The handset MUST support the use of the CHARACTERISTIC WALLPAPER,

• The handset MUST support the use of the PARM IMAGE that references to the source of an image.

• …

<!ELEMENT omtp-simplebrandingdoc (characteristic+)><!ATTLIST omtp-simplebrandingdoc version CDATA #IMPLIED>

<!ELEMENT characteristic (parm*, characteristic*)><!ATTLIST characteristic type CDATA #REQUIRED>

<!ELEMENT parm EMPTY><!ATTLIST parm name CDATA #REQUIRED value CDATA #IMPLIED>


July 2005

WS 1: Common requirementsApplication Platform Reqt. ExampleOTA management capability is added




• The handset MUST support the Customization object in the DM tree.

• The Customization object MUST support the Simple Branding object that contains basic UI settings.

• The Simple Branding object MUST include the following nodes:

•BackgroundImage: This node will store the image used as general background.•SearchingNetworkLogo: This node will store the icon used to indicate that the handset is searching the available networks.•SMSRingtone: This node will store the ring tone that will be reproduced upon receipt an SMS

<NodeName> Customization </NodeName><Path>.</Path><DFProperties><Access Type> <Get/> </Access Type><Description> Customization Settings </Description><DFFormat> <node/> </DFFormat><Ocurrence> <One/> </Ocurrence><Scope> <Permanent/> </Scope><DFTitle>Customization Node </DFTitle></DFProperties>

./Customization SimpleBranding BackgroundImage

SearchingNetworkLogo

SMSRingtone


July 2005

Application Security - Project Approach

• Produce a set of device abuse cases with risk analysis and impact on user and network

• Define terminal security policies• Recommend certification program requirements• Develop requirements for trusted environment

Based on work in GSMA on Mobile Application Security


July 2005

Application Security ConceptThe “Mobile Application Security Concept” is based on the terminal policy and underlying certification program

Application Developer

Certification Programme

Authentication Testing

TestCriteria Signing of

Application

1.Application developer designs mobile application

2.Developer submits application for certification

3.The Certification Programme will authenticate the developer, test the application and sign it upon successful pass

4. The certified application

can be offered on mobile portals

Cer

tifi

cati

on

Pro

cess

Cer

tifi

cati

on

Pro

cess

2. User downloads mobile application

3. Terminal platform security model validates existence and origin of application certificate

4. Pending on certificate and terminal security policy, user will receive platform originated promptings

Application X wants to send a message.ALLOW DENY

Ter

min

al S

ecu

rity

Po

licy

Ter

min

al S

ecu

rity

Po

licy

1.Mobile portals offering a variety of mobile applications

5. In case of a malicious application, it is possible to revoke it, disabling further execution.

X

Mobile Portals, e.g.


July 2005

Technology Assessment

ILLUSTRATIVE

OMTP Process Flow and Timeline R1

Functional Requirements UE Reqts.

Look&Feel Custom.

Technical Requirements

Technical Implementation Options

Proprietary Platforms Standards based PF

P5 P4

HW Requirements

Security Requirements

Application Platform

P6

P3 P4 P6

SDO

06/2005

11/2005

02/2006Man.

Px

Template driving “Call for Proposal”

Iterative review process to get requirements aligned across operatorsProject x involved

Standards influence(JCP today,

possibly later: OMA, Linux, W3C,..)

P2

P3?

Can different Technology Platforms deliver against OMTP use case requirements

e.g. CDC Javae.g. CDC Java e.g. Linuxe.g. CDC Javae.g. Symbian e.g. Native

… .. . … .. .


July 2005

Technology Assessment - Example

Source: David Stephens, Vodafone

Specification of a Java Core Software Platform - Java Technology assessment vs. OMTP Use Case Requirements

• CDC Gap Analysis (JSRs existing vs. needed for CDC phone offering)

• Filing of needed JSR(s) where appropriate

• R1 input material – Java clarifications

• Java UI technology assessment - Swing vs. SWT

-Fact Gathering

-Criteria Definition


July 2005

2005 release plan• April:

– High level Objectives & Display requirements• June:

– UE Customization I (Approved as Pre-Release) – Camera, Codecs – Logical Application Framework Concept

• August/September:– CDC Java phone requirements– Trust Environment?

• November:– UE customization II– Logical Application framework - XML rep. of UI – Application Security– Performance benchmarks

Documents

0 © - Confidential, all rights reserved July 2005 OMTP Presentation OMTP LIMITED This document contains information confidential and proprietary to OMTP