1 [4.7]a Structure of M2M Consolidation SDOStructureComment Overall 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 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. Responsibilities of the various levels will need to be agreed. Other commonly proposed WGs (ETSI/CCSA): Management M2M 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. M2MCons02_30

2 [4.7]b Structure of M2M Consolidation SDOStructureComment 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 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 See attached diagram CCSA Diagram provided on potential structure. See attached diagram

3 [4.7]b Structure of M2M Consolidation SDOStructureComment ETSI Minimize resources See attached diagram TIA 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 M2M 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

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

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

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

7 TIA [4.7]f Structure of M2M Consolidation