IOT Unit-1 PDF

Unit 2 Syllabus: Iot Reference Architecture: Introduction, Functional View, Information View, Deployment and Operational View, Other Relevant Architectural views. Real-World Design Constraints- Introduction, Technical Design constraints. Iot Reference Architecture: The reference architecture con...

Unit 2 Syllabus: Iot Reference Architecture: Introduction, Functional View, Information View, Deployment and Operational View, Other Relevant Architectural views. Real-World Design Constraints- Introduction, Technical Design constraints. Iot Reference Architecture: The reference architecture consists of a set of components. Layers can be realized by means of specific technologies, and we will discuss options for realizing each component. There are also some cross-cutting/vertical layers such as access/identity management. Fig: IoT Reference architecture The layers are 1) Client/external communications - Web/Portal, Dashboard, APIs 2) Event processing and analytics (including data storage) 3) Aggregation/bus layer – ESB and message broker 4) Relevant transports - MQTT/HTTP/XMPP/CoAP/AMQP, etc. 5) Devices The cross-cutting layers are 6) Device manager 7) Identity and access management 1) The Device Layer: The bottom layer of the architecture is the device layer. Devices can be of various types, but in order to be considered as IoT devices, they must have some communications that either indirectly or directly attaches to the Internet. Each device typically needs an identity. The identity may be one of the following: A unique identifier (UUID) burnt into the device (typically part of the System-on-Chip, or provided by a secondary chip) A UUID provided by the radio subsystem (e.g. Bluetooth identifier, Wi-Fi MAC address) An OAuth2 Refresh/Bearer Token (this may be in addition to one of the above) An identifier stored in nonvolatile memory such as EEPROM For the reference architecture we recommend that every device has a UUID (preferably an unchangeable ID provided by the core hardware) as well as an OAuth2 Refresh and Bearer token stored in EEPROM. 2 ) The Communications Layer: The communication layer supports the connectivity of the devices. There are multiple potential protocols for communication between the devices and the cloud. The well known three potential protocols are HTTP/HTTPS (and RESTful approaches on those) MQTT 3.1/3.1.1 Constrained application protocol (CoAP) HTTP is well known, and there are many libraries that support it. Because it is a simple text based protocol, many small devices such as 8-bit controllers can only partially support the protocol. The larger 32-bit based devices can utilize full HTTP client libraries that properly implement the whole protocol. There are several protocols optimized for IoT use. The two best known are MQTT6 and CoAP7. MQTT was invented in 1999 to solve issues in embedded systems and SCADA. It has been through some iterations and the current version (3.1.1) is undergoing standardization in the OASIS MQTT Technical Committee8. MQTT is a publish-subscribe messaging system based on a broker model. CoAP is a protocol from the IETF that is designed to provide a RESTful application protocol modeled on HTTP semantics, but with a much smaller footprint and a binary rather than a text-based approach. CoAP is a more traditional client-server approach rather than a brokered approach. CoAP is designed to be used over UDP. 3) The Aggregation/Bus Layer: An important layer of the architecture is the layer that aggregates and brokers communications. This is an important layer for three reasons: 1. The ability to support an HTTP server and/or an MQTT broker to talk to the devices; 2. The ability to aggregate and combine communications from different devices and to route communications to a specific device (possibly via a gateway) 3. The ability to bridge and transform between different protocols, e.g. to offer HTTP based APIs that are mediated into an MQTT message going to the device. The aggregation/bus layer provides these capabilities as well as adapting into legacy protocols. The bus layer may also provide some simple correlation and mapping from different correlation models (e.g. mapping a device ID into an owner’s ID or vice-versa). Finally the aggregation/bus layer needs to perform two key security roles. It must be able to act as an OAuth2 Resource Server (validating Bearer Tokens and associated resource access scopes). It must also be able to act as a policy enforcement point (PEP) for policy-based access. 4) The Event Processing and Analytics Layer: This layer takes the events from the bus and provides the ability to process and act upon these events. A core capability here is the requirement to store the data into a database. This may happen in three forms. The traditional model here would be to write a server side application, e.g. this could be a JAX-RS application backed by a database. However, there are many approaches where we can support more agile approaches. The first of these is to use a big data analytics platform. This is a cloud- scalable platform that supports technologies such as Apache Hadoop to provide highly scalable map reduce analytics on the data coming from the devices. The second approach is to support complex event processing to initiate near real-time activities and actions based on data from the devices and from the rest of the system. Our recommended approach in this space is to use the following approaches: Highly scalable, column-based data storage for storing events Map-reduce for long-running batch-oriented processing of data Complex event processing for fast in-memory processing and near real-time reaction and autonomic actions based on the data and activity of devices and other systems In addition, this layer may support traditional application processing platforms, such as Java Beans, JAX-RS logic, message-driven beans, or alternatives, such as node.js, PHP, Ruby or Python. 5) Client/External Communications Layer: The reference architecture needs to provide a way for these devices to communicate outside of the device-oriented system. This includes three main approaches. Firstly, we need the ability to create web-based front-ends and portals that interact with devices and with the event-processing layer. Secondly, we need the ability to create dashboards that offer views into analytics and event processing. Finally, we need to be able to interact with systems outside this network using machine-to-machine communications (APIs). These APIs need to be managed and controlled and this happens in an API management system. The dashboard is a re-usable system focused on creating graphs and other visualizations of data coming from the devices and the event processing layer. The API management layer provides three main functions: The first is that it provides a developer-focused portal (as opposed to the user focused portal previously mentioned), where developers can find, explore, and subscribe to APIs from the system. There is also support for publishers to create, version, and manage the available and published APIs; The second is a gateway that manages access to the APIs, performing access control checks (for external requests) as well as throttling usage based on policies. It also performs routing and load-balancing; The final aspect is that the gateway publishes data into the analytics layer where it is stored as well as processed to provide insights into how the APIs are used. 6) Device Management: Device management (DM) is handled by two components. A server-side system (the device manager) communicates with devices via various protocols and provides both individual and bulk control of devices. It also remotely manages software and applications deployed on the device. It can lock and/or wipe the device if necessary. The device manager works in conjunction with the device management agents. There are multiple different agents for different platforms and device types. The device manager also needs to maintain the list of device identities and map these into owners. It must also work with the identity and access management layer to manage access controls over devices (e.g. who else can manage the device apart from the owner, how much control does the owner have vs. the administrator, etc.) There are three levels of device: non-managed, semi-managed and fully managed (NM, SM, and FM). Fully managed devices are those that run a full DM agent. A full DM agent supports: Managing the software on the device Enabling/disabling features of the device (e.g. camera, hardware, etc.) Management of security controls and identifiers Monitoring the availability of the device Maintaining a record of the device’s location if available Locking or wiping the device remotely if the device is compromised, etc. Non-managed devices can communicate with the rest of the network, but have no agent involved. Semi-managed devices are those that implement some parts of the DM (e.g. feature control, but not software management). 7) Identity and Access Management: The final layer is the identity and access management layer. This layer needs to provide the following services: OAuth2 token issuing and validation Other identity services including SAML2 SSO and OpenID Connect support for identifying inbound requests from the Web layer XACML PDP Directory of users (e.g. LDAP) Policy management for access control (policy control point) The identity layer may of course have other requirements specific to the other identity and access management for a given instantiation of the reference architecture. In order to address the concerns of mainly the concrete IoT architect, and secondly the concerns of most of the above stakeholders, we have chosen to present the Reference Architecture as a set of architectural views A Reference Architecture, on the other hand, serves as a guide for one or more concrete system architects. However, the concept of views for the presentation of architecture is also useful for the IoT Reference Architecture. Views are useful for reducing the complexity of the Reference Architecture blue prints by addressing groups of concerns one group at a time. 1) Functional View: Description of what the system does, and its main functions. 2) Information View: Description of the data and information that the system handles. 3) Development View: defines how to implement the system. 4) Operational View: defines how to keep the system alive in the field. 5) Deployment View: defines how to transition the system to live operation. Fig: various views in IoT 1) Development View: The Development View defines how to implement the system. The Development View addresses the concerns of developers and testers. All software projects involve some amount of new code being written.This view provides a stable environment for more detailed design work. 2) Deployment View: The Deployment View defines how to transition the system to live operation. Focuses on aspects of the system important after the system has been built and is ready to be put into live operation. It defines -The physical environment it will run in. -Hardware and hosting environment (processing nodes, network interconnections, disk storage). -Technical environment requirements for each processing node. - Mapping of elements to the runtime environment that will execute them. It is needed when the system has- -Complex runtime dependencies. - Third party libraries, network services. - Complex runtime environments. -Elements distributed across many machines. -Dependencies on unfamiliar HW/SW. -Deployed on cloud hardware. - When the system will be deployed in wildly varying software environments. - Commercial software runs on a PC. - Wildly varying physical environments. - Specialist or unfamiliar hardware. 3) Operational View: The Operational View defines how to keep the system alive in the field It identifies a system-wide strategy for addressing operational concerns. It helps to ensure system is a reliable and effective part of its environment. For packaged software, it helps to illustrate the types of issues that could occur once installed. It documents how the system can be architected to reduce or address these concerns. The Operational View is the often least well-defined view, as many of the details are not fully-defined until construction is underway 3.1) Installation and upgrade Operation team performs the install. Sometimes users install and configure themselves. In installation and upgrade it checks/validates- - Resources allocated to a cloud environment. -Is this a pure installation or an upgrade? -Upgrades can be more complex. It must respect existing data and settings, state of running elements. -Can you keep the system running during update? - Ensure the system can be installed or updated successfully. 3.2) Documenting Installation and Upgrade It help the reader understand: What needs to be installed or upgraded to move the system into production? What dependencies exist between groups of items to be installed or upgraded (determines event order). What constraints exist on the installation process? What needs to be done to abandon and undo the installation/upgrade if there is a problem? Do not need a complete guide. Instead, constraints the architecture imposes on installation and upgrade. 3.3) Operational Monitoring and Control: In Operational Monitoring and Control it checks- -Does systems require routine monitoring? Which control operations can be used to keep the system running correctly. -Startup, shutdown, transaction resubmission. -How much is required depends on how many unexpected operational conditions are likely to occur. -Balance against cost and time. -Consider deployment environment to identify solutions. 3.4) Alerting: A system should send notifications when something bad happens. - Technical alert: Unable to connect to database. -Functional alert: Bad data on an automated input. Significant non-error conditions (startup, shutdown) Active function of a system. Alert should be sent to appropriate humans for action. It defines which events require alerts, what information should be included, and where it should be sent. Avoid sending too many alerts 3.5) Backup and Restore: Data must be protected and insured. -for that Backup processes should be designed, built, and tested regularly. -It must be possible to restore data from a backup in a transactionally consistent state. -All updates committed to the restored database or not recovered at all, must be checked regularly. -Consider data lost as part of restoring (at least any transactions active during failure). -Failure in one element could corrupt system. -Recover or recreate lost data. Revert system to older state. 3.6) Documenting System Administration: It contains monitoring and control facilities. How to monitor and adjust the system. Custom utilities, existing management environments. Basic message log to full-blown infrastructure. Define what features you will offer, how to use them, and any limitations. Required routine procedures What needs to be performed regularly? What are the Backup and health check procedures? Define purpose of each procedure, when performed, who performs it, and the steps involved. The likely error conditions Error conditions may require administrative intervention (disk full, network failure). What is unique about architecture? Explain error conditions, when they occur, how to recognize them, and HOW to correct them. Performance monitoring facilities. Watch the system for performance problems Explain measures taken, how they can be extracted and analyzed. 4) Functional view: Fig : Functional view The functional view for the IoT Reference Architecture is presented in Fig ,and is adapted from IoT- A architecture. It consists of the Functional Groups (FGs) presented earlier in the IoT Functional Model, each of which includes a set of Functional Components (FCs). It is important to note that not all the FCs are used in a concrete IoT architecture, and therefore in the actual system as explained earlier 4.1) Device and Application functional group: The Device and Application FGs are already covered in the IoT Functional Model. For convenience the Device FG contains the Sensing, Actuation, Tag, Processing, Storage FCs, or simply components. These components represent the resources of the device attached to the Physical Entities of interest. The Application FG contains either standalone applications (e.g. for iOS, Android, Windows phone), or Business Applications that connect the IoT system to an Enterprise system. 4.2) Communication functional group The Hop-by-Hop Communication is applicable in the case that devices and messages have to traverse the mesh from node-to-node (hop-by-hop) until they reach a gateway node which forwards the message (if needed) further to the Internet. This FC has two main interfaces: one “southbound” to/from the actual radio on the device, and one “northbound” to/from the Network FC in the Communication FG. The Network FC is responsible for message routing & forwarding and the necessary translations of various identifiers and addresses. The translations can be (a) Between network layer identifiers to MAC and/or physical network identifiers, (b) Between high-level human readable host/node identifiers to network layer addresses and (c) Translation between node/service identifiers and network locators in case the higher layers above the networking layer use node or service identifiers The End-to-End Communication FC is responsible for end-to-end transport of application layer messages through diverse network and MAC/PHY layers. 4.3) IoT Service functional group The IoT Service FC is a collection of service implementations, which interface the related and associated Resources. For a Sensor type of a Resource, the IoT Service FC includes Services that receive requests from a User and returns the Sensor Resource value in synchronous or asynchronous (e.g. subscription/notification) fashion. The IoT Service Resolution FC contains the necessary functions to realize a directory of IoT Services that allows dynamic management of IoT Service descriptions and discovery/lookup/resolution of IoT Services by other Active Digital Artifacts. 4.4) Virtual Entity functional group: The Virtual Entity FG contains functions that support the interactions between Users and Physical Things through Virtual Entity services. An example of such an interaction is the query to an IoT system of the form, “What is the temperature in the conference room Titan?” 4.5) Process Management functional group: The IoT Process Management FG, integration of business processes with IoT-related services. It consists of two FCs: The Process Modelling FC provides that right tools for modelling a business process that utilises IoT-related services. The Process Execution FC contains the execution environment of the process models created by the Process Modelling FC and executes the created processes by utilising the Service Organisation FG in order to resolve high-level application requirements to specific IoT services 4.6) Service Organization functional group: The Service Composition FC manages the descriptions and execution environment of complex services consisting of simpler dependent services. An example of a complex composed service is a service offering the average of the values coming from a number of simple Sensor Services. The Service Orchestration FC resolves the requests coming from IoT Process Execution FC or User into the concrete IoT services that fulfill the requirements. The Service Choreography FC is a broker for facilitating communication among Services using the Publish/Subscribe pattern. Users and Services interested in specific IoT-related services subscribe to the Choreography FC, providing the desirable service attributes even if the desired services do not exist. 4.7) Security functional group: The Security FG contains the necessary functions for ensuring the security and privacy of an IoT system. The Identity Management FC manages the different identities of the involved Services or Users in an IoT system The The Authentication FC verifies the identity of a User and creates an assertion upon successful verification. Verifies the identity of a User and creates an assertion upon successful verification. The Authorization FC manages and enforces access control policies. It provides services to manage policies (CUD), as well as taking decisions and enforcing them regarding access rights of restricted resources. The Key Exchange & Management is used for setting up the necessary security keys between two communicating entities in an IoT system. The Trust & Reputation FC manages reputation scores of different interacting entities in an IoT system and calculates the service trust levels. 4.8) Management functional group: The Configuration FC maintains the configuration of the FCs and the Devices in an IoT system. The component collects the current configuration of all the FCs and devices, stores it in a historical database, and compares current and historical configurations. The Fault FC detects, logs, isolates, and corrects system-wide faults if possible. This means that individual component fault reporting triggers fault diagnosis and fault recovery procedures in the Fault FC. The component collects the current configuration of all the FCs and devices, stores it in a historical database, and compares current and historical configurations. The Member FC manages membership information about the relevant entities in an IoT system. The State FC is similar to the Configuration FC, and collects and logs state information from the current FCs, which can be used for fault diagnosis, performance analysis and prediction, as well as billing purposes. The Reporting FC is responsible for producing compressed reports about the system state based on input from FCs. ii-font-family. 5) Information view: The information view consists of (a) The description of the information handled in the IoT System, and (b) The way this information is handled in the system; in other words, the information lifecycle and flow (how information is created, processed, and deleted), and the information handling components Information description The pieces of information handled by an IoT system complying to an ARM such as the IoT-Architecture are the following:  Virtual Entity context information, i.e. the attributes (simple or complex) as represented by parts of the IoT Information model (attributes that have values and metadata such as the temperature of a room).This is one of the most important pieces of information that should be captured by an IoT system, and represents the properties of the associated Physical Entities or Things. IoT Service output itself is another important part of information generated by an IoT system. For example, this is the information generated by interrogating a Sensor or a Tag Service. Virtual Entity descriptions in general, which contain not only the attributes coming from IoT Devices (e.g. ownership information), but also associations between Virtual Entities and related IoT Services. IoT Service Descriptions, which contain associated Resources, interface descriptions, etc. Resource Descriptions, which contain the type of resource (e.g. sensor), identity, associated Services, and Devices. Device Descriptions such as device capabilities (e.g. sensors, radios). Descriptions of Composed Services, which contain the model of how a complex service is composed of simpler services. IoT Business Process Model, which describes the steps of a business process utilizing other IoT-related services (IoT, Virtual Entity,Composed Services). Security information such as keys, identity pools, policies, trust models, reputation scores, etc. Management information such as state information from operational FCs used for fault/performance purposes, membership information, etc.  Fig: Information exchange patterns Push: An FC A pushes the information to another FC B provided that the contact information of the component B is already configured in component A, and component B listens for such information pushes. Request/Response: An FC A sends a request to another FC B and receives a response from B after A serves the request. Typically the interaction is synchronous inthe sense that A must wait for a response from B before proceeding to other tasks, but in practice this limitation can be realized with parts of component A waiting, and other parts performing other tasks. Component B may need to handle concurrent requests and responses from multiple components, which imposes certain requirements on the capabilities for the device or the network that hosts the FC. Subscribe/Notify: Multiple subscriber components (SA, SB) can subscribe for information to a component C, and C will notify the relevant subscribers when the requested information is ready. This is typically an asynchronous information request after which each subscriber can perform other tasks. Nevertheless, a subscriber needs to have some listening components for receiving the asynchronous response. The target component C also needs to maintain state information about which subscribers requested which information and their contact information. The Subscribe/Notify pattern is applicable when typically one component is the host of the information needed by multiple other components. Then the subscribers need only establish a Subscribe/Notify relationship with one component. If multiple components can be information producers or information hosts, the Publish/Subscribe pattern is a more scalable solution from the point of view of the subscribers. Publish/Subscribe: In the Publish/Subscribe (also known as a Pub/Sub pattern), there is a third component called the broker B, which mediates subscription and publications between subscribers (information consumers) and publishers (or information producers). Subscribers such as SA and SB subscribe to the broker about the information they are interested in by describing the different properties of the information. Publishers publish information and metadata to the broker, and the broker pushes the published information to (notification) the subscribers whose interests match the published information. Following fig shows Information Flow and Lifecycle Use case to depict all views: Fig: Parking Lot Deployment and Operational View, Devices. The Deployment and Operational View depends on the specific actual use case and requirements, and therefore we present here one way of realizing the Parking Lot example seen earlier. Figure depicts the Devices view as Physical Entities deployed in the parking lot, as well as the occupancy sign. There are two sensor nodes (#1 and #2), each of which are connected to eight metal/car presence sensors. The two sensor nodes are connected to the payment station through wireless or wired communication. The payment station acts both as a user interface for the driver to pay and get a payment receipt as well as a communication gateway that connects the two sensor nodes and the payment interface physical devices (displays, credit card slots, coin/note input/output, etc.) with the Internet through Wide Area Network(WAN) technology. The occupancy sign also acts as a communication gateway for the actuator node (display of free parking spots), and we assume that because of the deployment, a direct connection to the payment station is not feasible (e.g. wired connectivity is too prohibitive to be deployed or sensitive to vandalism). The physical gateway devices connect through a WAN technology to the Internet and towards a data center where the parking lot management system software is hosted as one of the virtual machines on a Platform as a Service (PaaS;) configuration. The two main applications connected to this management system are human user mobile phone applications and parking operation center applications. We assume that the parking operation center manages several other parking lots using similar physical and virtual infrastructure.  Figure shows two views super imposed, the deployment and functional views, for the parking lot example. Please note that several FGs and FCs are omitted here for simplicity purposes, and certain non- IoT-specific Services appear in the figure because an IoT system is typically part of a larger system. Starting from the Sensor Devices, as seen earlier, Sensor Node #1 hosts Resource #11#18, representing the sensors for the parking spots #01#08, while earlier Sensor Node #2 hosts Resource #21#28, representing the sensors for the parking spots#09#16 Fig: Parking Lot Deployment & Operational View, Resources, Services, Virtual Entities, Users Assume that the sensor nodes are powerful enough to host the IoT Services #11#18 and #21#28 representing the respective resources. The two sensor nodes are connected to the gateway device that also hosts the payment service with the accompanying sensors and actuators, as seen earlier. The other gateway device hosts the occupancy sign actuator resource and corresponding service. The management system for the specific parking lot, as well as others, is deployed on a virtual machine on a data center. The virtual machine hosts communication capabilities, Virtual Entity services for the parking spots #01#16, the Virtual Entity services for the occupancy sign, a payment business process that involves the payment station and input from the occupancy sensor services, and the parking lot management service that provides exposure and access control to the parking lot occupancy data for the parking operation center and the consumer phone applications. As a reminder, the Virtual Entity service of the parking lot uses the IoT Services hosted on two sensor nodes and performs the mapping between the sensor node identifiers (#11#18 and #21#28) to parking spot identifiers (spot #01#16). The services offered on these parking spots are to read the current state of the parking spot to see whether it is “free” or “occupied.” The Virtual Entity corresponding to the occupancy sign contains one writable attribute: the number of free parking spots. A User writing this Virtual Entity attribute results in an actuator command to the real actuator resource to change its display to the new value.  Fig: Mapping IoT Domain Model concepts to Deployment View Figure shows an example of mapping an IoT Domain Model and Functional View to Devices with different capabilities (different alternatives) connecting to a cloud infrastructure. Alternative 1 shows devices that can host only a simple Sensor Device and a short-range wired or wireless connectivity technology (Basic Device #1). Such kind of device needs an Advanced Device of type #1 that allows the basic device to perform protocol adaptation (at least from the short-range wired or wireless connectivity technology to a WAN technology) so that the Sensor IoT service in the cloud and the Sensor Resource on the Basic Device #1 can exchange information. The Virtual Entity representing the Physical Entity where the Basic Device #1 is deployed is also hosted in the cloud. In alternative 2, Advanced Devices (type #2) can host the Sensor IoT Service communicating to the Sensor Resource on a Basic Device #1. The cloud infrastructure in this case only hosts the Virtual Entity Service corresponding to the Sensor IoT Service. The difference between alternative 1 and 2 is that the Sensor IoT Service hosted on an Advanced Device #2 should be capable of responding to requests from Users (cloud services, Applications) with the appropriate secure mediation of course. In alternative 3, the Basic Device #3 is capable of providing the Sensor Resource and the Sensor IoT Service but still needs an Advanced Device #1 to transport IoT service requests/responses/subscriptions/ notifications/publications to the Users in the cloud. According to experience, this kind of deployment scenario imposes a high burden on a Basic Device, which potentially makes the Basic Device the weakest link in the information flow, If malicious Users launch a Denial of Service (DoS) attack on the node, the probability of the node going down is very high. Alternatives 4 and 5 show Advanced Devices offering a WAN interface. In alternative 4, only the Sensor Resource is hosted on the Device, while in alternative 5, even the IoT Service is hosted on the Device. The Virtual Entity Service is hosted in the cloud. Real-World Design Constraints: The real world design constraints are mostly applied to devices and network components. It’s classified into two types:- Design Constraints 1) Functional Constraints 2) Non-Functional Constraints: 1) Technical constraints 2) Non-Technical constraints 1) Functional Constraints: Functional design constraints in IoT refer to the specific requirements and limitations that govern the functionality and operation of IoT systems. Here are some common functional design constraints in IoT: - Specific sensing and actuating capabilities: Sensing principle and data requirements: Sometimes continuous sampling of sensing data is required. For some applications, sampling after specific intervals is required. The parameters like higher network throughput, data loss, energy use, etc are decided based on sensing principle. The sensing field is to be considered for sensing in local area or distributed sensing. The distance between sensing points is also important factor to be considered. The physical environment has an implication on the communications technologies selected and the reliability of the system in operation thereafter. Devices must be placed in close enough proximity to communicate. Where the distance is too great, routing devices may be necessary. -Programming and embedded intelligence: Devices in the IoT are heterogeneous such as various computational architectures, including MCUs (8-, 16-,32- bit, ARM, 8051, RISC, Intel, etc.), signal conditioning (e.g. ADC), and memory (ROM, S/F/D) RAM, etc.), communications media, peripheral components (sensors, actuators, buttons, screens, LEDs), etc. In every case, an application programmer must consider the hardware selected or designed, and its capabilities. Application-level logic decides the sampling rate of the sensor, the local processing performed on sensor readings, the transmission schedule (or reporting rate), and the management of the communications protocol stack, among other things. The programmers have to reconfigure and reprogram devices in case of change in devices in IoT application. - Data Collection and Processing: IoT systems need to efficiently collect and process data from a variety of sensors and devices. Design constraints include defining the types of data to be collected, determining the frequency and volume of data, and establishing the processing requirements for real-time or batch processing. -Gateway: Gateway devices or proxies are selected according to need of data transitions. - Device Compatibility: IoT systems often involve multiple devices from different manufacturers with varying communication protocols and data formats. Design constraints include ensuring device compatibility, defining communication standards or protocols, and establishing mechanisms for device discovery, registration, and integration. 2) Non-Functional Constraints: Non functional constraints are having two types: 1) Technical constraints 2) Non-Technical constraints 1) Technical constraints: Technical constraints in IoT refer to the limitations and considerations related to the underlying technology and infrastructure of IoT systems. These constraints impact the design, implementation, and performance of IoT solutions. Here are some common technical constraints in IoT: - Network Bandwidth: IoT devices generate and transmit large amounts of data, which can strain network bandwidth. Technical constraints include the availability and capacity of the network infrastructure to handle data traffic efficiently and ensure timely delivery of data. - Security and Privacy: IoT systems face significant security and privacy challenges due to the large attack surface and potential vulnerabilities of connected devices. Technical constraints involve implementing robust security measures, including authentication, encryption, secure communication protocols, and intrusion detection systems, to protect data and devices from unauthorized access and attacks. -Connectivity: IoT devices require reliable and secure connectivity to transmit data to the cloud or other systems. Design constraints include determining the connectivity requirements (e.g., Wi-Fi, cellular, LPWAN), ensuring network coverage and quality, and establishing mechanisms for seamless and robust communication. - Interoperability: IoT devices come from different manufacturers and may use various communication protocols and data formats. The architecture should support interoperability by providing mechanisms to integrate heterogeneous devices and systems seamlessly. -Integration with existing systems: IoT systems must be able to integrate with existing systems, such as enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, and supply chain management (SCM) systems. This requires the use of common interfaces and protocols. -Maintenance and repair: IoT devices may be deployed in remote or hard-to-reach areas, where maintenance and repair may be difficult. This constraint must be considered during the design phase to ensure that the devices can be easily maintained and repaired, or that they have failover mechanisms in place to ensure continuity of service. 2) Non-Technical Constraints: -Legal and regulatory compliance: IoT deployments must adhere to various laws and regulations, including consumer protection, data privacy, security, and product safety. Complying with legal requirements and industry standards is a non-negotiable constraint that must be considered during the design and implementation phases. -Cultural and social factors: IoT systems may encounter cultural or social barriers that can impact user acceptance and adoption. Factors like cultural norms, language barriers, and accessibility requirements must be considered to design inclusive IoT solutions that cater to diverse user needs. -Interoperability and standardization: IoT involves a multitude of devices, platforms, and communication protocols. Interoperability challenges can arise due to the lack of standardized interfaces and protocols. Ensuring compatibility and interoperability between different IoT devices and systems is a non-technical constraint that needs to be addressed to facilitate seamless integration. -Cost: IoT devices must be designed to be cost-effective, as they are often deployed in large numbers. This requires the use of low-cost components, efficient manufacturing processes, and streamlined supply chains. -Ethical considerations: IoT devices and systems can raise ethical concerns, particularly regarding issues like surveillance, consent, and data ownership. Designing IoT systems that respect ethical principles and prioritize the well-being and autonomy of individuals is a significant constraint. -Social acceptance and trust: Widespread adoption of IoT technologies depends on public acceptance and trust. Concerns regarding privacy, security, and the potential impact on employment or societal structures must be addressed to gain public trust and ensure social acceptance. -Business models and economic viability: Developing sustainable business models for IoT solutions is crucial. The cost of devices, infrastructure, maintenance, and connectivity must be balanced with potential revenue streams and return on investment (ROI). Understanding the economic viability and ensuring scalability is a non-technical constraint that influences IoT implementation.  IV Unit – M2M and IoT Technology Fundamentals UNIT IV: M2M and IoT Technology Fundamentals Devices and gateways, Local and wide area networking, Data management, Business processes in IoT, Everything as a Service(XaaS), M2M and IoT Analytics, Knowledge Management. 4.1 Devices and gateways 4.1.1 Introduction  There is a growing market for small-scale embedded processing such as 8-, 16-, and 32- bit microcontrollers with on-chip RAM and flash memory, I/O capabilities, and networking interfaces such as IEEE 802.15.4 that are integrated on tiny System-on-a- Chip (SoC) solutions.  Such devices enable very constrained devices with a small footprint of a few mm2 and with a very low power consumption in the milli- to micro-Watt range, but which are capable of hosting an entire Transmission Control Protocol/Internet Protocol (TCP/IP) stack, including a small web server.  A device is a hardware unit that can sense aspects of it’s environment and/or actuate, i.e. perform tasks in its environment.  A device can be characterized as having several properties, including: Microcontroller: 8-, 16-, or 32-bit working memory and storage. Power Source: Fixed, battery, energy harvesting, or hybrid. Sensors and Actuators: Onboard sensors and actuators, or circuitry that allows them to be connected, sampled, conditioned, and controlled. Communication: Cellular, wireless, or wired for LAN and WAN communication. Operating System (OS): Main-loop, event-based, real-time, or full featured OS. Applications: Simple sensor sampling or more advanced applications. User Interface: Display, buttons, or other functions for user interaction. Device Management (DM): Provisioning, firmware, bootstrapping, and monitoring. Execution Environment (EE): Application lifecycle management and Application Programming Interface (API). 4.1.1.1 Device types  Group devices into two categories Basic Devices: Devices that only provide the basic services of sensor readings and/or actuation tasks, and in some cases limited support for user interaction. LAN 1  IV Unit – M2M and IoT Technology Fundamentals communication is supported via wired or wireless technology, thus a gateway is needed to provide the WAN connection. Advanced Devices: In this case the devices also host the application logic and a WAN connection. They may also feature device management and an execution environment for hosting multiple applications. Gateway devices are most likely to fall into this category. 4.1.1.2 Deployment scenarios for devices  Example deployment scenarios for basic devices include: Home Alarms: Such devices typically include motion detectors, magnetic sensors, and smoke detectors. A central unit takes care of the application logic that calls security and sounds an alarm if a sensor is activated when the alarm is armed. The central unit also handles the WAN connection towards the alarm central. These systems are currently often based on proprietary radio protocols. Smart Meters: The meters are installed in the households and measure consumption of, for example, electricity and gas. A concentrator gateway collects data from the meters, performs aggregation, and periodically transmits the aggregated data to an application server over a cellular connection. By using a capillary network technology it’s possible to extend the range of the concentrator gateway by allowing meters in the periphery to use other meters as extenders, and interface with handheld devices on the Home Area Network side. Building Automation Systems (BASs): Such devices include thermostats, fans, motion detectors, and boilers, which are controlled by local facilities, but can also be remotely operated. Standalone Smart Thermostats: These use Wi-Fi to communicate with web services. Examples for advanced devices, meanwhile, include: Onboard units in cars that perform remote monitoring and configuration over a cellular connection. Robots and autonomous vehicles such as unmanned aerial vehicles that can work both autonomously or by remote control using a cellular connection. Video cameras for remote monitoring over 3G and LTE. Oil well monitoring and collection of data points from remote devices. Connected printers that can be upgraded and serviced remotely. 2  IV Unit – M2M and IoT Technology Fundamentals 4.1.2 Basic devices  These devices are often intended for a single purpose, such as measuring air pressure or closing a valve. I  In some cases several functions are deployed on the same device, such as monitoring humidity, temperature, and light level.  The main focus is on keeping the bill of materials (BOM) as low as possible by using inexpensive microcontrollers with built-in memory and storage, often on an SoC- integrated circuit with all main components on one single chip (Figure 5.1).  Another common goal is to enable battery as a power source, with a lifespan of a year and upwards by using ultra-low energy microcontrollers.  The microcontroller typically hosts a number of ports that allow integration with sensors and actuators, such as General Purpose I/O (GPIO) and an analog-to-digital converter (ADC) for supporting analog input.  For certain actuators, such as motors, pulse-width modulation (PWM) can be used.  As low-power operation is paramount to battery-powered devices, the microcontroller hosts functions that facilitate sleeping, such as interrupts that can wake up the device on external and internal events. 3  IV Unit – M2M and IoT Technology Fundamentals  Some devices even go as far as harvesting energy from their environment, e.g. in the form of solar, thermal, and physical energy.  To interact with peripherals such as storage or display, it’s common to use a serial interface such as SPI, I2C, or UART.  These interfaces can also be used to communicate with another microcontroller on the device.  This is common when the there is a need for offloading certain tasks, or when in some cases the entire application logic is put on a separate host processor.  It’s not unusual for the micro controller to also contain a security processor,e.g. to accelerate Advanced Encryption Standard (AES).  This is necessary to allow encrypted communication over the radio link without the need for a host processor.  The gateway together with the connected devices form a capillary network.  The microcontroller contains most of the radio functions needed for communicating with the gateway and other devices in the same capillary network.  An external antenna is, however, necessary, and preferably a filter that removes unwanted frequencies, e.g. a surface acoustic wave (SAW) filter.  Due to limited computational resources, these devices commonly do not use a typical OS.  It may be something as simple as a single-threaded main-loop or a low-end OS such as FreeRTOS, Atomthreads, AVIX-RT, ChibiOS/RT, ERIKA Enterprise, TinyOS, or Thingsquare Mist/Contiki.  These OSes offer basic functionality, e.g. memory and concurrency model management, (sensor and radio) drivers, threading, TCP/IP, and higher level protocol stacks.  The actual application logic is located on top of the OS or in the mainloop.  A typical task for the application logic is to read values from the sensors and to provide these over the LAN interface in a semantically correct manner with the correct units. 4.1.3 Gateways  A gateway serves as a translator between different protocols, e.g. between IEEE 802.15.4 or IEEE 802.11, to Ethernet or cellular.  There are many different types of gateways, which can work on different levels in the protocol layers.  A gateway refers to a device that performs translation of the physical and link layer, but application layer gateways (ALGs) are also common.  The latter is preferably avoided because it adds complexity and is a common source of error in deployments.  Some examples of ALGs include the ZigBee Gateway Device which translates from ZigBee to SOAP and IP, or gateways that translate from Constrained Application Protocol (CoAP) to HyperText Transfer Protocol/Representational State Transfer (HTTP/REST). 4  IV Unit – M2M and IoT Technology Fundamentals  Tthe gateway device is also used for many other tasks, such as data management, device management, and local applications. 4.1.3.1 Data management  Typical functions for data management include performing sensor readings and caching this data, as well as filtering, concentrating, and aggregating the data before transmitting it to back-end servers. 4.1.3.2 Local applications  Examples of local applications that can be hosted on a gateway include closed loops, home alarm logic, and ventilation control, or the data management function above  The benefit of hosting this logic on the gateway instead of in the network is to avoid downtime in case of WAN connection failure, minimize usage of costly cellular data, and reduce latency.  To facilitate efficient management of applications on the gateway, it’s necessary to include an execution environment.  The execution environment is responsible for the lifecycle management of the applications, including installation, pausing, stopping, configuration, and uninstallation of the applications.  A common example of an execution environment for embedded environments is OSGi, which is based on Java: applications are built as one or more Bundles, which are packaged as Java JAR files and installed using a so-called Management Agent.  The Management Agent can be controlled from, for example, a terminal shell or via a protocol such as CPE WAN Management Protocol (CWMP).  Bundle packages can be retrieved from the local file system or over HTTP, for example. OSGi also provides security and versioning for Bundles, which means that communication between Bundles is controlled, and several versions of them can exist.  The benefit of versioning and the lifecycle management functions is that the OSGi environment never needs to be shut down when upgrading, thus avoiding downtime in the system.  Also, Linux can be used as an execution environment. 4.1.3.3 Device management  Device management (DM) is an essential part of the IoT and provides efficient means to perform many of the management tasks for devices: Provisioning: Initialization (or activation) of devices in regards to configuration and features to be enabled. Device Configuration: Management of device settings and parameters. Software Upgrades: Installation of firmware, system software, and applications on the device. 5  IV Unit – M2M and IoT Technology Fundamentals Fault Management: Enables error reporting and access to device status.  Examples of device management standards include TR-069 and OMA-DM.  In the simplest deployment, the devices communicate directly with the DM server.  This is, however, not always optimal or even possible due to network or protocol constraints, e.g. due to a firewall or mismatching protocols.  In these cases, the gateway functions as mediator between the server and the devices, and can operate in three different ways: If the devices are visible to the DM server, the gateway can simply forward the messages between the device and the server and is not a visible participant in the session. In case the devices are not visible but understand the DM protocol in use, the gateway can act as a proxy, essentially acting as a DM server towards the device and a DM client towards the server. For deployments where the devices use a different DM protocol from the server, the gateway can represent the devices and translate between the different protocols (e.g. TR-069, OMA-DM, or CoAP).  The devices can be represented either as virtual devices or as part of the gateway 4.1.4 Advanced devices  An advanced device are the following: A powerful CPU or microcontroller with enough memory and storage to host advanced applications, such as a printer offering functions for copying, faxing, printing, and remote management. A more advanced user interface with, for example, display and advanced user input in the form of a keypad or touch screen. Video or other high bandwidth functions. 4.1.5 Summary and vision  The most important of these is security, both in terms of physical security as well as software and network security.  External factors that can affect the operation of the devices, such as rain, wind, chemicals, and electromagnetic influences.  One of the major effects that the IoT will have on devices is to disrupt the current value chains, where one actor controls everything from device to service.  This will happen due to standardization and consolidation of technologies, such as protocols, OSes, software and programming languages (e.g. Java for embedded devices), and the business  New types of actors will be able to enter the market, e.g. specialized device vendors, cloud solution providers, and service providers. 6  IV Unit – M2M and IoT Technology Fundamentals  Standardization will improve interoperability between devices, as well as between devices and services, resulting in commoditization of both.  Another expected outcome of improved interoperability is the possibility to reuse the same device for multiple services;  for example, a motion detector can be used both for security purposes as well as for reducing energy consumption by detecting when no one is in the room.  Thanks to developments in hardware and network technologies, entirely new device classes and features are expected, such as: Battery-powered devices with ultra-low power cellular connections. Devices that harvest energy from their environment. Smart bandwidth management and protocol switching, i.e. using adaptive RF mechanisms to swap between, for example, Bluetooth LE and IEEE 802.15.4. Multi-radio/multi-rate to switch between bands or bit rates Microcontrollers with multicore processors. Novel software architectures for better handling of concurrency. The possibility to automate the design of integrated circuits based on business-level logic and use case. 4.2 Local and wide area networking 4.2.1 The need for networking  A network is created when two or more computing devices exchange data or information.  The ability to exchange pieces of information using telecommunications technologies has changed the world  Devices are known as “nodes” of the network, and they communicate over “links.”  In modern computing, nodes range from personal computers, servers, and dedicated packet switching hardware, to smart phones, games consoles, television sets and, increasingly, heterogeneous devices that are generally characterized by limited resources and functionalities.  Limitations typically include computation, energy, memory, communication (range, bandwidth, reliability, etc.) and application specificity (e.g. specific sensors, actuators, tasks), etc. Such devices are typically dedicated to specific tasks, such as sensing, monitoring, and control.  Network links rely upon a physical medium, such as electrical wires, air, and optical fibers, over which data can be sent from one network node to the next.  A selected physical medium determines a number of technical and economic considerations. 7  IV Unit – M2M and IoT Technology Fundamentals  Nodes of the network must have an awareness of all nodes in the network with which they can indirectly communicate. This can be a direct connection over one link (edge, the transition or communication between two nodes over a link), or knowledge of a route to the desired (destination) node by communicating through cooperating nodes, over multiple edges.  In Figure 5.2 is the simplest form of network that requires knowledge of a route to communicate between nodes that do not have direct physical links.  if node A wishes to transfer data to node C, it must do so through node B.  Thus, node B must be capable of the following:  Communicating with both node A and node C,  advertising to node A and node C that it can act as an intermediary.  Basic networking requirements have become explicit.  It is essential to uniquely identify each node in the network, and it is necessary to have cooperating nodes capable of linking nodes between which physical links do not exist.  In modern computing, this equates to IP addresses and routing tables.  Consider the differences between streaming video from a surveillance camera, for example, and an intrusion-detection system based on a passive sensor.  Streaming video requires high bandwidth, whereas transmitting a small amount of information about the detection of an intruder requires a tiny amount of bandwidth, but a higher degree of reliability with respect to both the communications link and the accuracy of the detection.  Node A is a device that can only communicate over a particular wireless channel of limited range  Node B is cap able of communicating with node A, but also with an application server with service capabilities (node C, with which it can connect using wired Ethernet, e.g. over a complex link using a standardized protocol and/or web service such as REST at the application layer) over the Internet.  Node B may be connected to a sub-network (of child nodes, similar to node A) of up to thousands of similarly constrained devices (A1...An).  These thousands of devices may be equipped with sensors, deployed specifically to monitor some physical phenomenon.  They can only communicate with one another and node B, and may communicate with each other over single or multiple hops. 8  IV Unit – M2M and IoT Technology Fundamentals  Consider that the owner of the WSN wishes to obtain the data from each of the (A1...An) devices in the WSN.  However, the preferred way to read the data is through a web browser, or application on a smartphone/tablet, via node C.  Therefore, a networking solution is required to transfer all of the WSN data from nodes A1...An to node C, through node B.  This concept maps directly to the M2M Functional Architecture, where nodes A1...An are an M2M Area Network, node B is an M2M Gateway, and node C is representative of M2M Service Capabilities and Applications.  A Local Area Network (LAN) was traditionally distinguishable from a Wide Area Network (WAN) based on the geographic coverage requirements of the network, and the need for third party, or leased, communication infrastructure.  In the case of the LAN, a smaller geographic region is covered, such as a commercial building, an office block, or a home, and does not require any leased communications infrastructure.  WANs provide communication links that cover longer distances, such as across metropolitan, regional, or by textbook definition, global geographic areas.  In practice, WANs are often used to link LANs and Metropolitan Area Networks (MAN)  LANs tended to cover distances of tens to hundreds of meters, whereas WAN links spanned tens to hundreds of kilometers.  The most popular wired LAN technology is Ethernet. Wi-Fi is the most prevalent wireless LAN (WLAN) technology.  Wireless WAN (WWAN), as a descriptor, covers cellular mobile telecommunication networks, a significant departure from WLAN in terms of technology, coverage, network infrastructure, and architecture.  Difference between LAN and WAN S.NO LAN WAN LAN stands for Local Area Whereas WAN stands for Wide Area 1. Network. Network. LAN’s ownership is But WAN’s ownership can be private 2. private. or public. 3. The speed of LAN is While the speed of WAN is slower 9  IV Unit – M2M and IoT Technology Fundamentals S.NO LAN WAN high(more than WAN). than LAN. The propagation delay is Whereas the propagation delay in 4. short in LAN. WAN is long(longer than LAN). There is less congestion in While there is more congestion in 5. LAN(local area network). WAN(Wide Area Network). There is more fault While there is less fault tolerance in 6. tolerance in LAN. WAN. LAN’s design and While it’s design and maintenance is 7. maintenance is easy. difficult than LAN.  The current generation of WWAN technology includes LTE (or 4G) and WiMAX.  Acting as a link between LANs and Wireless Personal Area Networks (WPANs), M2M Gateway Devices typically include cellular transceivers, and allow seamless IP- connectivity over heterogeneous physical media.  In the home, the “wireless router” typically behaves as a link between the Wi-Fi (WLAN, and thus connected laptops, tablets, smartphones, etc. commonly found in the home) and Digital Subscriber Line (DSL) broadband connectivity, traditionally arriving over telephone lines. “DSL” refers to Internet access carried over legacy (wired) telephone networks, and encompasses numerous standards and variants.  “Broadband” indicates the ability to carry multiple signals over a number of frequencies, with a typical minimum bandwidth of 256 kbps.  In the office, the Wi-Fi wireless access points are typically connected to the wired corporate (Ethernet) LAN, which is subsequently connected to a wider area network and Internet backbone, typically provided by an Internet Service Provider (ISP).  The need exists to interconnect devices (generally integrated microsystems) with central data processing and decision support systems, in addition to one another.  In WLAN technologies, a geographic region can be covered by a network of devices that connect to the Internet via a gateway device, which may use a leased network connection.  For example, a gateway device can access the IP backbone over a WWAN (e.g. GPRS/UMTS/LTE/WiMAX) link, or over a WLAN link. 10  IV Unit – M2M and IoT Technology Fundamentals  WPANs is the for newer standards that govern low-power, low-rate networks suitable for M2M and IoT applications.  “IEEE 802.15.4 _ Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs).  This is similar to the evolution of Wi-Fi WLAN technology (e.g. IEEE 802.11, a, b, g, n, etc.).  Communication ranges for IEEE 802.15.4 technology may range from tens of meters to kilometers.  Devices in an M2M Area Network connect to the IP backbone, or Network Domain, via an M2M Gateway device.  Gateway device is equipped with a cellular transceiver that is physically compatible with UMTS or LTE-Advanced, for example, WWAN.  The same device will also be equipped with the necessary transceiver to communicate on the same physical medium as the M2M Area Network(s) in the M2M Device Domain.  M2M Area Networks may include a plethora of wired or wireless technologies, including: Bluetooth LE/Smart, IEEE 802.15.4 (LR-WPAN; e.g. ZigBee, IETF 6LoWPAN, RPL, CoAP, ISA100.11a, WirelessHART, etc.),  The “Internet of Things,” as a term, originated from Radio Frequency Identification (RFID) research, wherein the original IoT concept was that any RFID-tagged “thing” could have a virtual presence on the “Internet.”  RFID ,bar codes and QR codes use different technological means to achieve the same result.  M2M applications become more synonymous with IoT, it is necessary to understand the technologies, limitations, and implications of the networking infrastructure. 4.2.2 Wide area networking  WANs are typically required to bridge the M2M Device Domain to the backhaul network, thus providing a proxy that allows information (data, commands etc) to traverse heterogeneous networks.  It is used to provide communications services between the M2M service enablement and the physical deployments of devices in the field.  WAN is capable of providing the bi-directional communications links between services and devices which is achieved by means of physical and logical proxy.  The proxy is achieved using an M2M Gateway Device.  M2M Gateway Device is typically an integrated microsystem with multiple communications interfaces and computational capabilities.  It is a critical component in the functional architecture, as it must be capable of handling all of the necessary interfacing to the M2M Service Capabilities and Management Functions. 11  IV Unit – M2M and IoT Technology Fundamentals  Example: consider a device that incorporates both an IEEE 802.15.4-compliant transceiver, capable of communicating with a capillary network of similarly equipped devices, and a cellular transceiver that connects to the Internet using the UMTS network.  Transceivers (sometimes referred to as modems) are typically available as hardware modules with which the central intelligence of the device (gateway or cell phone) interacts by means of standardized AT Commands.  This device is now capable of acting as a physical proxy between the LR-WPAN, or M2M Device Domain, and the M2M Network Domain.  The latest ETSI M2M Functional Architecture is illustrated in Figure 5.3.  The Access and Core Network in the ETSI M2M Functional Architecture are foreseen to be operated by a Mobile Network Operator (MNO), and can be thought of simply as the “WAN” for the purposes of interconnecting devices and backhaul networks (Internet), thus, M2M Applications, Service Capabilities, Management Functions, and Network Management Functions.  The WAN covers larger geographic regions using wireless as well as wire-based access.  WAN technologies include cellular networks (using several generations of technologies), DSL, WiMAX, Wi-Fi, Ethernet, Satellite, and so forth.  The WAN delivers a packet-based service using IP as default. Circuit-based services can also be used in certain situations.  important functions of the WAN include: The main function of the WAN is to establish connectivity between capillary 12  IV Unit – M2M and IoT Technology Fundamentals networks, hosting sensors, and actuators, and the M2M service enablement. The default connectivity mode is packet-based using the IP family of technologies. Many different types of messages can be sent and received. for example, a message sent from a sensor in an M2M Area Network and resulting in an SMS received from the M2M Gateway or Application Use of identity management techniques (primarily of M2M devices) in cellular and non-cellular domains to grant right-of-use of the WAN resource. The following techniques are used for these purposes:  MCIM (Machine Communications Identity Module) for remote provisioning of SIM targeting M2M devices.  xSIM (x-Subscription Identity Module), like SIM, USIM, ISIM.  Interface identifiers, an example of which is the MAC address of the device, typically stored in hardware.  Authentication/registration type of functions (device focused).  Authentication, Authorization, and Accounting (AAA), such as RADIUS services.  Dynamic Host Configuration Protocol (DHCP), e.g. employing deployment-specific configuration parameters specified by device, user, or application-specific parameters residing in a directory.  Subscription services (device-focused).  Directory services, e.g. containing user profiles and various device (s) parameter(s), setting(s), and combinations thereof. M2M-specific considerations include, in particular:  MCIM (cf. 3GPP SA3 work).  User Data Management (e.g. subscription management).  Network optimizations (cf. 3GPP SA2 work). 4.2.2.1 3rd generation partnership project technologies and machine type communications  Machine Type Communications (MTC) is heavily referred to in the ETSI documentation.  MTC refers to small amounts of data that are communicated between machines (devices to back-end services and vice versa) without the need for any human intervention. In the 3rd Generation Partnership Project (3GPP), MTC is used to refer to all M2M communication. 4.2.3 Local area networking  Capillary networks are typically autonomous, self-contained systems of M2M devices that may be connected to the cloud via an appropriate Gateway. 13  IV Unit – M2M and IoT Technology Fundamentals  They are often deployed in controlled environments such as vehicles, buildings, apartments, factories, bodies, etc. (Figure 5.4) in order to collect sensor measurements, generate events should sensing thresholds be breached, and sometimes control specific features of interest (e.g. heart rate of a patient, environmental data on a factory floor, car speed, air conditioning appliances, etc.).  There will exist numerous capillary networks that will employ short-range wired and wireless communication and networking technologies.  For certain application areas, there is a need for autonomous local operation of the capillary network.  In the event that application-level logic is enforceable via the cloud, some will still need to be managed locally.  The complexity of the local application logic varies by application.  For example, a building automation network may need local control loop functionality for autonomous operation, but can rely on external communication for configuration of control schemas and parameters.  The M2M devices in a capillary network are typically thought to be low-capability nodes (e.g. battery operated, with limited security capabilities) for cost reasons, and should operate autonomously.  For this reason, a GW/application server will naturally also be part of the architected solution for capillary networks.  More and more (currently closed) capillary networks will open up for integration with the enterprise back end systems.  For capillary networks that expose devices to the cloud/Internet, IP is envisioned to be the common waist. 14  IV Unit – M2M and IoT Technology Fundamentals  IPv6 will be the protocol of choice for M2M devices that operate a 6LoWPAN-based stack.  IPv4 will still be used for capillary networks operating in non-6LoWPAN IP stacks (e.g. Wi-Fi capillary networks).  In terms of short-range communication technology convergence, an IPv6 stack with 6LoWPAN running above the physical medium is expected.  The development of the IEEE 802.15.4g standard, a physical layer amendment to support Smart Utility Networks (SUN) _ smart grid in particular _ designed to operate over much larger geographic distances (wireless links spanning tens of kilometers), and specifically designed for minimal infrastructure, low power, many-device networks. 4.2.3.1 Deployment considerations  There are increasing numbers of innovative IoT applications (hardware and software) marketed as consumer products.  These range from intelligent thermostats for effectively managing comfort and energy use in the home, to precision gardening tools (sampling weather conditions, soil moisture, etc.).  Scaling up for industrial applications and moving from laboratories into the real world creates significant challenges that are not yet fully understood.  Low-rate, low-power communications technologies are known to be “lossy.” The reasons can relate to environmental factors, which impact upon radio performance, technical factors such as performance trade-offs based on the characteristics of medium access control and routing protocols, and physical limitations of devices (including software architectures, runtime and execution environments, computational capabilities, energy availability, local storage, etc), and practical factors such as maintenance opportunities (scheduled, remote, accessibility, etc.).  Numerous deployment environments (factories, buildings, roads, vehicles) are expected in addition to wildly varying application scenarios and operational and functional requirements of the systems.  ETSI describes a set of use cases, namely eHealth, Connected Consumer, Automotive, Smart Grid, and Smart Meter, that only capture some of the breadth of potential deployment scenarios and environments that are possible.  Assuming that IP connectivity can be the fundamental mechanism to bridge heterogeneous physical and link layer technologies, it stands to reason that fragmentation can continue such that appropriate technologies are available for the breadth of potential application scenarios. 4.2.3.2 Key technologies  Power Line Communication (PLC) refers to communicating over power (or phone, coax, etc.) lines. 15  IV Unit – M2M and IoT Technology Fundamentals  This amounts to pulsing, with various degrees of power and frequency, the electrical lines used for power distribution.  PLC comes in numerous flavors. At low frequencies (tens to hundreds of Hertz) it is possible to communicate over kilometers with low bit rates (hundreds of bits per second). Typically, this type of communication was used for remote metering, and was seen as potentially useful for the smart grid.  Enhancements to allow higher bit rates have led to the possibility of delivering broadband connectivity over power lines.  There have been a number of attempts to standardize PLC in recent years. NIST recently included IEEE 1901 and ITU-T G.hn as standards for further review for potential use in the smart grid in the United States.  LAN (and WLAN) continues to be important technology for M2M and IoT applications.  This is due to the high bandwidth, reliability, and legacy of the technologies. Where power is not a limiting factor, and high bandwidth is required, devices may connect seamlessly to the Internet via Ethernet (IEEE 802.3) or Wi-Fi (IEEE 802.11).  The IEEE 802.11 (Wi-Fi) standards continue to evolve in various directions to improve certain operational characteristics depending on usage scenario.  A widely adopted recent release was IEEE 802.11n, which was specifically designed to enhance throughput (typically useful for streaming multimedia).  Ongoing work such as IEEE 802.11ac is developing an even higher throughput version to replace this, focusing efforts in the 5 GHz band.  IEEE 802.11ah is allow a number of networked devices to cooperate in the ,1 GHz (ISM) band.  The idea is to exploit collaboration (relaying, or networking in other words) to extend range, and improve energy efficiency (by cycling the active periods of the radio transceiver).  Bluetooth Low Energy (BLE; “Bluetooth Smart”) is designed for short-range (,50 m) applications in healthcare, fitness, security, etc., where high data rates (millions of bits per second) are required to enable application functionality.  It is deliberately low cost and energy efficient by design, and has been integrated into the majority of recent smart phones.  Low-Rate, Low-Power Networks are another key technology that form the basis of the IoT.  For example, the IEEE 802.15.4 family of standards was one of the first used in practical research and experimentation in the field of WSNs.  Low-Rate Wireless Personal Area Networks (LR-WPAN)- It covered the Physical and Medium Access Control layers, specifying use in the ISM bands at frequencies around 433 MHz, 868/915 MHz, and 2.4 GHz. This supported data rates of between 20 kbps up to 256 kbps, depending on selected band, over distances ranging from tens of meters to kilometers. 16  IV Unit – M2M and IoT Technology Fundamentals  Radio duty cycling refers to managing the active periods of the Radio Frequency Integrated Circuit (RFIC) during transmission, and listening to the medium.  IEEE 802.15.4 defines the PHY layer, and in some instances the MAC layer, upon which a number of low-energy communications specifications have been built. Namely, ZigBee.  Recent developments, such as the PHY Amendment for Smart Utility Networks (SUN), IEEE 802.15.4g, seek to extend the operational coverage of these networks up to tens of kilometers in order to provide extremely wide geographic coverage with minimal infrastructure.  6LoWPAN (IPv6 Over Low Power Wireless Personal Area Networks) was developed initially by the 6LoWPAN Working Group (WG) of the IETF as a mechanism to transport IPv6 over IEEE 802.15.4-2003 networks.  Specifically, methods to handle fragmentation, reassembly, and header compression were the primary objectives.  The WG also developed methods to handle address autoconfiguration, the hooks for mesh networking, and network management.  RPL (IPv6 Routing Protocol for Low Power and Lossy Networks) was developed by the IETF Routing over Low Power and Lossy Networks (RoLL) WG.  They defined Low Power Lossy Networks as those typically characterized by high data loss rates, low data rates, and general instability.  No specific physical or medium access control technologies were specified, but typical links considered include PLC, IEEE 802.15.4, and low-power Wi-Fi.  Typical use cases involve the collection of data from many (for example) sensing points, nodes towards a sink, or alternatively, flooding information from a sink to many nodes in the network.  Thus, the well-known concept of a Directed Acyclic Graph (DAG) structure was concentrated to a Destination Oriented DAG (DODAG) for the purposes of initial development.  The group defined a new ICMPv6 message, with three possible types, specific for RPL networks.  These include a DAG Information Object (DIO), that allows a node to discover an RPL instance, configuration parameters and parents, a DAG Information Solicitation (DIS) to allow requests for DIOs from RPL nodes, and Destination Advertisement Object (DAO), used to propagate destination information upwards (i.e. towards the root) along the DODAG (specific RPL details are available in RFC 6550 and related RFCs).  The Trickle Algorithm is an important enabler of RPL message exchange.  CoAP (Constrained Application Protocol) is being developed by the IETF Constrained RESTful Environments (CoRE) WG as a specialized web transfer protocol for use with severe computational and communication constraints typically characteristic of M2M and IoT applications. 17  IV Unit – M2M and IoT Technology Fundamentals 4.3 Data management 4.3.1 Introduction  In the era of M2M, where billions of devices interact and generate data at exponential growth rates, data management is of critical importance as it sets the basis upon which any other processes can rely and operate  Some of the key characteristics of M2M data include: Big Data: Huge amounts of data are generated, capturing detailed aspects of the processes where devices are involved. Heterogeneous Data: The data is produced by a huge variety of devices and is itself highly heterogeneous, differing on sampling rate, quality of captured values, etc. Real-World Data: The overwhelming majority of the M2M data relates to real- world processes and is dependent on the environment they interact with. Real-Time Data: M2M data is generated in real-time and overwhelmingly can be communicated also in a very timely manner. Temporal Data: The overwhelming majority of M2M data is of temporal nature, measuring the environment over time. Spatial Data: Increasingly, the data generated by M2M interactions are not only captured by mobile devices, but also coupled to interactions in specific locations, and their assessment may dynamically vary depending on the location. Polymorphic Data: The data acquired and used by M2M processes may be complex and involve various data, which can also obtain different meanings depending on the semantics applied and the process they participate in. Proprietary Data: Up to now, due to monolithic application development, a significant amount of M2M data is stored and captured in proprietary formats. However, increasingly due to the interactions with heterogeneous devices and stakeholders, open approaches for data storage and exchange are used. Security and Privacy Data Aspects: Due to the detailed capturing of interactions by M2M, analysis of the obtained data has a high risk of leaking private information and usage patterns, as well as compromising security.\ 4.3.2 Managing M2M data 18  IV Unit – M2M and IoT Technology Fundamentals  The data flow from the moment it is sensed (e.g. by a wireless sensor node) up to the moment it reaches the backend system has been processed manifold (and often redundantly), either to adjust its representation in order to be easily integrated by the diverse applications, or to compute on it in order to extract and associate it with respective business intelligence (e.g. business process affected, etc.).  In Figure 5.5, we see a number of data processing network points between the machine and the enterprise that act on the datastream (or simply forwarding it) based on their end- application needs and existing context.  Dealing with M2M data may be decomposed into several stages.  Additionally, the degree of focus in each stage heavily depends on the actual usage requirements put upon the data as well as the infrastructure. 4.3.2.1 Data generation  Data generation is the first stage within which data is generated actively or passively from the device, system, or as a result of its interactions.  The sampling of data generation depends on the device and its capabilities as well as potentially the application needs.  Usually default behaviors for data generation exist, which are usually further configurable to strike a good benefit between involved costs, e.g. frequency of data collection vs. energy used in the case of WSNs, etc. 19  IV Unit – M2M and IoT Technology Fundamentals 4.3.2.2 Data acquisition  Data acquisition deals with the collection of data (actively or passively) from the device, system, or as a result of its interactions.  The data acquisition systems usually communicate with distributed devices over wired or wireless links to acquire the needed data, and need to respect security, protocol, and application requirements.  The nature of acquisition varies, e.g. it could be continuous monitoring, interval-poll, event-based, etc.  The frequency of data acquisition overwhelmingly depends on, or is customized by, the application requirements (or their common denominator).  The data acquired at this stage (for non-closed local control loops) may also differ from the data actually generated.  In simple scenarios, due to customized filters deployed at the device, a fraction of the generated data may be communicated.  Data aggregation and even on-device computation of the data may result in communication of key performance indicators of interest to the application. 4.3.2.3 Data validation  Data acquired must be checked for correctness and meaningfulness within the specific operating context.  This is usually done based on rules, semantic annotations, or other logic.  The acquired data may not conform to expectations and data may be intentionally or unintentionally corrupted during transmission, altered, or not make sense in the business context.  As real-world processes depend on valid data to draw business-relevant decisions  Several known methods are deployed for consistency and data type checking;  for example, imposed range limits on the values acquired, logic checks, uniqueness, correct time-stamping, etc.  In addition, semantics may play an increasing role here, as the same data may have different meanings in various operating contexts, and via semantics one can benefit while attempting to validate them.  Another part of the validation may deal with fallback actions such as requesting the data again if checks fail, or attempts to “repair” partially failed data.  Failure to validate may result in security breaches.  Tampered-with data fed to an application is a well known security risk as its effects may lead to attacks on other services, privilege escalation, denial of service, database corruption, etc. 20  IV Unit – M2M and IoT Technology Fundamentals 4.3.2.4 Data storage  The data generated by M2M interactions is what is commonly referred to as “Big Data.”  Machines generate an incredible amount of information that is captured and needs to be stored for further processing.  As this is proving challenging due to the size of information, a balance between its business usage vs. storage needs to be considered; that is, only the fraction of the data relevant to a business need may be stored for future reference.  However, one has to carefully consider what the value of such data is to business not only in current processes, but also potentially other directions that may be followed in the future by the company as different assessments of the same data may provide other, hidden competitive advantages in the future.  Due to the massive amounts of M2M data, as well as their envisioned processing (e.g. searching), specialized technologies such as massively parallel processing DBs, distributed file systems, cloud computing platforms, etc. are needed. 4.3.2.5 Data processing  Data processing enables working with the data that is either at rest (already stored) or is in-motion (e.g. stream data).  The scope of this processing is to operate on the data at a low level and “enhance” them for future needs.  Typical examples include data adjustment during which it might be necessary to normalize data, introduce an estimate for a value that is missing, re-order incoming data by adjusting timestamps, etc.  Similarly, aggregation of data or general calculation functions may be operated on two or more data streams and mathematical functions applied on their composition.  Another example is the transformation of incoming data; for example, a stream can be converted on the fly (e.g. temperature values are converted from _F to _C), or repackaged in another data model, etc. Missing or invalid data that is needed for the specific time-slot may be forecasted and used until, in a future interaction, the actual data comes into the system. 4.3.2.6 Data remanence  Even if the data is erased or removed, residues may still remain in electronic media, and may be easily recovered by third parties _ often referred to as data remanence.  Several techniques have been developed to deal with this, such as overwriting, degaussing, encryption, and physical destruction.  For M2M, not only the DBs where the M2M data is collected, but also the points of action, which generate the data, or the individual nodes in between, which may cache it. 21  IV Unit – M2M and IoT Technology Fundamentals  At the current technology pace, those buffers (e.g. on device) are expected to be less at risk since their limited size means that after a specific time has elapsed, new data will occupy that space; hence, the window of opportunity is rather small.  In addition, for large-scale infrastructures the cost of potentially acquiring “deleted” data may be large; hence, their hubs or collection end-points, such as the DBs who have such low cost, may be more at risk. 4.3.2.7 Data analysis  Data available in the repositories can be subjected to analysis with the aim to obtain the information they encapsulate and use it for supporting decision-making processes.  The analysis of data at this stage heavily depends on the domain and the context of the data.  For instance, business intelligence tools process the data with a focus on the aggregation and key performance indicator assessment.  Data mining focuses on discovering knowledge, usually in conjunction with predictive goals.  Statistics can also be used on the data to assess them quantitatively (descriptive statistics), find their main characteristics (exploratory data analysis), confirm a specific hypothesis (confirmatory data analysis), discover knowledge (data mining), and for machine learning, etc.  This stage is the basis for any sophisticated applications that take advantage of the information hidden directly or indirectly on the data. 4.3.3 Considerations for M2M data  The M2M infrastructure in place heavily depends on real-world processes, implying also that a big percentage of data will be generated by machines that interact with the real- world environment, while the rest will be purely virtual data.  Many of the machines generating this data, which can then be communicated to others (e.g. analytics specialists).  The end-beneficiaries might acquire information, but do not necessarily need to have access or to process the data by themselves.  There is a rise of specialists in the various stages of M2M data management that will cooperate with application providers, users, etc. for the common benefit.  Sharing of data and usage in multiple applications, security and trust are of key importance.  Security is mandatory for enabling confidentiality, integrity, availability, authenticity, and nonrepudiation of data from the moment of generation to consumption.  Due to the large-scale IoT infrastructure, heterogeneous devices, and stakeholders involved, this will be challenging. 22  IV Unit – M2M and IoT Technology Fundamentals  In addition, trust will be another major issue, as even if data is securely communicated or verified, the level of trust based on them will impact the decision-making process and risk analysis.  Managing security and trust in the highly federated M2M-envisioned infrastructures poses a significant challenge, especially for mission critical applications that also exercise control.  Privacy is also expected to be a significant issue in IoT infrastructures.  Currently, a lot of emphasis is put on acquiring the data, and no real solutions exist for large-scale systems to share data in a controlled way.  Once data is shared, the originator has no more control over its lifetime.  A typical example here constitutes the usage of private citizen data, which could be controllably shared as wished; it should also be possible to (partially) revoke that right at will.  Data Science in the IoT era is a cross-discipline approach building on mathematics, statistics, high-performance computing, modeling, machine learning, engineering, etc. that will play a key role in understanding the data, assessing their information at large scale, and hopefully enabling the better studying of complex systems of systems and their emergent characteristics. 4.3.4 Conclusions  Data and its management hold the key to unveiling the true power of M2M and IoT.  To do so, however, we have to think and develop approaches that go beyond simple data collection, and enable the management of their whole lifecycle at very large scale, while in parallel considering the special needs and the usage requirements posed by specific domains or applications. 4.4 Business processes in IoT 4.4.1 Introduction  A business process refers to a series of activities, often a collection of interrelated processes in a logical sequence, within an enterprise, leading to a specific result.  There are several types of business processes such as management, operational, and supporting, all of which aim at achieving a specific mission objective.  As business processes usually span several systems and may get very complex, several methods and techniques have been developed for their modeling, such as the Business Process Model and Notation (BPMN), which graphically represents business processes in a business process model. 23  IV Unit – M2M and IoT Technology Fundamentals  Several key business processes in mod