Abstract—The Internet of Things perceives a world where-in the embedded devices are made intelligent and can be uniquely identified in the internet. The communication among these devices is achieved by fully integrating them to the web paving way for the concept of Web of Things. With standards like 6LoWPAN at the network layer and 802.15.4 at the physical layer, applications built over these are made smarter, interoperable, scalable and secure. We present a heuristic approach by which interoperability can be implemented at the application layer addressing the issues in a real-time traffic scenario. A REST based design provides loose coupling and lightweight implementation of web services aiding the role of memory constrained devices in the Web of Things. This paper also enlists an efficient publish subscribe mechanism for event notification among the sensors.
Keywords-6LoWPAN, CoAP, Internet of Things, REST, Sensor, Sensor Network, Web of Things
Internet of Things aims in establishing a unique identity for the things and representing them virtually in the internet. The future of technology will be powered by devices, diminishing in the size of processing units. The data that drives the network is gathered by humans, whose efficiency and accuracy is deemed to be questionable. To solve the problems of incompatibility and isolation in a network of smart things and address the shortcomings from the data gatherers, Cyber Objects (Association of physical objects and their virtual representation)  can be proven to be an optimistic solution. According to , it is expected that over the next decade the number of connected devices could reach more than 50 billion. Integrating the ecosystem of embedded devices (based on the Internet of Things) to the web has led to the origin of Web of Things. Applications can be built upon the smart things using well known web languages and technologies (example HTML, Java Script, AJAX, PHP, and Python). We propose an enhancement based on Web of Things for Toll Gate system in specific to the Indian Scenario. The proposed system uses 6LoWPAN at the network ideal for a wireless embedded internet and CoAP at the application layer (see Section IV). The scheme uses the concept of Smart Objects (microcontrollers with sensors, actuators and communication device). The interaction among these objects is made effective using web services. The RESTful implementation of the services ensures high scalability, security and generality of interfaces.
Web services encourage communication among heterogeneous environments either using SOAP (Simple Object Access Protocol) or REST (Representational State Transfer).SOAP is a XML (Extensible Markup Language) based RPC (Remote Procedure Call) solution while the latter is a much more lighter solution. Although SOAP offers support for reliable messaging, security and atomic transactions REST supplants the former by its effective utilization of the well-known HTTP protocol (features like HTTP caching and security enforcement). REST facilitates loose coupling among web services and does not require XML parsing. The application consuming the service needs to understand the format of the information represented which may be of variable formats typically an HTML, XML or JSON document. In environments with limited bandwidth and resources, the RESTful architecture is found to be quintessential . Although REST is light it is not totally suitable for realizing the vision of web of things for the following reasons: •no support for multicast •pull based communication To overcome the above barriers, the IETF (Internet Engineering Task Force) CoRE (Constrained RESTful Environment) Working Group is working on a protocol for embedded web services called CoAP (Constrained Application Protocol) for the application layer. CoAP unlike HTTP works towards building M2M applications. The overhead caused by the use of TCP’s flow control mechanism in HTTP renders it inextensible for the use in resource constrained networks. HTTP is sensitive to mobility and lacks multicast support due to the use of TCP which is overcome in CoAP through the use of UDP. The use of UDP results in compact packet overhead. The architecture we propose for the real-time traffic application involves embedding CoAP based web server on smart things.
AlertMe1 is based on ultra-low-power ZigBee-enabled devices that envision the concept of Connected Home with sensors scattered around the home, which are turned into internet devices via the proxy of a home gateway. Energy Visible2 is a RESTful 6LoWPAN based application framework for smart homes addressing service discovery and service description. A syndication mechanism using RESTful messaging system is also specified. Nimbits3 is a free, social and open source Internet of Things based data historian server built on cloud computing architecture providing connectivity between devices using data points. Environmental sensor nodes, energy monitoring systems and RFID-tagged objects are connected to the web using Sun Spots, PLOGGS which is demonstrated in .A data platform as a middleware between the physical world and the virtual digital world focusing on vehicular networks and environmental perception is designed in . Information collected from infrastructures beside the roads is processed and helpful advices are provided to the interested users. We see that most of the application development for wireless sensor network uses REST over HTTP which is not suitable for resource constrained devices. Low power consumption is observed in Wireless Sensor Network running on CoAP server when compared to that running on HTTP server . This makes CoAP a better choice for use in Wireless Sensor Network. We propose a design that could be employed for the Web of Things applications development, which uses a more efficient REST-based protocol called as CoAP. Considering the realm of sensing through the use of Radio Frequency Identification (RFID), which uses tag based identification that uses radio-frequency electromagnetic radiation for transmission of information, it is proved to be unreliable owing to the small range and inability to transmit across obstructions. The privacy offered by RFID is questionable and it can be easily blocked through the use of a Faraday Cage to block electromagnetic transmissions. Metals like thin foils can cause interference with RFID detection . RFID poses a setback in transmission range of messages to approximately 8~30 m; hence the syndication mechanism that we aim to establish through the use of CoAP messaging across long distances cannot be fulfilled. Frequent traffic updates to the subscribed users of the system can be realized through the use of WSN. Reasoning as to why Zigbee is a better standard to be used for Wireless Sensor Network in comparison to Bluetooth technology is, we find that it offers high flexibility in the network by allowing the use of clusters, tree and mesh networks. Furthermore, Zigbee allows roughly more than 65,000 nodes in a WSN according to its specification. Another boon is its transmission range varying from 1-100 m in contrast to Bluetooth which offers only 1-10 m .Zigbee offers better power management options and a longer battery life, essential for low-power small devices that may be located in remote regions and are not frequently maintained . IV.COAPAND6LOWPAN In constrained machine-to-machine applications we find that the devices usually have 8-bit microcontrollers with limited RAM and ROM. Using networks like 6LoWPAN  we can aim to minimize the message overhead by reducing fragmentation of IPv6 packets. CoAP  serves to be an alternative to HTTP, but at the same time provides an effective mapping mechanism that allows proxies to be built providing access to CoAP resources through HTTP or vice versa. The significant changes from HTTP to CoAP highlighted would be the use of UDP (User Datagram Protocol) asynchronously for the emulation of the request-response model. The lack of complete reliability as in TCP is compensated by the feature of exponential back-off ensuring optional reliability. Multicast requests in CoAP are not directed to the CoAP endpoint instead are addressed to an IP multicast address. CoAP stack as shown in Fig.1 is visualized to be into 2 layers logically, the messaging and the request/response layer. CoAP requests are sent over the network to access the URI of the resource in the server. Proxying and caching benefits of CoAP helps in speedy processing of requests and response messages. CoAP also uses security binding to the Datagram Transport Layer Security (DTLS).
Confirmable (CON), Acknowledgement (ACK), Reset (RST) and Non-Confirmable (NON) are the four types of messages that are defined in the protocol as explained below: 1)CON: Confirmable message requires an Acknowledgement message (ACK) from the recipient for a successful transmission carrying the corresponding Message ID. 2)NON: Non-Confirmable message does not require an Acknowledgement Message (ACK). 3)ACK: Acknowledges that a specific Confirmable message has arrived. 4)RST: Indicates that a specific message be it Confirmable or Non-Confirmable was received nevertheless the processing was hindered due to context mismatch. 2