Cisco Packet Tracer IoT Technology Introduction

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 

37 

Download 3,37 Mb.