Study Report on IoT Reference Architectures/Frameworks

Transcription

1 Contents 1. Background Introduction Requirements for IoT Reference Architecture General requirements for IoT Reference Architecture Application specific requirements for IoT Reference Architecture Examples of requirements only needed or critical in specific applications are Example of a specific set of requirements for a specific application domain: those identified for sensor web applications Example of how generic requirements lead to a specific set of requirements for a specific application domain - those identified for security Identified differences in RAs studied (i.e. limitations, suitability for different applications) Classification of requirements Conclusion Annex 1: Architecture and Framework documents JTC 1 Standards ISO/IEC Information Technology Sensor networks Sensor Network Reference Architecture (SNRA) ISO/IEC :2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 1: General overview and requirements ISO/IEC :2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 2: Vocabulary and terminology ISO/IEC : Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 3: Reference architecture views ISO/IEC : 2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 4: Entity models ISO/IEC :2013 Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 5: Interface Definitions ISO/IEC : Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 6: Applications ISO/IEC : Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 7: Interoperability Guidelines ISO/IEC TR Information technology -- Future Network -- Problem statement and requirements ISO/IEC TR :2012 General Aspects ISO/IEC TR : Naming and Addressing (currently DTR) ISO/IEC TR :2013 Switching and Routing ISO/IEC TR :2013 Mobility ISO/IEC TR Security (currently DTR) ISO/IEC TR :2013 Media Distribution ISO/IEC TR :2013 Service Composition JTC 1 Home Electronic Systems (HES) related activities Background

2 1.3.2 UPnP architecture (see Device architecture document Oct 2008 and ISO/IEC series) JTC 1 SC29 Media Context and control ISO/IEC :2014 Information technology -- Media context and control -- Part 1: Architecture ISO/IEC :2013 Information technology -- Media context and control -- Part 2: Architecture ISO/IEC :2013 Information technology -- Media context and control -- Part 3: Sensory Information ISO/IEC :2013 Information technology -- Media context and control -- Part 4: Virtual World Object characteristics ISO/IEC :2013 Information technology -- Media context and control -- Part 5: Data formats for interaction devices ISO/IEC :2013 Information technology -- Media context and control -- Part 6: Common types and tools ISO/IEC :2014 Information technology -- Media context and control -- Part 7: Conformance and reference software Other JTC 1 activities related to IoT JTC 1 WG 7 on Sensor Network s NWIP JTC1 N12087 IoT Reference Architecture Exploratory work in a number of JTC 1 SCs ITU-T recommendations ITU-T Y.2060 (Overview of the Internet of things Published in 2012) ITU-T Y.2069 (Terms and definitions for the Internet of things Published in 2012) ITU-T Y.2061 (Requirements for the support of machine oriented communication applications in the next generation network environment Published in 2012) ITU-T Y.2080 (Functional architecture for distributed service networking Published in 2012) ITU-T Y.2027 (Functional architecture of multi-connection Published in 2012) ITU-T Y.2063 (Framework of the web of things Published in 2012) ITU-T F.744 (Service description and requirements for ubiquitous sensor network middleware Published in 2009) ITU-T F.771 (Service description and requirements for multimedia information access triggered by tag-based identification Published in 2008) ITU-T H.621 (Architecture of a system for multimedia information access triggered by tag-based identification Published in 2008) ITU-T Y.gw-IoT-arch (Functional architecture of gateway for IoT applications under development) ITU-T Y.IoT-funct-framework (IoT functional framework and capabilities under development) ITU-T Y.2066 Common Requirements of the Internet of Things ETSI ETSI TS : Machine-to-Machine communications (M2M); Functional architecture

3 Functional architecture GS GS1 EPCglobal Architecture Framework OGC OGC Sensor Web for IoT IEC IEC PAS The universaal Framework for User Interaction in Multimedia Ambient Assisted Living (AAL) Spaces Relevant Research Projects and Deliverables project June 2013: IoT-a Project: website: IOT-I Internet of Things Initiative Thing Architecture: See Weightless Bluetooth Smart and Mesh Korean RA work overview Study on IoT Reference Architecture IEEE P Other RA diagrams provided as additional information Annex 2: IoT Requirements mapping used to develop requirements section 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 23 rd January and 10 th February and reported to the fourth meeting of the SWG in Chongqing, China from 18 th -20th March 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

4 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 ( 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. 4

5 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 1. Regulation Compliance 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. 8. Usability 5

6 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 welldefined, 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, usercustomized 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. 6

7 17. Modularity 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 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. 3. Human Body Connectivity 7

8 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 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 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: 8

9 Data Protection and Integrity 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 Accessibility and usage conditions 9

10 Flexibility of design 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; Security and privacy protection requirements 10

11 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 crosscommittee 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. 11

12 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 Information Technology Sensor networks Sensor Network Reference Architecture (SNRA) The 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 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 series are described below ISO/IEC :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 ISO/IEC :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. 12

13 1.1.3 ISO/IEC : Information technology -- Sensor networks: Sensor Network Reference Architecture (SNRA) -- Part 3: Reference architecture views ISO/IEC :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 :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: Device Management Service Domain Data Mining CIP Data Fusion Others Data Processing Data Storage Information Communication Information Provisioning Service Management Security Management Business Management User Management Network Domain Local Area Networks Wide Area Network Data Communication Security Management Service Management Sensing Domain Data Acquisition Data Storage CIP Data Fusion Feature Extraction Data Aggregation Others Communication Protocol Stack Communication Support functions Device Management Service Management Security Management Network Management Data Processing Data Communication Feedback & Control Data, Information, & Communications Control & Management Figure 1- Sensor network functional architecture 13

14 Figure 2- Physical operation activity model ISO/IEC : 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). 14

15 Figure 3- Functional entities of a sensor network ISO/IEC :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. Figure 4 depicts all the interfaces addressed in this part. 15

16 Interface 1 User Service provider Application Layer Interface 2 Cross- Layer Manag ement Interface - CLM/AL- SL-BFL Interface - SL/AL* Service Layer Interface - BFL/SL* Basic Functions Layer Interface HL/BFL* Sensor Node Hardware Layer Interface 3 Backbone Network Gateway node Interface 4 *Colored boxes represent SN interfaces Interface 5 Sensor node Figure 4- Various interfaces of a sensor network ISO/IEC : 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 ISO/IEC : 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. 16

17 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 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 SC6 has collaborated with ITU-T SG13, SG17 and SG2 in the development of the FN work. 17

18 Figure 7: General Concept of FN ISO/IEC TR :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 ISO/IEC TR : 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 ISO/IEC TR :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. 18

19 1.2.4 ISO/IEC TR :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 :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 ISO/IEC TR 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 ISO/IEC TR :2013 Media Distribution Part 6 describes the problem statement and requirements for the Future Network in the perspective of media transport. ISO/IEC TR :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 ISO/IEC TR :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 :2013 also introduces various on-going standardization and research activities related to service composition. 1.3 JTC 1 Home Electronic Systems (HES) related activities 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. 19

20 Wireless and power line carrier technologies are facilitating the introduction of networks into existing homes. Home networks can support the emerging market for televisions with Internet connectivity to receive Internet TV (IPTV). Homes are increasingly equipped with home systems meeting HES standards ISO/IEC 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 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 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 y that specifies comparable functions UPnP architecture (see Device architecture document Oct 2008 and ISO/IEC 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, 20

21 and learn about the presence and capabilities of other devices. Finally, a device can leave a network smoothly and automatically without leaving any unwanted state behind. 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. 21

22 1.4 JTC 1 SC29 Media Context and control ISO/IEC :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 ISO/IEC :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. 22

23 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 ISO/IEC :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. 23

24 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. 24

25 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 ISO/IEC :2013 Information technology -- Media context and control -- Part 4: Virtual World Object characteristics ISO/IEC :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 ISO/IEC :2013 Information technology -- Media context and control -- Part 5: Data formats for interaction devices ISO/IEC :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 ISO/IEC :2013 Information technology -- Media context and control -- Part 6: Common types and tools ISO/IEC :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 are also defined in Annex A of ISO/IEC :2013. Other tools to be developed are included in ISO/IEC :2013, if those tools are to be used with the tools defined in more than one 25

26 part of ISO/IEC Most of the tools defined in ISO/IEC :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 ISO/IEC :2014 Information technology -- Media context and control -- Part 7: Conformance and reference software ISO/IEC :2014 specifies the conformance and reference software implementing the normative clauses of all parts of ISO/IEC 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 Furthermore, ISO/IEC :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 and informative descriptions thereof. 1.5 Other JTC 1 activities related to IoT 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 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 - High-level requirements of the IoT and IoT reference models 26

27 - Figure 8: IoT Reference Model Application customer Platform provider Application provider 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. 27

28 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 Network overview for the support of MOC applications in the NGN environment 28

29 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 29

30 DSN Functional Architecture 30

31 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 31

32 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 32

33 Overview of the web of things architecture 33

34 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 34

35 <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 35

36 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 <Functional architecture> 36

37 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 37

38 AAI Gateway Applications Application Group ASI Platforms PSI Support Capabilities Group SAI Adaptation Capabilities Group ADI ANI Devices Networks <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 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. Scope 38

39 - Elements of the IoT functional framework, and the relationships among these elements - Associated capabilities - Security considerations for the IoT functional framework and associated capabilities Remarkable Figures Service Provision Data management Application Support System management Thing connectivity Security and privacy protection Communication <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. 39

40 3. ETSI 3.1 ETSI TS : Machine-to-Machine communications (M2M); Functional architecture. This specification describes the end-to-end onem2m functional architecture, including the description of the functional entities and associated reference points. onem2m functional architecture has its focus on the Service Layer aspects and takes Underlying Networkindependent view of the end-to-end services. The Underlying Network is used for the transport of data and potentially for other services. Functional architecture Application Common Services Underlying Network Services The onem2m functional architecture in comprises of the following functions: 1. Application Entity (AE): Application Entity provides Application logic for the end-to-end M2M solutions. Examples of the Application Entities can be fleet tracking application, remote blood sugar monitoring application, or remote power metering and controlling application. 2. Common Services Entity (CSE): A Common Services Entity comprises the set of "service functions" that are common to the M2M environments and specified by onem2m. Such service functions are exposed to other entities through Reference Points Mca and Mcc. Reference point Mcn is used for accessing Underlying Network Service Entities. Examples of service functions offered by CSE are: Data Management, Device Management, M2M Subscription Management, Location Services etc. Such "sub-functions" offered by a CSE may be logically apprehended as Common Services Functions (CSFs). Inside a Common Services Entity (CSE), some of the CSFs can be mandatory and others can be optional. Also, inside a CSF, some sub-functions can be mandatory or optional (e.g., inside a "Device Management" CSF, some of the sub-functions like "Application Software Installation," "Firmware Updates," "Logging," "Monitoring," etc. can be mandatory or optional). 3. Underlying Network Services Entity (NSE): An Underlying Network Services Entity provides services to the CSEs. Examples of such services include device management, location services and device triggering. No particular organization of the NSEs is assumed. NOTE: Underlying Networks provide data transport services between entities in the onem2m System. Such data transport services are not included in the NSE. 40

41 Service functions provided by the Common Services Layer that are common to the onem2m environment are referred to as Common Service Functions (CSFs). The CSFs provide services to the Applications to other Common Service Entities (CSEs). An instantiation of a CSE in a Node comprises a subset of the CSFs from the CSFs described herein. Common Services Entity (CSE) Application Entity (AE) Mca Reference Point Application and Service Layer Management Security Service Session Management Service Charging & Accounting Data Management & Repository Communication Management/ Delivery Handling Device Management Discovery Location Registration Subscription Notification Network Service Exposure/Service Ex+Triggering Mcc Reference Point Group Management Mcn Reference Point Underlying Network Service Entity (NSE) The Application and Service Layer Management (ASM) CSF is responsible for providing management of AEs and CSEs on the Application Dedicated Nodes, Application Service Nodes, Middle Nodes and Infrastructure Nodes. This includes functions to configure, troubleshoot and upgrade the functions of the CSE as well as upgrade the AEs. The Communication Management and Delivery Handling (CMDH) CSF is responsible for providing communications with other CSEs, AEs and NSEs.The CMDH CSF is responsible to decide at what time which communication connection to use for delivering communication (e.g. CSE-to-CSE communication) and, when needed and allowed, store communication requests so that they can be forwarded at a later time. This processing in the CMDH CSF has to be carried out in line with the provisioned policies and delivery handling parameters that can be specific to each request for communication. For communication using the Underlying Network data transport services, the Underlying Network can support the equivalent delivery handling functionality. In such case the CMDH CSFis able to use the Underlying Network, and it may act as a front end to access the Underlying Network equivalent delivery handling functionality. 41

42 One of the goals of onem2m CSEs is to enable M2M Applications to exchange data with each other. Data Management and Repository (DMR) CSF is responsible for providing data storage and mediation functions. It includes the capability of collecting and aggregating large amounts of data, converting this data into a specified format, and storing it for analytics and semantic processing. The "data" can be either raw data transparently retrieved from an M2M Device, or processed data which is calculated and/or aggregated by M2M entities. This collection of large amounts of data constitutes what is known as the Big Data Repository functionality. The Device Management (DMG) CSF is responsible for providing management of device capabilities on Middle Nodes (M2M Gateways), Application Service Nodes and Application Dedicated Nodes (M2M Devices) as well as devices that reside within an M2M Area network. Application Entities(AE) can manage the device capabilities on those Nodes by using the services provided by DMG CSF, and AE does not need to be aware of the management technology specific knowledge. However, management technology specific knowledge might be exposed to the AE for administrative purposes (diagnostics and troubleshooting etc.). Discovery (DIS) CSF is responsible for searching information e.g., supported attributes and resources according to a Request from an Originator within a given scope and subject to permissions, including those allowed by M2M service subscription. An Originator could be an Application or another CSE. The scope of the search could be in one CSE, or in more than one CSE. The discovery results are returned back to the Originator. Group Management (GMG) CSF is responsible for handling Group related requests. The request is sent for the management of a Group and its membership as well as for the bulk operations supported by the Group. When adding or removing members to/from a Group, it is necessary to validate if the member complies with the purpose of the Group. Bulk operations includes read, write, subscribe, notify, device management, etc. Whenever a request or a subscription is made via the Group, the Group is responsible for aggregating its responses and notifications. The members of a Group can have the same role with regards to access rights control towards a resource. In this case, access control is facilitated by grouping. When the Underlying Network provides broadcasting and multicasting capability, the GMG CSF is able to utilize such capability. The Location (LOC) CSF allows M2M AEs to obtain geographical location information of M2M Nodes (e.g., ASN, MN) for location-based services. Such location information requests may be from an M2M AE residing on either a local Node or a remote Node. NOTE: Geographical location information can be more than simply the longitude and the latitude information. Network Service Exposure, Service Execution and Triggering (NSSE) CSF manages communications with the Underlying Networks for accessing network service functions over the Mcn reference point. The NSSE CSF uses the available/supported 42

43 methods for service "requests" on behalf of M2M Applications. The NSSE CSF shields other CSFs and AEs from the specific technologies and mechanisms supported by the Underlying Networks. NOTE: The NSSE CSF provides adaptation for different set of network service functions supported by various Underlying Networks. Registration (REG) CSF is responsible for handling an Application or another CSE to register with a CSE in order to allow the registered entities to use the services offered by the registered-with CSE. The REG CSF handles registration of a Device also, so as to allow registration of Device's properties/attributes with the CSE. Security (SEC) CSF comprises the following functionalities: Sensitive Data Handling functionality; Security Administration functionality; Security Association Establishment functionality; Authorization and Access Control functionality; Identity Protection Functionality. Sensitive Data Handling functionality in the SEC CSF protects the local credentials on which security relies during storage and manipulation. Sensitive Data Handling functionality performs other sensitive functions as well such as security algorithms. This functionality is able to support several cryptographically separated security environments. Security Administration functionality enables services such as the following: Creation and administration of dedicated security environment supported by Sensitive Data Handling functionality; Post-provisioning of a root credential protected by the security environment; Provisioning and administration of subscriptions related to M2M services and M2M application services. Security Association Establishment functionality is responsible for establishing security association between corresponding M2M nodes, in order to provide services such as confidentiality, integrity, authentication, authorization, etc. Authorization and Access Control functionality is responsible for authorizing services and data access to authenticated entities, according to provisioned security policies and assigned roles. While unique identifier of an entity are used for authentication, the Identity Protection functionality provides pseudonyms which serve as temporary identifiers which cannot be linked to the true identity of either the associated entity or its user. Service Charging and Accounting (SCA) CSF provides charging functions for the Service Layer. It supports different charging models which include online charging and offline charging. The SCA CSF is responsible for capturing chargeable events, recording of information, generating charging records and charging information. The SCA CSF can interact with the charging System in the Underlying Network also. But the SCA CSF is responsible for generating and recording of the final service level charging information. It is the responsibility of the SCA CSF in the Infrastructure 43

44 Node or the Service Layer Charging Server to handle the charging information for the purpose of charging. An M2M service session is an end-to-end Service Layer connection managed by the Service Session Management (SSM) CSF. The SSM CSF manages M2M service sessions between M2M Applications, between an M2M Application and a CSE, or between CSEs. The management of a M2M service session includes capabilities such as the management of session state, session authentication and establishment, management of Underlying Network connections and services related to the session, coordination of sessions spanning multiple hops of CSEs, exchange of information between session endpoints, and session termination. The SSM CSF uses the CMDH CSF within its local CSE for sending/receiving messages to/from the next-hop CSE or to/from an Application for a given M2M service session. The SSM CSF also uses the SEC CSF for the management of session related security credentials and authentication of session participants. The SSM CSF generates session specific charging events also that it communicates to the SCA CSF within its local CSE. The Subscription and Notification (SUB) CSF is responsible for providing notifications pertaining to a subscription that tracks changes on a resource (e.g., deletion of a resource). A subscription to a resource is initiated by an AE or a CSE, and is granted by the Hosting CSE subject to access rights. During an active subscription, the Hosting CSE sends a notification per modification of the resource to the address(es) where the resource subscriber wants to receive it. 4. GS1 4.1 GS1 EPCglobal Architecture Framework The GS1 EPCglobal Architecture Framework is a collection of hardware, software, and data standards, together with shared network services that can be operated by GS1, its delegates or third party providers in the marketplace to enable accurate, immediate and cost-effective visibility of information throughout the supply chain. A fundamental principle of the EPCglobal Architecture Framework is the assignment of a unique identity to physical objects, loads, locations, assets, and other entities whose use is to be tracked. The EPCglobal Architecture Framework is decentralized, meaning that logically centralized functions are distributed among multiple facilities, each serving an individual End User or group of End Users. In some cases, certain of these facilities are operated by End Users themselves. EPCglobal software standards are, whenever possible, defined using a layered approach. In this approach, the abstract content of data and/or services is defined using a technology-neutral description language such as UML. Separately, the abstract specifications are given one or more bindings to specific implementation technology such as XML, web services, and so forth. The EPCglobal Architecture Framework explicitly recognizes the fact that change is inevitable. A general design principle for all EPCglobal Standards is openness to extension. Extensions 44

45 include both enhancements to the standards themselves, through the introduction of new versions of a standard, and extensions made by a particular enterprise, group of cooperating enterprises, or industry vertical, to address specific needs that are not appropriate to address in an EPCglobal standard. Roles and Interfaces of a typical system architecture The plain green bars in the diagram below denote interfaces governed by EPCglobal standards, while the blue shadowed boxes denote roles played by hardware and software components. 45

46 EPC Network Services Discovery Services (In Development) (In Development) ONS Root ONS I face Manager Number Assignment (offline service) Tag Data Translation Definition File End User ONS Interface Partner End User EPCIS Accessing Application Local ONS EPCIS Accessing Application Pull or Push mode EPCIS Query Interface Pull or Push mode Optional bypass for real-time push EPCIS Repository EPC Core Business Vocabulary (Data Spec.) Legend EPCIS Capture Interface = HW/SW Role EPCIS Capturing Application From non-rfid data carriers Filtering & Collection (ALE) Interface = Interface or Data Specification (EPCglobal Standard) Filtering &Collection Reader Interface ALE Tag Memory, Logical Reader, and Access Control APIs From non- Gen2 Tags RFID Reader Reader Management Interface Reader Management EPC Tag Data Specification Tag Air Interface (UHF Class 1 Gen 2, et al) RFID Tag 46

47 5. OGC 5.1 OGC Sensor Web for IoT See Sensor Web for IoT Requirements Quickly discover sensors and sensor data (secure or public) that can meet my needs Therefore location, observables, quality, ability to task Obtain sensor information in a standard encoding that is understandable by me and my software Readily access sensor observations in a common manner, and in a form specific to my needs Task sensors, when possible, to meet my specific needs Subscribe to and receive alerts when a sensor measures a particular phenomenon 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 OGC Sensor Things API Status o Current draft on GitHub o o o o o a reference service implementation ready a simple client ready a.net Micro Framework ready (Netduino) a JavaScript library almost ready an Interactive SDK ready 47

48 6. IEC 6.1 IEC PAS The universaal Framework for User Interaction in Multimedia Ambient Assisted Living (AAL) Spaces The universaal UI Framework for Multimedia AAL spaces is based on separating the application layer from the presentation layer by introducing (1) a new type of software components called UI handlers and (2) a brokerage mechanism between the application and presentation layers. The goal is to achieve an open system in which arbitrary applications as well as UI handlers can be plugged in independently from each other while enabling applications to benefit from support for multimodal interaction both by the framework itself and by the UI handlers. A Smart environment is an environment centred on its human users in which a set of embedded networked artefacts, both hardware (HW) and software (SW), collectively realize the paradigm of Ambient Intelligence, mainly by providing for contextawareness and personalization, adaptive reactivity, and anticipatory pro-activity. Figure illustrating the concept of a smart environment 48

49 Devices in an overall system 7. Relevant Research Projects and Deliverables 7.1 project June 2013: The project focused on employing IoT technologies in industrial and automation environments, a communication and middleware infrastructure for self-managing resilient networks employing middleware and service oriented application architectures was piloted in an IoTbased plug and work concept centred on industrial automation. Projects conclusions are that IoT architecture and technologies developed in the project can facilitate and reduce interruption time of production line during the Plug&Work bootstrapping of devices in new factories and also that IoT architecture & technologies are expected to provide the relevant breakthroughs along the management cycle of automated production lines enabling advanced monitoring and prediction of tool failure. IoT@Work architecture is targeted at three basic layers, a layer for device and network embedded services, a layer for resource creation and management, and an application level middleware layer. The architecture is structured around Three primary Functional Horizontal Layers and 49

50 Three Vertical Planes (Communications, Security. Management) submitted.pdf Integrated technology structure is organized around seven functional activities: 1) Directory Service - The directory service links all the services to the devices, while hiding underlying standards and protocols. a. 50

51 2) Real-Time Ethernet Auto-configuration IP address assignment, Discovery of the new device and submission of a URL to the Device Description File (DDF), DDF retrieval and parsing, Real-time Ethernet specific configuration a. 3) Event Dispatching (Event Notification Service) - The Event Notification Service is a middleware component that acts as a flexible and scalable connector among event sources and event consumers a. 4) Capability-Based Access Control - access right delegation, capability tokens revocation, fine grained access rights. 5) Event Processing - intelligent processing of messages, e.g. to analyze faults, predictive maintenance, etc. a. 6) Network Slices - network virtualization, resource management, policy control, and auto-configuration. a. 7) Access Control - Network Access Control (NAC) providing secure Plug & Work and secure communication, supporting a secure device bootstrapping architecture a. 51

52 7.2 IoT-a Project: website: Doc # Document Name Brief Description D _D1_1_Final.pdf SOTA report on existing integration frameworks/architectures for WSN, RFID and other emerging IoT related technologies wrt to requirements D1.2 D1.2_Initial_architectural_r Initial architectural reference model for the IoT - v0.9 eference_model_for_iot.pd f ARM IoT-A ARM Book Introduction v7.pdf Architectural Reference Model for the IoT - (ARM) Introduction Booklet D1.3 D1.3_Architectural_Referen Architectural Reference Model for the IoT (updated) ce_model_update.pdf D1.4 D1.4_Converged_Architect ural_reference_model[14.1 Converged Architectural Reference Model for the IoT v2.0 52

53 Doc # Document Name Brief Description 1.12].pdf D2.1 D2.1_FINAL.pdf Resource Description Specification D2.2 D2.2_Concepts for Concepts for Modeling IoT-Aware Processes Modeling IoT-Aware Processes.pdf D2.3 D2.3_Orchestration of Orchestration of distributed IoT service interactions distributed IoT service interactions.pdf D2.5 D2.5.pdf Adaptive, fault-tolerant orchestration of distributed IoT service interactions D3.1 D3_1_Initial_M2M_Analys Initial M2M API Analysis is.pdf D3.3 D3.3_InitialProtocolDesign. Initial IOTP Protocol Suite definition pdf D4.1 D4.1-LookupResourceIDv1.02_DM.pdf Concepts and Solutions for Identification and Lookup of IoT Resources D4.2 D4.2_final-2_DM.pdf Concepts and Solutions for Privacy and Security in the Resolution Infrastructure D4.3 D4.3_V1.02_DM.pdf Concepts and Solutions for Entity-based Discovery of IoT Resources and Managing their Dynamic Associations D6.2 D6.2_Updated Updated Requirements List Requirements List.pdf D6.6 IoT-A_Deliverable_6.6.pdf Report on Stakeholder opinions D8.1 D8.1_Information Flyer.pdf Information Flyer Key documents for SWG-IoT are highlighted D1.1 SOTA Report on Existing Integration Frameworks/Architecture for WSN, RFID and Other Emerging IoT Related Technologies has sections on Section 1: The existing architecture and framework solutions Section 2: The latest modelling techniques for IoT Section 3: A survey on the communication protocols Section 4: Identification and resolution framework Section 5: An overview of the available IoT object platforms. Section 6: A security and privacy 6 commercial products (ZigBee, ZigBee Smart Energy v2.0, WirelessHart, Sensinode, SunSpot, QT Code) were evaluated for their integration aspects to IoT architecture. Standardization activities evaluated for architecture relevance were: ETSI TC M2M ITU-T USN (Ubiquitous Sensor Networks) ISO/IEC JTC 1 WG7 (Working Group on Sensor Networks) OGC SWE (Sensor Web Enablement) 53

54 IETF (constrained devices) EPCglobal Network Architecture REST Architecture Web Service Architecture D1.3 is an updated version of D1.2 and provides an updated architecture reference model. D1.2 was delivered on 16 June 2011, and D1.3 was delivered on 16 June D1.3 is organized with the following contents: Section 1: Executive summary Section 2: Introduction Section 3: Reference model Section 4: Reference architecture Section 5: Best practices Section 6: Conclusions and outlooks Appendix A Terminology Appendix B Requirements Appendix C Use cases, sequence charts and interfaces Among the contents of D1.3, Sections3and 4 are of the key JTC 1 SWG 5 AHG 4 s interest. Additionally, the requirements listed in Appendix B will be beneficial for the IoT reference architecture standard development in ISO/IEC JTC 1. Discourse/General Concerns Identifies abstract quality concepts that have to be taken into account for the realization of IoT systems. Domain Model [D1.2] Summarizes concepts and entities that represent particular aspects of the IoT domain and a top-level domain description and their relations are defined. The domain model also serves as a common lexicon for and taxonomy of the IoT. Generally, entities in a domain model are either responsible for keeping track of certain information and for doing certain things. This refers to knowledge and behavior, respectively. [D1.3] Introduces the main concepts of the IoT and the 54

55 relations between these concepts. The abstraction level has been chosen in such a way that the concepts are independent of specific technologies and are invariant, i.e. are not expected to change over time. Information Model [D1.2] Represents the knowledge. Its purpose is to specify the data semantics of the domain model. [D1.3] Defines the structure (e.g. relations, attributes) of all the information (data) that is handled in an IoT system on a conceptual level. So the information pertaining to those concepts of the Domain Model is modelled, which is explicitly gathered, stored and processed in an IoT system. Communication Model [D1.2] Addresses high-level communication paradigms pertinent to the IoT domain. The communication model presented describes how communication has to be managed in order to achieve the features required in the IoT. [D1.3] Introduces concepts for handling the complexity of communication in heterogeneous IoT environments. Communication also constitutes one Functionality Group in the Functional Model. Functional Model Identifies groups of functionalities that are in most cases centered around key concepts of the Domain Model. A number of these Functional Groups (FG) build one on top of the other, following the relations identified in the Domain Model. The Functional Group then provides the functionalities for interacting with the instances of these concepts or managing the information related to the concepts. The functionalities managing information use the Information Model as the basis for structuring their information. Security and Privacy Are of paramount importance in typical IoT environments. Therefore, the relevant functionalities and their interdependencies and interactions are introduced in the Security Model. As in the case of communication, security constitutes one Functionality Group in the Functional Model. D1.3 is then further details each of the bullet items above., the discussions about the IoT Domain are on heterogeneity, interoperability, scalability, manageability, mobility, security & privacy, reliability, changes (or adaptation/adaptation of new technologies) and evolution. 55

56 IoT Functional Model 7.3 IOT-I Internet of Things Initiative The Internet of Things (IoT) is one of the most important areas of a Future Internet with high potential to positively impact European economy and society. The IoT initiative (IoT-i), a EU Framework Programme 7 project, started in September 2010, brings together key actors from all relevant but currently fragmented IoT communities in Europe to work jointly towards a common vision of the Internet of Things. It represents the first serious attempt in building a unified IoT community in Europe, going across boundaries of disparate technology sectors, in order to create a joint European strategic vision of the Internet of Things and aligning this vision with the current developments on the Future Internet. IoT-i pursues the achievement of the following strategic objectives: Creating a joint strategic and technical vision for the IoT in Europe that encompasses the currently fragmented sectors of the IoT domain holistically. Contributing to the creation of an economically sustainable and socially acceptable environment in Europe for IoT technologies and respective R&D activities. Creating an environment that favours international adoption of European IoT technology. There are a large number of informative deliverables including: D1.1 "Knowledge-base capturing the state-of-the-art in IoT Research" This document explains about the database created and accessible at The database is publically available and it lets you search for organizations involved in the IoT and what they are doing. D1.4 "Final Report on the State-of-the-Art in IoT Research" There are two tasks within the IOT-i roadmap that are concerned with the IoT Database. The first one is Task 1.1, which aims at capturing the State of the Art (SotA) in IoT research. The second task (T4.1) deals with the IoT community building activities. We have decided to capture the results of those two tasks into a single Knowledge base. It therefore offers a collection of important pieces of contents on one hand and an as exhaustive as possible snapshot of the IoT community people/projects/companies on the other hand. This will be thoroughly explained later on.d1.4 (this deliverable) represents the version 2 of D1.1 and provides an analysis of the content of the database SotA- wise. D1.5 "Final White Paper defining a Reference Model for IoT" (update D1.2) The Internet of Things (IoT) is a hot topic in R&D today. However, there is still a lack of understanding of what the term means and what constitutes the IoT.A commonly accepted reference model would alleviate this problem. A detailed survey on IoT Reference Models showed the desire of the community to have such a model, and what such a model should contain. Taking these into account, this document is proposing to establish the model developed by the IoTA project as a common IoT Reference Model. D1.6 "Final Analysis of Existing IoT Strategic research directions and priorities" (SRA v2) The Strategic Research Agenda ( SRA ) of the European Research Cluster for the Internet of Things ( IERC ) shall cover the important issues and challenges for the Internet of Things ( IoT ) technology. It shall provide the vision and the roadmap for coordinating and 56

57 rationalizing current and future research and development efforts in this field by addressing the different enabling technologies covered by the Internet of Things concept and paradigm. D2.1 "Initial report on IoT applications of strategic interest"(1.5 MB) The range and diversity of IoT applications is huge, permeating through practically all aspects of everyday life. This report presents the results of the IOT-i s initial efforts to systematically organise IoT scenarios designed, proposed and analysed by several research projects (FP6 and FP7) and then to collect feedback from a variety of communities about the scenarios. In particular, we were interested to find out which scenarios people consider the most important from the societal and business aspect as well as how mature the scenarios are (from the market and technology points of view). Report is updated in D2.3 "(Final) Report on IoT Applications of Strategic Interest" which describes the business analysis of 17 strategic application scenarios for the Internet of Things based on scenarios described in the IoT-I deliverable D.2.1 Initial report on IoT applications of strategic interest 1 and the IoT comic book special edition The IoT-I s most relevant paper to this adhoc is the work presented in D1.5 IoT Reference Model White Paper. This white paper is proposing to establish the model developed by the IoTA project as a common IoT Reference Model. This IoT Reference Model contains all the components that a reference model should contain: a domain model, that not only provides terminology definition, but also identifies all important concepts and the relationships between them; an information model defining the structure on a conceptual level of all information handled by an IoT system; a communication model showing the different communication paradigms, as well as a security model. The white paper discusses four models for the reference model: Domain Model 57

58 Information Model Communications Model Security, Trust, and Privacy Model The white paper discusses the validation of these models with models from other organizations and common IoT application scenarios. The paper concludes that the IoT reference model developed by IoT-A validates against all other existing models and architectures as well as common IoT scenarios and use cases. It concludes that: Thus, the IoT Reference Model as presented in this document provides a foundation for a commonly accepted model. While technically sound and reflecting current knowledge and understanding of the topic, the model will only be accepted widely if it is useful in developing interoperable solutions. 8. Thing Architecture: See An Open Source Code solution Home Automation (HA) should revolve around rules in which things observe events, and in response other things perform tasks. Of course, it's up to the home-owner to define the rules. In the old days, a 'steward' was a trusted servant who ran the household on behalf of the homeowner. The home-owner set the rules and the steward was responsible for seeing that they were faithfully implemented. The steward is at the heart of the thing system and connects to things in your home, and allows them to connect to one another. There are three different protocols that the steward uses to communicate with a thing, native protocols (e.g. Zigbee, DASH7, Z-Wave, device specific protocols etc.), Simple Thing Protocol and Thing Sensor Reporting Protocol. Basic architecture diagram: 58

59 Thing Sensor Reporting Protocol (TSRP). If a thing needs to report sensor readings, or an event happening, to the steward it can implement the TSRP. This is a simple multicast UDP based protocol All transmissions are uni-directional, from the thing to the steward. All transmissions are via UDP to port on multicast address ' '. All messages are in JSON. All messages have a requestid parameter, which is a non-empty string. For design cleanliness, each requestid value should be distinct from the previous one. All messages have a path parameter, which is always '/api/v1/thing/reporting'. Simple Thing Protocol 59