This article has been accepted for publication in a future issue of this journal, but has not been
fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
A Generic IoT Architecture for Ubiquitous
Context-Aware Learning
Salsabeel Y. Shapsough, Member, IEEE, and Imran A. Zualkernan, Member, IEEE
Abstract—Ubiquitous learning environments move learners out
of a classroom and into the real world where learners engage in
experiential and tangible learning involving instrumented physical
things. Learners use peer-to-peer networks connecting learners,
teachers, and a host of learning ‘things’ like instrumented pieces
of art, flower pots, and even buildings. A key component of such
systems is wireless-enabled edge devices augmented with various
types of sensors to represent the state of physical things and their
context. This paper presents a novel generic architecture for
context-aware ubiquitous learning systems based on the Internet
of Things (IoT) computing paradigm. A commonly used IoT edge
device was used to implement four variants of the proposed
architecture. The variants were based on Advanced Message
Queuing Protocol (AMQP), Constrained Application Protocol
(CoAP), Message Queue Telemetry Transport (MQTT), and
Extensible Messaging and Presence Protocol (XMPP). All variants
provided more than adequate performance for implementing
ubiquitous learning scenarios. As expected, CoAP was generally
more resource-efficient. However, practical differences in
performance were so small that the choice of which architectural
variant to use may depend on non-functional requirements like
reliability, security, maximum payload size, and ease of
implementation.
Index Terms—Internet of Things (IoT), smart education,
ubiquitous learning, Raspberry Pi, Extensible Messaging and
Presence Protocol (XMPP), Message Queuing Telemetry
Transport (MQTT), Advanced Message Queuing Protocol
(AMQP), Constrained Application Protocol (CoAP)
I. INTRODUCTION
BIQUITOUS Learning (UL) is learning anywhere and
U anytime [1]. A ubiquitous learning system obviates the
limitations of a typical classrooms by presenting learning
content and activities in the real world [2]. Rather than reading
about topics such as history, zoology, or botany, learners can
instead go out to a museum, zoo, or garden and observe
themselves [3]. Ubiquitous learning uses low-cost sensors and
actuators, lightweight communication protocols, and open-
source software to implement situated, inquiry and problem-
based, and peer-to-peer learning [4]. Ubiquitous learning
systems implement novel pedagogies that would otherwise be
unfeasible in a classical learning environment. Using digital
communication technologies, learners go outside the classroom
and learn about the world by experiencing it deeply through
sensors and actuators. For example, a learner can not only feel
how cold a water stream is, and how fast it is flowing, but can
Manuscript received May 21, 2019; revised November 11, 2019.
The authors are with the Computer Science and Engineering Department,
American University of Sharjah, Sharjah, United Arab Emirates (email:
sshapsough@aus.edu; izualkernan@aus.edu)
1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
1
also know its actual temperature and velocity via embedded
sensors within learning ‘things’ submerged in the water.
Learners can then instantly communicate their experiences to
their peers and teachers around the world using the Internet
enabled by ubiquitous telecommunication networks like the 5G.
Further, teachers can remotely manage learning content and
provide learners with real-time mentoring and feedback.
Sensing technologies such as RFID tags, QR-codes, and
Bluetooth Low Energy (BLE) beacons make it possible to
convert any physical space into an interactive environment for
an in-situ learning experience. Given an artifact in a museum,
for example, a learner’s experience can extend beyond simple
observation of viewing generic information in the form of audio
and video snippets. The learner’s presence in front of an artifact
can be automatically identified using BLE beacons. Learning
content delivered to learner can then be customized based on
their prior preferences, and by using sensor data from their
smartwatch. For example, high heart rate may mean that they
are anxious and consequently calming content and background
music could be presented.
A host of learning environments and mobile applications
have implemented ubiquity. Context-aware inquiry-based
learning is one type of ubiquitous learning [5] in which a learner
is placed in a physical environment and learns by posing and
answering questions about various aspects of the environment.
One such system is Archi-pods [6]. Since a key motivation for
this paper is to provide design principles for building ubiquitous
learning systems like Achi-pods, details of this system are
presented next to setup the context for this paper.
As shown in Fig. 1, Archi-pod was a wireless sensor-based
edge node equipped with various sensors including
temperature, motion, and illumination. Archi-pods were
powered by batteries and a small solar panel and could be
placed in any outdoor location. Undergraduate Architecture
students enrolled in an ‘Architecture Principles’ course were
provided with a web-based mobile application that interacted
with Archi-pods distributed around campus. Students were
asked to walk around campus, interact with each Archi-pod to
acquire sensor readings, and to then incorporate this
information into posing or answering questions about an
architectural space. For example, in one task students were
asked to locate an architectural element like an Arc. Once a
student had located an Arc, they could take a photo of the Arc
using their smartphone, and subsequently incorporate this photo
into their answer which they then posted to a nearby Archi-pod.
In another task, students were asked to guess the illumination
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
level in a particular space, and to relate this level to how the
space was being used. Elsewhere, the students were asked to
judge the level of ‘comfort’ in a space and then to correlate this
feeling with actual ambient temperature and humidity at the
location. The system also allowed students to rate questions
posed by others, which in turn was expected to improve their
question posing skills, and, hence elevating critical thinking. It
is clear from these examples that the learning design of such
systems cannot be implemented without using appropriate
technology. Fig. 2 shows screenshots of the Archi-Pods app.
The App was used by students as well as the instructors.
Fig. 1. The Archi-pod edge-device for ubiquitous learning.
While there is a general understanding of how ubiquitous
learning systems can improve learning, it is not yet clear how
such systems can best be implemented. While there have been
numerous studies of factors that influence an institution’s
willingness to adopt a smart learning system [7], [8], there is
little publicly available information on how such systems
perform technically in a way that can influence user experience.
Fig. 2. Screenshots from Archi-Pods.
1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
1
This paper presents the design and analysis of a generic
architecture for ubiquitous learning systems like Archi-Pod.
The primary goal of this paper is to present and analyze a
generalized architecture that exploits the lessons learnt in
building current Internet of Things (IoT) systems. The
suggested design is evaluated in terms of technical performance
parameters. The proposed architecture is also analyzed against
non-functional requirements that could influence aspects like
security, reliability, and flexibility to meet various formats of
learning curricula.
The paper is organized as follows. Next section presents an
analysis of recently proposed ubiquitous learning systems. In
the third section a common set of requirements for such systems
is established and a generic architecture based on IoT
technologies satisfying these requirements is described. The
fourth section shows an experimental evaluation of four
variants of this architecture. The paper concludes with a
summary of findings, and recommendations for future work.
II. CURRENT STATE OF UBIQUITOUS LEARNING
A recent survey of ubiquitous learning systems is
summarized in Table I. As Table I shows, few systems (e.g.,
[9], [10]) were built using the IoT paradigm. Most systems used
propriety architectures developed specifically for each use case
or project. As Table I shows, many systems employed edge
technologies such as low-cost microcontrollers and active or
passive sensors. QR codes and RFID were also used to enable
interaction between learners and objects in various
environments like museums [11], gardens [12], and cities [13].
Small microcontrollers like Arduinos and Raspberry Pi’s
augmented with cheap sensors were used to help learners
understand how they experienced the world. Various types of
learning designs ranging from elementary school students
learning about the natural world [10], or undergraduates
learning how design of a physical space affects the way they
experience it [6] were implemented.
While many projects adopted IoT hardware technologies,
how various elements connected and communicated with each
other was often done using existing classic internet
technologies and topologies. For example, as Table I shows,
HyperText Transfer Protocol (HTTP) [14] was the most
commonly used protocol for the communication layer amongst
existing Internet-based systems. Most systems relied heavily on
peer-to-peer communications to deliver findings, assessments,
and feedback among groups of learners and teachers. However,
this type of peer-to-peer, and often one-to-many
communication is not conducive to the use of the HTTP
protocol which was originally designed for a request-response
architecture. Few projects used instant messaging protocols like
Extensible Messaging and Presence Protocol (XMPP) [15] or
publish/subscribe protocols like Message Queueing Telemetry
Transport (MQTT) [16]. The projects that utilized such
protocols did this either because the primary emphasis was on
peer-to-peer interactions (e.g., [17], [18]), or on large-scale,
efficient communications [19]. Furthermore, most projects
were rarely evaluated for technical performance issues like
response time, etc.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

TABLE I
BREAKDOWN OF EXISTING UL SYSTEMS
System Edge Device Sensing Element Network Messaging Database
Natural science [12] Phone QR code WiFi HTTP Not Specified
CRPS [20] Phone QR codes WiFi HTTP Not Specified
EULER [12] PDA RFID, Camera WiFi HTTP SQL
IoT-based UL [9] Phone NFC, QR codes WiFi, 3G WebSocket Not Specified
OBSY [10] Raspberry Pi sensors, camera WiFi HTTP None
Prete-a-apprendre [21] Arduino sensors WiFi, ZigBee HTTP, ZigBee None
Hoodies and Barrels [22] Arduino sensors, RFID WiFi, ZigBee ZigBee None
Adaptive u-learning [23] PDA RFID WiFi, 3G HTTP Not Specified
Control lab [24] Control panel lab equipment WiFi, GPRS SMS, HTTP None
LOCH [25] Phone GPS, camera, mic PHS HTTP Not Specified
HELLO [26] Phone QR codes WiFi/ WCDMA HTTP SQL
PCULS [27] Phone WLAN localization WiFi SMS, HTTP SQL
Museum [28] Phone Camera, mic WiFi HTTP Not Specified
Smart education museum [29] Smartphones QR codes, RFID, NFC WiFi HTTP Not Specified
U-museum [30] PDA RFID WiFi N/S - HTTP Not Specified
Zydeco [31] Phone Camera, mic WiFi HTTP Not Specified
Amsterdam [13] Phone GPS, camera, mic UMTS SMS, MMS None
IB tour [32] PDA RFID, GPS WiFi Propriety IM + HTTP SQL
TELD [33] Smartphones QR codes, NFC Bluetooth, WiFi N/S - HTTP Not Specified
QR-Lumps [34] Smartphones QR codes WiFi HTTP Not Specified
MLSS [35] Smartphones Barcodes, GPS WiFi HTTP Not Specified
M-game for vocabulary [36] Smartphones, tablets - WiFi, 3G, 4G HTTP Not Specified
Archi-pods [6] Smartphones, Raspberry Pi Sensors, camera WiFi HTTP CDB
IEEE 802.15.4, SiteWhere
IoT4SSAE [37] Libelium Meshlium Sensors Ethernet, 3G, 4G, MQTT MongoDB
GSM, GPRS MySQL
Smart meters, wearable Local edge
Google Gear, Google WiFi, 3G, 4G/LTE,
IoTFLiP [38] health monitoring sensors, Not Specified device
Glass, smartphones WiBro, GPRS
video cameras memory
IEEE 802.15.4,
GAIA [39] Raspberry Pi, Arduino Sensors MQTT Not Specified
WiFi, Ethernet,
Context-aware assessment [19] Smartphones Sensors, GPS WiFi MQTT CDB
PSILAN [18] PC - WiFi XMPP Not Specified
SMILE [17] PC - WiFi XMPP Not Specified
Learning Catalytics [40] PC - WiFi HTTP Not Specified
WeSpot [41] Smartphones Camera, mic WiFi HTTP MySQL
GPIM [42] Google Glass sensors WiFi HTTP MySQL
PCAR [43] Smartphones QR codes, GPS WiFi Not Specified Not Specified
Youubi [44] Mobile, Smart Watch GPS Ethernet, WiFi HTTP Not Specified
Barcode, RFID, QR codes, BLE, Wi-Fi,
u-ONE [45] Robot, PDA, OLPC BLE, HTTP, ZigBee Not Specified
E-Pen, Magnet Card, Laser ZigBee, Group Net
OPC Classical, OPC
Sensors, actuators, camera, IO-Link, industrial UA, RESTful HTTP,
SEPT Learning Factory [46] PLC, Robot Not Specified
barcode, RFID ethernet MQTT, DDS,
AMQP, CoAP

In summary, many existing ubiquitous learning applications
used resource-constrained edge devices and sensors. Several
applications also incorporated peer-to-peer event-based
communication paradigms to facilitate collaborative learning
amongst learners. These two trends suggest that IoT
architectures would be appropriate candidates for building such
systems in systematic manner. The next section presents a
generic architecture based on IoT technologies.
III. REQUIREMENTS FOR UL SYSTEMS
Table II shows primary requirements of a context-aware
ubiquitous learning system abstracted from the various
ubiquitous learning systems shown in Table I. As shown in
Table II, a major requirement of such a system is the peer-to-
peer communications between learners and teachers.
Messaging protocols typically follow one of two design
patterns; request/response or publish/subscribe. In
request/response pattern, one device is a server, while the other
acts as a client. The client sends requests to retrieve or post data,
while the server responds by either providing required
information or acknowledging the posted data.
Request/response design pattern is not appropriate for large-
scale peer-to-peer applications primarily because clients
interested in receiving updates have to continuously poll from
the server until an update is available.
In publish/subscribe, on the other hand, communication takes
place between devices through a middleware called a broker.
Each client can be a publisher and/or a subscriber. Publishers
generate data and publish it to the broker. The broker then
automatically relays that data to subscribers. Messages are
routed from publishers to subscribers using pattern matching.
In some protocols like MQTT, tags known as “topics” are used
that allow for efficient content filtering. If a subscriber is
interested in a specific topic, ‘first grade mathematics,’ for
example, the subscriber will subscribe only to this topic. Once
new content related to this topic is published by another node,

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

the content is automatically delivered to the subscriber. Nodes 3 shows, XMPP and MQTT are both simpler publish/subscribe
can be publishers and subscribers of multiple topics at the same protocols. Advanced Message Queuing Protocol (AMQP) [50],
time. By routing messages based on topics, subscribers are on the other hand, is a more sophisticated protocol that uses
decoupled from publishers. Nodes do not have to registers with concepts of “exchanges” and “queues” to enable complex
other nodes and can therefore start publishing and subscribing message routing.
arbitrarily. If a new subscriber joins the network, they start
receiving messages on the topics they are interested in
immediately. The publisher does not have to keep track of
subscribers or address them individually, as these services are
handled by the broker.

TABLE II
GENERIC REQUIREMENTS FOR UL SYSTEMS
Component Requirement
Peer-to- • Actors must interact with peers in real-time.
peer • Actors are notified once new learning content or
Comm. activity has been posted, and locations from which
to retrieve the content.
Context • Actors posting new learning content or activities can
awareness specify one or more edge-devices through which the
content or learning activities can be retrieved.
• Actors’ choice of which edge-devices to publish
content or activities to should relate to the topic and
learning outcomes.
• Actors can retrieve content or learning activities
from edge-devices that are physically located in
areas that relate to the learning content.
• Actors can respond to content or learning activities
via any of the relevant edge-devices.
Teacher • Teachers can pose learning content or activities
supervision independently of location.
• A teacher can dynamically assign and un-assign
edge-devices to one or more different categories.
• A teacher can receive real-time learning analytics of
one or more individuals or groups of actors based on
the teacher's interest.
Data • Actors can choose to integrate sensor readings into Fig. 3. Comparison of the protocols’ communication paradigms.
their own content, activities, or responses.
• Actors can choose to attach or link to content media
TABLE III
files. COMPARISON OF PEER-TO-PEER COMMUNICATION IMPLEMENTED BY EACH
• The system must data formats used by common PROTOCOL
learning object standards (e.g., SCORM [47], QTI Features Polling Publish/Subscribe
[48], etc.) HTTP MQTT AMQP CoAP XMPP
Reliability • The edge-devices should function as standalone Native No Yes - Yes - Yes - Yes -
units in case of network problems. support for simple complex mimicked simple
• A new edge-devices added or removed from the peer-to- through
system during operation should not disrupt ongoing peer observe
processing. mode
• Edge-devices, teachers, and students should be Flexibility Low Medium High Low Medium
updated with all offline interactions once lost in routing
communication is reconciled. Scalable at No Yes Yes Yes Yes
Ubiquity • Actors can access all functionalities of the system client level
Scalable at Yes Yes Yes Yes Yes
regardless of the type of device they own.
server level
Robust No Yes Yes No Yes
Classic protocols such as HTTP implement the request- Reliable No Yes Yes No Yes
response pattern. As Fig. 3 shows, Constrained Application
Protocol (CoAP) [49] was originally a request-response based A summary of how well each protocol implements peer-to-
on HTTP which was extended to implements an “observer” peer communication is presented in Table III. As the table
mode that mimics the publish/subscribe pattern. Several recent shows, for the most part, the publish/subscribe protocols are
UL environments have utilized the publish-subscribe design similar in terms of native support for peer-to-peer applications
pattern. For example, PSILAN [18] and SMILE [17] utilized as well as readiness for large scale systems in terms of
XMPP to facilitate communication between learners and scalability, reliability, flexibility, and robustness. Therefore, a
teachers. Similarly, IOT4SSAE [37] and GAIA [39] used designer building such system requires guidance on which is
Message Queuing Telemetry Transport (MQTT) [16]. As Fig. the most appropriate for their UL application.

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

Fig. 4. Proposed architecture for ubiquitous context-aware learning system.

IV. PROPOSED ARCHITECTURE
The overall system architecture implementing the
requirements from Table II is shown in Fig. 4.
A. System Components
The architecture has three parts: front-end applications, edge
device, and back-end servers. The various components
communicate over a peer-to-peer messaging network to allow
easy and flexible dissemination of information. Each of the
three components is explained next.
1) Front-End Applications
A front-end application enables learners and teachers to
interact with the system. As Fig. 4 shows, these applications can
be a Learner Mobile Device or a Teacher Device using a web-
browser. Teachers and learners create and view content or
learning activities using these applications. For example,
learners can use a web application to post and retrieve content,
and to connect with their peers as in [18] and [17]. Similarly, in
[6] and [10], front-end applications allowed learners to read
sensors from the edge devices and to connect with their peers.
The interaction could also use specialized hardware like the
Google Glass as described in [42].
2) Learning Edge Device
As shown in Fig. 4, a Learning Edge Device allows learners
or teachers to interact with their surroundings and retrieve
contextual information. These actors use capabilities of edge
devices to post or retrieve content or inquire about sensor
readings. Passive edge-device include QR-codes, an RFID tags,
NFC tags or Bluetooth Low Energy (BLE) beacons located at
interesting learning points. For example, a BLE beacon can
advertise that the child is in the playground. Active edge
devices use more sophisticated sensing and computation
technologies to enable intelligent interactions with the actors.
Examples are Raspberry-Pi-based Archi-pods [6], OBSY nodes
[10], Arduino microcontrollers [21], [22], or robots [45]. Fig.
5 shows commonly used edge devices and their specifications
in terms of memory available and processing power. The type
of device chosen for a specific ubiquitous learning scenario
typically depends on the required computational power,
memory, cost and support for various libraries. For example,
ESP8266 and ESP32 are commonly used edge devices
supporting build-in WiFi and ease of programming using a
variety of operating systems. Raspberry Pi is another commonly
used platform for applications that require more memory and
processing power and software libraries running on embedded
Linux platform.
In the proposed architecture shown in Fig. 4 an edge device
must implement three modules; sensing, processing, and
messaging. The first module is responsible for sensing and
consists of an assortment of analog and digital sensors. The
sensors vary from one system implementation to another
depending on learning design. For example, an inquiry-based
learning system implemented for a course in Architecture (e.g.,
[6]), may incorporate motion, temperature, humidity,
illumination, and air pollution sensors. As Fig. 4 shows, the
sensing module interfaces with a second module responsible for
data processing and storage. The processing module reads
sensor data upon request and interprets the data into intelligible
information. The processing module also includes persistence
storage or a database that stores sensor data along with other
information such as date and time the sensor readings were
taken. In addition to storing user-generated content, the storage
may also function as a cache memory for sensor readings as to
save power from repetitive requests within a short period of
time.
Finally, as shown in Fig. 4, the messaging module in a
learning edge device is responsible for communicating with
other learners, teachers, sensors, and data processing services in
the system. This module acts as a messaging client and is able
to send and receive learning content, sensor readings, and
performance reports while interacting with the system.

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

Fig. 5. Some candidate platforms for currently available learning edge devices.

There are two types of learning edge devices; on-site and
remote. Actors have direct access to on-site edge devices. For
example, learners walking around a campus, museum, or a
garden connect to on-site edge devices using WiFi to pose,
retrieve, and respond to content or request for learning
activities. Teachers or learners can select an audience to publish
their content to. Once new content and activities have been
posted to an edge device, the edge device is responsible for
publishing the content or learning activity to other edge devices
that are registered to serve the learners, and to notify the
learners that new content or learning activities are available. As
opposed to on-site edge devices, remote edge devices are
installed in areas that are not directly accessible; for example,
overseas monuments, rain forests, and deserts. Learners cannot
walk up these edge devices but need to communicate with them
by using mediators like the on-site edge devices.
3) Backend Servers
As Fig. 4 shows, various back-end servers are required and
typically include an application server, a database server and an
analytics engine. All new content or activities posted to an on-
site edge device are published to the backend server, which
manages, stores, and analyzes the information. As Table I
shows, the choice of database in current ubiquitous learning
systems ranged from SQL databases (e.g., MySQL), NSQL
databases (e.g., CouchDB, MongoDB), or Big Data
infrastructures such as Hadoop. Application servers provide the
business logic and glue between networks and other servers.
For example, explicit application servers were used in Archi-
Pods [6], the problem-based learning application [24], and the
language learning application (LOCH) [25]. Finally, analytics
and machine learning engines are used to make either real-time
or batch decisions based on data from the ubiquitous learning
systems. Through analytics engines it is possible for the teacher
to view performance analytics concerning a single learner,
classroom, or compare how their learners perform compared to
other classrooms in the system. For example, current systems
like [17], [40] used analytics engines to provide real-time
performance analytics. In addition, analytic servers allow one
to analyze learners with respect to dimensions like class, grade,
or a specific learning topic or outcome. The results can be
viewed by stakeholders in the form of graphs, and spreadsheets.
B. Use Cases
From the perspective of learners and teachers, there are three
key scenarios in ubiquitous learning systems; 1) the actor can
post new learning content or activities directly to an edge
device, 2) retrieve learning content/activities or current sensor
readings from an edge-device, and 3) submit a response to the
edge device. Each of these use cases is described next.
1) Post New Learning Content or Activities
As Fig. 4 shows, in this use case (Use Case #1), a learner or
a teacher posts new learning content or activities to an edge
device. The content can be an image, a video, comments, an
assessment item, a response to an assessment item, or any other
type of contribution, or could be a set of activities to perform
for learning. For example, in a SMILE [17] classroom, a learner
challenged their peers by posing a multiple-choice question and
attaching a relevant media item. Similarly, a student using
Archi-pods [6] could walk up to an edge device and post a
question about an architectural element in the physical space.
Posting new content can initiate a series of events, which may
include the new content being published to other edge devices
or to the application server. Other learners and teachers may not
automatically receive the content or proposed activities, but the
ones who subscribe to relevant topics may receive a notification
with the content identifier or link and the locations of the
nearest edge-devices hosting the content.
2) Retrieve Learning Content/Activity/Sensor Readings
As shown in Fig. 4, in the second use case (Use Case #2) a
teacher or a learner attempts to view new learning content or an
activity on the edge device. This could be a learner accessing a
quiz made up of their peers’ contribution as in SMILE, or a
learner retrieving information about a location from a QR-code
(e.g., as in [9], [20], [34]). In the proposed architecture, a learner
who has received new learning content/activity notification
uses the content identifier or link included in the notification

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
body to request the content body from a nearby edge device. An
actor can also request current sensor readings via the same
operation. On-site edge-device must maintain the partial state
of remote edge devices that might be of interest to actors, and
therefore, may receive sensor updates periodically. This ensures
that a recent reading from a remote edge-device is always
available should an actor request it.
3) Respond to Posting of New Learning Content
In the third use case (see Fig. 4), a learner posts a response to
new learning content or activity. Actors can comment on the
content or contribute new information about the content or
activity in a collaborative task [13], [26], or respond to one or
more assessment items [6], [26], [27]. In the proposed
architecture, this response mediated out using a nearby edge
device. This scenario is like the first use case except other
learners and teachers need not be notified. Furthermore, if the
content is an assessment item in the form of true-or-false,
multiple-choice, or fill-in-the-blanks, the response is assessed
locally, and the result and feedback are provided to the actor
immediately. The result is also sent to the edge device in the
same message as the response. The message is also published
to the back-end servers that performs real-time performance
analysis and publish it to teachers subscribed to the relevant
topics or class.
V. PERFORMANCE EVALUATION DESIGN
A. Objectives
The major focus of the performance evaluation were the edge
devices because they play a critical role in such systems. Edge
devices typically have resource constraints and being outdoors,
are often powered using solar cells or batteries. Power
consumption is therefore an important issue. Consequently,
objective of the performance evaluation was to compare the
reference architecture as implemented using the various types
of IoT brokers with respect to resources like power
consumption, CPU utilization, network bandwidth utilization,
and end-to-end latency in presence of network disturbances.
The RPi ran a NodeJS [51] application server. Content stored
on the edge device was stored using a local NSQL databased
called CouchDB [52]. CouchDB is a document-based database,
supporting JSON, and allows master-to-master syncing. The
on-site edge device engages in two types of communications;
the device acted like a server in learner-edge-device
communication, and a client in large-scale information
dissemination. The edge communication between a mobile
device of a student or a teacher and the edge device was based
on HTTP.
B. Experimental Setup
The experimental setup was designed to simulate use cases
using hardware similar to that which would be used in a real-
life implementation of the system.
1) Edge Device
Raspberry Pi (RPi) 3.0 [53], a low-cost development
microcomputer, was used as a representative learning edge
device. One reason for using Raspberry Pi was that unlike
1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
1
smaller platforms like ESP32 [54] and Photon [55], software
libraries for major broker architectures considered in this paper
were available for RPi. The technical specifications of the RPi
3.0 used in this paper are shown in Table IV.
TABLE IV
EDGE DEVICE SPECIFICATIONS
RPi 3.0 [53]
CPU 4× ARM Cortex-A53 at 1.2GHz
RAM 1 GB LPDDR2-900 SDRAM
Ethernet speed 94.3 Mbps
WiFi speed 20.9 Mbps
Storage 16GB microSD
OS Raspbian Jessie with PIXEL
2) Broker Architectures
Within the large network of edge devices, learners, teachers,
and back-end servers, four commonly used protocols in IoT
systems were considered; AMQP, MQTT, XMPP and CoAP.
First three protocols offer native publish/subscribe support.
Since CoAP is a request-response protocol, the ‘observe’ mode
was used to implement the publish/subscribe functionality. The
observe mode is known to have optimization issues while
scaling which can be addressed using proxies and caches [56].
However, this paper used a standard CoAP observe
implementation without proxies.
3) Evaluation Use Case
Use Case #1 shown in Fig. 6 was used for this experiment
because this use case placed the highest demands on resources
and was a superset of others.
Fig. 6. Use case 1: post new learning content or activity.
4) Posted Content
Data from an assessment bank from an e-Learning system
was used to simulate the selected use case. The set contained a
total of 2890 assessment items (mean size = 1223 Bytes, max =
65873 Bytes, min = 124 Bytes, median size = 486 Bytes,
standard deviation = 2774) in QTI (XML) format. The
assessments included short answer, multiple choice, and true or
false assessment items. The assessment items were either text-
based or included a serialized media object like a photograph.
The original XML-based assessment items were converted to
JSON objects.
5) Data Collections Setup
As shown in Fig. 7, each learner was simulated using a
NodeJS [51] process that sampled a random item from a local
database and posted it to an edge device. JXCore [57] was used
to spawn multiple processes to emulate multiple learners. Once
the learning edge device received the item, it published the item
via MQTT to a local messaging broker, to be published to other
edge devices. Time delay was measured using timestamps.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

Fig. 7. Evaluation setup.

The traffic was shaped using a traffic shaping tool, running arriving out of order due to multiple paths. Every run consisted
on the broker machine. Network parameters such as throughput of 16 identical clients, each representing a learner, publishing a
were measured using Wireshark [58], while the power new content item every minute each, over a period of 10
consumption was measured using an inline USB ammeter. minutes, and each run was repeated 10 times. A total of 1600
Finally, resource consumption of the edge device, mainly CPU randomly selected content items were posted with individual
utilization, was measured using NMON [59]. latency values.
C. Experiment I: Network Performance Evaluation TABLE VI
EXPERIMENT I DEPENDENT VARIABLES
The objective of first experiment was to assess network Variable Definition Unit
performance of each architectural variant under imperfect Latency Time needed for a content item to travel ms
network conditions. The primary performance metric used was from the publishing edge-device to other
network latency. Latency is defined as the time (msec) required edge-devices in the system
Bandwidth Data transmission rate bps
for a packet published from one edge device to reach another utilization
edge device. “Sent” and “received” timestamps were added to
each packet depending on when the packet left the edge device, TABLE VII
and when it reached another edge device, respectively. The EXPERIMENT I CONTROL VARIABLES
difference was taken as latency (msec). The second network Variable Definition Value
estimate was bandwidth utilization in terms of bits/second. The Channel Maximum bitrate achievable by the 20.9 Mbps
bandwidth Ethernet channel after network shaping
channel bandwidth was set at 20 Mbps, which was the edge has been activated, but no metrics were
device’s WiFi speed, and the bandwidth for a 4G link. The explicitly set
independent, dependent and control variables for the first Frequency Number of content items posted by a 1CI/min
experiment are shown in Table V, Table VI, and Table VII, given student client in a minute
Students Number of student client processes 16
respectively. connected at any given moment in time
TABLE V
EXPERIMENT I INDEPENDENT VARIABLES
Variable Definition Min Δ Max D. Experiment II: Resource Consumption
Lag Hold the packets for a short 100 100 1000 The objective of the second experiment was to assess the four
period of time to emulate network variants in terms of resource usage including energy
lagging in milliseconds
Throttling Probability of a packet being 5% 5% 90%
consumption and CPU utilization of the edge device. This type
blocked for a certain amount of of evaluation is helpful in estimating the cost of implementing
time due to a network bottleneck and operating such as system in terms of hardware. The
Duplicate Send cloned packets right after to 5% 5% 50% independent, dependent, and control variables for this
the original one
Out of Re-arrange the order of packets 5% 5% 50%
experiment are shown in Table VIII, Table IX, and Table X,
Order respectively.
TABLE VIII
EXPERIMENT II INDEPENDENT VARIABLES
As Table V shows, four main network disturbances were Variable Definition Min Max
considered: network lag due to slow network or network traffic, Idle Time The waiting time between two 4 min 1 min
bottlenecks that may occur due to legacy network elements, consecutive new content post actions
Students Number of actor client processes 1 128
duplicate packets resulting from retransmissions, and packets

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
TABLE IX
EXPERIMENT II DEPENDENT VARIABLES
Variable Definition Unit
Power Power consumed calculated based on Watts
ammeter values
CPU CPU% consumed by the server app %
utilization server during the experiment
TABLE X
EXPERIMENT II CONTROL VARIABLES
Variable Definition Value
Channel Maximum bitrate supported by the edge 18.8 Mbps
bandwidth device NIC
Server Number of other processes using server N/A
load resources
Learners were simulated via a script that fetched a random
content/activity item from the database and posted it to the edge
device. Multiple concurrent processes running the script were
used to simulate the required number of learners and ranged
between 1 to 128 concurrent learners. The simulations ran for
10 minutes at a time, where either the frequency of posting or
the number of learners was changed every run to simulate all
possible combinations of frequency and concurrent learners.
The simulation started with one student publishing once every
4 minutes, all the way to 128 concurrent students publishing
once every minute. While publishing every 4 minutes
represents a normal quiet class session, the extreme case is
meant to simulate the case of an exam where large numbers of
learners in one school are publishing to the same local
infrastructure. This resulted in a total of 24, 10-minute-long test
runs. This process was repeated 12 times to obtain accurate
results and eliminate the influence of other factors such as other
processes running on the edge device or the server.
VI. PERFORMANCE EVALUATION RESULTS
A. Experiment I: Network Performance Results
The results of the first experiment are divided into two
sections: Bandwidth Utilization, and Latency.
1) Bandwidth Utilization
According to the experimental design described earlier,
messages were sent between edge devices for ten minutes
scenarios over a relatively idle 20Mbps WiFi network. The
bandwidth utilization was based on bits sent and received over
the same period. A descriptive analysis of bandwidth utilization
is shown in Fig. 8. As the figure shows that while the three TCP-
based protocols (i.e., MQTT, AMQP, XMPP) reported a
bandwidth utilization of around 3~4 kbps, UDP-based CoAP’s
bandwidth utilization was significantly lower, at around 1.4
kbps. It should be noted that each protocol contributes a specific
header size that can affect the average amount of data
transferred and hence bandwidth utilization. Header sizes and
their overhead will be discussed in a later section.
The largest contributor to bandwidth utilization for TCP is
connection maintenance and reliability packets. Messages such
as acknowledgment, handshakes and reconnections, and keep-
alive packets add a significant amount of data to the network
which in turn increase the network bandwidth utilization. Since
CoAP uses UDP, it reduces the bandwidth cost by incorporating
1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
1
minimal reliability features. This represents a major advantage
for CoAP in a constrained environment where bandwidth is
expensive and limited; in this case, CoAP used almost one
quarter of the bandwidth to achieve the same results.
Fig. 8. Bandwidth utilization on an ideal channel (16 students posting 1
content item/minute).
2) Latency
The end-to-end latency was defined as the time required for
a message to travel from a publisher edge device to a subscriber
edge device. The general trend on how the latency was affected
by the various network disturbances is shown in Fig. 9. Since a
range of values for each input variables like lag, or duplicates,
were considered, the network performance results will be
discussed based on using the midpoint of these values. For
example, the midpoint value for lag (Fig. 9 (a)) was 500 msec.
The latency data under each network disturbance were not
normally distributed (Shapiro test; p<0.05). Variances across
sub-groups were, however, homogeneous (Levene test;
p>0.05). Consequently, the medians (instead of means) were
used for comparing latency across protocols. The results are
summarized below:
• There was a statistical difference between the median
latency for the midpoint (30%) duplicates (Kruskal-Wallis;
chi-squared = 242.5, p<0.05) for the various architectural
alternatives. MQTT had the lowest latency among the four
alternatives.
• There was a statistical difference in median latency
for midpoint lag (500 milliseconds) (Kruskal-Wallis; chi-
squared = 3646.1, p<0.05); CoAP had the lowest median
latency.
• There was a statistical difference in median latency
for an out of order condition (30% packets arriving out of
order) (Kruskal-Wallis; chi-squared = 366.57, p<0.05);
MQTT had the lowest median latency under these
conditions.
• There was a statistical difference in median latency
between the various architectural options for throttling
(50% of the packets throttled) (Kruskal-Wallis; chi-
squared = 449.38, p < 0.05); CoAP had the lowest latency.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

Fig. 9. Median latency response to (a) network lag, (b) packets arriving out of order, (c) duplicated packets, (d) throttle packets.

In summary, MQTT and CoAP generally had the lowest heavily on sending large media files. For such situations,
latency under various network disturbances. However, except MQTT and AMQP were found to be a better choice than CoAP.
for lag, the worst latency for the other three disturbances was
still less than 100 milliseconds. Even for the lag, a latency of a B. Experiment II: Resource Consumption Results
little under 3 seconds for 64 students publishing content every The results of this experiment are shown in two parts: power
minute is very acceptable for most ubiquitous learning consumption and CPU Utilization.
scenarios.
Little’s Law (1) can be used to estimate the number of 1) Power Consumption
content or learning items queued in the system when it was in Power consumption is expressed in Watts. The power
stable state. In (1), L is the average number of items in the consumed over a certain period, measured in Watt-hours (Wh)
queue, λ is the period (number of items sent/second), W is the for a full day was calculated as shown in (2).
average latency (seconds). P=V(V) .I(A) .t(h) (2)
L = λW (1)
In the worst-case scenario λ = 1 items posted/min or 1/60 = The solar panel size in Watts [62] required to charge an edge-
0.016 items posted/sec. The worst average latency was found to node was then calculated using (3).
be 2.5 seconds and therefore W=2.5sec. The number of items Pday(Wh)
Panel Size(W) = (3)
queued in the system at any given moment can then be tpeak(h)
calculated to be on average 0.016 x 2.5 = 0.042 items. Since the Maximum power consumption per day of an edge device for
average message size was around 1250 bytes, there was on the greatest number of students (128 students) and the highest
average 0.042 items x 1250 bytes/item = 53 bytes in the queue. frequency of posting (1 content item/minute) are shown in
This means that, in practice, there was little queuing. Table XI. Table XI shows that there were no practical variations
Using the same formula, it is also possible to estimate the in power consumption across the architectural options. In the
maximum number of consecutive items that can be sent through worst-case scenario, the difference was less than 5%. Table XI
the system without queueing (L<1). Assuming the 2.5 second also shows that using a peak sunshine of 4.5 hours/day, the solar
worst latency, the queueing would begin at posting more than panel size and battery prices were the same for each
24 items/min. In other words, if 24 students were publishing 1 architectural alternative.
item/minute then one would begin to see queuing which would TABLE XI
MAXIMUM POWER CONSUMED BY EACH ARCHITECTURE AT MAXIMUM
eventually have an effect on latency. The results reported here SYSTEM STRESS (128 STUDENTS PUBLISHING CONTENT EVERY MINUTE)
are consistent with similar experiments conducted by others but Baseline AMQP CoAP MQTT XMPP
diverge when the system was stressed further. For example, this
Powerday (Wh) 40.22 43.56 44.40 42.71 44.13
happens when message size exceeds tens of kilobytes [60], or
when posting frequency exceeds 10 items/second [61]. While it Panel size (W) 8.94 9.68 9.87 9.49 9.81
is unreasonable to assume that learners can post content at such Battery price $10 $10 $10 $10 $10
a high frequency, the system can be stressed if the learners rely

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

Fig. 10. Average power consumption (Watts) by each Architecture variant for different numbers of students and period between two consecutive publishes.

Fig. 10 shows how the power consumption varied with variants, there were no practical differences between the power
respect to number of students and the posting frequency. Fig. consumed.
10 shows that by increasing the number of students, the median
of power consumption less than 1.77 Watts for any alternatives.
In addition, CoAP tended to perform generally better with
lower power consumption at all test scenarios. MQTT
demonstrated a tight trend at each period but AMQP showed
higher variance.
Fig. 11 shows power consumption for a typical scenario,
where 32 students were publishing content once every 4
minutes each. There was a statistically significant difference
between the median power consumed by various options
(Kruskal-Wallis; chi-squared = 844.45, p <0.05); CoAP had the
lowest energy consumption with a middle rank of 12649. Fig.
11 shows that across broker architectures, power consumption
followed a bimodal distribution with the two peaks representing
conditions when the edge device was idle as opposed to
processing data.
During idle time, the learning edge device consumed on
average 1.65 Watts, and 1.92 Watts when the device was busy. Fig. 11. Probability distribution of power consumption at the typical scenario
A Kruskal-Wallis test showed a statistically significant point (32 users publishing content once every 4 minutes).
difference between the median power consumed by each
variant for idle (chi-squared = 348.37, p <0.05) and busy (chi- TABLE XII
POWER CONSUMPTION (WATT) FOR IDLE AND BUSY STATES
squared = 1339.5, p <0.05) conditional distributions. However, AMQP CoAP MQTT XMPP
as Table XII shows there were no practical difference between Busy
the power consumption across architectures. Mean 1.925 1.911 1.932 1.935
In summary, the increase in power consumption was almost Stdv 0.0922 0.0723 0.0825 0.0863
log-linear as the number of students interacting with the edge Idle
Mean 1.650 1.653 1.648 1.652
device were increased. In addition, even though there were Stdv 0.0123 0.0118 0.0137 0.0119
statistical differences in power consumption between the

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

Fig. 12. CPU% over 5 minutes for each protocol. students=128, frequency=1CI/min.

2) CPU Utilization and can adequately handle adverse network conditions.

The average CPU utilization for the learning edge device Therefore, the ultimate choice of which alternative to use may
publishing at the rate of one content/activity item per min depend on qualitative aspects. These are discussed next.
(CI/min) for varying number of students is shown in Table XIII.
As the table shows, the average CPU utilization was typically VII. EVALUATING NON-FUNCTIONAL REQUIREMENTS
around 2-3% and was less than 4% in the worst case.
TABLE XIII This section evaluates the non-functional requirements of
AVERAGE CPU UTILIZATION (% OF CPU) each architectural variant. Primary non-functional requirements
Variant
Number of students posting 1 CI /min are ease of implementation, security of the implementation,
2 4 8 16 32 64 128 reliability of content delivery, and flexibility to reflect the
AMQP Avg. 2.16 2.20 2.26 2.32 2.44 2.63 3.14
sd 0.39 0.51 0.77 1.32 2.00 3.21 5.03 structure of the learning material. It is important to take these
CoAP Avg. 1.61 1.62 1.63 1.65 1.67 1.71 1.79 into account because a variant with higher performance may not
sd 0.27 0.29 0.38 0.47 0.72 0.80 1.37 be feasible if it does not fulfil non-functional requirements.
MQTT Avg. 1.98 2.01 2.05 2.12 2.18 2.29 2.57
sd 0.44 0.55 0.79 1.39 2.16 3.46 4.88 A. Maximum Payload Size Supported
XMPP Avg. 2.02 2.07 2.11 2.19 2.29 2.43 2.78
sd An important aspect in selecting one of the four variants (e.g.,
0.53 0.70 1.14 1.97 3.17 4.51 6.65
MQTT) is its ability to support typical learning content sizes
Fig. 12 also shows the CPU % utilization over a 5-min-long without the need to implement segmentation. For example, in
run for each architectural variant with 128 student clients addition to text, users may share multimedia content such as
posting one content per minute each. Given that the peak CPU images, audio recordings, or videos. The variants studied here
utilization at any point was less than 50% of the available either offered a high payload size limit or were designed so that
processing power, the edge device used was more than the payload size limit was set by and depended on the broker.
sufficient to handle the load and could be replaced by a system Once exception was CoAP which has a maximum default
with lower processing power. For example, for CoAP that used payload size of 1280 bytes and 127 bytes if used over
only 20% of available CPU power, a much smaller 6LOWPAN. This may become an issue if the learning content
microcontroller (e.g., ESP32) could be used. size does not fit this limit. For example, in this experiment, out
C. Main Findings of Performance Analysis of the 2890 content items, 505 (17.5%) content items were too
large to fit a single CoAP packet. Sending larger content would
While CoAP demonstrated much lower bandwidth
utilization, and a latency of up to a second less than XMPP, the require complex programming on both client and server ends.
difference is negligible in practical terms. CoAP and MQTT B. Protocol Overhead
had a slight advantage over the rest of the variants in resource The second metric concerned with message size is overhead
consumption. Finally, the results presented here for CPU percentage. In constrained environments, packet overhead
consumption are consistent with those reported elsewhere [61]. should be minimized as much as possible to save bandwidth.
The main takeaway from the quantitative evaluation is that even Header overheads for content used in this experiment is shown
though CoAP was generally more resource-efficient, a system in Table XIV. As Table XIV shows, MQTT had the lowest
built using the proposed architecture and employing any of the overhead while XMPP was the worst. CoAP and MQTT had
four variants can perform well, is capable of handling traffic, similar overhead.

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

TABLE XIV using TLS or DTLS added an overhead of less than 5% in power
PROTOCOL OVERHEAD
consumption for severely constrained edge devices like an
Median
Protocol
Mean Packet %Overhead
Packet Size
%Overhead ESP32. Therefore, it is likely that all protocols are able to
Size (Bytes) for Mean for Median implement optional security features with little energy
(Byte)
Raw 1221 486 overhead.
MQTT 1294 5.64% 559 13.06% TABLE XV
CoAP 1301 6.15% 566 14.13% OPTIONAL SECURITY FEATURES
AMQP 1340 8.88% 605 19.67%
Protocol Optional Comments
XMPP 1442 15.33% 730 33.42%
feature
C. Reliability AMQP TLS [67] May be an issue with low resource devices
SASL [68] May be an issue with low resource devices
Reliability is the assurance that learning content or activity is X509 [69]
always delivered regardless of the state of the various edge CoAP DTLS [70]
devices. In learning settings, especially when graded content IPSec [71]
such as quizzes are being exchanged, it is vital that the system CoAP security
options [49]
offers reliable communication and ensures that learners’ MQTT TLS Problematic for constrained devices
contributions are not lost even with an unreliable wireless TLS-PSK [72] Not widely supported
network. The concept of queuing messages is therefore X509 Only available for MQTT over WebSockets
important. Second, when a new edge-device or user device is XMPP TLS May be an issue with low resource devices
SASL May be an issue with low resource devices
being added to the system, or a device losses access to the
system, content should still be delivered. The introduction of a
new device to the system should be as seamless as possible in E. Adequacy of Representation
that previously posted content items relevant to an edge device In ubiquitous learning systems, a key component is the user’s
in that location and context should immediately be delivered. In ability to publish and subscribe to topics based on a curriculum.
addition, devices can go offline because of technical issues, or Curricula often follow a hierarchy like the one shown in Fig.
because they were moved to another location/context. Once the 13. Learning activities are mostly organized around curricular
device is reconnected, the device should receive all the previous items as well. For example, a teacher in “School 1” may want
content/activity contributions as well. Publish/subscribe to pose a Science learning activity to every 6 th grader in their
protocols like AMQP, MQTT and XMPP support message
school. The teacher, however, may not want to publish this
queuing on the broker side and republish missed content items.
activity to 6th graders in other schools, or to students in other
This is not the case with CoAP. The observer mode in CoAP is
still at draft stage, and therefore, does not implement full grades in the same school. Alternately, another teacher may
functionality of other publish/subscribe protocols. Therefore, want to target a question related to “Past Tense” in English
CoAP is less reliable than other protocols. Grammar, to all 5th grade students around the world.
This type of hierarchical posting and subscription is natively
D. Security supported by publish/subscribe protocols like MQTT and
Security is an issue rarely discussed in ubiquitous learning AMQP. For example, MQTT implements the concept of topic
systems [63]. Information exchanged within the system can hierarchies, where topics can be cascaded and summarized.
expose sensitive information such as the location of individual AMQP also offers the option of using regular expressions when
learners in an outdoor learning setting. It is vital that only matching subscribed topics. Protocols like XMPP and CoAP,
authorized users can access such information. Furthermore, as on the other hand, do not provide native support for such topic
the exchange of learning content can impact a learner’s grades, hierarchies. Therefore, significant programming effort is
both teachers and learners should feel safe interacting with the required to implement such functionality for these protocols.
system without the fear of cheating or data vandalism taking
place.
By default, none of the architectural alternatives is secure.
However, each variant offers various security options to protect
the privacy and integrity of the system and its users. These
security options are shown in Table XV. IoT security in
ubiquitous learning applications mostly focuses on two
concepts: a) user authentication and authorization, and b) data
integrity and confidentiality [64]. Network security also plays a
greater part in maintaining a fair assessment and grading system
[65]. Information about learners’ locations, activities, as well as
personal information is exchanged through the system which
must be encrypted to protect their privacy. Equally critical is
securing data flowing through the system such as feedback and
results and protecting them from unauthorized access and
tampering. A recent study of security features and cost
Fig. 13. Example of curriculum as a topic hierarchy.
comparing MQTT and CoAP [66] found that adding security

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
F. Summary of Findings
The comparison between the non-functional features offered
by each of the four protocols highlighted the shortcomings of
CoAP in terms of limits on content size and lack of native
support for topic hierarchies. Alternatively, MQTT and AMQP
offer a fixed and small overhead, support very large content
items, implement security features at marginal cost, and
natively support topic hierarchies. XMPP is the worst as it has
larger overhead and a lack of native support for topic hierarchy.
VIII. CONCLUSION
This paper has synthesized the requirement of ubiquitous
learning systems and proposed a generalized architecture based
on IoT technologies. The architecture was implemented and
evaluated experimentally and based on non-functional
requirements. CoAP (in observe mode) appears to be an
adequate choice for severely resource-constrained edge devices
but may face issues in reliability, content size and lack of
support for topic hierarchies. For most applications, the MQTT-
based variant seems appropriate. However, since there are little
differences between MQTT and AMQP in terms of latency and
power consumption, situations that require more sophisticated
filtering and routing could use AMQP as the architecture of
choice. The only issue here would be that MQTT has a wider
developer community and software libraries available for more
embedded platforms.
Regardless of which variant is used, the proposed
architecture more than sufficiently meets the requirements of
most ubiquitous learning systems discussed. Another advantage
of this architecture is that it can be easily expanded. For
example, adding heterogenous edge devices like smaller
microcontrollers or smartwatches is simply a matter of
including them as additional edge devices with appropriate
client software. For example, most current smartwatches like
Samsung (Tizen), Apple, Huawei (Android), and FitBit support
MQTT directly or through a companion mobile device. Indeed,
it is also possible to easily connect multiple ubiquitous learning
systems if they share the same messaging broker or by using
bridging brokers. For example, ubiquitous learning systems
from gardens of various schools can be easily connected where
students from one school can collaborate with students in other
schools regardless of the physical location.
The work presented here was limited to analyzing one
commonly used representative learning edge device and
experiments were conducted using real content data from an
assessment databank. It is entirely possible that results may
vary in situations that require widely different period or content
size. However, the proposed architecture is stable and scalable
by design. In the future it is possible and recommended to
experiment with other IoT messaging protocols such as Data
Distribution Service (DDS) [73]. It is also possible to evaluate
the performance of the variants based on the resources available
such as wireless network technology. While WiFi is widely
used in IoT applications and is commonly available in
educational spaces, long range low power protocols such as
LoRaWAN [74] and NB-IoT [75] are gaining popularity in IoT
1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
1
systems. For example, a variation of the architecture can be
implemented where rather than edge devices communicating
over the learning space’s WiFi network, edge devices from
numerous spaces around a city could all communicate directly
with datacenter located in the city using LoRaWAN. While this
could pose new challenges in terms of bandwidth, data rates,
and security, such architectures can also reduce the cost of the
system and change the way data is aggregated from edge to data
center. Another approach which may offer a similar cost-
performance tradeoff is opting for more constrained devices at
the edge. Rather than a Raspberry Pi, it is possible to
experiment with more modest Arduino-based microcontrollers
to assess how much the cost of hardware can be reduced while
maintaining key performance criteria.
Additionally, future work could lead research in the direction
of designing and optimizing the core segment of the system, or
the data center. It would be interesting to focus on testing and
evaluating other components of the proposed architecture such
as and the back-end servers and databases. The latter can prove
exceptionally interesting with the incorporation of machine
learning, analytics and issues associated with fog and
computational offloading [76].
In conclusion, this work aims to shine the light on
performance aspects of ubiquitous learning that are not
commonly addressed when proposing topic-specific
implementations, and inspire new works that examine various
segments of a modern ubiquitous learning system in order to
eventually create a reliable, optimized, and low cost
architecture which can be used as a standard for such
applications regardless of the material or available resources.
REFERENCES
[1] B. Gros, “The Dialogue Between Emerging Pedagogies and Emerging
Technologies,” in The Future of Ubiquitous Learning: Learning
Designs for Emerging Pedagogies, B. Gros, Kinshuk, and M. Maina,
Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2016, pp. 3–23,
doi: 10.1007/978-3-662-47724-3_1.
[2] G. Avellis and A. Finkelstein, “Innovative use of mobile learning for
occupational stress: evaluation of non-functional requirements and
architectures,” in Proc. IEEE Intl. Workshop Wireless and Mobile
Technologies in Education (WMTE), Tokushima, Japan, Nov. 28-30,
2005, pp. 146–148, doi: 10.1109/WMTE.2005.36.
[3] L. A. Cárdenas-Robledo and A. Peña-Ayala, “Ubiquitous learning: A
systematic review,” Telemat. Inform., vol. 35, no. 5, pp. 1097–1132,
Aug. 2018, doi: 10.1016/j.tele.2018.01.009.
[4] G.-J. Hwang, C.-C. Tsai, and S. J. H. Yang, “Criteria, Strategies and
Research Issues of Context-Aware Ubiquitous Learning,” J. Educ.
Technol. Soc., vol. 11, no. 2, pp. 81–91, 2008.
[5] A. Mikroyannidis, “weSPOT: A personal and social toolkit for inquiry-
based learning,” in Proc. Intl. Conf. Web and Open Access to Learning
(ICWOAL), Dubai, United Arab Emirates, Nov. 25-27, 2014, pp. 1–4,
doi: 10.1109/ICWOAL.2014.7009208.
[6] S. Shapsough, S. Amin, H. Ahmed, I. Zualkernan, and K. Mitchell,
“ARCHI-PODS: Ubiquitous Learning Technology to Teach
Architectural Design Principles to Architecture Students,” in Proc. Intl.
Technology, Education and Development Conf. (INTED), Madrid,
Spain, Mar. 2-4, 2015, pp. 4338–4347,
[7] C. Pimmer, M. Mateescu, and U. Gröhbiel, “Mobile and ubiquitous
learning in higher education settings. A systematic review of empirical
studies,” Comput. Hum. Behav., vol. 63, pp. 490–501, Oct. 2016,
10.1016/j.chb.2016.05.057.
[8] H. Rodrigues, F. Almeida, V. Figueiredo, and S. L. Lopes, “Tracking
e-learning through published papers: A systematic review,” Comput.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) <
Educ., vol. 136, pp. 87–98, Jul. 2019, doi:
10.1016/j.compedu.2019.03.007.
[9] J. Gómez, J. F. Huete, O. Hoyos, L. Perez, and D. Grigori, “Interaction
System based on Internet of Things as Support for Education,”
Procedia Comput. Sci., vol. 21, pp. 132–139, 2013, doi:
10.1016/j.procs.2013.09.019.
[10] P. Putjorn, C. S. Ang, and D. Farzin, “Learning IoT Without the ‘I’-
Educational Internet of Things in a Developing Context,” in Proc.
Workshop Do-it-yourself Networking: An Interdisciplinary Approach,
New York, NY, USA, Mar, 18, 2015, pp. 11–13, doi:
10.1145/2753488.2753489.
[11] S. Alletto et al., “An Indoor Location-Aware System for an IoT-Based
Smart Museum,” IEEE Internet Things J., vol. 3, no. 2, pp. 244–253,
Apr. 2016, doi: 10.1109/JIOT.2015.2506258.
[12] T.-Y. Liu, T.-H. Tan, and Y.-L. Chu, “Outdoor Natural Science
Learning with an RFID-Supported Immersive Ubiquitous Learning
Environment,” J. Educ. Technol. Soc., vol. 12, no. 4, pp. 161–175,
2009.
[13] S. Akkerman, W. Admiraal, and J. Huizenga, “Storification in History
education: A mobile game in and about medieval Amsterdam,”
Comput. Educ., vol. 52, no. 2, pp. 449–459, Feb. 2009, doi:
10.1016/j.compedu.2008.09.014.
[14] IETF, “HTTP - Hypertext Transfer Protocol,” 1999. [Online].
Available: https://tools.ietf.org/html/rfc7231. [Accessed: 03-May-
2017].
[15] P. Saint-Andre, “Extensible Messaging and Presence Protocol (XMPP):
Core,” 2011. [Online]. Available: https://tools.ietf.org/html/draft-ietf-
xmpp-3920bis-17.html. [Accessed: 03-May-2017].
[16] A. Banks and R. Gupta, “MQTT Version 3.1. 1,” OASIS Stand., 2014.
[Online]. Available: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/
mqtt-v3.1.1-os.html. [Accessed: 03-May-2017].
[17] E. Buckner and P. Kim, “Integrating technology and pedagogy for
inquiry-based learning: The Stanford Mobile Inquiry-based Learning
Environment (SMILE),” Prospects, vol. 44, no. 1, pp. 99–118, Apr.
2014, doi: 10.1007/s11125-013-9269-7.
[18] S. Seol, A. Karimi, P. Kim, A. Goyal, B. Dodson, and M. Lam,
“Pocketschool interactive Learning Ad-hoc Network,” in Proc. Intl.
Conf. e-Education, Entertainment and e-Management, Bali, Indonesia,
Dec. 27-29, 2011, pp. 70–75, doi: 10.1109/ICeEEM.2011.6137845.
[19] S. Shapsough, S. E. Shapsough, M. Hassan, and I. Zualkernan, “IoT
technologies to enhance precision and response time of mobile-based
educational assessments,” in Proc. Intl. Conf. Computational Science
and Computational Intelligence, Las Vegas, NV, Dec. 15-17, 2016, pp.
202–205, doi: 10.1109/CSCI.2016.0045.
[20] I.-C. Hung, X.-J. Yang, W.-C. Fang, G.-J. Hwang, and N.-S. Chen, “A
context-aware video prompt approach to improving students’ in-field
reflection levels,” Comput. Educ., vol. 70, pp. 80–91, Jan. 2014, doi:
10.1016/j.compedu.2013.08.007.
[21] I. A. Zualkernan, N. Al-Khunaizi, S. Najar, and N. Nour, “Prête-à-
apprendre+: Towards ubiquitous wearable learning,” in Proc. 10th
IEEE Intl. Conf. Advanced Learning Technologies (ICALT), Sousse,
Tunisia, Jul. 5-7, 2010, pp. 740–741, doi: 10.1109/ICALT.2010.216.
[22] I. Arroyo, I. A. Zualkernan, and B. P. Woolf, “Hoodies and barrels:
Using a hide-and-seek ubiquitous game to teach mathematics,” in Proc.
11th Intl. Conf. Advanced Learning Technologies (ICALT), Athens,
USA, Jul. 6-8, 2011, pp. 295–299, doi: 10.1109/ICALT.2011.91
[23] S.-L. Wang and C.-Y. Wu, “Application of context-aware and
personalized recommendation to implement an adaptive ubiquitous
learning system,” Expert Syst. Appl., vol. 38, no. 9, pp. 10831–10838,
Sep. 2011, doi: 10.1016/j.eswa.2011.02.083.
[24] I. A. Zualkernan, G. G. A. Husaini, K. F. Loughlin, J. G. Mohebzada,
and M. E. Gaml, “Using Problem Posing, Problem Solving for Game-
Based Learning in Remote Labs,” in Proc. IEEE 12th Intl. Conf.
Advanced Learning Technologies (ICALT), Rome, Italy, Jul. 7-10,
2012, pp. 716–717, doi: 10.1109/ICALT.2012.179.
[25] Ogata, Hiroaki, Saito, Nobuji A., Paredes, J., Rosa, G., Martin, Gerardo
Ayala San, and Yano, Yoneo, “Supporting Classroom Activities with
the BSUL System,” Educ. Technol. Soc., vol. 11, no. 1, pp. 1–16, 2008.
[26] T.-Y. Liu and Y.-L. Chu, “Using ubiquitous games in an English
listening and speaking course: Impact on learning outcomes and
motivation,” Comput. Educ., vol. 55, no. 2, pp. 630–643, Sep. 2010,
doi: 10.1016/j.compedu.2010.02.023.
[27] C.-M. Chen and Y.-L. Li, “Personalised context-aware ubiquitous
learning system for supporting effective English vocabulary learning,”
1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.
1
Interact. Learn. Environ., vol. 18, no. 4, pp. 341–364, Dec. 2010, doi:
10.1080/10494820802602329.
[28] R. Reynolds, K. Walker, and C. Speight, “Web-based museum trails on
PDAs for university-level design students: Design and evaluation,”
Comput. Educ., vol. 55, no. 3, pp. 994–1003, Nov. 2010, doi:
10.1016/j.compedu.2010.04.010.
[29] M. Coccoli and I. Torre, “Interacting with annotated objects in a
Semantic Web of Things application,” J. Vis. Lang. Comput., vol. 25,
no. 6, pp. 1012–1020, Dec. 2014, doi: 10.1016/j.jvlc.2014.09.008.
[30] C.-C. Chen and T.-C. Huang, “Learning in a u-Museum: Developing a
context-aware ubiquitous learning environment,” Comput. Educ., vol.
59, no. 3, pp. 873–883, Nov. 2012, doi:
10.1016/j.compedu.2012.04.003.
[31] C. Cahill, A. Kuhn, S. Schmoll, A. Pompe, and C. Quintana, “Zydeco:
Using Mobile and Web Technologies to Support Seamless Inquiry
Between Museum and School Contexts,” in Proc. 9th Intl. Conf.
Interaction Design and Children, Barcelona, Spain, Jun. 9-12, 2010, pp.
174–177, doi: 10.1145/1810543.1810564.
[32] Y. H. Chang and B. S. Lin, “An Inquiry-based Ubiquitous Tour
System,” in Proc. Intl. Conf. Complex, Intelligent, and Software
Intensive Systems, Seoul, South Korea, Jun. 30 - Jul. 2, 2011, pp. 17–
23, doi: 10.1109/CISIS.2011.13
[33] X. T. R. Kong, G. W. Chen, G. Q. Huang, and H. Luo, “Ubiquitous
auction learning system with TELD (Teaching by Examples and
Learning by Doing) approach: A quasi-experimental study,” Comput.
Educ., vol. 111, pp. 144–157, Aug. 2017, doi:
10.1016/j.compedu.2017.04.009.
[34] K. Y. Chin, K. F. Lee, and Y. L. Chen, “Impact on Student Motivation
by Using a QR-Based U-Learning Material Production System to
Create Authentic Learning Experiences,” IEEE Trans. Learn. Technol.,
vol. 8, no. 4, pp. 367–382, Oct. 2015, doi: 10.1109/TLT.2015.2416717.
[35] K.-Y. Chin and Y.-L. Chen, “A Mobile Learning Support System for
Ubiquitous Learning Environments,” Procedia - Soc. Behav. Sci., vol.
73, no. Supplement C, pp. 14–21, Feb. 2013, doi:
10.1016/j.sbspro.2013.02.013.
[36] T.-T. Wu and Y.-M. Huang, “A Mobile Game-based English
Vocabulary Practice System Based on Portfolio Analysis,” Educ.
Technol. Soc., vol. 20, pp. 265–277, 2017.
[37] K. Gunasekera, A. N. Borrero, F. Vasuian, and K. P. Bryceson,
“Experiences in building an IoT infrastructure for agriculture
education,” Procedia Comput. Sci., vol. 135, pp. 155–162, Jan. 2018,
doi: 10.1016/j.procs.2018.08.161.
[38] M. Ali et al., “IoTFLiP: IoT-based flipped learning platform for
medical education,” Digit. Commun. Netw., vol. 3, no. 3, pp. 188–194,
Aug. 2017, doi: 10.1016/j.dcan.2017.03.002.
[39] G. Mylonas, D. Amaxilatis, L. Pocero, I. Markelis, J. Hofstaetter, and
P. Koulouris, “An educational IoT lab kit and tools for energy
awareness in European schools,” Int. J. Child-Comput. Interact., vol.
20, pp. 43–53, Jun. 2019, doi: 10.1016/j.ijcci.2019.03.003.
[40] “Learning CatalyticsTM.” [Online]. Available:
https://www.pearsonhighered.com/products-and-services/course-
content-and-digital-resources/learning-applications/learning-
catalytics.html. [Accessed: 03-May-2017].
[41] M. A. Bedek, O. Firssova, E. P. Stefanova, F. Prinsen, and F. Chaimala,
“User-driven Development of an Inquiry-Based Learning Platform:
Qualitative Formative Evaluations in weSPOT,” Interact. Des. Archit.,
no. 23, pp. 122–139, 2014.
[42] A. Suarez, S. Ternier, M. Kalz, and M. Specht, “GPIM: Google
Glassware for Inquiry-Based Learning,” in Open Learning and
Teaching in Educational Communities, Springer, 2014, pp. 530–533,
doi: 10.1007/978-3-319-11200-8_58.
[43] C. Yao, “Constructing a User-Friendly and Smart Ubiquitous
Personalized Learning Environment by Using a Context-Aware
Mechanism,” IEEE Trans. Learn. Technol., vol. 10, no. 1, pp. 104–114,
Jan. 2017, doi: 10.1109/TLT.2015.2487977.
[44] B. de Sousa Monteiro, A. S. Gomes, and F. M. Mendes Neto, “Youubi:
Open software for ubiquitous learning,” Comput. Hum. Behav. vol. 55,
pt. B, pp. 1145-1164, Feb. 2016, doi: 10.1016/j.chb.2014.09.064.
[45] N. S. Chen, I. C. Hung, and C. W. Wei, “Developing Ubiquitous
Learning System with Robots for Children’s Learning,” in Proc. 3rd
IEEE Intl. Conf. Digital Game and Intelligent Toy Enhanced Learning,
Kaohsiung, Taiwan, Apr. 12-16, 2010, pp. 61–68, doi:
10.1109/DIGITEL.2010.17.
[46] D. Centea, M. Elbestawi, I. Singh, and T. Wanyama, “SEPT Learning
Factory Framework,” in Smart Industry & Smart Education, M. E. Auer
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TLT.2020.3007708, IEEE
Transactions on Learning Technologies
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1

and R. Langmann, Eds. Cham: Springer International Publishing, Jul. [Online]. Available: https://tools.ietf.org/html/rfc4158. [Accessed: 19-
2018, pp. 354–362, doi: 10.1007/978-3-319-95678-7_40. Apr-2017].
[47] O. Bohl, J. Scheuhase, R. Sengler, and U. Winand, “The sharable [70] N. Modadugu and E. Rescorla, “Datagram Transport Layer Security.”
content object reference model (SCORM)-a critical review,” in Proc. [Online]. Available: https://tools.ietf.org/html/rfc4347. [Accessed: 19-
Intl. Conf. Computers in Education, Auckland, New Zealand, Dec. 3-6, Apr-2017].
2002, pp. 950–951, doi: 10.1109/CIE.2002.1186122. [71] R. Atkinson and S. Kent, “IP Encapsulating Security Payload (ESP).”
[48] “IMS Global Learning Consortium.” [Online]. Available: [Online]. Available: https://tools.ietf.org/html/draft-ietf-ipsec-esp-v2-
/question/qtiv1p2/imsqti_litev1p2.html. [Accessed: 12-Apr-2017]. 05. [Accessed: 19-Apr-2017].
[49] C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, and B. Silverajan, [72] H. Tschofenig and P. Eronen, “Pre-Shared Key Ciphersuites for
“CoAP - Constrained Application Protocol,” [Online]. Available: Transport Layer Security (TLS).” [Online]. Available:
https://tools.ietf.org/html/rfc8323. [Accessed: 15-Jun-2018]. https://tools.ietf.org/html/rfc4279. [Accessed: 19-Apr-2017].
[50] “Advanced Message Queuing Protocol (AMQP) Protocol [73] Object Management Group (OMG), “Data Distribution Service (DDS)
Specifications (Version 0-10).” [Online]. Available: Version 1.4,”[Online]. Available:
http://www.amqp.org/specification/1.0/amqp-org-download. https://www.omg.org/spec/DDS/About-DDS/. [Accessed: 09-Feb-
[Accessed: 04-Dec-2016]. 2017].
[51] “Node.js.” [Online]. Available: https://nodejs.org/en/. [Accessed: 03- [74] “What is the LoRaWAN® Specification?,” LoRa Alliance. [Online].
Dec-2016]. Available: https://lora-alliance.org/about-lorawan.[Accessed: 23-Feb-
[52] “Apache CouchDB.” [Online]. Available: http://couchdb.apache.org/. 2019].
[Accessed: 03-Dec-2016]. [75] “Narrowband – Internet of Things (NB-IoT),” [Online]. Available:
[53] “Raspberry Pi 3 Model B,” Raspberry Pi. [Online]. Available: https://www.gsma.com/iot/narrow-band-internet-of-things-nb-iot/.
https://www.raspberrypi.org/products/raspberry-pi-3-model-b/. [Accessed: 26-Feb-2018]
[Accessed: 04-Dec-2016]. [76] J. He, J. Wei, K. Chen, Z. Tang, Y. Zhou, and Y. Zhang, “Multitier Fog
[54] “ESP32 Overview | Espressif Systems.” [Online]. Available: Computing With Large-Scale IoT Data Analytics for Smart Cities,”
https://www.espressif.com/en/products/hardware/esp32/overview. IEEE Internet Things J., vol. 5, no. 2, pp. 677–686, Apr. 2018, doi:
[Accessed: 20-Oct-2018]. 10.1109/JIOT.2017.2724845.
[55] “Particle.” [Online]. Available: https://www.particle.io/. [Accessed:
20-Oct-2018].
[56] N. Correia, D. Sacramento, and G. Schütz, “Dynamic Aggregation and
Scheduling in CoAP/Observe-Based Wireless Sensor Networks,” IEEE Salsabeel Shapsough received her
Internet Things J., vol. 3, no. 6, pp. 923–936, Dec. 2016, doi: BSc. (2014) in Computer Engineering
10.1109/JIOT.2016.2517120.
and her MSc. (2017) in Computer
[57] “JXcore,” GitHub. [Online]. Available: https://github.com/jxcore.
[Accessed: 28-Mar-2017]. Engineering from the American
[58] “Wireshark.” [Online]. Available: https://www.wireshark.org/. University of Sharjah, Sharjah, UAE. In
[Accessed: 01-Aug-2018]. 2017, she joined the American
[59] “nmon for Linux.” [Online]. Available: University of Sharjah as a Research
http://nmon.sourceforge.net/pmwiki.php. [Accessed: 28-Mar-2017].
[60] J. Ramirez and C. Pedraza, “Performance analysis of communication Associate in the field of Internet of
protocols for Internet of things platforms,” in Proc. IEEE Colombian Things and smart solar energy systems where she is responsible
Con. Communications and Computing (COLCOM), Cartagena, for the design and development of solar power monitoring
Colombia, Aug. 16-18, 2017, pp. 1–7, doi:
systems and technologies. Her research interests include
10.1109/ColComCon.2017.8088198.
[61] A. Talaminos-Barroso, M. A. Estudillo-Valderrama, L. M. Roa, J. Internet of Things, smart education technologies, and smart
Reina-Tosina, and F. Ortega-Ruiz, “A Machine-to-Machine protocol energy.
benchmark for eHealth applications – Use case: Respiratory
rehabilitation,” Comput. Methods Programs Biomed., vol. 129, pp. 1–
Imran A. Zualkernan (M’03) received
11, Jun. 2016, doi: 10.1016/j.cmpb.2016.03.004.
[62] N. S.- http://the1path.com, “Calculating Your Solar Power B.S. (high distinction) and Ph.D. degrees in
Requirements.” [Online]. Available: computer science from the University of
http://www.solartechnology.co.uk/support-centre/calculating-your- Minnesota, Minneapolis, in 1983 and 1991
solar-requirments. [Accessed: 02-Apr-2017]. respectively.
[63] C. (Defta) Costinela-Luminiţa and C. (Iacob) Nicoleta-Magdalena, “E-
learning Security Vulnerabilities,” Procedia - Soc. Behav. Sci., vol. 46, From 1984 to 1990, he was a Research
pp. 2297–2301, Jan. 2012, doi: 10.1016/j.sbspro.2012.05.474. Assistant with the Knowledge Systems
[64] S. Shapsough, F. Qatan, R. Aburukba, F. Aloul, and A. R. A. Ali, Laboratory at the University of Minnesota.
“Smart grid cyber security: Challenges and solutions,” in Proc. Intl. He was an Assistant Professor with the Computer and Electrical
Conf. Smart Grid and Clean Energy Technologies (ICSGCE),
Offenburg, Germany, Oct. 20-23, 2015, pp. 170–175, doi: Engineering Department, Pennsylvania State University,
10.1109/ICSGCE.2015.7454291 College Park from 1992 to 1995. He was a Principal Design
[65] F. D. S. Bahry, N. Anwar, N. Amran, and R. P. M. Rias, Engineer with AMCS Inc. in Chanhassen, Minnesota from
“Conceptualizing Security Measures on Mobile Learning for Malaysian
1995-1998. He was the Chief Executive Officer of Askari
Higher Education Institutions,” Procedia - Soc. Behav. Sci., vol. 176,
pp. 1083–1088, Feb. 2015, doi: 10.1016/j.sbspro.2015.01.582. Information Systems from 1998 to 2000, and the Chief
[66] S. E. Shapsough, F. Aloul, and I. Zualkernan, “Securing Low-Resource Technology Officer for Knowledge Platform, Inc., Singapore
Edge Devices for IoT Systems,” in Intl. Symp. in Sensing and from 2000 to 2003. In 2003 he joined the American University
Instrumentation in IoT Era (ISSI) Shanghai, China, Sep. 6-7, 2018, pp. of Sharjah in the UAE where he is currently a Professor of
1-4, doi: 10.1109/ISSI.2018.8538135.
[67] T. Dierks, “The Transport Layer Security (TLS) Protocol Version 1.2,” Computer Science and Engineering. He is the author of more
2008. [Online]. Available: https://tools.ietf.org/html/rfc5246. than 190 articles. His research interests include consumer
[Accessed: 19-Apr-2017]. systems, sensor-based Internet applications, Internet of Things
[68] K. D. Zeilenga and A. Melnikov, “Simple Authentication and Security (IoT) and application of big data to IoT.
Layer (SASL).” [Online]. Available: https://tools.ietf.org/html/rfc4422.
[Accessed: 19-Apr-2017].
[69] Y. Dzambasow, S. Joseph, R. Nicholas, P. Hesse, and M. Cooper,
“Internet X.509 Public Key Infrastructure: Certification Path Building.”

1939-1382 (c) 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
Authorized licensed use limited to: University of Exeter. Downloaded on July 15,2020 at 07:52:16 UTC from IEEE Xplore. Restrictions apply.