\chapter{Privacy Preserving Loneliness Detection: A Federated Learning Approach}
\markboth{Privacy Preserving Loneliness Detection}{}

In Chapter 2, which was the literature review, we identified privacy as a critical issue in the existing passive sensing-based loneliness detection systems. To address this gap, this appendix presents a feasibility study to explore the potential of using federated learning for handling privacy in passive sensing for loneliness detection. This work is primarily a proof-of-concept. Significant improvements and addressing issues would be necessary for using this in real scenarios.

Previous research has used machine learning in combination with several clinical scales to detect loneliness in people using data collected passively from smartphone sensors. Usually, these studies use data from multiple individuals using their smartphones and wearable sensors on a single central server to train a model for loneliness detection. However, this centralized approach has major privacy issues since it transfers sensitive user data to a single place, which makes it susceptible to breaches and other privacy related issues. This appendix presents a federated learning based method for developing loneliness detection system that allows machine learning models to be trained locally on users' end devices. This approach improves privacy since there is no need to transfer the raw sensor data to a server; instead, it will share only local models' weights with the server for training a global model.

This appendix also discusses the results that were obtained using different algorithms inside federated learning. The study used the StudentLife dataset and four different binary classifiers have been used to train loneliness classification models inside federated learning framework. The models are assessed in federated and centralized learning scenarios to determine their efficiency of detecting loneliness using passive sensing data.

\section{Methodology}

\subsection{Federated Learning Architecture}
Federated learning (FL) prioritizes data privacy by decentralizing data storage and training machine learning models directly on users' devices. Instead of aggregating raw data at a single server, FL uses the knowledge gained from local models to collaboratively train a shared global model. This method inherently protects data privacy and reduces the costs associated with data transfer to a server. In federated learning, a central server coordinates the training process on behalf of various participants, known as clients. Instead of sending their local data to the server, clients compute updates on the shared model. Only these updates are transmitted to the server, ensuring client data remains private and secure.

The overall architecture of federated learning is presented in Figure~\ref{fig:arch}. Each client goes through an independent model training process. Only the learned local model parameters from each client are forwarded to a secure server for aggregation into a global model. Subsequently, the server provides the combined global model to the clients, and this cycle continues. We have presented this process in detail below.

\subsubsection{Process of a Single Epoch in Federated Learning}
The following are the stages for a single epoch in Federated Learning (FL).

\subsubsection{Initial Setup}

\begin{enumerate}
  \item \textbf{Parameter Initialization:} At the beginning of the federated learning (FL) process, the global model and the local models on each client's device are both started with random parameters. Because of this arbitrary initialization, the parameters of the local models and the global model are different from each other.
  \item \textbf{Parameter Distribution:} The global model provides its initial parameters to all participating clients to ensure consistency. This stage ensures that all clients start training their local models from a standardized baseline which helps to create a consistent learning process across the network.
\end{enumerate}

\subsubsection{Local Model Training}

\begin{enumerate}
  \item \textbf{Client-Side Training:} Clients use the global model's parameters to train their local models independently using the data on their own devices. This training process is localized, meaning that it allows the model to use personal data that is specific to the device.
    \item \textbf{Parameter Updating:} Throughout the local training phase, each client updates its model's parameters based on the learning process. This iterative adjustment refines the local models and makes them representative of their local data.
\end{enumerate}

\subsubsection{Aggregation and Global Update}

\begin{enumerate}
  \item \textbf{Local Parameter Sharing:} Upon completing the local training, clients prepare to contribute to the global model's learning by sharing their updated model parameters with the central server.
  \item \textbf{Global Model Aggregation:} Once the central server receives updated parameters from all participating clients, it proceeds to aggregate these weights to update the global model. The objective is to synthesize the learning from across the network into a single, improved global model that would be based on distributed models from all the clients.
  \item \textbf{Global Model Redistribution:} The server sends back to the clients the updated global model parameters after completing the aggregation. This completes a single cycle of federated learning, with each client receiving the latest version of the global model's parameters to serve as the basis for the next round of local training.
\end{enumerate}

\begin{figure}[hbt!]
    \centering
    \includegraphics[width=0.48\textwidth]{figures/Appendix/FL_arch.png}
    \caption{Federated Learning Architecture: The central server communicates with the clients without exchanging any private data from clients. Still, the global model on the server uses the model weights from each client's local models to achieve a higher overall performance.}
    \label{fig:arch}
\end{figure}

These steps complete one epoch. We can set the number of epochs to repeat all the above steps again and again to improve the performance of the global model. We have used the Flower framework \cite{beutel2020flower} to build and simulate a federated learning environment. Flower is a flexible and customizable framework for building and researching federated learning systems. It is designed to make it easier for developers to experiment with different federated learning strategies. Flower provides many federation algorithms for model training and aggregation on the server side. We chose the most commonly used FedAvg algorithm for this feasibility study \cite{mcmahan2017communication}, given its established effectiveness, simplicity, and suitability for handling moderately heterogeneous data.

\subsubsection{Federated Averaging (FedAvg) Algorithm}

FedAvg algorithm works through a series of iterative steps to train a global model across multiple clients. Below is a detailed explanation of each step in the FedAvg algorithm as described in Algorithm~\ref{alg:fedavg}.

\begin{algorithm}[H]
\caption{FedAvg Algorithm. K is the total number of clients; B is the size of mini-batches, T is the total number of communication rounds, E is the total local training epochs, and $\eta$ is the learning rate}
\label{alg:fedavg}
\begin{algorithmic}[1]
\REQUIRE $K$: Total number of clients, $N$: Total data points across all clients, $E$: Number of local epochs, $B$: Local mini-batch size, $\eta$: Learning rate
\STATE \textbf{Server executes:}
\STATE Initialize global model weights $W_0$
\FOR{each round $t = 1,2,\dots$}
    \STATE $m \leftarrow \max(C \cdot K, 1)$  \COMMENT{$C$ is the fraction of clients selected per round}
    \STATE $S_t \leftarrow$ (random set of $m$ clients)
    \FOR{each client $k \in S_t$ \textbf{in parallel}}
        \STATE $W_{t+1}^k \leftarrow \text{ClientUpdate}(k, W_t)$
    \ENDFOR
    \STATE $W_{t+1} \leftarrow \sum (\frac{n_k}{N}) \cdot W_{t+1}^k$  \COMMENT{Aggregate updates from clients}
\ENDFOR
\STATE
\STATE \textbf{ClientUpdate}$(k, W)$:  \COMMENT{Run on client $k$}
    \STATE $B_k \leftarrow$ (split data into batches of size $B$)
    \FOR{each local epoch $i$ from $1$ to $E$}
        \FOR{batch $b \in B_k$}
            \STATE $W \leftarrow W - \eta \cdot \nabla L(W; b)$  \COMMENT{Update weights using gradient descent}
        \ENDFOR
    \ENDFOR
    \RETURN $W$ to server
\end{algorithmic}
\end{algorithm}

\subsubsection*{Initialization}
The server initiates the process by assigning global model weights, denoted as $W_{0}$. These weights are the starting point for the model before any training has occurred.

\subsubsection*{Training Rounds}
For each training round \( t \), the server selects a subset of clients. The selection is random, with the number of chosen clients determined by the product of \( C \) (the fraction of clients to be selected each round) and \( K \) (the total number of clients), ensuring at least one client is selected.

\subsubsection*{Local Training on Clients}
The selected clients receive the current global model weights $W_{t}$ from the server. Using these weights as their starting point, each client trains the local model by using the local data available. This local training is performed for \( E \) epochs, meaning the model on each client is iteratively updated \( E \) times based on the client's data.

\subsubsection*{Parameter Updating and Aggregation}
Upon completing local training, clients update their model's parameters based on the insights collected from their data. These updated parameters are then sent back to the server.
The server aggregates these updates from all participating clients to form a new set of global model weights, $W_{t+1}$. Aggregation is typically performed by taking a weighted average of the submitted updates, where the weights are proportional to the volume of data each client contributes. This ensures that clients with more data have a proportionally greater influence on the global model.

\subsubsection*{Distribution of Updated Global Model}
After aggregation, the server distributes the updated global model $W_{t+1}$ back to the clients. This completes the cycle, or epoch, of federated learning, with each client receiving the latest version of the global model to serve as the basis for the next round of local training.

\subsection{Dataset and Data Preprocessing}
This study used a subset of the StudentLife dataset \cite{wang2014studentlife}. Effective data preprocessing is important in federated learning environments to ensure that the models trained on decentralized data can generalize well across diverse clients. We performed multiple preprocessing steps on each local client, which included outlier removal, handling missing values, handling class imbalance, and data scaling. These steps contribute to addressing some aspects of non-IID (non-Independent and Identically Distributed) data challenges associated with FL. Local preprocessing helps normalize data within each client to reduce feature-level disparities across clients. For instance, client-specific outlier removal and scaling can help align the range and distribution of feature values to mitigate some effects of feature distribution skew. Additionally, to address class imbalance, we used the Synthetic Minority Over-sampling Technique (SMOTE) locally on each client. SMOTE creates synthetic examples of the minority class to help balance the class distribution within each client's dataset. This local application of SMOTE can help mitigate label distribution skew across clients, as it ensures each client has a more balanced representation of classes, potentially leading to more robust local models and, consequently, a more effective global model.

\subsection{Loneliness Detection Using Centralised Machine Learning}
We took loneliness as a binary classification problem with a target variable as '1' for students feeling lonely and '0' for not lonely. The data from 41 students was used to train four distinct binary classifiers. These classifiers are Logistic Regression, Random Forest, Support Vector Machine (SVM), and XGBoost. These were selected for their diverse learning mechanisms and proven effectiveness in binary classification problems.

For the evaluation and validation of these models, a 10-fold cross-validation technique was used. This method involves partitioning the data into ten equal parts, using nine parts for training the model and one part for testing, which iteratively cycles through all parts to ensure each segment serves as the test set once. The performance metrics chosen for evaluating the classifiers include accuracy, precision, recall, and the F1 Score. These metrics provide insights into the models' effectiveness in correctly identifying lonely individuals (accuracy), their reliability in making positive predictions (precision), their sensitivity in detecting actual cases of loneliness (recall), and a balanced measure of precision and recall (F1 Score).

\subsection{Loneliness Detection Using Federated Learning}
To explore the effectiveness of federated learning (FL) for detecting loneliness, we implemented a federated learning approach using the FedAvg algorithm for model aggregation. In this setup, each of the 41 participants in the study acted as a local client. The process involved multiple number of rounds of local training, while the number of rounds for the global model varied for different models. After each round of local training, model updates were shared with the server and aggregated using FedAvg to create an updated global model. We trained local models using the same binary classification algorithms used in the centralized approach: Logistic Regression, Support Vector Machine (SVM), Random Forest, and XGBoost. The evaluation of the federated learning models used the same metrics which are accuracy, precision, recall, and the F1 score.

\begin{table}[b]
\caption{Performance of centralised machine learning models classifying loneliness using a subset from the StudentLife dataset.}
\centering
\begin{tabularx}
{0.76\textwidth} { 
  |p{21mm}| >{\centering\arraybackslash}X 
  |p{22mm}| >{\centering\arraybackslash}X 
  |p{10mm}| >{\centering\arraybackslash}X 
  |p{10mm}| >{\centering\arraybackslash}X
  |p{13mm}| >{\centering\arraybackslash}X | }
  
 \hline
  & \textbf{Accuracy} & \textbf{Precision} & \textbf{Recall} & \textbf{F1 Score} \\
 \hline
 \textbf{XGBoost}  & 83\%  & \centering 93\% & 89\% & 91.5\%  \\
\hline
\textbf{RF}  & 85\%  & \centering 89\% & 82\% & 87\%  \\
\hline
\textbf{SVM}  & 78.5\%  & \centering 77\% & \centering 83\% & 81\% \\
\hline
\textbf{LR}  & 73\%  & \centering 68\% & 79\% & 75\%  \\
\hline
\end{tabularx}
\label{table:centralisedprivacy}
\end{table}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Results and Discussion}
The goal of classification models was to differentiate between lonely (Class 1) and not lonely (Class 0) individuals. Results show that XGBoost is the best model among centralized machine learning models overall, with an accuracy of 83\%. After this is Random Forest with an 85\% but other metrics are low as compared to XGBoost. The performances of all classifiers within the centralized framework are detailed in Table-\ref{table:centralisedprivacy}.

In the federated learning (FL) models, the performance metrics of various classifiers are presented in Table-\ref{table:federated}. Here XGBoost performed best with an accuracy of 77.5\%, followed by Random Forest (72\%), Support Vector Machine (68\%), and Logistic Regression (51\%), respectively.

The reduced performance observed in FL models could be due to several factors inherent to the decentralized nature of FL and the characteristics of the dataset. Data heterogeneity across clients likely contributes to this performance gap. This variability leads to non-IID data distributions, which complicate model training and generalization. Our preprocessing steps have been implemented to reduce some of these effects. Specifically, these techniques help standardize the training data across clients, ensuring more uniform input into the models. While these preprocessing techniques may not fully eliminate all the challenges posed by non-IID data.


\begin{table}[b]
\caption{Performance of federated learning models classifying loneliness using a subset from the StudentLife dataset.}
\centering
\begin{tabularx}
{0.76\textwidth} { 
  |p{21mm}| >{\centering\arraybackslash}X 
  |p{22mm}| >{\centering\arraybackslash}X 
  |p{10mm}| >{\centering\arraybackslash}X 
  |p{10mm}| >{\centering\arraybackslash}X
  |p{13mm}| >{\centering\arraybackslash}X | }
  
 \hline
  & \textbf{Accuracy} & \textbf{Precision} & \textbf{Recall} & \textbf{F1 Score} \\
 \hline
 \textbf{XGBoost}  & 77.5\%  & \centering 81\% & 84\% & 81.5\%  \\
\hline
\textbf{RF}  & 72\%  & \centering 61.5\% & 76\% & 68\%  \\
\hline
\textbf{SVM}  & 68\%  & \centering 58\% & \centering 71\% & 67\% \\
\hline
\textbf{LR}  & 51\%  & \centering 43\% & 61\% & 56\%  \\
\hline
\end{tabularx}
\label{table:federated}
\end{table}


\section{Limitations}
This feasibility study shows the potential of federated learning (FL) as a privacy-preserving approach for loneliness detection using passive sensing data. However, there are a number of limitations to this work. Firstly, our use of the 10-fold cross-validation to determine performance and convergence and adjust the number of rounds may have introduced some level of overfitting. This approach could lead to overly optimistic performance estimates. Additionally, we did not implement an early stopping mechanism, which could have helped prevent overfitting and optimize computational resources. Another significant challenge is in effectively handling non-IID data in federated learning scenarios. While our preprocessing steps aimed to mitigate some effects of data heterogeneity, more advanced techniques for addressing this issue should still be investigated. 

With only 41 participants serving as clients, our study may not fully capture the scalability challenges of FL in larger, more diverse populations. FL involves multiple rounds of communication between clients and the server which can be resource-intensive. In real-world applications, this could lead to increased latency and energy consumption on mobile devices so efficient scalable solutions would be required to handle this issue. Our study assumed consistent client participation, which may not reflect real-world scenarios where clients may join or leave dynamically. 
