Usage Scenarios for CSE Group Name: WG2(ARC-WG) Source: Shingo Meeting Date: 2013-09-19 Agenda Item: Message.

Slides:

Advertisements

Similar presentations

A global Service layer platform for M2M communications

Advertisements

Access Control Mechanism Discussion

CMDH Refinement Contribution: oneM2M-ARC-0397

Summary on the M2M CMDH Policies Management Object (MCMDHMO)

Is a Node or not Node? ARC Node_resolution Group Name: ARC Source: Barbara Pareglio, NEC, Meeting Date: ARC#9.1 Agenda.

Problem of Current Notification Group Name: ARC WG Source: Heedong Choi, LG Electronics, Meeting Date: ARC 9.0 Agenda Item: TBD.

Service Layer Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP16 Agenda Item:

Software Engineering CSE470: Requirements Analysis 1 Requirements Analysis Defining the WHAT.

3 rd SG13 Regional Workshop for Africa on “ITU-T Standardization Challenges for Developing Countries Working for a Connected Africa” (Livingstone, Zambia,

Device Management using mgmtCmd resource

Device Management using mgmtCmd resource Group Name: WG2/WG5 Source: InterDigital Communications Meeting Date: Agenda Item: TBD.

OneM2M-ARC Service_examples_and_evolution Service examples and evolution Group Name: WG2 Source: Philip Jacobs, Cisco Systems,

Project Analysis Course ( ) Week 2 Activities.

OneM2M-ARC BRequest_Resource Architecture Proposal to address Broadcasting/Multicasting Requirements Group Name: WG2 Source: Takanori Iwai, NEC,

Multi-Link Devices Group Name: WG1 Source: Kaonmedia, KETI Contact: Hwang Kwang Tae Yong-Suk Park

RoA and SoA Integration for Message Brokers Group Name: WG2-ARC Source: ALU Meeting Date: Agenda Item:

Mechanism to support establishment of charging policies Group Name: WG2-ARC Source: InterDigital Meeting Date: TP8 Agenda Item:

CMDH Policies Contribution: ARC R03-CMDH_Policies.ppt Source: Josef Blanz, Qualcomm UK, Hongbeom Ahn, LG Electronics,

Common Service Entities

SOFTWARE DESIGN AND ARCHITECTURE LECTURE 09. Review Introduction to architectural styles Distributed architectures – Client Server Architecture – Multi-tier.

In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:

Announcement Resources ARC Announcement_Issues Group Name: WG2 Source: Barbara Pareglio, NEC Meeting Date: Agenda Item: Input Contribution.

3GPP Rel-13 Interworking discussions

In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:

Management of CMDH Policies Group Name: WG5-MAS Source: Wolfgang Granzow, Qualcomm, Meeting Date: Agenda Item: Management.

Discussion on the problem of non- Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.2.

User Management. Basics SDMS shall maintain a database of all users. SDMS shall maintain a database of all users. SDMS shall not limit the number of registered.

Work Group / Work Item Proposal Slide 1 © 2012 oneM2M Partners oneM2M-TP oneM2M_Work_Group_Work_Item_Proposal Group name: Technical Plenary Source:

Proposal for WG3 & WG5 work area split

Architectural Principles for Services Group Name: WG2- ARC Source: Tim Carey, ALU, Meeting Date: Agenda Item:

Discussion on the problem of non- Blocking Synchronous mode Group Name: ARC WG Source: Yuan Tao, Mitch Tseng, Huawei Technologies Meeting Date: ARC 15.2.

Step by step approach Group Name: WG2 Source: Michael hs. Yang, LG uplus, Jaeseung Song, NEC Europe, Meeting.

Node-Specific Resource Group Name: ARC&MAS Source: LGE, Meeting Date: Agenda Item: Contribution.

Primitive End-to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm, Meeting.

Matching Resources with CSFs Group Name: WG2 (ARC) Source: Hongbeom Ahn, LG Electronics, Meeting Date:

Interworking with an External Dynamic Authorization System Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.2,

Device Management using mgmtCmd resource Group Name: WG2/WG5 Source: InterDigital Communications Meeting Date: Agenda Item: TBD.

Process for Documenting Resources related services and Alignment with Service Components Group Name: WG2-ARC-( ) Source: Ericsson Meeting Date:

M2M Service Session Management (SSM) CSF

E2EKey Resource Group Name: SEC WG Source: Qualcomm Inc., Wolfgang Granzow & Phil Hawkes Meeting Date: SEC#20.3, Agenda Item: End-to-End Security.

Routing Problem of the Current Architecture Group Name: ARC Source: Hongbeom Ahn, LG Electronics, Meeting Date: Agenda.

Different planes for the resource structure Group Name: WG5 – MAS and WG2 – ARC Source: Nicolas Damour, Sierra Wireless

App and Management End- to-End Security Requirements Group Name: SEC WG4 Source: Phil Hawkes, Qualcomm,

Discussion about RESTful Admin API Group Name: SEC & ARC Source: FUJITSU Meeting Date: Agenda Item: Device Configuration.

Security API discussion Group Name: SEC Source: Shingo Fujimoto, FUJITSU Meeting Date: Agenda Item: Security API.

M2M Service Layer – DM Server Security Group Name: OMA-BBF-oneM2M Adhoc Source: Timothy Carey, Meeting Date:

Potential use case for discussion – Street Light Automation Group Name: WG1/2 Source: Cisco Meeting Date: Joint-REQ-ARC-WGs-call Agenda Item: Use cases.

3GPP SCEF Interworking Discussions

M2M Service Session Management (SSM) CSF Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:

and LMAP liaison Document Number: IEEE R0 Date Submitted: Source: Antonio BovoVoice:

Adding Non-blocking Requests Contribution: oneM2M-ARC-0441R01R01 Source: Josef Blanz, Qualcomm UK, Meeting Date: ARC 7.0,

CMDH and Policies Contribution: oneM2M-ARC-0603

Subscription and Notification Issue Group Name: WG2 Source: Qi Yu, Mitch Tseng- Huawei Technologies, Co. LTD. Meeting Date: ~23 Agenda Item:

Consideration Security Issues on Registration Group Name: WG4 (SEC) Source: Shingo Fujimoto, FUJITSU, Meeting Date:

Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.

Reasons for CSF Clean-up (Issues & Next Steps) Group Name: WG2 Source: Syed Husain – NTT DOCOMO Meeting Date: (ARC_9.3) Agenda Item: 6 DOC#:

DM Collaboration – OMA & BBF: Deployment Scenarios Group Name: WG5 - MAS Source: Tim Carey, ALU, Meeting Date:

DECADE Requirements draft-gu-decade-reqs-05 Yingjie Gu, David A. Bryan, Y. Richard Yang, Richard Alimi IETF-78 Maastricht, DECADE Session.

Introduction to Service Session Management Group Name: WG2-ARC Source: IDCC, LGE, ZTE Meeting Date: TP8 Agenda Item:

Possible options of using DDS in oneM2M Group Name: ARC Source: KETI, Huawei, Hitachi, China Unicom Meeting Date: Agenda Item: DDS binding.

Resource subscription using DDS in oneM2M

Service Framework Proposal

Possible options of using DDS in oneM2M

Discussion to clarify online/offline behavior

3GPP Interworking Abstraction

Considering issues regarding handling token

Overview of E2E Security CRs

CMDH Refinement Contribution: oneM2M-ARC-0397R01

CMDH Policies Contribution: ARC-2014-xxxx

Unified Modeling Language

Presentation transcript:

Usage Scenarios for CSE Group Name: WG2(ARC-WG) Source: Shingo Meeting Date: Agenda Item: Message Flow

Introduction We are going to start describing ‘Message Flows’ following proposed template But describing each resource behavior seems difficult to understand how multiple CSFs are working behind scenes

Potential Issue WG2 members identifies potential overwraps and dependencies among CSFs But, Message Flows for each CSF does not covers interaction between CSFs

Example of CSF dependencies (from Detail Description for DMR CSF) The DMR CSF shall support transfer of data to/from the AEs, other CSFs and remote CSEs. The DMR CSF shall support transfer of data regardless of the peer entity being on-line or not. The DMR CSF shall support operations such as Create, Read, Update and Delete. The DMR CSF may associate event categorization (e.g., normal, urgent) with the data for supporting differentiated services. External entities such as AFs, other CSFs or remote CSEs shall be able to be granted access to the data in the DMR CSF based on defined policies. (from Detail Description for CMDH CSF) The services that other CSFs, AFs or NSFs can request from the CMDH CSF is to transport some given data to a specific target (CSE, AF or NSF), according to specific delivery instructions while staying within the constraints of provisioned communication management and delivery handling Policies. (from Detail Description for NSE CSF) The NSE CSF shall provide to the CMDH CSF information related to the Underlying Network so the CMDH CSF can include them to determine proper communication handling.

Proposal Assign volunteers to work on particular usage scenario (ex. Data Storing, Getting Data, Change Device Setting, Deploy New Device, …) Define set of typical usage scenarios which are derived from most simplest one Build ‘Message Flows’ which is involved related CSFs based on usage scenarios (optional)

Example of usage scenarios 1.Storing data from remote Device 1.Remote Device is online (Basic) 1.CMDH CSF on remote device (sender CSE) triggers scheduled data upload to store data (described as policy) 2.CMDH CSF(sender) gets information about Underlying Network from NSE CSF to reach the receiver CSE 3.CMDH CSF(sender) connects to the receiver CSE 4.Security CSF(receiver) authenticates the sender CSE to allow uploading data 5.CMDH CSF(sender) transfers data to DMR CSF(receiver) 2.Remote Device is offline (Alternate-1) 3.…

What we can get ? We can identify overwrap and dependency with functionality of other CSFs We can also determine which functionality should be exposed to other CSEs