Réseau WiFi ferroviaire : Comment les opérateurs fournissent une connectivité à grande vitesse

Ce guide de référence technique fournit des informations exploitables aux responsables informatiques, aux architectes réseau et aux directeurs des opérations de transport sur l'architecture et le déploiement de réseaux WiFi ferroviaires fiables. Il couvre l'ensemble de la pile, de l'infrastructure en bord de voie et de l'agrégation multi-support à la gestion de la bande passante, aux captive portals et à l'analyse des passagers. Le guide montre comment les opérateurs peuvent cesser de considérer le WiFi embarqué comme un centre de coûts et plutôt l'exploiter comme un atout stratégique générant des données de première partie, de l'intelligence opérationnelle et un ROI mesurable.

📖 7 min de lecture📝 1,698 mots🔧 2 exemples❓ 4 questions📚 9 termes clés

🎧 Écouter ce guide

Voir la transcription

Welcome to another technical briefing. Today, we're looking at one of the most challenging environments for enterprise networking: the railway WiFi network. We're talking about delivering high-speed, reliable connectivity to hundreds of concurrent users, on a metal tube travelling at 125 miles per hour.

I'm your host, and over the next ten minutes, we're going to break down how operators are actually doing this today — looking at the lineside infrastructure, the onboard aggregation, and the critical role of captive portals and analytics in managing the passenger experience.

Let's set the context. For IT managers and CTOs in the transport sector, passenger WiFi is no longer a nice to have — it's a baseline expectation. But the physics of a moving train make standard deployments impossible. You're dealing with constant cell tower handoffs, Doppler shift, Faraday cage effects from the train carriages, and massive bandwidth spikes when a train pulls into a station.

So, how do we architect a solution that works?

Let's dive into the technical deep-dive.

The architecture of a modern railway WiFi network is split into three main components: the trackside or lineside network, the onboard train network, and the core network or cloud Network Operations Centre.

First, the backhaul. Most modern deployments rely on a multi-bearer approach. You aren't just putting a 4G SIM in a router. You are using an onboard multi-SIM aggregation gateway. This device bonds multiple cellular connections — often across different carriers like EE, Vodafone, and O2 in the UK — to create a single, aggregated pipe. When the train moves through a dead zone for one carrier, the others pick up the slack. This is essential for failover and seamless roaming.

But cellular alone isn't always enough, especially on high-density commuter routes. That's where dedicated lineside infrastructure comes in. Operators are increasingly deploying their own trackside, track-to-train radio networks, using technologies like millimetre wave or dedicated 5G spectrum, firing a signal directly down the track to receivers on the front and rear of the train.

Once the signal is on the train, it's distributed via a standard enterprise-grade local area network. You'll have a switch in each carriage, connecting to high-density Wi-Fi 6 access points. The access points need to be ruggedised — often with M12 connectors, compliant with EN 50155 standards for railway electronic equipment — to handle the vibration and temperature fluctuations.

Now, let's talk about the passenger experience and the captive portal. This is where the network meets the user, and it's where a platform like Purple becomes critical.

When a user connects to the onboard access point, they are redirected to a captive portal. This isn't just a splash page; it's a gateway for authentication, bandwidth management, and data collection.

Because bandwidth is finite on a moving train, the captive portal enforces fair usage policies. You might cap users at 5 megabits per second to ensure everyone can check email, while blocking high-bandwidth streaming services like Netflix or large operating system updates.

Furthermore, the portal is your primary mechanism for capturing first-party data. By requiring an email login or social authentication, the operator can build a rich database of passenger demographics and travel patterns. This data feeds into the analytics dashboard.

Speaking of analytics, let's move to implementation recommendations and pitfalls.

The biggest pitfall I see is operators treating the onboard network as a dark box. You deploy it, and you only know it's broken when passengers complain on social media.

You need real-time analytics. A platform like Purple's Guest WiFi analytics allows the Network Operations Centre to see exactly what's happening. How many concurrent devices? What's the bandwidth utilisation per carriage? Are we seeing high latency on the backhaul?

By mapping the GPS data of the train against the network performance metrics, operators can identify physical dead zones on the route and work with carriers to optimise coverage.

Another recommendation: security. You must implement client isolation on the access points so passengers cannot see each other's devices. And for the portal, ensure strict GDPR compliance with clear opt-ins for marketing data.

Let's do a rapid-fire question and answer session based on common client questions.

Question one: Can we support OpenRoaming on trains?

Yes, and it's highly recommended. Passpoint or OpenRoaming allows seamless, secure authentication without the user interacting with a captive portal every time. Purple acts as a free identity provider for OpenRoaming, making this a very viable upgrade path.

Question two: How do we handle the station surge?

When a train pulls into a station, hundreds of devices suddenly connect to the station's macro-cellular network, causing interference and capacity issues. The solution is often to configure the train's access points to hand off to the station's dedicated high-capacity WiFi network when at the platform, saving the cellular backhaul.

Question three: What's the biggest mistake operators make when scoping a railway WiFi project?

Underestimating the importance of the software layer. Most operators spend 80 percent of their planning time on the hardware and RF engineering, and only 20 percent on the captive portal, analytics, and management platform. In reality, the software is where you generate the return on investment. Get the hardware right, but invest equally in the platform.

To summarise and wrap up: Delivering WiFi at speed requires robust multi-SIM aggregation, ruggedised onboard hardware, and strict bandwidth management via a captive portal. But the real value for the operator comes from the analytics — turning a cost centre into a source of first-party data and operational intelligence.

If you're planning a deployment, focus on the analytics and the user journey just as much as the RF engineering.

Thanks for joining this technical briefing. Until next time.

Points clés à retenir

✓Moving trains present unique networking challenges including constant cell tower handoffs, Faraday cage effects, Doppler shift at high speeds, and unpredictable bandwidth demand spikes.
✓A multi-SIM aggregation gateway bonding connections from multiple MNOs is the single most important architectural decision — it provides the failover resilience that a single-carrier solution cannot.
✓All onboard hardware must meet EN 50155 standards with M12 industrial connectors to survive the vibration, temperature extremes, and mechanical stress of a railway environment.
✓A redundant ring LAN topology is essential for the onboard network — a daisy-chain approach creates unacceptable single points of failure at every inter-carriage connection.
✓Captive portals are not just a user experience layer — they are the bandwidth management engine, the GDPR compliance mechanism, and the first-party data capture tool that drives commercial ROI.
✓Integrating WiFi with a cloud analytics platform like Purple transforms the onboard network from a cost centre into a source of operational intelligence, carrier accountability data, and passenger marketing capability.
✓Proactive NOC monitoring overlaid with GPS train position data is the only way to identify coverage gaps before passengers experience them and to hold MNOs accountable to contracted SLAs.

Résumé Exécutif

Fournir un WiFi fiable dans les trains en mouvement est l'un des défis les plus complexes du réseau d'entreprise. Pour les responsables informatiques, les architectes réseau et les directeurs des opérations de site, la connectivité des passagers n'est plus un luxe — c'est une attente fondamentale qui impacte directement la satisfaction client et la perception de la marque.

Ce guide décrit l'architecture technique requise pour maintenir une connectivité à grande vitesse à 125 mph, en gérant les transferts constants entre antennes cellulaires, les effets de cage de Faraday des wagons métalliques et les densités d'utilisateurs fluctuantes. Nous explorons la transition des simples routeurs cellulaires vers les passerelles d'agrégation multi-support et l'infrastructure dédiée en bord de voie. De manière cruciale, nous examinons comment les opérateurs peuvent utiliser les captive portals et les plateformes d'analyse — telles que Guest WiFi et WiFi Analytics — pour gérer la bande passante, assurer la conformité GDPR et extraire des données de première partie exploitables. En traitant le réseau embarqué non seulement comme un centre de coûts, mais comme un atout stratégique, les opérateurs de transport peuvent générer un ROI significatif tout en répondant aux exigences numériques du passager moderne.

Approfondissement Technique

L'architecture d'un réseau WiFi ferroviaire exige un changement fondamental par rapport à la conception statique d'un LAN d'entreprise. Le réseau doit combler le fossé entre un environnement local en mouvement rapide et le backhaul internet central, tout en maintenant la continuité de session pour des centaines d'utilisateurs simultanés.

L'Architecture de Backhaul Multi-Support

S'appuyer sur un seul fournisseur cellulaire est insuffisant pour un train en mouvement. Les déploiements modernes utilisent une passerelle d'agrégation multi-SIM (ou routeur multi-support) installée dans le train. Ce dispositif agrège simultanément les connexions de plusieurs opérateurs de réseaux mobiles (MNOs) sur les réseaux 4G et 5G.

Lorsque le train traverse différentes zones de couverture, l'agrégateur achemine dynamiquement le trafic sur les liens disponibles en fonction des métriques de latence en temps réel, de perte de paquets et de force du signal. Si un opérateur perd le signal dans un tunnel ou une tranchée rurale, les autres maintiennent la session, offrant une bascule transparente sans interruption perceptible pour le passager. C'est la décision architecturale la plus importante dans tout déploiement WiFi ferroviaire.

Infrastructure en Bord de Voie (Voie-vers-Train)

Pour les lignes de banlieue à forte densité où les réseaux cellulaires publics deviennent congestionnés aux heures de pointe, les opérateurs investissent dans une infrastructure dédiée en bord de voie. Cela implique le déploiement d'antennes le long de la voie — généralement à des intervalles de 500 mètres à 2 kilomètres selon la technologie — qui transmettent un signal dédié utilisant le spectre mmWave ou 5G propriétaire directement aux récepteurs montés à l'extérieur des wagons de train.

Cette approche contourne entièrement la congestion cellulaire publique, offrant un débit garanti. Le compromis est un investissement en capital significatif dans la construction le long de la voie, mais pour les lignes interurbaines à revenus élevés, le cas d'affaires est convaincant. Une considération clé est l'effet Doppler : à des vitesses supérieures à 100 mph, la fréquence radio perçue par le récepteur diffère de la fréquence transmise, nécessitant un équipement radio spécialisé conçu spécifiquement pour les scénarios de mobilité à grande vitesse.

Distribution Embarquée et Normes Matérielles

Une fois le backhaul sécurisé, le signal est distribué via un backbone Ethernet embarqué vers des points d'accès sans fil (APs) dans chaque wagon. Le matériel déployé dans les trains doit respecter des normes environnementales strictes, spécifiquement la norme EN 50155. Cette norme dicte les exigences pour les équipements électroniques utilisés sur le matériel roulant, assurant leur résilience contre les variations de température extrêmes (généralement -25°C à +70°C), l'humidité, les chocs et les vibrations.

Les APs nécessitent généralement des connecteurs industriels M12 plutôt que des ports RJ45 standard pour éviter les déconnexions dues aux vibrations. Le Wi-Fi 6 (802.11ax) est désormais la norme recommandée pour les nouveaux déploiements, offrant des performances améliorées dans les environnements à haute densité grâce à des technologies comme l'OFDMA et le BSS Colouring.

La topologie du LAN embarqué est tout aussi importante. Une approche en guirlande (daisy-chain) crée des points de défaillance uniques à chaque connexion inter-wagon. L'architecture recommandée est une topologie en anneau redondant, où une rupture dans un segment de câble est automatiquement contournée en acheminant le trafic dans la direction opposée autour de l'anneau.

Guide d'Implémentation

Le déploiement d'un service WiFi ferroviaire exige une planification minutieuse et une exécution par phases. Les étapes suivantes fournissent un cadre pratique pour les équipes informatiques.

Étape 1 : Étude RF et Évaluation du Backhaul

Avant la sélection du matériel, réalisez une étude RF complète de l'ensemble de l'itinéraire ferroviaire. Cartographiez la force du signal et le débit de données de tous les principaux MNOs le long de la voie à des moments représentatifs de la journée. Identifiez les zones blanches — tunnels, tranchées profondes, tronçons ruraux — où la couverture cellulaire disparaît complètement. Ces données informent directement la configuration des cartes SIM pour les passerelles d'agrégation et mettent en évidence les endroits où un investissement dans l'infrastructure en bord de voie pourrait être justifié.

Étape 2 : Approvisionnement et Installation du Matériel

Sélectionnez du matériel conforme à la norme EN 50155 auprès de fournisseurs ayant fait leurs preuves dans les déploiements ferroviaires. Installez l'agrégateur multi-SIM dans une armoire de communication sécurisée et ventilée, généralement dans le wagon de tête ou de queue. Faites passer un câblage résilient — des anneaux Ethernet doubles redondants utilisant un câble de qualité industrielle — à travers les wagons jusqu'aux APs. Enles antennes extérieures sont profilées aérodynamiquement et scellées selon la norme IP67 ou supérieure contre les intempéries.

Étape 3 : Configuration du Captive Portal et de la gestion de la bande passante

C'est le point d'intégration critique où l'infrastructure rencontre l'expérience passager. Vous ne pouvez pas offrir une bande passante illimitée dans un train ; le backhaul est une ressource finie et partagée. Mettez en œuvre une solution de Captive Portal pour appliquer les politiques d'utilisation équitable (FUP).

La limitation de débit plafonne les vitesses individuelles des utilisateurs — généralement 5 Mbps en téléchargement — pour garantir un accès équitable à tous les appareils connectés. Le Traffic Shaping bloque ou réduit le débit des applications à forte consommation de bande passante telles que le streaming 4K ou les mises à jour logicielles volumineuses, en priorisant la navigation web, les e-mails et la VoIP. L'authentification via le portail capture les données des passagers (adresse e-mail, connexion sociale) en pleine conformité avec le GDPR, les alimentant dans votre plateforme d'analyse.

Étape 4 : Intégration et surveillance du NOC

Intégrez le réseau embarqué à un centre d'opérations réseau (NOC) basé sur le cloud. Configurez des alertes en temps réel pour l'état des points d'accès (AP), les seuils de latence du backhaul et les événements de basculement de SIM. Superposez les données de position GPS du train avec les métriques de performance réseau pour créer une carte de qualité du signal au niveau de l'itinéraire. C'est la base d'une gestion proactive plutôt que d'une gestion réactive des plaintes.

Bonnes pratiques

Mettez en œuvre l'isolation des clients sur tous les points d'accès (AP). Assurez-vous que les appareils des passagers ne peuvent pas communiquer directement entre eux sur le réseau local. Cela atténue le risque d'attaques peer-to-peer, d'exploits de type "man-in-the-middle" et de propagation de logiciels malveillants sur le LAN embarqué. C'est une base de sécurité non négociable pour tout réseau public.

Adoptez OpenRoaming pour réduire la friction du portail. Pour améliorer l'expérience des passagers réguliers, prenez en charge Passpoint et OpenRoaming (IEEE 802.11u). Cela permet aux appareils compatibles de s'authentifier de manière sécurisée et automatique sans interagir avec un Captive Portal à chaque trajet. Purple agit comme un fournisseur d'identité gratuit pour les services OpenRoaming, ce qui en fait une voie de mise à niveau viable pour les opérateurs utilisant déjà la plateforme. Pour plus de contexte sur les fondamentaux de la sécurité réseau, consultez Protégez votre réseau avec un DNS et une sécurité robustes .

La surveillance proactive est non négociable. Ne vous fiez pas aux plaintes des passagers pour identifier les pannes. Intégrez le réseau embarqué à un NOC cloud pour surveiller la disponibilité, la latence du backhaul et l'état des points d'accès (AP) en temps réel. L'objectif est d'identifier et de résoudre les problèmes avant que le premier passager ne les remarque.

Considérez le Captive Portal comme un produit, pas comme un utilitaire. Le portail est votre principal point de contact avec le passager. Investissez dans une expérience de marque, à chargement rapide, qui communique clairement les conditions de service et l'utilisation des données. Un portail mal conçu crée des frictions et réduit les taux d'authentification, ce qui a un impact direct sur la qualité de vos données de première partie.

Dépannage et atténuation des risques

L'effet de surtension en gare

Le risque : Lorsqu'un train entre dans une gare très fréquentée, des centaines d'appareils embarqués peuvent tenter simultanément de se connecter au réseau macro-cellulaire de la gare ou au WiFi public de la gare, provoquant de graves interférences, une saturation du backhaul et une expérience dégradée pour tous les passagers.

Atténuation : Configurez les points d'accès (AP) embarqués pour qu'ils basculent dynamiquement leur backhaul du réseau cellulaire vers une liaison WiFi ou fibre dédiée à haute capacité sur le quai de la gare. Utilisez la géolocalisation ou des déclencheurs GPS pour ajuster automatiquement les politiques de bande passante lorsque le train est stationnaire dans un hub majeur, en levant temporairement les plafonds par utilisateur lorsque la capacité du backhaul est effectivement illimitée.

Pannes de câblage inter-voitures

Le risque : Les connexions physiques entre les voitures sont soumises à des contraintes mécaniques, des vibrations et des mouvements constants lors des opérations d'attelage et de dételage, entraînant une dégradation des câbles et une segmentation du réseau.

Atténuation : Mettez en œuvre une topologie en anneau redondante pour le LAN embarqué en utilisant des commutateurs conformes à la norme EN 50155 avec le protocole Rapid Spanning Tree Protocol (RSTP) ou un protocole en anneau propriétaire. Si un câble se rompt entre deux voitures, le trafic est automatiquement acheminé dans la direction opposée autour de l'anneau, maintenant la connectivité pour tous les points d'accès (AP) en quelques secondes.

Saturation du backhaul à la sortie du tunnel

Le risque : Lorsqu'un train sort d'un long tunnel, tous les appareils tentent simultanément de resynchroniser des données (e-mails, mises à jour d'applications, sauvegardes cloud), créant un pic de trafic qui sature le backhaul pendant 30 à 60 secondes.

Atténuation : Mettez en œuvre des politiques agressives de Traffic Shaping qui limitent spécifiquement le trafic des applications en arrière-plan. Configurez le Captive Portal pour déprioriser le trafic de mise à jour du système d'exploitation et les services de synchronisation cloud au niveau de la couche application, garantissant que le trafic interactif (navigation web, messagerie) est toujours priorisé.

ROI et impact commercial

Bien que le déploiement d'un réseau WiFi ferroviaire nécessite des dépenses d'investissement importantes — généralement de 50 000 £ à 200 000 £ par train selon la complexité de la solution de backhaul — il offre des retours substantiels et mesurables lorsqu'il est intégré à une plateforme d'analyse robuste.

Facteur de valeur	Mécanisme	Résultat mesurable
Acquisition de données de première partie	Authentification via Captive Portal	Base de données d'e-mails des passagers pour le CRM et le marketing
Intelligence opérationnelle	Analyse NOC + superposition GPS	Responsabilité SLA des opérateurs, identification des lacunes de couverture
Revenus des médias de détail	Publicité via Captive Portal	Revenus directs du contenu sponsorisé lors de la connexion
Satisfaction des passagers	Connectivité fiable	Amélioration des scores NPS, augmentation de la part modale ferroviaire
Conformité réglementaire	Capture de données conforme au GDPR	Réduction des risques juridiques, registres de consentement vérifiables

En exigeant une authentification via un Captive Portal, les opérateurs construisent une base de données précieuse de padémographie des passagers et leurs habitudes de voyage. Ces données peuvent être utilisées pour des campagnes de marketing ciblées, des programmes de fidélité et la personnalisation des services. Les tableaux de bord analytiques qui superposent les performances du réseau aux données de localisation des trains permettent aux opérateurs d'identifier les lacunes de couverture le long des voies et de tenir les fournisseurs de services cellulaires responsables des SLA contractuels.

Le Captive Portal lui-même est un bien immobilier numérique de premier ordre. Les opérateurs peuvent insérer des publicités ciblées ou des messages sponsorisés dans le processus de connexion, générant ainsi des revenus directs pour compenser les coûts d'infrastructure. Ce modèle est très performant dans d'autres secteurs, notamment les pôles Retail et Transport , et les mêmes principes s'appliquent directement à l'environnement ferroviaire. Pour les opérateurs du secteur de l'hôtellerie gérant des hôtels de gare ou des salons, les mêmes principes de plateforme s'appliquent — consultez notre guide sur les déploiements de WiFi Hospitality pour des modèles d'implémentation parallèles.

Termes clés et définitions

Multi-Bearer Aggregation

The process of combining multiple network connections — typically several 4G or 5G SIM cards from different carriers — into a single, robust data connection using a bonding gateway to improve aggregate bandwidth and provide automatic failover.

Essential for trains, as it prevents network dropouts when passing through areas where a single cellular provider lacks coverage. The gateway dynamically routes packets across all available bearers in real-time.

EN 50155

An international standard (IEC 60571) covering electronic equipment used on rolling stock for railway applications, specifying requirements for temperature, humidity, vibration, shock, and power supply fluctuations.

IT teams must ensure all onboard routers, switches, and APs are EN 50155 certified. Standard enterprise hardware will fail in the railway environment due to vibration and temperature extremes.

Captive Portal

A web page that the user of a public-access network is obliged to view and interact with before full internet access is granted. It typically requires authentication and acceptance of terms of service.

Used by operators to authenticate users, enforce fair usage policies, and capture valuable first-party marketing data. It is the primary commercial interface between the operator and the passenger on the WiFi network.

Client Isolation

A security feature on wireless access points that prevents connected devices from communicating directly with each other on the local network, forcing all traffic through the gateway.

Critical for public networks like train WiFi to protect passengers from peer-to-peer hacking attempts, man-in-the-middle attacks, and malware propagation across the onboard LAN.

Lineside Infrastructure

Dedicated telecommunications equipment — including antennas, radio units, and fibre backhaul — installed along the railway track to provide a private, high-capacity backhaul network for the trains.

Deployed when public cellular networks cannot handle the high data demands of dense commuter routes. Requires significant capital investment but offers guaranteed throughput independent of public network congestion.

Passpoint / OpenRoaming

A protocol suite (based on IEEE 802.11u and Hotspot 2.0) that allows devices to automatically and securely connect to participating WiFi networks without requiring a captive portal login, using certificate-based authentication.

Improves the passenger experience for repeat travellers by providing seamless, automatic connectivity. Purple acts as an identity provider for this service, enabling operators to offer it without building their own authentication infrastructure.

Traffic Shaping (QoS)

The practice of regulating network data transfer to control bandwidth allocation, prioritise certain types of traffic, and block or throttle others, ensuring a defined quality of service for all users.

Used on trains to block high-bandwidth applications (like 4K video streaming) and prioritise interactive traffic (web browsing, email, VoIP) to ensure all passengers have a usable connection despite finite backhaul capacity.

Doppler Shift

The change in frequency of a radio wave as perceived by a receiver that is moving relative to the transmitter. At high speeds, this frequency shift can degrade the quality of the radio link.

A fundamental physical challenge in high-speed rail networking. Specialised track-to-train radio equipment is required to compensate for Doppler shift at speeds above 100 mph, making standard enterprise outdoor APs unsuitable for lineside deployment.

Fair Usage Policy (FUP)

A set of rules enforced by the network operator that limits the bandwidth or data consumption of individual users to ensure equitable access for all connected devices.

Implemented via the captive portal and traffic shaping engine on the multi-SIM aggregator. Without an FUP, a small number of heavy users can saturate the entire backhaul, degrading the experience for all passengers.

Études de cas

A regional rail operator with 50 trains is experiencing severe WiFi complaints. Passengers report the network drops out completely during a 15-minute stretch of the journey through a rural valley. The current setup uses a single-SIM 4G router in each carriage. What is the recommended remediation approach?

The operator must upgrade to a multi-bearer architecture. Step 1: Replace the single-SIM routers with a centralised EN 50155-compliant multi-SIM aggregation gateway per train. Step 2: Conduct an RF survey of the valley to determine which MNOs have partial coverage in the affected segment. Step 3: Provision the gateway with SIMs from at least three different MNOs (e.g., EE, O2, Vodafone), configuring the gateway for packet-level bonding and seamless failover. Step 4: Implement a captive portal to enforce a strict 2 Mbps per-user rate limit during the low-coverage valley segment to prevent connection timeouts for basic web browsing. Step 5: Integrate with a cloud NOC to monitor the failover events in real-time and build a coverage map for carrier negotiations.

Notes de mise en œuvre : This solution addresses the root cause — a single point of failure in the backhaul — rather than treating the symptom. Moving to a multi-SIM aggregator ensures that even if one carrier drops in the valley, the session is maintained via the others. The dynamic bandwidth management via the captive portal is a crucial secondary step to manage user expectations during periods of constrained backhaul. The NOC integration transforms a reactive problem into a proactive, data-driven carrier management tool.

A major intercity operator is launching a new premium service and wants to offer a differentiated WiFi experience: first-class passengers get 20 Mbps uncapped, while standard-class passengers receive 5 Mbps with streaming blocked. How should this be architected?

This requires a multi-SSID architecture with per-SSID QoS policies. Step 1: Configure two separate SSIDs on the onboard APs — one for first class, one for standard class. Step 2: Assign each SSID to a separate VLAN. Step 3: On the multi-SIM aggregator, configure per-VLAN traffic shaping policies: VLAN 10 (first class) receives priority queuing with no application-layer blocking; VLAN 20 (standard class) receives a 5 Mbps per-user cap with Deep Packet Inspection (DPI) rules blocking known streaming service domains and IP ranges. Step 4: Deploy separate captive portal instances for each SSID, with the first-class portal pre-populated for frequent travellers via OpenRoaming or a loyalty programme token.

Notes de mise en œuvre : The multi-SSID and multi-VLAN approach is the correct vendor-neutral solution. It avoids the complexity of single-SSID per-user policy enforcement and maps cleanly to the operator's commercial model. The DPI-based streaming block is more robust than simple domain filtering, as streaming services frequently rotate their IP ranges. The OpenRoaming integration for first-class passengers demonstrates a clear understanding of how to reduce friction for high-value customers.

Analyse de scénario

Q1. You are designing the onboard LAN for a new fleet of 8-carriage trains. The project manager suggests daisy-chaining the APs via standard Cat6 cable between carriages to reduce cost. What is the primary risk of this approach, and what architecture should you recommend instead?

💡 Astuce :Consider the physical environment of a moving train and what happens to network segments downstream of a broken inter-carriage cable.

Afficher l'approche recommandée

The primary risk is a cascading single point of failure. If the cable between Carriage 3 and Carriage 4 breaks due to vibration or mechanical stress during coupling, Carriages 4 through 8 lose all network connectivity. I would recommend a redundant ring topology using EN 50155-compliant managed switches with M12 connectors and RSTP or a proprietary ring protocol. In a ring topology, a break in any single cable segment is automatically bypassed within milliseconds by routing traffic in the opposite direction around the ring, maintaining connectivity for all APs.

Q2. Your analytics dashboard shows that total bandwidth on the 08:00 commuter service is maxing out the multi-SIM backhaul, causing widespread complaints about slow speeds. However, only 30% of passengers have authenticated on the captive portal. What is the likely cause and what is the solution?

💡 Astuce :Think about what devices do in the background when they detect a known or open WiFi network, even before a user actively browses.

Afficher l'approche recommandée

The most likely cause is background device activity: OS updates, cloud backups (iCloud, Google Drive), app refresh cycles, and email sync all initiate automatically as soon as a device associates with the SSID, regardless of whether the user has authenticated through the captive portal. The solution is to implement strict pre-authentication walled gardens on the captive portal — only allowing access to the portal itself before login — combined with post-authentication traffic shaping that blocks known update server IP ranges and CDN domains during peak hours. Per-user rate limiting should also be applied immediately post-authentication.

Q3. A train operator wants to deploy dedicated lineside track-to-train infrastructure to bypass public cellular networks entirely. Their procurement team has identified a low-cost option using standard enterprise outdoor WiFi access points mounted on poles at 200-metre intervals along the track. The trains travel at 125 mph. Why will this approach fail, and what should they specify instead?

💡 Astuce :Consider both the physics of high-speed radio communication and the operational requirements of handoff between access points.

Afficher l'approche recommandée

This approach will fail for two fundamental reasons. First, standard enterprise outdoor APs are not designed to handle the rapid handoffs required when a train is moving at 125 mph — at that speed, the train passes a 200-metre cell in under 4 seconds, far faster than standard 802.11 roaming protocols can execute a clean handoff. Second, the Doppler shift effect at those speeds will degrade the radio link quality, as standard APs cannot compensate for the frequency shift caused by the relative velocity between the train and the fixed antenna. The operator must specify dedicated track-to-train radio equipment from vendors with proven high-speed railway deployments, using technologies specifically designed for mobility scenarios, with directional antennas and proprietary handoff protocols optimised for train speeds.

Q4. A passenger rail operator is preparing for a GDPR audit. Their captive portal collects email addresses and uses them for marketing. What are the three most critical compliance requirements they must demonstrate?

💡 Astuce :Focus on the lawful basis for processing, the right to withdraw consent, and data retention.

Afficher l'approche recommandée

The three most critical requirements are: 1) Lawful basis and explicit consent — the portal must present a clear, unbundled consent checkbox for marketing communications that is not pre-ticked and is separate from the terms of service acceptance required for WiFi access. Passengers must be able to access WiFi without consenting to marketing. 2) Right to withdraw — there must be a clear, accessible mechanism for passengers to withdraw their marketing consent at any time, typically an unsubscribe link in every email and a self-service preference centre. 3) Data retention and minimisation — the operator must have a documented data retention policy specifying how long passenger data is held, and must be able to demonstrate that data is deleted or anonymised after the retention period. All three must be evidenced with audit logs.