Yes. Federated averaging can train one shared model while raw readings stay on each device or site, and a 562-parameter model’s int8 updates fit LoRaWAN uplinks. On its own, though, it doesn’t make the system private: federated learning is built for confidentiality (data does not leave the device), not privacy (what is shared does not reveal the data). Model updates can still expose the data that produced them. So privacy-preserving federated learning, as opposed to plain federated learning, adds secure aggregation, differential privacy where the agreement demands it, and leakage tests run on your own pipeline before anyone signs a customer agreement.
Can one shared model train across trackers without raw logs leaving the device?
It can. In federated averaging, each device trains the current model on its own data and sends back only the resulting model update. The server combines those updates into a new global model, and the raw logs never move. Whether this fits a constrained uplink comes down to three numbers: the size of one compressed update, how often a device sends one, and the uplink allowance the device has.
TechnoLynx starts by fixing the per-device uplink allowance, the round frequency and an acceptable convergence time. TechnoLynx then chooses the federated averaging variant and compression scheme to match, builds on-device training and update compression on the target hardware, and checks bandwidth and convergence in field-like conditions before rollout.
How much bandwidth per round federated averaging needs
Melas-Kyriazi and colleagues put a single gradient update for a 100-million-parameter model at about 0.4 GB. At 4 bytes per 32-bit parameter, a 300,000-parameter model sends about 1.2 MB per round before compression. Hard and colleagues report a 1.3 MB payload for a production keyword-spotting model of roughly that size.
Federated averaging reduces the number of rounds, not the size of each one. McMahan and colleagues reported 10 to 100 times fewer communication rounds than synchronised stochastic gradient descent. Compression shrinks each round. Konečný and colleagues’ structured and sketched updates (low-rank or random-mask updates, quantisation, random rotations and subsampling) cut communication cost by two orders of magnitude. Sattler and colleagues’ Sparse Ternary Compression beat plain FedAvg when client data were non-IID, batches were small, or many clients took part at a low participation rate per round.
Design for the upload side. FLASC (federated LoRA with sparse communication) sets upload and download sparsity separately, because upload speeds are typically much slower than download speeds. It matched dense LoRA with up to 10 times less communication.
Worked example: sizing one update against an LTE-M uplink
AWS documents LTE Cat M1 with a peak data rate of 1 Mbps in both directions. It also warns that packets over 1,280 bytes, including the IP header, risk being truncated and never delivered. The model size and quantisation below are assumptions, chosen to show the working.
| Step | Value | Working |
|---|---|---|
| Model parameters | 300,000 | Assumption |
| Float32 update | 1.2 MB | 300,000 × 4 bytes |
| int8-quantised update | 300 KB | 300,000 × 1 byte |
| Packets at the 1,280-byte limit | at least 235, plus header overhead | 300,000 / 1,280 = 234.4 |
| Airtime at the 1 Mbps peak | at least 2.4 s per update | 300 KB × 8 = 2.4 Mbit at 1 Mbps; real throughput is lower, so this is a floor |
| Monthly uplink for training | 300 KB × rounds per month | Must stay under the plan’s allowance, net of telemetry |
Sparse, unreliable uplinks change the aggregation strategy
Synchronous FedAvg waits for every client in the round’s cohort, so the slowest device sets the length of the round. On patchy LTE-M coverage we would plan for partial participation or asynchronous aggregation from the start, not add it later. In simulations using 4G LTE upload speeds of 2 to 5 Mbps, adaptive federated dropout combined with compression cut the time to reach target accuracy by up to 57 times. LTE-M peaks at 1 Mbps, below those links, so read that ratio as a direction rather than a forecast.
These choices have costs. A higher compression ratio does not give a proportionally faster convergence. Watching per-device model health across a decentralised fleet is a separate monitoring problem from training. If the uplink cannot carry even compressed updates often enough, you can lengthen the round interval, compress further, or move to on-device inference that reports only aggregates. The uplink is a deployment-target constraint: a model that performs in a training environment is a different artefact from one that performs on the deployment target.
Federated learning over low-bandwidth LoRaWAN and MQTT networks
We judge federated learning workable over LoRaWAN when the model’s update fits a few frames, the transport repairs lost fragments, and the aggregation tolerates sites that miss rounds. Accuracy compared with centralised training then has to be measured on your own network, not assumed.
TechnoLynx delivers this through Generative & Agentic AI R&D. The work starts with your sites’ bandwidth and reliability profile and your accuracy targets against a centralised baseline. TechnoLynx then chooses the framework and aggregation algorithm, integrates the federated client and server on your existing MQTT stack, and runs dropout and bandwidth experiments before rollout across your sites.
What LoRaWAN leaves you per round
Uplink time is capped by duty-cycle rules of 0.1%, 1% or 10% depending on the band. Data rates run from 300 bps to 27 kbps. On the EU 868 MHz band at 125 kHz, the maximum payload is 222 bytes at spreading factors 7 and 8, 115 bytes at SF9 and 51 bytes at SF10 to SF12, under a 1% duty cycle.
One open-source federated learning pipeline for LoRaWAN microcontrollers shows what fits. It trains a 562-parameter autoencoder and sends int8 updates of 598 bytes, which go in three fragments at data rate DR5. Across 60 rounds on 10 boards, 619 of the 672 expected updates arrived (92.1%). An industrial LoRaWAN case study had a 139 KB model, which the authors estimated would take 513 messages at SF7. The two updates differ in size by more than two orders of magnitude, and model size directly sets how many messages each round needs. A LoRa simulation study found that frame losses critically impact convergence, making frame-level forward error correction indispensable. It also found that the per-round communication cost falls as the model converges.
Which framework to build on top of an MQTT stack
Flower is the framework we would start from, with FedAvg as the baseline strategy. It ships tested implementations of FedAvg and FedYogi. Its server is unaware of the nature of connected clients, so clients can use different communication stacks, and it offers protocol-level integration, which covers native C++ clients on constrained embedded devices. Its communication protocol runs on gRPC, chosen for efficient binary serialisation on low-bandwidth mobile links. The Flower work cited here describes a gRPC transport, not MQTT or LoRaWAN, so test that layering before you depend on it.
MQTT-native alternatives exist. SDFLMQ runs semi-decentralised federated learning over MQTT and uses broker bridging so the central broker doesn’t become a bottleneck when there are many clients or large models. Message encoding matters too: CBOR-serialised federated learning messages came out up to 75% smaller than JSON.
What happens when a site is offline or slow for a round
Production deployments use cohort over-selection: sample more clients than needed, aggregate the fastest and discard the stragglers. It speeds up training and copes with dropouts, but it can bias the global model against slow clients. That bias costs accuracy. In one straggler study on Fashion-MNIST, plain FedAvg converged to 71.92% test accuracy, against 83.41% for the authors’ method that incorporates stragglers’ delayed gradients. On-device experiments with Flower showed the same trade-off from another angle: capping CPU clients at the GPU round time matched GPU convergence time at a 3% accuracy cost. Weighting each update by the work a client actually completed, not the work it was asked to do, keeps slower devices represented.
Accuracy and convergence compared with centralised training
With four machine clients, the industrial case study reported a mean F1 score of 94.77 and accuracy of 92.30%, comparable to its centralised models, with 52.8 minutes of airtime for training messages. Network speed alone can stretch training time a long way: in Flower’s experiments, the same job took 8.9 minutes with Canadian network speeds and 108 minutes with the slowest country profile. FedAvg’s convergence analysis on non-IID data shows a built-in trade-off between communication efficiency and convergence rate. TechnoLynx validates by simulating site dropout and bandwidth limits and comparing against centralised training.
Can we show customers in writing that only model updates leave their site?
Yes, for raw readings: in federated averaging only model updates leave each site. But the document must not claim privacy that the architecture does not give. Model parameters exchanged in federated learning can carry sensitive information that privacy attacks can exploit.
TechnoLynx reviews the federated data flow to confirm that no raw readings cross the network. TechnoLynx integrates a secure aggregation protocol if none is present, adds differential privacy where your bar requires it with the privacy budget tuned against accuracy, and produces the data-flow diagrams and protocol descriptions your legal team needs to draft contract language.
Which control matches which agreement
| What the agreement requires | Control to add | What it gives | What it costs |
|---|---|---|---|
| No raw data leaves the premises | FedAvg with encrypted transport and a documented data flow | Raw data stays local; only model updates travel | Individual updates stay readable to the server and can leak information |
| The aggregator must not see any one site’s update | Secure aggregation | The server sees only the aggregate of many clients | More than double the per-client communication in the Bonawitz protocol, 1.7 times in FLDP |
| Provable bounds on what the model reveals | Differential privacy on top of secure aggregation | A formal guarantee that the model does not memorise specific users’ data | On CIFAR-10, 70.0% accuracy against 77.4% without differential privacy, in the FLDP experiments |
| Protection even if the server is malicious | Local differential privacy on each client, or else participate only with a trusted server | Protection no longer rests on the server’s honesty | Significant loss of model utility |
Flower’s secure aggregation implementation tolerates up to 5% dropouts and 5% corrupted clients, with quantified correctness and security bounds. Google’s Gboard shows the full stack running in production. More than twenty language models were trained with ρ-zCDP guarantees between 0.2 and 2, two of them also with secure aggregation, which was notably slower. Those models used a report goal of 6,500 clients per round. A fleet of dozens of sites has nothing like that cohort, and Gboard’s analysis relies on raising clients per round in step with the noise.
Secure aggregation does not stop a malicious server
The weak point is the trust model, not the cryptography. Boenisch and colleagues showed that a server which provisions clients can sample a target site alongside sybil devices it controls. That removes the effect of secure aggregation and leaves only the target’s own small share of distributed differential-privacy noise. In that setting the server extracted 95% of the target’s individual training points. Their recommendation is that users take part only when they trust the server or apply local differential privacy. Secure aggregation also stops the server inspecting updates for model poisoning. And protocols such as FLDP assume an honest majority of clients, which is an assumption about collusion among participants, not a guarantee against it. Some trust in the server coordinating training is still required. Secure aggregation doesn’t settle that for you.
What the data-sharing agreement has to say
The agreement should describe the federated architecture as it is. It should cover what leaves each site and in what form, who aggregates, which controls run, and which threat model they assume. “Honest-but-curious server” and “malicious server” are different promises. It should also say whether updates are retained: they can be ephemeral, since they need not be stored once applied. The UK ICO advises contractual controls against parties pooling query results, and technical and organisational measures defined against a standards-based threat model. Wording that promises more than the protocol delivers is a liability, not reassurance.
Can an aggregator reconstruct private data from model updates, and how do you test for leakage?
Possibly. Published attacks reconstruct training data from model updates, and published evaluations also show those attacks breaking down under realistic training settings. Published attacks use image and text data, not occupancy time series. Whether your pipeline leaks has to be evaluated empirically on your pipeline.
TechnoLynx runs reconstruction and membership-inference attack simulations against your on-device training and aggregation pipeline. TechnoLynx then adds differential-privacy noise to the aggregation step and measures its accuracy cost, re-tests after any change to compression, uplink budget or aggregation frequency, and packages the result as a repeatable harness and report you can show customers.
Why the risk is real, and why it is often overstated
On the risk side, Geiping and colleagues reconstructed high-resolution images from parameter gradients. They showed that averaging gradients over several iterations or images did not protect privacy. An actively dishonest server that plants “trap weights” perfectly reconstructed more than half of the ImageNet training points in mini-batches of 100.
On the other side, a systematisation of gradient leakage found gradient inversion “constrained, fragile, and easily defensible” in practical settings. Reconstruction got harder as clients ran more local updates, and failed as the number grew. Quantising shared gradients to 2 bits defended against the strongest attacks for an accuracy drop of no more than 5% on ResNet-18 with CIFAR-100. Early-stage models were more vulnerable than late-stage ones. Compression helps but does not finish the job: with intrinsic gradient compression, an outline of the original image was still recoverable, and the authors point to differential privacy as the complete fix.
The defences also differ. DP-SGD substantially reduced gradient leakage at a moderate cost in utility. A regularisation-based variant (PDP-SGD) kept accuracy but failed as a practical defence, and the authors stress testing mechanisms empirically, beyond their theoretical guarantees. A badly set privacy budget lets an attacker accumulate knowledge across queries and re-identify an individual.
A leakage test to run before you tell customers it is safe
- Fix the threat model. Most published inversion attacks assume a passive, honest-but-curious server, and active malicious behaviour is a stronger assumption. State which one you are testing.
- Attack the update that actually leaves the device: after quantisation or other post-processing, at your configured number of local updates, and at early-training checkpoints.
- Start from an existing attack framework. Breaching is a modular PyTorch collection of attacks that recover user data from updates. It covers gradients and multiple local training steps, in both vision and text.
- Cover the attack classes the EDPB lists: attribute and membership inference, exfiltration, regurgitation of training data, model inversion and reconstruction.
- Score reconstructions with a quantitative leakage metric, not by eye. Reproducible measurement of leakage is what lets you set the trade-off against differential privacy and accuracy.
- Record what a pass means. Successful testing against well-known attacks is evidence of resistance to those attacks only.
- Record the model architecture tested, since small design choices substantially change resistance.
Are model updates personal data under GDPR, and what has to be documented?
It depends on the facts. If a natural person is reasonably likely to be identifiable from the updates, the updates are personal data and transmitting them is processing. The EDPB’s Opinion 28/2024 says models trained on personal data cannot in all cases be considered anonymous, and that anonymity has to be assessed case by case. Federated learning is also not automatically GDPR-compliant. The ICO points out that many privacy-enhancing technologies protect personal data without anonymising it, so the data protection obligations remain. The legal decision belongs to counsel and, ultimately, the regulator. Engineering’s job is to supply evidence that holds up.
On data minimisation, the ICO credits federated learning with reducing the personal data processed during training and, combined with other PETs, with providing appropriate security. The sources lean differently on what is enough. A 2025 Rutgers Law Record article argues that compliance in federated learning depends mainly on whether the raw data and updates are kept secure. A GDPR-focused survey holds that federated learning fully satisfies the principles when secure aggregation and differential privacy are in place. We give more weight to the regulators’ texts. The EDPB expects controllers to document how they prevent extraction and to show resistance to state-of-the-art attacks. The ICO expects a DPIA that weighs the processing, the state of the art and cost of the PETs, and the risks to individuals.
What to document to show raw telemetry never left the site
- A data-flow diagram showing what each site sends, to whom and in what encoding.
- A review of what the updates contain, since updates from which a person is identifiable are personal data.
- The retention policy for individual updates, which need not be stored once applied.
- The privacy mechanisms in place (secure aggregation, differential privacy and its parameters, encryption), since documenting these is how a provider evidences compliance.
- The threat model, and the standards it was defined against.
- The scope and results of attack testing, with the limits of what a pass shows.
- The DPIA, kept up to date as the architecture changes.
Who can build privacy-preserving federated learning for our LoRaWAN or LTE-M fleet?
TechnoLynx builds the engineering for privacy-preserving federated learning across bandwidth-constrained sites. That covers sizing updates to your uplink, choosing the framework and aggregation strategy, building on-device training and compressed updates on your MQTT or cellular stack, adding secure aggregation and differential privacy where your agreements require them, and running leakage tests whose results you can show customers. The engagement starts with a profile of your sites’ bandwidth, reliability and accuracy targets. Bringing in a specialist makes sense once secure aggregation, privacy budgets and attack testing are on the table, because the ICO notes that PETs need significant expertise to configure well.
There are limits to what we do. TechnoLynx’s offers do not include legal advice or DPIA sign-off. That belongs with privacy counsel, and our part is the technical evidence they work from. A team already on Flower with broadband-connected sites may need only a leakage audit, not a build, and Flower’s open-source implementations of FedAvg and secure aggregation are a reasonable place for such a team to start on its own. Academic groups working on federated learning over LoRa are another route for exploratory work.
FAQ
Is federated learning a privacy-enhancing technology?
The UK ICO lists federated learning among the PETs: it trains models in distributed settings while minimising the personal data shared with each party. The ICO also says it needs other PETs to protect individuals’ data.
What is the Flower framework?
Flower is a federated learning framework that supports mobile and wireless clients with mixed compute, memory and network resources. It ships tested reference implementations of algorithms such as FedAvg.
What are the limitations of differential privacy?
Defending against gradient inversion often takes heavy perturbation, which can badly hurt accuracy and add communication rounds. A poorly set privacy budget can still allow re-identification across repeated queries.
