Web Services for Collaboration Analysis With IoT Badges

Collaborative learning is an educational approach to teaching and learning that involves groups of learners collaborating to solve a problem, complete a task, or create a product. To enhance the performance of collaborative learning, the studies in Yamaguchi et al. (2021, 2021, 2021, and 2022) develop an IoT system and quantitatively extract collaboration between learners. The studies acquire sensor data from IoT badges on learners and analyze learning activities with the acquired sensor data on a computer. However, existing studies are not user-friendly for learning analysts who are unfamiliar with information technology owing to complex software installation and command line interface (CLI) operation. Such drawbacks hinder the wide expansion of technology and the exploration of new learning patterns in learning science. Considering high usability for analysts, this paper proposes novel web services named Sensor-based Regulation Profiler Web Services (SRP Web Services) for collaboration analysis with IoT badges. The proposed web application consists of front-end on Next.js and back-end on FastAPI, SQLite, and Python and extracts key points in learning activities for the analysts from the acquired sensor data on a web browser. Experimental evaluations showed that the proposed web services support learning analysts in quantitative analysis of learning activities with high usability. In addition, SRP Web Services are scalable with hundreds of users.


I. INTRODUCTION
Collaborative learning, which involves collaborating to creatively solve a problem, is an educational approach to teaching and learning in learning science. Learners integrate new ideas from other learners and enhance their social abilities through collaboration with other learners. Researchers have qualitatively analyzed collaborative learning and revealed various patterns to improve learning performance in learning science [5], [6], [7], [8], [9]. However, existing studies require much time since the researchers were forced to repeatedly observe recorded video of collaborative learning. Such The associate editor coordinating the review of this manuscript and approving it for publication was Jose Saldana . qualitative analysis is inapplicable for actual learning environments, such as a class composed of several groups.
The studies in [1], [2], [3], and [4] support existing qualitative analysis by learning analysts with a novel IoT system named the Sensor-based Regulation Profiler (SRP). The studies consist of IoT badges named SRP Badges to acquire sensor data from learners and learning analysis algorithms named SRP Analysis for the acquired sensor data. SRP Badges accurately acquire sound pressure, acceleration, and infrared from learners and the learning environment while synchronizing across the SRP Badges. SRP Analysis automatically extracts key points for qualitative learning analysis, such as face-to-face interaction, learning phases, speakers, and activity with the acquired sensor data. Owing to While the above studies support qualitative analysis of collaborative learning, they have drawbacks in usability for learning analysts who are unfamiliar with information technology. First, the studies force the users to understand software attribution. The studies involve the use of Python and C-based AutoPlait [10]. The users must install Python considering the versions, packages, and operating system (OS) of the installation destination. In addition, the users must place AutoPlait on an appointed directory to activate the analysis algorithms. Such a process hinders users who are unfamiliar with the software from utilizing the algorithms. Second, the studies force the users to operate on an unfamiliar interface. The studies assume CLI operation on UNIX to build binaries in AutoPlait and to execute the algorithms in Python. The users are obliged to construct a UNIX environment on each computer and to operate CLI to analyze learning activities with the algorithms. Such a technical assumption limits learning analysts who are unfamiliar with information technology to start learning analysis with the algorithms.
To overcome the above problems, an earlier and briefer version of this article was presented in the study of [11]. The study in [11] proposed a web application with IoT badges [2] named the Sensor-based Regulation Profiler Web (SRP Web) to support qualitative analysis for collaborative learning. The proposed scheme consists of an SRP Badge and a web application for learning analysis that extracts and visualizes collaborative learning activity from the acquired sensor data. The SRP Web was developed in Django, a web application framework that is based on Python. Any users can access and utilize the application on a web browser. Fundamental evaluations qualitatively show that the SRP Web reduces the analysis cost of learning activities by extracting and visualizing collaboration, such as face-to-face interaction across learners, learning phases, learners speech, and learners activity from sensor data. This paper proposes an extended version of the SRP Web named SRP Web Services to easily extract and visualize sensor data acquired from SRP Badges for high usability in collaborative learning analysis (Fig. 1). The proposed web application consists of front-end on Next.js and back-end on FastAPI, SQLite, and Python and extracts key points in learning activities for learning analysts from the acquired sensor data on a web browser. While the existing studies force the users to construct specific and complex environments on their computers, constructing such an environment is not necessary to use SRP Web Services. The users just access the webpage provided by the server preparing the above environment. Compared with the CLI operation in the existing studies, SRP Web Services are user-friendly for learning analysts owing to the graphical user interface (GUI) operation. Experimental evaluations showed that the proposed web services support learning analysts in quantitative analysis of learning activities with high usability. In addition, our SRP Web Services improve the scalability of the SRP Web and promote an IoT system to support collaborative learning analysis for learning analysts who are unfamiliar with information technology.
The remainder of this paper is organized as follows: Section II describes related studies. Section III presents the proposed web services for collaboration analysis with SRP Badges. Section IV conducts a qualitative evaluation of the proposed web services in terms of user experience. Section V conducts a quantitative evaluation of the proposed web application in terms of load testing. Section VI concludes our paper.

II. RELATED WORKS
This study is related to studies on collaboration analysis with IoT badges, web services for sensor data analysis, and sensor-based activity recognition.

A. COLLABORATION ANALYSIS WITH IoT BADGES
Some studies have extracted human collaboration with IoT badges on users [1], [2], [3], [4], [12], [13], [14], [15], [16], [17]. Table 1 shows the taxonomy of the earlier studies. Hitachi proposed an IoT badge named Business Microscope equipped with an accelerometer and infrared sensor [12]. Business Microscope revealed that an appropriate frequency of meetings had an impact on work efficiency in organization management with face-to-face interaction from its infrared sensors. While there is no need for any users to install software and operate on unfamiliar interfaces, such as CLI, Business Microscope has a drawback in usability for learning analysts owing to outsourcing collaboration analysis. Outsourcing hinders the immediate feedback of learning analysis to the learning environment.
MIT Media Lab. developed IoT badges and algorithms named Sociometric Badge [13], [14], [15], Open Badges [16], and Rhythm [17] for human collaboration analysis in 2008, 2016, and 2018, respectively. Sociometric Badge mounted an accelerometer, Bluetooth, an infrared sensor, and a sound pressure sensor and was applied to various domains such as organization management [13], health care [14], and organization engineering [15]. For example, the study in [13]  demonstrated the importance of face-to-face social networks in predicting worker productivity with Sociometric Badge in organization management. Open Badges downsized Sociometric Badge for low power consumption and preliminarily visualized face-to-face interactions between users with sound pressure and the Bluetooth Received Signal Strength Indicator (RSSI). Rhythm realized a unified measurement platform with Open Badges for organization management and measured interaction across users in colocated and distributed contexts with online applications. However, the studies have drawbacks in usability for learning analysts who are unfamiliar with information technology. Rhythm, even the pioneer study of the MIT Media Lab., requires analysts to install software and operate on a CLI to start collaboration analysis on the GUI application. Concretely, Rhythm requires Python for collecting and preprocessing sensor data and constructing a back-end server to start collaboration analysis on the GUI. Such a technical assumption limits analysts' ability to start learning analysis with the developed systems.
The studies in [1], [2], [3], and [4] proposed an IoT system with wearable badges for collaborative learning analysis named the Sensor-based Regulation Profiler (SRP). Owing to precise synchronization across the proposed IoT badges, named SRP Badges within an error of ±30 µs, the system accurately extracted key points with learning analysis algorithms named SRP Analysis in learning activities even on a short time scale. However, the studies also have drawbacks in usability for learning analysts who are unfamiliar with information technology. The studies require analysts to install software such as Python and C-based AutoPlait [10] and operate on a CLI to start collaboration analysis on a GUI. Such a technical assumption limits the analysts to start learning analysis with the developed systems.
To solve these drawbacks, an earlier and briefer version of this article was presented in the study of [11]. The study in [11] proposed a Django-based web application with SRP Badges, named the Sensor-based Regulation Profiler Web (SRP Web), to support collaborative learning analysis. This paper proposes an extended version of the SRP Web, named SRP Web Services, as user-friendly web services for qualitative analysis of collaborative learning. The proposed web services do not require the installation of complex software and the operation of the developed systems on CLI. Any users just access the webpage and immediately analyze learning activities on a web browser. Our SRP Web Services improve the scalability of the SRP Web and promote an IoT system to support collaborative learning analysis for learning analysts who are unfamiliar with information technology.

B. WEB SERVICES FOR SENSOR DATA ANALYSIS
Some studies have developed user-friendly web services for sensor data analysis [11], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28], [29]. For example, the study in [23] presented a model for smart agriculture to monitor real-time soil properties and to remotely control various operations of the field anytime by mobile and web application. The proposed structure provided an environment in which users could easily monitor data processed by the components through a web browser anywhere and anytime. The study in [29] proposed a novel SaaS platform named motch to easily operate IoT systems for end users with a web front end. The proposed web front end enabled the users to easily check the availability of each IoT device on a web browser.
An earlier and briefer version of this article was presented in the study of [11]. The study in [11] proposed a Django-based web application with SRP Badges named the SRP Web to support collaborative learning analysis. Fundamental evaluations showed that the SRP Web reduced the analysis costs of learning activities by extracting and visualizing collaboration, such as face-to-face interactions across learners, learning phases, learners speech, and learners activity from sensor data. This study proposes an extended version of the SRP Web, named SRP Web Services, to easily extract and visualize sensor data acquired from SRP Badges for high usability in collaborative learning analysis. Our SRP Web Services expand the possibility that analysts who are unfamiliar with information technology start learning analysis with learning analysis algorithms owing to the improvement of scalability in the SRP Web.

C. SENSOR-BASED ACTIVITY RECOGNITION
Some studies have recognized human activity with sensors [30], [31], [32], [33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44]. For example, the study in [32] proposed an action tutor system that achieved high-level evaluation of human action movements with the aid of Kinect. Experimental results showed that the proposed human action descriptor was representative for action video retrieval and that the tutor system could effectively help the user while learning action movements. The study in [34] proposed a feature extraction algorithm to recognize hand gestures with a sliding window and a graph-based approach to identify the relations between signals sensed by an array of force sensor resistors. Experimental evaluations showed that the proposed method achieved acceptable results by providing good features, which helped obtain a more accurate classification. The study in [41] proposed a novel, multistage training methodology from multimodal wearable sensor data to increase the diversity in the feature extraction process by efficiently employing a multitude of time-series transformations that facilitated the exploration of diversified feature spaces. Extensive experiments showed that the proposed scheme consistently provided outstanding performance with average fivefold cross-validation accuracies of 99.29 %, 99.02 %, and 97.21 % in three publicly available datasets with some activities.
This paper acquires sound pressure, acceleration, and infrared acquired from IoT badges and extracts learning activity for learning analysis, such as face-to-face interaction, learning phases, speakers, and activity with the acquired sensor data on a web browser. Our proposed scheme supports qualitative analysis of collaborative learning through the visualization of key points in the learning activity. Figures 1 and 2 show an overview of the proposed web services named Sensor-based Regulation Profiler Web Services (SRP Web Services) and the interface of the proposed web application for collaboration analysis with SRP Badges [2]. SRP Badge is an IoT badge to be worn on the chest of each learner. SRP Badge mounts an accelerometer, an infrared sensor, and a sound pressure sensor. The accelerometer and the sound pressure sensor sample 12 bits at 100 Hz. The infrared sensor detects infrared radiation at 34 Hz at most. In addition, SRP Badge precisely synchronizes with other SRP Badges owing to a wireless synchronization module. SRP Web Services import sensor data acquired from SRP Badges, manage the sensor data in each session, and extract and visualize key points for qualitative analysis of collaborative learning, such as face-to-face interaction, learning phases, speakers, and activity with the sensor data on a web browser. SRP Web Services support learning analysts in qualitative analysis of collaborative learning with the following steps:

III. PROPOSED SYSTEM: WEB SERVICES FOR COLLABORATION ANALYSIS
1) Distribute SRP Badges to learners and learning environments prior to collaborative learning activity. 2) Acquire sensor data with the SRP Badges during the learning activity. 3) Collect the SRP Badges from the learners and learning environments. 4) Import sensor data from the SRP Badges to each session on the proposed web application. 5) Extract and visualize key points for learning analysis in each session on the web application. 6) Qualitatively analyze the learning activity with the acquired results.
A. ARCHITECTURE Figure 3 shows the architecture of the web application. The web application consists of the front end on Next.js ver. 12 and back end on FastAPI ver. 0.72.0, SQLite, and Python 3.6. The users' requests are sent from the front end to FastAPI in the back end. FastAPI receives the requests and communicates with the database or each learning analysis algorithm. FastAPI creates, reads, updates, and deletes (CRUD) the users' accounts, projects for each analysis of learning activities, and sensor data acquired from SRP Badges among the databases on SQLite. FastAPI sends the acquired sensor data and parameters, such as the start and end times of analysis, to each learning analysis algorithm on Python 3.6. FastAPI receives analysis results from each algorithm and returns the response to the front end.

Figures 4 (a) through (d)
show a snapshot of each learning analysis algorithm [4] in Fig. 3. The algorithms extract key points for collaborative learning analysis with social graph extraction, learning phase extraction, speaker identification, and activity estimation.  Social graph extraction represents face-to-face interaction across learners and learning environments with SRP Badges in collaborative learning. The algorithm measures face-toface interaction with infrared sensors in the SRP Badge. The infrared sensor detects other infrared sensors directed at itself and records the IDs of the detected sensors every second. The algorithm forms square matrices with a dimension of the number of sensors representing face-to-face interactions across the sensors every second. The algorithm then sums each element of the matrices for optional time and additionally forms square matrices representing the frequency of face-to-face interactions across the sensors for the optional time. The algorithm finally visualizes face-to-face interactions across the sensors as a directed graph with the square matrices in Fig. 4 (a). We note that bolder arrows show more frequent face-to-face interactions between sensors.
The learning phase extraction divides a collaborative learning activity into several different patterns based on face-toface interaction frequency across learners with SRP Badges. The algorithm supposes collaborative learning composed of three phases: video viewing to collect information about the problem, discussion to suggest possible solutions for the problem, and conclusion to choose the best solution based on the study [45] with an educational material called the Adventures of Jasper Woodbury [46]. The algorithm forms a scholar matrix named network difference with the matrices representing the frequency of face-to-face interactions across the sensors for the optional time in the social graph extraction. The algorithm then inputs the scholar matrix to AutoPlait [10] to classify time-series data into similar patterns with hidden Markov models. The algorithm finally visualizes the result acquired from AutoPlait as learning phases in Fig. 4 (b).
The speaker identification represents the speech of each learner with SRP Badges in collaborative learning. The algorithm identifies speakers with sound pressure sensors in the SRP Badge. There are three steps for speaker identification: 1) preprocessing, 2) speech section estimation, and 3) speaker identification. The first step detects sound pressure in each learner. The algorithm makes a zero-point correction of sound pressure by subtracting the minimum value from all the sound pressures in each user. The algorithm labels speech or nonspeech in each user with the zero-adjusted sound pressure and sliding windows. If the maximum sound pressure in the window exceeds the threshold, the algorithm regards the window as a speech section. The algorithm acquires speech labels for all users named ''the 1-0 data for each user.'' The second step estimates the speech or nonspeech section from the 1-0 data for each user. The algorithm complements labels 1 in a section with consecutive labels 0 within 90 ms between labels 1 to account for midspeech pauses in the 1-0 data for each user. The algorithm replaces a short interval with continuous labels 1 within 150 ms with labels 0 to correct for the section falsely detected by ambient noise. The algorithm takes the logical summation of the 1-0 data for each user as a speech section named ''the speech section data.'' The third step determines who speaks in each speech section with the 1-0 data for each user and the speech section data. The algorithm focuses on each section where a user is supposed to speak based on the speech section data. The algorithm extracts a user with the most labels 1 in each speech section and regards the user as a speaker in the speech section based on the 1-0 data for each user. The algorithm finally visualizes the 1-0 data for each user as shown in Fig. 4 (c).
The activity estimation represents the motion of each learner with SRP Badges in collaborative learning. The algorithm estimates activity of each learner with the ADXL362 three-axis accelerometer in the SRP Badge. ADXL362 quantizes and records acceleration within twice the gravitational acceleration. The algorithm calculates the L2-norm across the acquired acceleration of every sample in each SRP Badge. The algorithm subtracts the offset from all accelerations as a zero-point correction with reference to the data sheet of ADXL362. The algorithm finally converts quantized acceleration to relative values from 0 to 1 and visualizes the values as learners' activity in Fig. 4 (d).

C. FUNCTIONS
There are five beneficial functions on the web application.

1) HIGH ACCESSIBILITY
Learning analysts who are unfamiliar with information technology can access the services on a web browser without installation of complex software and CLI operation to activate the application. For example, analysts do not necessarily install Python considering the versions, packages, and OS of the installation destination. Such users benefit from web services that require only a web browser and internet connection to run.

2) LOW PERFORMANCE DEPENDENCE ON END DEVICES
Web applications minimally depend on the performance of users' computers. Since the application runs on a web server, the users' device does not require high performance to run the application for learning analysis. Low performance dependence supplies the users with equal environments to analyze learning activities.

3) PHYSICAL SEPARATION FOR EASY MAINTENANCE
The web application consists of front-end and back-end structures for easy maintenance. The physical separation enables developers of the application to separately maintain the front-end and back-end functions in the services. The structure enables developers to quickly correspond to users' feedback and update services.

4) ACCOUNT MANAGEMENT FOR MULTIPLE USERS' ACCESS
Each user can simultaneously and separately utilize the services on a web browser with each account. The services require any users to register an account and log in with the account before using the services. Multiple users can simultaneously and separately analyze learning activity with each account.

5) SESSION MANAGEMENT FOR MULTIPROCESSING OF LEARNING ANALYSIS
Each user can manage and analyze multiple cases of learning activities with each session. The web services prepare a session to save sensor data corresponding to each case of learning activities. The user can simultaneously analyze multiple cases of learning activities with each session in parallel.

D. USAGE
Each user can utilize the web application on a web browser with three steps for learning analysis: 1) sign up and log in, 2) create a session, and 3) import and analyze sensor data acquired by SRP Badges.
The first step enables multiple users to simultaneously utilize web services. Figure 5 shows a snapshot of account management in the proposed web services. Each user can create an account with an email address, login ID, and password on the screen of Fig. 5. Once the user registers the account, the user can log into the web services with the login ID and password.
The second step enables the user to manage and analyze multiple learning activities. Figure 6 shows a snapshot of session management in the proposed web services. The user can create a new session to import sensor data acquired by SRP Badges on the screen of Fig. 6. The web services keep the created session until the user deletes the session even after the user exits the webpage.
The third step enables the user to automatically extract and visualize key points for learning analysis, such as faceto-face interaction, learning phases, speakers, and activity in each session as shown in Fig. 4. The user imports sensor data as a .DAT file extension acquired by the SRP Badges. The user selects each learning analysis algorithm and executes the algorithm with some parameters, such as the start and end times of learning analysis. The algorithm plays face-to-face animation as face-to-face interaction across the learners. The user can select the parameters of the start and end times (s) for the animation, playback speed (s) for the animation, and display duration (s) for the afterimage of the face-to-face data. The algorithm classifies learning activities into several phases with AutoPlait [10] and visualizes the learning phases. The user can select the parameters of window size and slide width (s) for sliding windows in the algorithm of learning phase extraction. Subsequently, the user can analyze the results of the appropriate classification. Speaker identification extracts a speaker from all the learners. The user can select the parameters of start and end times (s) for analysis duration, window size and slide width (s) for sliding windows in the algorithm of speaker identification, and speech threshold (dB) for the algorithm. The study in [3] showed that the algorithm accurately identifies a speaker with window size and slide width of 2 s and 1 s, respectively. The appropriate speech threshold depends on the learning environment. The study in [3] reported that the appropriate thresholds are 75 dB and 85 dB under a no-noise environment and office environment, respectively, similar to the learning environment. Activity estimation visualizes each learner's movement as an L2-norm across three-axis acceleration. The user can select the parameters of the start and end times (s) for the analysis duration.

IV. QUALITATIVE EVALUATION: USER EXPERIENCE ON THE PROPOSED WEB SERVICES
We evaluated user experience for the proposed web services on a web server. We selected the dataset of collaborative learning activity with SRP Badges [2]. The study in [2] acquired sensor data with the SRP Badges for an hour from a group with three learners and learning environments. The synchronizer for the SRP Badges was set at the center of the learners' desk. Each learner mounted an SRP Badge on the chest during the activity. A whiteboard was set up to assist the learners in discussion. Two SRP Badges were placed on both edges of the whiteboard. In addition, an iPad was placed on the desk to present learning tasks to the learners. An SRP Badge was attached to the top of the iPad. A researcher in learning science analyzes the learning activity with the proposed web services on a web browser.

A. SIMPLE ENVIRONMENTAL CONSTRUCTION
We evaluated the process of environmental construction with the proposed web services compared with the existing algorithms [4] for learning analysis. Existing studies required the installation of Python, considering the versions, packages, and OS of the installation destination. Existing studies also required placing AutoPlait on an appointed directory to activate the analysis algorithms. The above process was difficult for learning analysts who are unfamiliar with information technology and impaired the usability of the learning algorithms. On the other hand, environmental construction was not needed for the analysts to use the proposed web services. The web server has constructed the environments, including Next.js, FastAPI, and Python, required for the proposed web services. The analysts just had to access a webpage and receive a response from the web server. The proposed web services showed the improvement in usability for learning analysts who are unfamiliar with information technology related to environmental construction.

B. SIMPLE OPERATION WITHOUT CLI
We also evaluated the process of operation with the proposed web services compared with existing algorithms [4] for learning analysis. Existing studies have forced learning analysts who are unfamiliar with information technology to construct a UNIX environment on each computer and to operate CLI to analyze learning activities. Concretely, the studies assume CLI operation to build binaries in AutoPlait and to execute algorithms in Python for learning analysis.
Such operation was not user-friendly for the analysts and impaired the usability of the learning algorithms. Compared with existing algorithms, the proposed web services were user-friendly for analysts owing to the GUI operation. The web services provided GUI operation on a web browser so that the analysts could analyze the learning activities without operation on an unfamiliar interface. The proposed web services showed usability for learning analysts who are unfamiliar with information technology related to CLI operation.

V. QUANTITATIVE EVALUATION: LOAD TESTING FOR THE WEB SERVICES
We quantitatively evaluated load testing for the web services: processing time in each function, scalability, and running cost of the proposed web services. We deployed the web services on three EC2 instances provided by Amazon Web Service (AWS) for different expected users: t3.large, m6i.large, and m6i.2xlarge.

A. PROCESSING TIME IN EACH FUNCTION
We evaluated the processing time for each function of the proposed web services deployed on the EC2 instances. We selected the dataset of collaborative learning activity with SRP Badges [2], as shown in Sec. IV. This paper extracted different lengths of sensor data: 15 min, 30 min, 45 min, and 60 min acquired from three users' chests in the learning activity for an hour. We recorded each processing time in three functions without the sensor data-sign up, log in, and create a session-and five functions with the sensor data-import a sensor datum, extract face-to-face interaction, extract learning phases, identify speakers, and estimate activity. We calculated each processing time by averaging ten processing times. Tables 2 and 3 show the results of the processing time for each function without sensor data and with sensor data, respectively. Table 2 shows the processing time to sign up, log in, and create a session on t3.large, m6i.large, and m6i.2xlarge, respectively. Table 3 shows processing time to import a sensor datum, extract face-to-face interaction, extract learning phases, identify speakers, and estimate activity with sensor data for 15 min, 30 min, 45 min, and 60 min on t3.large, m6i.large, and m6i.2xlarge, respectively. We found three characteristics in the results of processing time in Tables 2 and 3. • Each function was processed by m6i.large and m6i.2xlarge faster than t3.large.
• There seemed to be few gaps in processing time between m6i.large and m6i.2xlarge.
• Speaker identification was the heaviest process in the functions.
The first point showed that t3.large could hinder learning analysts from quickly analyzing collaborative learning with the proposed web services. Each instance differed in network bandwidth; t3.large allowed 5 Gbps at most and m6i.large and m6i.2xlarge allowed 12.5 Gbps at most. To accelerate each function, m6i.large or m6i.2xlarge were recommended. The second point showed that m6i.large has sufficient CPU performance and memory for processing each function on the web services. Each instance differed in the performance of CPU and memory; m6i.large mounted four CPUs and 16 GiB of memory and m6i.2xlarge mounted eight CPUs and 32 GiB of memory. To accelerate each function, the performance of m6i.large was sufficient. The third point showed that there was room to improve the architecture of speaker identification. For example, the web services provided speaker information from sensor data for 60 min on m6i.large in 61.8 s in Tab. 3 (b). While the web services provided speaker information to learning analysts, the function required more than 1 min to show the results of speaker identification. We leave how to accelerate speaker identification in web services as a future work.

B. SCALABILITY
We evaluated the scalability of the proposed web services deployed on the EC2 instances. We compared the scalability of the proposed web services with that of the earlier web application of the proposed services [11]. We requested multiple access from one server to another server, which deployed each scheme with Apache's JMeter [47]. We requested speaker identification with 1 min sensor data acquired from three users' chests with SRP Badges during collaborative learning activity . 1 The number of accesses varied from 0 to 300 in increments of 50 on the proposed web services and from 0 to 60 in increments of 5 on the earlier web application. In addition, we evaluated the scalability of the proposed web services with 60 min sensor data. We deployed the proposed web services on the EC2 instances and requested multiple access to the instances as in the above settings. We requested speaker identification with 60 min sensor data acquired in the above learning environment. The number of accesses varied from 0 to 1200 in increments of 100. Figure 7 shows the scalability for multiple requests with 1 min sensor data on the earlier web application labeled SRP Web and the proposed web services labeled SRP Web Services. The horizontal axis shows the number of simultaneous requests to each scheme, and the vertical axis indicates the success rate of the response to requests. The legend shows the combination of each scheme and instance type: the earlier web application on t3.large (SRP Web on t3.l), the earlier web application on m6i.large (SRP Web on m6i.l), the earlier web application on m6i.2xlarge (SRP Web on m6i.2xl), and SRP Web Services on any instance (SRP Web Services). 1 Speaker identification was the heaviest function in the proposed web services. The earlier web application indicated that the success rate on t3.large was 1.0 for the number of requests from 0 to 20 in increments of 5 and 0.960, 0.767, 0.029, 0.025, 0.000, 0.000, 0.000, and 0.033 for 25,30,35,40,45,50,55, and 60 accesses, respectively. The success rate on m6i.large was 1.0 for the number of accesses from 0 to 30 in increments of 5 and 0.000 for the number of accesses from 35 to 60 in increments of 5, respectively. The success rate on m6i.2xlarge was 1.0 for the number of accesses from 0 to 35 in increments of 5 and 0.925, 0.844, 0.640, 0.036, and 0.017 for 40, 45, 50, 55, and 60 requests, respectively. The proposed web services indicated that the success rate on any instance was 1.0 for the numbers of requests between 0 and 300 in increments of 50. The figure shows that the proposed web services improved the scalability of the earlier web application. Figure 8 shows the scalability for multiple requests on the proposed web services. The horizontal axis shows the number of simultaneous requests to the proposed web services, and the vertical axis indicates the success rate of the response to requests. The success rate on t3.large was 1.0 for the number of accesses from 0 to 400 in increments of 100 and 0.964, 0.802, 0.683, 0.599, 0.536, 0.481, 0.439, and 0.337 for 500, 600, 700, 800, 900, 1000, 1100, and 1200 accesses, respectively. The success rate on m6i.large was 1.0 for the number of accesses from 0 to 400 in increments of 100 and 0.996, 0.797, 0.681, 0.599, 0.527, 0.477, 0.435, and 0.397 for 500, 600, 700, 800, 900, 1000, 1100, and 1200 accesses, respectively. The success rate on m6i.2xlarge was 1.0 for the number of accesses from 0 to 900 in increments of 100 and 0.952, 0.853, and 0.821 for 1000, 1100, and 1200 accesses, respectively. The figure shows that the proposed web services completely allow simultaneous requests of speaker identification, the heaviest function in the proposed web services, for 400 accesses on t3.large and m6i.large and for 900 accesses on m6i.2xlarge.

C. RUNNING COST
We estimated the cost of running the proposed web services based on the service fee on AWS [48]. We assumed that the web services were deployed on the EC2 instances in the region of Ohio, USA, spending 0.0832 USD per hour on t3.large, 0.096 USD per hour on m6i.large, and 0.384 USD per hour on m6i.2xlarge. We estimated running costs as running time multiplied by the hourly unit price. We assumed the number of users to be 400, 400, and 900 on t3.large, m6i.large, and m6i.2xlarge, respectively, which the proposed web services simultaneously process without rejecting requests in Sec. V-B. We also assumed that each user analyzes five sessions of collaborative learning activity for one month. We set the number of learners to three and set the learning duration to 60 min in each session. We summed the running time, including the time to sign up, log in, create sessions, import sensor data, extract face-toface interaction, extract learning phases, identify speakers, and estimate activity, for each user based on each average processing time in Sec. V-A. According to the above discussion, the total running cost is approximately 5.658 USD on t3.large for 400 users, 4.320 USD on m6i.large for 400 users, and 18.816 USD on m6i.2xlarge for 900 users for one month.

VI. CONCLUSION
This paper proposed novel web services named SRP Web Services for collaboration analysis with IoT badges named SRP Badges. SRP Web Services improved usability for users who are unfamiliar with information technology in collaborative learning analysis with SRP Badges in existing studies [1], [2], [3], [4]. The studies forced the users to install complex software and to operate the developed systems on an unfamiliar interface. For example, the studies required Python installation considering the versions, packages, and OS of the installation destination. In addition, the studies assumed CLI operation on UNIX from installation to execution of the developed systems. Such a technical assumption has limited the users to start learning analysis with the systems. Our SRP Web Services do not require installation of complex software and operation of the developed systems on CLI. Any users just access the webpage and analyze learning activities on a web browser. Experimental evaluations showed that the proposed web services support learning analysts in quantitative analysis of learning activities with high usability. In addition, SRP Web Services are scalable with hundreds of users. SRP Web Services promote an IoT system to support collaborative learning analysis for learning analysts who are unfamiliar with information technology. For our future work, we plan to accelerate learning algorithms of our proposed web services to further improve the usability for learning analysts. RITSUKO OSHIMA has been involved in a research project to develop a project-based learning curriculum at the Engineering Department for several years. She is currently a Professor with the Faculty of Informatics, Shizuoka University, Japan. Her current research interest includes the development of a scenario-based questionnaire to evaluate students' collaboration skills.
JUN OSHIMA is currently a Professor with the Faculty of Informatics, Shizuoka University, Japan. His research interest includes development of new methodologies to evaluate students' collective knowledge advancement. In his recent work, he has developed a social network analysis of discourse from the perspective of knowledge-building. TAKASHI WATANABE (Member, IEEE) received the B.E., M.E., and Ph.D. degrees from Osaka University, Japan, in 1982, 1984, and 1987, respectively. He joined the Faculty of Engineering, Tokushima University, as an Assistant Professor, in 1987, and moved to the Faculty of Engineering, Shizuoka University, in 1990. He was a Visiting Researcher at the University of California at Irvine, from 1995 to 1996. He is currently a Professor with the Graduate School of Information Science and Technology, Osaka University. He has served on many program committees for networking conferences of IEEE, ACM, IPSJ, and the Institute of Electronics, Information and Communication Engineers (IEICE), Japan. His research interests include mobile networking, ad-hoc networks, sensor networks, ubiquitous networks, intelligent transport systems, and especially MAC and routing. He is a member of IEEE Communications Society, IEEE Computer Society, IPSJ, and IEICE.