87
Another bug, happening both with IoT and normal devices, was clearly visible when a
configuration was changed multiple time within a short time. This causes the device to
not respond properly, not to get connected to the network
or not to act as it was pro-
grammed.
Two examples emerged during the practical classes when an IoT server did not connect
logically to the router even if configuration was correct, or when some students struggled
for long time to connect some IoT devices to the WLAN even if the setup was correct.
The tip shared to the students was that, if troubleshooting of the issue would take more
than few minutes, it would have been better to erase the
device and re-add it to the
simulation from scratch, this solved almost every time the issue. Other option was also
to close and restart the entire Cisco Packet Tracer.
Another limitation identified when creating the exercise was the obvious fact that not all
that is possible in real life is possible in Cisco Packet Tracer. There were in fact multiple
limitation for example when setting up ISPs, or when expanding network device ports
but also more in general on what the IoT smart-device could do.
Limitations were usually overcome by creating workaround or clearly explain them to the
students during the classes.
Regarding the methodology of the exercise the main problem
was related to the time
spent for the practical classes. As explained in the chapter 3, during the initial conversa-
tion with the IoT course lecturer, as this was the first time that course was taught, the
time to be allocated for the practical classes was not clear.
It was then decided to allocate two classes, first one for a generic introduction of the tool
and the second one for a group practical exercise.
Feedback shared with the course lecturer afterward was that more time was required for
the practical classes. Idea for future classes could be to allocate three slots for the topic,
dedicating the first class for the introduction of the tool and diluting the group work in two
sessions, allowing the students to spend more time building the own business case.
Even if three classes would be required, it was observed that some other small aspects
needs to be taken care before the next course.
88
Most of the students, even if asked, did not create beforehand the Cisco NetAcad ac-
count. This caused a bit of delays in start the class. For future course the account should
be created by default during the starting of the course or perhaps be requested by other
non IoT courses, so students will have it already when IoT practical classes will start.
Another problem, emerged during the lab sessions, was that some of the IoT business
cases, developed by the students in previous classes of the course, were not achievable
in Cisco Packet Tracer. This was mostly due to fact that Cisco simulator did not have
sensors required
in the student’s cases. For future iteration it would be better to introduce
Cisco Packet Tracer to the students earlier so they could familiarize
with the options
offered by the tool and create their own IoT business cases on the top of it.
In order to enhance the IoT practical experience of the students another possibility for
the future could be to limit the time spend in simulating the IoT
cases with Cisco Packet
Tracer and have one class where students could practice with real microcontroller sce-
narios.
This would however require a more complex setup as hardware and sensors would be
necessary, a dedicate IoT network would be needed and also students groups should
be built in such a way that programming skills are available in the group.
To conclude, despite the limitations and bugs in Cisco Packet Tracer, the simulation tool
was a very good choice for the Internet of Thing study course. Regarding the contents
and the methodology a positive feedback was shared by students and the course lec-
turer. Everyone also seemed to agree that additional time is required in future courses
in order to have a more complete IoT experience for the students.
