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
I.INTRODUCTION
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) [1] can be proven to be an optimistic solution. According to
[2], 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.
II.WEBSERVICESFORSMARTOBJECTS
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 [3]. 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.
III.RELATED WORK AND MOTIVATION
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 [4].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 [5]. 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 [6]. 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 [7]. 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 [8].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 [9]. 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 [10] we
can aim to minimize the message overhead by reducing fragmentation of IPv6 packets.
CoAP [11] 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:https://codeshoppy.com/shop/product/bus-timing-report/
https://codeshoppy.com/shop/product/bridge-between-investor-and-business-people/
https://codeshoppy.com/shop/product/ijob-job-peers-training-and-exam/
https://codeshoppy.com/shop/product/sharing-marriage-invitation/
https://codeshoppy.com/shop/product/business-invoice/
