On the Orchestration of Federated LearningThrough Vehicular Knowledge Networking

Duncan Deveaux†, Takamasa Higuchi‡, Seyhan Uçar‡, Chang-Heng Wang‡, Jérôme Härri†, Onur Altintas‡

†EURECOM, Campus SophiaTech, 450 route des Chappes, 06904 Sophia-Antipolis, FranceE-mail: {deveaux,haerri}@eurecom.fr

‡InfoTech Labs, Toyota Motor North America R&D, Mountain View CA, USAE-mail: {takamasa.higuchi,seyhan.ucar,chang-heng.wang,onur.altintas}@toyota.com

Abstract—Federated Learning (FL) is a recent distributedtechnique to extract knowledge, i.e. an abstract understandingobtained from a set of information through experience andanalysis. Vehicular networks are highly mobile networks inwhich a large spectrum of data types is distributed. So far,no mechanisms have been defined that distribute FL modelupdates in vehicular networks based on which nodes are likelyto hold the right data for training, and when. In turn, thispotentially limits FL model training speed and accuracy. In thispaper, we describe protocols to exchange model-based trainingrequirements based on the Vehicular Knowledge Networkingframework. Based on this understanding, we define vehicularmobility and data distribution-aware FL orchestration mecha-nisms. An evaluation of the approach using a federated variantof the MNIST dataset shows training speed and model accuracyimprovements compared to traditional FL training approaches.

Index Terms—vehicular, federated, knowledge, orchestration

I. INTRODUCTION

KNOWLEDGE plays an increasingly important role invehicular networks. In applications such as platoon-

ing, object recognition or navigation, knowledge extractedfrom sensor information can be generated, stored and sharedto augment the capacities of connected vehicles. Machinelearning has increasingly been used as a tool for generatingknowledge, as part of multiple use cases. Traditionally, modeltraining is performed by a single, centralized organizationafter all training information has been gathered in a singlepoint. This mode of operation potentially raises privacy andbandwidth issues as large amounts of training information aretransferred over the network to third-party training servers.Federated Learning (FL) is a novel machine learning paradigmaimed at addressing these issues. Instead of gathering alltraining information in a single point, model training is directlyperformed by data-collecting nodes. The result of each localtraining is then aggregated.

Mechanisms have been studied that optimize FL training invehicular networks based on heterogeneous computing powersand link quality of vehicles. However, vehicular networks arehighly mobile and involve large amounts of information ofdifferent nature. Vehicular mobility introduces a specific setof challenges for the efficient application of FL in vehicularnetworks. Because of mobility, the nature and amount ofavailable training information on-board vehicles varies dynam-

ically. What is more, as vehicles are bound by predefinedand nonrandom mobility patterns, mobility induces a biaseddistribution of training data among vehicles.

As such, a vehicular mobility-based orchestration mecha-nism for FL is required to improve training performances. Inthis article, we suggest an approach of mobility-based FL or-chestration based on Vehicular Knowledge Networking (VKN),a framework for knowledge description, creation, storage anddistribution in vehicular networks. Through two complemen-tary use case studies, we demonstrate the need for and define amobility-based FL orchestration mechanism. The contributionof this paper lies in FL orchestration through training clientselection in vehicular environments where training input isunevenly distributed, rather than in FL algorithms themselves.In the evaluation section, we show performance improvementsof VKN-orchestrated FL while training a classifier model forthe digits-only FEMNIST dataset [1]. It is a federated versionof the MNIST dataset of handwritten digits, grouped by writer.

The rest of the article is organized as follows: Section IIintroduces the concept of FL, in both centralized and de-centralized settings. Section III introduces the challenges thatmobility introduces for vehicular FL through two use cases.Based on this understanding, Section IV describes the needfor a vehicular mobility-based orchestration of FL. Section Vintroduces Vehicular Knowledge Networking (VKN) as a po-tential technical candidate to realize FL orchestration. Finally,Section VI shows performance improvements linked to VKN-orchestrated FL, while Section VIII summarizes the article.

II. FEDERATED LEARNING

A traditional approach to training a machine learning modelis to upload all training information from multiple localsources to a centralized training organization. A learningalgorithm, e.g. Stochastic Gradient Descent (SGD), is thenapplied to the full input set to train a model. Once fully trained,the model is spread to local nodes so it can be used in vehicularapplications. However, this approach notably raises privacyissues, as it requires exposing the training information fromeach local source to a central authority.

FL has emerged in the past years to address the issue as analternative approach to traditional machine learning. Insteadof gathering information from local nodes in a centralized

FL Coordinator

RSU MEC

Local Database

1

1

1

1

1

1

2

2

2

2

2

2

3Aggregation of local updated models

Model is downloaded to local nodes

Nodes update their local model copy with local data

Fig. 1: A Round of Federated Learning Training

data center for subsequent training, FL training is directlyperformed by local nodes using local information.

As illustrated in Figure 1, training a FL model is decom-posed into training steps:

1. A subset s ∈ S of local nodes is selected to perform localtraining.

2. The current global model mglob hosted by the coordinatoris downloaded to each node in s (see Figure 1, step 1).

3. Each node si ∈ S performs one or several steps oftraining of the received model with local information (seeFigure 1, step 2).

4. The parameters of each locally-updated model are sentback to the coordinator, which aggregates the local modelparameters to update mglob (see Figure 1, step 3).

The FL approach allows training a model from distributedinput information while preserving user privacy. Alternatively,decentralized approaches eliminating the FL coordinator suchas Gossip Learning (GL) have been studied in the literature [2].As shown in Figure 2, during a session of GL training, eachnode implements two procedures:

• Local training and distribution: Each local node i runsa few steps of local training of their local copy of themodel mi. The updated local model parameters are thensent to a random other node (see Figure 1, step 1).

• Local model merging: When receiving a model update, alocal node merges the received parameters with those ofits own copy of the model (see Figure 1, step 2). Then, itrepeats a step of local training and distribution (step 3).

After multiple rounds of local training and local model distri-bution to random neighbors, models in the network converge.

III. VEHICULAR MOBILITY CHALLENGES FOR FL

Theoretically, FL/GL allows comparable training perfor-mance to that of traditional machine learning, while ensuringstronger training information privacy [3]. However, practicalchallenges must be addressed in order to reach such perfor-

Local Database

1

2

11

1

1

1

2

2

2

2

2

33

3

3

1Nodes train their local copy of the model based on local data.

Nodes choose a random node to send their local model parameters to. Upon reception, the selected node merges the received model with its local copy.

Repeat: Nodes train the updated local model with local data and transmits the result to a random other node.

23

Fig. 2: Principles of Gossip Learning

mance in real mobile applications. Typical challenges faced inapplications of FL to mobile networks include:

• Resource constraints [4, 5]– Non-perfect network channel quality∗ Link quality-aware training node selection [6].∗ Irrelevant updates discarding mechanism [7].∗ Compression mechanisms [8, 9].

– Computational power.– Access to training input.∗ Heterogeneous sensing capabilities.∗ Limited storage capacity.

• Non independent and identically distributed (IID) traininginput.

• Security concerns– Protection against forged model updates [10].– Privacy of training input [11].

• Optimal convergence of the distributed gradient descentalgorithm [12, 13].

• Incentive mechanisms for FL model training [14, 15].When training a FL/GL model, each node is associated

with a training context. An uneven distribution and accessto training data, as well as nodes’ training ability, linked tocomputing power and network link quality must be takeninto account. A key feature of vehicular networks is thehigh mobility of vehicles. As introduced in [16], vehicularmobility brings specific challenges for FL training. It impliesa dynamically evolving training environment and distributionof training data among nodes. In this section, we exemplifythe vehicular mobility-related challenges for FL training invehicular networks through two complementary case studies.

A. Case Study 1: Commonly Observable Input

We consider the use case of a FL model that can be trainedfrom input that can be observed by vehicles at all times whiledriving. Vehicles sense training input as they drive using onboard sensors and are then connected with a FL coordinator

Federated Learning Coordinator

Trainingvehiclesselection

?

Likely selectionA majority of nodes is driving main roads

Training input from main roads is likely to beover-represented in training

Availabletraining input

Availabletraining input

Similar availabletraining input

Availabletraining input

Similar availabletraining input

Unlikely selectionA minority of nodes collect diversetraining data from secondary roads

Fig. 3: Vehicular Mobility Impact for FL with CommonlyObservable Data

to train a model from their locally observed data. In that case,the trained model uses input data that can be collected at anytime of driving by vehicles, e.g. road-state related information.

For example, [17] describes a machine learning modelof road roughness estimation from vehicles’ front camera.Although the authors train the model using traditional machinelearning, the model can be adapted for FL training, wheresensed training information is kept on board vehicles.

At each step of FL training, the coordinator performs clientselection and chooses a set of vehicles to locally compute amodel update. The nature of mobility in vehicular networksbrings additional challenges to perform efficient FL clientselection. As illustrated by Figure 3, mobility in vehicularnetworks is non random. Two originally distant vehicles arelikely to drive the same roads at some point in their journey,as they drive through main arteries e.g. in cities.

As such, the unequal distribution of vehicles on the roadnetwork leads to many vehicles sensing similar training inputin similar areas – e.g. camera images of main roads. A mecha-nism must be designed to unsure that nodes possessing diversetraining data sensed in secondary roads also get represented inFL training, in order to avoid over fitting the model to typicalmain axes mobility.

B. Case Study 2: Sparsely Observable Input

We consider the use case of a FL model that can be trainedfrom input that can only be observed by vehicles at punctualtimes and locations. For example, [18] presents a machinelearning model to predict near-crash situations from observedvehicles’ kinematics. Near-crashes are reasonably rare events,that can only be observed at punctual points of space and time.In the hypothesis of training this model using FL, only vehicleshaving sensed kinematics data of another vehicle experiencinga near-crash should be leveraged as local training nodes. Asvehicles are moving, the ability of vehicles to take part intraining dynamically evolves through time.

In order to accurately train the model, the selected clientsshould be nodes having witnessed a near-crash event andsensed the accompanying kinematics information. As illus-trated by Figure 4, an orchestration mechanism must bedefined in order to allow the coordinator and training vehicles

Federated Learning Coordinator

Near crashevent

Near crashevent

No LocalTrainingData

No LocalTrainingData

Trainingvehiclesselection

?

Available nearcrash input

Available nearcrash input

Pertinent selectionNodes possess training input

Nonoptimal selectionNodes are unable to train

Fig. 4: Vehicular Mobility Impact for FL with Sparsely Ob-servable Data

to communicate training capacities and allocate training re-sources to vehicles that hold meaningful input.

IV. A NEED FOR MOBILITY-BASED FL ORCHESTRATION

Various orchestration mechanisms have been defined toincrease the efficiency of FL in mobile networks to account forheterogeneous capacity and resources access in the network.For example, [6] shows performance improvement of FL inmobile networks by favoring the selection of training nodeswith good channel link quality.

In the previous section, we exemplified the vehicularmobility-related challenges inherent to the application of FLin vehicular networks. In this work, we aim at defining FLorchestration mechanisms to address challenges related tovehicular mobility, leading to varying training environments,rather than varying training capabilities of vehicles.

A. Requirements for Mobility-based Orchestration

Mechanisms of mobility-based orchestration of FL in ve-hicular networks must account for the dynamically evolvingtraining environment of vehicles, in order to:

• Increase the likelihood that nodes selected for modeltraining are able to train the model – i.e. possess theright input for the right model.

• Ensure a dynamic and balanced selection of vehicles formodel training. It should ensure to (i) avoid over fittingthe trained model with training input sensed in similarcontexts, and (ii) avoid missing valuable and originaltraining input sourced from some vehicles.

Protocols should be defined so that training nodes andcoordinators can communicate about required training envi-ronments to train a given model.

On the one hand, training nodes e.g. vehicles shouldcommunicate information about the nature of training datathey hold and the context in which it was gathered. Withoutleaking training data, a vehicle should be able to indicate whatcategory of information it possesses through semantics andinformation naming standards.

On the other hand, coordinators must indicate the necessarycontext and necessary nature of input training data needed for

participating in a FL model training, so as to avoid contactingvehicles that lack required training input.

Once the coordinator was provided with contextual in-formation about the current training context vehicles andtraining nodes are facing, mechanisms should be defined todynamically allocate client selection to avoid over representingor missing valuable training input.

B. Technical Definitions

In order to allow communication of contextual knowledgebetween training nodes, the following technical requirementsmust be met:

1. A message format should be defined to describe thenature of information sensed by vehicles, and the contextit is sensed in. This message should include at least:• A standard, semantically-defined name to identify the

nature of sensed information.• The time and position of information collection.Additional pertinent contextual information includes (i)the status of the vehicle: driving, idle, (ii) data on vehiclekinematics and destination.

2. A message format should be defined to formally describeFL models and their required input. Through a formaldefinition of the conditions of application of a model,coordinators can perform efficient training node selectionby targeting the nodes that possess the required traininginput in the right format. Elements to formally describea model should at least include input and output infor-mation types and nature.

3. A message format should be defined for coordinators torequest for vehicles that possess the right context fortraining a model.

V. INTEGRATION WITH VEHICULAR KNOWLEDGENETWORKING

Vehicular Knowledge Networking (VKN) is a frameworkfor knowledge description, creation, storage and distributionwithin vehicular networks [19]. VKN aims at providing aframework for standard knowledge description, in turn al-lowing cooperative and interoperable knowledge creation anddistribution. As such, VKN can provide for the technical re-quirements of mobility-based orchestration of FL in vehicularnetworks.

As illustrated by Figure 5, vehicular mobility-based orches-tration of FL requires the three aspects of VKN: knowledgedescription, distribution and storage.

A. VKN Semantics & Input Description

VKN allows the description of a model’s input and outputparameters. As defined in [19], the use of semantics standardallows vehicles to know which input to provide to a modelin order to apply or train it. Using this format, training nodesand coordinator can reach a common understanding on whatcontext is required to train a model.

Figure 6 illustrates an example model description appliedto the model of road surface condition estimation described

Vehicle 1Training Environment

FL Coordinator

Knowledge Base

Vehicle 2Training Environment

Vehicle nTraining Environment

● Sensing location● Sensing time● Information type

● Semantic name

1

3

2

Training contextnotification

Request for aspecific training context

VKN: Knowledge Base

VKN: Semantics &Knowledge Description

VKN: KnowledgeSharing Messages

Client Selection & Training

For each Training Iteration

Available Training Environments...

Selected Training Vehicles

...

Fig. 5: FL Orchestration Through VKN

in [17] and introduced in Case Study 1. The nature of requiredinput to the model is a front camera image, the output of themodel is a class for the road surface condition, as detailedin [17]. Additionally, description of model weights as wellas training parameters allow nodes to take part in a trainingprocess for the model.

model_name: model.road_surface_condition

model_description:INPUT(camera_image: #Image.FrontCamera),OUTPUT(road_surface_condition: #RSC.ClassID)

model_training_parameters:MODEL_PARAMETERS(... [Neural Network

Weights Description]),LOSS_FUNCTION(loss.cross_entropy)

Fig. 6: Example of a VKN Model Description applied to [17](Case Study 1)

B. VKN Knowledge Distribution: Environment Description

Coordinator and training vehicles must communicate inorder to orchestrate FL training:

• Vehicles communicate their training environment to thecoordinator.

• The coordinator issues training environment requests tovehicles to get a list of vehicles able to train a model.

As exemplified in pseudo code in Figure 7, using the Vehic-ular Knowledge Query format introduced in [19], coordinatorand vehicles can communicate on training environments. Thedescription of a training environment includes the nature ofsensed information – i.e. a semantically-defined name –, aswell as the time and location of information collection. Ina decentralized GL setting, vehicles can directly query andexchange training environments with other vehicles.

C. VKN Knowledge Base: Coordinator

Finally, as shown in point 3 of Figure 5, the coordinatorreceives training environment descriptions from vehicles andstores them in a local Knowledge Base (KB). Using the contentof the KB, while training a model, the coordinator is able toselect vehicles that are most likely to feature the required train-ing input. Alternatively, in a decentralized GL setting where

Coordinator requests:REQUEST TRAINING_ENV(#Image.FrontCamera)

IN [Area] AT [Time Range]

Vehicle answers:AVAILABLE TRAINING_ENV(#Image.FrontCamera)

IN [Area] AT [Time Range],VEHICLE ID: [vehicle address]

Fig. 7: Training Environment Request and Answer, basedon [17] (Case Study 1)

vehicles directly exchange training environments, vehicles canstore that content in an on-board KB and use it to directlytransfer model updates to other pertinent vehicles.

VKN integration provides a support for the definitionof mobility-based FL orchestration mechanisms in vehicularnetworks. In Section VI, we provide and evaluate a VKN-based orchestration mechanism for centralized FL. Vehiclesand coordinator are training a model whose VKN descriptionis commonly available. As vehicles sense information thatqualifies as input for the model being trained, they inform thecoordinator of their updated training environment and ability totrain the model. Finally, at each iteration of model training, thecoordinator performs clustering of potential training vehiclesbased on the location of their last reported training inputsensing. Then, for each cluster, the coordinator selects thevehicle having most recently reported an updated trainingenvironment to perform a model update for that iteration.

VI. EVALUATION SETUP

We implement mobility-based orchestration of FL throughVKN and investigate potential performance improvements forboth case studies described in Section III. We simulate a set ofvehicles in a fixed size area, whose movements follow standardmobility models. As they move, vehicles sense informationabout their environment, that can be used as FL training input.We use vehicles as training nodes to train a classifier basedon the digits-only FEMNIST dataset.

For the first case study, we investigate on mobility-based or-chestration on FL training process for models with commonlyobservable input, e.g. the road surface condition estimationmodel in [17]. All vehicles periodically sense information fromtheir environment that is usable in the model’s FL training.As vehicular mobility is not random, two vehicles that areoriginally distant are likely to drive the same road at somepoint, and thus provide similar input to the model’s training,potentially triggering overfitting.

For the second case study, we implement mobility-basedorchestration for the class of models that can be trained oninput sourced from sparse, rare events. The model describedin [18] fits this category. Due to vehicular mobility, in thiscase study, only a fraction of vehicles owns the required inputfor training the model at a given time.

1 km

1 km

FL Coordinator

Training Interests Database

FL TrainingMNIST digits

dataset

Each cell is associated with a constant single training inputSample 1 Sample 2 Sample n

...

750 vehicles divided in groups

Fig. 8: Evaluation Setup for Case Study 1

A. MNIST Dataset Choice

In order to assess the performance of FL training with VKNorchestration, we train a classifier based on the digits-onlyFEMNIST dataset [1]. It is a federated version of MNIST, andconsists of a dataset of handwritten digits associated with a textversion of the character. In this federated version, digits aregrouped by writer. As such, digits-only FEMNIST replicatesthe non-IID data distribution that one should expect in FLtraining.

Rather than in FL algorithms themselves, the contribution ofthis paper lies in FL orchestration through training client selec-tion in vehicular environments. While digits-only FEMNIST isa simple dataset, it provides flexibility in terms of choosing andmodifying the distribution of training data, which is necessaryto verify the performance of the VKN-orchestrated FL scheme.Therefore, as an initial application and proof of concept, weuse the FEMNIST dataset to compare the performance oftraining with and without VKN orchestration.

B. General Setup

We simulate the FL training of a digits-only FEMNISTclassifier in a vehicular environment. V = 750 vehicles aresimulated in a one square kilometer area over the courseof T = 1h simulated time. Each vehicle is a potentialtraining node, reachable by a central coordinator at all timesto compute local model updates upon request. For both casestudies, the training algorithm and evaluation processes areidentical. However, the mobility model followed by vehiclesas well as the data sensing mechanism are different, tosimulate the mobility challenges described in Section III. Weuse the tensorflow federated library to implement the modeltraining through the Federated Averaging algorithm, which isan implementation of FL.

1) Mobility & Data sensing: Vehicles move according toa standard mobility model that is specific to each of the twocase studies. The first simulation uses the Random Waypoint(RWP) mobility model, whereas the second uses the ReferencePoint Group (RPG) mobility model. Moreover, training input

0 50 100 150 200Training step

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Mod

el a

ccur

acy

∈ [0

;1]

Model Accuracy per training stepVKN-orchestrated training - AccuracyTraditional training - Accuracy

7

8

9

10

11

12

13

14

15

Num

ber o

f sel

ecte

d tra

inin

g no

des p

er st

ep

VKN-orchestrated training - Selected nodesTraditional training - Selected nodesBandwidth saved through VKN orchestration

(a) Model Accuracy per Training Iteration

0 50 100 150 200Training step

0.50

0.75

1.00

1.25

1.50

1.75

2.00

2.25

Loss

Loss per training stepVKN-orchestrated trainingTraditional training

(b) Training Loss per Iteration

Fig. 9: Evaluation of VKN-orchestrated FL Performances for Case Study 1

Events TimelineT=0 T=1h

1 km

1 km

FL Coordinator

Training Interests Database

FL TrainingMNIST digits

dataset

Each event is associated with a single training inputSample 1 Sample 2 Sample n

...

750 vehicles

Fig. 10: Evaluation Setup for Case Study 2

sensing mechanisms are simulated differently in both cases,respectively a grid-based observation mechanism for the firstcase study and a rare events generation mechanism for thesecond.

2) Model Training: The FL coordinator holds the currentglobal state of the FEMNIST-based model to be trained. Thetraining is divided into sequential steps in which:

1. The coordinator samples a set of N = 10 vehicles towhich it transmits the current global state of the model.

2. Upon receiving the model:• If the vehicle holds training input for the model in its

local storage, a model update is locally computed andreturned to the coordinator.

• If not, the vehicle is not able to train the model due toa lack of training data, and discards the model.

3. After a simulated delay of ∆t = 15s, the coordinator ag-

gregates the model updates received for the current step.It then starts a new step and repeats until convergence.

3) VKN Orchestration: In both simulations, we comparethe efficiency of ’traditional’ FL as opposed to mobility-based VKN-orchestrated FL by analyzing model accuracy andtraining loss per training iteration. The VKN orchestrationprocess takes place at the training client selection level inthe coordinator. Thus, the difference between the traditionaland VKN-orchestrated approaches lies in the training vehiclesampling mechanism at each step.

On the one hand, in the traditional approach, no mechanismsare implemented to anticipate which vehicle is likely to holdwhich type of training information. At every training step, thecoordinator samples N = 10 randomly chosen vehicles toperform local model training.

On the other hand, in the VKN-orchestrated approach,vehicles inform the coordinator of their training environmentrespectively (i) every ∆t = 10s in case study 1 where thetrained model requires commonly observable input, and (ii)each time a relevant input is sensed in case study 2 wherethe trained model requires rarely sensed input. Thus, thecoordinator is fitted with a KB containing the last observedpertinent input of each vehicle if any, as well as the timeand location of sensing. Training environment informationis discarded from the coordinator’s KB after a timeout of∆t = 5min.

Using this contextual knowledge, the coordinator clustersthe training vehicles by the location of their last documentedtraining input sensing in N = 10 clusters using a K-Meansalgorithm. Then, the coordinator sends a model update to thevehicle having most recently filed a training environment itemin each of the N clusters. Through that clustering process, thecoordinator maximizes the diversity of training input, whilereducing the likelihood to request training to vehicles that donot possess the required input data.

25 50 75 100 125 150 175 200 225Training step

0.2

0.3

0.4

0.5

0.6

0.7

0.8

Mod

el a

ccur

acy

∈ [0

;1]

Model Accuracy per training step

VKN-orchestrated trainingTraditional training

(a) Model Accuracy per Training Iteration

25 50 75 100 125 150 175 200 225Training step

0.5

1.0

1.5

2.0

2.5

3.0

3.5

Loss

Loss per training stepVKN-orchestrated trainingTraditional training

(b) Training Loss per Iteration

Fig. 11: Evaluation of VKN-orchestrated FL Performances for Case Study 2

VII. PERFORMANCE EVALUATION

In this section, we describe the specific parameters ofthe simulations performed to represent each case study, anddiscuss evaluation results.

A. Case Study 1: Commonly observable input

Figure 8 illustrates the specific setup of Simulation 1.The vehicles in the simulation follow the RPG mobilitymodel. Mobility is divided into one major and nine minorgroups of vehicles. In order to represent commonly observabletraining input, the simulation area is divided into a gridof 10x10 cells. Each cell is permanently associated with asingle, constant training sample extracted from the digits-onlyFEMNIST dataset. Vehicles periodically sense the trainingsample associated with the cell they are located in, everyT = 10s of simulated time.

As described in the evaluation’s general setup, at eachstep, the coordinator performs clustering of potential trainingvehicles in order to select N = 10 clients most likely to featurediverse training input. In this case study, as an optimization,if two selected vehicles are separated by a distance of 50meters or less, one of them is discarded from the selection.Thus, in the VKN-orchestrated approach, for some trainingiterations, the number of selected vehicles can potentially bebelow N = 10.

Figure 9 shows the obtained result in terms of modelaccuracy and training loss per training iteration. The resultsare bounded by 95% confidence intervals obtained after av-eraging the results from S = 25 simulations. In this casestudy, orchestration resulted in: (i) a minor but consistentimprovements in terms of model accuracy of about 4% while(ii) reducing the amount of nodes selected for training to anaverage of 9 instead of 10 training vehicles per iteration. Thus,VKN orchestration combines improved training accuracy withreduced bandwidth usage in terms of model update exchanges.

As a trade off, vehicles inform the coordinator of their trainingenvironment every ∆t = 10s. Thus, the actual variationof bandwidth usage depends on the trained model and thedifference between the size of model updates and that oftraining environment messages. In complex neural networksmodels encoding numerous weights, the bandwidth savedthrough the reduction of model update exchanges is likelyto be significant over the overhead of training environmentmessages exchange.

B. Case Study 2: Sparsely Observable Input

Figure 10 illustrates the specific setup of Simulation 2.Vehicles in the simulation follow the RWP mobility model,with a pause probability of 0.5, a maximal pause duration of5 minutes, and a speed range of [5; 20]m/s. As the simulationaims to represent situations of sparsely observable traininginput, events are randomly generated within the simulationarea.

Events occur following a Poisson distribution at a constantmean rate of 1.5 events per simulated minute. Each eventhas a circular shape and appears in the simulated area fora limited amount of time. Namely, an event is composed of(i) a start time, (ii) a duration sampled from a normal lawN (60, 10) seconds, (iii) a center point sampled uniformly inthe simulated area, (iv) a radius r ∼ N (50, 1) meters, and (v)a single training data sample extracted from the digits-onlyFEMNIST dataset that passing vehicles will be able to sense.

Everytime a vehicle drives within the bounds of the circularrepresentation of an active event, the vehicle senses the train-ing data sample associated with the event and saves it in localstorage, erasing any previous sensing. Moreover, to accountfor existing vehicular database maintenance features [20], datasamples stored on-board vehicles are removed if:Time relevance The last sensed sample was obtained more

that 5min of simulated time ago.

Space relevance The last sensed sample was obtained morethan 500m away.

Figure 11 illustrates the obtained results in terms of modelaccuracy and training loss per training step. The results arebounded by 95% confidence intervals obtained after averagingthe results from S = 25 simulations. The orchestration of theFL training through VKN results in significant improvementsin terms of convergence time as well as model accuracy. Afterconvergence, the model training through VKN orchestrationshows a significance increase in label prediction accuracy ofabout 15%.

VIII. CONCLUSION

Federated Learning shows potential for knowledge creationand distribution in vehicular networks, while avoiding thetransfer of training data. However, the patterns of vehicu-lar mobility introduce specific challenges for FL, such asa dynamically evolving training environments for nodes invehicular networks. In this paper, we exemplified vehicularmobility-related challenges for FL through two complemen-tary case studies. On the one hand, models with commonlyobservable input require educated training node selection inorder to avoid over fitting models to a majority of inputsourced from main roads axes. On the other hand, modelsthat require rare observations as input, e.g. models studyingnear-crash events require communication between trainingnodes, to avoid requesting model updates to vehicles thatdo not own the required input data. We introduce VehicularKnowledge Networking as a candidate framework to answerneeds of mobility-based orchestration in vehicular FL. Fi-nally, we evaluate the described approach by running twocomplementary simulations representing each case study. Weobserve that mobility-based FL orchestration through VKN ledto improvements in terms of model training speed and modelaccuracy, as opposed to unorchestrated training.

REFERENCES

[1] Sebastian Caldas et al. LEAF: A Benchmark for Feder-ated Settings. 2019. arXiv: 1812.01097 [cs.LG].

[2] István Hegedus, Gábor Danner, and Márk Jelasity.“Gossip Learning as a Decentralized Alternative toFederated Learning”. In: Distributed Applications andInteroperable Systems. Ed. by José Pereira and LauraRicci. Cham: Springer International Publishing, 2019,pp. 74–90.

[3] L. Giaretta and Š. Girdzijauskas. “Gossip Learning: Offthe Beaten Path”. In: 2019 IEEE International Confer-ence on Big Data (Big Data). 2019, pp. 1117–1124.

[4] Ahmed Imteaj et al. Federated Learning for Resource-Constrained IoT Devices: Panoramas and State-of-the-art. 2020. arXiv: 2002.10610 [cs.LG].

[5] Wei Yang Bryan Lim et al. Federated Learning inMobile Edge Networks: A Comprehensive Survey. 2019.arXiv: 1909.11875 [cs.NI].

[6] Takayuki Nishio and Ryo Yonetani. “Client Selectionfor Federated Learning with Heterogeneous Resourcesin Mobile Edge”. In: ICC 2019 - 2019 IEEE Inter-national Conference on Communications (ICC) (May2019).

[7] Luping Wang, Wei Wang, and Bo Li. “CMFL: Miti-gating Communication Overhead for Federated Learn-ing”. In: 2019 IEEE 39th International Conferenceon Distributed Computing Systems (ICDCS) (2019),pp. 954–964.

[8] Richeng Jin, Xiaofan He, and Huaiyu Dai. On theDesign of Communication Efficient Federated Learn-ing over Wireless Networks. 2020. arXiv: 2004.07351[cs.LG].

[9] Jinjin Xu et al. Ternary Compression forCommunication-Efficient Federated Learning. 2020.arXiv: 2003.03564 [cs.LG].

[10] Eugene Bagdasaryan et al. How To Backdoor FederatedLearning. 2018. arXiv: 1807.00459 [cs.CR].

[11] Z. Li, V. Sharma, and S. P. Mohanty. “PreservingData Privacy via Federated Learning: Challenges andSolutions”. In: IEEE Consumer Electronics Magazine9.3 (2020), pp. 8–16.

[12] B. Swenson et al. “Distributed Gradient Descent: Non-convergence to Saddle Points and the Stable-ManifoldTheorem”. In: 2019 57th Annual Allerton Conferenceon Communication, Control, and Computing (Allerton).2019, pp. 595–601.

[13] S. Wang et al. “Adaptive Federated Learning in Re-source Constrained Edge Computing Systems”. In:IEEE Journal on Selected Areas in Communications37.6 (2019), pp. 1205–1221.

[14] Yuan Liu et al. FedCoin: A Peer-to-Peer Payment Sys-tem for Federated Learning. 2020. arXiv: 2002.11711[cs.CR].

[15] Han Yu et al. “A Fairness-Aware Incentive Scheme forFederated Learning”. In: Proceedings of the AAAI/ACMConference on AI, Ethics, and Society. AIES ’20. NewYork, NY, USA: Association for Computing Machinery,2020, pp. 393–399. ISBN: 9781450371100.

[16] Ahmet M. Elbir, Burak Soner, and Sinem Coleri. Fed-erated Learning in Vehicular Networks. 2020. arXiv:2006.01412 [eess.SP].

[17] S. Roychowdhury et al. “Machine Learning Modelsfor Road Surface and Friction Estimation using Front-Camera Images”. In: 2018 International Joint Confer-ence on Neural Networks (IJCNN). 2018, pp. 1–8.

[18] Osama A. Osman et al. “Prediction of Near-Crashesfrom Observed Vehicle Kinematics using MachineLearning”. In: Transportation Research Record 2673.12(2019), pp. 463–473.

[19] Duncan Deveaux et al. A Definition and Framework forVehicular Knowledge Networking. 2020. arXiv: 2005.14505 [cs.NI].

[20] ETSI EN 302 895 V1.1.1 : Intelligent Transport Systems(ITS); Vehicular Communications; Basic Set of Appli-cations; Local Dynamic Map (LDM). Sept. 2014.