1. Proposal for WG3 & WG5 work area split
Group Name: WG3(PRO) & WG5(MAS)
Source: Shingo Fujimoto, Fujitsu,
Meeting Date:
Agenda Item: WG3/WG5 work split

2. Introduction oneM2M architecture become more stable
It seems ready to go for Stage 3 (protocol dev.)
Issues
WG3(Protocol WG) and WG5(Management, Abstraction and Semantics WG) work may potentially overwrapped.
WG3 and WG5 should discuss to split work loads by its speciality.

3. Potential Issues What is the scope of “Device Management” ?
How we can use existing solutions ?
How WG3 and WG5 can deliver (integrated or series of) TS ?

4. Scope of “Device Management”
Device Management in M2M Platform is defined as “General Concept”:
Device Management (DMG) CSF enables the management of device capabilities including one or more of the following:
Application Software installation and settings;
Configuration settings and Provisioning;
Firmware Updates;
Logging, Monitoring, Diagnostics;
Topology Management of Area Networks;
Devices within an Area Network Management.
“Device Management” in M2M is purely administrative, but critical part of the M2M service

5. oneM2M Architecture Overview

6. Problem on current DM architecture
There are no standardized specifications to fit
(interoperability issue is exist)

7. Proposed DM architecture
Intermediate/End Node is controlled using management protocol

8. Deployment Scenario PAN comm. Proprietary interface API call
OMA-DM
Server
OMA-DM Client (Smartphone)
Weight Scale
Sending Measured
Data ?
API call
M2M Infrastructure Node
M2M Application
Server
Sending Measured
Data ?
Proprietary interface
LAN comm.
BBF TR-069
ACS
Air Conditioner
BBF TR-069
Compliant GW
WG5
[Issues regarding DM]
WG3
[Issues in General]

9. Proposal
Consider using management protocols (ex. OMA-DM, TR-069, …) for reference point Y
WG5 can focus on how implement CSE on M2M intermediate/end node for its work area.
(WG3 will work on generic issues regarding API for reference point X.)