Proposal for WG3 & WG5 work area split Group Name: WG3(PRO) & WG5(MAS) Source: Shingo Fujimoto, Fujitsu, shingo_fujimoto@jp.fujitsu.com Meeting Date: 2013-09-03 Agenda Item: WG3/WG5 work split
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.
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 ?
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
oneM2M Architecture Overview
Problem on current DM architecture There are no standardized specifications to fit (interoperability issue is exist)
Proposed DM architecture Intermediate/End Node is controlled using management protocol
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]
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.)