Study Report on IoT Reference Architectures/Frameworks

Study Report on IoT Reference Architectures/Frameworks

Contents

1. Background ... 3

2. Introduction ... 4

3. Requirements for IoT Reference Architecture ... 4

3.1 General requirements for IoT Reference Architecture ... 5

3.2 Application specific requirements for IoT Reference Architecture ... 7

3.2.1 Examples of requirements only needed or critical in specific applications are ... 7

3.2.2 Example of a specific set of requirements for a specific application domain: those identified for sensor web applications ... 8

3.2.3 Example of how generic requirements lead to a specific set of requirements for a specific application domain - those identified for security ... 8

4. Identified differences in RAs studied (i.e. limitations, suitability for different applications) ... 10

5. Classification of requirements ... 10

6. Conclusion ... 11

Annex 1: Architecture and Framework documents ... 12

1. JTC 1 Standards ... 12

1.1 ISO/IEC 29182 Information Technology – Sensor networks – Sensor Network Reference Architecture (SNRA) ... 12

1.1.1 ISO/IEC 29182-1:2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 1: General overview and requirements ... 12

1.1.2 ISO/IEC 29182-2:2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 2: Vocabulary and terminology ... 12

1.1.3 ISO/IEC 29182-3: Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 3: Reference architecture views ... 13

1.1.4 ISO/IEC 29182-4: 2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 4: Entity models ... 14

1.1.5 ISO/IEC 29182-5:2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 5: Interface Definitions ... 15

1.1.6 ISO/IEC 29182-6: Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 6: Applications ... 16

1.1.7 ISO/IEC 29182-7: Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 7: Interoperability Guidelines ... 16

1.2 ISO/IEC TR 29181 Information technology -- Future Network -- Problem statement and requirements ... 17

1.2.1 ISO/IEC TR 29181-1:2012 General Aspects ... 18

1.2.2 ISO/IEC TR 29181-2: Naming and Addressing (currently DTR) ... 18

1.2.3 ISO/IEC TR 29181-3:2013 Switching and Routing ... 18

1.2.4 ISO/IEC TR 29181-4:2013 Mobility ... 19

1.2.5 ISO/IEC TR 29181-5 Security (currently DTR) ... 19

1.2.6 ISO/IEC TR 29181-6:2013 Media Distribution ... 19

1.2.7 ISO/IEC TR 29181-7:2013 Service Composition ... 19

1.3 JTC 1 Home Electronic Systems (HES) related activities ... 19

Study Report on IoT Reference Architectures/Frameworks

1.3.2 UPnP architecture (see Device architecture document Oct 2008 and ISO/IEC

29341 series) ... 20

1.4 JTC 1 SC29 – Media Context and control ... 22

1.4.1 ISO/IEC 23005-1:2014 Information technology -- Media context and control -- Part 1: Architecture ... 22

1.4.2 ISO/IEC 23005-2:2013 Information technology -- Media context and control -- Part 2: Architecture ... 22

1.4.3 ISO/IEC 23005-3:2013 Information technology -- Media context and control -- Part 3: Sensory Information ... 23

1.4.4 ISO/IEC 23005-4:2013 Information technology -- Media context and control -- Part 4: Virtual World Object characteristics ... 25

2.4.5 ISO/IEC 23005-5:2013 Information technology -- Media context and control -- Part 5: Data formats for interaction devices ... 25

1.4.6 ISO/IEC 23005-6:2013 Information technology -- Media context and control -- Part 6: Common types and tools ... 25

1.4.7 ISO/IEC 23005-7:2014 Information technology -- Media context and control -- Part 7: Conformance and reference software ... 26

1.5 Other JTC 1 activities related to IoT ... 26

1.5.1 JTC 1 WG 7 on Sensor Network’s NWIP JTC1 N12087 IoT Reference Architecture ... 26

1.5.2 Exploratory work in a number of JTC 1 SCs ... 26

2. ITU-T recommendations ... 26

2.1 ITU-T Y.2060 (Overview of the Internet of things – Published in 2012) ... 26

2.2 ITU-T Y.2069 (Terms and definitions for the Internet of things – Published in 2012) 27 2.3 ITU-T Y.2061 (Requirements for the support of machine oriented communication applications in the next generation network environment – Published in 2012) ... 28

2.4 ITU-T Y.2080 (Functional architecture for distributed service networking – Published in 2012) ... 29

2.5 ITU-T Y.2027 (Functional architecture of multi-connection – Published in 2012) 31 2.6 ITU-T Y.2063 (Framework of the web of things – Published in 2012) ... 32

2.7 ITU-T F.744 (Service description and requirements for ubiquitous sensor network middleware – Published in 2009) ... 34

2.8 ITU-T F.771 (Service description and requirements for multimedia information access triggered by tag-based identification– Published in 2008) ... 35

2.9 ITU-T H.621 (Architecture of a system for multimedia information access triggered by tag-based identification – Published in 2008) ... 36

2.10 ITU-T Y.gw-IoT-arch (Functional architecture of gateway for IoT applications – under development) ... 37

2.11 ITU-T Y.IoT-funct-framework (IoT functional framework and capabilities– under development) ... 38

2.12 ITU-T Y.2066 Common Requirements of the Internet of Things ... 39

3. ETSI ... 40

3.1 ETSI TS 102 690: Machine-to-Machine communications (M2M); Functional architecture. ... 40

Study Report on IoT Reference Architectures/Frameworks

Functional architecture ... 40

4. GS1 ... 44

4.1 GS1 EPCglobal Architecture Framework ... 44

5. OGC ... 47

5.1 OGC Sensor Web for IoT ... 47

6. IEC ... 48

6.1 IEC PAS 62883 The universAAL Framework for User Interaction in Multimedia Ambient Assisted Living (AAL) Spaces ... 48

7. Relevant Research Projects and Deliverables ... 49

7.1 IoT@Work project 2010- June 2013: https://www.iot-at-work.eu/ ... 49

7.2 IoT-a Project: ... 52

website: http://www.iot-a.eu/public/public-documents/documents-1 ... 52

7.3 IOT-I Internet of Things Initiative http://www.iot-i.eu ... 56

8. Thing Architecture: See http://thethingsystem.com ... 58

9. Weightless ... 61

10. Bluetooth Smart and Mesh ... 63

11. Korean RA work overview ... 65

Study on IoT Reference Architecture ... 65

12. IEEE P2413 ... 69

13. Other RA diagrams provided as additional information. ... 70

Annex 2: IoT Requirements mapping used to develop requirements section ... 72

1.

Background

At the November 2013 JTC 1 Plenary JTC 1 requested the JTC 1 SWG 5 (IoT) to prepare a study report on reference architectures for Internet of Things. This was covered in Resolution 9 by a new addition (8) to the Terms of Reference.

8. Study IoT Reference Architectures/Frameworks and provide a study report. This study report should be written so it could be referenced in a possible JTC 1 New Work Item Proposal on IoT. The report shall be made available to JTC 1 no later than the 2014 JTC 1 Plenary.

The SWG established a fourth AdHoc Group (AHG) under the leadership of Kate Grant to develop this Study Report. AHG 4 held 2 teleconferences on 23rd January and 10th February and reported to the fourth meeting of the SWG in Chongqing, China from 18th -20th March 2014.

The AHG was re-established at the fourth meeting and asked to produce the draft study report and attach as an annex the document they had prepared with information on a number of IoT reference architectures. The AHG continued to add additional sections to the annex and prepare the draft study report with further teleconferences from June to July 2014.

Study Report on IoT Reference Architectures/Frameworks

2.

Introduction

A number of Standards Organisations have worked in the area of Internet of Things. There are some application domain specific architectures, and some more generic reference architectures. Additionally a number of fora and consortia have been active in proposing architectures for the Internet of Things, some international research projects have also worked on such

developments.

Since there is no universally accepted definition of IoT, different groups have developed different approaches according to the domain in which they are active and where IoT

technology (or aspects thereof) is appropriate. Currently there is IoT related activity in JTC 1 SCs and other entities such as WG7, SC6, SC25, SC27, SC29, and SC31 with cloud aspects also in SC38. In ISO other TCs involved in aspects of IoT include TC104, TC 122, TC 211, TC 215, etc. In IEC other TCs and systems committees involved in IoT include IEC TC100 and the systems committees on AAL and Smart Cities.

In ITU-T there is a Joint Coordination Activity on IoT and various questions related to IoT are being progressed in SG9 (Q5, Q8 and Q9), SG11 (Q10 and Q12), SG13 (Q2, Q3, Q12, Q21 and Q25), SG16 (Q22, Q25, Q27 and Q28), SG17 (Q6, Q10 and Q12), and in ITU-R there is work in SG5. In ETSI there is significant activity on M2M. Fora and consortia involved in IoT related standardisation (with an example of their IoT related specifications) include OMA (Web Services Network Identity), 3GPP (M2M) Ecma (e.g. ECMA-262), OGC (Sensor Web) IEEE (802.24 TAG) and many others.

A single IoT reference architecture suitable for all these bodies is not an achievable goal so the AHG identified a number of IoT reference architectures and began an analysis of the common and domain specific requirements, and also identified differences in the reference architectures studied (i.e. limitations, suitability for different applications). Finally the AHG tried to draw some conclusions on the potential impact of these activities for JTC 1; while there is a possibility of defining a generic conceptual model logical and physical models are likely to diverge and be domain or application specific. The whole report is endorsed by the SWG 5 (IoT).

3.

Requirements for IoT Reference Architecture

Requirements for IoT systems have been identified by various SDOs, consortia, and

manufacturers. Some of these have direct implications for a reference architecture while some may directly or indirectly influence the design and architecture of a particular system.

Requirements may be generic and apply to all systems or be specific to a particular domain or application area. In this requirements section the requirements identified in the documents referenced in the annex of IoT reference architectures have been grouped into general and application-specific requirements with a brief outline of the requirement itself. For those who want to compare the different descriptions of these requirements in existing specifications a mapping of these requirements is included in annex 2.

Study Report on IoT Reference Architectures/Frameworks

The Reference Architecture should not prescribe any specific method for implementation unless this is a requirement for a specific application domain. The architecture should describe the system or systems for the IoT, the major components involved, the relationships between them, and their externally visible properties.

The performance level of each requirement may be important, and it may involve not only the performance of a specific component but the overall system performance. In some applications specific requirements are critical for successful implementation.

3.1 General requirements for IoT Reference Architecture

The IoT RA should support compliance with any relevant regulations and regional requirements.

2. Autonomous Functionality

The IoT RA should support self-configuring, self-healing, self-optimizing and self-protecting capabilities at the networking level, in order to adapt to different application domains, different communication environments, large numbers and different types of devices.

3. Auto-configuration

The IoT RA should support auto-configuration so that the IoT system can react to the addition and removal of components such as devices and networks.

4. Scalability

The IoT RA should support a large range of applications varying in size, complexity, and workload. The IoT RA should support systems involving a large number of devices,

applications, users, significant data traffic volumes, frequencies of event reporting etc. Ideally the same components that are used in a very simple application should also be usable in a very large complex distributed system.

5. Discoverability

The IoT RA should support discovery services so that the IoT users, services, capabilities, devices and data from devices can be discovered according to different criteria, such as geographic location information, type of device, etc. Discovery services need to be supported across domains in complex IoT systems.

6. Heterogeneity

The IoT RA should support heterogeneous devices and networks with different types of devices regarding communication technology, computing capabilities, storage capability and mobility, different service providers and different users and support interoperability among different networks and operating systems. The IoT RA should support global-scale

connectivity including legacy system interworking.

7. Unique Identification

The IoT RA should support standardised unique identification for each component of the IoT (e.g. devices and services) to provide interoperability and support services such as discovery and authentication across heterogeneous networks.

Study Report on IoT Reference Architectures/Frameworks

The IoT RA should support Plug and Play capability in order to enable on-the-fly generation, composition or the acquisition of semantic-based configurations for seamless integration and cooperation of interconnected components with applications, and responsiveness to application requirements.

9. Standardised Interfaces

The IoT RA should support standardised interfaces to IoT RA components based on well-defined, interpretable, and unambiguous standards. Devices offering external interoperability through standardised interfaces can support internal component flexibility and customisation for applications. Standardized web services should exist for accessing sensor information and sensor observations.

10.Well Defined Components

The IoT RA should support the connection of a diverse heterogeneous set of components to perform differing functions based on stakeholder needs. The architecture should support discovery and use of components whose characteristics are well known and described using standardized semantics and syntax.

11.Network Connectivity

The IoT RA should support connectivity capabilities which are independent of specific

application domains, and integration of heterogeneous communication technologies needs to be supported to allow interoperability between different IoT devices and services. Networked systems may need to deliver specific Quality of Service (QoS), and support time-aware, location-aware, context-aware and content-aware communications

12.Timeliness

The IoT RA should support timeliness, because the characteristic of providing a service within a specified time is necessary to deal with a range of functions at different levels within the IoT system.

13.Time-Awareness

The IoT RA should support time synchronicity among the actions of interconnected

components when using communication and service capabilities. Accurately associating a time measurement with a measurement from the physical world is an important aspect of IoT components. It may be necessary to accurately combine or associate data from multiple sensors and data sources. Both the time value and uncertainty of the value are needed to properly assess whether a specific component can perform the requisite task.

14.Location-Awareness

The IoT RA should support IoT components that interact with the physical world and have an awareness of physical location. The accuracy requirement for location will change based upon the application. It is therefore important that components can describe not only their locations, but also the associated uncertainty of the locations.

15.Context-Awareness

The IoT RA should support Context-Awareness so the IoT can enable flexible, user-customized and autonomic services based on the related context of IoT components and/or users. Context information is used as the basis for taking actions in response to the situation at hand, possibly through the use of sensor information and actuators.

16.Content-Awareness

The IoT RA should support content awareness to facilitate services such as path selection and routing of communications based on content.

Study Report on IoT Reference Architectures/Frameworks

IoT RA should support components that can be combined in different configurations to form systems as needed. By focusing on standardized interfaces and not specifying the internal workings of each component, implementers have flexibility in the design of components and IoT systems.

18.Reliability

The IoT RA should support the appropriate level of reliability in aspects such as

communication, service and data management capabilities to meet system requirements. The IoT RA should be resilient and support the ability to respond to change due to external perturbations, error detection and self-healing.

19.Security

The IoT RA should support secure components, communications, access control to the system and the management services and data security. Both physical and cyber security aspects should be supported by the IoT RA.

20.Confidentiality and Privacy

The IoT RA should support the confidentiality and privacy requirements of an IoT implementation.

21.Legacy Components

The IoT RA should support legacy component integration and migration. New components and systems should be designed so that present or legacy aspects do not unnecessarily limit future system evolution. A plan for adaptation and migration of legacy systems must be developed to ensure legacy investments are not prematurely stranded. Legacy components should be integrated in a way that ensures that security and other essential performance and functional requirements are met.

22.Manageability

The IoT RA should support management capabilities to address aspects such as data

management, device management, network management, and interface maintenance and alerts.

23.Risk management

The IoT RA should support operational resilience under normal and abnormal conditions.

3.2 Application specific requirements for IoT Reference Architecture

Application categories may overlap several domains or may be domain specific.

3.2.1 Examples of requirements only needed or critical in specific applications are

1. Power and Energy Management

The IoT RA should support power and energy management particularly in networks with battery powered components. Different strategies will suit different applications but may include using low-power components in devices, limiting the communication range, limiting the local processing and storage capacity, supporting sleep modes and energy harvesting.

2. Accessibility

The IoT RA should support accessibility preferences and requirements. In some application domains accessibility will be important for the usability of the IoT system for example in AAL systems and wherever there is significant user involvement in the configuration, operation and management of the system.

Study Report on IoT Reference Architectures/Frameworks

The IoT RA should support implementations involving safe human body connectivity. In order to provide communication capabilities related with the human body in compliance with

regulation and laws a special quality of service is required, reliability and security have to be quantified, and privacy protection is required

4. Service Related Requirements

The IoT RA should support service related requirements such as prioritisation, semantic services, service composition, usage tracking, and service subscription which will vary

according to the application domain and implementation. For example Location-Awareness in some applications may need the support of location-based services with specified accuracy.

5. “Environmental Impact” Requirements

The IoT RA should support components, services and capabilities which lead to minimal “environmental impact” for an implementation.

3.2.2 Example of a specific set of requirements for a specific application domain: those identified for sensor web applications

 Sensors will be web accessible

 Sensors and sensor data will be discoverable

 Sensors will be self-describing to humans and software (using a standard encoding)

 Most sensor observations will be easily accessible in real time over the web

 Standardized web services will exist for accessing sensor information and sensor observations

 Sensor systems will be capable of real-time mining of observations to find phenomena of immediate interest

 Sensor systems will be capable of issuing alerts based on observations, as well as be able to respond to alerts issued by other sensors

 Software will be capable of on-demand geolocation and processing of observations from a newly-discovered sensor without a priori knowledge of that sensor system

 Sensors, simulations, and models will be capable of being configured and tasked through standard, common web interfaces

 Sensors and sensor networks will be able to act on their own (i.e. be autonomous

3.2.3 Example of how generic requirements lead to a specific set of requirements for a specific application domain - those identified for security

Generic Requirements from 3.1: 19.Security

The IoT RA should support secure components, communications, access control to the system and the management services and data security. Both physical and cyber security aspects should be supported by the IoT RA.

20.Confidentiality and Privacy

The IoT RA should support the confidentiality and privacy requirements of an IoT implementation.

An example of how these generic requirements for security can be amplified below. Some applications may need all these requirements to be met while other applications may just need a subset:

Study Report on IoT Reference Architectures/Frameworks

• Cryptographic stability and longevity

• Prove the integrity of the data and authenticity

• Prove deletion and decommissioning

• Chain of evidence

• Prove evidence of capability and functionality

• Routing of data

• Long term archiving of data

• Integrated reporting: endpoint, gateway, network, Clouds and Data Centre

• Privacy and personal data regulations

• Anonymity • Unlinkability • Unobservability • Verified deletion • Right to be forgotten • Data portability

• Reliability and availability

• Network performance and Service Level Agreements

• IoT Design and Documentation

• Self-healing and self-organizing

• Remote diagnostics and management

• Resource Consumption and Energy Management

• Device resilience e.g. Wills

• Flow classification and QoS

• Interchangeability /Vendor neutrality

• Lifetimes, upgrading and disposal

• Heartbeats, census and inventory

• Documentation and reporting

• Identity and access control

• Multi-party authentication and cryptography in the IoT

• Group authentication and authorization

• Autonomics (self-configuring, intelligence for control)

• Discovery/search (e.g. Directories and memberships)

• Authorization, Authentication and credentials requirements

• Access Control, subject-based, role based, attribute-based,

• Uniquely Addressable

• Ownership transfer

• Anonymous devices and blinded identities

• Usage context

• Data and time as context

• Presence of people as context

• Device type as context

• Operational State of IOT application

• Location awareness

Study Report on IoT Reference Architectures/Frameworks

• Well-defined components and architecture

• Device adaptation

• Inclusivity of Things

• Scalability (including Network flow reversal)

• Interoperability of components

• Standardized interfaces

• Legacy device support

• Support for both network and application virtualization.

• Transportability of subscriptions and service: supporting competitive service provision.

• Diversity and utility of reporting and interfaces.

• Risk Management

• End point controls

• Gateway controls

• Network controls

• Cloud/data centre/application controls

• Overall systems controls

4.

Identified differences in RAs studied (i.e.

limitations, suitability for different applications)

There are clear differences in the approach to the following requirements:

 Power requirements

 Cost

 Security

 Range

 Domain e.g. weightless vs ETSI M2M

5.

Classification of requirements

The requirements for a Reference Architecture for IoT identified in this report may need to be classified; one possible solution would be to adopt a similar classification to that used by Y.2066 where requirements are divided into:

– Implementation and operability requirements – Non-functional requirements

– Application support requirements; – Service requirements;

– Communication requirements; – Device requirements;

– Data management requirements;

Study Report on IoT Reference Architectures/Frameworks

6.

Conclusion

IoT is emerging as a major horizontal activity which will impact the work of many JTC 1 SCs. There is an urgent need for the development of a generic reference architecture which can help ensure a consistent approach to IoT standardisation throughout JTC 1.

To develop a consistent approach to IoT standardisation in JTC 1 will require considerable coordination if all the standards are developed in separate SCs. In IEC there is already a new approach to improve such integration – the use of Systems Committees for these “cross-committee” activities. The IEC SMB SG on Industry 4.0 will be covering various aspects of IoT and may eventually lead to a systems committee covering this area. The current JTC 1 approach with an SWG which can encourage cooperation but needs the support and ongoing involvement of all SCs involved in the area could be improved with a similar approach which clarifies the different responsibilities between committees undertaking generic standardisation and those dealing with specific aspects such as security.

Nevertheless the number of different specifications being developed in a variety of bodies (SDOs, fora, consortia) illustrates the urgent need for the development of a generic reference architecture which can help ensure a consistent approach to IoT standardisation throughout JTC 1. It is desirable for a committee under JTC 1 to be able to develop the generic standards required for IoT while the specialised work would still be done in the relevant SC, for example security aspects and requirements would be developed in SC27.

Study Report on IoT Reference Architectures/Frameworks

Annex 1: Architecture and Framework documents

This document summarises some of the documents, relating to existing and developing IoT Architectures/Frameworks, identified by the AHG members and provides a brief overview of scope, content etc. of the documents

1.

JTC 1 Standards

1.1 ISO/IEC 29182 Information Technology – Sensor networks –

Sensor Network Reference Architecture (SNRA)

The 29182 series has been developed by JTC 1 WG7 – Sensor Networks. The purpose of the standard is to (i) provide guidance to facilitate the design and development of sensor networks, (ii) improve interoperability of sensor networks, and (iii) make sensor network components plug-and-play, so that it becomes fairly easy to add/remove sensor nodes to/from an existing sensor network. The ISO/IEC 29182 series focuses on a generic architecture for sensor

networks. It can be used by sensor network designers, software developers, system integrators, and service providers to meet customer requirements, including any applicable interoperability requirements. The seven parts of the 29182 series are described below.

1.1.1 ISO/IEC 29182-1:2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 1: General

overview and requirements

Part 1 provides a general overview of the characteristics of a sensor network and the organization of the entities that comprise such a network. It also describes the general requirements that are identified for sensor networks. It presents sensor network architecture from the communications and service provisioning perspectives (standalone, interconnected, connected to other networks), the characteristics of sensor networks that differentiate them from traditional data networks, and general requirements for sensor networks.

1.1.2 ISO/IEC 29182-2:2013 Information technology -- Sensor networks:

Sensor Network Reference Architecture (SNRA) -- Part 2: Vocabulary and

terminology

Part 2 provides a general overview of the characteristics of a sensor network and the organization of the entities that comprise such a network. It also describes the general requirements that are identified for sensor networks. It presents terms and definitions for selected concepts relevant to the field of sensor networks, establishes a general description of concepts in this field, and identifies the relationships among those concepts.

Study Report on IoT Reference Architectures/Frameworks

1.1.3 ISO/IEC 29182-3: Information technology -- Sensor networks: Sensor

Network Reference Architecture (SNRA) -- Part 3: Reference architecture

views

ISO/IEC 29182-3:2014 provides Sensor Network Reference Architecture (SNRA) views. The architecture views include business, operational, systems, and technical perspectives, and these views are presented in functional, logical, and/or physical views where applicable. ISO/IEC 29182-3:2014 focuses on high-level architecture views which can be further developed by system developers and implementers for specific applications and services. Two such views are shown in Figures 1-2: Data Communication S e n s in g D o m a in Wide Area Network S e rv ic e D o m a in

Data, Information, & Communications

Data Processing

Control & Management Device Management

Data Mining CIP

Security Management Service Management Business Management User Management Service Management Security Management Device Management Security Management Service Management Network Management

Feedback & Control Communication

Protocol Stack

Communication Support functions Data Acquisition Data Storage

Data Processing Feature Extraction Data Fusion Data Aggregation Data Storage Data Fusion Data Communication CIP Information Communication Information Provisioning N e tw o rk D o m a in Local Area Networks Others Others

Study Report on IoT Reference Architectures/Frameworks

Figure 2- Physical operation activity model

1.1.4 ISO/IEC 29182-4: 2013 Information technology -- Sensor networks:

Sensor Network Reference Architecture (SNRA) -- Part 4: Entity

models

Part 4 presents models for the entities that enable sensor network applications and services according to the Sensor Network Reference Architecture (SNRA). It provides basic information about and high-level models for various entities that comprise a sensor network. Physical entities are pieces of hardware and actual devices or components thereof that form the network, such as sensor nodes and gateways while functional entities represent certain tasks that may be carried out on one or more types of physical entity (see Figure 3).

Study Report on IoT Reference Architectures/Frameworks

•

Figure 3- Functional entities of a sensor network

1.1.5 ISO/IEC 29182-5:2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 5: Interface Definitions

Part 5 provides the definitions and requirements of sensor network (SN) interfaces of the entities in the Sensor Network Reference Architecture and covers the following aspects:

 interfaces between functional layers to provide service access for the modules in the upper layer to exchange messages with modules in the lower layer;

 interfaces between entities introduced in the Sensor Network Reference Architecture enabling sensor network services and applications.

Study Report on IoT Reference Architectures/Frameworks

Sensor Node Hardware Layer

*Colored boxes represent SN interfaces

Sensor node Gateway node Backbone Network Service provider User Application Layer Interface - SL/AL* Service Layer Interface – HL/BFL* Basic Functions Layer Interface - BFL/SL* Cross-Layer Manag ement Interface - CLM/AL-SL-BFL Interface 1 Interface 3 Interface 4 Interface 5 Interface 2

Figure 4- Various interfaces of a sensor network

1.1.6 ISO/IEC 29182-6: Information technology -- Sensor networks:

Sensor Network Reference Architecture (SNRA) -- Part 6: Applications

This part provides a compilation of sensor network applications for which International Standardized Profiles (ISPs) are needed, guidelines for a structured description of sensor network applications, examples of structured sensor network application descriptions such as management of mobile assets in hospitals and container monitoring in the supply chain, that support the development of ISPs in a follow up step.

1.1.7 ISO/IEC 29182-7: Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 7: Interoperability Guidelines

This Part provides a general overview and guidelines for achieving interoperability between service providers and related entities in a heterogeneous sensor network as illustrated below.

Study Report on IoT Reference Architectures/Frameworks

Figure 5-Using a generic standardized sensor network interface for interoperability

Figure 6-Using multiple interfaces on a gateway for interoperability

1.2 ISO/IEC TR 29181 Information technology -- Future Network --

Problem statement and requirements

SC6 WG7’s work on Future Network (FN) aims to create a series of new network architecture and protocol standards based on a clean slate design approach where the network design can take into the consideration of the requirement of technological and social needs for more secure, more efficient and more economical information exchange and network

communication. The FN project development plan has three stages:

 Stage 1 is the study of problems and overall requirements

 Stage 2 is the establishment of FN architecture/framework  Stage 3 is the development of FN network protocols

Study Report on IoT Reference Architectures/Frameworks



Figure 7: General Concept of FN

1.2.1 ISO/IEC TR 29181-1:2012 General Aspects

Part 1 describes the definition, general concept, problems and requirements for Future Network (FN). It also discusses a milestone for standardization on FN. The scope includes: motivation of FN; definition, general concept, and terminologies of FN; services and

applications in FN; problems with current networks; design goals and high-level requirements for FN; milestones for standardization on FN.

1.2.2 ISO/IEC TR 29181-2: Naming and Addressing (currently DTR)

Part 2 describes the general characteristics of Future Network Naming and Addressing Schemes including problem statement, design objectives, gap analysis, and development directions. The topics include: the characteristics and deficiencies of existing NAS in existing network; a list of major technical challenges to assure that the FN-NAS will be able to provide solid technical support from the base level to meet the objectives of FN; the general

characteristics of Future Network are discussed and their impact on NAS design; examines the gap between existing network NAS and future network performance expectations; specify objectives and principles for NAS design.

1.2.3 ISO/IEC TR 29181-3:2013 Switching and Routing

Part 3 contains the problem statement and requirements for switching and routing in the Future Network, in particular: 1, description of the requirements for carrying data over digital networks; 2, description of the ways in which these requirements are not satisfied by current networks; 3, functional architecture for switching and routing in the Future Network; 4, and requirements for control plane information flows for finding, setting up, and tearing down routes. The requirements in 4 include support for both current ("legacy") and future ("new") switching technologies, to aid the transition between them.

Study Report on IoT Reference Architectures/Frameworks

1.2.4 ISO/IEC TR 29181-4:2013 Mobility

Part 4 describes the problem statements of current network and the requirements for Future Network in the mobility perspective. It mainly specifies problems of the current network in mobile environment, and requirements for mobility support in Future Network. In addition, ISO/IEC TR 29181-4:2013 gives information on existing mobility control schemes in the current network, examples of high-level mobility control architecture for Future Network, distributed mobility control in the Proxy Mobile IPv6 networks, and additional considerations for Future Network mobility.

1.2.5 ISO/IEC TR 29181-5 Security (currently DTR)

Part 5 describes the problem statements of current network and the requirements for Future Network in the security perspective. It mainly specifies Problems of the current network in security environment and requirements for security support in Future Network.

1.2.6 ISO/IEC TR 29181-6:2013 Media Distribution

Part 6 describes the problem statement and requirements for the Future Network in the perspective of media transport. ISO/IEC TR 29181-6:2013 specifies: detailed description of the media transport requirements in the Future Network; identification and definition of services, basic and media services, which will fit the requirements for communications over heterogeneous environments supporting various user preferences, for any kind of media content, either time-dependent or time-independent; requirements and functionalities of Media Aware Network Elements, which are intended to be nodes in the network to provide seamless media experiences to users.

1.2.7 ISO/IEC TR 29181-7:2013 Service Composition

Part 7 describes the problem statement, requirements and a functional building block for the Future Network (FN) from the perspective of service composition. The goal of is to: analyse and classify problems of the current solutions on the service composition, identify

requirements on the service composition for the FN, describe some technical aspects of the service composition for the FN, and propose a functional building block of the service

composition including functional components and their reference points among them. ISO/IEC TR 29181-7:2013 also introduces various on-going standardization and research activities related to service composition.

1.3 JTC 1 Home Electronic Systems (HES) related activities

1.3.1 Background

JTC1 SC25 reports that the home systems industry is in an active phase of commercialisation. Renewed attention by industry, consumers and governments in energy management,

conservation, and greenhouse gas emissions, renewable sources of energy, energy storage, transactive energy (for grid stability), electric vehicle interconnection with home networks and the “smart grid” will further expand the market for home networking applications.

Study Report on IoT Reference Architectures/Frameworks

Internet connectivity to receive Internet TV (IPTV). Homes are increasingly equipped with home systems meeting HES standards ISO/IEC 14543-x-y series that support competitive markets and interoperability of products from different sources within its sub -series. This series was extended to include a wireless protocol optimised for energy harvested by devices such as sensors. Standards for remote access and management of home equipment are being developed. Products meeting these specifications have been well received by the market and enable smart grids to interact with intelligent homes. It should be noted that homes are made intelligent with interconnected sensors, actuators and smart consumer appliances. Such networks use a variety of media: IT cabling, wireless and power line communication. In addition SC 25 seeks to facilitate system interoperability beyond the sub series within ISO/IEC 14543 by continuing development of subsequent parts to the SC 25 standards for the

residential gateway (ISO/IEC 15045) and product interoperability (ISO/IEC 18012). JTC 1 SC25 Work continues on “Home Network Resource Management” (HNRM) (ISO/IEC 30100). Home resource management allows uniform fault processing, diagnostics and configuration management of HES elements in a home environment. Among the elements that may be managed with this protocol are:

 A server operated by a home network service provider.

 A server operated by the management office of an apartment complex.  A home residential gateway or set-top box.

The UPnP Architecture that was approved under the fast track procedure and published as ISO/IEC 29341 in 2008 has been updated and extended under the JTC 1 PAS transposition procedures in 2011 and will be further maintained and extended. WG 1 completed multiple parts of a series of standards to add IGRS (Intelligent Grouping and Resource Sharing) to the HES Architecture as ISO/IEC 14543-5-y that specifies comparable functions.

1.3.2 UPnP architecture (see Device architecture document Oct 2008 and ISO/IEC 29341 series)

UPnP™ technology defines an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP technology provides a distributed, open networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices.

The UPnP Device Architecture (UDA) is more than just a simple extension of the plug and play peripheral model. It is designed to support zero-configuration, "invisible" networking, and automatic discovery for a breadth of device categories from a wide range of vendors. This means a device can dynamically join a network, obtain an IP address, convey its capabilities,

Study Report on IoT Reference Architectures/Frameworks

The UPnP description for a device is partitioned into two logical parts: a device description

describing the physical and logical containers, and service descriptions describing the capabilities exposed by the device. A UPnP device description includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. (details below). For each service included in the device, the device description lists the service type, service name, a URL for a service

description, a URL for control, and a URL for eventing. A device description also includes a description of all embedded devices and a URL for presentation of the aggregate. This section explains UPnP device descriptions, and the sections on Control, Eventing, and Presentation explain how URLs for control, eventing, and presentation are used respectively.

The UPnP description for a device is partitioned into two logical parts: a device description

describing the physical and logical containers, and service descriptions describing the capabilities exposed by the device. A UPnP device description includes there is one UPnP device description for the root device, and that device description contains a description for all embedded devices. In the latter case, there are multiple UPnP device descriptions, one for each root device. vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. (details below). For each service included in the device, the device description lists the service type, service name, a URL for a service description, a URL for control, and a URL for eventing. A device description also includes a description of all embedded devices and a URL for presentation of the aggregate.

When a device is added to the network, the device advertises its services to control points. It does this by multicasting discovery messages to a standard address and port. Control points listen to this port to detect when new capabilities are available on the network. To advertise the full extent of its capabilities, a device must multicast a number of discovery messages corresponding to each of its root devices, embedded devices and services.

Particular elements are defined by the UPnP device architecture, for example manufacturer, model, UUID, UPC, icon list (image format, colour depth size etc.) service list, embedded devices

To control a device, a control point invokes an action on the device's service. After a control point has (1) discovered a device and (2) retrieved a description of the device, the control point is ready to begin presentation. If a device has a URL for presentation, then the control point can retrieve a page from this URL, load the page into a browser and, depending on the capabilities of the page, allow a user to control the device and/or view device status. The degree to which each of these can be accomplished depends on the specific capabilities of the presentation page and device.

Study Report on IoT Reference Architectures/Frameworks

1.4 JTC 1 SC29 – Media Context and control

1.4.1 ISO/IEC 23005-1:2014 Information technology -- Media context and control -- Part 1: Architecture

MPEG-V outlines an architecture and specifies associated information representations to enable interoperability

 between virtual worlds (e.g., digital content provider of a virtual world, gaming, simulation), and

 between real and virtual worlds( e.g., sensors, actuators, vision and rendering, robotics). This part specifies the architecture of MPEG-V (media context and control), and its three associated use cases of information adaptation from virtual world to real world, information adaptation from real world to virtual world, and information exchange between virtual worlds. It outlines the Architecture, the associated information representations and lists the

components, APIs and use cases.

1.4.2 ISO/IEC 23005-2:2013 Information technology -- Media context and control -- Part 2: Architecture

MPEG-V Part 2 specifies syntax and semantics of the tools required to provide interoperability in controlling devices in real as well as virtual worlds.

The adaptation engine (Real-Virtual or Virtual-Real engine), which is not within the scope of standardization, takes five inputs: sensory effects (SE), user’s sensory effect preferences (USEP), sensory devices capabilities (SDC), sensor capability (SC), and sensed information (SI) and outputs sensory devices commands (SDC) and/or sensed information (SI) to control the devices in real world or the parameters of the virtual world objects.

The scope of MPEG-V Part 2, illustrated in the Figure below, covers the interfaces between the adaptation engine and the capability descriptions of actuators/sensors in the real world and the user’s sensory preference information, which characterizes devices and users. Therefore the appropriate information to control devices (actuators and sensors) can be generated from the sensory effects. In other words, user’s sensory preferences, sensory device capabilities, and sensor capabilities are within the scope of this part of MPEG-V. The control information including the user's sensory preference information, device capability description, and sensor capability description can be used to fine tune the sensed information and the device command for the control of virtual/real world by providing extra information to the adaptation engine.

Study Report on IoT Reference Architectures/Frameworks

Figure:Scope of the Control Information MPEG-V Part 2 is composed as follows:

 A tool called Control Information Description Language (CIDL) is defined to provide a basic structure of the description of control information;

 A set of tools called Device Capability Description Vocabulary (DCDV) is defined to provide interface for describing capability of each individual sensory device;

 A set of tools called Sensor Capability Description Vocabulary (SCDV) is defined to provide interface for describing capability of each individual sensor;

 A set of tools called Sensory Effect Preference Vocabulary (SEPV) is defined to

provide interface for describing preference of individual user on specific sensory effect.

1.4.3 ISO/IEC 23005-3:2013 Information technology -- Media context and control -- Part 3: Sensory Information

MPEG-V Part 3 Sensory Information specifies the Sensory Effect Description Language (SEDL) as an XML Schema-based language which enables one to describe so-called sensory effects such as light, wind, fog, vibration, etc. that trigger human senses. The actual sensory effects are not part of SEDL but defined within the Sensory Effect Vocabulary (SEV) for extensibility and flexibility allowing each application domain to define its own sensory effects. A description conforming to SEDL is referred to as Sensory Effect Metadata (SEM) and may be associated to any kind of multimedia content (e.g., movies, music, Web sites, games). The SEM is used to steer sensory devices like fans, vibration chairs, lamps, etc. via an appropriate mediation device in order to increase the experience of the user. That is, in addition to the audio-visual content of, e.g., a movie, the user will also perceive other effects such as the ones described above, giving her/him the sensation of being part of the particular media which shall result in a worthwhile, informative user experience. The concept of receiving sensory effects in addition to audio/visual content is depicted in Figure below.

Study Report on IoT Reference Architectures/Frameworks

Figure: Concept of MPEG-V Sensory Effect Description Language.

The media and the corresponding SEM may be obtained from a Digital Versatile Disc (DVD), Blu-ray Disc (BD), or any kind of online service (i.e., download/play or streaming). The media processing engine – sometimes also referred to as RoSE Engine – acts as the mediation device and is responsible for playing the actual media resource and accompanied sensory effects in a synchronized way based on the user’s setup in terms of both media and sensory effect

rendering. Therefore, the media processing engine may adapt both the media resource and the SEM according to the capabilities of the various rendering devices.

The Sensory Effect Vocabulary (SEV) defines a clear set of actual sensory effects to be used with the Sensory Effect Description Language (SEDL) in an extensible and flexible way. That is, it can be easily extended with new effects or by derivation of existing effects thanks to the extensibility feature of XML Schema. Furthermore, the effects are defined in a way to abstract from the authors intention and be independent from the end user’s device setting as depicted below.

Figure 2. Mapping of Author’s Intentions to Sensory Effect Metadata and Sensory Device Capabilities.

The sensory effect metadata elements or data types are mapped to commands that control sensory devices based on their capabilities. This mapping is usually provided by the RoSE engine and deliberately not defined in this standard, i.e., it is left open for industry competition.

Study Report on IoT Reference Architectures/Frameworks

It is important to note that there is not necessarily a one-to-one mapping between elements or data types of the sensory effect metadata and sensory device capabilities. For example, the effect of hot/cold wind may be rendered on a single device with two capabilities, i.e., a heater/air conditioner and a fan/ventilator.

Currently, the standard defines the following effects:

 Light, coloured light, flash light;

 Temperature;  Wind;  Vibration;  Sprayer;  Scent;  Fog;  Colour correction;  Motion;  Kinesthetic  Tactile.

1.4.4 ISO/IEC 23005-4:2013 Information technology -- Media context and control -- Part 4: Virtual World Object characteristics

ISO/IEC 23005-4:2013 specifies syntax and semantics of description schemes and descriptors used to characterize a virtual world object related metadata, making it possible to migrate a virtual world object (or only its characteristics) from one virtual world to another and to control a virtual world object in a virtual world by real world devices.

2.4.5 ISO/IEC 23005-5:2013 Information technology -- Media context and control -- Part 5: Data formats for interaction devices

ISO/IEC 23005-5:2013 specifies syntax and semantics of the data formats for interaction devices, i.e. Device Commands and Sensed Information, required for providing

interoperability in controlling interaction devices and in sensing information from interaction devices in real as well as virtual worlds.

1.4.6 ISO/IEC 23005-6:2013 Information technology -- Media context and control -- Part 6: Common types and tools

ISO/IEC 23005-6:2013 specifies syntax and semantics of the data types and tools common to the tools defined in the other parts of ISO/IEC 23005, such as basic data types which are used as basic building blocks in more than one of the tools in ISO/IEC 23005, colour-related basic types which are used in light and colour-related tools to help in specifying colour-related characteristics of the devices or commands, and time stamp types which can be used in device commands, and sensed information to specify timing related information.

Several classification schemes which are used in more than one part of ISO/IEC 23005 are also defined in Annex A of ISO/IEC 23005-6:2013. Other tools to be developed are included in ISO/IEC 23005-6:2013, if those tools are to be used with the tools defined in more than one

Study Report on IoT Reference Architectures/Frameworks

part of ISO/IEC 23005. Most of the tools defined in ISO/IEC 23005-6:2013 are not intended to be used alone, but to be used as a part or as a supporting tool of other tools defined in other parts of ISO/IEC 23005.

1.4.7 ISO/IEC 23005-7:2014 Information technology -- Media context and control -- Part 7: Conformance and reference software

ISO/IEC 23005-7:2014 specifies the conformance and reference software implementing the normative clauses of all parts of ISO/IEC 23005. The information provided is applicable for determining the reference software modules available for the parts of ISO/IEC 23005,

understanding the functionality of the available reference software modules, and utilizing the available reference software modules. The available reference software modules are specified in the form of application programming interfaces (API) according to ISO/IEC 23006-1. Furthermore, ISO/IEC 23005-7:2014 provides means for conformance testing, i.e. bit-streams - XML descriptions - that conform or do not conform to the normative clauses of the other parts of ISO/IEC 23005 and informative descriptions thereof.

1.5 Other JTC 1 activities related to IoT

1.5.1 JTC 1 WG 7 on Sensor Network’s NWIP JTC1 N12087 IoT Reference Architecture

Scope

“This new work item specifies IoT conceptual model, conceptual reference model, and reference architecture from different architectural views, common entities, and interfaces between IoT domains. “

1.5.2 Exploratory work in a number of JTC 1 SCs

A number of SCs have set up exploratory activities or study groups; for example

 SC27

 SC29

 SC38

2. ITU-T recommendations

2.1 ITU-T Y.2060 (Overview of the Internet of things – Published in

2012)

This document explains IoT Reference Architecture as layers in abstract level. Functionalities in each layer of IoT Reference Model are described. Also, this document defines IoT

ecosystem and business models relevant to the IoT Reference Model.

Scope

Study Report on IoT Reference Architectures/Frameworks

-Figure 8: IoT Reference Model

Platform provider Application provider Application customer

Network provider

Device provider

IoT Ecosystem

2.2 ITU-T Y.2069 (Terms and definitions for the Internet of things –

Published in 2012)

Scope: Terms and Definitions of IoT

This document collects the terms and definitions of IoT which are published in ITU-T

Recommendations in regard of NID (RFID), USN (Sensor Network), Ubiquitous Computing, Web of Things, M2M and etc.

Study Report on IoT Reference Architectures/Frameworks

2.3 ITU-T Y.2061 (Requirements for the support of machine

oriented communication applications in the next generation network

environment – Published in 2012)

This document defines MOC architecture and its capabilities which are similar to M2M. The device domain, network domain and service domain are defined and capabilities in each domain are also defined in this architecture.

Scope

 network overview; description of an MOC ecosystem and the characteristics of MOC

 service requirements for the support of MOC applications

 requirements of NGN capabilities based on MOC service requirements  requirements of MOC-device domain capabilities based on MOC service

requirements

 reference framework for MOC capabilities



Study Report on IoT Reference Architectures/Frameworks

High-level view of the reference framework for MOC capabilities

2.4 ITU-T Y.2080 (Functional architecture for distributed service

networking – Published in 2012)

Scope

- Functional architecture of distributed service networking(DSN) and its relationships with next generation networks (NGNs)

- Description of functions required for the support of the DSN and reference points between DSNfunctions

DSN is an overlay networking which provides distributed and manageable capabilities to support various multimedia services and applications in a NGN (Next Generation Network) environment

Study Report on IoT Reference Architectures/Frameworks

Study Report on IoT Reference Architectures/Frameworks

Relationship between the DSN and NGN from a functional architecture view

2.5 ITU-T Y.2027 (Functional architecture of multi-connection –

Published in 2012)

This document explains multiple-connection architecture in NGN (Next Generation Network) environment and is specific to NGN.

Scope

- Functional architecture of multi-connection in terms of the overall functional

requirements and the high-level overview of the multi-connection framework itself in NGN environment

Note: Multi connection is the functionality which provides the user equipment (UE) and network with the capability to maintain more than one access network connection simultaneously

Study Report on IoT Reference Architectures/Frameworks

Overview of multi-connection architecture

2.6 ITU-T Y.2063 (Framework of the web of things – Published in

2012)

This document explains the WoT Framework as three layers in abstract level; service layer, adaption layer and physical layer and functional entities in each layer are described. WoT is very similar to IoT where Web technologies are applied

Scope

- Overview of the WoT

- Requirements to support the WoT - Deployment models of the WoT - Functional architecture for the WoT

Study Report on IoT Reference Architectures/Frameworks

Study Report on IoT Reference Architectures/Frameworks

Functional architecture of the WoT broker

2.7 ITU-T F.744 (Service description and requirements for

ubiquitous sensor network middleware – Published in 2009)

This document explains functional model of USN middleware.

Scope

 Description of USN services and USN middleware  Use cases of USN services which use USN middleware  Functional model of USN middleware

 Requirements for USN middleware to support functions commonly required by USN services

Study Report on IoT Reference Architectures/Frameworks

<Functional model of USN middleware>

2.8 ITU-T F.771 (Service description and requirements for multimedia

information access triggered by tag-based identification– Published in 2008)

Scope

- Service description and the requirements for multimedia information access triggered by tag-based identification

High-level functional model of the multimedia information access triggered by tag-based identification

Study Report on IoT Reference Architectures/Frameworks

This document explains the functional model of multimedia information access triggered by tag-based identification as physical entity, ID tag (RFID or barcode), ID terminal, network and service functionality domain.

2.9 ITU-T H.621 (Architecture of a system for multimedia

information access triggered by tag-based identification – Published

in 2008)

This document explains functional architecture of multimedia information access triggered by tag-based identification

Scope

 Functional architecture reference model with descriptions of corresponding elements;  Interface protocols between communication elements; and

 Generic work flow to support multimedia information access triggered by tag-based identification.

 Implementation examples with work flows

Study Report on IoT Reference Architectures/Frameworks

Interfaces between components in functional architecture

2.10 ITU-T Y.gw-IoT-arch (Functional architecture of gateway for IoT

applications – under development)

Scope

 Functional architecture of gateway for IoT applications  Functional entities of gateway for IoT applications  Reference points of gateway for IoT applications

Study Report on IoT Reference Architectures/Frameworks

Support Capabilities Group Application Group

Adaptation Capabilities Group

Devices Networks Applications Platforms

Gateway

<Reference functional architecture of Gateway for IoT application> Relevancy to IoT Reference Architecture: High/Medium/Low/None

This document defines functional architecture of gateway for IoT applications and describes functional entities of IoT gateway. If IoT gateway is defined in IoT Reference Architecture, this functional architecture of IoT gateway can be referenced.

2.11 ITU-T Y.IoT-funct-framework (IoT functional framework and

capabilities– under development)

The IoT functional framework in this Recommendation refers to the IoT capability framework, which consists of groups of IoT capabilities. The elements of the IoT functional framework in this Recommendation are used to be represented by the groups of IoT capabilities, simply called the IoT functional groups. The classification of the IoT functional groups is based on the functional categories of IoT common requirements, such as application support requirements, service requirements, data management requirements, device requirements, communication requirements, security and privacy protection requirements.

Study Report on IoT Reference Architectures/Frameworks

elements

- Associated capabilities

- Security considerations for the IoT functional framework and associated capabilities Remarkable Figures Application Support Service Provision Data management Thing connectivity Communication System management Security and privacy protection

<IoT functional framework: IoT functional groups>

2.12 ITU-T Y.2066 Common Requirements of the Internet of Things

These requirements are based on general use cases of the IoT and IoT actors, which are built from the definition of IoT contained in [ITU-T Y.2060]. The common requirements of the IoT are independent of any specific application domain, which refer to the areas of knowledge or activity applied for one specific economic, commercial, social or administrative scope, such as transport application domain and health application domain.

The Recommendation builds on the overview of IoT [ITU-T Y.2060], developing the common requirements based on general use cases of the IoT and the IoT actors, and taking into account important areas of consideration from a requirement perspective. Some representative use cases of the IoT, which are abstracted from application domains, are also provided. The common requirements of the IoT specified in this Recommendation are classified into the categories of non-functional requirements, application support requirements, service requirements,

communication requirements, device requirements, data management requirements, and security and privacy protection requirements.