Live Traffic Light Timing

Assumed Audience: anyone with an interest in delightful technology or technical estimation

On a trip to Beijing, I saw navigation apps included real-time traffic light updates. They show the live countdown to a change in the lights. An audible prompt lets you know of an impending change. This is particularly useful when some sequences involve wait times over 99s. I’d not seen this before, but seeing it in action was one of those rare delightful moments with technology.

I spent the rest of the journey wondering how the system might work. I haven’t been able to find a definitive answer, but here are my observations.

• The timings are accurate - within a second or so of traffic light changes.
• The timings appear on-screen well before visible range of the lights.
• The timings are available at minor intersections.
• The timings are available on an iPhone 13 (sold in China).
• The timings are available in Beijing.

Given the use of a regular phone, I ruled out custom hardware to receive timing signals from the lights. With timing available outside visible range of the lights, the system doesn’t rely on a camera. It might be possible to use the camera to read the visible countdown on most intersections, but that isn’t happening here. This leaves one option, timings communicated from a central traffic management system.

How challenging would it be to serve live traffic light timings for all traffic lights in the city? This felt like a fun estimation challenge.

• 100,000 lights in China, 70% isolated fixed timing (source)
• Shanghai (4000), Beijing (3000), Shenzhen (2500), Guangzhou (1300) (source)

The data I could find was for 2017, so lets assume this has doubled since then. 6,000 lights in Beijing is on a par with London so still feels low but we’ll use this estimate for now.

I’ll assume that a single message contains the timing for all phases of a set of lights. Assuming per second updates for each set of lights, a central system would need to send 6,000 messages a second. This would be an upper bound. I wouldn’t expect updates this often. An updated once per sequence would drop this figure to 6,000 messages a minute (100/s). A lower bound would be to provide updates whenever there are updates to phase timing. This could be one message per day, week, or even month. Because I’m looking at solution feasibility, I’m going to use the upper bound. 6,000 message per second.

Even at 6,000 messages per second, this doesn’t feel as magical as I had first assumed. In my head there were way more traffic lights. 6,000 messages per second would be a lot for a hobby server, but is well within the realms of technical possibility.

Another angle to consider could be the message size. I’ll start by assuming each update is 10kb of JSON. This is somewhat arbitrary and I’d expect messages to be smaller than this, but it’s a starting point. I’ll double my estimate to account for message headers etc. 6,000 messages per second at 20kb, we’d be looking at 120 megabytes/s. This again feels doable. My expectation is that the message rate and bandwidth required will be less than this.

In conclusion, it is workable to provide city-wide live traffic light timing from a central system.

I’ve always enjoyed estimation problems like this. If you can see any obvious flaws in my working, I’d love to hear from you. What did I miss?