OMA-TP-2003-0408- OMA Work Plan & Dependencies OMA Work Plan & Dependencies

© 2003 Open Mobile Alliance Ltd. All Rights Reserved.Used with the permission of the Open Mobile Alliance Ltd. under the terms as stated in this document. OMA-TP-2003-0408 Slide #1

[OMA-Template-SlideDeck-20030826]

OMA-TP-2003-0408-OMA Work Plan & Dependencies

OMA Work Plan & Dependencies

USE OF THIS DOCUMENT BY NON-OMA MEMBERS IS SUBJECT TO ALL OF THE TERMS AND CONDITIONS OF THE USE AGREEMENT (located at http://www.openmobilealliance.org/UseAgreement.html) AND IF YOU HAVE NOT AGREED TO THE TERMS OF THE USE AGREEMENT, YOU DO NOT HAVE THE RIGHT TO USE, COPY OR DISTRIBUTE THIS DOCUMENT.

THIS DOCUMENT IS PROVIDED ON AN "AS IS" "AS AVAILABLE" AND "WITH ALL FAULTS" BASIS.

Submitted To: Technical Plenary

Date: 21st August 2003

Availability: Public OMA Confidential

Contact: Philippe Lucas

[email protected]

Source: Technical Plenary vice-chair

X



Contents of the presentation

Overview of process

Release & tracking process

Handling of work orginating from affilliate organisations

OMA Approved WIs and Work Programme



OMA has three processes

• The OMA organisation and process document • Deals with general procedural matters for the Technical Plenary and in particular handling of

Work Items and the subsequent specification/enabler development life cycle

• The OMA IOP process document• Deals with interoperability processes, policies and principles

• The OMA Work Programme and Release Handling process document• Deals with procedures for the OMA work programme and the release of enablers



OMA Work Programme and Release Handling process

• The process deals with the following topics:• What kind of information the WP tracks• When the information need to be made available to the WP• How the information needed as input to the WP is to be collected and distributed

• How the information collected as part of the WP is intended to be used• How OMA Releases are defined and named• How OMA Releases are planned and managed• How specifications and releases from incoming affiliates are handled



OMA Release Programme

• OMA working process is a market driven, continuous program designed to deliver three key milestones

• Ensures products and services work together seamlessly• Requires thorough interoperability testing

• 3 Phases• Phase 1: Candidate Enabler Release• Phase 2: Approved Enabler Release• Phase 3: Interoperability Release



OMA Release Programme

• OMA uses a Work Item List to scope an activity in OMA, including:• a list of deliverables,• a time schedule for the work to be undertaken• any dependencies that the WI may have towards other ongoing work within or outside

of OMA

• An Enabler Release is a collection of specifications that when combined form an enabler for a service area, e.g a download enabler, browsing enabler, etc.

• An Interoperability Release is a number of Enablers that have gone through the OMA Interoperability process and have proven interoperability



Tracking of work in progress

• All working groups that have ownership of Work Items are required to maintain time schedules for the work that is related to the Work Item

• Information of time schedules for the work is collected on a regular basis by the Release Planning and Management Committee

• The result is compiled and made available to the Technical Plenary and its working groups



Release process (1/4)

• The WG responsible for a WI identifies specifications to be included in an enabler and kicks off drafting the Enabler Release Definition (ERELD)

• When the specifications, ERELD and Enabler Test Requirements have been drafted and considered to be complete, they undergo a consistency review

• After the complete enabler package with the Requirements Document and Architecture Document, plus supporting information is submitted to the TP for review and approval

• The TP approval of the release results in a Candidate Enabler Release where all specifications belonging to it also get Candidate status

CandidateSpecificationCandidate

SpecificationDraftSpecification

EnablerRelease

Definition+ Candidate

EnablerRelease

Review andapproval by

the TPSupportingdocuments+

Phase1




• The Candidate Enabler Release plus the IOT enabler test cases and IUT (Implementations Under Test) are used as input to OMA Test Fests for interoperability testing

• The Test Fests are likely to result in a number of Problem Reports (PRs) and Change Requests (CRs) that lead to updates of the specifications and test cases

• A successful Test Fest proves interoperability on enabler level and is documented in a Enabler Test Report

CandidateEnablerRelease

+IOT

EnablerTest

cases

IOTTest Fest

IUTIUT

IUT+ Enabler

TestReport

Phase2(1/2)




ApprovedCRsApproved

CRsApprovedCRs based

on PRs

+Candidate

EnablerRelease

IncorporateCRs

UpdatedCandidate

EnablerRelease

EnablerTest

Report

UpdatedCandidate

EnablerRelease

+ ApprovedEnablerRelease

• The documents in the Candidate Enabler Release are updated with the approved CRs to get a clean release

• The updated Candidate Enabler Release plus the final Enabler Test Report are brought to the Technical Plenary for approval

• The Technical Plenary approves the release becoming an Approved Enabler Release where all specifications belonging to it

Phase2(2/2)

Review andapproval by

the TP




+ApprovedEnablerRelease

• Progress of the work items that are intended to be included in an Interoperability Release is tracked

• Based on this input, the TP combines Approved Enabler Releases with an Interoperability Release definition and this combined forms an Interoperability Release

• The Approved Interoperability Release is made publicly available by OMA after TP approval

ApprovedEnablerReleaseApprovedEnablerRelease

Interoprelease

definition

ApprovedInter-

operabilityRelease

Review andapproval bythe TP

Phase3



Work Item Approved

• OMA maintains a list of approved WIs

To be updated before the W

orkshop



Work programme summary (1)

Calendar viewKey: Requirements phase Updated: 20 Aug 03

Specification phase ( Phases serialised to simplify overall view) Now

IOP phase |2 0 0 3 2 0 0 4

Current state J F M A M J J A S O N D J F M A M J

Browsing 2.1 noneCandidate EnablerBrowsing Enhancement+WCSS 2.221,22Submitted to RPUser Agent Profile 1.1 noneCandidate EnablerUser Agent Profile 2.0 noneCandidate EnablerDefault stylesheet ? 53 (Browsing maintenance) 2.x 58 URI schemes ?

Download 1.0 noneCandidate EnablerDownload 2.0 44WI approvedDigital Rights Management 1.0 04Candidate EnablerDigital Rights Management 2.0 04Specs in Dev

Data Synchronization 1.1.2noneApproved EnablerData Synchronization 1.2 48Specs in devDevice Management 1.1.2noneCandidate EnablerDevice Management 1.21, 50,52Reqmts phaseDevice Management WS i/f TBD 13 DS Common 1.1.2noneApproved EnablerClient Provisioning 1.1 noneCandidate EnablerClient Provisioning 1.x 51 Identity management f/w TBD 49

MMS 1.1 noneCandidate EnablerMMS +Minimal Interoperability 1.2 10Candidate EnablerStandard Transcoding i/f TBD 23ReqmtsIMPS 1.1 noneApproved EnablerIMPS 1.2 26Candidate EnablerIMPS 1.3 26 SIP/SIMPLE TBD 28 WSI TBD 27Reqmts devPOC TBD 43Reqmts dev

Bro

wse

rD

ownl

oad

Man

agem

ent

Mes

sagi

ng



Work programme summary (2)

Key: Requirements phaseSpecification phaseIOP phase

2 0 0 3 2 0 0 4

Current state J F M A M J J A S O N D J F M A M J

Loca

tion

Location - MLP 3.1 (1.0)noneEnabler readyLocation WAP Enabler readyLocation (for 3GPP rel6) 2.039,40,42Reqmts(Location maintenance)

Games Services 1.0 noneCandidate EnablerGames Services 2.0 37Reqmts

Common service enablers

Mobile Web Services (1.0) 05Spec in dev

Onboard Key Generation + EnrollmentTBD 45Spec in devWireless Identity Module TBDOCSP-MP TBD 38Spec in devPush security

Proxy Based Redirect TBD07R1Req approvedDomain Name System 1.0 noneCandidate EnablerE-Mail Notification 1.0 noneCandidate Enabler(MPG maintenance)

Other Billing Framework 1.0 noneCandidate Enabler(Maintenance Billing F/w) OMA events calendar Technical PlenaryRequirements InterimArchitecture InterimIOP Interim

Loca

tion

Gam

esS

ecur

ityP

roto

cols

MW

S



Summary

• Release planning process is well defined

• OMA maintains a work programme in which WI and enabler specifications are well referenced and tracked

• OMA work can be shared with partner organisations, in particular 3GPP

Documents

OMA-TP-2003-0408- OMA Work Plan & Dependencies OMA Work Plan & Dependencies