3. INTRODUCTION
• The Internet Of Things is recent communication paradigm that envisions a near
future.
• In this scenario, objects of everyday life will be equipped with microcontrollers,
transceivers and suitable protocol stacks.
• IoT will foster the development of a number of applications which will use the
enormous amount of data generated by devices used for home appliances,
surveillance cameras, monitoring sensors, actuators, displays, vehicles etc. to
provide new services to citizens, companies and public administrations.
• With such a heterogeneous field of applications, lack of best practices in backend
network services and devices and lack of a clear and widely accepted business model,
the realization of IoT network has become a formidable challenge.
• Urban IoT, i.e, a communication infrastructure that provides unified, simplified and
economical access to plethora of services.
•The aim is to make better use of public resources, increased quality of services to
citizens and reducing operational cost of public administrations.
4. SMART CITY CONCEPT AND
SERVICES
https://www.youtube.com/watch?v=Br5aJa6MkBc
5. SMART CITY CONCEPT AND
SERVICES
The services that might be enabled by an urban IoT paradigm which are of
potential interest in the smart city context are:
• Structural health of buildings
• Waste Management
• Air Quality
• Noise Monitoring
• Traffic Congestion
• City Energy Consumption
• Smart Parking
• Smart Lighting
• Automation and Salubrity of Public buildings
6. SMART CITY CONCEPT AND
SERVICES
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?&arnumber=6740844
7. URBAN IOT
ARCHITECTURE
A. Web Service Approach For IOT
Service Architecture
• Here, IETF(Internet Engineering Task
Force) standards are followed because
they are open and royalty-free.
• IoT services are designed in
accordance with the ReST paradigm
which exhibits a strong similarity with
traditional web services.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?&arnumber=6740844
8. URBAN IOT
ARCHITECTURE
• Urban IoT system entails both an
unconstrained and constrained protocol
stack.
• The unconstrained protocol stack consists
of XML, HTTP and IPV4 which are
currently the de-facto standard for
internet communications.
• Constrained protocol stack is of low-
complexity, i.e, Efficient XML
Interchange(EXI), Constrained Application
Protocol(CoAP), and IPV6 over Low power
Wireless Personal Area
Network(6LoWPAN).
• Transcoding in between these protocol
stacks can be performed in standard and
low complexity manner guaranteeing easy
access and interoperability of the IoT
nodes with the Internet.
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?&arnumber=6740844
9. URBAN IOT ARCHITECTURE
The protocol architecture can be distinguished into three different
functional layer.
1) Data Format:
• The size of the XML messages is often too large and to parse the text messages becomes
complicated for CPU-limited devices for the IoT.
• EXI defines two types of encoding, i.e, schema-less and schema-informed.
• Depending on the node mobility, operating range and level of specialization, there are three
types of nodes.
a) Base Station Node(BSN) – IPV6 sink/router
b) Mobile Node(MN) – Wireless dongle to add WSN connectivity to a standard laptop
c) Specialized Node(SN) – offering services like temperature readings or actuation
10. URBAN IOT ARCHITECTURE
• In REST paradigm, any resource is addressed by a unique identifier of standard format and it
supports the following features.
a) Direct simple resource request/response
b) Concise one-to-many resource request/response
c) Structured resource request/response
d) Resource subscription and event or delayed notification
e) Zero-knowledge network probing
11. URBAN IOT ARCHITECTURE
Binary Web/XML Services
BWS is based on UDP, compatible with the verbose HTTP protocol enables the REST interaction
model on severely limited devices such as wireless sensors.
In 2-3 bytes long header of the message are specified the target resource(identified by a URL),
the access method(GET, PUT, POST etc.) and the format of the payload(Content-Type).
The response is identified by its source(IP, port) pair; header contains HTTP status code
summarizing the result and Content-Type.
BWS delegates payload data compression, and advocates the use of Efficient XML
Interchange(EXI) from W3C for Binary XML encoding.
13. URBAN IOT ARCHITECTURE
2) Application and Transport Layer:
• Internet traffic nowadays is carried at the application layer by HTTP over TCP.
• Due to heavily correlated data, HTTP over TCP has become a limiting factor for
constrained IoT devices.
• The CoAP protocol over UDP proposes a binary format transmission which helps in
overcoming the difficulties.
• A) Constrained Application Protocol (CoAP)
• CoAP needs to consider optimizing length of datagram and satisfying REST protocol
to support URI(Uniform Resource Identifier).
• CoAP is simply compression of HTTP protocol with low processing and low power
consumption.
• HTTP-CoAP cross protocol proxy has an important role in solving congestion
problem in the constrained environment.
15. URBAN IOT ARCHITECTURE
HTTP
1. It is based on TCP protocol which is heavy
weight.
2. It used P2P communication model which is
not suitable for notification push services and
IoT constrained devices.
3. It is reliable and long term successful plan.
CoAP
1. It used UDP without complex congestion
control of TCP.
2. With lightweight UDP, it allows IP multicast
for group communication in IoT and provides
URI, REST methods(GET, POST, PUT and
DELETE).
3. It provides retransmission mechanism for
reliability and resource discovery mechanism.
http://www.cse.wustl.edu/~jain/cse574-14/ftp/coap/
http://www.cse.wustl.edu/~jain/cse574-14/ftp/coap/
16. URBAN IOT ARCHITECTURE
CoAP Message Layer:
a) Reliable Message Transfer: b) Unreliable Message Transfer
http://www.cse.wustl.edu/~jain/cse574-14/ftp/coap/
http://www.cse.wustl.edu/~jain/cse574-14/ftp/coap/
17. URBAN IOT ARCHITECTURE
CoAP Request/Response Layer Message:
a) Piggy-backed b) Separate Response c) Non confirmable
request and response
http://www.cse.wustl.edu/~jain/cse574-14/ftp/coap/
18. URBAN IOT ARCHITECTURE
• The message format for CoAP uses simple binary format where Message = fixed-size 4 byte
header + variable length token (asynchronous response/match a request with response) + a
sequence of CoAP options + payload.
• DTLS(Datagram Transport Layer Security) is used for CoAP security because it solves reordering
and packet loss.
• Energy Control System
19. URBAN IOT ARCHITECTURE
2) Network Layer:
• Due to the exhaustion of IPV4 address blocks, IPV6 standard is used for nodes in the IoT network
which has 128-bit address field.
• Because of overheads in IPV6, 6LoWPAN (IPV6 over low power wireless personal area network)
network is used for constrained devices.
• A border router which is directly attached to the 6LoWPAN network, translates IPV6 packet intended
for a node to 6LoWPAN network with header compression format and operates in inverse translation in
opposite direction.
• The problem still remains in finding a way to address a specific IPV6 host using an IPV4 address and
other meta-data available in the packet. Some approaches to achieve this goal are:
a) v4/v6 Port Address Translation:
• Multiple IPV6 addresses are mapped into single IPV4 public address. When a packet is returned to the
IPV4 common address, the NAPT service in the edge router replace it with the private address/port of
intended receiver by looking up at the NAPT table.
• This approach has scalability problem like limited number of TCP/UDP ports.
20. URBAN IOT ARCHITECTURE
b) v4/v6 Domain Name Conversion:
• When a DNS request for the domain name of an IoT web service is made, the DNS returns the
IPV4 address of an HTTP-CoAP cross proxy to be contacted to access the IoT node.
• The proxy requires the resolution of the domain name contained in the HTTP host header to
the IPV6 DNS server, which replies with the IPV6 address that identifies the final IoT node
involved in the request.
• Then the proxy forwards the HTTP message to the intended IoT node via CoAP.
c) Universal Resource Identifier(URI) mapping:
• The reverse cross proxy which is a particular type of HTTP-CoAP cross proxy, behaves as
being the final web server to the HTTP/IPV4 client and as the original client to the CoAP/IPV6
web server.
• Since IPV6 connectivity is present to allow direct access to the final IoT nodes, IPV4/IPV6
conversion is internally resolved by the applied URI mapping function.
21. URBAN IOT ARCHITECTURE
IPV6 network with a 6LoWPAN mesh network: 6LoWPAN
Stack
http://www.ti.com.cn/cn/lit/wp/swry013/swry013.pdf
22. URBAN IOT ARCHITECTURE
• Unconstrained Technologies
1. This includes traditional LAN, MAN, WAN
communication technologies like Ethernet,
WiFi, fiber optic, broadband power line
communication(PLC) and cellular technologies
such as UMTS and LTE.
2. These are characterized by high reliability,
low latency, and high transfer rates(Mbits/s
or higher).
3. Not suitable for IoT nodes because of their
inherent complexity and energy consumption.
•Constrained Technologies
1. These include IEEE 802.15.4 Bluetooth and
Bluetooth Low Energy, IEEE 802.11 Low Power,
PLC, NFC and RFID.
2. These are characterized by low energy
consumption, relatively low transfer
rates(smaller than 1 Mbit/s).
3. These links exhibit long latencies because
of low transmission rate and duty cycling with
short active periods to implement power
saving policies.
B. Link Layer Technologies
23. URBAN IOT ARCHITECTURE
C. Devices
• Essential devices to realize an urban IoT are classified based on the position, they occupy in the
communication flow.
1) Backend Servers:
• It is located in the control center, where data is collected, stored and processed to produce added-
value services.
• Backend systems commonly considered for interfacing with the IoT data feeders which includes
database management systems, websites and enterprise resource planning systems(ERP).
2) Gateways:
• The gateway is required to provide protocol translation and function mapping between
unconstrained and constrained protocols, i.e, XML-EXI, HTTP-CoAP, IPV4/V6-6LoWPAN.
3) IoT Peripheral Nodes:
• These are classified based on wide range characteristics such as powering mode, networking role,
sensor/actuator equipment and support link layer technologies.
• RFtags are extremely low cost, no internal energy source. They are used for object identification by
proximity reading which can be used for logistics, monitoring and other services. Mobile devices are
also very important part of urban IoT.
24. AN EXPERIMENTAL STUDY: PADOVA
SMART CITY
• The target application consists of a system for collecting environmental data and monitoring
the public street lighting by means of wireless nodes, equipped with different kinds of sensors,
placed on street light poles and connected to the internet through a gateway unit.
System Architecture
Of Padova Smart
City:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?&arnumber=6740844
25. AN EXPERIMENTAL STUDY: PADOVA
SMART CITY
Padova Smart City Components:
1) Street Lights:
• The correct operation of the bulbs is performed through photometer sensors which directly
measures the intensity of lights emitted by the lamps at regular time intervals or upon requests.
• The wireless IoT nodes are also equipped with temperature, humidity and benzene sensors.
2) Constrained Link Layer Technologies:
• The IoT nodes use the 6LoWPAN and routing functionalities are provided by the IPV6 Routing
Protocol for Low power and Lossy Networks(RPL).
• The IoT nodes collectively deliver their data to a sink node, which represents a single point of
contact for the external nodes.
26. AN EXPERIMENTAL STUDY: PADOVA
SMART CITY
3) WSN Gateway:
• It has the role of interfacing the constrained link layer technologies used in the sensors cloud with
traditional WAN technologies used to provide connectivity to the central backend servers.
• It plays the roles of 6LoWPAN border router and RPL root node.
• The connection to the backend services is provided by common unconstrained communication
technologies like optical fibers.
• It also operates as a sink node for the sensor cloud for collecting all the data that is needed to be
delivered to the backend services because sensor nodes do not support CoAP services.
4) HTTP-CoAP Proxy:
• It can be extended to better support monitoring applications and limit the amount of traffic injected
into the IoT peripheral network.
• It can cache the list of resources that need to be monitored. It is done by polling selective resource
proactively and subscribing to the selected resource using the “observe” functionality of CoAP, i.e, the
server only sends the update when the value measured by the sensor falls outside a certain range.
27. AN EXPERIMENTAL STUDY: PADOVA
SMART CITY
5) Database Servers:
• The data stored in the database are accessible through traditional web programming
languages which can be visualized in the form of a web site or exported in any open data
format.
• In the padova smart city project, the database server is realized within the WSN gateway.
6) Operator Mobile Device:
• The public lighting operators will be equipped with mobile devices which can locate
streetlights that requires intervention.
• They can issue actuation commands directly to the IoT node connected to the lamp and signal
the result of intervention to the central system.
28. AN EXPERIMENTAL STUDY: PADOVA
SMART CITY
Data Collected For Temperature, Humidity, light and Benzene By Padova
Smart City Project
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?&arnumber=6740844
29. CONCLUSION
•The discussed technologies are close to being standardized.
•Industry players are already active in the production of devices that take advantage of these
technologies to enable the application of interest.
•While the range of design options for IoT systems is rather wide, the set of open and
standardized protocols is significantly smaller.
•The enabling technologies have reached a level of maturity which allows the practical realization
of IoT solutions and services starting from field trials which might clear the uncertainty that
prevents a massive adoption of IoT paradigm.
30. REFERENCES
[1] Andrea Zanella, Nicola Bui, Angelo Castellani,Lorenzo Vangelista, Michele Zorzi, “Internet of Things for
Smart Cities” IEEE INTERNET OF THINGS JOURNAL, VOL. 1, NO. 1, FEBRUARY 2014
[2] Angelo P. Castellani, Nicola Buit, Paolo Casari, Michele Rossi, Zach Shelby, Michele Zorzi, “Architecture and
Protocols for the Internet of Things: A Case Study” in Proc. 8th IEEE Int. Conf. Pervasive Comput. Commun.
Workshops(PERCOM Workshops), 2010, pp. 678–683.
[3] http://www.ti.com.cn/cn/lit/wp/swry013/swry013.pdf
[4] http://www.cse.wustl.edu/~jain/cse574-14/ftp/coap/
