Voice System Riding the Campus Core Network
A four-building university campus runs one networked emergency voice/alarm communication system: 96 nodes, 1,200 speakers, and a single system-wide operator console in the police dispatch center. The IT department requires the fire alarm to ride the shared campus core as a VLAN with DHCP addressing, arguing that a private fiber plant would duplicate infrastructure. During a scheduled core switch firmware upgrade, the stack rebooted three times; the fire panels logged network trouble, but voice evacuation messages originating in Building A could not reach Buildings C and D for 11 minutes, and the system did not revert to autonomous per-building operation. The two high-rise dormitories were designed for high pathway survivability per the engineer's basis of design, but the interbuilding fiber is a single non-rated strand pair run through a shared ceiling plenum. Battery calculations assume 24 hours standby plus 15 minutes of voice alarm. The AHJ has asked for a written narrative explaining what happens when the campus network is unavailable.
1. Characterize the failure modes this architecture creates and identify which are unacceptable for a voice evacuation system.
Read the worked answer
Separate network problems from life-safety problems. The network layer can fail by losing the link, by high latency or jitter, by packet loss that an audio codec hides as distortion, by address reassignment, and by policy change (firewall rules, QoS removal, VLAN pruning). Each of those is a normal IT event.
What is unacceptable:
- Loss of local protection. A building must not become less safe because a switch in another building rebooted. If the panel in Building C cannot receive a manual evacuation command from the console in Building A, it must still be able to initiate evacuation locally from its own initiating devices and its own operator interface. Autonomous operation on network loss is not optional; it is the whole mitigation.
- Silent degradation. An 11-minute gap with only a “network trouble” log entry - with no local annunciation and no notification to dispatch - is the real failure. Trouble must be visible where someone is looking.
- Non-deterministic timing. An audio system that depends on best-effort delivery cannot guarantee that a message starts when commanded or that it is intelligible.
What is tolerable: system-wide conveniences such as all-call paging, central console control of remote buildings, and mass notification scenarios that are not part of the fire response. Trade those away deliberately and document the trade.
Also check DHCP. A leased address means the node identity is not fixed. Static addressing or DHCP reservations are mandatory; fire alarm equipment should not depend on a lease renewal to stay in service.
2. Draft the technical requirements you would put in the integration agreement with IT.
Read the worked answer
Demarcation first. State exactly where the fire alarm vendor's responsibility ends and IT's begins, and name who is called at 2 a.m. Ambiguity at the demarcation is where outages live.
Transport requirements:
- A dedicated VLAN with no shared broadcast domain, or preferably a physically separate fiber plant. Physically separate is worth the cost; ask IT to price it before you accept a VLAN-only design.
- Static IP addressing for every node; no DHCP, no NAT between nodes.
- Priority treatment for the system's traffic, with a documented, tested configuration.
- No network address translation, no content inspection, no application-layer firewall in the signaling path.
Change management:
- Written notice before any firmware upgrade, spanning-tree change, ACL change, or core maintenance, with the fire alarm vendor present or on call.
- A mandatory post-change verification test: signal from each building to each other building, plus a live voice message, documented and signed.
- No upgrades during occupied hours without a documented risk acceptance.
Monitoring: both parties monitor the link; IT's alerts route to the fire alarm vendor, not only to a network operations dashboard nobody checks on weekends.
Performance: state the maximum acceptable message delivery latency and jitter, and the test that demonstrates it. If it is not stated and tested, it does not exist.
3. The interbuilding fiber is a single non-rated pair running through a shared plenum. How do you reconcile that with the survivability basis of design, and what do you tell the AHJ?
Read the worked answer
Do not paper over it. A single non-rated fiber does not satisfy a high survivability basis of design, and the narrative the AHJ asked for is the wrong place to start improvising.
Analyze the exposure honestly. A single path through a shared plenum means one fire, one construction crew, or one backhoe takes out every interbuilding function. The building-by-building autonomy described above mitigates the consequence for local evacuation, but does not restore cross-building notification, which the dormitory design likely relies on.
Options, in order of preference:
- Two physically separate paths, each with the required fire-resistive protection, routed so a single fire cannot take out both. This satisfies redundancy-based survivability and is usually the cheapest conforming answer.
- A single path protected by listed circuit integrity cable in a rated enclosure. Acceptable where a second route is genuinely impossible, but requires listed cable and a rated raceway - not plenum-rated fiber in a shared ceiling.
- A documented performance alternative: engineering analysis, fire modeling, and written AHJ acceptance. Treat this as a last resort with real schedule risk.
What you tell the AHJ: a short narrative stating the current configuration does not meet the basis of design, the acceptable options with the recommended one, the interim mitigation (local autonomy plus a documented notification procedure), and a date for the permanent fix. Volunteering the gap preserves credibility; having the AHJ discover it destroys it.