1. Proposed Co-convened WG1/2 Objectives, Schedule, and Activities Group Name: TP#1 Source: Omar Elloumi (Alcatel-Lucent), Laurent Laporte (Sprint) Meeting Date: 2012-09-27 Agenda Item: n.a.

2. Proposed Objectives Requirements Analysis and comparison of existing requirements documents in the document pool as well as allowing for requirements derived from member contributions Tentative harmonization of requirements Architecture Familiarization of different architectures Because of translation issues, we propose that short presentations of the architectures are prepared Short report providing a summary of the different architecture frameworks

3. Proposed Meeting Rotation US PacificUS EasternEurope CETChinaAustralia 14:00 GMT06:0009:0015:0022:0001:00 05:00 GMT21:0000:0006:0013:0016:00 23:00 GMT15:0018:0000:0006:0009:00

4. Meeting Schedule DatesUS PacificUS EastCETBeijingSeoulSydney 9 & 11 Oct21:0000:0006:0012:0013:0015:00 16 & 18 Oct06:0009:0015:0021:0022:0000:00 23 & 25 oct15:0018:0000:0006:0007:0009:00 30-Oct06:0009:0014:0021:0022:0000:00 06-Nov21:0000:0006:0013:0014:0016:00 08-Nov06:0009:0015:0022:0023:0001:00 13 & 15 Nov21:0000:0006:0013:0014:0016:00 20-Nov06:0009:0015:0022:0023:0001:00 27 & 29 Nov14:0017:0023:0006:0007:0009:00

5. Proposed Activities Develop Requirements input template Develop initial set of requirements for TP#2 Approval can only take place at TP level Develop initial description/analysis of architecture framework Propose liaisons to industry segment SDO’s as needed To request feedback To inform of results

6. Responsibility Identify and document use cases that are relevant for oneM2M – Use cases describe the interactions between actors and the system/subsystem using a sequence of steps to achieve a goal. – Use cases shall be described in an architecture neutral manner. Identify and specify service and system requirements that are relevant for oneM2M scope, including interworking aspects to other systems Gather M2M service requirements specific to the vertical ecosystem contexts obtained from vertical industry groups and fora Conduct studies leading to deliverables pertaining the aggregation and analysis of requirements necessary for development of the M2M system according to the scope of oneM2M. Topics include (but are not limited to): Service and system Requirements – can belong to either service support or service deployment including aspects regarding deployments Ecosystem context –how the M2M system is expected to fit together with selected vertical eco-systems, including all non-M2M system components required to deploy a complete solution. Proposed ToR WG1

7. Responsibility Specify architecture for M2M system according to oneM2M scope Develop specifications that meet requirements and choose whether to reuse/reference existing standards and specifications or parts thereof. Coordinate M2M architecture activity with that of other oneM2M WGs as well as other specification groups and fora. Conduct studies leading to deliverables pertaining to the evolution of the M2M system. Topics include (but not limited to): Architecture – functional entities, reference points, and related message flows Interworking aspects (e.g. leveraging network capabilities as and when applicable) Evolution guidelines – to describe architectural steps that M2M systems follow in order to migrate towards using oneM2M components. Guidelines pertaining to the application of oneM2M standards in specific verticals Proposed ToR WG2

8. Proposal for the co-convener activities between TP1 and TP2 Group Name: TP#1 Source: Omar Elloumi (Alcatel-Lucent), Laurent Laporte (Sprint) Meeting Date: 2012-10-09 Agenda Item: n.a.

9. Introduction This section is prepared by the WG1/WG2 co- convener to initiate the discussion on how to structure the work between TP1 and TP2 It is only an initial proposal that will be adjusted based on member feedback during the calls or by email to the co-conveners and the rapporteurs Slide 1 to 7 are the same slides as contribution 48 presented during TP1

10. 8 ->15->22->29->5->12->19->26-> -Use case template -Requirements methodology -Benefits doc. calls week tasks OctoberNovember Kick-off Call Use case/ Req. 9 11 16 18 29 27 201513 6 30 23 25 8 Tentative kick-off call arch review Use case collection/consolidation/distilling Requirements consolidation Benefits doc development Use case collection/consolidation/distilling Requirements Consolidation Architecture review Benefits doc development Comment Ad hoc meetings Technical input is to be contributed to TP2 for consideration and approval WG1/WG2 co-convened conference call structure NOTE: Use case, benefits and requirements is an ongoing TP process Tentative allocation of meeting time (will be adjusted based on feedback, contributions, and progress made).

11. Use case template – Rationale: Use cases are better documented using a single use case template to ensure common understanding and a single practice across oneM2M; – Description: Agree on a single initial use case template for subsequent oneM2M use case development Requirement methodology – Agree on a methodology to harmonize requirements; Use case consolidation – Document an initial set of use cases according to the template. Requirement consolidation – Use the methodology to harmonize the requirements (initial set). WG1 Task Descriptions

12. Architecture review – Initial review of the #architecture proposals; – High level comparison/contrast; – Document at a high level the different architecture proposals, with: scope, high level framework, etc. WG2 Task Descriptions

13. Proposed template should include (only initial ideas for discussion): – Name: a meaningful name of the use case (short) – Summary: brief description – Actors – entities involved in the process; definitions must be included to describe each actor in terms of their role and how they behave; – System under study – treated as a “black box” so as not to impose any architectural bias; may include certain important elements/actors involved in the interaction that are external to the system that is to be defined; – Basic/main Interactions – high-level information flow between actor and system; – Potential requirements – requirements derived from the use case; – Other aspects of a use case that may need to be considered: Viewpoint: from which stakeholder side is the use case being described Preconditions: conditions for the use case to take place Alternative interaction: other variants for interaction Exceptions/Errors Post conditions: Priority: priority of the use case (e.g. for the purpose of a certain release) Per agreement in the Technical Plenary, use cases may come from: – Contributions from oneM2M members; – Documents submitted to the document pool. Initial Proposal for Use Case Template

14. Each requirement should consist of: – Description of the requirement; – Source (i.e. SDO doc xyz, contribution abc); – Categories (examples – not an exhaustive list): Data collection/exchange; Location; Device management; Interworking with access networks; Interworking with area networks; Group; Data security; Others; – Service or system requirement; Per agreement in the Technical Plenary, requirements may come from: – Contributions from oneM2M members; – Documents submitted to the document pool. Initial Proposal for Requirements Template

15. 8 ->15->22->29->5->12->19->26-> calls week OctoberNovember 9 11 16 18 29 27 201513 6 30 23 25 8 Use Case Proposed schedule for WG1/2 between TP#1 and TP#2 Reqmnt Draft TR for TP#2 consideration Arch Benefits Doc Draft TR for TP#2 consideration Draft for TP#2 consideration These items are required outputs per oneM2M-TP-2012-0049R01 and -0050R01 Review for submittal to Requirements WI stream Use case and requirements contributions may occur throughout the period prior to Final Draft ready for review