Cisco Packet Tracer IoT Technology Introduction

4.2 Cisco Packet Tracer IoT Technology Introduction
Along with the standard networking functionalities, in the version 7.0.0, Cisco Packet
Tracer received an important upgrade with IoT components [25].
This chapter is mainly focusing on the IoT functionalities of the tool, only giving a brief
overview of the network components. Purpose of the study course was on Internet of
Things and not networking, hence all the four IoT simulations had a pre-configured net-
work to allowing IoT students to concentrate more on the IoT aspects.
In the four IoT simulation the network devices were the backbone elements for connect-
ing the IoT devices allowing them to interact between each other.
Every simulation had a dedicated network layout, however basic components were sim-
ilar among the examples. Routers, switches and wireless router were in fact commonly
used to create the network foundation.
In the figure below it is possible to see, as an example, the different routers offered by
Cisco Packet Tracer, main difference to consider when placing the device in the simula-
tions are the possibly hardware limitations that are coming with the devices, in terms of
number of ports available, options to change the network interfaces, number of expan-
sion slot etc. An extensive list of switch, server, PC and laptop is also available in the
tool.
Figure 5 - List of routers in Cisco Packet Tracer
In special cases, such as the two Smart-Home examples, also a simulation of an internet
connection was used. This connection was aiming to simulate a normal Internet Service
Provider (ISP) connectivity, giving the possibility to the home owner to remotely connect
to the own home network from an external network, such a corporate office or a cellular
network. In the second Smart-Home simulation the ISP was also used to link the home
devices to the backend IoT intelligence as IoT functionalities were provided as-a-service.
28
Additionally, in the Smart-industrial and one of the Smart-home cases, a 3G networks
were also implemented. Additional component such cell-tower and backend servers
were necessary to ensure the functioning of the network. Utilizing cellular network gave
more flexibility while connecting IoT devices to the network. As setup was very easy and
no limitation, such range and number of connected devices, are present as it would be
in real WLANs.
Once a network devices was placed into the simulation, the next step was to configure
it. Cisco Packet Tracer offered two options: configuration of the device via a user inter-
face or via a Command Line Interface (CLI). While using CLI method specific Cisco com-
mands need to be used and real device logic applies. Configuring via user interface was
more intuitive, did not require knowledge of Cisco commands but limited the amount of
parameters that could be set.
Depending on different setups different type of cabling were used to interconnect the
network devices such as copper straight cables, copper crossover cables and optic fast-
Ethernet cables. Also IoT custom cables were utilized in the microcontroller example.
As one can see in the below figure, Cisco Packet Tracer, offered several cabling options,
however an important feature was the auto-cabling option (lightning icon in the Figure
6). When selecting it, the tool would automatically chose the correct cable to connect two
network interface. For learning reason this option can also be disabled.
Figure 6 - List of available cables in Cisco Packet Tracer
Another important feature in the Cisco Packet Tracer tool is the possibility to separate
the network at physical level using sub-environments such as city, building, containers
and wiring cabinets. From the main view of the tool it is possible to switch very quickly
between logical and physical layer as illustrated in the Figures 7 and 8.
29
When creating network simulations, in the logical view, by default all the components are
placed in the same physical space. For basic simulation this is not probably a detail that
should be taken care, however for IoT simulations it was advisable to utilize different
physical layers in order to be able to adjust the environment variable to influence the IoT
devices behavior. Below figure shows the physical separation of the Smart-industrial ex-
ercise, where five different containers were utilized to physically split the various net-
works.
Figure 9 - Example of physical view from Smart-Industrial simulation
Figure 8 - Logical view
Figure 7 - Physical view
30
Physical separation helps to divide physically the network in several sub-areas introduc-
ing a more realistic aspect of it such as a need of backbone connections, a physical
wiring length limitation and WLAN coverage limitations and a need of custom environ-
mental variables.
Every physical sub-layer, except for the wiring cabinets, are coming with a large set of
fully customizable environmental variables,.
Variables are tunable parameters for representing real life environments such as:
amount of sunlight, air carbon dioxide concentration, gravity, winds speed and many
more. In Cisco Packet Tracer there are more than fifty different variables that students
can adjust accordingly based on a 24 hours time range.
In the Figure 10 below one can see the amount of sunlight and rain setup in the Smart-
campus exercise.
Variables are necessary in order to influence the sensor behavior in the IoT simulations.
Variables are in fact detected by the sensor and, as a consequence, actions are then
triggered. Adjusting variables was also helping students in order to validate immediately
if the IoT logic setup was done correctly.
31
Figure 10 - Example of environmental variable setup
In the provided four simulations the variables utilized were: sunlight and wind speed
level, in order to boost electricity production done by solar panel and wind turbine. Also
amount of raining manipulations were used during a random time of the day in order to
activate the water sensors, sensors were then placed in the school sport field, to detect
extra water level and stop the water irrigation sprinklers. In the Smart-Home cases also
humidity and temperature levels variable were changed in order to fire up the home AC
unit.
Creation of a smaller sub-container helped also to boost the environmental changes in
the variable parameter. As an example, if an old car was placed in the city level and it
was turned on, the level of carbon dioxide build up in the city level would have raised at
a slower pace compared if the car was turned on in a sub-container. In the second case,
being in a smaller space, like a car garage, the carbon dioxide sensor picked up carbon
dioxide variation faster than in the city level.
32
Physical layers and network components are present in the Cisco Packet Tracer since
many year, the real addition that make the tool capable to simulate IoT environments
was the introduction of IoT devices.
The main categories are: smart-devices, sensors, actuators and microcontrollers.
In the below figure there is an example of a list of home smart devices that can be added
in the IoT simulations.
Figure 11 - List of smart device
Smart-devices are devices that are fully capable to be connected to a wired or wireless
network and where the behavior and interaction logic can be quickly set up by utilizing
pre-loaded Phyton programs. These sensors include smart lights, AC units, coffee
maker, alarm sirens, RFID readers and a long list of other sensors, such as carbon di-
oxide, humidity, temperature, water level etc.
These devices usually are plug-and-play type of elements and they just need to be con-
nected to a local LAN. In some cases, if a wireless LAN was needed, a physical network
configuration required to be done mostly by swapping the LAN network interface for a
WLAN card.
Once connected to a network the devices needed to be remotely connected to the IoT
backend server. Creating the IoT connection enabled the possibility for the users to
check the status of the IoT devices from an IoT browser homepage. As illustrated in the
Figure 12 below from a home tablet, also connected to the local WLAN, it was possible
via browser to connect to a dedicated IoT homepage to monitor the list of all connected
IoT devices.
33
Figure 12 - Example of IoT homepage from Smart-Home 2 exercise
When accessing the list of the devices it was also possible to visualize their status but
also interact with the device remotely. As an example one can turn on the garden light
or check the remaining power of the IoT battery.
Furthermore, while connected to the IoT main home page, it was also possible to setup
a basic IoT logic for creating an interaction between the devices. As demonstrated in the
below Figure 13, the humidity sensor was connected to the home AC unit, starting AC in
case humidity would pass the fifty percent threshold. More detailed explanation of the
pre-set IoT logic in the four IoT simulations will be covered in the chapter 4.3.
Figure 13 - Example of pre-set conditions from Smart-Home 2 exercise
34
Cisco Packet Tracer also offered the possibility to use other non-smart devices such as
actuators. These type of components required additional actions in order to be connected
and operated but, despite the extra complexity, offered a more realistic degree of simu-
lation and flexibility when setting up the exercises.
Non-smart components were usually not network-capable, unless configured otherwise,
and needed to be connected to a microcontroller board via some special IoT cabling.
In Cisco Packet Tracer the microcontroller simulated an Arduino or Raspberry Pi devices
that, based on a custom software, took the input from some device, mostly input sensors,
and produced output, mostly operating actuators.
In order to create these simulations basic programming skills were required in Java, Phy-
ton or Blocky. Creating Java or Phyton scripts enabled the possibility to fully command
and control all the sensor and actuators. The use of Blockly language helps less skilled
programmers to visually create the programming logic. All programming done for the four
IoT exercises was done with Blockly, enabling all students to understand the logic be-
hind.
Before programming a sensor or an actuator, students must understand the device spec-
ifications. A brief explanation of how the device behaves can be found in the specification
tab when placing a sensor in a logical window of the tool. Specification included all the
necessary information on how the device operates, what are the different states, what
type of input the device would expect or output that the component would generate. For
more complex devices also an example of API command was suggested.
35
Figure 14 - Example of a smart-lamp specifications
Figure 14 above illustrates, as an example, the behavior of a simple smart-lamp. The
lamp can be directly controller by pressing ALT on the keyboard and clicking on it. Lamp
could also be connected to a microcontroller and a customWrite command would need
to be used in the output pin to operate it. Lamp is also having three states: off, dim and
on. So the previous customWrite command should also carry a variable to specify the
state.
Cisco Packet Tracer offered for each device a very helpful and complete specification
tab.
Another very important Cisco Packet Tracer feature worth to mention was the possibility
to switch from a real time to a simulation mode. The first mode enabled the possibility to
36
create the underneath network, connect IoT devices and define IoT backend logic. How-
ever, only in the simulation mode, it was really possible to validate that the network com-
munication layer really happened between the devices.
In the simulation mode it was in fact possible to simulate a packet traffic between nodes
and devices in order to check the connectivity, routing protocols and other network logic.
This mode helped to physically visualize and troubleshoot any kind of network, for ex-
ample setting up pings, or more complex packages, between nodes. The simulation
mode also listed in real time the various packages broadcasted in the network, allowing
to deep dive in the payload of the network package.
Figure 15 - Example of packages captured in the simulation mode
|