26
second case the devices were only having a connectivity layer
inside the house LAN,
but the IoT server components were hosted in a third-party network, simulating a pro-
vider cloud Software-as-a-Service scenario.
Both of the cases included a remote network, in the form of a corporate office network
or a mobile 4G network, where home owner could connect to in order to monitor the IoT
activities in the house.
The third simulation was about an interconnected university campus network where IoT
smart devices were connected. Along with the two basic networks,
classrooms and
apartments, a third network was connecting all the IoT devices and the backend IoT
servers. Through a user authorization mechanism from any point of the network it was
possible to access the IoT devices and monitor their status.
The last case represented a more complex industrial environment where five
networks
were connected. Two of networks were
connecting the IoT devices, via a switch or a
dedicated 3G network, for an electricity production. The electricity was then consumed
by a third network of IoT devices used in a production line. The remaining two networks
were utilized to simulate a corporate office remote area and a more important control
room, where backend IoT server was located and where users could connect to control
the IoT devices.
In order to be able to interact with the four simulations some basic knowledge of Cisco
Packet Tracer were required, due to the fact that IoT simulations were not only exploring
the basic network components the students needed to be familiar with concepts such as
physical containers, environmental variables, IoT backend servers and IoT component
programming. The following chapter covers the basic non-networking components con-
cepts, a deeper practical explanation was given to the students during the two practical
classes.
