Proposed Co-convened WG1/2 Objectives, Schedule, and Activities

Group Name: TP#1Source: Omar Elloumi (Alcatel-Lucent), Laurent Laporte (Sprint)Meeting Date: 2012-09-27Agenda Item: n.a.

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

Proposed Meeting Rotation

US Pacific US Eastern Europe CET China Australia

14:00 GMT 06:00 09:00 15:00 22:00 01:00

05:00 GMT 21:00 00:00 06:00 13:00 16:00

23:00 GMT 15:00 18:00 00:00 06:00 09:00

Meeting Schedule

Dates US Pacific US East CET Beijing Seoul Sydney

9 & 11 Oct 21:00 00:00 06:00 12:00 13:00 15:00

16 & 18 Oct 06:00 09:00 15:00 21:00 22:00 00:00

23 & 25 oct 15:00 18:00 00:00 06:00 07:00 09:00

30-Oct 06:00 09:00 14:00 21:00 22:00 00:00

06-Nov 21:00 00:00 06:00 13:00 14:00 16:00

08-Nov 06:00 09:00 15:00 22:00 23:00 01:00

13 & 15 Nov 21:00 00:00 06:00 13:00 14:00 16:00

20-Nov 06:00 09:00 15:00 22:00 23:00 01:00

27 & 29 Nov 14:00 17:00 23:00 06:00 07:00 09:00

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

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 ToRWG1

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 ToRWG2

Proposal for the co-convener activities between TP1 and TP2

Group Name: TP#1Source: Omar Elloumi (Alcatel-Lucent), Laurent Laporte (Sprint)Meeting Date: 2012-10-09Agenda Item: n.a.

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

8 -> 15-> 22-> 29-> 5-> 12-> 19-> 26->

-Use case template

-Requirements methodology

-Benefits doc.

calls

calls

week

week

task

sta

sks

October November

Kick-off Call Use case/Req.

9 11 16 18 292720151363023 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

Com

ment

Com

ment

Ad hocmeetings

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).

• 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

• 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

• 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

• 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

8 -> 15-> 22-> 29-> 5-> 12-> 19-> 26->

calls

calls

week

week October November

9 11 16 18 292720151363023 25 8

Use

Case

Use

Case

Proposed schedule for WG1/2 between TP#1 and TP#2

Reqm

nt

Reqm

nt

Draft TR for TP#2

consideration

Arc

hA

rch

Benefits

D

oc

Benefits

D

oc

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