1
0 Comments

Inside the Infrastructure Millions Never See: How Communications Engineering Keeps New York's Subway Running

New York City's subway carried nearly 1.3 billion trips in 2025, a seven percent increase over the prior year and the system's strongest ridership since before the pandemic. On its busiest day last year, more than 4.65 million passengers moved through 472 stations spread along 665 miles of track. Every one of those trips depended on communications infrastructure that most riders never think about: the CCTV cameras that feed real-time footage to control centers, the public address systems that relay service alerts, the emergency elevator intercoms that connect riders with disabilities to help, and the networked switches that tie it all together. When these systems fail, safety fails with them.

We spoke with Savni Sandbhor, a Senior Project Manager at MKJ Communications, about what it takes to design, integrate, and commission these systems inside one of the oldest and busiest transit networks in the world. Sandbhor is a Senior IEEE member and with over 9 years of experience delivering mission-critical communications infrastructure for New York City Transit. Her portfolio spans more than two dozen subway stations and includes the deployment of over 1,000 networked surveillance devices across projects representing more than $100 million in capital investment. Below, she explains the engineering challenges that most people never see, and why getting them right matters for millions of daily riders.

Most people think of subway construction as concrete and steel. What does the communications side of a station project actually involve?

There is far more technology inside a subway station than riders realize. Every station requires a layered communications architecture that includes IP-based CCTV and video surveillance, Passenger Station Local Area Networks, public address systems, intercom and emergency elevator two-way communication systems, telephone infrastructure, and critical power systems that support life-safety operations. These are not off-the-shelf installations. Each system must be engineered for redundancy, failover, and interoperability within a live transit environment where service cannot be interrupted.

My work covers the full lifecycle: network design, IP addressing strategies, switch configuration, acceptance testing, and system validation. On a typical project, I am coordinating across multiple vendors, transit authority engineering divisions, construction management teams, and third-party manufacturers simultaneously. The goal is to make sure that every component, from a single camera to a full station LAN, functions as part of one cohesive system. If one link breaks, the entire safety chain is weakened.

You led the communications engineering for the ADA Package 1 contract, covering eight stations across all five boroughs. What made that project particularly challenging?

Scale and speed. We had to bring 18 elevators and their associated communications systems into service across eight different stations, each with its own physical constraints, legacy wiring, and coordination requirements. Managing one station is complex enough. Managing eight in parallel, across every borough of New York City, required a level of phasing and sequencing that left very little margin for error.

We divided the stations and elevators by type and phased the rollouts to meet the transit authority's deadlines. Each station needed a full communications package: CCTV coverage, emergency elevator two-way communication systems, network video recorders, telephone systems, and PS-LAN integration.

I was responsible for the engineering, field setup, programming, and system integration and testing on all of them. The project also became a training ground. I used it to develop three junior engineers into effective project managers, building the internal capability we needed to handle concurrent work streams.

This was the first package in the contract series, so the standards we established here became the reference point for future packages. That added a layer of responsibility beyond the immediate deliverables.

What does it mean to work as a systems integrator inside an active subway environment?

It means every engineering decision must account for the fact that trains are running, passengers are moving through the station, and you cannot shut anything down. The transit system operates 24 hours a day, seven days a week. There is no maintenance window where you can take a station offline and work freely.

Redundancy planning becomes non-negotiable. You design systems so that if one path fails, another picks up immediately. You stage your work in phases so that existing communications remain operational while new equipment is being installed and tested. And you validate everything in the field, because conditions underground do not always match what was drawn on paper.

I attend NYCT communications bulletins, cable routing and splicing reviews, and constructability evaluations where we assess network topology, fiber and copper pathways, grounding schemes, and labeling standards. These reviews happen before a single cable is pulled because errors at the planning stage compound rapidly once construction begins.

How do you approach the challenge of integrating modern technology into infrastructure that was built decades ago?

That is really the central problem I spend most of my time on. The subway system was designed in an era long before IP networks and digital surveillance existed. The physical environment, cable pathways, power feeds, and available space were all built for analog systems. Introducing modern technology into that environment requires a deep understanding of both the new systems and the legacy constraints.

For example, a station built in the early twentieth century was never designed to accommodate the power draw and heat output of networked video recorders and IP camera clusters. You have to engineer power solutions, ventilation considerations, and cable routing that work within walls and conduits that were never intended for this equipment. Getting that wrong creates a safety risk. Getting it right means passengers have reliable surveillance, clear public announcements, and functional emergency communications for decades to come.

My involvement in the broader engineering community reinforces this perspective. As an editorial board member for two SARC journals focused on economics, intelligence, technology, and public administration, I evaluate research that addresses how legacy public systems can adopt modern infrastructure responsibly. That work sharpens my thinking about the long-term maintainability of the systems I deploy.

You have worked on some of New York's most high-profile transit locations. What is different about engineering for a station like Times Square or Grand Central compared to a standard station?

The complexity multiplies. A station like Times Square is not one station. It is a complex of interconnected stations, mezzanines, and transfer passages serving multiple subway lines with tens of millions of annual passengers. The number of cameras, intercoms, PA zones, and network access points is significantly higher than a standard station. The coordination with other active construction projects happening in the same space adds another dimension entirely.

Grand Central presented similar challenges. The communications scope required careful integration with existing laser intrusion detection systems and power plants, in addition to the standard CCTV, PS-LAN, and telephone systems. At locations like these, any misconfiguration does not just affect one station. It can cascade across an interconnected transit complex.

These are the kinds of assignments where systems-level thinking matters most. You cannot design in isolation. Every decision about IP addressing, switch configuration, and cable routing must account for how the station complex operates as a whole.

How has your peer review work outside of your day-to-day engineering role influenced your professional approach?

Reviewing research forces a different kind of discipline. In my SARC peer review work, I evaluate papers on their methodological rigor, the validity of their conclusions, and whether their findings translate beyond their immediate context. That analytical habit carries directly into my engineering practice.

When I am reviewing a network plan or evaluating whether a system design will hold up under real-world conditions, I apply the same scrutiny. Does the design account for edge cases? Are the assumptions about traffic load and failover actually validated? Is the documentation clear enough that someone maintaining this system five years from now can understand why decisions were made?

Engineering and scholarly review share a common thread. Both require you to challenge assumptions, demand evidence, and accept that rigor takes longer but lasts.

With the MTA committing to making all stations ADA-accessible by 2055, what does the future of transit communications look like?

The accessibility mandate means a sustained, decades-long cycle of station modernization across the entire system. Every accessibility upgrade includes a communications component because elevators, escalators, and accessible pathways require emergency communication systems, surveillance coverage, and network connectivity. The volume of this work will only increase.

At the same time, technology is advancing. Higher-resolution cameras generate more data. IP-based public address systems require more bandwidth. Analytics platforms that can interpret video feeds in real time demand network architectures that can handle increasing throughput without latency. The systems we install today need to support capabilities that may not be deployed for another five or ten years.

The stations my team and I have helped modernize collectively serve more than 600 million cumulative passenger trips. That number will keep growing. The work of building and maintaining the communications infrastructure that keeps those passengers safe, informed, and connected to emergency services is not visible to the people who benefit from it. But it is the backbone of everything riders experience the moment they step underground.

on May 10, 2026
Trending on Indie Hackers
Priorities for launching a SaaS solo, with no budget User Avatar 226 comments I built a tool directory that doesn't pretend every founder has the same needs User Avatar 54 comments AI helped me ship faster. Then I forgot what my product actually does. User Avatar 33 comments I thought picking a voice for my app would take a day. It rebuilt everything. User Avatar 13 comments How I Run a 1.7M Product Search Engine at 66ms on a $0 Hosting Budget User Avatar 9 comments Most early-stage SaaS companies miss churn signals — here’s how to catch them early User Avatar 8 comments