4 7a Structure of M 2 M Consolidation

[4. 7]a Structure of M 2 M Consolidation SDO Structure Goals of Structure: • Be responsive to the needs of the vertical market stakeholders (individual and organizational), SDOs, and service providers • Balance regional requirements and differences; • Address timeframe objectives across the regions; • Support global harmonization; • Afford a level playing field for all stakeholders; and • Be practical (less global travel; resource commitment) • Common rules, including IPR policy Overall Common high level structure: • Overall body (e. g. , PCG , Steering Committee, Oversight Board) • Technical Plenary/TSG Proposed WGs in common (not taking SWGs into account): • Requirements & Use Case Harmonization (to be created first? ) • Common Service Architecture & Protocol/API • Testing and Interoperability • Security High level structure should be created first; Working Groups should be created second. Comment Other commonly proposed WGs (ETSI/CCSA): • Management • M 2 M Terminals/Module • Service/Technology Adaptation Other proposed WG (TIA): • Interworking & Application Toolbox This document was not discussed during the meeting, but was drafted by the leadership for discussion. This document was subsequently agreed to be used as the baseline for the 24 August teleconference on Structure. Responsibilities of the various levels will need to be agreed. M 2 MCons 02_30 1

[4. 7]b Structure of M 2 M Consolidation SDO Structure ARIB/ TTC • Need to be able to address agreed upon technical scope that effectively facilitates the issues between working groups. • Should focus now on the high level structure, such as OPs and steering group, and the remaining detail (working group and sub-working group level) can be decided after forming a consolidation activity. • No specific structure proposed • See attached diagram ATIS • Goals of Structure: • Be responsive to the needs of the vertical market stakeholders, SDOs, and service providers • Balance regional requirements and differences; • Address timeframe objectives across the regions; • Support global harmonization; • Afford a level playing field for all stakeholders; and • Be practical (less global travel; resource commitment) • Develop common service layer use cases and requirements first, and create the relevant WG first; this work should take place now during creation of consolidated activity • Creation of regional outreach to allow for increased regional participation given the likely global travel required for the consolidation effort • Additional WGs created later – in a logical order based upon use cases and requirement, keeping the number to a minimum to minimize resource requirements • Regional outreach first • Diagram provided on potential structure. • See attached diagram CCSA Comment 2

[4. 7]b Structure of M 2 M Consolidation SDO ETSI TIA Structure Comment • Minimize resources • See attached diagram • Top tier must be formed first; WGs later • Detailed functions and rules also proposed • Participation by the members of the other organizations (e. g. , verticals) in the M 2 M Initiative may be as important as the engagement of the organization. • Provided definition of participation and members, and provided five options for defining rights • Provided key functions of proposed Oversight Board and TSGs • See attached diagram TTA 3

[4. 7]c Structure of M 2 M Consolidation ATIS Steering Committee Plenary Requirements & Use Case Harmonization Working Group Common Service Architecture & Protocol Working Group Security Aspects Working Group Test & Conformance Working Group 4

Technology IW 1 Technology IW 2 Testing & interopera bility Application 1 Application 2 Security Managem ent i. Nteroperability events Terminal /Module Test definition WG APIimpacts OMA DM TR 069 Others CCSA Architecture Framework 2 Architect ure & API Requirements Capability Interface Requirement s & use cases Architecture Data models & API Reuse of CN Requirements Use case 1 Use case 2 Use case 3 [4. 7]d Structure of M 2 M Consolidation M 2 M PP PCG M 2 M Technical plenary Service/ Vertical technology sector 2 sector 3 Adaptation Example of activities in the WGs 5

WGs Example of activities in the M 2 M Terminals Interop events Test definition M 2 M Technical Plenary Technology IW 1 Technology IW 2 Management Application 1 Application 2 Security M 2 M module interfaces Requirements & use cases M 2 M Module API ETSI APIimpacts OMA DM TR 069 Others Architecture & API Architecture Framework 2 Architecture Data models & API Reuse of CN Requirements Use case 1 Use case 2 Use case 3 [4. 7]e Structure of M 2 M Consolidation M 2 M Coordination Testing & interoperability Service/ technology Adaptation

[4. 7]f Structure of M 2 M Consolidation TIA 7