1 / 30

Management Abstraction & Semantics in oneM2M: A Standard Research

Explore the concepts, architecture, and evolution roadmap of Management Abstraction and Semantics in oneM2M for IoT applications across different sectors such as home, transport, health, and energy. Learn about the importance of abstraction and semantics in managing diverse networks, devices, and interfaces for seamless interoperability.

rbono
Download Presentation

Management Abstraction & Semantics in oneM2M: A Standard Research

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. On Management, Abstraction & Semantics Yongjing Zhang Standard Research Lead, Carrier Software BU, Huawei Technologies Co., Ltd. zhangyongjing@huawei.com oneM2M www.onem2m.org

  2. Agenda • Concepts about M.A.S. • The Management Capabilities in oneM2M • Architecture • Resource modeling • Protocol mapping • The Generic Abstraction & Semantic Capabilities in oneM2M • Resource modeling • Interworking framework • Semantic enhancement • Evolution roadmap • Conclusion

  3. Why M.A.S. IoT Applications Home Transport Health Energy Retail … ABSTRACTed APIs • Common Information Model & SEMANTICS • Common Service Functions (e.g. MANAGEMENT) oneM2M Heterogeneous Networks, Devices, Interfaces ZigBee KNX BLE ZWave mBus 3GPP/2 OMA BBF …

  4. Concepts - Abstraction • Abstraction: generalizing the information model •  to hide the complexity of the specific technologies by providing a single format to represent devices and unified methods directly usable by the applications. • Interworking: mapping between two specific technologies •  to enable the information exchange between heterogeneous systems • Applications may still need to understand the native information model (e.g. Zigbee profile) • Interworking is the basis for Abstraction

  5. Concepts - Semantics • Semantics: adding the meaning and relationships between concepts (e.g. data, devices, things) and their instances •  to enable machine understandable interoperability without a-priori agreement or configuration between communication parties • the formal specification of a conceptualization is done by 'ontology', which provides unambiguous vocabulary and model about objects, measurands, their properties and relationships. Abstraction vs. Semantic Levels of meaningfullness • Semantics is the evolution of Abstraction

  6. Concepts - Management • Management: the management (configuration, monitoring, trouble shooting, upgrade, etc.) of devices (ADN/ASN/NoDN), applications (AEs) and common service entities (CSEs) • to provid 'Abstracted' unified & simplified management APIs for M2M applications. • Management is essentially a specific aspect of oneM2M Abstraction framework: • Data models: the resources describing the mgmt capabilities, properties and status • Operations: the actions performing mgmt tasks, e.g. download (firmware), get (status) or set (properties), execute (software installation) Mgmt Applications oneM2M Management Abstraction (data models & operations) OMA BBF … • Management is a specific aspect of Abstraction

  7. Management Capabilities • Application & Service Layer Management (ASM CSF) • Configuration (e.g. CMDH Policy configuration) • Software Management (e.g. download/ install/ activation): • Device Management (DMG CSF) • Device Configuration (e.g. enable/ disable capabilities, provisioning) • Device Diagnostics and Monitoring (e.g. memory, battery, event logs, reboot) • Device Firmware Management • Device Topology Management (e.g. Area Network topology & characteristics )

  8. Management Architecture • IN-DMG-MA • Protocol Translation • Interaction with the Mgmt Server • Mgmt Server selection • Discovery of external mgmt objects IN-AE • oneM2M abstracted mgmt APIs (HTTP/CoAP/MQTT) Mca • Invoking underlying mgmt server functions, • Receiving mgmt results • Managing Area Nwk & Devices(technology specific) • Performing actual mgmt tasks by reusing existing techs (e.g. OMA, BBF)

  9. Management Architecture • MN-DMG-MA or ASN-DMG-MA • Mapping between the DMG and Management Client • Interaction with the Mgmt Client IN-AE • oneM2M abstracted mgmt APIs (HTTP/CoAP/MQTT) Mca • Mgmt resource creation, • Service layer mgmt • Local mgmt objects discovery

  10. Management Abstraction oneM2M TS-0001 (ARC)/ TS-0004 (PRO) Application &Service Layer Mgmt Generic Mgmt Resource Model <mgmtObj> [software] [cmdhPolicy]  A specialized mgmt func. type (e.g. "software")  Tech-specific mapping info Device Mgmt Specialization  Link to sub-resources [firmware] [deviceInfo] [deviceCapability]  Attributes to be specialized for a specific mgmt func. [eventLog] [battery] [memory] [reboot] [areaNwkInfo] [areaNwkDeviceInfo]

  11. Management Abstraction oneM2M TS-0001 (ARC)/ TS-0004 (PRO) Application &Service Layer Mgmt Generic Mgmt Resource Model <mgmtObj> [software] [cmdhPolicy]  A specialized mgmt func. type (e.g. "software")  Tech-specific mapping info Device Mgmt Specialization  Link to sub-resources [firmware] [deviceInfo] [deviceCapability]  Attributes to be specialized for a specific mgmt func. [eventLog] [battery] [memory] [reboot] [areaNwkInfo] [areaNwkDeviceInfo] Mapping oneM2M TS-0005 (OMA) oneM2M TS-0006 (BBF) • FUMO • SCOMO • DevInfo • DiagMO • … • DeviceInfo • SoftwareModules • X_oneM2M_... • … • Device Object • Firmware Update Object • Software Mgmt Object • … OMA DM 1.X OMA DM 2.0 OMA LWM2M BBF TR069/TR181

  12. Management Abstraction oneM2M TS-0001 (ARC)/ TS-0004 (PRO) Generic Resource Model for RPC-like mgmt commands (BBF TR069) * Each execution creates a <execInstance> to maintain the execution status and result <mgmtCmd> <execInstance>  RPC cmd type (e.g. "download")  Cmd arguments (opaque)  Cancel a pending cmd  Trigger of execution (by 'UPDATE')  Target device(s) (<node> or <group> URI)  Execution mode(e.g. 'repeated')  Inherit from the parent <mgmtCmd>  In association with execution mode

  13. Management Abstraction oneM2M TS-0001 (ARC)/ TS-0004 (PRO) Generic Resource Model for RPC-like mgmt commands (BBF TR069) * Each execution creates a <execInstance> to maintain the execution status and result <mgmtCmd> <execInstance>  RPC cmd type (e.g. "download")  Cmd arguments (opaque)  Cancel a pending cmd  Trigger of execution (by 'UPDATE')  Target device(s) (<node> or <group> URI)  Execution mode(e.g. 'repeated')  Inherit from the parent <mgmtCmd>  In association with execution mode Mapping oneM2M TS-0006 (BBF) • RESET • REBOOT • UPLOAD • DOWNLOAD • SOFTWAREINSTALL • SOFTWAREUNINSTALL BBF TR069

  14. Management Example Flow IN-CSE MN/ASN-CSE IN-AE Mgmt Adaptor Mgmt Server Mgmt Client Mgmt Adaptor Registration, CREATE <ASN-node> <IN-CSEbase> <ASN-remoteCSE> Local mgt objects discovery Resource creation <ASN-node> [deviceInfo] CREATE <deviceInfo>, <battery>, <firmware>… [battery] [firmware] Resource creation Keep in sync by UPDATE […] RETRIEVE [battery] Invoke battery monitoring Mgmt Session (e.g. DM/TR069) Battery info [battery] update [battery] representation UPDATE [firmware] Invoke firmware update Mgmt Session (e.g. DM/TR069) OK [firmware] update OK

  15. Generic Abstraction/Semantics • Data collection • Application • Resource types <AE>, <container> & <contentInstance> are used for the abstraction of M2M applications, data collection and instances.. • Data instance • Hierarchical data collection

  16. Generic Abstraction/Semantics • Data collection • Application • Resource types <AE>, <container> & <contentInstance> are used for the abstraction of M2M applications, data collection and instances.. • Attribute 'ontologyRef' is to provide the semantic annotation (meaning) for application and data. It's the rudimentary step towards semantic capability enablement. • Data instance • Hierarchical data collection

  17. Sensor/Meter Sensor/Meter Utily Application Common Data model Awareness Zigbee telco Profile Mbus/COSEM IPE IPE Mca specific Data model Awareness Mca Mca Mcc CSE CSE Application Service Node Infrastructure Node Interworking with non-oneM2M (Informative) • The Inter-working Proxy Application Entity (IPE) abstracts and maps the non-oneM2M data model to the oneM2M resources exposed via the Mca reference point • ZigBee. • DLMS/COSEM. • Zwave. • BACnet. • ANSI C12. • mBus. IPE  <AE> 1 n M2M Area Network 1 n Device 1 n • <AE>, • <container>, • <contentInstance> Application 1 n Interface 1 1 n n Data Field Method Generic data modeling of interworking Translation of non-oneM2M Data Model to oneM2M Specific Data Model

  18. Interworking Enhancement with Semantics (Informative)  <AE>  *Semantic URI  <container>  *Semantic URI  <container>  *Semantic URI  <contentInstance>  <container> * Attribute 'ontologyRef' links to the ontology definition of each concept (e.g. 'FunctionBlock'). A generic semantic concept model (ontology) representing an Area Network An example of mapping to oneM2M resources

  19. Roadmap to Semantic Enablement (Informative) 3. Use of Semantic Technologies for specific Platform Functionalities 1. Semantic Modeling (Ontology) 4. Full Semantic Platform 2. Semantic Annotation

  20. Roadmap to Semantic Enablement (Informative) 1. Semantic Modeling (Ontology)

  21. Roadmap to Semantic Enablement (Informative) 2. Semantic Annotation

  22. Roadmap to Semantic Enablement (Informative) 3. Use of Semantic Technologies for specific Platform Functionalities

  23. Roadmap to Semantic Enablement (Informative) 4. Full Semantic Platform

  24. Conclusion Applications Semantics Annotation Ontology Query Reasoning Mash-up … Abstraction oneM2M Common Service Layer [battery], [memory], [deviceInfo], [software], [firmware], … <AE> (e.g. IPE), <container>, <contentInstance>, … Interworking <mgmtObj>, <mgmtCmd> Technology-specific ZigBee KNX … OMA BBF … Management Abstraction Semantics

  25. Join us at theoneM2M showcase event

  26. backup

  27. Abstract Interface Descriptions (e. g. XML) SOAP REST Concepts - Abstraction • Examples of existing work study: • ETSI M2M ZigBee Interworking • HGI Smart Home Abstraction Layer (SHAL) High-level architecture for supporting device abstraction (Ref: ETSI TS 102 690: "Machine-to-Machine communications (M2M); Functional architecture".) Mapping of an abstract device to the ETSI M2M resource architecture using the <subcontainer> resource A high-level conceptual HGI architecture The abstract appliance interface descriptions should be mappable to various environments (Ref: HGI02029: "Smart Home Architecture and System Requirements")

  28. Concepts - Semantics • Examples of existing work study: • OGC Best Practice for semantic annotation • W3C Semantic Sensor Network (SSN) Ontology based on OGC SWE information model (Ref:Open Geospatial Consortium Best Practice, Semantic annotations in OGC standards.) Semantic annotations at levels of: service metadata, data model & data entities. (Ref:Semantic Sensor Network XG Final Report, W3C Incubator Group Report 28 June 2011.) Overview of the Semantic Sensor Network ontology classes and properties

  29. An Example Case using Semantics User request for high level info (e.g. Get Discomfort Index of Room X) Virtual resource created by semantic mash-up Semantic annotated data Raw data from physical devices An example of Home Environment Monitoring Service using semantic mash-up

More Related