One IoT: an IoT protocol and framework for OEMs to make IoT-enabled devices forward compatible
- 2.3k Downloads
Internet of Things (IoT) paradigm is going to imbue and become ubiquitous in everyday living, ranging from generic household, healthcare, public utility to defence applications. The IoT as a technology realm is witnessing advancement at a lightning speed. Consequently, there is a growing number of IoT-related reference architectures, frameworks, guidelines, platforms and standards. For IoT vendors and original equipment manufacturers (OEMs), however, such evolving IoT landscape means bountiful amounts of both opportunities and risks. The same holds for the consumers who are going to buy such products. We present an IoT framework and protocol that is unconditionally forward compatible. Our work defines the minimal criteria for a device to qualify as an IoT-enabled device, which could be taken as reference by IoT OEMs to build their IoT devices accordingly, across varied applications and domains. Such knowledge could help them make an informed choice amongst various available target hardware. With this protocol, it is possible to generate user interface/s on the fly, as per the devices’ functionalities.
KeywordsInternet of things Reference architecture Forward compatibility IoT Protocol Application layer Security
Cascaded successes of various information and communication technologies (ICT)—together with their reducing cost—and maturity in sensor and actuator technologies led to the birth of Internet of Things paradigm. The paradigm of Internet of Things (IoT) is taking automation and control to new heights. IoT is disrupting everyday living, manufacturing industries, defence systems, healthcare, etc. Estimates forecast the IoT device number—not counting mobile phones—crossing 8 Billion by the year 2020 . Furthermore by 2032, Industrial Internet is poised to cross $10–$15 trillion worth .
IoT is all about connected systems via internet that can both provide real time data, and handle requests based on this real time data to make everyday systems act more intelligent. Here ‘Things’ are physical objects consisting of processor/s, sensor/s and/or actuator/s with some intelligence either in situ or ex situ . Though at core, IoT is all about connected things and their access via internet, implementing IoT-based solutions is very challenging. The foremost challenges are due to the heterogeneity factor inherent with the IoT. There is heterogeneity in application domains, hardware and requirements from diverse perspectives. Due to this heterogeneity, IoT happens to be the only technology that has several definitions . Besides this heterogeneity, since connectivity and energy consumption is involved and information processing opens venues for various sophisticated analytics , there are functional requirements based on rich analytics and non-functional requirements around security and minimal energy consumption and harvesting. Such challenges—due to heterogeneity, functional and nonfunctional requirements—can be addressed by defining IoT reference architectures, frameworks, guidelines, protocols and standards.
To address the challenges posed by the IoT paradigm, several consortia have comeup—with partners having expertise in various convergent technologies—and are working towards developing IoT reference architectures, frameworks and protocols. Some individual companies have released developer platforms and ecosystem based on certain reference architectures. For instance, ThingWorx is one such system released by PTC . Open Interconnect Consortium (OIC) has recently released a reference IoT architecture  as well. The Industrial Internet Reference Architecture (IIRA) is a reference architecture for industrial IoT  catering for the manufacturing sector. Identifying the gravity of this drastically changing IoT paradigm, several nations have released their own IoT policies , and founded working groups involving their own national academic and industrial experts in the related and relevant ICT areas. Several efforts means several non-unified frameworks. Consequently, several reference frameworks would only mean postponement of heterogeneity due to multiple disjoint frameworks.
In this dynamic IoT landscape, no unified protocol exists to support for diverse IoT-based devices . For this very reason, several IoT device OEMS—standing at the crossroads of evolving protocols and frameworks—have bountiful options that might be opportunities or risks, which can only be decided by time. The current situation of the IoT device OEMs is similar to that of the DVD-vendors during the Blu-ray Vs. HD-DVD war.1 On the other receiving end are IoT device consumers or end users with dilemma about which IoT-enabled device to buy. Again, the situation of these IoT consumers is comparable to that of the DVD discs’ and players’ consumers during the same period. Moreover, majority of these upcoming frameworks are trying to address several issues in a single go, which from an OEM perspective is too much to deliver from one single OEM. It is always good to have a robust ecosystem, but then this requires pacts between various vendors that is wishful thinking.
Therefore, in this paper, we present an operational framework and an affiliated protocol which could be a guideline for IoT-related OEMs on how to make their devices qualify as IoT-enabled devices. This protocol allows discovery, advertisement, invocation, and configuration of IoT devices. Such steps would allow the protocol to adapt to many scenarios where it may find an application, as the protocol has the ability to learn any device’s capabilities on the fly which is done through a ’probing’ mechanism as described later. The protocol, though caters human-in-the-loop kind of interaction, is fairly usable for Machine to Machine (M2M) interaction as well. We also describe the end to end message format used in the communication. This protocol addresses some security hurdles faced in the IoT paradigm by its integrated approach. We then demonstrate a system architecture that may be used on an IoT device that leverages our protocol, to create full-fledged IoT ecosystems and take support of existing IoT ecosystems with sufficient plumbing in place.
In this section, we will discuss a few preliminary concepts that forms basis for our framework and protocol. Here we also give our definition of IoT.
2.1 Embedded system
Embedded systems are microcontroller-based electronic control systems together with one or more sensors and/or actuators. They are often embedded in a larger entity to control/monitor their operation. This embedding entity serves the main functionality to the end user. For example, in a smart air conditioner, air conditioner (AC) is the entity and the smart controller is the embedded system. Here the end function of AC is to condition the air as per user requested temperature. The embedded system comprises: microcontroller executing the control law; thermometer and hygrometer as sensors to read temperature and humidity, respectively, and control switches to cooling system as the actuators.
2.1.1 Sensors and actuators
Sensors and actuators are the bridging links between digital and physical worlds. They are the end interfaces that make it possible to access status and control operations of IoT-enabled devices. Sensors detect changes in measurable quantities of the environment around it, and relay this information back as a signal. Actuators on being activated with a signal generate a physical stimulus in its environment.
2.2 Internet of things
(Internet of Things) A world wide network of interconnected embedded devices that are natively (Internet Protocol) IP-enabled, hence interconnectable and uniquely addressable based on standard communication protocols. It also includes internet services monitoring and controlling those devices.
Internet connectivity layer
Cloud layer and
(IoT node) IoT node is an embedded device comprising a microcontroller with IP network interface and sensors and/or actuator/s. It also includes the embedding entity.
2.3 Minimum framework
There are a wide variety of definitions for IoT paradigm as reported in . But in this paper we give a minimum framework that leaves room to develop IoT-based applications as per any of those definitions using appropriate plugins and additional layers.
to its end user the kind of remote-host service we present in our later sections and
the IoT node with certain minimum behaviour which is detailed below.
2.4 Minimum behaviour from an IoT node
receiving the commands from authorised remote host/s and user agent/s (via wired and/or wireless media)
execute the commands accordingly and
periodically reporting operational status and sensor information to authorised remote host/s.
2.5 Protocol entities
The proposed protocol operates on the application layer and is theoretically communication medium independent. This protocol involves three entities: an IoT device, User Agent (Client), and Cloud. User agent is a client interface here for the IoT device users. Smartphones could be user agents with an appropriate app or web browser as the client interface. We developed an app for Android-based phones which generates an User interface on the fly to control the IoT device.
The Client is essentially a host machine that allows remote access to IoT devices using various communication media including, but not limited to Wi-Fi and Bluetooth. Such client typically functions as a dashboard for end users to manage their IoT device. However, same clients may exist as bridge nodes as well to support inter-device communication from the point of view of our protocol. This is discussed in Sect. 9.
A Cloud, on which the remote-host is running, is a necessity here to keep track of large number of IoT devices and their mapping to the authorised users. Since our protocol could be integrated into any other ecosystem, such extensibility could be easily achieved via cloud through this host. To use the protocol via the Internet, a Cloud network first provides user accounts to help users keep track of their IoT devices, and to grant or revoke access to IoT devices owned by them. All such users who have access rights of an IoT device are called authorised users. Further, the cloud also makes possible seamless communication to IoT devices which may not be on a static IP address. This is detailed in Sect. 4.
Discovery and Registration of IoT-enabled devices and
Advertisement of a Thing’s capabilities.
Invocation of a Thing’s operations and
Configuration changes of the Thing can be carried out.
Before any communication can actually take place, discovery of available nodes to communicate with is a vital part of any protocol. Therefore, the DISCOVERY method performs a local scan via Wi-Fi, Ethernet over LAN, Bluetooth and other short ranged protocols. This discovery phase would not be applicable for IP-based communication. The discovery involving IP-based communication is explained through the next phase. Further, discovery can be overridden with local settings, if the IoT device has been chosen to be invisible by the respective owner.
Typically, we can communicate with an IoT device once we have its IP address and key. The concept of key will be explained later. However, if the device is not on a static IP address, it becomes mandatory to keep track of its current IP address, which is not a trivial task. Our protocol addresses this problem as well, as described in Sect. 4. To achieve this securely, on Cloud corresponding web host maintains a many-to-many relationship between Things and their authorised Users. To add a new Thing-User relationship to this mapping, we have the ’REGISTER’ request. Whenever a user wants to add a new Thing in his/her Thing account (held on the cloud), he/she has to send his access credentials, Thing-ID and Thing-key. Figure 3 illustrates the sequence during Registration.
(Thing-ID) Thing-ID is a unique identifier provided by the vendor of the IoT device.
This Thing-ID is something similar to EPC.
(Thing-Key) Thing-Key is a private secret code of sufficient length.
In this paper, we consider a key of length 128-bits. This key shall be provided by the OEMs. It is conceptually similar to bank users receiving a pincode for their debit and/or credit cards.
The operations offered by the given IoT device and
The expected way to invoke any specific operation on that IoT device.
Another use-case for IoT devices includes configuration updates: changes in protocol variables and server parameters. Configuration updates that change core functionality of IoT devices should be addressed by appropriate Invocation requests, supplied by the manufacturer. Other configurations that are generic and not implementation specific, are addressed by the ’CONFIGURE’ method of the protocol. These changes include changes to tick rates, security parameters and other protocol variables. These protocol variables are explained later. The main reason these variables should be altered is to improve performance metrics of these devices relative to their use case. Since a wide array of IoT devices would take over the technology market soon, with applications of varying uses, each implementation would have their own ’sweet spot’ metrics, with some implementations not being time critical, and thus being conservative on their power requirements, while others being extremely time critical at the cost of a little extra power consumption. The CONFIGURE method exactly serves for this cause.
4 Communication media
Dynamic Addressed Media, including those which operate on addresses that are subject to change, such as the Internet which operates on dynamic IP addresses assigned by Internet Service Providers (ISP).
In this section, we will look at some of the security aspects of the protocol that would otherwise leave it vulnerable to exploitation. We are inclined to a security policy that promises safety and availability. Security is a big concern [15, 16] for the IoT paradigm in general. Our protocol covers security from the perspective2 of IoT device security and associated data security. IoT paradigm essentially involves web-based abstractions and/or interfaces for physical devices, exploitation of these devices would not only cause the loss of data, but also the loss of fidelity of the associated physical systems . When the IoT device numbers are in the order of billions , it results in chaos. Therefore, security should be natively built into IoT-based solutions , and thus IoT solutions should offer at least a level of robustness that could be affordable from the available processing power of the IoT device. Since the processing power with an IoT device can be limited, security can also be provided as a service from cloud. Our protocol provides security that is affordable with IoT devices. Besides constrained processing power, affordability is defined by the available energy and bandwidth.
In the proposed protocol, we have strong urge and need to encrypt ’raw’ packet data from end to end, with accepted encryption standards of sufficient encryption entropy. The only fields worth exposing in plain text include a header describing the protocol name and version, along with the encryption type used. As mentioned in Sect. 4, communication is only possible: post successful registration that would distribute an authorisation key, post registration for communication. The authorisation key itself could be the device key, or an OAuth3 like key, generated by the cloud which can be revoked as and when needed, to better support multi-client ecosystems and is recommended. Encryption must be performed whenever data is exchanged between two entities, and for maximum protection, a different key must be used for each entity pair.
Another key security aspect to consider whilst designing a secure packet, is the presence of a salt , to further strengthen the encryption which is inevitable in the IoT ecosystem. Consider the scenario where an attacker taps into a private network and sniffs encrypted packets used to communicate with IoT devices. Considering a saltless encryption, the packets used would lack sufficient entropy, as the cipher-text of any invocation packet would not change as long as the plain text or the actual request itself remains the same. This would allow the attacker to correlate the encrypted packets to the physical outcomes performed by the IoT devices either manually or by deployment of Trojan sensors in situ. Either way, the outcomes would be cracked without the need of cracking the encryption itself, thus nullifying the complete encryption process. A salt that would consist of a well generated random number would help make the encryption much stronger by increasing the entropy of the cipher-text by multiple orders of magnitude.
Another attack vector for IoT devices are Dos and/or DDoS attacks [18, 19], because of their taxing nature even on full-fledged servers, DDoS prevention at IoT device level is difficult. However, DDoS attacks can still be countered by rerouting requests to a cloud with one of the several existing state-of-the-art DDoS filter services to prevent direct attack mechanisms on smaller embedded IoT devices, which would otherwise cripple because of their limited hardware capacity. One way to achieve this would be to implement minimal logging support on the IoT device which would report failed attempts at the communication step, and the source IP address to the cloud that would then log these failed attempts, and relay these to a DDoS detection filter in real time, which would then analyse the logged requests with recent history of logs from the same source IP address (or a range of certain IP addresses), and classify the request as genuine or malicious, and accordingly relay instructions to the IoT device to block incoming connections from the malicious source.  proposes a technique to identify DDoS attacks.
6 Message structures
After elaborating on the protocol itself, we will now substantiate on how exactly the protocol will actually be transmitted on the network. In this section, we will establish the application level packet structures and byte sizes that are sent on the wire, taking into consideration all the proposals made so far. As mentioned earlier, security would be a vital part of the protocol, thus most parts of the messages would be encrypted leaving a small unencrypted header which would identify the protocol name, version, and the encryption type used. The Response message would contain an additional unencrypted header Status. Also, the encryption would be salted, to increase the entropy of the resulting digest and making it harder to crack, as explained in Sect. 5.
6.1 Payload structures
The payload structure for each of the type of message allowed in our protocol as described in the Sects. 3 and 4, are concertised in the below subsections. Figures 8, 9, 10, 11, 12, 13, 14, 15, 16 and 17 illustrate various payloads explained in the following.
6.1.1 Discovery payload
6.1.2 Registration payload
Registration payload contains information that is required during the registration process: including the Thing-ID, and Key combo in the Request, and Authorisation Keys if any in the response.
6.1.3 Advertisement payload
Advertisement payload contains the data shared during the advertisement phase that is only the parseable format in the response.
The request payload contains a single byte which identifies that the message is of the type PROBE.
The response payload will contain the details of metadata of the thing and operations it provides in a parseable format, which could be a verbose string format like XML/JSON or a more compact format like BSON.
6.1.4 Invocation Payload
Invocation Payload contains information necessary to handle a specific service/operation. The request includes Invocation token along with the required inputs, and the response includes corresponding outputs.
The first byte of the request payload identifies that the message is of the type INVOKE. The next byte of the payload represents the size of the string Operation Name, the actual bytes of which would follow next. The next byte represents the number of arguments following, each of which contain one byte representing the data size of the argument and the argument itself.
The response is formatted in a similar fashion, with each output having the first byte representing the size of output followed by the byte data of the actual output.
6.1.5 Configuration payload
Configuration payload has configurations information, and consists of param-name and param-value pairs in the request payload, while the response would contain the final configuration of the Thing.
The first byte of the request payload identifies that the message is of the type CONFIG. The next byte of the payload represents the number of config changes being requested, with the actual requests following next. Each of the config requests contain a key-value pair: both of which begins with one byte representing the data size of the key/value, followed by those many bytes of the key/value itself.
The response is formatted in a similar fashion, with each key-value pair representing the new, updated config data.
6.1.6 Heartbeat packet
6.1.7 New address payload
7.1 Basic simulation: to analyse communication flows
The objective of the first experiment we conducted was to test the integrity of various communication flows and the overall behaviour of the protocol. For this, we planned to carry out the experiment with a handful of commonly used sample Things. Also, since we are not concerned about any potential hardware specific problems of Things, we experimented with simulated models of Things instead of real hardware. Each thing is modelled as a process. The process models phases of the Things’ operation cycle: initialisation step, functionality step, interaction step and termination step, corresponding to: booting of the IoT device, delivering the functionality, waiting & listening for the client requests and shutdown, respectively. We modelled various types of Things, such as Microwave, Washing Machine, Fridge, along with that of an instance one each of Client and Cloud. Thus, the simulation setup consisted of a set of processes running on different computers connected via internet. On such a simulation setup, we tested various communication flows corresponding to various use-cases and scenarios.
Our experimental simulation setup consisted of multiple computers, one corresponding to a particular Thing acting as an IoT node, another acting as a Client. Each of the Things and Client were written in Python  using the Twisted framework , and are essentially processes able to communicate through the Internet. For Cloud node, we deployed it on an Amazon Web Service’s Elastic Compute Cloud (AWS EC2) instance, making it run on a static IP address. Thus, all in all we had three different types of processes corresponding to things, clients and cloud in our framework, each running on a different host.
We initially experimented with the IP Handling flow described earlier, on a single machine by running three different processes to emulate each of the following: the Cloud, a Client and a Thing. The Cloud and the Thing simulations act as servers, with the Cloud always listening on a fixed port. The Thing, however, listening on a random port which changes periodically. This is to simulate IP address changes / reallocations which occur on the Internet. The Client process works like a shell, allowing commands of the form (target, opcode), which would relay messages to the target address stored in cache locally. If the address lease of the target has expired, then the request would result in a timeout, protocol mismatch, or authorisation failure, as explained in earlier sections. This is followed by a ’GETADDRESS’ request to the cloud to get the new address (if address has changed), and request the same service on the new address.
Figure 22, for example, shows one of such experiments where IoT node used is a model of Fridge, and the communication flow which is being tested is the IP Handling flow. The image shows the simulation corresponding to the scenario when where the Fridge had an IP address change from some earlier address to http://localhost:8388. It can be seen only when the Client tries to connect to Fridge. It first fails as it tries to connect to the earlier IP address, but then realises this and sends a request to the cloud to get the new address being used by the Fridge. Cloud has the knowledge of the current IP address of the Fridge because of the periodic heartbeat sent by the Fridge, and hence responds with this information to the Client. With the new address available, Client now sends the request again on the new address, this time succeeding to connect to it. This confirms the expected operation of our protocol.
7.2 Example client (android application)
7.3 IoT hardware setup
The goal of the final experiment is to replicate the exact scenario of how the end deliverables might be actually used. For this, we had run the proposed protocol on the actual hardware devices. Our setup consists of one Client node, one IoT node and a Cloud. The Client node is an android application we developed which includes the implementation of protocol, specific to a client node. The android phones, which we used for testing purposes include Samsung GT-N7000 and Samsung GT-i9300, both running Android 6.0.1. The IoT node is a smart bulb, which is a configurable LED with certain functionality. This LED bulb can be configured regarding its blinking frequency, colour of the light from LED via changing the Red, Green and Blue component values, etc. Furthermore, it can report whether it is turned ON or OFF.
8 Related work
The work in the field of IoT has been very diverse. There are a multitude of protocols being developed by various research groups, both from industry and academia. Constrained Applications Protocol (CoAP)  is one such protocol that has gained broad popularity. There is also a software framework, being developed by the AllSeen Alliance, known as the AllJoyn Framework . Although started by Qualcomm, many established organisations are now collaborating towards it, including companies such as Cisco, Sony, LG, Microsoft and Panasonic. Currently AllJoyns source code has been signed over to the Linux Foundation and is under a very active development. There are also many proprietary organisations contributing to the field of IoT. Wigwag  is one such IoT Platform. There exists dense collection of IoT frameworks , platforms  and standards  proposed by many consortia which can be consulted in . Majority of them have no flexibility and forward compatibility as offered by our protocol. One example for flexibility in our protocol is generation of user interface (at the client side) on the fly depending on the operations defined in the manifest. The forward compatibility of our protocol is due to the abstraction defined in our framework. No matter what the technology landscape might look like, it always consists of the entities—in one form or the other—as defined in our framework. This brings in the unconditional forward compatibility of the IoT devices, which are implemented as per our framework and protocol.
RFC 7252  defines CoAP as “The Constrained Application Protocol (CoAP) is a specialised web transfer protocol for use with constrained nodes and constrained networks in the Internet of Things. The protocol is designed for M2M applications such as smart energy and building automation...”. CoAP is heavily inspired by the simplicity and versatility of representational state transfer (REST) style of the usage of HTTP. While being consistent to RESTful principles, CoAP also adds specialised features like support to multicast messages. Though such multicast feature is useful in group communications, it has poor reliability. For this reason, it exploits unicast via an intermediate agent that interacts with the members of a group. Like our protocol the security is via key-based encryption.
The AllJoyn protocol is in many ways similar to our protocol. Both our proposed protocol and AllJoyn have an advertisement and discovery phase. Both are independent of, the programming language used, operating system of the device and transport layer of the communication medium. M2M is made possible via event-driven actions and finally both of the protocols implement security measures at the application level. There are, however, major differences between our proposed protocol and AllJoyn. AllJoyn divides the participating agents of the protocol into two types: AllJoyn App and an AllJoyn Router. Whereas, in our protocol we have three categories of participating devices: IoT node, Client Node and a Cloud Node. AllJoyn App and an AllJoyn Router are in many ways analogous to IoT node and Client Node, however, by the introduction of Cloud Node in our protocol we are able to handle dynamic changes in IP addresses when devices move across networks and also gain easier and more control over security of the system by making the Cloud act as a key distribution center. AllJoyn also can handle changes in IP addresses of the devices, but through the usage of Wi-Fi Hotspot 2.0 , which is as defined by the Wi-Fi Alliance.
9 Discussion and future work
This reported work could guide the OEMs to develop forward compatible IoT-enabled devices. The proposed protocol, which we named as One IoT, allows device discovery, advertisement, registration, invocation and configuration; while the framework includes authentication-host, internet, client/s and thing/s. We further address connectivity and security concerns in the protocol. While the protocol was designed for Human to Machine interaction, its simplicity makes it applicable and adaptable for Machine to Machine (M2M) communication as well. We are working on Version 2 of our One IoT protocol that works for M2M as well. This could be done by running scripts on Clients, or by making Broker Clients that act like smart hubs and help create smart IoT ecosystems. These scripts could be triggered synchronously (periodically) or asynchronously (event-based). However, identifying attacks and mitigation of those attacks are equally important. For attacks’ identification and mitigation, our protocol being on the cloud, can plugin the state of the art attack filter services that become available on the cloud.
From a cultural perspective, application of IoT—irrespective of the domain of application—is going to positively disrupt both the people’s ways of thinking (hence interacting and describing patterns) and the material objects that together shape a people’s way of life. IoT technology landscape shall be such that this change happens in a seamless fashion. Our One IoT protocol is exactly an attempt in that pursuit.
9.1 Future work
The IoT paradigm makes it possible to implement a range of applications both in civilian and military domains. Furthermore, such IoT-based systems could be safety critical systems as well. The utilities industry is envisaging to realise unforeseen applications with IoT technology. No matter what the end application is and what kind of sophistication is made possible by the IoT paradigm, one should not forget that the Internet itself is the essential constituent of this technology. This means when an internet outage occurs, there is a risk that the IoT devices might carry out operations that might not be in the positive interest to the owners. We are working on the next version of One IoT protocol, which addresses this concern of internet outage. The solution we propose is on detecting an internet outage bring the IoT devices into a no-internet-mode. Such a mode is specific to the IoT device and the type of application domain. The idea is “ whenever for an IoT device such a safe mode is defined, our protocol (on the Thing-side) would—on detecting the internet outage event—imposes the actuation controls bringing the device into that safe mode. We could achieve this behaviour in our protocol by having a method that actively reads the internet status. But again, the safe mode needs to be defined per device basis.
Furthermore, to facilitate: (a) training in IoT paradigm through our protocol and framework and (b) modelling and analysis of deployed IoT systems based on our protocol, we are developing a simulator for IoT deployments. This simulator envisages to make possible formal verification of Quality of Services in IoT paradigm both from qualitative and quantitative perspectives. The underlying verifier is from the work reported in .
Hardware devices that react with the physical world, and
Clients that moderate the above-mentioned hardware.
The advent of a universal protocol would also help IoT manufacturers in a plethora of ways, by reducing investment towards research and development of IoT protocols that reduce manufacturing costs and enable economic IoT implementations, and can also help systematise the manufacturing process. This allows OEMs to make their devices future proof and would allow interplay between IoT devices in the future, thus making these devices attractive from the point of view of end consumers. End consumers would also benefit from such unified protocols, as this allows wider variety, and thus pave way for personalised IoT ecosystems, which may also be tailored to user specific implementations.
In mid 2000s, there were two competing high-definition DVD video formats: Bluray and HD-DVD. Bluray was advocated by the group led by Sony Corp.; while HD-DVD was from the other group led by Toshiba Corp. In the end, Bluray was adapted by majority. Though Sony did benefit by Bluray, it is well known how bad the DVD market suffered due to the advent of streaming media.
The perspectives for security include: network security, server security, data security
OAuth provides applications a ’secure delegated’ access for service owners to authorise third party access to their resources
- 1.Harbor Research (2014) What exactly is the ’internet of things’?. http://harborresearch.com/wp-content/uploads/2014/03/Harbor-Postscapes-Infographic_March-2014.pdf
- 2.Evans PC, Annunziata M (2012) Industrial internet: pushing the boundaries of minds and machines. http://www.ge.com/sites/default/files/Industrial_Internet.pdf
- 3.IEEE: Towards a definition of the Internet of Things (IoT) (2015)Google Scholar
- 4.Bonomi F, Milito R, Zhu J, Addepalli S (2012) Fog computing and its role in the internet of things. In: Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing, MCC ’12, pp 13–16. ACM, New York, NY, USA. doi: 10.1145/2342509.2342513
- 5.Thingworx Platform. http://www.thingworx.com
- 6.Open Interconnect Consortium: The Open Interconnect Consortium and IoTivity (2015). http://openinterconnect.org/wp-content/uploads/2015/07/OIC-IoTivity_White-Paper_Final.pdf
- 7.Industrial Internet Consortium: Industrial internet reference architecture. Tech. rep., Industrial Internet Consortium (2015). http://www.iiconsortium.org/IIRA-1-7-ajs.pdf
- 8.Ministry of Communication and Information Technology India D.: Draft policy on internet of things. Tech. rep., Government of India (2015)Google Scholar
- 9.EU 2012 (2012) The artemis embedded computing systems initiative. http://www.artemis-ju.eu/
- 10.Information and Communications (ICT) Services businesses and technologies: Internet of Things Strategic Research Agenda (IoT-SRA) (2011)Google Scholar
- 11.Shelby Z, Bormann C (2009) 6lowpan—the wireless embedded internetGoogle Scholar
- 13.Bluetooth-SIG (2007) Bluetooth core specification version 2.1+ edr. Specification of the Bluetooth systemGoogle Scholar
- 14.Baddeley D (1999) Identification cards–contactless integrated circuit (s) cards–proximity cards–part 2: radio frequency power and signal interface. ISO/IEC, pp 14443–2Google Scholar
- 15.Oltsik J (2014) The internet of things: a ciso and network security perspective. Tech. rep, Cisco SystemsGoogle Scholar
- 16.Wind River (2015) Security in the internet of things. Tech. rep, Wind River SystemsGoogle Scholar
- 17.Morris R, Thompson K (1979) Password security: a case history. Commun ACM 22(11):594–597Google Scholar
- 18.Mirković J., Prier G, Reiher P (2002) Attacking ddos at the source. In: 10th IEEE International Conference on Network Protocols, 2002. Proceedings. IEEE, pp. 312–321Google Scholar
- 19.Wood AD, Stankovic JA (2004) A taxonomy for denial-of-service attacks in wireless sensor networks. Handbook of Sensor Networks: Compact Wireless and Wired Sensing Systems, pp 739–763Google Scholar
- 20.Yogesh DS, Rajendra K, Neminath H (2015) An experience report on scalable implementation of ddos attack detection. In: Advanced Information Systems Engineering Workshops. Springer, Berlin, pp 518–529Google Scholar
- 21.Rossum GV (1995) Python Tutorial. Technical Report CS-R9526, Centrum voor Wiskunde en InformaticaGoogle Scholar
- 22.Kinder K (2005) Event-driven programming with twisted and python. Linux J 2005(131):6Google Scholar
- 23.IETF: The constrained application protocol (coap) (2014). https://tools.ietf.org/html/rfc7252
- 24.AllJoyn. https://allseenalliance.org/framework/documentation/learn. Accessed 21 Oct 2015
- 25.Wigwag IoT Platform. URL http://www.wigwag.com. Accessed 23 Sep 2015
- 26.Industrial Internet Consortium: Industrial internet reference architecture (2015). http://www.iiconsortium.org/IIRA-1-7-AJS.pdf
- 27.Open Internet Consortium: Reference implementation of the internet of things (2015). URL http://www.openinterconnect.org/developer-resources-specs.pdf
- 28.Orlandi B, Scahill F (2012) Wi-fi roaming–building on andsf and hotspot 2.0. Alcatel-Lucent and British Telecommunications, Tech. RepGoogle Scholar
- 29.Banda G, Gallagher JP (2010) Constraint-based abstract semantics for temporal logic: A direct approach to design and implementation. In: Logic for Programming, Artificial Intelligence, and Reasoning—16th International Conference, LPAR-16, Dakar, Senegal, April 25–May 1, 2010, Revised Selected Papers, pp 27–45. doi: 10.1007/978-3-642-17511-4-3