Abstract
Driven by technologies and demands, the modern transportation system has developed from intelligent transportation systems (ITS) to autonomous transportation systems (ATS) to resolve intertwined demands and supplies with few human interventions. In ATS, personal mobility service (PMS) is the service that can sense real-time traffic conditions comprehensively, learn travelers’ preferences accurately, recommend multimodal travel options appropriately, and provide service responses timely to elevate the level of personalization and intelligence in smart mobility services. Since current PMS widely employs centralized approaches (CPMS) to process massive sensitive data from individuals and support diverse edge devices, resulting in high pressure in privacy protection and performance balancing, this paper presents a federated PMS (FPMS) and its design architecture in logical and physical views by adopting federated learning to provide multimodal, dynamic, and personalized travel options with system-saving safety and efficiency guaranteed. Moreover, through an extensive evaluation, the performances of CPMS and FPMS are compared to reveal the merits of FPMS in reducing costs and latency.
1. Introduction
Presently, our travel activities have relied on intelligent transportation systems (ITS) for over 50 years, and the development of ITS technologies has been abundant and comprehensive. However, with the vast application of advanced technologies (e.g., artificial intelligence, big data, and Internet of Things), travel patterns are diversified over time, impacting the evolution of the modern transportation system. Gradually, ITS becomes incapable of keeping a balance between the demands of the public and the supplies of the system, and hence, a next-generation system, called autonomous transportation system (ATS), is being put forward to renovate ITS services. In general, ATS aims to bridge user demands and system supplies through an automated and integrated workflow, which can precept system statuses, learn insightful knowledge, make optimal decisions, and control corresponding components to transform the overall system towards five goals to be safer, more efficient, more convenient, more environmental, and more economic unobtrusively, seamlessly, and automatically, as shown in Figure 1.
To make the system to be less human-centric, ATS with its components, i.e., demands, technologies, services, functions, and participants, shall be renewed to gradually elevate its level of intelligence and autonomy. Personal mobility service (PMS) [1] can be renovated to help travelers find the most suitable and personalized route choices quickly during the route planning step, to support various travelers with user preferences fulfilled and system objectives addressed at the same time. Accordingly, there arise three challenges: (1) how to process massive sensitive data (e.g., personal preferences, trajectories, and activities) for travelers’ preference analysis, (2) how to ensure data security, especially protecting user privacy while processing unconsented data from travelers, and finally, (3) how to harness plentiful and growing resources located at the edge (e.g., personal smart devices) as a means to reduce the burden of the server.
Presently, there are related solutions studying the above challenges; however, most of the solutions concentrate on big data processing to better profile the users and provide more accurate travel suggestions by using centralized approaches that, in turn, implement centralized PMS (CPMS) [2–4], instead of considering user privacy protection and idle resource usage. Hence, this paper presents an FPMS (federated PMS) and its design architecture, making trip planning more personal, intelligent, and efficient. In general, FPMS is integrated with multimodal travel options and is implemented in ATS to support dynamic and personalized services. Compared to the limited and general options provided by traditional route planning services, FPMS can address the specific needs and preferences of travelers together with system supplies optimized. To achieve that, FPMS not only needs to sense the macro traffic conditions but also needs to accurately analyze the micro user behavior to assist in decision-making and service planning and provide dynamic and personalized solutions to improve system efficiency and effectiveness [5, 6].
The main contributions of this paper can be concluded as follows: (1) the emerging requirements and challenges of PMS to support the development of ATS are summarized, (2) a reference architecture to design an FPMS for ATS, with functional, logical, and physical views that distinguish it from the CPMS, and (3) through an extensive experiment, the performances of CPMS and FPMS are compared to reveal the merits of FPMS in improving the service quality by manipulating and orchestrating the massive smart devices.
The remainder of this paper is organized as follows: Section 2 provides an overview of PMS, CPMS, and FPMS and also discusses related challenges and solutions. Next, Section 3 describes the architecture design methodology with multiviewed architectures (e.g., functional, logical, and physical architectures) between CPMS and FPMS. Section 4 analyzes the performance differences between CPMS and FPMS through three indicators (e.g., training time, resource consumption, and average outage probability). Section 5 concludes the achievements of our research and gives suggestions for future studies.
2. Overview
In this section, PMS is, first, introduced, and accordingly, the differences between CPMS and FPMS are explained as prior knowledge to discuss current research challenges and solutions.
2.1. Introduction of PMS
Personal mobility service (PMS), as a service enabling mobility as a service, primarily emphasizes the integration of real-time demands and multimodal travel modes, which can assist individual mobility by recommending suitable travel options. In addition, as one of the core characteristics of PMS, it requires rerouting timely based on sensed changes in user and system statuses, e.g., the travel destination altered during a trip, or congestions caused by accidents. Besides that, personalization is ensured by building and interpreting user profiles and disclosed by providing and serving individuals according to their interests and expectations. Therefore, the quality of PMS highly relies on the advancement of recommendations, which can handle individuality (e.g., identity, preferences, and constraints) to capture relevant users’ attributes and characteristics (e.g., users’ behaviors).
As a facade for PMS, typical user interfaces (UIs) are required in PMS. Specifically, when users start to travel, they can timely access the personal travel menu (see Figure 2) through a variety of channels such as smartphone apps, tablets, and computers, to determine their mode, time, cost, etc. Compared to the traditional route planning service, which provides travel options based on the availability of various travel modes (which can be integrated as well), PMS has the potential to not only provide user-oriented routes according to travelers’ preferences but also optimize the usage of currently available system supplies.
As shown in Figure 3, PMS can enable collaboration between the physical and virtual worlds. There are two important modules to assist the running of PMS, namely, (1) dynamic route planner and (2) personalized recommendation engine. Specifically, the dynamic route planner receives basic traveler requests (e.g., origins and destinations) and real-time traffic conditions to provide multimodal route schemes meeting the objective of the system. After receiving multimodal route schemes, the personalized recommendation engine returns best-fit routes by analyzing user needs and preferences according to the information extracted from users’ profiles and travel histories. After these recommended trips are presented to each individual through mobility hubs, the actual travel will be performed by travelers by selecting one of the travel options and also act as an impulse to the system, which will change its running status accordingly. Since the trip executed by travelers is recommended and optimized by PMS with user preferences and system objectives both considered seamlessly, PMS can be an efficient and effective user-oriented and long-running service to elevate the intelligence and autonomy of the transportation system.
2.2. Differences between CPMS and FPMS
Conventionally, PMS widely adopts a centralized mechanism, called centralized PMS (CPMS), which manages massive user data and collaborates with diverse user devices through a central server. Since user-sensitive data need a high bandwidth network to transmit and a high-performance server to process, issues about information leakage and single-point failure may occur and become the bottleneck of PMS. To address these issues, PMS is adopting a distributed operation mechanism, which forms federated PMS (FPMS). Specifically, FPMS employs federated learning and computing to not only bridge data silos in a private-preserving manner but also utilize distributed computing resources at the edge in a collaborative approach. Compared to CPMS in Figure 4, FPMS can enable local data processing at each client, and instead of exchanging raw data, it only requires desensitized parameters for knowledge fusion, e.g., to train a machine-learning model [7]. In this way, FPMS can not only ensure data security and privacy but also improve resource utilization. To sum up, FPMS is one step ahead of CPMS in optimizing mobile demand and supply in a new way, by allowing the integration of multiple types of open and private data.
2.3. Emerging Requirements and Related Solutions
This section summarizes (1) requirements in designing and implementing PMS and (2) related solutions addressing these specific challenges to better support PMS.
2.3.1. Challenges
Personal mobility service (PMS) could be considered an advanced and intelligent route planning service, which represents one form of travel information service [8] to provide various and valuable travel information through the interactions between travelers and public transport operators. Conventionally, static data are mainly the information source for route planning, such as finding the shortest paths [9]. Along with the rapid development of emerging technologies and increase in traveling demands, real-time data sensed from the system and users are processed to provide more accurate and user-friendly travel options [10]. To achieve such a goal, during the transformation from ITS to ATS, PMS needs to fulfill the following essential requirements:(i)Real-time data [9, 11]: The combination of static data and real-time data could assist travelers in interpreting traffic situations and remedying the perception of unreliability from the user perspective. Effective collection and use of real-time data in PMS can help travelers feel more in control of their trips, including their time spent and money cost.(ii)Multimodal route [12, 13]: The multimodal route refers to the extrapolation of routes using different modes of transportation within a given time interval, which is usually provided by most commercial tools and applications, such as Google and Baidu Maps. Travelers usually ask for an optimal route, including all available transportation modes, and this needs a more efficient and advanced routing mechanism. Multimodal routing refers to the extrapolation of routes using different modes of transportation within a given time interval, which is usually provided by most commercial tools and applications, such as Google and Baidu Maps.(iii)Dynamic routing [14, 15]: Dynamic routing implies that the routing algorithm can process sensed information about passengers and transportation systems in real-time and also react to it through rerouting. Based on real-time traffic data, dynamic routing in PMS can guide travelers to their destination in a timely and cost-efficient way.(iv)Personalization aspect [16, 17]: Both traffic conditions and personal characteristics are essential for personalization. Such that, PMS is required to capture and analyze individual characteristics and real-time traffic situations and recommend the most suitable options matching users’ preferences with less latency and error.(v)Privacy protection [1, 18]: Since PMS needs to process large amounts of sensitive data, the leakage of information may occur, if these data are collected and managed by a central server. Moreover, due to the various laws and regulations that countries have put in place to protect personal data, data silos with unshareable data may incapacitate the application of PMS by using centralized solutions.(vi)Service performance [5, 19]: At present, PMS needs to implement most of its functions and process large amounts of disparate data collected from many participants in a centralized cloud, which can be a performance bottleneck for the timely processing of related requests, especially when the number of service users is growing exponentially [20]. It is required to renovate the service operation paradigm to further improve the efficiency and effectiveness of PMS.
2.3.2. Related Solutions
To address these challenges, various solutions have been proposed as summarized and evaluated in Figure 5. Initially, the traditional route service used static data to plan routes and inform travelers’ travel information (e.g., time, cost, and distance) studied, such as TransPlus [21]. After that, KAMO [22], as a mobile public transportation guide application, is proposed to support route planning for public transportation passengers based on real-time data. More advanced, multimodal routes are addressed by OneRide [10] and in-vehicle application for multimodal route planning (IVA-MAP) [15], which can also support dynamic routing to further enhance the functionality of PMS.
Moreover, recently, personalization has been emphasized, and accordingly, several solutions have been proposed to implement trip recommendations, e.g., TRIP [23], approach CTRR [2], and BR2 [24]. As a comprehensive solution to not only address the real-time data and multimodal travel modes but also support on-demand route (re-)planning, MaaS is studied to provide travelers flexible, personalized, and seamless mobility via a single interface [25].
Since most of the current solutions for PMS adopt centralized approaches to collect and process massive sensitive data to better analyze user preferences, it may suffer issues about user privacy as data transmitted through the network are vulnerable and single-point failure as most of the tasks are implemented and executed at the central server, such that the requirements to improve service quality start to be discussed. For example, OR2P [26] protects trajectory privacy and PIR [27] protects location privacy.
Finally, as for the service performance, a novel location obfuscation method (DLOM) for online route planning was proposed by Corcoran et al. [28], which can protect user privacy and allocate workload to the edge according to a distributed mechanism, which is also applied in a driver preference-based route planning (DPRP) model to speed up the search process in recommending personalized routes [29].
In summary, the requirements to handle real-time data, multimodal routes, dynamic routing, and personalization have been widely studied in related solutions; however, solutions to protect user privacy and improve service performance are still partial. To further evaluate the intelligence of PMS, this paper proposes a novel architecture by incorporating federated learning to address emerging issues about privacy protection and performance improvement. Federated learning (FL) was proposed by Google in 2016, to build machine-learning models based on datasets that are distributed across multiple devices while preventing data leakage [30]. AbdulRahman et al. [31] presented a deep investigation and analysis of the FL architecture, design, etc., and proposed future challenges and research directions. Especially, they explain why and how centralized learning develops to FL and point out the issues of CL: latency and data transfer cost. Ben Sada et al. [32] also mentioned the centralized framework that sends data from local devices to the cloud for processing is facing many challenges such as latency and privacy. Therefore, FL has the advantages such as protecting privacy and improving performance, which make FL applications comprehensive.
3. From CPMS to FPMS: The Proposed Design Architecture
To create a standardized architecture of PMS for ATS, the design methodology will be first introduced. Accordingly, the required components are defined and described, and the logical and physical architectures demonstrating the relationships between functions and the interactions among physical objects (e.g., travelers and the information center) are presented, respectively.
3.1. Design Methodology
Developing a common PMS architecture that captures the features of ATS is essential. Hence, the design methodology is proposed, as shown in Figure 6, which consists of (1) component design to define functions and elements required in PMS and (2) architecture design to illustrate the workflow of function in a logical architecture and the interactions among physical objects in a physical architecture. In general, as one of the core services in ATS, PMS aims to satisfy the demands of people and goods by organizing related supplies of the system, which are first defined in the component design. As shown in Figure 6(a), PMS comprises different elements, which are basic physical entities, such as users, infrastructures, and vehicles, and also various functions.
Moreover, based on these defined components, the architecture design illustrates the data flow among functions and information interaction among physical objects (e.g., elements). Accordingly, the logical architecture (LA) and the physical architecture (PA) are defined, respectively, as shown in Figure 6(b). In general, LA presents data flow among functions to define the operation logic of the system. Similarly, PA presents information interaction between elements to illustrate the logic among physical objects (POs) in the real world.
Notably, even though LA defines logical flow among function modules and PA forms physical flow among POs, LA and PA are correlated, as LA can be converted into PA by associating functions with POs, and vice versa. As shown in Figure 7, while functions in LA are associated with related POs, they could form PA, which demonstrates the information interaction between POs. For example, the functions, namely, collecting incident information and collecting dynamic traffic situation data, are supported by POs, namely, roadway monitoring equipment and emergency management center, respectively. The functions, namely, fusion processing data, identifying road network conditions information, and generating traffic control information, are provided by one PO, namely, the traffic management center. Normally, functions are provided by various POs; thus, interaction among different functions in LA is similar to that in PA, and the physical flow below can map to the logical flow above.
3.2. Components of CPMS and FPMS
The components of PMS consist of (1) elements, such as users, vehicles, and infrastructures, and (2) functions required by the elements.
3.2.1. Elements
The elements of FPMS and CPMS are the same as summarized in Figure 8, which are the stakeholders, vehicles, and infrastructures on the left. The stakeholder section refers to people taking part in the operation with 7 objects, e.g., users and travelers, the vehicle section refers to transit vehicles, and the infrastructure section is facilities to maintain the regular transportation operation with 10 objects, e.g., roadway monitoring equipment and traffic information center.
3.2.2. Functions
There are 25 functions in FPMS and 22 functions in CPMS, which are summarized in Figure 9. Importantly, functions are divided into 4 categories based on their characteristics and attributes, which are associated with the processes of “autonomous perception, autonomous learning, autonomous decision-making, and autonomous control.” Note that the functional difference between CPMS and FPMS is highlighted in red.(i)The autonomous perception process is to monitor traffic conditions, in which the sensing functions actively collect environmental data and obtain travelers’ statuses.(ii)The autonomous learning process includes learning functions that extract valid information and knowledge from sensed data (e.g., data fusion and data analysis). The difference between CPMS and FPMS is that CPMS processes data and FPMS aggregates local models uploaded from clients to train the global model.(iii)The autonomous decision-making process generates personalized travel options according to the learned knowledge. In general, both CPMS and FPMS focus on multimodal and personalized route generation.(iv)The autonomous control process produces highly automated execution to fulfill the needs of users and ensure the optimization of system operations. It encompasses the responding capacities that enable the implementation of chosen travel options while providing valid information.
3.3. Multiviewed Architectures of CPMS and FPMS
According to the components defined, the logical architecture (LA) and the physical architecture (PA) can be defined for CPMS and FPMS. LA mainly describes the information interaction and data flow among function modules and provides construction guidance for PA. PA implements data flow in LA, to generate the architecture with various physical objects (POs) and information interactions. PA maps the function modules in LA into the real world and forms various information interactions and data flow among different entities. In general, LA provides construction guidance for PA; therefore, LA is a general design, while PA is a detailed design.
3.3.1. Logical Architecture
LA illustrates the workflow between two connected functions with operation logic highlighted. The flow is to exchange data between functions in four kinds, namely, open data, consented data, desensitized data, and operational data.
First, as shown in Figure 10, LAs of FPMS and CPMS contain 4 layers, namely, the autonomous perception layer, autonomous learning layer, autonomous decision-making layer, and autonomous control layer, with 8 steps:(i)Step 1: Data collection describes the data acquisition process implemented in related sensing devices; e.g., surveillance cameras collect license plate recognition data.(ii)Step 2: Data extraction describes the data extraction process, e.g., extracting meteorological information from environmental data.(iii)Step 3: Data fusion describes the data fusion process, e.g., aggregating multisource heterogeneous data and dispatching global traffic condition data.(iv)Step 4: Data analysis describes the data analysis process that different participants communicate with the server. In FPMS, instead of requiring raw data, the server receives desensitized parameters from clients and aggregates them for the fused knowledge, e.g., the global model.(v)Step 5: Option generation outlines the process where the travel optimization models are used to create multimodal routes.(vi)Step 6: Option personalization outlines the procedure of producing customized travel options by utilizing the optimal global travel selection models to tailor global options based on user preferences.(vii)Step 7: Option execution outlines the option execution process which assists travelers through interactive user interfaces (UIs) during their trips.(viii)Step 8: Option feedback outlines the option feedback process which gathers user experiences for ongoing enhancement of PMS.
While most steps between FPMS and CPMS are similar, there are differences in the data analysis, option generation, and option personalization steps. First, in FPMS, based on the global traffic condition information, it trains the global travel optimization models and transmits models to support the generation of multimodal routes. However, CPMS transmits unimodal route data directly to the server for route planning. Second, in FPMS, based on the personal travel preference information, it trains the local trip choice models for each client and aggregates local models at the server for the global choice models. After the global model is generated, it is transmitted to the client to support the generation of personalized travel options. In CPMS, it requires all raw data, e.g., travelers’ needs, historical trajectories, and system running status, to the central server to train the global model, which may suffer the issue of data leakages and performance bottlenecks.
3.3.2. Physical Architecture
PA of FPMS and CPMS describes the information interaction among different POs, as shown in Figure 11. The PO refers to physical objects, such as vehicles and infrastructures. POs of FPMS and CPMS can be categorized into three categories: entity, module, and system, according to their complexity and functionality:(i)Entity: It is the basic PO and the primary information source in ATS, which interacts with the internal functions provided by the system. In general, an entity is usually a single element, such as stakeholders and vehicles that exchange information with other POs. Entities in PA are marked in yellow in Figure 11, mainly including (a) stakeholders (e.g., travelers and users) consuming the service and (b) vehicles (e.g., bus and metro) supporting the service for the movement of users.(ii)Module: It is the intermediate PO between entities and systems, based on elements that provide simple functionality embedded and exploited at the edges. Modules in PA are marked in red in Figure 11, mainly consisting of (a) roadside monitoring equipment (RME) that collects dynamic traffic situation data, (b) transit vehicle on-board equipment (TVOBE) that collects transit vehicle situation data and transit schedule information from the bus and metro, and (c) the personal information device (PID) that enables travelers to access personalized travel menus.(iii)System: It is the compound PO, which comprises multiple modules, entities, and corresponding functions. Systems in PA are marked in blue in Figure 11, mainly containing (a) weather service system (WSS), which provides weather information, (b) emergency management center (EMC), which provides incident information, (c) maintenance and construction management center (MCMC), which provides work zone information, work plans, and roadway maintenance status, (d) transit management center (TSMC), which manages transit vehicles and provides transit vehicle situation data and transit schedule information, (e) traffic information center (TIC), which serves as a data hub, (f) traffic management center (TMC), which manages massive and various vehicles on the road, and (g) personalized recommendation center (PRC), which optimizes the running of the system according to the personal travel choice model.
In general, PA of FPMS and CPMS has different behaviors in communication between PIDs and PRC. In centralized learning of CPMS, data are transmitted to the server; however, in FPMS, model parameters are transmitted. You et al. [7] proposed the FL life cycle in a distributed manner: (1) raw data are kept on-devices, and each selected client locally trains a model and sends its model parameters to the server, (2) the aggregation of the received models for the global model is performed on the server, and (3) distribution of the updated model to the clients. Since PA of CPMS is designed based on the centralized mechanism, PIDs need to transmit massive sensed data to PRC, as shown at the bottom of Figure 11. Therefore, user privacy could be exposed, and PRC computation workload could be full of pressure. On the contrary, PA of FPMS can deal with data security and privacy challenges through decentralized mechanisms, as shown at the top of Figure 11. After receiving training instruction from PRC, PIDs can train the local travel choice models and send them to PRC for aggregation rather than directly exchanging personal data. Then, PRC returns the latest global travel choice model to PIDs for another round of learning. The above training rounds will be repeated until the global model gets converged.
4. Performance Evaluation
The variations between CPMS and FPMS are (1) CPMS processes data with centralized approaches and (2) FPMS processes data with decentralized approaches. As the workload is allocated to the participants rather than the only server, FPMS is expected to have better performance in communication and computation modules. Hence, this paper defines a common training task to reveal their performance differences by three indicators: (1) training time, (2) resource consumption, and (3) average outage probability.
4.1. Evaluation Setting
This study uses the publicly available dataset Swissmetro [33], which is widely used in research on choice-based estimation of individual travel preferences. Specifically, the data were collected in Switzerland containing 10,729 samples on the trains between St. Gallen and Geneva in 1998. The dataset reflects the travel choice on options of the private car, Swissmetro, and train, and three attributes (e.g., travel cost, time, and distance) were considered [20]. Moreover, Gibbs sampling [6] is applied, and each personal information device (PID) is to train a model analyzing user choice behavior.
One personalized recommendation center (PRC) and 200 PIDs are visualized and connected through the network in the training procedure. In order to simulate a realistic scenario in which users gradually engage with the service until saturation is reached, we assume that the number of clients and their local data will increase gradually and dynamically in each round. While the number of PIDs increases from 1, the related data will increase as well in a learning round. The common constraints used in dynamic data assignment, e.g., the increasing rate of the PID number ( and ) and the growth rate of new data ( and ), are defined in Table 1.
4.2. Evaluation Indicator
With the increase in PIDs and also their assigned data, multiple iterations are necessary to run the model with ideal accuracy to reach a stable state. Under the circumstances, 200 rounds are executed, and the training time, resource consumption, and average outage probability at the final round are used as the evaluation index.
The performance of computation and communication is affected by the size of data samples in each learning round [20]. and indicate PID and the round of iteration, and Table 2 shows the description and value of the related hyperparameters. For example, is the sample size contained by the PID in the learning round. is the sample size utilized by PRC of CPMS, which is the sum of .
As FedAvg [34] is utilized, the aggregation process in FPMS can be ignored in the computation phase, whose computation complexity is 0. and are the CPU frequency of the PID and PRC, respectively. and are the training workload per sample and the computation coefficient [20]. According to the measures in [35], the energy consumption and the computation time of the PID under FMPS in the round and PRC under CPMS are expressed as follows:
, , , and denote transmit power, bandwidth, channel gain of each client, and the power spectral density of the Gaussian noise, respectively. We assume that is allocated uniform bandwidth , where represents the number of currently participated ones. Moreover, the channel gain is modeled through combined path loss and shadowing [36], e.g., , where is the path loss exponent, is shadowing, is the distance to the server, and K represents a unitless constant. The uplink transmission capacity of each client is
As for the communication phase, the size of the model parameter to be uploaded, the record size of simple, the communication coefficient, and the wireless bandwidth are denoted as , , , and , respectively. According to measures in [37], the energy consumption and the communication time of FPMS and CPMS in the round are expressed as follows:
In conclusion, the energy consumption and total time of FPMS and CPMS per round can be expressed as follows:
As for the outage probability during communication, since the server collects data from clients with different volumes, and the growth of clients is at different rates, traffic congestion in the network may lead to upload outages. Hence, the average upload outage probability in the 200 rounds is utilized as the evaluation indicator.
Let mark the size of the data to be transferred. Noteworthy, since the model parameters are uploaded in FL, , while the original data are uploaded in CL; therefore, , in which and are the size of model parameters and data per sample, respectively. We assume that the uplink transmission is lower than the maximum delay ; then, the minimum transmission rate is
As a result, if the transmission capacity is lower than the minimum transmission rate , the transmission outage will occur with a certain probability [36]:where and
4.3. Evaluation Results and Discussion
According to the above configuration, the evaluation is conducted, and related results about training time, resource usage, and service outage are analyzed and discussed.
4.3.1. Training Time
The evaluation results of training time about computation and communication in CPMS and FPMS are illustrated in Figure 12. Since FPMS can train the local model by using the vacancy resources of each PID and transmitting only model parameters, Figures 12(a) and 12(b) show that FPMS spends less time in computation and communication, compared to CPMS. Moreover, the communication time is much lower than the computation time; thus, the sum of training time for FPMS is much lower than the sum for CPMS as well, which can be seen in Figure 12(c).
(a)
(b)
(c)
4.3.2. Resource Consumption
Figure 13 demonstrates the results of resource consumption about computation and communication in CPMS and FPMS. Similarly, FPMS can separate the training tasks and assign them to each PID. Such that the workload of the server can be significantly reduced compared to CPMS, which only consumes resources in PRC. Hence, FPMS consumes fewer resources in computation and communication, compared to CPMS, as illustrated in Figures 13(a) and 13(b). Although the communication consumption of CPMS drops off as less raw data are to be transmitted along with the growth of the learning round, FPMS can still maintain its advantages to optimize the utilization efficiency of resources, as shown in Figure 13(c).
(a)
(b)
(c)
4.3.3. Average Outage Probability
The average outage probability is also used as an indicator for CPMS and FPMS, respectively. As shown in Figure 14, since FPMS only transmits model parameters through the network, it requires much less bandwidth and thus has a low probability of outage only when it has extremely low latency constraints (0.05 ms) and the maximum number of clients. Moreover, this excellent performance does not diminish with an increase in data, which corresponds to the demand for low latency and high reliability of PMS. As the new data steadily increase per round, CPMS occupies more bandwidth gradually, and correspondingly, the outage probability increases. Then, the outage probability of CPMS will reach the peak and lastly decrease to the bottom, as all data have been transmitted.
In summary, FPMS can not only outperform CPMS with a decrease in resource consumption and training time but also be able to serve more clients requiring seamless connections. Such a result reveals the advantages of FPMS in utilizing service resources efficiently and effectively to support PMS with sensitive data protection.
5. Conclusion
The paper presents federated PMS (FPMS), which can provide dynamic and personalized services with the integration of multimodal travel options and real-time traffic situations under the regulation of user privacy for ATS. Through the architecture design (logical architecture and physical architecture) and components design (elements and functions), the differences between CPMS and FPMS are summarized to demonstrate how FPMS can behave better than CPMS to support travelers in a collaborative and privacy-preserving manner. Moreover, an extensive evaluation between CPMS and FPMS is conducted by analyzing their performances according to three indicators, namely, training time, resource consumption, and average outage probability. Compared with CPMS, FPMS can spend less time and resources on computation and communication and maintain better communication stability.
Based on the proposed architecture, FPMS will be implemented with a multimodal data integration mechanism to combine public and private data in different resolutions in the future [20]. In addition, an FL-based travel recommendation algorithm will be proposed to coordinate various heterogeneous devices in an asynchronous manner to overcome the collaboration obstacles among clients.
Data Availability
The data presented in this study are openly available in Biogeme at https://biogeme.epfl.ch/data.html (accessed on 7 August 2022).
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The research was supported by the National Key R&D Program of China (2020YFB1600400), the National Natural Science Foundation of China (62002398 and 41901188), and the Collaborative Innovation Center for Transportation of Guangzhou (202206010056).