489594658-Unit-III-Iot architecture.pptx

Very good lecture note on IoT Architecture

1. IOT ARCHITECTURE UNIT - III

2. Topics to be Covered M2M high level architecture IETF architecture for IoT OGC architecture IoT reference model Domain model Information model Functional Communication model IoT reference architecture.

3. IoT An Architectural Overview Architecture refers to the description of the main conceptual elements, the actual elements of a target system, how they relate to each other, and principles for the design of the architecture Several Reference Architectures and Models exist both for M2M and IoT systems. The M2M system architectures are naturally more communication-oriented, while the IoT -related reference architectures and models are more holistic in their scope.

4. Cont… The term “reference architecture” relates to a generalized model that contains the richest set of elements and relations that are of relevance to the domain “Internet of Things.” The applied architecture is then the blueprint used to develop the actual system solution

5. Building an architecture Cont… An architecture can be described in several different views to capture specific properties that are of relevance to model, and the views chosen Functional view Deployment view Process view I nformation view

6. IoT architecture objective Design for reuse of deployed IoT resources across application domains well-defined service interfaces application programming interfaces ( APIs) are required to facilitate application development Design for ensuring trust, security, and privacy. Design for scalability, performance, and effectiveness. Design for evolvability , heterogeneity, and simplicity of integration Design for simplicity of management . Design for different service delivery models Design for lifecycle support

7. Standards considerations The primary objective of any technology oriented standardization activity is to provide a set of agreed-upon specifications that typically address issues like achieving interoperability in a market with many actors and suppliers Full Form of Standards Standards Development Organizations (SDO) International Telecommunications Union (ITU) International Standardization Organization (ISO) European Telecommunications Standards Institute (ETSI) European Committee for Electro technical Standardization (CENELEC) World Wide Web Consortium (W3C) Internet Engineering Task Force (IETF) Information and Communications Technology (ICT) 3rd Generation Partnership Project (3GPP) National Institute of Standards and Technology (NIST) Request For Comments (RFC)

8. ETSI The M2M system architectures are naturally more communication-oriented, while the IoT related reference architectures The European Telecommunications Standards Institute (ETSI) in 2009 formed a Technical Committee (TC) on M2M topics aimed at producing a set of standards for communication among machines from an end to- end viewpoint The technical committee consisted of representatives from telecom network operators, equipment vendors, administrations, research bodies, and specialist companies.

9. Cont… The ETSI M2M specifications are based on specifications from ETSI as well as other standardization bodies such as the IETF (Internet Engineering Task Force), 3GPP (3rd Generation Partnership Project), OMA (Open Mobile Alliance), and BBF (Broadband Forum). ETSI M2M produced the first release of the M2M standards in early 2012 In the middle of 2012 seven of the leading Information and Communications Technology(ICT) standards organizations (ARIB, TTC, ATIS, TIA, CCSA, ETSI,TTA) formed a global organization called oneM2M Partnership Project(oneM2M) in order to develop M2M specifications, promote the M2Mbusiness, and ensure the global functionality of M2M systems

10. ETSI- M2M High Level Architecture

11. ETSI- M2M high level architecture This high-level architecture is a combination of both a functional and topological view showing some functional groups (FG) clearly associated with pieces of physical infrastructure (e.g. M2M Devices, Gateways) There are two main domains, a network domain and a device and gateway domain. The boundary between these conceptually separated domains is the topological border between the physical devices and gateways and the physical communication infrastructure (Access network). The Device and Gateway Domain contains the following functional or topological entities:

12. Device and Gateway Domain M2M Device : This is the device of interest for an M2M scenario, for example, a device with a temperature sensor. An M2M device connects to the Network Domain either directly or through an M2M Gateway. M2M Area Network: This is typically a local area network (LAN) or a Personal Area Network (PAN) and provides connectivity between M2M Devices and M2M Gateways. M2M Gateway: The device that provides connectivity for M2M Devices in an M2M Area Network towards the Network Domain.

13. Network Domain Access Network: This is the network that allows the devices in the Device and Gateway Domain to communicate with the Core Network. Example Access Network Technologies are fixed ( xDSL , HFC) and wireless Satellite, GERAN, UTRAN, E-UTRAN W-LAN, WiMAX). Core Network: Examples of Core Networks are 3GPP Core Network and ETSI TISPAN Core Network. It provides the following functions: • IP connectivity. • Service and Network control. • Interconnection with other networks. • Roaming. M2M Service Capabilities: These are functions exposed to different M2M Applications through a set of open interfaces . M2M Applications: These are the specific M2M applications ( e.g. smart metering ) that utilize the M2M Service Capabilities through the open interfaces.

14. Cont… Network Management Functions: These are all the necessary functions to manage the Access and Core Network (e.g. Provisioning, Fault Management, etc.). M2M Management Functions: These are the necessary functions required to manage the M2M Service Capabilities on the Network Domain while the management of an M2M Device or Gateway is performed by specific M2M Service Capabilities.

15. SERVICE CAPABILITIES LAYER The SCL is a collection of functions that are exposed through the open interfaces or reference points mla , dla , and mld (ETSI M2M TC 2013b). Because the main topological entities that SCL can deploy are the Device, Gateway, and Network Domain. There are three types of SCL: 1. DSCL (Device Service Capabilities Layer), 2. GSCL (Gateway Service Capabilities Layer), 3. NSCL (Network Service Capabilities Layer).

16. ETSI M2M service capabilities

17. Cont… Application Enablement ( xAE ). The xAE service capability is an application facing functionality and typically provides the implementation of the respective interface Generic Communication ( xGC ). The NGC is the single point of contact for communication towards the GSCL and DSCL. It provides transport session establishment Reachability , Addressing, and Repository ( xRAR ). This is one of the main service capabilities of the ETSI M2M architecture. The NRAR hosts mappings of M2M Device and Gateway names to reachability information Communication Selection ( xCS ): This capability allows each xSCL to select the best possible communication network when there is more than one choice or when the current choice becomes unavailable due to communication errors. Remote Entity Management ( xREM ). The NREM provides management capabilities such as Configuration Management (CM) for M2M Devices and Gateways (e.g. installs management objects in device and gateways), collects performance management (PM) and Fault Management (FM) data

18. Cont… SECurity ( xSEC ). These capabilities provide security mechanisms such as M2M Service Bootstrap, key management, mutual authentication, and key agreement History and Data Retention ( xHDR ). These capabilities provide data retention support to other xSCL capabilities (which data to retain) as well as messages exchanged over the respective reference points. Transaction Management ( xTM ). This set of capabilities is optional and provides support for atomic transactions of multiple operations. Compensation Broker ( xCB ). This capability is optional and provides support for brokering M2M-related requests and compensation between a Customer and a Service Provider Telco Operator Exposure (NTOE). provides exposure of the Core Network service offered by a Telecom Network Operator. Interworking Proxy ( xIP ). This capability is an optional capability and provides mechanisms for connecting non-ETSI M2M Devices and Gateways to ETSI SCLs.

19. ETSI M2M interfaces The main interfaces mIa , dIa , and mId mIa : This is the interface between a Network Application and the Network Service Capabilities Layer (NSCL). dIa : This is the interface between a Device Application and (D/G)SCL or a Gateway Application and the GSCL. mId : This is the interface between the Network Service Capabilities Layer (NSCL) and the GSCL or the DSCL.

20. ETSI M2M resource management The ETSI M2M architecture assumes that applications (DA, GA, NA) exchange information with SCLs by performing CRUD (Create, Read, Update, Delete) operations on a number of Resources following the RESTful (Representational State Transfer) architecture paradigm. In addition to the CRUD operations, ETSI M2M defines two more operations: NOTIFY and EXECUTE .

21. Internet Engineering Task Force architecture Different part of the communication stack of a constrained device

22. Cont… The picture shows clear that each set of specifications makes an attempt to address a different part of the communication stack of a constrained device. The modified Open Systems Interconnection (OSI) model in which several layers are merged because of the implementation on constrained devices. one layer called Application Support which includes the Presentation and Session Layers combined. Adaptation Layer positioned between the Physical/Data Link and the Network Layer and whose main function is to adapt the Network Layer packets to Phy /Link layer packets among others.

23. Cont… 6LoWPAN layer designed to adapt IPv6 packets to IEEE 802.15.4/Bluetooth Low Energy (BLE)/DECT Low Energy packets. Constrained Application Protocol ( CoAP ), which provides reliability and RESTful operation support to applications IETF CoAP draft specification describes the Transport and Application Support Layers, which essentially defines the transport packet formats, reliability support on top of UDP, and a RESTful application protocol with GET/PUT/POST/DELETE methods similar to HTTP with CoAP clients operating on CoAP server resources. Apart from the core of the specifications, The CoRE Link Format specification (Shelby 2012) describes a discovery method for the CoAP resources of a CoAP server.

24. Cont… For example, a CoAP client sending a request with the GET method to a specific well defined server resource (./well-known/core) should receive a response with a list of CoAP resources and some of their capabilities (e.g. resource type, interface type). The IETF CoRE working group has also produced a draft specification for a Resource Directory (Shelby et al. 2013b). A Resource Directory is a CoAP server resource (/rd) that maintains a list of resources, their corresponding server contact information (e.g. IP addresses or fully qualified domain name, or FQDN), their type, interface, and other information similar to the information that the CoRE Link Format document specifies (Figure 6.8a). An RD plays the role of a rendezvous mechanism for CoAP Server resource descriptions, in other words, for devices to publish the descriptions of the available resources and for CoAP clients to locate resources that satisfy certain criteria such as specific resource types (e.g. temperature sensor resource type).

25. Resource Discovery

26. Open Geospatial Consortium architecture Large scale, ad hoc sensing networks using IoT will provide an unprecedented understanding of our environment.   Seismic monitoring, air pressure, air quality, noise and a myriad of other environmental variables will be recorded with a spatial density of measurements that will revolution our understanding and our ability to predict physical and social phenomena. Using sensors on Android phones  provides a global network of user-contributed atmospheric pressure readings which can lead to improved weather forecasting. The OGC SWE standards are well suited to bring large scale sensing to reality and Machine-to-Machine Communications: Connecting Billions of Devices OGC's developments aim to achieve the vision of an "Open IoT "

27. Cont… The Open Geospatial Consortium (OGC) is an international consortium of more than  500  businesses, government agencies, research organizations, and universities driven to make geospatial (location) information and services FAIR - Findable, Accessible, Interoperable, and Reusable. The Open Geospatial Consortium (OGC 2013) is an international industry consortium of: A few hundred companies, Government agencies and universities That develops publicly available standards that provide geographical information support to the Web, and wireless and location-based services.

28. Cont… OGC includes, among other working groups, the Sensor Web Enablement (SWE) (OGC SWE 2013) domain working group, which develops standards for : Sensor system models (e.g. Sensor Model Language, or SensorML ) Sensor information models (Observations & Measurements or O&M) Sensor services that follow the Service-Oriented Architecture (SOA) paradigm

29. OGC Cont… OGC SWE includes the following standards: SensorML and Transducer Model Language (TML): which include a model and an XML schema for describing sensor and actuator systems and processes. Observations and Measurements (O&M): which is a model and an XML schema for describing the observations and measurements for a sensor (Observations and Measurements, O&M). SWE Common Data model: for describing low-level data models ( e.g serialization in XML) in the messages exchanged between OGC SWE functional entities. Sensor Observation Service (SOS): which is a service for requesting, filtering, and retrieving observations and sensor system information. Sensor Planning Service (SPS): which is a service for applications requesting a user-defined sensor observations and measurements acquisition. PUCK: which defines a protocol for retrieving sensor metadata for serial port (RS232) or Ethernet-enabled sensor devices.

30. IoT reference Model An ARM consists of two main parts: a Reference model and a Reference Architecture. For describing an IoT ARM, we have chosen to use the IoT A ARM ( Carrez et al. 2013) as a guide because it is currently the most complete model and reference. However , a real system may not have all the modeled entities or architectural elements described in this chapter, or it could contain other non- IoT -related entities . A reference model describes the domain using a number of sub-models. The domain model of an architecture model captures the main concepts or entities in the domain The IoT Reference Model provides the concepts and definitions on which IoT architectures can be built . The IoT Reference Model aims at establishing a common grounding and a common language for IoT architectures and IoT systems .

31. Cont… The Reference Model consists of several sub-models that set the scope for the IoT design space and that address architectural views and perspectives . IoT Domain Model IoT Information Model IoT Functional Model IoT Communication model

32. Need IoT reference Model Simplifies : It helps break down complex systems so that each part is more understandable . Clarifies: It provides additional information to precisely identify levels of the IoT and to establish common terminology . Identifies: It identifies where specific types of processing is optimized across different parts of the system . Standardizes: It provides a first step in enabling vendors to create IoT products that work with each other . Organizes: It makes the IoT real and approachable, instead of simply conceptual.

33. IoT reference Model

34. Cont… The domain model of an architecture model captures the main concepts or entities in the domain in question, in this case M2M and IoT . common language references are established, the domain model adds descriptions about the relationship between the concepts. concepts and relationships serve the basis for the development of an information model because a working system needs to capture and process information about its main entities and their interactions. A working system that captures and operates on the domain and information model contains concepts and entities of its own, and these need to be described in a separate model, the functional model. An M2M and IoT system contain communicating entities, and therefore the corresponding communication model needs to capture the communication interactions of these entities.

35. Reference Architecture A System Architecture is a communication tool for different stakeholders of the system. Describing an architecture for M2M and IoT systems involves the presentation of the multiple facets of the systems in order to satisfy the different stakeholders. The high-level abstraction is called Reference Architecture as it serves as a reference for generating concrete architectures and actual systems A concrete architecture can be further elaborated and mapped into real world components by designing, building, engineering, and testing the different components of the actual system.

36. IOT Domain Model The domain model captures the basic attributes of the main concepts and the relationship between these concepts. A domain model also serves as a tool for human communication between people working in the domain in question and between people who work across different domains. Model notation and semantics use the Unified Modeling Language (UML) Class diagrams in order to present the relationships between the main concepts of the IoT domain model.

37. Relationship Generalization Specialization, Aggregation and Reflexive Aggregation, Composition, Directed Association and Reflexive Directed Association, and Realization.

38. Cont… Main concepts The IoT is a support infrastructure for enabling objects and places in the physical world to have a corresponding representation in the digital world. The reason why we would like to represent the physical world in the digital world is to remotely monitor and interact with the physical world using software. In the digital world, a parking spot is a variable with a binary value (“available” or “occupied”). The parking lot payment station also needs to be represented in the digital world in order to check if a recently parked car owner actually paid the parking fee.

39. Cont… Three kinds of Device types are Sensors: These are simple or complex Devices that typically involve a transducer that converts physical properties such as temperature into electrical signals. Actuators: These are also simple or complex Devices that involve a transducer that converts electrical signals to a change in a physical property (e.g. turn on a switch or move a motor). Tags: Tags in general identify the Physical Entity that they are attached to. In reality, tags can be Devices or Physical Entities but not both, as the domain model shows. An example of a Tag as a Device is a Radio Frequency Identification (RFID)

40. Information model Information is defined as the enrichment of data (raw values without relevant or usable context) with the right context, so that queries about who, what, where, and when can be answered. The attribute values are updated as a result of the associated services to a Virtual Entity. The associated services, in turn, are related to Resources and Devices as seen from the IoT Domain Model.

41. Cont… Virtual Entity object contains simple attributes/properties: entityType to denote the type of entity, such as a human, car, or room (the entity type can be a reference to concepts of a domain ontology, e.g. a carontology ); a unique identifier; and zero or more complex attributes of the class Attributes. The Virtual Entity in the IoT Information Model is described with only a few simple attributes, the complex Attribute associated with sensor/actuator/tag services.

42. Cont… Attributes or properties that could exist in a Virtual Entity description Location and its temporal information are important because Physical Entities represented by Virtual Entities exist in space and time. Service type, which denotes the type of service, such as Big Web Service or RESTful Web Service. Web Application Description Language (WADL), RESTful Web Services, Web Services Description Language (WSDL).

43. Cont… IoT Information Model also contains Resource descriptions Resource name and identifier for facilitating resource discovery. Resource type (a) a sensor resource (b) an actuator resource Free text attributes or tags on-Device resource or network resource. Location information Associated Service information Associated Device description information

44. Functional Model

45. Communication model The communication model for an IoT Reference Model consists of the identification of the endpoints of interactions, traffic patterns (e.g. unicast vs.multicast ), and general properties of the underlying technologies used for enabling such interactions. The potential communicating endpoints or entities are the Users, Resources , and Devices from the IoT Domain Model. Users include Human Users and Active Digital Artifacts (Services, internal system components, external applications).