Train WiFi Roaming

Abstract

UK First for seamless WiFi roaming between Stations and Trains

Publication
Train to Station to Train seamless 3G & WiFi roaming
Date
Links

Summary of Requirement

Chiltern Railways, a part of the Arriva Trains UK network wished to provide a seamless wireless network service for their customers. The solution had to provide a single sign on registration for the customer, which could be undertaken on anyone of their 34 stations, or on the train. Once registered the user would be seamlessly handed between station and train, train and station across the complete network.

Working together to deliver a solution

With multiple parties involved including The Cloud ( the incumbent service provide ), EE ( Everything Everywhere, 3G network operator ), Icomera ( Specialist train WiFi provider) and of course WiFi SPARK Ltd ( leading managed wireless solution vendor). My role at WiFi SPARK is as the Development manager, and as such I took the lead technical role in the design and delivery of this solution. Without doubt the most difficult aspect of driving and delivering an integration such as this, is getting all the teams on the same page and working well together. Each organisations development and delivery teams have technical and customer demands that must be navigated with care.

I lean heavily on Open Source methodologies, in particular one pattern that I refer to often is the Bazaar versus the Cathederal development paradigm. Traditional education establishments teach the Cathederal style of software development. In contrast the free software community has a preference for the Bazaar model. I do recommend “The Cathederal and the Bazaar” by Eric S Raymond for further reading on this topic.

In essence Bazaar is agile, rapid application development style. It relies on tightly bound team work, close and frequent communication and a dynamic, energetic approach to getting the work done. I sort from the very first technical briefing meeting to position WiFi SPARK in the technical driving seat, whilst at the same time using soft objection handling techniques to ensure the other teams did not get entrenched in any specific paradigm or requirement. Once attached and leading the road map the knack is to quick to drive proof of concept code into verson control, and to fight off getting bogged down in writing technical specifcations. This approach is stright from the gospel according to free software, and is often referred to as extreme programming. It’s principles are simple :-

  • Release often, Release early
  • Function first, Optimise last

What on earth is a “SPARK ® Connector”

This is the clever bit of systems intercommunication that takes care of transferring customers from Station to Station, Train to Train, Train to Station and Station to Train. It remembers users and their devices, and it speaks the language of everyone elses system. It communicates between each systems and relays requirements to the SPARK controller, the wireless management controller which is WiFi SPARKS lead product.

Conclusion

It has been tremendous fun working on such a challenging integration, and I am deeply grateful to the teams for their support and contribution. I tip my hat and pat the backs of the software development team, especially Richard Elmes, and Alexander Pyatkov ( aka Sasha) for their excellent development work on the SPARK Connector and SPARK APi.