报告人简历

1. 报告人简历 • 报告人：Mark Cataldo ，OMA技术全会 主席，1994年起从事无线通信标准工作。曾在几家主要的欧洲和美国电信、IT公司工作。目前在Openwave工作，并于2002年被选为第一届OMA技术全会主 席。

2. Technical Work Within OMA OMA Experts Technology Seminar organized by China Communication Standard Association CCSA November 20, Beijing, China Mark Cataldo Chairman of the Technical Plenary Open Mobile Alliance

3. Various candidate technologies to consider Need to harmonize disparate requirements GSMA Others OMA Application Level (Services, Enablers) W3C CDG Desire common boundaries and clarity of roles IETF 3GPP 3GPP2 Others Transport Level (Core, Radio, Term) Standardization Requirements Wireline Domain Mobile Domain Positioning OMA in the industry

4. Positioning of the Service Enablers Examples of OMA Service Enabler technologies XHTML Browsing DRM & Download … MMS IMPS < CONTENT DEVICES Open Mobile Alliance SERVICES NETWORKS Phase 2 of OMA Release Program: End-to-end single Enabler interoperability. Phase 3 of OMA Release Program: Multi Service Enabler interoperability.

5. Open Specifications & Common Architecture • OMA generates specifications allowing others to develop differentiating services • OMA generates specifications, not services • Agnostic of the underlying bearers, operating system and device • OMA specifications enable interoperability whilst permitting development of differentiating services • OMA creates and promotes common industry view on an architectural framework

6. Technical Plenary Groups • Technical Plenary consists of the following types of groups: • Working Groups • defining and performing technical work of OMA under auspices of Technical Plenary (e.g. creating specifications). • Committees • aid and support smooth running of Technical Plenary to deliver technical work (e.g. processes, planning/management) • Birds of a Feather (BoFs) • temporary groups making recommendations to Technical Plenary on a specific activity • Technical Plenary and each group has its own web pages • listing its officers, meeting plans, documents etc. • Organisational structure • http://www.openmobilealliance.org/organization.html

7. Technical Plenary Structure Board Technical Plenary Mark Cataldo, Openwave Operations & Processes Dwight Smith, Motorola Release Planning & Management Jari Alvinen, Nokia Requirements Kevin Holley, mmo2 Browser & Content Alastair Angwin, IBM Games Services Lars Brenk, TTPCom Mobile Protocols Rory McHale, Logica Architecture Christian Herzog Siemens Device Management James Jennings, IBM Location Hans Rohnert, Siemens Mobile Web Services Michael Luna, Openwave Security Michel Mouly, Vodafone/Orange Data Synchronisation Bartley Calder, Sun Messaging Mark Lipford, Sprint Presence & Availability Frank Dawson, Nokia Interoperability Sanjay Gupta, Motorola Developers Interests Alan Kaplan, Panasonic Mobile Commerce & Charging Jouni Käiväräinen, Telia Push to talk over cellular Dwight Smith, Motorola

8. Specify use-cases and interoperability and usability requirements • From use cases provide requirements to work groups • Coordinate requirements work in work groups • Verify consistency of requirements in work groups • Definition of overall OMA architecture • Enable specification work in work groups • Assure adherence of specification work to OMA architecture • Secure communication protocols between mobile clients and servers at transport and application layers • Security and trust services (e.g. authentication, confidentiality, integrity) provided by/to mobile clients and servers • Secure interactions with entities (e.g. with secure hardware tokens) • Identify, specify and maintain processes policies and test programs to ensure interoperability for OMA enablers and end-to-end services • Consolidate affiliate IOP groups into common understanding ofIOP • Study and understand best practices Interoperability Requirements Architecture Security OMA Work Groups

9. Defining a service enabling two-way form communications allowing users to engage in immediate communication with one or more users, similar to a “walkie-talkie”. • Focussing on providing service layer support • Use technology and identify mechanisms of other fora to enable service • Responsible for messaging technologies, leveraging architecture and appropriate base technologies of OMA and other fora • Specifies basic messaging and content handling to enable specific messaging paradigms • Support themeans to activate other mobile applications on the device • Address presence and availability requirements from all technologies • Develop shared presence and availability specificationsto avoid duplication and/or overlap in for presence and availability as used by different technologies • Make the presence and availability technology protocol-neutral to encouragee re-use of the technology by multiple services regardless of protocol used within them Push to Talk Over Cellular Presence & Availability Messaging OMA Work Groups

10. Protocols and mechanisms for management of devices • Setting of initial configuration data in devices • Updates of persistent data in devices • Retrieval of management data from devices • Processing events and alarms generated by devices • Specifications for data synchronization • Develop similar specifications, including but not limited to SyncML technology • Conformance specifications and a set of best practices • Specifications to ensure interoperability of Mobile Location Services on an end-to-end basis • Enable Mobile Location Services • End-to-end Architectural Framework with application and contents interfaces, privacy, security, charging and billing, and roaming Data Synchronisation Device Management Location OMA Work Groups

11. Collect and publish data relevant to developers • Provide means for software developers to articulate needs to OMA • Identify missing or inconsistent developer interfaces, make recommendations for additional / enhanced developer interfaces • Consolidated and consistent approach to generic (horizontal) bearers and protocols • Ensure consistent repeatable approach for leverage and usage across applications • Identify and recommend bearers and Internet protocols, specify profiles of external specifications and define bearer/protocol adaptations or extensions • Interoperability specifications, APIs and protocols for network enabled gaming • Enable game developers to develop / deploy mobile games to efficiently interoperate with OMA platforms • Enable cost reduction for game developers, game platform owners and service providers Mobile Protocols Games Services Developers Interests OMA Work Groups

12. Specify features (e.g. "user agents", content formats, programming interfaces etc.) enabling creation of data services • Create network-centric application models exploiting and leveraging web technology and architecture • Develop content formats, browser user agent semantics, interfaces to other applications, application-level services, execution environments and application-level programming interfaces • Bring industry players (companies, forums, etc.) closer together to get a more coordinated effort on m-commerce • Provide an overall m-commerce view • Provide secure transactions, engage wireless network operators, meet financial industry requirements • Define application of web services within OMA architecture • Provide application of web services converged with work of external activities • Generate recommendations, specifications and best practices to apply web services • Leverage existing standards where applicable Mobile Web Services Mobile Commerce & Charging Browser & Content OMA Work Groups

13. Defines operational processes for Technical Plenary • Provides support on operational and process activities • makes operations/process recommendations to Technical Plenary • Other support activities as Directed by the Technical Plenary • Responsible for planning and managing OMA Releases • Defines (and proposes to Technical Plenary) the OMA Releases based on OMA specifications • Co-operates with working groups and IOP group • Supports Technical Plenary with OMA external communications • Manage legacy specification approval process for affiliates Release Planning & Management Operations & Processes OMA Committees

14. Role of the Technical Plenary • Reports to the Board of Directors • Delegated by Board of Directors with responsibility for • technical specification drafting and planning activities • approval and maintenance of technical specifications and reports • resolution of technical issues • Produces technical specifications for application and service frameworks, with certifiable interoperability, in a timely manner enabling deployment of rich mobile applications and services • Charters a number of Working Groups and committees • Organises Plenary meetings, workshops and adhoc meetings • Uses the OMA Process to perform its duties

15. Market-Driven Activities • Work items proposed by members to define a specification activity • Work items checked against high level market-driven use cases and requirements to generate a Requirements Document • Requirements drive the definition of an Architecture Document to support the Requirements Document • Set of functional specifications produced based on Requirements Document • Multiple cross reviews to ensure consistency with market-driven requirements

16. Interaction with other fora WORK ITEM CREATION Step1 DETAILED TECHNICAL WORK Step4 ASSIGNMENT BY TP TO WG Step2 VALIDATION & IOP Step5 REQUIREMENTS Step3 Approved Specs Work Flow Process

17. What Are the OMA Deliverables? • OMA generates specifications based on market-driven requirements and use cases • OMA Release Programme delivers complete open specifications packaged into “Enabler Releases” • Enabler Releases may consist of one or more specifications • OMA testing verifies Enabler Releases in interoperability test events for products built using OMA technical specifications • Enabler Releases used by different organisations to develop differentiating interoperable products and services • OMA deliverables are based on market requirements

18. OMA Release Program • OMA working process is a market driven, continuous program designed to deliver three key milestones • Phase 1: Candidate Enabler Release • Approved specification for a single OMA Service Enabler • Phase 2: Approved Enabler Release • To ensure products and services supporting a single OMA Service Enabler work together seamlessly “end to end” across different devices and networks • Phase 3: OMA Interoperability Release • To ensure thorough device and network interoperability testing is completed across multiple OMA Service Enablers

19. Candidate Enabler Releases (Phase 1) • OMA Billing Framework 1.1 • OMA Browsing version 2.1 • OMA Client Provisioning version 1.1 • OMA Device Management Version 1.1.2 • OMA DNS version 1.0 • OMA Digital Rights Management version 1.0 • OMA Download version 1.0 • OMA Email Notification version 1.0 • OMA Games Services version 1.0 • OMA IMPS version 1.2 • OMA Multimedia Messaging Service version 1.1 • OMA Multimedia Messaging Service version 1.2 • OMA User Agent Profile version 1.1 • OMA User Agent Profile Version 2.0

20. Approved and IOP Enabler Releases (Phases 2 & 3) • OMA Phase 2: Approved Enabler Releases • OMA IMPS version 1.1 • OMA SyncML Common Specification  version 1.1.2 • OMA Data Synchronisation Version 1.1.2 • OMA Phase 3: Interoperability Enabler Releases • Interoperability Releasespackage together multiple Approved Enabler Releases • OMA will publish its Interoperability Enabler Releases upon approval

21. Focus on Interoperability • The following OMA enablers are currently undergoing interoperability testing • Device Management/Data Synchronization • Instant Messaging and Presence Service • Multimedia Messaging • Test specifications in development for other enablers

22. Upcoming Specifications • New Enablers • Mobile web services • Push to talk over cellular • Enabler Evolution • Gaming • Location • Download and Digital Rights Management • Browser Evolution (WCSS) • MMS • Instant Messaging • Device Management and Data Synchronization

23. Access to OMA Documents • Enabler Releases and open documents can be downloaded from the public web site • www.openmobilealliance.org • E-mail address for comments from anyone outside OMA • technical-comments@mail.openmobilealliance.org

24. Summary • OMA specifically supports the application and services layer • OMA generates specifications allowing others to develop differentiating services • Agnostic of the underlying bearers, operating system and device • All technical work done in Technical Plenary and its working groups • Well defined processes and procedures to administer its work • Technical activities initiated with Work Items, driven by market-driven requirements • 3-Phase OMA Work Programme to deliver Candidate, Approved and Interoperability Enabler Releases • Enabler Releases and other documents openly available on website