Policymaking and Standards
I've had 10 years close experience with telecommunications regulators, and I have published a number of telecoms papers and proposals.
Leo Brown
I’m a purpose-driven technologist with 25 years’ experience — from distributed carrier networks, to crisis innovation and policy work.
My current focus is fibre network delivery at Brighton Fibre and expanding the dark fibre footprint of Global Reach.
Explore my work
Projects
Software & technical projects
Software and technical projects exploring networks, automation, distributed systems and new ways to solve problems.
Software
Axon
IoT sensor network
Software
Ember
ML background task pipeline
Software
Sēlo
Personal operating system
Hardware & software
Ripple
Voice-led household communication
Software
Lapis
Bluetooth presence detection
Software
Plexus
Fibre network mapping
Software
Fusion
PHP SIP call engine
Software
Synthesis
Telecoms API platform
PingletRouting loops
& traffic amplification
& traffic amplification
Software
Pinglet
Routing loop detection
Software
OpenMobile
Mobile network enablement
Companies
Telecoms & network infrastructure
Companies I’ve built and helped develop, from telecoms platforms to fibre networks and shared infrastructure.
Papers
Publications & protocols
Papers, protocols and applied research across telecommunications and humanitarian technology.
Skills
Analysis, architecture & implementation
Principal Skills
Stakeholder Liaison
My industry background stands me in good stead for speaking the language of the many strata of global networks and interpreting their sometimes competing needs.
Protocol Analysis
With a robust grounding in deep packet inspection and protocol design, I am uniquely placed to analyse and critique protocols across the OSI model.
Network and Infrastructure
Core Network
I've rearchitected a number of ISP Core Networks based on a variety of hardware such as Cisco, Mikrotik and Juniper. I've also experience in SDN (Software Defined Networking) and hosting routing services in the cloud with platforms such as CHR (RouterOS Cloud Hosted Router).
Firewalls and Filtering
Having designed and maintained several hundred firewalls, I'm well-versed in intelligent firewall design, including deep layer 4-7 filtering of privileged malicious vectors.
Monitoring and Assessment
I've a wide-ranging experience of NMS (Network Monitoring Systems) including Observium, PRTG, OpenNMS, Nagios and I've authored a number of custom monitoring systems based on open source software like Iptables.
Topological Redundancy
By building in redundancy from the outset, I create networks that tolerate many failures before repair is necessary. With the right deployment of technologies, no network should contain a single point of failure, and should be inherently able to balance loads within.
Software Design
Software Polyglot
I learned to code aged six (in 1987) in BASIC as it was the only real way to 'enjoy' a home computer. Since then I've written at least 5 million lines of code across several languages. I now only do short stints of actual code in order to solve critical problems, but my knowledge of various languages gives me a solid understanding of common development pitfalls.
Black Box Specialist
I've always built software projects in reusable, self-contained silos, way before the days of popularised containerisation such as Docker. In 2001 I structured a web hosting product line around FreeBSD jails, a protected environment whereby an operating system would run within another, while both efficiently share common resources (kernel modules).
API Evangelist
I've used APIs wherever possible and I've written several dozen APIs over the years. With a focus on simplicity and standards, APIs provide stability and security to hardware, software and networks.
Appointments
Organisations & ongoing work
2019Service Provider
Brighton Fibre
Brighton Fibre (AS60395) was founded in 2019 in order to widen the landscape of connectivity offerings in Brighton and Hove. We have embarked on a core network build in the city including popping the BT Exchanges and are now rolling out FTTP to underserved areas.
2012Cloud Voice
Netfuse Telecom
Netfuse Telecom (AS35071) is a consultative IP Telco focussed on improving the link between inherent business data and two way voice telecoms services. Netfuse's primary product is a self-service hosted Cloud Voice platform, but auxiliary to this is a suite of custom integrations and application deployed and in active development.
2002Wholesale Carrier
Global Reach
Global Reach (AS41099) began as a traditional hosting provider and now plays a role as an aggregator of global voice and data networks, bringing connectivity from 62 countries to SMEs at near-wholesale costs.
2022Infrastructure Cooperative
Cooperative Network Infrastructure
Cooperative Network Infrastructure (CNI) brings together public and private sector organisations to build and share fibre infrastructure. My work within the Cooperative is focussed on planning, delivering and maintaining CNI dark fibre infrastructure.
2015Infrastructure Cooperative
Brighton Digital Exchange
The Brighton Digital Exchange (AS44488) is a cooperatively-owned carrier neutral datacentre and "meet me" point. Established to provide a menu of inter-carrier connectivity options in an accessible, central location, the BDX is a novel and disruptive model of an open exchange which helps businesses and carriers access parts of the internet value chain previously locked within large ISPs.
Contact
Drop me a line.
A network challenge, a new idea, or a discussion about something you’d like input on. I’d be happy to talk over your project.
I’m not taking on paid work at the moment, but I’m always happy to explore people’s challenges and offer my input.
Axon
IoT sensor network
Axon is a distributed probe network and decision cloud for observing and controlling IRL systems. I started desperately building it while my wife was in hospital for a life-saving operation. I was travelling back and forth from London every day, and I couldn’t shake the fear that some of the plants at home would die, and she would be mortified. I dreamed of a low-power sensor network that could keep an eye on soil quality and make sure I could do as good a job as she did.
Bringing the signals together
The plant sensors could tell me what was happening in the soil, but I wanted some context before deciding what to do about it. I wanted to bring in sunrise and sunset times through APIs, so I could work out sensible times for alerts. I don’t want to be woken at three in the morning because a plant needs watering.
I also wanted to know whether the heating was on. That gives me another clue about how quickly the soil might dry, alongside the readings from the probes. Bringing those signals together helps me decide when to check the plants, rather than treating every reading as a reason to send an alert.
Sources provide the incoming information; sensors represent individual values extracted from those sources. Those values can be retained over time, graphed, and used in rules and conditions.
From observation to decisions
Axon keeps observations, state, conditions and transitions in the same operational model. The runtime can evaluate what is happening and use that understanding to coordinate the next action.
Depending on the system, the outcome might be an alert, a dashboard update, an actuator command or a recovery path. The aim is to connect observation and control in a coherent loop.
Purpose-made probes
The ESP32-based probes let me place observations where they are needed in the physical environment. They are part of the same model as the external data sources, allowing decisions to use information from several places at once.
One view of a distributed system
The interesting part is the connection between many small observations and a useful decision. Axon gives distributed hardware, live telemetry and software logic a common place to meet.
Ember
ML background task pipeline
As an ethical multitasker and ADHD-er, I have a desperate wish to finish many of the dozens of ideas I have each day. Finding the brilliant unfinished ones is a regular and painful process. Ember is one of my “secret hatches” I’m building: a way to finish ideas when I’m asleep, so they can keep ticking when I’ve got distracted.
The idea
The inspiration is similar to SETI’s use of spare home-computer capacity: take a resource that is available but underused, and give it useful work. With Ember, the resource is AI capacity and the work is a collection of projects with defined goals.
That might mean analysing a difficult problem, investigating a technical question, or progressing a penetration-testing project. The aim is to draw on available AI resources and turn intermittent attention into sustained progress.
Keeping the work moving
Each project needs more than a fresh conversation. It needs a record of what has been tried, what has been learned, and what to do next. Ember keeps project progress and outputs together so that the next run can continue the work rather than start again.
Sharing the capacity
The resource dashboard lets me set how much allowance Ember may use, how to divide that pool between projects, and how much capacity to keep available for my own interactive work. Those allocations are approximate; they provide a way to pace background work rather than a promise of a precise quota.
Tracking usage
The usage view records individual runs, their outcomes, and input and output token counts. It keeps those reported counts separate from quota points, which reflect approximate changes in the account’s allowance.
The central idea is simple: keep useful projects moving when I’m working on something else.
Sēlo
Personal operating system
Sēlo started with a very familiar problem: too many ideas, not enough time. I wanted “something, somewhere” to get me back to my train of thought. In practice, this is through a network of Raspberry Pis nestled around the house, plugged in along hallways and next to washing machines. I’ve built a dumping ground for thoughts, feelings and ideas — a personal operating system, with lofty ideas of becoming a counsellor and coach.
Getting thoughts out
The first job is to make it easy to capture what’s on my mind. That could be an idea, a worry, a plan or a passing observation. Sēlo’s writing surface keeps that starting point simple, with space to write and a control for recording an idea.
I want it to be useful before a thought is polished or neatly categorised. Getting it down comes first; giving it structure can happen later.
The Raspberry Pis are part of how I want Sēlo to fit into everyday life: a way to capture a thought or get a reminder without first finding the right app. The aim is to help me pick up the thread of what I was doing.
Finding a structure
Collections let related writing sit together. They can be nested and reordered, with a preview of the writing inside each one. That gives me a way to organise broad areas of life alongside smaller, more specific threads.
A counsellor and coach
The direction is more than a place to store writing. I’m exploring how a personal system can help me reflect on what I’ve captured, understand what matters and decide what to do next.
The counsellor and coach idea describes where I want to take it: a system shaped around my own thoughts and circumstances, with room for both reflection and practical progress. Sēlo is still being written.
Ripple
Voice-led household communication
With a young family, just finding the kids around the house can be a task in itself. Ripple grew out of that everyday problem: I want to be able to say a name and reach someone without knowing which room they’re in. It brings together voice, embedded hardware and presence information to help make that possible.
Find the person
The starting point is familiar: someone calls across the house, nobody hears the answer, and the shouting starts again. A phone might be on silent or charging in another room. Children may not have one at all.
I want Ripple to let someone say “Hey Dad” without needing to know which room Dad is in. Small devices around the home would connect the conversation where he is most likely to be. If the system is unsure, a short summons would let him answer from a nearby device, opening the conversation there and leaving the others quiet.
Listening locally
The proposed design keeps the immediate listening work on the device: detecting a wake word, identifying speech and recognising supported requests with compact models. The aim is a quick response that does not need a cloud round trip for every conversation.
Cloud assistance has a different role. With permission, selected recordings can help build reviewed training examples for names and household phrases. Recognising a request, identifying the speaker and locating the recipient are separate problems; a transcript alone does not solve all three.
Where to connect
I’m exploring how recent recognised speech and opt-in Bluetooth proximity could help estimate where someone is. Those signals need a sense of freshness and confidence: a phone left on a table is not proof that its owner is still beside it.
That uncertainty needs to shape the behaviour. Asking someone to answer a summons is better than confidently connecting the wrong room. Longer term, optional telephone calling could extend the same idea beyond the house. Clear call indicators, microphone controls and household preferences are part of the intended design.
Early experiments
Ripple is still very much a work in progress. So far, I’ve been testing microphone capture and SIP/RTP audio on ESP32 hardware, alongside a separate wake-word detector and cloud transcription workflow. The photo shows the initial wake-word experiments.
The next challenge is bringing those pieces together. Reliable two-way audio, speaker recognition and routing to the right person all need to be proved in a real home, with television, background noise and competing voices. The ambition is a simple everyday interaction; the current work is understanding what it takes to make that dependable.
Lapis
Bluetooth presence detection
I keep forgetting to do things, so I wanted a way to remind myself when I got home. I also wanted it to work without tying myself to Apple’s ecosystem or depending on another app whose useful features might disappear later. Lapis uses local Bluetooth activity as a cue for presence, so reminders and home automation can respond to who is around.
The name comes from lapis lazuli, a deep blue gemstone — a nod to the Bluetooth signals the project works with.
From devices to presence
A phone or another familiar Bluetooth device can provide a useful indication of presence. By associating known devices with people and observing their local activity, the project builds a picture of arrivals, departures and the spaces being used.
The useful question is not simply whether a device can be seen. It is what that observation tells us about the home, and how that picture changes over time. Device activity is a signal to interpret, rather than a guarantee of someone’s exact location.
The device view brings signal-strength (RSSI) history, time buckets and an approximate location timeline together, so changes in radio activity can be examined over time. The timeline uses the strongest observing node as an indication of proximity.
Giving the home context
The aim is to use that presence information to drive lighting, heating and other home behaviour. Different parts of the home can respond to the same understanding of who is around, instead of relying only on separate switches, schedules or motion sensors.
A practical use for local signals
I’m interested in how ordinary radio activity can become useful information about a physical environment. Lapis applies that idea to the home: observe the local Bluetooth environment, interpret the patterns, and make the result available for automation.
Plexus
Fibre network mapping
Plexus grew out of one of my “lockdown ideas gone mad”, Brighton Fibre. When everything outside became very unforgiving, uninterrupted connectivity became paramount. I wanted to build a local fibre network that people could depend on and feel part of. I had to design things from scratch — and that meant digging the ground and finding something to help remember what went where when it all disappeared from sight. Plexus became that thing: a detailed, interconnected record of infrastructure, of ducts and chambers, fibres and lasers, and everything they tell us.
There’s more of the background in Brighton Fibre’s origin story ↗.
Recording the physical network
Once cable is installed, much of it disappears underground. Plexus records ducts, their bores and available space, cables and joints. Built on open-source software and hardware, it relates that infrastructure to the streets and properties above it, supporting capacity planning as the network grows.
Tracing the optical connections
Geography is only part of the record. Plexus follows individual fibres through each splice, connecting the street map to the optical path between an exchange and a customer. Those joins make it possible to trace a connection through multiple cables.
Keeping records close to the work
Engineers can add evidence and reports from the field as they extend the network. The records need to follow the infrastructure as it changes.
Watching optical performance
Plexus also tracks customer optical readings. Its OLT loss analyser groups readings by port, helping identify differences worth investigating. Mapping and monitoring sit together: the route, the joins along it and the performance of the connection.
Read the fuller story, Recording the Unseen, on Brighton Fibre.
Fusion
PHP SIP call engine
I started Fusion because I was a broke software developer who couldn’t afford a phone system, so I decided to build one myself. I was 19 and learning PHP on the fly. It was a thoroughly inappropriate language for a phone system, but it was the one I knew. That was enough to get me started.
The software is a PHP Back-to-Back User Agent (B2BUA), using the PHP Threads library to handle the involved SIP protocol in a high-level language.
The software takes a class-based approach to receiving and dispatching incoming SIP messages on a public port. If anyone would like to use a PHP user agent in their software, please get in touch!
Synthesis
Telecoms API platform
The Synthesis platform was built to provide an API-led approach to telecoms giving developers tools to rapidly build, deploy and iterate context-aware, elastically scalable integrations between business data and telecoms systems, without the pain of investing heavily in infrastructure or development.
The most crucial feature of Synthesis is the ability to route live call flows via an external web application. Synthesis provides a functional telecoms layer which can be built on to creative incredibly reactive telephony applications, leveraging existing wholesale infrastructure rather than that of large aggregators who consume a large proportion of the value chain.
Read more about the Synthesis Call Routing API.
The Synthesis Web APIs were used to create the Synthesis business telecoms platform, a general-purpose phone system for small and medium-sized businesses to create call routing logic, hunt groups, voicemail and other feature-rich telecoms services.
Read an introduction to the Synthesis for Business Platform Features.
Pinglet
Routing loop detection
I see networks being attacked all the time through tiny glitches in their setup. I wanted to make a few common problems easier to spot, so I could warn friendly network operators about issues in their own networks too. Pinglet grew out of that, and I decided to make it open source so others could use it as well.
The name comes from “Piglet”, my three-year-old’s pet name for her six-year-old brother.
Pinglet focuses on exposing vulnerable network echoes: route loops that create traffic amplification risks, and “noisy neighbours” that reply to simple probes where I expect silence. I want to turn those small, easily missed behaviours into evidence I can share with the people running the network.
Looking for unwanted echoes
A network can appear healthy while still doing something strange at its edges. A packet sent towards an unused address may get caught in a routing mistake; a device may answer a basic request from somewhere it was never meant to be reachable. I’m interested in what comes back from those small probes, and what that response tells me about the network behind it.
The current work brings together three checks: possible routing loops, unexpected web-service responses, and changes in the path to a destination. Together, they give me a way to look beyond whether a target is simply up or down.
When traffic gets stuck
A routing loop can send a packet around the same links repeatedly, consuming bandwidth and router effort until its lifetime runs out. That is the amplification risk I’m interested in: a small amount of incoming traffic causing repeated work inside the core.
The loop detector probes configured address ranges and looks for TTL-expired replies. It records the destination being tested and, when available, the router reporting the expiry. Known cases can be silenced so that an understood condition does not keep filling the alert channel.
A TTL-expired reply tells me the probe exhausted its hop budget. It flags a possible loop for follow-up; confirming the loop and its impact takes further investigation.
Noisy neighbours
There is another kind of echo I want to find: a device answering a minimal request when I would expect silence. The web-service check asks configured addresses and ports for a basic HTTP response, then records the status code and any server or device clues in the headers.
That can bring an overlooked router web interface or another unexpectedly exposed service into view. The useful question for the operator is simple: is this meant to be reachable here? An HTTP reply shows that a service is responding; whether that exposure is a fault depends on what the network is intended to allow.
Watching the route change
The path monitor uses MTR to follow the route towards a destination and keeps a record of the last good path. It adds network numbers and operator names using RIPE’s prefix data, making a trace easier to relate to the networks involved.
It compares a simplified sequence of the networks seen along that trace, grouping consecutive hops in the same network and allowing for routers that do not answer. That helps avoid treating a less talkative router as a meaningful route change. It is a view of the observed forwarding path, useful for noticing a change in transit or where replies stop.
The monitor also distinguishes a failed probe from a destination that appears unreachable, and reports recovery. If the monitoring tool itself has failed, I want that stated clearly rather than presented as evidence that a remote network has gone down.
Making the findings useful
The checks are small PHP command-line tools with configured targets, timeouts, local logs and Slack notifications. They can sit alongside my existing monitoring without needing a large dashboard first.
A loop alert identifies the target and the router reporting the expiry. A path-change alert puts the old and new network sequence side by side. When a destination appears unreachable, the report includes the last responding hop and, where a saved baseline is available, the next hop it expected.
That gives me something concrete to investigate and a clear finding to share with a friendly operator. Making Pinglet open source means other people can inspect the checks, adapt them to their own networks and help each other catch the little problems before they become much bigger ones.
OpenMobile
Mobile network enablement
I've always sought to create a disruption to an existing industry and in 2010 I hoped to do this by creating a general purpose Mobile Virtual Network Enablement (MVNE) service which could bring mobile telecoms into the hands of SMEs who had 50 subscribers or more.
The ultimate aim was that SMS and Voice traffic was seamless between fixed lines and mobile users in a given organisation - what is now commonly referred to as fixed-mobile convergence. I believed that many SMEs had the ability and desire to handle their own Mobile Originating (MO) and Mobile Terminating (MT) SMS, and to present this to them as an option - as well as the voice component - was a strong value proposition which would justify the R&D time required to bring MVNO to SMEs.
Here's an early overview of how voice and SMS traffic were to be segmented when using the OpenMobile product in an organisation:
The lynchpin of this proposition was originally an H3G MVNO brokered beautifully by AQL but this project was stopped as the high cost of data throughput meant that it was not possible to bring the service to a B2B market.
I then worked with the UK Telecommunications Regulator, Ofcom, and obtained a new mobile range (100,000 numbers) for the purpose of providing OTT services across a wide range of multi-network International Mobile Subscriber Identities (IMSIs) so that the underlying carrier was no longer critical to providing the service. I engaged with Manx Telecom to provide USIMs with IMSIs from multiple Mobile Network Operators (MNOs) and rolled out the service to early-adopter Netfuse customers.
Brighton Fibre
Companies · Fibre infrastructure
I created Brighton Fibre at the beginning of the COVID-19 epidemic to help alleviate the downward pressure on connectivity in the City as a response to the mass transition to working from home and working via telecon as the new normal. I wanted to create a low-profile network with infinite capacity and unbreakable reliability, using entirely clean energy.
The only way to do this was to create an entirely new passive optical network by laying new cable within the City. While there was already some fibre in Brighton we were the first true fibre operator to begin connecting homes and businesses in the City.
Going Under
The first thing I had to do was undergo training to work safely underground and learn about how best to connect properties in the City. I completed most of my underground training by Jan 2021, around 9 months after the first lockdown. This taught me the basics of gas detection, cable installation, rodding and roping, etc. Once safety was out of the way most of the rest would be learned 'on the job'.
Managing Traffic
Since I would be in the road regularly laying cable, the other important qualifications I would need were around traffic management. I took sister company Global Reach through the process of obtaining Code Powers which allowed us to book road space - but we would still need to comply legally with signing, lighting and guarding while working in the carriageway.
Tooling Up
Having never spliced a single fibre before, I had to get familiar with the hardware. I got in touch with Fujikura, who kindly supplied me a reconditioned fusion splicer - one of the most crucial tools of the trade. Today it's the old spare splicer in the back of the cupboard, but just 2 years ago it was a futuristic experience.
Exchanging Ideas
In order to cover more of the City more quickly, I decided to 'pop' the local BT Exchanges. This effectively means renting space inside a BT Telephone Exchange to build your own network and install equipment.
Inside my first BT Exchange (well the first time with permission)It felt great to be inside a BT Telephone Exchange for the first time. As a kid, I always looked in wonder at the exchange at the end of my road in Highbury, and wondered how I could get inside. I think I was 8 years old when I first realised the skips outside contained lots of old outdated telephone network hardware (they still do!). I used to pick out relays and build my own little networks.
Once in, you are hit by a musty smell that's now so reminiscent bakelite, mahogany, and soldering. I plan to write up what it's like to be in an old exchange some day but back to the Brighton Fibre story.
Labcabin
Before connecting customers to the network I needed to lab out the infrastructure that would support them. I started with a number of routers on the bench, to see how much data they could push and how quickly the network would self-heal when one of them failed. This is the only opportunity you really get to mess around with a network before customers are on board - so it's important to take your time to really explore all the options.
Making Connections
The next challenge once into an exchange is to bring in connectivity from other sites - to get traffic to/from the internet and to Docklands in London where most large networks coexist. A BT Telephone Exchange is a great place to 'meet' other networks and connect cables to eachother - a concept broadly known as multilateral peering, a mesh of interconnections between service provider and wholesale networks. What this means in practise is asking BT Openreach to deliver a cable between your racks and your neighbour's racks - letting people run their own cabling would soon result in a spaghetti mess.
Feeling Ropey
So I had racks in BT exchanges, lots of reels of fibre, and customers to connect. It was time to start rodding, roping and cabling to deliver this fibre into customer sites. The beauty of dark fibre is that it's a single piece of glass from your network to your customer's site, within which you can fit any amount of data.
My first dark fibre connection, at Lorna Road in HoveFinding our natural base
Now that I have built a network and some directly-connected dark fibre customers, it was time to roll out to some underserved areas. I focussed on one of the most connectivity-deprived streets of Brighton, Gardner Street. This street is particularly hard hit as there are coal cellars for every property which run under the highway, meaning the prevailing networks have not managed to lay cable underground due to insufficient depth to lay telecoms duct.
Splicing some of the first connections at Komedia on Gardner StreetTaking it to Market
Once the model was tested and deployed, I worked with competitor Fairfibre to amalgamate our experience and customers and redefine the Brighton Fibre purpose. There was a lot of complementary assets; Fairfibre had the experience of physically connecting much larger numbers of customers, and Brighton Fibre had a working, multi-site core. We hope to expand the customer base to 3,000 subscribers by 2025.
Netfuse Telecom
Companies · Carrier & cloud voice
I founded Netfuse to capitalise on the convergence of open source and telecoms in the web and integrations space. Since going live we have become a national UK operator with our own number ranges and multi-POP national resilient MPLS metro network which I have built out from the very core, becoming a RIPE LIR, obtaining our own IP space, and establishing carrier interconnects on which to announce our prefixes. In 10 years of operating we have carried over 100 million minutes, hold several hundred thousand numbers and have provided a totally unique approach to IP Telecoms based on realtime API-led call control. I have personally established MVNO relationships via H3G and Manx Telecom and continue to serve as a technical liaison for third-line support and carrier interworking requirements.
Download the Netfuse Deck below
Global Reach
Companies · Wholesale infrastructure
I created Global Reach to provide wholesale infrastructure for carriers and networks essential to service their client base. Global Reach was established in 2002 as a hosted application services provider servicing the UK financial and governmental sectors. Today Global Reach is building a fibre network across the UK.
Acumen
Companies · Software & public sector
I created Acumen to provide web-based applications for the UK financial and governmental sectors. Acumen built around 60 apps and websites between 2004 and 2013, until we built Netfuse, which focussed our web-building skills firmly into cloud telecoms.
Planning Tools for UK Government
As part of our work with the UK Government we provided hosting and software support to the UK Foreign and Commonwealth Office (FCO), The Department for International Development (DfID) and the Stabilisation Unit. This involved both cloud-hosted infrastructure and black-box software deployments in the field, notably in reconstruction efforts throughout the middle east, and joint exercises at UK bases.
Cooperative Network Infrastructure
Companies · Cooperative infrastructure
Bringing public and private sector organisations together to build and share fibre infrastructure.
My work with CNI
My work within Cooperative Network Infrastructure is focussed on planning, delivering and maintaining CNI dark fibre infrastructure.
Related work
Explore the Brighton Fibre network build and the Brighton Digital Exchange for more on my work in fibre delivery and cooperative infrastructure.
Brighton Digital Exchange
Companies · Cooperative infrastructure
The Brighton Digital Exchange (BDX) is a group of digital businesses working together in innovative ways to improve the digital infrastructure available to the Brighton business community. At the heart of BDX is a cooperatively-owned and run data centre, where member businesses can peer and colocate equipment; and from which they can provide services to Brighton businesses and the world.
The Digital Exchange facility went live in July 2015. Member businesses can buy wholesale access to exchange facilities including rack space, peering with other local carriers, and fibre access to business units in New England House.
Dataroom Build
Once a supplier was selected and permissions were obtained we conducted the datacentre build. This involved a single dataroom with an adjacent plant room, and self-contained 'comms room' for carrier interconnections and those bringing fibre into the facility. Air conditioning condensers were obviously housed outside in a separate containment area, along with a diesel generator across the road.
Developing Access Control
Access control systems were developed to allow per-user access to each part of the facility, allowing sub-group access to the comms room or common ways.
Building Management System (BMS) Build-Out
A common BMS framework was used to aggregate signalling from the various datacentre sensor networks, such as environmental monitoring, CRAC (Computer Room Aircon) status, UPS levels, generator status etc. This BMS allows mainly read-access but also read-write access to various sub-facilities such as the intruder alarm.
Interconnection with Locally Present Carriers
In order to provide a resilient connection to customers and services within the facility, redundant connections were made to multiple ISPs carrying divergent fibre in the building. Redundant core routers established BGP sessions with core routers from other networks, in order to advertise our IP space with multiple ingress routes.
Testing Automatic Failover
Before putting services on top of the newly-established connectivity, I set up a number of throughput and redundancy tests to ensure that failure of fibre optic cable between core routers or carriers would not affect connectivity for customers and devices downstream. When the convergence time was suitably low for such a failure I was able to move toward readying services for deployment.
Core Services Racking Up
With everything else in place, servers are ready to be built and racked up. We used general purpose Dell servers with dual redundant ethernet (red primary and yellow secondary) and dual power connections such that any server can be easily moved between racks by detaching only one source cable at a time. Using the VRRP/HSRP protocol I brought convergence times down to less than one second for an ethernet cable swap.
Fibre Interconnection to Local Business Units
With core routers, edge routers and supplementary services tested and running resilient, I was able to connect our first customers in the building back to our shared Digital Exchange infrastructure and to provide a rock-solid 1Gbps broadband product to our existing customers there. We've since enjoyed a 100.00% uptime in the facility.
Caller Location Services in the 2015 Ebola Epidemic
Papers · Humanitarian technology
I was contacted by eHealth, the organisation in charge of the 117 ebola call centre in Sierra Leone to see how intelligence from mobile networks could be used to improve the operational response and analytical insights of the fight against ebola in Sierra Leone and beyond.
My work involved a number of technical and communications challenges. Primarily this involved establishing data exchange protocols with the incumbent mobile operators, such that subscriber call logs could be used to ascertain the cell site used to place a call to the 117 hotline. These data were then married up with call detail logs (CDRs) from the call logs from the call centre database in order to classify the nature and outcome of each ebola-related call.
These data were then combined to create a full event log allowing us to produce interactive heatmaps of ebola progression over time in the region and to cluster events by type (suspected cases, confirmed cases, deaths etc). The information was insightful in both confirming/expanding upon existing epidemic progression analysis, but also opened possibilities in terms of using similar data in future in order to help streamline the data collection needed to shed light on the rapid geographic progression of a virus throughout a region.
Some of my work on this subject was published in the proceedings of Humanitarian Technology 2015 Conference, the paper of which may be found here.
The presentation slides to this conference (our paper was presented by Co-Author Peter Eyres) can be found here.
Telephony Route Exchange Protocol
Papers · Standards & research
With a focus on bringing the worlds of Internetworking and Telecommunications closer, in 2015 I designed a protocol intended to bring the flexibility of the Internet's Border Gateway Protocol (BGP) to the more baroque and manual telecommunications industry.
In essence, I proposed a BGP for Telecoms.
We know that on the internet there are around half a million route entries - a table whose unwieldiness BGP sought to tame. In telecommunications there are a similar number, around 300,000 prefixes. However, these routes are not treated equally; unlike the net-netural approach of our Internet forefathers, they all come with their own specific set of features and criteria. Primarily this is the price per minute to terminate (connect) calls to the number, but this itself may vary, and may be billed per second, per minute, per connection, or any combination thereof. Numbers may be geographic, national, mobile, nomadic, or in one of many different sub-categories of national and international reachability.
It was this confusion which I hoped to hand over to the machines by drafting T.REX, a working group Request For Comments (RFC) in a format consistent with that which is expected by the internet's standards committees.
This is more of an academic endeavour, as I did not see it likely that competing networks would ever adopt a single, open standard unless their hands were forced. Telecoms pricing is still a very manual process - ratesheets are hammered out by salespeople meeting their opposite numbers in bars, a mixture of arbitrage, price-fixing and outright fraud produces a hastily-emailed Excel sheet the morning after. Deals are made in ways that ultimately cost consumers and businesses, and there will always be inertia to any automation of this process.
Nonetheless, please feel free to read my proposal to update this prehistoric industry here.
Typology of Loss in Cold Chain Vaccine Supply
Papers · Research & IoT
Cost effectiveness is critical to the success of immunisation programmes in developing countries. Being able to continuously, flexibly and accurately monitor the vaccine supply chain can help reduce the cost of operating it, and savings can be applied to deliver further resources to those that need them. In this project, we present a cloud-based continuous monitoring application for supervising the operation of the vaccine supply chain. The application utilises Internet of Things (IoT) location-aware platforms for data harvesting. Our contribution to this area is the design and development of a prototype continuous monitoring device capable of adapting its behaviour according to both the contexts it encounters as it passes along the vaccine supply chain and the constraints that it is given. Our prototype is sufficiently flexible to operate at different points in the supply chain, and can be used to track shipments and provide real-time remote monitoring.
By leveraging my relationships with MNOs globally we produced a SIM card which was able to roam across many networks and provide us up to date location information as cell sites were traversed. The equipment we build was also enabled with GPS monitoring where that was available.
The full paper, was was presented in the Proceedings of the Fifth ACM Symposium on Computing for Development can be found here.
Browse articles
Enable JavaScript to switch pages, or open an article directly: