**4. Architecture**

This section describes our MEC/SDN-oriented architecture that satisfies the aforementioned requirements, and how it integrates different components to reconfigure and manage the learning applications running on top of classroom devices automatically, on-demand and in real-time. Figure 1 shows the levels, components and communications of the proposed architecture. The main elements, following a top-down approach, are the next ones:

**Figure 1.** Architecture oriented to the Mobile Edge Computing (MEC) paradigm.


In the following subsections, we explain in detail the components and main levels of our platform.

#### *4.1. Learning Analytics Platform*

The *Learning Analytics Platform* has the different modules and components that are necessary to implement learning analytics applications that have as a final objective to improve the learning experience and outcomes of students. With that goal in mind, the platform hosts different components able to acquire, process, analyze, recommend and visualize relevant data generated during the interaction of students with learning applications. Among the most relevant components, we highlight the *Learning Record Store (LRS)*, which acquires and stores students' interaction registers generated by learning applications. Those registers are sent to the *Analytics Engine* component to analyze them by using ML and statistical techniques. According to the registers, the outputs of the *Analytics Engine* and some trained models, the *Recommender* component provides students and instructors with suggestions to improve the learning experience. Finally, the *Visualizer* component exposes a graphical interface that allows students and instructors to interact with registers, data and outputs of the learning platform.

#### *4.2. MEC System Level Management*

The *MEC System Level Management* deals with the managemen<sup>t</sup> of the classroom devices and the behaviour of the learning applications running on top. In this context, the *Operation Support System* (OSS) is focused on the the logic of the architecture. This element provides instructors with an interface to define the rules that enable the reconfiguration of the learning applications and software running on top of the heterogeneous devices belonging to a classroom. These rules will be provided to the *Decision* component to identify particular actions to be taken. Once a decision is made, the *Orchestrator* receives the notification and interacts with the managers and controllers of the lower levels to configure the network, the classroom devices and their learning applications. Finally, the *Acquisition* component senses data generated by the classroom devices and their applications and services (not only learning applications) to detect misconfigurations or problems. When one problem is detected, the *Decision* and *Orchestrator* modules come into play to decide, schedule, and spread the required actions.

#### *4.3. MEC Host Level*

The *MEC Host Level* is composed of two planes, the control and data planes.

The control plane is called *MEC Host Level Management* and it is in charge of deploying, controlling and dismantling learning applications, instantiated as *MEC Apps* that run on top of heterogeneous classroom devices (*MEC Hosts*). The MEC Host level managemen<sup>t</sup> contains two managers: the *MEC Platform Manager* and the *Virtualization Infrastructure manager* (VIM). The MEC Platform Manager controls the whole life-cycle of MEC Apps, and the VIM manages the computation, storage and networking virtual and physical resources of the Virtualization Infrastructure.

In the data plane, we find the MEC Hosts, which are classroom devices providing computational, storage, and networking resources to execute learning applications. Each MEC Host contains a *Virtualization Infrastructure*, a *MEC Platform* and one or more *MEC Apps*. MEC Apps can be deployed as learning applications, components of the Learning Analytics Platform (commented on in Section 4.1) and other applications like, for example, those oriented to improve the learning courses security and privacy). MEC Apps can be instantiated in Virtual Machines (VM) or containers running on top of the virtual infrastructure. The virtualization infrastructure consumes the hardware of heterogeneous learning devices such as computers, digital blackboards, or cameras and provides computational, storage and networking virtual resources. Finally, the MEC platform provides essential and generic MEC Services needed to run MEC Apps. These services can be specific for particular applications or generic enough to be shared among several MEC Apss. Examples of MEC Services can range from communication protocols to access control mechanisms or cryptographic material.

#### *4.4. Network Level*

The *Network Level* contains two types of elements: heterogeneous *Networks* and the *Network manager*. The networks represent the hardware and software networking resources needed to connect MEC Hosts and their MEC Apps. The Network Manager allocates the SDN Controller, which has the global view of the network status as well as the logic of the network to control the data plane where heterogeneous networks are located.

#### *4.5. Solutions Provided by our Architecture to the Previous Requirements*

**Solution to Requirement 1—Within-scenario flexibility for instructor-configured data collection, analytics, visualizations and recommendations**: Easy and flexible reconfigurations of the instructors' and learners' applications, such as the one needed in the first scenario, are enabled by our solution. Figure 2 shows the interaction between the components of our architecture to reconfigure the storage and processing capabilities of the instructor host. For clarity's sake, we show how the architecture reconfigures two MEC Apps running on top of an MEC Host. However, this functionality could be extended to several MEC Hosts and applications. The 1st step of Figure 2 shows when the decision of reconfiguring the instructor host is made by the Decision component. After that, the Orchestrator provides the MEC Platform Manager with the MEC Host and the reconfiguration details of the new storage and processing capabilities. Once received, the MEC Platform Manager interacts with the instructor host to access the storage and processing MEC Apps and reconfigure them (steps from 3 to 6). When the reconfigurations have finished, the action is confirmed to the Orchestrator (step 7).

**Figure 2.** Architecture reconfiguring two MEC Apps running on top of an MEC Host.

**Solution to Requirement 2—Between-scenario flexibility for automatic deployment of the MMLA solutions**: Aligned with the capabilities shown in the previous issue and focused on addressing this one, the proposed architecture deploys, configures and dismantles MEC Hosts and their applications in real-time and on-demand. Following the previous example, Figure 3 shows how the components of our architecture dismantle the instructor host when a given application is finished, and deploy new ones with different capabilities for the next class. In the 1st step of Figure 3, the Decision component interacts with the Orchestrator to notify the necessity of changing the instructor host. After that, the Orchestrator provides the VI Manager with the required info to dismantle the MEC Host (step 2). Once the notification is received, the VI Manager dismantles the host and confirms the Orchestrator the action (steps 3–5). When the old instructor host has been dismantled, the next step is to deploy a new MEC instructor host with more hardware resources (processor and graphics). This process is shown from 6 to 9 in Figure 3. At this stage, our architecture has already deployed a new MEC instructor host with enough hardware resources to meet the requirements of the next learning analytics application and the next step is to deploy a new MEC App with visualization tools and capabilities. For that, the MEC Platform Manager is the component in charge of deploying, configuring and confirming the new MEC App (steps from 10 to 13). Finally, the Orchestrator communicates with the SDN Controller to include a new rule in the switch flow table, and route the network packets sent and received by the new instructor host and its applications (step 14).

**Figure 3.** Architecture dismantling an old MEC Host, and deploying a new MEC Host and MEC App.

**Solution to Requirement 3—Seamless privacy and authentication configurations**: Our architecture is able to deploy MEC Apps, providing students with authentication and authorization capabilities, in real-time and on-demand. On the one hand, depending on the learning course security requirements, the architecture will deploy and configure an MEC App providing several authentication mechanisms with different levels of security. On the other hand, the architecture will deploy another MEC App allowing students to define their privacy preferences by defining user-friendly policies. In this context, students will determine what pieces of sensitive data can be shared, who or what learning tools can process the sensitive data, how long data can be processed or stored, or what can be done with the data, among others. Once defined the policies, they will be sent to the components of the Learning Analytics Platform to ensure that they are considered during the data managemen<sup>t</sup> and storage processes.

**Solution to Requirement 4—Easy communication with external data sources**: As can be seen on top of Figure 1, the design of our architecture considers external data sources such as MOOC, LMS, or academic datasets feeding the Learning Analytics Platform with additional data that will be critical for the data analysis processes performed by its components.

## **5. Experimentation Results**

A key aspect of our proposal is how the architecture deploys and configures the learning ecosystem automatically for each scenario, which addresses the aforementioned Requirements 1 and 2. We consider these two requirements as the key ones that are necessary to bring scalability and interoperability to smart classrooms and MMLA applications, and thus we focus our experimentation in this section on those two aspects. The deployment process is dealt by the Orchestrator that must consider the features of each classroom device and its performance with different MEC Apps. In this

section, we show experimental results regarding computational performance and efficiency of typical classroom devices with practical learning tools.

With a model of deploying MEC Apps based on containers, we investigate experiments about three types of learning tools: high-intensive computing, medium-intensive computing and high-intensive data consuming. The high-intensive computing MEC App is a face-recognition that detects all the faces and face encoding in each frame of a video source. This application is a Python program based on *dlib* library using a Histogram of Oriented Gradients (HOG) face detector. The medium-intensive computing MEC App is a feature extractor for Automatic Speaker Recognition (ASR). This application is also a Python program based on the Mel-Frequency Cepstral Coefficients (MFCC) that analyzes an audio source periodically each second. In addition, the high-intensive data consuming MEC App is a computational physics simulation that plots a 3D surface. This application is a Python program based on Matplotlib library for creating animated visualizations.
