IoT Internet of Things

The present document allows application developers to describe the status of devices as resources on oneM2M-based platform in various ways. Thus different application developers can create different resource trees even when they build the same kinds of applications. Moreover when handling the same kinds of devices from different vendors on M2M platforms, application developers may create disunited resource trees without common information model.

Prepare a standard for the lower layers for uni and bi-directional meters data exchange by radio frequency communication. (see resolutions 2& 3/1999).

IoT devices represent a wide variety of non-traditional devices that are increasingly implemented in organizations due to the numerous benefits. These unique devices often pose a security challenge due to the limited size and lack of innate security making them difficult to secure with traditional security controls and methodologies. It is a combination of these factors that has rendered many devices vulnerable to attacks like the Mirai botnet. The IoT Working Group's mission is dedicated to understanding relevant use cases for IoT deployments and defining actionable guidance for security practitioners to secure their IoT ecosystem. This includes outlining best practices for securing IoT implementations, identifying gaps in standards coverage for IoT security, and identifying threats to IoT devices and implementations.

The present document describes the oneM2M defined information model for home appliances, including the description of how it is mapped with other information models from external organizations. It also explains the ontology for the home domain information model.

The present document specifies the architectural options, resources and procedures needed to pre-provision and maintain devices in the Field Domain (e.g. ADN, ASN/MN) in order to establish M2M Service Layer operation between the device's AE and/or CSE and a Registrar and/Hosting CSE. The resources and procedures includes information about the Registrar CSE and/or Hosting CSE needed by the AE or CSE to begin M2M Service Layer operation.

The present document specifies the oneM2M and AllJoyn® interworking technologies that enable AllJoyn® Applications and oneM2M entities produce/consume services.

The OASIS Advanced Message Queuing Protocol (AMQP) Bindings and Mappings (AMQP-BINDMAP) Technical Committee works closely with the AMQP TC to advance a wire-level messaging protocol that offers organizations an efficient, reliable approach to passing real-time data and business transactions. AMQP provides a platform-agnostic method for ensuring information is safely transported between applications, among organizations, within mobile infrastructures, and across the Cloud.

The OASIS AMQP TC advances a vendor-neutral and platform-agnostic protocol that offers organizations an easier, more secure approach to passing real-time data streams and business transactions. The goal of AMQP is to ensure information is safely and efficiently transported between applications, among organizations, across distributed cloud computing environments, and within mobile infrastructures. AMQP avoids proprietary technologies, offering the potential to lower the cost of enterprise middleware software integrations through open interoperability. By enabling a commoditized, multi-vendor ecosystem, AMQP seeks to create opportunities for transforming the way business is done in the Cloud and over the Internet.

The purpose of oBIX (open Building Information Exchange) is to enable the mechanical and electrical control systems in buildings to communicate with enterprise applications, and to provide a platform for developing new classes of applications that integrate control systems with other enterprise functions. Enterprise functions include processes such as Human Resources, Finance, Customer Relationship Management (CRM), and Manufacturing.

This revision specifies technical corrections and clarifications to IEEE Std 802.11 for wireless local area networks (WLANS) as well as enhancements to the existing medium access control (MAC) and physical layer (PHY) functions. It also incorporates Amendments 1 to 10 published in 2008 to 2011.

In this amendment to IEEE Std 802.15.4TM-2011, a physical layer for IEEE 802.15.4 in the 2360 MHz to 2400 MHz band which complies with Federal Communications Commission (FCC) MBAN rules is defined. Modifications to the MAC needed to support this new physical layer are also defined in this amendment.

The Management Information Base (MIB) module specifications for IEEE Std 802.3, also known as Etherenet, are contained in this standard. It includes the Structure of Management Information Version 2 (SMIv2) MIB module specifications formerly produced and published by the Internet Engineering Task Force (IETF), and the Guidelines for the Definition of Managed Objects (GDMO) MIB modules formerly specified within IEEE Std 802.3, as well as extensions resulting from amendments to IEEE Std 802.3. The SMIv2 MIB modules are intended for use with the Simple Network Management Protocol (SNMP), commonly used to manage Etherenet.