System Design Description (SyDD) — ISO/IEC/IEEE 15289 — Description | IEEE 29148 §6.5
Generated 2026-03-27 — UHT Journal / universalhex.org
flowchart TB n0["system<br>Emergency Dispatch System"] n1["subsystem<br>Call Handling Subsystem"] n2["subsystem<br>Computer-Aided Dispatch Subsystem"] n3["subsystem<br>GIS Subsystem"] n4["subsystem<br>Radio Communications Subsystem"] n5["subsystem<br>Mobile Data Subsystem"] n6["subsystem<br>Records Management Subsystem"] n7["subsystem<br>Network Infrastructure Subsystem"] n0 -->|contains| n1 n0 -->|contains| n2 n0 -->|contains| n3 n0 -->|contains| n4 n0 -->|contains| n5 n0 -->|contains| n6 n0 -->|contains| n7
Emergency Dispatch System — Decomposition
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SUB-REQS-001 | The ESInet SIP Gateway SHALL terminate a minimum of 150 concurrent SIP sessions across voice, RTT, and video media types, with each session maintaining TLS 1.2+ mutual authentication and SRTP media encryption. Rationale: 150 concurrent SIP sessions matches the system-level capacity requirement SYS-REQS-001. TLS 1.2+ mutual authentication is required by NENA i3 security framework to prevent call injection and eavesdropping on the ESInet. SRTP encryption protects caller audio from interception, which is mandatory for calls involving law enforcement operations and domestic violence situations. | Test | subsystem, call-handling, esinet-sip-gateway, session-253 |
| SUB-REQS-002 | The ESInet SIP Gateway SHALL complete SIP INVITE processing, authentication validation, and media negotiation within 200ms of receiving the initial INVITE from the ESInet border control function. Rationale: The 200ms gateway processing budget is derived from the 2-second end-to-end target in SYS-REQS-002, allocating 10 percent of the total budget to protocol handling. This includes SIP parsing, TLS certificate validation, and SDP media negotiation. Exceeding 200ms at the gateway leaves insufficient budget for downstream ACD routing and ANI/ALI lookup within the 2-second system target. | Test | subsystem, call-handling, esinet-sip-gateway, session-253 |
| SUB-REQS-003 | The Automatic Call Distribution Engine SHALL route an incoming call to an available call-taker position within 500ms of receiving the session from the ESInet SIP Gateway, applying skill-based routing, geographic assignment, and load-balancing rules. Rationale: The 500ms ACD routing budget is allocated from the 2-second SYS-REQS-002 target after gateway processing. Skill-based routing ensures callers with specific language needs or call types reach qualified dispatchers. Geographic assignment routes callers to dispatchers familiar with their area. Load balancing prevents dispatcher burnout and ensures equitable workload distribution during sustained high-volume periods. | Test | subsystem, call-handling, acd-engine, session-253 |
| SUB-REQS-004 | The ANI/ALI Database Interface SHALL return caller location data to the Call-Taker Workstation within 2 seconds of call arrival, querying the appropriate location source (ALI database for wireline, MPC/GMLC for wireless Phase II, LIS via HELD for NG911) and selecting the best available location with uncertainty metadata. Rationale: The 2-second location delivery target consumes the remaining budget from SYS-REQS-002 after gateway and ACD processing. Multiple location source types must be queried because wireline ALI, wireless MPC/GMLC, and NG911 LIS use different protocols and return different accuracy levels. Uncertainty metadata is essential for dispatchers to understand whether the displayed location is accurate to a building or only to a cell sector. | Test | subsystem, call-handling, ani-ali, session-253 |
| SUB-REQS-005 | The Call Recording System SHALL capture 100% of emergency call audio from both caller and dispatcher channels with dual-redundant recording paths, storing recordings in G.711 or uncompressed PCM format with GPS/NTP-synchronised timestamps accurate to within 10ms. Rationale: 100 percent capture rate with dual redundancy derives from SYS-REQS-006. Any gap in recording creates an evidentiary hole that could invalidate prosecution of crimes reported via 911. G.711 or uncompressed PCM preserves audio fidelity required for voice identification and background-sound analysis. GPS/NTP timestamps accurate to 10ms enable synchronisation of caller and dispatcher audio channels for timeline reconstruction. | Test | subsystem, call-handling, call-recording, session-253 |
| SUB-REQS-006 | The Text-to-911 Gateway SHALL deliver incoming text messages to the assigned Call-Taker Workstation display within 1 second of receipt from the ESInet text control centre, supporting SMS, RTT per RFC 4103, and SIP MESSAGE transport protocols. Rationale: The 1-second text delivery target derives from SYS-REQS-009 equitable access mandate. Text-to-911 callers in active danger situations cannot tolerate multi-second message delivery delays. Support for SMS, RTT, and SIP MESSAGE covers the three transport protocols mandated by FCC for text-to-911 service, ensuring no text caller is excluded based on their device capabilities. | Test | subsystem, call-handling, text-to-911, session-253 |
| SUB-REQS-007 | When all call-taker positions are occupied and the queue depth exceeds 5 calls, the Automatic Call Distribution Engine SHALL initiate overflow routing to pre-configured backup PSAPs within 2 seconds, maintaining caller audio and location data through the transfer. Rationale: Overflow routing derives from SYS-REQS-005 availability and STK-NEEDS-007 mutual aid requirements. The 5-call queue threshold and 2-second activation target are based on NENA best practices for avoiding abandoned calls. Maintaining caller audio and location through transfer prevents callers from having to re-explain their emergency to the receiving PSAP, which is critical during high-stress situations. | Test | subsystem, call-handling, acd-engine, session-253 |
| SUB-REQS-008 | The Call-Taker Workstation SHALL simultaneously display the caller location on the GIS map, ANI/ALI data, active call controls, incident entry form, and protocol-guided interrogation script within 3 seconds of call presentation, across a minimum dual-monitor configuration at 1920x1080 resolution per display. Rationale: Simultaneous display of all call context derives from SYS-REQS-003 and SYS-REQS-004. Dispatchers must see location, caller identity, and incident entry simultaneously to avoid toggling between screens during time-critical calls. The 3-second presentation target ensures all context is visible before the dispatcher begins speaking. Dual 1920x1080 monitors are the minimum configuration to display map, ANI/ALI, and CAD panels without overlap. | Demonstration | subsystem, call-handling, workstation, session-253 |
| SUB-REQS-009 | The ESInet SIP Gateway SHALL operate in an active-active redundant configuration with stateful session replication, achieving failover to the standby gateway within 500ms without dropping active calls or requiring caller re-dial. Rationale: Active-active redundancy with 500ms failover derives from SYS-REQS-005. The ESInet SIP Gateway is the single entry point for all emergency calls and therefore the highest-criticality component. Stateful session replication ensures active calls survive gateway failure without requiring caller re-dial, which may be impossible if the caller is incapacitated. 500ms failover is achievable with modern SIP proxy clustering and prevents perceptible audio interruption. | Test | subsystem, call-handling, esinet-sip-gateway, session-253 |
| SUB-REQS-010 | The Incident Management Engine SHALL create, classify, and assign a priority level to an incoming incident within 500ms of receiving the incident creation request from the Call-Taker Workstation, applying NIMS-compliant incident type codes and one of three priority levels (Emergency, Urgent, Routine). Rationale: 500ms response time derived from NFPA 1221 standard requiring dispatch processing within 60 seconds total; each pipeline stage must contribute minimal latency. NIMS-compliant incident type codes required by FEMA for all emergency management agencies receiving federal funding. Three-tier priority enables differential response protocols. | Test | subsystem, cad, incident-management, session-255 |
| SUB-REQS-011 | The Incident Management Engine SHALL support a minimum of 500 concurrent active incidents with independent state machines, each tracking state transitions through Created, Dispatched, En Route, On Scene, Resolved, and Closed with sub-second transition latency. Rationale: 500 concurrent incidents sized for worst-case major metropolitan area during a large-scale event where multiple PSAPs consolidate. Independent state machines prevent cross-incident state corruption during high-tempo operations. Sub-second transition latency ensures dispatchers see current state without delays that could cause duplicate dispatches. | Test | subsystem, cad, incident-management, session-255 |
| SUB-REQS-012 | When two or more incidents are identified as referring to the same event, the Incident Management Engine SHALL merge them into a single parent incident within 2 seconds, preserving all original call records, assigned units, and timeline entries from each source incident. Rationale: Duplicate 911 calls for the same event are common — a highway accident may generate 20+ calls. Without merge, separate incidents consume separate units, depleting resources. 2-second threshold ensures merge does not delay primary dispatch. Preservation of all source records required for legal discovery and after-action review. | Test | subsystem, cad, incident-management, session-255 |
| SUB-REQS-013 | The Dispatch Decision Support Module SHALL generate a ranked list of at least 3 candidate unit assignments within 2 seconds of incident creation, using road-network travel-time estimation, unit capability matching, current unit workload, and historical response-time data for the incident location. Rationale: Road-network travel time is critical because actual response in urban environments can be 3-5x the straight-line estimate due to one-way streets, bridges, and traffic. 2-second computation window sized to keep total call-to-dispatch time within NFPA 1221 standards. Minimum 3 candidates gives dispatcher meaningful choice without overwhelming under time pressure. | Test | subsystem, cad, dispatch-decision-support, session-255 |
| SUB-REQS-014 | When no dispatcher action is taken on a Priority Emergency incident within 30 seconds of recommendation presentation, the Dispatch Decision Support Module SHALL automatically dispatch the top-ranked available unit and present a confirmation alert to the assigned dispatcher workstation. Rationale: NFPA 1221 requires call-to-dispatch within 60 seconds for 90% of emergency calls. A 30-second timeout on Priority Emergency incidents provides a safety net if the dispatcher is overloaded, ensuring life-threatening calls are never indefinitely queued. Confirmation alert maintains situational awareness and allows override. | Test | subsystem, cad, dispatch-decision-support, session-255 |
| SUB-REQS-015 | The Dispatch Decision Support Module SHALL apply configurable run-card rules that specify mandatory multi-unit response compositions for each incident type, and SHALL alert the dispatcher when the recommended assignment does not fulfil the run-card minimum (e.g., structure fire requiring 2 engines, 1 ladder, 1 battalion chief, 2 ambulances). Rationale: Run cards define minimum resource composition per incident type based on fire service doctrine and mutual aid agreements. A structure fire missing a ladder company directly endangers lives. Alerting the dispatcher when the recommendation falls short of run-card minimum prevents under-resourcing due to unit unavailability being silently accepted. | Test | subsystem, cad, dispatch-decision-support, session-255 |
| SUB-REQS-016 | The Unit Tracking and Status Module SHALL ingest AVL position updates from a minimum of 2000 simultaneous field units at 5-second reporting intervals, with end-to-end latency from GPS fix to map display position update not exceeding 3 seconds. Rationale: 2000 simultaneous units sized for a large metropolitan dispatch center serving multiple agencies. 5-second AVL reporting interval balances position accuracy with cellular/MDT bandwidth. 3-second end-to-end latency ensures the map view is current enough for accurate nearest-unit recommendations. | Test | subsystem, cad, unit-tracking, session-255 |
| SUB-REQS-017 | The Unit Tracking and Status Module SHALL maintain and update unit status codes (Available, Dispatched, En Route, On Scene, At Hospital, Out of Service) within 1 second of status change receipt, and SHALL record each transition with timestamp and source (MDT automatic, MDT manual, dispatcher-initiated) in the unit activity log. Rationale: 1-second status update latency ensures the recommendation engine does not suggest units that are out-of-service or already dispatched. Recording transition source (MDT automatic vs manual vs dispatcher-initiated) is essential for after-action review — disputes about response time often hinge on when a unit actually went en-route vs when marked. | Test | subsystem, cad, unit-tracking, session-255 |
| SUB-REQS-018 | The Dispatcher Workstation Interface SHALL present an integrated display combining the GIS map with real-time unit positions, active incident list sorted by priority and age, recommended unit assignments, and radio channel status, with display refresh latency not exceeding 500ms for position updates across a minimum of 4 simultaneous monitors per dispatch position. Rationale: Integrated display eliminates context-switching between separate applications during emergencies that costs seconds accumulating into delayed response. 500ms position refresh derived from human perceptual threshold for smooth map movement. 4-monitor minimum reflects PSAP ergonomic standards for simultaneous views of map, incident queue, unit status, and radio controls. | Demonstration | subsystem, cad, dispatcher-workstation, session-255 |
| SUB-REQS-019 | The Dispatcher Workstation Interface SHALL support single-keystroke dispatch confirmation and common status update commands, enabling a dispatcher to accept the top-ranked unit recommendation and dispatch it without mouse interaction, completing the dispatch action within 2 keystrokes from recommendation display. Rationale: During peak operations a dispatcher handles 40+ incidents per hour. Mouse workflows add 3-5 seconds per action; keystroke dispatch eliminates this overhead. 2-keystroke maximum derived from cognitive ergonomics research showing more keystrokes increase error rate under stress. Directly supports NFPA 1221 call-to-dispatch targets. | Demonstration | subsystem, cad, dispatcher-workstation, session-255 |
| SUB-REQS-020 | The CAD Database and Event Logger SHALL sustain a minimum of 5000 write transactions per minute during peak operations, using synchronous replication to a standby database node with automatic failover completing within 10 seconds and zero committed transaction loss. Rationale: 5000 writes/minute derived from peak load: 500 concurrent incidents generating 10 state transitions per minute each. Synchronous replication with zero committed transaction loss is mandatory because incident records are legal evidence — a lost dispatch record could invalidate court proceedings. 10-second failover ensures brief interruption without losing dispatcher capability. | Test | subsystem, cad, database, session-255 |
| SUB-REQS-021 | The CAD Database and Event Logger SHALL encrypt all data at rest using AES-256 and implement role-based access controls compliant with CJIS Security Policy v5.9, including multi-factor authentication for administrative access and audit logging of all data access events. Rationale: CJIS Security Policy v5.9 is federally mandated for all systems accessing criminal justice information through FBI NCIC, NLETS, or state equivalents. Non-compliance results in loss of access to warrant checks, stolen vehicle databases, and wanted person records essential for officer safety. AES-256 at rest protects against physical media theft. | Inspection | subsystem, cad, database, cjis, session-255 |
| SUB-REQS-022 | The Supervisor Dashboard Module SHALL display call queue depth, oldest-waiting-call age, average and 95th-percentile response times by incident type, unit utilisation by district, and active incident count by priority, refreshing all metrics at 5-second intervals per SYS-REQS-007, and SHALL trigger visual and audible alerts when queue depth exceeds 5 calls or oldest-waiting-call exceeds 60 seconds. Rationale: Supervisors must detect dispatch bottlenecks in real-time to activate mutual aid or redistribute workload. 5-second refresh aligns with SYS-REQS-007. Queue depth >5 and oldest-call >60s thresholds derived from NFPA 1221 — exceeding these indicates the PSAP is falling behind service-level obligations and needs immediate intervention. | Demonstration | subsystem, cad, supervisor-dashboard, session-255 |
| SUB-REQS-023 | The Dispatch Radio Console SHALL support simultaneous monitoring of a minimum of 24 talk groups and 4 conventional channels, with independent volume control and audio routing per channel, and SHALL allow the dispatcher to transmit on any monitored channel within 100ms of PTT activation. Rationale: 24 simultaneous talk groups reflects typical large PSAP configuration monitoring fire, EMS, law enforcement, mutual aid, tactical, and administrative channels across jurisdictions. 4 conventional channels for legacy analog interoperability with volunteer departments. 100ms PTT latency is the maximum acceptable for real-time voice without perceivable delay disrupting natural speech. | Test | subsystem, radio-comms, dispatch-radio-console, session-256 |
| SUB-REQS-024 | When a field unit activates an emergency alert on any monitored talk group, the Dispatch Radio Console SHALL immediately unmute that channel, display a visual emergency indicator with the unit ID and talk group, and generate an audible alarm within 500ms of alert reception. Rationale: Emergency alerts from field units (officer down, firefighter mayday) are the highest-priority radio events — delayed notification directly endangers lives. 500ms ensures the dispatcher is alerted within one heartbeat. Automatic unmute prevents the alert from being missed when the channel is muted during multi-talk-group monitoring. | Test | subsystem, radio-comms, dispatch-radio-console, session-256 |
| SUB-REQS-025 | The Radio Gateway Controller SHALL bridge a minimum of 48 simultaneous voice paths between IP-connected dispatch consoles and the P25 trunked radio infrastructure, converting between G.711 mu-law and IMBE vocoder formats with no more than 50ms transcoding latency per direction. Rationale: 48 simultaneous voice paths sized for 24 dispatch positions with 2 concurrent transmissions each. G.711 to IMBE transcoding mandatory because IP dispatch uses G.711 while P25 trunked radio uses IMBE vocoder. 50ms transcoding latency ensures total end-to-end stays under 150ms, well below ITU 250ms conversational threshold. | Test | subsystem, radio-comms, radio-gateway-controller, session-256 |
| SUB-REQS-026 | The Radio Gateway Controller SHALL operate in an active-standby redundant configuration with stateful session replication, achieving automatic failover within 2 seconds with no loss of active voice paths and no dropped PTT transmissions. Rationale: Loss of the radio gateway during an active emergency severs communications between dispatchers and field units. 2-second failover ensures brief interruption that does not cause PTT timeouts. Stateful session replication prevents active calls from being torn down, critical during multi-agency incidents where re-establishment would require manual intervention from multiple positions. | Test | subsystem, radio-comms, radio-gateway-controller, session-256 |
| SUB-REQS-027 | The Talkgroup Management Module SHALL support configuration of a minimum of 500 talk groups across 32 zones, and SHALL complete dynamic talk group patch creation (connecting 2 or more talk groups for cross-channel audio) within 3 seconds of dispatcher request. Rationale: 500 talk groups across 32 zones reflects a regional system serving multiple jurisdictions and mutual aid agreements. 3-second dynamic patch creation enables dispatchers to bridge talk groups during emerging incidents without delay that would leave field units unable to communicate cross-agency during critical first minutes. | Test | subsystem, radio-comms, talkgroup-management, session-256 |
| SUB-REQS-028 | When a Priority Emergency call is received by the CAD, the Talkgroup Management Module SHALL automatically affiliate the assigned dispatch position with the incident talk group within 1 second, without requiring manual channel selection by the dispatcher. Rationale: Manual channel selection during high-tempo dispatch adds cognitive load and introduces errors where a dispatcher transmits on the wrong talk group. Automatic affiliation upon CAD dispatch confirmation ensures the dispatcher is immediately on the correct channel, supporting the 2-keystroke workflow in SUB-REQS-019. | Test | subsystem, radio-comms, talkgroup-management, session-256 |
| SUB-REQS-029 | The Interoperability Gateway SHALL support a minimum of 48 simultaneous cross-patched talk groups across ISSI (Inter-RF Subsystem Interface) connections to a minimum of 8 external P25 systems from different vendors, operating across VHF, UHF, and 700/800 MHz frequency bands. Rationale: Multi-agency mutual aid incidents require interoperability across jurisdictions using different P25 systems from different vendors. 48 simultaneous cross-patches sized for a major incident with 6 patches each across 8 partner systems. Multi-band (VHF/UHF/700-800 MHz) reflects real frequency allocations — federal on VHF, local LE on 800 MHz, rural fire on UHF. | Test | subsystem, radio-comms, interoperability-gateway, session-256 |
| SUB-REQS-030 | The Interoperability Gateway SHALL implement ISSI Group Call, Unit-to-Unit Call, and Emergency Alert services per TIA-102.BACA-A, and SHALL propagate emergency alerts from external systems to the Dispatch Radio Console within 1 second of reception. Rationale: TIA-102.BACA-A is the P25 standard for inter-system interoperability — compliance required for connection to partner networks. Emergency alert propagation within 1 second across system boundaries ensures a mayday from a mutual aid unit on an external system is immediately visible, preventing delayed response to personnel in distress. | Test | subsystem, radio-comms, interoperability-gateway, session-256 |
| SUB-REQS-031 | The Radio Logging Recorder SHALL capture 100% of radio transmissions across all monitored talk groups with audio quality of minimum 8 kHz sample rate and 16-bit depth, recording transmitter unit ID, talk group ID, RF site ID, and GPS-synchronized timestamp (UTC, accuracy within 10ms) for each transmission. Rationale: 100% capture with no missed transmissions required for evidentiary chain of custody — recorded radio traffic is used in criminal proceedings, internal affairs, and liability cases. 8 kHz/16-bit maintains intelligibility above P25 IMBE native quality. GPS-synchronized 10ms timestamps enable precise correlation with CAD events and body camera footage. | Test | subsystem, radio-comms, radio-logging-recorder, session-256 |
| SUB-REQS-032 | The Radio Logging Recorder SHALL retain all radio transmission recordings for a minimum of 7 years with tamper-evident storage, and SHALL support instant replay of the last 60 seconds of any monitored talk group from the dispatcher console within 2 seconds of request. Rationale: 7-year retention aligned with the longest common state records retention schedule for public safety communications. Tamper-evident storage mandatory for evidentiary integrity — recordings must be admissible in court. 2-second instant replay enables dispatchers to re-hear a garbled field transmission without leaving position or disrupting workflow. | Test | subsystem, radio-comms, radio-logging-recorder, session-256 |
| SUB-REQS-033 | The Encryption Key Management Module SHALL manage AES-256 traffic encryption keys (TEKs) and key encryption keys (KEKs) for a minimum of 5000 subscriber radios, supporting scheduled key rotation at configurable intervals (minimum daily) and emergency key zeroization of individual units or groups within 30 seconds of operator command. Rationale: 5000 subscriber radios reflects a large metropolitan agency fleet. Daily TEK rotation limits exposure if a key is compromised through a lost or stolen radio. 30-second emergency zeroization is critical when a radio is confirmed lost in a hostile environment — delayed key erasure could allow adversary monitoring of encrypted law enforcement communications. | Test | subsystem, radio-comms, encryption-key-management, session-256 |
| SUB-REQS-034 | The Encryption Key Management Module SHALL support Over-the-Air Rekeying (OTAR) per TIA-102.AACA for TEK distribution to field radios without requiring physical key loading, and SHALL confirm successful rekey of each targeted radio within 60 seconds of initiation. Rationale: Physical key loading requires each radio to be brought to a secure facility, consuming hours for a 5000-radio fleet. OTAR per TIA-102.AACA enables daily rotation without physical access, operationally essential for continuous field deployment. 60-second per-radio confirmation ensures the rekey completes within a manageable window. | Test | subsystem, radio-comms, encryption-key-management, session-256 |
| SUB-REQS-035 | The Map Tile Server SHALL serve raster and vector map tiles at a sustained rate of 200 concurrent tile requests with 95th-percentile response time not exceeding 200ms, supporting smooth pan and zoom across a minimum of 24 simultaneous dispatcher workstation map views. Rationale: The Map Tile Server must sustain 200 concurrent tile requests because a busy PSAP with 20 dispatch positions generates approximately 10 tile requests per second per workstation during active pan/zoom. 200ms 95th-percentile response time ensures smooth visual rendering — above this threshold, dispatchers perceive map lag that slows incident location identification. Raster and vector tile support enables both high-detail aerial imagery and fast-rendering road maps. | Test | subsystem, gis, session-257 |
| SUB-REQS-036 | The Geocoding Engine SHALL resolve street addresses, intersections, and common place names to WGS84 coordinates within 200ms with accuracy within 50 meters of the physical location, validating against the local MSAG (Master Street Address Guide) and returning MSAG-valid ESN (Emergency Service Number) for each resolved address. Rationale: The Geocoding Engine is the critical link between textual addresses from callers/ALI and map coordinates for dispatch. 200ms resolution time enables real-time geocoding as the call-taker types. 50-metre accuracy ensures the dispatched unit arrives at the correct building in urban areas. MSAG validation catches invalid addresses before units are dispatched to non-existent locations, reducing wasted response time. | Test | subsystem, gis, session-257 |
| SUB-REQS-037 | The Routing Engine SHALL compute road-network travel time estimates between any two points within the dispatch jurisdiction within 500ms, using a weighted road graph incorporating speed limits, one-way restrictions, turn prohibitions, and historical emergency response time data, with route accuracy within 10% of actual drive time for 90% of routes. Rationale: The Routing Engine provides travel time estimates that the Dispatch Decision Support Module uses to recommend the closest available unit. 500ms computation time is acceptable because route calculation happens after unit selection narrows candidates to 3-5 units. Incorporating speed limits, one-way restrictions, and real-time conditions prevents dispatching units along routes that are slower than alternatives, directly affecting emergency response time. | Test | subsystem, gis, session-257 |
| SUB-REQS-038 | The Spatial Database SHALL support point-in-polygon queries completing within 50ms to determine the ESZ, fire management zone, police beat, and EMS response area for any incident coordinate, using spatial indexes over a minimum of 20 geographic overlay layers. Rationale: Point-in-polygon queries determine which response zones (ESZ, fire district, police beat, EMS area) contain a given incident location. This determines which agencies and units are dispatched. 50ms query time ensures zone lookup does not delay the call processing pipeline. Spatial indexing (R-tree or GeoHash) is necessary because polygon boundary complexity in metropolitan jurisdictions makes brute-force computation too slow for real-time use. | Test | subsystem, gis, session-257 |
| SUB-REQS-039 | When the Spatial Database is updated with new geographic data, the Map Tile Server SHALL regenerate affected tile caches within 30 minutes and the Geocoding Engine SHALL reload its address index within 15 minutes, without interrupting service to active dispatcher sessions. Rationale: When ESZ boundaries or road networks change, outdated map tiles or address indexes could cause dispatchers to see incorrect zone assignments or geocoding failures. 30-minute tile cache regeneration ensures dispatchers see current boundaries within one shift. 60-minute address index reload balances index rebuild time against currency requirements. Without automated propagation, manual cache clearing is error-prone and risks dispatching to wrong jurisdictions. | Test | subsystem, gis, session-257 |
| SUB-REQS-040 | The Mobile Data Gateway Server SHALL maintain authenticated sessions with a minimum of 200 concurrent mobile data terminals, with per-session TLS 1.2+ encryption and session re-establishment within 3 seconds of connectivity restoration. Rationale: A metropolitan PSAP may have 200+ field units across police, fire, and EMS. The Mobile Data Gateway Server must maintain concurrent sessions with all of them. TLS 1.2+ encryption is mandated by CJIS Security Policy for data in transit. 30-second re-establishment time after disconnection limits the window during which a field unit cannot receive dispatch updates, which is critical when units are en route to emergencies. | Test | subsystem, mobile-data, gateway, session-258 |
| SUB-REQS-041 | When an MDT loses cellular connectivity, the Mobile Data Gateway Server SHALL queue all pending messages for that unit for a minimum of 30 minutes and deliver them in chronological order within 5 seconds of connectivity restoration. Rationale: FirstNet LTE coverage gaps occur in parking garages, building interiors, and rural fringe areas. Queuing messages for 30 minutes covers the typical duration of an on-scene event where the MDT may lose cellular connectivity. Chronological delivery ensures the field unit receives dispatch updates in the correct order (e.g., hazard update before cancellation). 5-second delivery after reconnection minimizes the stale-information window. | Test | subsystem, mobile-data, gateway, session-258 |
| SUB-REQS-042 | The Mobile Data Terminal Application SHALL display a complete dispatch assignment (incident type, address, cross street, caller information, hazard flags, responding units, and tactical notes) within 2 seconds of receipt from the Mobile Data Gateway Server. Rationale: Field units need complete dispatch information on the MDT screen within 3 seconds of radio dispatch to avoid requesting repeat information over the radio channel, which consumes shared airtime. The full information set (incident type, address, cross street, caller info, hazard flags, responding units, tactical notes) is what responders need to begin response planning en route. Hazard flags (violent subject, HazMat, structural collapse) are safety-critical. | Test | subsystem, mobile-data, mdt, session-258 |
| SUB-REQS-043 | The Automatic Vehicle Location Module SHALL transmit GPS position reports with unit identifier and UTC timestamp at a configurable interval of 5 to 60 seconds, with a default of 10 seconds for in-service units and 60 seconds for out-of-service units. Rationale: GPS position reports with unit ID and UTC timestamp are the minimum data set for the Unit Tracking and Status Module to plot field units on the dispatch map. Configurable intervals (5-60 seconds) balance position currency against cellular bandwidth — 10-second default provides adequate tracking resolution for urban response while limiting FirstNet data consumption. Faster intervals for in-service units enable more accurate arrival time predictions. | Test | subsystem, mobile-data, avl, session-258 |
| SUB-REQS-044 | The Automatic Vehicle Location Module SHALL achieve position accuracy of 3 metres CEP under open-sky conditions and 10 metres CEP in urban environments with multipath interference. Rationale: 3-metre CEP under open sky matches commercial GPS receiver specifications and is sufficient for vehicle-level positioning. 10-metre CEP in urban environments accounts for multipath from buildings and signal attenuation. These values enable the dispatch decision support module to correctly identify which unit is closest to an incident — position errors exceeding 10 metres in dense urban areas could cause incorrect closest-unit recommendations. | Test | subsystem, mobile-data, avl, session-258 |
| SUB-REQS-045 | The CJIS Query Proxy SHALL process NCIC/state criminal justice database queries from authenticated field MDTs and return results within 3 seconds of query submission under normal network conditions. Rationale: Field officers need NCIC query results within 3 seconds to maintain situational safety during traffic stops and field contacts. Beyond 3 seconds, officers may proceed without criminal history information, creating a safety risk. The CJIS Query Proxy handles query routing, response parsing, and audit logging as a centralized control point, which simplifies CJIS compliance auditing compared to distributed query endpoints. | Test | subsystem, mobile-data, cjis, session-258 |
| SUB-REQS-046 | The CJIS Query Proxy SHALL enforce CJIS Security Policy v5.9 requirements including FIPS 140-2 validated encryption for data at rest and in transit, advanced authentication for all query operators, and immutable audit logging of every query with operator ID, query type, timestamp, and result disposition. Rationale: CJIS Security Policy v5.9 is a mandatory federal compliance requirement for any system accessing criminal justice databases. FIPS 140-2 encryption, advanced authentication, and comprehensive audit logging are the three pillars of CJIS compliance. The CJIS Query Proxy is the PSAP's boundary for criminal justice data — if it fails compliance, the entire agency loses NCIC access, preventing field officers from running wants/warrants checks. | Inspection | subsystem, mobile-data, cjis, session-258 |
| SUB-REQS-047 | The FirstNet LTE Communications Module SHALL operate on Band 14 (758-768 MHz / 788-798 MHz) with Quality Priority and Preemption (QPP) enabled, maintaining data connectivity for public safety traffic when commercial network capacity is exhausted. Rationale: Band 14 is the dedicated FirstNet public safety spectrum allocated by the FCC Middle Class Tax Relief and Job Creation Act of 2012. QPP ensures public safety data traffic is prioritised over commercial users during network congestion. Operating on Band 14 is mandatory for FirstNet subscriber devices. Maintaining connectivity during commercial network congestion events (concerts, disasters) is critical because those are precisely the events generating the highest emergency call volumes. | Test | subsystem, mobile-data, firstnet, session-258 |
| SUB-REQS-048 | When Band 14 FirstNet coverage is unavailable, the FirstNet LTE Communications Module SHALL automatically roam to commercial LTE networks within 10 seconds, maintaining all active data sessions without requiring MDT operator intervention. Rationale: FirstNet Band 14 coverage does not reach all areas, particularly rural zones and building interiors. Automatic roaming to commercial LTE within 10 seconds ensures field units maintain data connectivity for dispatch and CJIS queries. Session persistence prevents loss of in-progress CJIS query results or dispatch acknowledgments during the handover. Without automatic roaming, units in coverage gaps would lose all MDT functionality. | Test | subsystem, mobile-data, firstnet, session-258 |
| SUB-REQS-049 | The Mobile Data Terminal Application SHALL provide one-touch status update capability allowing field units to transmit status changes (En Route, On Scene, Available, Out of Service) to the CAD system within 1 second of operator input. Rationale: Field units spend significant time on status updates (arriving on scene, going available, going out of service). One-touch status updates reduce the time officers spend interacting with the MDT while driving, improving safety. Sub-2-second update propagation to CAD ensures dispatchers see current unit status and can make correct dispatch decisions — stale status data leads to dispatching units that are already committed to other incidents. | Test | subsystem, mobile-data, mdt, session-258 |
| SUB-REQS-050 | The Incident Report Database SHALL store a minimum of 10 years of incident records (approximately 1 million records per year for a metropolitan PSAP) with full-text indexing and maintain query response times of 2 seconds or less for single-field searches. Rationale: State records retention statutes typically require 7-10 years of incident record retention. A metropolitan PSAP handling approximately 1 million incidents per year accumulates significant data volume. Sub-5-second query response on 10 years of data is necessary for investigative searches during active incidents where officers need prior incident history at a location. Full-text indexing enables narrative field searches that structured queries cannot satisfy. | Test | subsystem, records-management, session-258 |
| SUB-REQS-051 | The Retention and Purge Manager SHALL enforce configurable retention schedules per record type (incident reports, audio recordings, CAD event logs, radio transmissions) and SHALL suspend purge operations for any record subject to an active legal hold, producing a certified purge audit log with cryptographic hash verification for each deletion batch. Rationale: Records retention compliance is mandated by state law and subject to audit. Configurable schedules are necessary because different record types have different retention periods set by statute. Legal hold suspension prevents destruction of records subject to litigation or active investigation, which would constitute spoliation of evidence. Without automated purge management, manual deletion is error-prone and risks either premature destruction or unbounded storage growth. | Test | subsystem, records-management, session-258 |
| SUB-REQS-052 | The Report Generation Module SHALL generate FBI UCR and NIBRS-compliant submissions from incident data without manual data entry, producing monthly statistical reports within 4 hours of scheduled execution for datasets exceeding 100,000 incidents. Rationale: FBI UCR and NIBRS submissions are federal reporting mandates for law enforcement agencies. Automated generation eliminates manual data entry errors that have historically caused agencies to submit incorrect crime statistics. 4-hour execution time for monthly reports is acceptable for overnight batch processing. Without automated reporting, records staff spend 2-3 days per month on manual data extraction and formatting. | Test | subsystem, records-management, session-258 |
| SUB-REQS-053 | The Records Search and Retrieval Engine SHALL enforce role-based access control with a minimum of 5 permission tiers (public records clerk, investigator, supervisor, records administrator, system administrator) and SHALL automatically redact sealed juvenile records, protected witness information, and undercover officer identities from search results for unauthorized roles. Rationale: Role-based access control with 5 tiers prevents unauthorized access to sensitive records. Sealed juvenile records and protected caller information (domestic violence victims, informants) have legal restrictions on who may view them. Without granular RBAC, either everyone has access to sensitive records (legal violation) or access is so restricted that authorized personnel cannot perform their duties. The 5-tier structure maps to common PSAP organisational roles. | Test | subsystem, records-management, session-258 |
| SUB-REQS-054 | The Incident Report Database SHALL encrypt all data at rest using AES-256 with key management compliant with CJIS Security Policy v5.9, and SHALL maintain encrypted automated backups with a recovery point objective (RPO) of 1 hour and recovery time objective (RTO) of 4 hours. Rationale: CJIS Security Policy requires AES-256 encryption for criminal justice data at rest. The Incident Report Database contains caller PII, witness information, and linked CJIS query results that are subject to this policy. RPO of 15 minutes limits data loss to at most one major incident's worth of records. Without encrypted backups, a stolen backup tape would expose protected criminal justice information. | Test | subsystem, records-management, session-258 |
| SUB-REQS-055 | The Core LAN Switching Fabric SHALL achieve 99.999% availability measured annually through dual redundant core switches in an active-active topology with sub-50ms failover via Virtual Switching System or equivalent chassis redundancy, ensuring zero packet loss during any single switch or link failure. Rationale: NFPA 1221 requires 99.999% availability for PSAP communications infrastructure. The Core LAN carries all inter-subsystem traffic including life-safety SIP calls — any LAN failure causes total PSAP outage. Active-active topology with sub-50ms failover ensures no call-in-progress is dropped during a single switch failure. This is the most critical availability requirement in the system because every other subsystem depends on LAN connectivity. | Test | subsystem, network-infrastructure, core-lan, session-259, duplicate-of-SUB-REQS-056 |
| SUB-REQS-056 | The Core LAN Switching Fabric SHALL achieve 99.999% availability measured annually through dual redundant core switches in an active-active topology with sub-50ms failover via Virtual Switching System or equivalent chassis redundancy, ensuring zero packet loss during any single switch or link failure. Rationale: DUPLICATE OF SUB-REQS-055: This requirement duplicates the Core LAN Switching Fabric availability requirement. Tagged for removal during next review. | Test | subsystem, network-infrastructure, core-lan, session-259 |
| SUB-REQS-057 | The Core LAN Switching Fabric SHALL enforce VLAN segmentation with a minimum of four isolated network zones: voice/SIP signalling, CAD/records data, CJIS-restricted traffic, and network management, with inter-VLAN traffic permitted only through the Firewall and Intrusion Prevention System. Rationale: CJIS Security Policy v5.9 mandates network segmentation between CJIS-connected systems and other network traffic. Inter-VLAN ACLs prevent lateral movement if one zone is compromised. Voice VLAN isolation ensures QoS for emergency calls. Four zones is the minimum: voice (SIP/RTP), data (CAD/Records), CJIS (criminal justice queries), and management (SNMP/syslog). Without segmentation, a compromised workstation could access NCIC databases directly. | Test | subsystem, network-infrastructure, core-lan, session-259 |
| SUB-REQS-058 | The Core LAN Switching Fabric SHALL provide minimum 10 Gbps aggregate inter-switch link capacity and 1 Gbps to each access port, with Quality of Service policies guaranteeing strict priority queuing for voice VLANs with maximum 5ms one-way latency and less than 0.1% packet loss under full load. Rationale: 10 Gbps inter-switch capacity supports concurrent traffic from 150 SIP sessions (each ~100 Kbps = 15 Mbps), GIS tile serving (burst to 500 Mbps), CAD database replication, and CJIS query traffic. 1 Gbps access ports serve individual workstations and servers. Strict priority queuing for DSCP EF voice traffic guarantees that data bursts cannot cause voice jitter, which is essential for call-taker comprehension during stressful incidents. | Test | subsystem, network-infrastructure, core-lan, session-259 |
| SUB-REQS-059 | The WAN and ESInet Gateway SHALL maintain dual redundant WAN uplinks from physically diverse carriers with automatic failover via VRRP or HSRP, achieving route convergence within 5 seconds of primary carrier failure without dropping active SIP sessions or requiring ESInet re-registration. Rationale: Dual diverse-carrier WAN uplinks are required because the ESInet is the sole ingress path for NG9-1-1 calls. A single-carrier failure (fiber cut, provider outage) would cause complete loss of emergency call reception. 5-second convergence via VRRP/HSRP ensures callers experience at most one ring-back delay during failover. Physical carrier diversity means independent last-mile paths to the PSAP. | Test | subsystem, network-infrastructure, wan-esinet, session-259 |
| SUB-REQS-060 | The WAN and ESInet Gateway SHALL implement BGP peering with the ESInet service provider and policy-based routing that prioritises NG9-1-1 SIP INVITE and BYE signalling traffic over all other WAN flows, with a minimum committed information rate of 100 Mbps per WAN link. Rationale: BGP peering with the ESInet provider is the standard routing protocol for NG9-1-1 interconnection. Policy-based routing prioritising SIP INVITE and BYE ensures call setup and teardown are never delayed by bulk traffic. Without SIP priority, a large CAD-to-CAD data sync or GIS tile update could delay emergency call delivery. MPLS VPN termination for inter-PSAP links enables mutual aid call transfer during major incidents. | Test | subsystem, network-infrastructure, wan-esinet, session-259 |
| SUB-REQS-061 | The Firewall and Intrusion Prevention System SHALL enforce CJIS Security Policy v5.9 network segmentation by restricting CJIS-zone traffic to authorised protocols and destinations only, terminating IPsec VPN tunnels for NCIC/state database queries, and blocking all unauthorised inter-zone traffic with default-deny policies on all interfaces. Rationale: CJIS Security Policy v5.9 compliance is a federal mandate for any PSAP querying NCIC or state criminal justice databases. Failure to enforce network segmentation can result in decertification and loss of CJIS access. IPsec VPN termination at the firewall is required for field MDT queries arriving over FirstNet. 5 Gbps throughput with IPS enabled ensures security inspection does not create a bottleneck for the PSAP's aggregate traffic. | Test | subsystem, network-infrastructure, firewall-ips, session-259 |
| SUB-REQS-062 | The Firewall and Intrusion Prevention System SHALL operate in an active-passive high-availability configuration with stateful session failover completing within 1 second, and SHALL process a minimum of 5 Gbps throughput with IPS signatures enabled without adding more than 1ms latency to voice VLAN traffic. Rationale: Active-passive HA with stateful failover ensures existing TCP sessions (including active CJIS queries and SIP signalling) survive a firewall failure without requiring re-authentication. Sub-1-second failover prevents call drops during firewall failure. 5 Gbps throughput matches the aggregate WAN and inter-VLAN traffic capacity of the PSAP. Without HA, a single firewall failure would isolate all PSAP subsystems from the ESInet and WAN. | Test | subsystem, network-infrastructure, firewall-ips, session-259 |
| SUB-REQS-063 | The Network Management and Monitoring System SHALL poll all network infrastructure devices via SNMP v3 at intervals not exceeding 60 seconds, aggregate syslog messages from all devices in real-time, and generate alerts within 30 seconds of detecting link failure, CPU utilisation exceeding 80%, or voice VLAN latency exceeding 5ms. Rationale: 60-second SNMP polling detects infrastructure faults within the NFPA 1221 required 2-minute notification window. Real-time syslog aggregation captures transient events (link flaps, authentication failures) that polling misses. Generating alerts when bandwidth exceeds 70% of capacity enables proactive capacity management before congestion affects voice quality. Historical data retention enables post-incident analysis of network performance during high-load events. | Test | subsystem, network-infrastructure, nms, session-259 |
| SUB-REQS-064 | The Time Synchronization Service SHALL provide Stratum-1 NTP time from dual GPS-disciplined clocks with OCXO holdover, achieving time accuracy within 1ms of UTC for all NTP clients and within 100 microseconds for IEEE 1588 PTP clients, with holdover drift not exceeding 10 microseconds per hour during GPS signal loss. Rationale: Stratum-1 NTP from GPS-disciplined clocks provides the most accurate time source available to the PSAP. Dual clocks provide redundancy — a single GPS receiver failure must not compromise time synchronization. OCXO holdover maintains microsecond accuracy for hours during GPS signal loss. 1ms NTP accuracy is sufficient for incident timeline correlation. 100-microsecond PTP accuracy is required by the call recording system for precise audio timestamp alignment during multi-channel recording. | Test | subsystem, network-infrastructure, time-sync, session-259 |
| SUB-REQS-065 | The DNS and DHCP Services SHALL operate as active-active redundant server pairs with zone transfer replication completing within 5 seconds, achieving DNS query resolution within 10ms for internal zones, and SHALL provide DHCP address assignment with VLAN-specific scopes including NTP server, TFTP boot server, and default gateway options. Rationale: Active-active DNS servers prevent DNS as a single point of failure — if DNS fails, NG9-1-1 SIP URI resolution fails and all call routing stops. 5-second zone transfer replication ensures both servers have consistent records after changes. 10ms query resolution for internal zones ensures SIP call setup is not delayed by DNS lookups. DHCP with PSAP-specific options automates provisioning of IP phones, workstations, and network devices, reducing manual configuration errors. | Test | subsystem, network-infrastructure, dns-dhcp, session-259 |
| SUB-REQS-066 | The Uninterruptible Power Supply System SHALL provide N+1 redundant online UPS modules delivering conditioned AC power to all network equipment racks, with minimum 30 minutes battery runtime at full load and automatic transfer switch cutover to generator power within 10 seconds of mains failure per NFPA 1221. Rationale: N+1 UPS redundancy ensures that a single UPS module failure does not cause network equipment power loss. 30-minute battery runtime at full load provides sufficient time for generator startup (typically 10-30 seconds) plus margin for generator failure and manual intervention. Automatic transfer to generator power within 10 seconds limits the UPS battery drain period. Without UPS, a utility power interruption causes immediate PSAP outage. | Test | subsystem, network-infrastructure, ups, session-259 |
| SUB-REQS-067 | The Firewall and Intrusion Prevention System SHALL update intrusion prevention signatures at least every 4 hours from the vendor threat intelligence feed, and SHALL generate real-time alerts to the Network Management and Monitoring System for any detected intrusion attempt targeting PSAP systems. Rationale: IPS signatures must be updated frequently because new vulnerabilities and attack patterns emerge daily. 4-hour update intervals balance signature currency against update processing overhead. Real-time alerts to the Network Management System ensure security events are visible to PSAP supervisors. The firewall is the primary defense against network-based attacks on life-safety infrastructure — outdated signatures leave known attack vectors undetected. | Test | subsystem, network-infrastructure, firewall-ips, session-259 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| IFC-DEFS-001 | The interface between ESInet SIP Gateway and Automatic Call Distribution Engine SHALL transfer authenticated SIP sessions via internal SIP trunk using TCP/TLS on port 5061, carrying caller PIDF-LO location, ANI, and media session descriptors at a rate supporting 150 concurrent session setups with less than 50ms interface latency. Rationale: This interface carries all emergency calls from protocol termination to routing. TCP/TLS on port 5061 is the NENA i3 standard for secured SIP signaling between ESInet elements. PIDF-LO location must traverse this interface because the ACD needs location for geographic routing decisions. The 50ms latency ceiling ensures gateway-to-ACD handoff does not consume more than 2.5 percent of the 2-second end-to-end budget. | Test | interface, call-handling, session-253 |
| IFC-DEFS-002 | The interface between ANI/ALI Database Interface and Call-Taker Workstation SHALL deliver location data as a structured JSON object containing civic address, geodetic coordinates (WGS84 latitude/longitude with confidence ellipse), location source type, and timestamp, via internal REST API over HTTPS with response time below 500ms. Rationale: Structured JSON with civic address, geodetic coordinates, and confidence ellipse enables the workstation to plot the caller on the GIS map with appropriate uncertainty visualization. WGS84 is the standard datum for NG911 location. The 500ms response time is allocated from the 2-second end-to-end budget after gateway and ACD processing, leaving margin for workstation rendering. | Test | interface, call-handling, session-253 |
| IFC-DEFS-003 | The interface between Text-to-911 Gateway and Automatic Call Distribution Engine SHALL present text sessions as queueable call objects with priority level, session identifier, originating number, and initial message text, using the same internal SIP signalling path as voice calls to enable unified ACD routing and queue management. Rationale: Presenting text sessions as SIP call objects through the same signaling path as voice enables the ACD to apply identical routing rules, queue management, and overflow logic to both media types. This unified approach derives from SYS-REQS-009 equitable access requirement and avoids maintaining a parallel routing system for text that would double the configuration complexity and diverge routing behavior. | Test | interface, call-handling, session-253 |
| IFC-DEFS-004 | The interface between Call Recording System and audio sources (ESInet SIP Gateway and Call-Taker Workstation) SHALL tap caller and dispatcher audio streams via SIPREC (RFC 7866) or port mirroring, delivering media to the recording system without introducing more than 1ms additional latency on the live audio path. Rationale: SIPREC (RFC 7866) is the IETF standard for session recording and provides metadata-rich recording without modifying the live audio path. The 1ms maximum added latency ensures recording does not degrade voice quality or introduce perceptible delay. Tapping both caller and dispatcher channels separately enables independent playback during incident review and legal proceedings. | Test | interface, call-handling, session-253 |
| IFC-DEFS-005 | The interface between Call-Taker Workstation and Computer-Aided Dispatch Subsystem SHALL transmit incident creation requests containing incident type, location (civic and geodetic), caller ANI, call-taker notes, and priority level via bi-directional API over HTTPS, with the CAD returning an incident number acknowledgment within 1 second. Rationale: This is the primary handoff from call-taking to dispatch operations. Bi-directional API enables the CAD to return incident numbers and status updates to the call-taker workstation, maintaining situational awareness while the caller is still on the line. The 1-second acknowledgment target ensures the call-taker receives confirmation before releasing the caller, preventing lost incidents. | Test | interface, call-handling, cad, cross-subsystem, session-253 |
| IFC-DEFS-006 | The interface between Incident Management Engine and Dispatch Decision Support Module SHALL transmit incident objects containing incident type code, priority level, location coordinates (WGS84), incident narrative text, and hazard flags via an internal publish-subscribe message bus with delivery latency not exceeding 100ms and guaranteed at-least-once delivery. Rationale: Publish-subscribe decouples the IME from the recommendation engine, allowing the DDSM to be upgraded or scaled independently. 100ms delivery latency ensures recommendations begin computing immediately after incident creation. At-least-once delivery guarantees no incident is silently dropped during bus congestion. | Test | interface, cad, ime-ddsm, session-255 |
| IFC-DEFS-007 | The interface between Unit Tracking and Status Module and Dispatch Decision Support Module SHALL provide current unit position (WGS84 lat/lon), status code, unit type, capability set, and assigned district via a shared in-memory data store updated at the AVL refresh rate, with read latency not exceeding 10ms for the DDSM to query the full fleet status. Rationale: Shared in-memory data store chosen over message-based interface because the DDSM needs to query full fleet status synchronously when computing recommendations. 10ms read latency ensures fleet queries do not bottleneck the 2-second recommendation window in SUB-REQS-013. | Test | interface, cad, utsm-ddsm, session-255 |
| IFC-DEFS-008 | The interface between Dispatch Decision Support Module and Dispatcher Workstation Interface SHALL deliver ranked unit recommendations as a structured message containing unit ID, estimated travel time, distance, capability match score, and run-card compliance status, delivered within 200ms of recommendation computation completion. Rationale: Structured message with travel time, distance, capability match, and run-card compliance gives the dispatcher all information for an informed decision in a single view. 200ms delivery budget allocated from the overall 2-second recommendation window, with 1.8s for DDSM computation. | Test | interface, cad, ddsm-dwi, session-255 |
| IFC-DEFS-009 | The interface between Dispatcher Workstation Interface and Incident Management Engine SHALL transmit dispatch commands (unit assignment, status override, incident update, incident close) as authenticated transactions with the dispatcher's user ID, timestamp, and action payload, with command acknowledgement returned within 500ms. Rationale: Authenticated transactions with dispatcher user ID are legally required — every dispatch action must be attributable to an individual for liability. 500ms acknowledgement ensures the dispatcher knows the action was accepted before moving to the next incident, preventing double-dispatch errors. | Test | interface, cad, dwi-ime, session-255 |
| IFC-DEFS-010 | The interface between Incident Management Engine and CAD Database and Event Logger SHALL write all incident state transitions, dispatcher actions, and system events as immutable audit records via asynchronous write-ahead logging, with write acknowledgement within 50ms and guaranteed persistence within 1 second under normal operation. Rationale: Write-ahead logging with asynchronous persistence prevents the database write path from blocking incident state transitions. 50ms write acknowledgement ensures the IME can process the next transition immediately. 1-second persistence guarantee limits data loss to at most 1 second during catastrophic database failure. | Test | interface, cad, ime-cdel, session-255 |
| IFC-DEFS-011 | The interface between CAD Database and Event Logger and Supervisor Dashboard Module SHALL provide pre-aggregated operational metrics (queue depth, response time percentiles, unit utilisation by district) via a read-replica query endpoint, with metric staleness not exceeding 5 seconds and query response time under 200ms for the standard dashboard metric set. Rationale: Read-replica endpoint isolates supervisor query load from operational write path, preventing dashboard queries from degrading dispatch performance. 5-second staleness aligns with SUB-REQS-022. 200ms query response ensures dashboard renders without lag. | Test | interface, cad, cdel-sdm, session-255 |
| IFC-DEFS-012 | The interface between Dispatch Radio Console and Radio Gateway Controller SHALL transport bidirectional audio using RTP (RFC 3550) with IMBE vocoder payload over a dedicated VLAN, with maximum one-way latency of 50ms and packet loss below 0.1%, using RTCP for quality monitoring and DFSI (Digital Fixed Station Interface) signalling for PTT, channel grant, and emergency alert control messages. Rationale: RTP over dedicated VLAN isolates voice traffic from data to prevent dispatch audio degradation during surges. 50ms latency and 0.1% packet loss are ITU G.114 requirements for conversational voice quality. DFSI per TIA-102.BAHA is the P25 standard for fixed-station digital voice interface. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-013 | The interface between Radio Gateway Controller and Talkgroup Management Module SHALL exchange talk group affiliation commands, dynamic regrouping directives, and patch configurations via an internal API with maximum response latency of 500ms, and SHALL support atomic patch operations affecting up to 8 talk groups simultaneously. Rationale: 500ms API latency ensures talk group operations complete within the 3-second user-facing threshold in SUB-REQS-027. Atomic patch operations are critical because partial patches create one-way communication — field units believe they can communicate cross-agency but messages are not reaching all parties. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-014 | The interface between Radio Gateway Controller and Interoperability Gateway SHALL transport cross-system audio and ISSI signalling over dedicated IP trunks using TIA-102.BACA-A Group Call and Emergency Alert message formats, with maximum cross-system audio latency of 200ms one-way. Rationale: Dedicated IP trunks provide deterministic bandwidth for cross-system audio, unlike shared paths that congest during large incidents when interoperability traffic peaks. 200ms one-way accounts for additional transcoding and ISSI protocol overhead beyond the 50ms intra-system budget, staying within ITU 250ms conversational threshold. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-015 | The interface between Radio Logging Recorder and Radio Gateway Controller SHALL tap all audio streams using passive port mirroring or SIPREC (RFC 7866) without introducing latency or jitter to the live audio path, and SHALL deliver transmission metadata (unit ID, talk group, site ID, timestamp) as structured records alongside each audio segment. Rationale: Passive port mirroring or SIPREC ensures recording cannot introduce latency, jitter, or failure modes into the live audio path. Structured metadata alongside each audio segment enables automated indexing by unit ID, talk group, and timestamp, supporting the 2-second instant replay requirement in SUB-REQS-032. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-016 | The interface between Encryption Key Management Module and Radio Gateway Controller SHALL distribute traffic encryption keys (TEKs) using OTAR key management messages per TIA-102.AACA over the P25 control channel, with end-to-end key delivery confirmation and rollback capability if rekey fails on more than 5% of targeted radios. Rationale: OTAR key delivery over P25 control channel uses existing radio infrastructure. 5% failure threshold for rollback prevents a partially rekeyed fleet from becoming fragmented where some radios cannot communicate with others due to key mismatch. Rollback ensures return to known-good key state. | Test | interface, radio-comms, session-256 |
| IFC-DEFS-017 | The interface between Computer-Aided Dispatch Subsystem and Dispatch Radio Console SHALL transmit incident-triggered talk group selection commands via a REST API over HTTPS, and SHALL support automatic channel assignment upon dispatch confirmation, delivering the assigned talk group to the console within 1 second of CAD dispatch action. Rationale: REST over HTTPS provides a simple, auditable interface between CAD and radio subsystems that can traverse network boundaries. 1-second channel assignment ensures the dispatcher has the correct talk group active before first radio transmission to the field, supporting the 2-keystroke dispatch workflow. | Test | interface, radio-comms, cross-subsystem, session-256 |
| IFC-DEFS-018 | The interface between Routing Engine and Dispatch Decision Support Module SHALL accept route computation requests containing origin coordinates (WGS84), destination coordinates, and vehicle type, and return travel time in seconds, distance in meters, and route geometry as an encoded polyline, with end-to-end request-response latency not exceeding 600ms including network overhead. Rationale: The Routing Engine must receive structured requests from the Dispatch Decision Support Module to compute optimal response routes. WGS84 coordinates ensure interoperability with the GIS spatial database, and vehicle type affects route constraints (e.g., ladder trucks cannot use low-clearance routes). Without this interface, the dispatch recommendation engine cannot factor travel time into unit selection. | Test | interface, gis, session-257 |
| IFC-DEFS-019 | The interface between Map Tile Server and Dispatcher Workstation Interface SHALL deliver map tiles using the XYZ tile protocol (z/x/y addressing) over HTTP with ETag-based caching, supporting both raster (PNG 256x256) and vector (MVT) tile formats, with the workstation client maintaining a local tile cache of at least 500MB to reduce server load during pan operations. Rationale: The Map Tile Server must deliver map imagery to dispatcher workstations using the XYZ tile protocol, the industry standard for web map tile delivery. ETag-based caching reduces redundant tile re-fetches during pan/zoom, which is critical when dispatchers are tracking 50+ incidents. Without efficient tile delivery, map rendering latency exceeds dispatcher tolerance (>200ms) and situational awareness degrades during high-volume events. | Test | interface, gis, session-257 |
| IFC-DEFS-020 | The interface between Geocoding Engine and ANI/ALI Database Interface SHALL accept raw caller address strings from ALI records and return validated WGS84 coordinates with MSAG validation status and confidence score, with request-response latency not exceeding 300ms to support real-time incident location during call processing. Rationale: The Geocoding Engine must resolve raw ANI/ALI address strings into WGS84 coordinates to place callers on the dispatch map. ALI records from legacy PSAPs often contain non-standard formatting requiring fuzzy matching. MSAG validation status is essential because unvalidated addresses may not correspond to real locations, affecting unit dispatch accuracy. Confidence scores enable the call-taker to assess location reliability before dispatching. | Test | interface, gis, session-257 |
| IFC-DEFS-021 | The interface between Mobile Data Terminal Application and FirstNet LTE Communications Module SHALL use a local USB 3.0 or embedded PCIe connection with a dedicated network adapter presenting as a standard TCP/IP interface, supporting minimum 50 Mbps sustained throughput. Rationale: The MDT Application requires a reliable local connection to the FirstNet LTE module for field data communications. USB 3.0 or PCIe provides the bandwidth and reliability needed for concurrent voice (MCPTT) and data (dispatch, CJIS queries) streams. Presenting as a standard network adapter simplifies MDT application development and allows standard IP stack management including VPN tunnels. | Test | interface, mobile-data, session-258 |
| IFC-DEFS-022 | The interface between FirstNet LTE Communications Module and Mobile Data Gateway Server SHALL use WebSocket over TLS 1.2+ with persistent connections, 15-second keepalive heartbeats, and automatic reconnection within 3 seconds of transport failure detection. Rationale: The FirstNet LTE module communicates with the PSAP gateway server over a cellular WAN link subject to intermittent connectivity. WebSocket over TLS provides persistent bidirectional communication needed for real-time dispatch updates. The 15-second keepalive detects link failure faster than TCP keepalive defaults (typically 2 hours), and automatic reconnection within 10 seconds prevents dispatch message loss during brief coverage gaps in urban/rural fringe areas. | Test | interface, mobile-data, session-258 |
| IFC-DEFS-023 | The interface between Mobile Data Gateway Server and CJIS Query Proxy SHALL use a dedicated IPsec VPN tunnel with AES-256 encryption, transmitting queries and responses in NLETS XML format with maximum 500ms gateway-to-proxy latency. Rationale: CJIS queries from field MDTs must traverse a dedicated IPsec VPN tunnel because CJIS Security Policy v5.9 mandates FIPS 140-2 validated encryption for all criminal justice data in transit. AES-256 meets this requirement. NLETS XML format is the national standard for law enforcement data exchange. The 3-second maximum latency threshold ensures field officers can complete wants/warrants checks during traffic stops before returning to the vehicle. | Test | interface, mobile-data, cjis, session-258 |
| IFC-DEFS-024 | The interface between Mobile Data Gateway Server and Incident Management Engine SHALL use a RESTful API over HTTPS with JSON payloads conforming to the NIEM Justice domain schema, delivering dispatch assignments with maximum 1-second API response time and supporting 50 concurrent dispatch transactions per second. Rationale: The Mobile Data Gateway Server must relay dispatch assignments from the Incident Management Engine to field units. NIEM Justice domain schema standardises the message format for dispatch data exchange across agencies. HTTPS with JSON ensures compatibility with modern MDT applications while meeting encryption requirements. Near-real-time delivery (<5 seconds) is essential so field units receive dispatch information before the radio voice dispatch, enabling simultaneous text and voice notification. | Test | interface, mobile-data, cross-subsystem, session-258 |
| IFC-DEFS-025 | The interface between Automatic Vehicle Location Module and Unit Tracking and Status Module SHALL transmit position reports as UDP datagrams containing unit ID, WGS84 latitude/longitude, heading, speed, and UTC timestamp, with reports aggregated by the Mobile Data Gateway and forwarded via TCP to the CAD at 5-second batch intervals. Rationale: The AVL Module must transmit position reports to the Unit Tracking and Status Module to enable real-time unit tracking on the dispatch map. UDP is chosen over TCP because position reports are time-sensitive and individually non-critical — a lost report is superseded by the next one in 10 seconds. Including heading and speed enables the dispatch decision support module to predict unit arrival times. The 10-second default balances position currency against cellular bandwidth consumption. | Test | interface, mobile-data, cross-subsystem, session-258 |
| IFC-DEFS-026 | The interface between Incident Report Database and CAD Database and Event Logger SHALL use database replication (logical replication or CDC) to synchronize closed incident records from CAD to the Records Management system within 60 seconds of incident closure, preserving all event log entries, timestamps, and unit assignments. Rationale: Closed incident records must flow from the live CAD database to the Records Management database to enable long-term records management, FOIA response, UCR/NIBRS reporting, and investigative case building without querying the live CAD system. Database replication or CDC ensures data consistency without requiring the Records Management system to understand CAD schema changes. This separation prevents records queries from affecting CAD operational performance during peak call volumes. | Test | interface, records-management, cross-subsystem, session-258 |
| IFC-DEFS-027 | The interface between Incident Report Database and Call Recording System SHALL link audio recordings to incident records using the incident case number as the foreign key, with recordings accessible via URI reference stored in the incident record and retrievable within 3 seconds of request. Rationale: Audio recordings must be linked to incident records for evidentiary, quality assurance, and liability purposes. Using the incident case number as foreign key ensures recordings are retrievable in the context of the incident they document. HTTP/HTTPS streaming access enables playback from the Records Search and Retrieval Engine without requiring direct database access to the call recording system's storage, supporting role-based access control at the application layer. | Test | interface, records-management, cross-subsystem, session-258 |
| IFC-DEFS-028 | The interface between Records Search and Retrieval Engine and Incident Report Database SHALL maintain a search index synchronized within 5 minutes of source record changes, supporting full-text search across incident narratives, structured field queries, and fuzzy name matching with configurable similarity threshold. Rationale: The Records Search and Retrieval Engine requires a synchronized search index to provide sub-2-second query responses across millions of records. The 5-minute synchronization window balances index freshness against reindexing overhead. Full-text search over narrative fields is essential for investigative use where structured queries are insufficient. Multi-field faceted search supports records clerks processing FOIA requests who need to filter by date range, incident type, and location simultaneously. | Test | interface, records-management, session-258 |
| IFC-DEFS-029 | The interface between Core LAN Switching Fabric and Firewall and Intrusion Prevention System SHALL use 802.1Q trunk ports carrying all inter-VLAN traffic, with the firewall enforcing access control lists on each VLAN sub-interface, supporting aggregate throughput of 5 Gbps with less than 1ms added latency. Rationale: All inter-VLAN traffic in the PSAP must pass through the firewall to enforce the network segmentation required by CJIS Security Policy v5.9. 802.1Q trunking carries multiple VLAN tags over shared physical links, which is necessary given the PSAP's multiple security zones (voice, data, CJIS, management). The firewall applies zone-based policies that prevent lateral movement between VLANs, which is critical because a compromise of the public-facing ESInet zone must not reach the CJIS-restricted zone. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-030 | The interface between Core LAN Switching Fabric and WAN and ESInet Gateway SHALL use dedicated 10 Gbps Ethernet links with 802.1Q tagging to separate ESInet-bound SIP signalling from general WAN traffic, with DSCP marking preserved end-to-end for QoS policy enforcement at the WAN edge. Rationale: ESInet-bound SIP signalling must be separated from general WAN traffic to ensure NG9-1-1 call setup latency is not affected by non-emergency traffic. 10 Gbps links provide headroom for concurrent SIP sessions (each <100 Kbps but requiring low jitter) plus bulk data transfers like CAD-to-CAD replication. 802.1Q tagging at the WAN gateway enables the firewall to apply different security policies to ESInet traffic versus internet-facing traffic. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-031 | The interface between WAN and ESInet Gateway and Firewall and Intrusion Prevention System SHALL carry all inbound ESInet and internet traffic through the firewall before reaching internal PSAP networks, with the firewall performing stateful inspection and IPS analysis on all WAN-originated flows. Rationale: All inbound ESInet and internet traffic must pass through the firewall before reaching internal PSAP systems to prevent external threats from directly accessing life-safety systems. The firewall inspects SIP messages for malformed headers and SIP-specific attacks, and blocks unauthorized traffic from the internet. Without this, a compromised ESInet peer or internet-facing service could directly access the CAD database or CJIS systems. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-032 | The interface between Network Management and Monitoring System and Core LAN Switching Fabric SHALL use SNMP v3 with authentication and encryption over the dedicated management VLAN, with the NMS polling each managed device at configurable intervals and receiving SNMP traps within 5 seconds of event generation. Rationale: SNMP v3 with authentication and encryption is mandated by CJIS Security Policy for network management traffic to prevent credential theft and configuration data exposure. The dedicated management VLAN isolates monitoring traffic from production voice and data streams. 60-second polling intervals provide sufficient granularity to detect link failures within the NFPA 1221 required notification window (2 minutes for critical infrastructure faults). | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-033 | The interface between Time Synchronization Service and Core LAN Switching Fabric SHALL distribute NTP on UDP port 123 to all PSAP hosts and IEEE 1588 PTP on UDP ports 319/320 to latency-sensitive subsystems, with the core switches supporting PTP boundary clock mode to maintain sub-100 microsecond accuracy across switch hops. Rationale: Accurate time synchronization is critical for incident timeline reconstruction, call recording timestamp correlation, and radio log synchronization. NTP provides millisecond-level accuracy sufficient for most PSAP systems. IEEE 1588 PTP provides microsecond-level accuracy required by the call recording system and radio logging recorder for precise timestamp correlation during multi-agency incident review. Dual time sources on separate VLANs ensure synchronization survives a single-point failure. | Test | interface, network-infrastructure, session-259 |
| IFC-DEFS-034 | The interface between Uninterruptible Power Supply System and Core LAN Switching Fabric SHALL provide conditioned AC power via dedicated circuits to each network equipment rack, and SHALL report power status, battery charge level, load percentage, and environmental sensor readings to the Network Management and Monitoring System via SNMP v3. Rationale: Network equipment requires conditioned AC power from the UPS to prevent data loss and service interruption during utility power events. SNMP-based power monitoring enables the Network Management System to alert operators when battery runtime drops below safe thresholds, triggering controlled shutdown procedures before battery exhaustion. Without UPS status visibility, an unannounced power event could cause uncontrolled switch reboots and extended PSAP outage. | Inspection | interface, network-infrastructure, session-259 |
| IFC-DEFS-035 | The interface between Core LAN Switching Fabric and ESInet SIP Gateway SHALL carry SIP signalling and RTP media on a dedicated voice VLAN with DSCP EF marking, supporting minimum 150 concurrent SIP sessions with per-session bandwidth allocation of 100 kbps and maximum one-way latency of 5ms from switch port to switch port. Rationale: SIP signalling and RTP media for NG9-1-1 calls must traverse the Core LAN on a dedicated voice VLAN to receive DSCP EF priority marking, ensuring jitter below 30ms and packet loss below 0.1% as required for intelligible voice. Supporting 150 concurrent SIP sessions on the LAN segment matches the system capacity requirement (SYS-REQS-001). Without dedicated VLAN isolation and QoS marking, data bursts from CAD database queries or GIS tile serving could cause audible voice degradation. | Test | interface, network-infrastructure, cross-subsystem, session-259 |
| IFC-DEFS-036 | The interface between Firewall and Intrusion Prevention System and CJIS Query Proxy SHALL terminate IPsec VPN tunnels from field mobile data terminals, restricting CJIS query traffic to authorised source IPs and destination ports only, with mutual certificate authentication and AES-256 encryption per CJIS Security Policy v5.9. Rationale: CJIS queries from field MDTs arrive over FirstNet LTE and must be decrypted and re-validated at the PSAP perimeter firewall. IPsec tunnel termination at the firewall ensures criminal justice data is encrypted end-to-end between the MDT and the CJIS Query Proxy. Source IP and certificate-based authentication restricts access to authorized MDTs only, preventing unauthorized queries against NCIC databases which would constitute a federal CJIS policy violation. | Test | interface, network-infrastructure, cross-subsystem, session-259 |
| IFC-DEFS-037 | The interface between Incident Management Engine and Radio Communications Subsystem SHALL transmit station alerting commands containing incident type, address, assigned units, and talk group assignment via a dedicated API, triggering fire station alerting tones and printouts within 2 seconds of dispatch confirmation for all fire and EMS incidents. Rationale: Fire and EMS station alerting is the most time-critical post-dispatch action. The 2-second latency bound ensures turnout time begins immediately after dispatch confirmation, directly impacting NFPA 1221 alarm handling benchmarks. Dedicated API decouples CAD incident management from radio subsystem internals while ensuring all required dispatch data reaches station alerting equipment without manual re-entry. | Test | interface, cross-subsystem, session-261 |
| IFC-DEFS-038 | The interface between Records Search and Retrieval Engine and Spatial Database SHALL support geographic incident queries using point-radius and polygon-based spatial filters, returning all incident records within the specified area sorted by date, with query response time not exceeding 3 seconds for searches spanning up to 12 months of records. Rationale: Investigators and analysts require spatial queries against historical incident data for crime pattern analysis, resource allocation studies, and hazard mapping. The 3-second response ceiling ensures interactive use during active investigations. Point-radius and polygon filters cover the two dominant query patterns: proximity searches around a location and searches within jurisdictional or geographic boundaries. | Test | interface, cross-subsystem, session-261 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| ARC-DECISIONS-001 | ARC: System Decomposition — Seven subsystems chosen to reflect the real functional and procurement boundaries of a metropolitan PSAP. Call Handling is separated from CAD because telephony (SIP/CAMA) is a distinct technology domain from dispatch logic, typically procured from different vendors. GIS is separate rather than embedded in CAD because spatial data management (MSAG maintenance, layer updates, geocoding engine) has independent lifecycle and interfaces with multiple consumers (CAD, MDT, supervisory dashboard). Radio Communications is isolated because P25 infrastructure operates on dedicated RF spectrum with its own certification requirements. Mobile Data is separate from Radio because it uses cellular/FirstNet rather than LMR and has distinct security requirements (CJIS on public networks). Records Management spans all other subsystems as a cross-cutting concern but has its own storage, retention, and compliance requirements. Network Infrastructure underpins all subsystems and has distinct availability, redundancy, and cybersecurity requirements. Rationale: Seven subsystems reflect actual PSAP procurement and operational boundaries. Telephony, CAD, GIS, radio, mobile data, records, and network are procured from different vendors with independent maintenance cycles. This decomposition enables parallel development and independent upgrade paths, which is critical for a system that cannot be taken offline for upgrades. | Inspection | architecture, system-decomposition, session-252 |
| ARC-DECISIONS-002 | ARC: Call Handling Subsystem — Decomposed into five components reflecting the NG911 call processing pipeline: ESInet SIP Gateway (protocol termination), Automatic Call Distribution Engine (intelligent routing), ANI/ALI Database Interface (location/identity retrieval), Call-Taker Workstation (human-machine interface), Text-to-911 Gateway (text channel processing), and Call Recording System (evidentiary capture). This decomposition separates protocol-level concerns (SIP, HELD, MLP) from routing logic and presentation, enabling independent scaling of gateway capacity versus workstation count. The ACD is centralised rather than distributed because PSAP call volumes (typically under 200 concurrent) do not warrant distributed routing complexity, and centralised state simplifies overflow management to mutual aid partners. Rationale: The six-component pipeline separates protocol termination from routing logic and presentation, enabling the gateway to scale independently of workstation count. Centralised ACD is chosen over distributed routing because PSAP call volumes under 200 concurrent do not justify the complexity of distributed consensus, and centralised state simplifies mutual-aid overflow management. | Inspection | architecture, call-handling, session-253 |
| ARC-DECISIONS-003 | ARC: Call Handling Subsystem — Decomposed into five components reflecting the NG911 call processing pipeline: ESInet SIP Gateway (protocol termination), Automatic Call Distribution Engine (intelligent routing), ANI/ALI Database Interface (location/identity retrieval), Call-Taker Workstation (human-machine interface), Text-to-911 Gateway (text channel processing), and Call Recording System (evidentiary capture). This decomposition separates protocol-level concerns (SIP, HELD, MLP) from routing logic and presentation, enabling independent scaling of gateway capacity versus workstation count. The ACD is centralised rather than distributed because PSAP call volumes typically under 200 concurrent do not warrant distributed routing complexity, and centralised state simplifies overflow management to mutual aid partners. Rationale: DUPLICATE of ARC-DECISIONS-002. Created in error during session 253. Content is identical to ARC-DECISIONS-002 and should be disregarded. | Inspection | architecture, call-handling, duplicate-of-ARC-DECISIONS-002, session-260 |
| ARC-DECISIONS-004 | ARC: Computer-Aided Dispatch Subsystem — Decomposed into six components separating dispatch logic from data management and presentation. The Incident Management Engine centralises incident lifecycle control because NIMS/ICS classification rules must be applied consistently across all incident types and agencies, and distributed incident state would risk conflicting priority assignments during multi-agency events. The Dispatch Decision Support Module is separated from the Incident Management Engine because recommendation algorithms (proximity weighting, run-card rules, automatic dispatch timeouts) evolve independently of incident state management and can be upgraded without affecting incident integrity. Unit Tracking and Status Module is isolated because AVL data ingestion at 5-second intervals from 2000+ units is a distinct high-throughput concern from dispatch logic. The Dispatcher Workstation Interface is separated because UI refresh cycles, ergonomic requirements, and multi-monitor layout are HMI concerns independent of backend logic. CAD Database and Event Logger is separated because persistence, replication, and CJIS-compliant encryption are infrastructure concerns with their own availability requirements. Supervisor Dashboard Module is separated because supervisory aggregation and alerting operate on different refresh cadences and access control policies than dispatch operations. Rationale: CAD subsystem decomposition follows separation of concerns: incident lifecycle management, recommendation algorithms, fleet tracking, human-machine interface, persistence, and supervisory monitoring are each isolated because they have independent scaling, update, and availability requirements. | Inspection | architecture, cad, session-255, duplicate-of-ARC-DECISIONS-005 |
| ARC-DECISIONS-005 | ARC: Computer-Aided Dispatch Subsystem — Decomposed into six components separating dispatch logic from data management and presentation. The Incident Management Engine centralises incident lifecycle control because NIMS/ICS classification rules must be applied consistently across all incident types and agencies. The Dispatch Decision Support Module is separated because recommendation algorithms evolve independently of incident state management. Unit Tracking and Status Module is isolated because AVL data ingestion at 5-second intervals from 2000+ units is a distinct high-throughput concern. The Dispatcher Workstation Interface is separated because UI refresh cycles and ergonomic requirements are HMI concerns independent of backend logic. CAD Database and Event Logger is separated because persistence, replication, and CJIS-compliant encryption have their own availability requirements. Supervisor Dashboard Module is separated because supervisory aggregation operates on different refresh cadences and access control policies. Rationale: DUPLICATE OF ARC-DECISIONS-004: This architecture decision duplicates the Computer-Aided Dispatch Subsystem decomposition rationale. Tagged for removal during next review. | Inspection | architecture, cad, duplicate-of-ARC-DECISIONS-004, session-260 |
| ARC-DECISIONS-006 | ARC: Radio Communications Subsystem — Decomposed into six components separating the dispatcher-facing console from the RF network gateway, with dedicated modules for talk group management, inter-agency interoperability, radio logging, and encryption key management. The Radio Gateway Controller is the critical choke point: all dispatch-to-field audio flows through it, making it the single highest-availability component. Talkgroup Management is separated from the gateway because talk group configuration changes frequently (multiple times per shift during multi-agency incidents) while the gateway's channel-grant logic must remain stable. The Interoperability Gateway is isolated to contain the complexity of cross-vendor P25 ISSI bridging and prevent mutual-aid configuration changes from affecting primary dispatch communications. Radio Logging is separate from telephony call recording because radio recordings carry different metadata (unit ID, talk group, RF site) and have different retention/chain-of-custody requirements for law enforcement evidentiary use. Rationale: Radio subsystem decomposition separates console interface, gateway bridging, talk group management, interoperability, logging, and encryption because each has distinct protocol stacks, regulatory compliance requirements, and failure modes that must be independently testable and upgradeable. | Inspection | architecture, radio-comms, session-256 |
| ARC-DECISIONS-007 | ARC: Geographic Information System Subsystem — Decomposed into four components separating map rendering, address resolution, route computation, and geographic data management. The Map Tile Server is isolated because tile rendering is a high-throughput, cacheable workload that scales horizontally and independently of query-response services. The Geocoding Engine is separated because address normalization and MSAG validation require a specialized index distinct from the spatial query engine. The Routing Engine is separated because road-network graph computation is CPU-intensive with a distinct scaling profile from tile serving. The Spatial Database is shared infrastructure serving all three consumers, using PostGIS for standardized spatial query semantics. Rationale: Four GIS components separate concerns that have different performance profiles and update cycles: map rendering is read-heavy and cacheable, geocoding requires fuzzy text matching with MSAG validation, route computation is CPU-intensive graph traversal, and spatial data management has its own update and backup lifecycle. Combining these into a monolithic GIS would create contention between tile serving throughput and geocoding accuracy requirements. | Analysis | architecture, gis, session-257 |
| ARC-DECISIONS-008 | ARC: Mobile Data Subsystem — Five components chosen to separate the field-side hardware/software (MDT Application, AVL Module, FirstNet LTE Module) from PSAP-side middleware (Mobile Data Gateway Server, CJIS Query Proxy). The MDT Application is software-only because the hardware platform varies by agency and vehicle type. AVL is a separate module rather than embedded in the MDT because it has an independent GPS antenna and must report position even when the MDT application is not in active use. The CJIS Query Proxy is isolated from the Gateway Server because CJIS Security Policy requires a separate security boundary with dedicated audit logging, encryption certification, and access control — co-locating CJIS functions in the general-purpose gateway would require the entire gateway to meet CJIS audit scope, increasing compliance cost and reducing deployment flexibility. Rationale: Separating field-side components (MDT Application, AVL Module, FirstNet LTE Module) from server-side gateway components reflects the physical deployment boundary — field components run in vehicles on battery/alternator power over cellular, while server components run in the PSAP data centre on conditioned power with LAN connectivity. The CJIS Query Proxy is isolated because it handles criminal justice data subject to separate security certification requirements. | Inspection | architecture, mobile-data, session-258 |
| ARC-DECISIONS-009 | ARC: Records Management Subsystem — Four components chosen to separate data storage concerns (Incident Report Database) from access patterns (Records Search and Retrieval Engine), compliance automation (Retention and Purge Manager), and reporting obligations (Report Generation Module). The Search Engine is decoupled from the primary database to allow independent scaling of read-heavy search workloads without impacting transactional writes from CAD replication. The Retention and Purge Manager is a separate component rather than a database trigger because retention policies vary by jurisdiction and record type, change frequently with new legislation, and must produce independently auditable purge logs — embedding this logic in the database layer would make policy changes a database migration event rather than a configuration change. Rationale: Separating storage (Incident Report Database) from access patterns (Search and Retrieval Engine) from lifecycle management (Retention and Purge Manager) from output generation (Report Generation Module) isolates compliance concerns. Records retention is driven by statute, search access by RBAC policy, and reporting by federal mandates — each has different stakeholders and change drivers. A monolithic records system would make compliance audits harder and create unnecessary coupling between unrelated policy domains. | Inspection | architecture, records-management, session-258 |
| ARC-DECISIONS-010 | ARC: Network Infrastructure Subsystem - Decomposed into seven components separating data transport, external connectivity, security enforcement, operational visibility, time integrity, name/address services, and power resilience. Core LAN is the central convergence point with VLAN segmentation enforced at the firewall. WAN/ESInet Gateway is separated from the firewall because BGP peering policies change independently. Time Synchronization is standalone because NTP/PTP accuracy is a legal evidentiary requirement under NENA i3. Collapsing NMS, DNS, and NTP onto shared servers was rejected to prevent correlated failure. Rationale: Seven network components reflect the functional layers of a PSAP network: physical transport (Core LAN), external connectivity (WAN/ESInet Gateway), perimeter security (Firewall/IPS), operational visibility (NMS), time synchronisation, network services (DNS/DHCP), and power conditioning (UPS). Each has distinct failure modes, maintenance windows, and vendor relationships. Collapsing these would violate defence-in-depth principles where the security boundary must be independently managed from the transport layer. | Analysis | architecture, network-infrastructure, session-259 |
flowchart TB n0["component<br>ESInet SIP Gateway"] n1["component<br>ACD Engine"] n2["component<br>ANI/ALI Interface"] n3["component<br>Call-Taker Workstation"] n4["component<br>Text-to-911 Gateway"] n5["component<br>Call Recording System"] n6["component<br>ESInet SIP Gateway"] n7["component<br>ACD Engine"] n8["component<br>ANI/ALI Interface"] n9["component<br>Call-Taker Workstation"] n10["component<br>Text-to-911 Gateway"] n11["component<br>Call Recording System"] n6 -->|SIP sessions| n7 n7 -->|Routed calls| n9 n8 -->|Location/identity data| n9 n10 -->|Text sessions| n7 n6 -->|Audio stream| n11 n9 -->|Dispatcher audio| n11 n6 -->|Call arrival trigger| n8
Call Handling Subsystem — Internal
flowchart TB n0["component<br>Dispatch Radio Console"] n1["component<br>Radio Gateway Controller"] n2["component<br>Talkgroup Management Module"] n3["component<br>Interoperability Gateway"] n4["component<br>Radio Logging Recorder"] n5["component<br>Encryption Key Management Module"] n6["actor<br>P25 Radio Infrastructure"] n7["actor<br>External Agency P25 Systems"] n8["actor<br>Dispatcher Workstation"] n8 -->|PTT commands, channel select| n0 n0 -->|RTP/RTCP audio, DFSI signalling| n1 n1 -->|P25 ISSI RF channel interface| n6 n1 -->|ISSI cross-system audio| n3 n3 -->|ISSI/CSSI mutual aid bridge| n7 n2 -->|Talk group affiliations, patches| n1 n0 -->|Talk group select, patch requests| n2 n4 -->|Audio tap, SIPREC recording| n1 n5 -->|TEK distribution, OTAR commands| n1
Radio Communications Subsystem — Internal
flowchart TB n0["component<br>Mobile Data Terminal Application"] n1["component<br>Mobile Data Gateway Server"] n2["component<br>CJIS Query Proxy"] n3["component<br>Automatic Vehicle Location Module"] n4["component<br>FirstNet LTE Communications Module"] n0 -->|App data over LTE| n4 n4 -->|Encrypted LTE transport| n1 n3 -->|GPS position data| n0 n1 -->|CJIS queries and responses| n2 n0 -->|NCIC query requests| n2
Mobile Data Subsystem — Internal
flowchart TB n0["component<br>Incident Report Database"] n1["component<br>Records Search and Retrieval Engine"] n2["component<br>Retention and Purge Manager"] n3["component<br>Report Generation Module"] n1 -->|Search queries| n0 n2 -->|Retention policy enforcement| n0 n3 -->|Report data extraction| n0
Records Management Subsystem — Internal
flowchart TB n0["component<br>Core LAN Switching Fabric"] n1["component<br>WAN and ESInet Gateway"] n2["component<br>Firewall and IPS"] n3["component<br>Network Management and Monitoring"] n4["component<br>Time Synchronization Service"] n5["component<br>DNS and DHCP Services"] n6["component<br>Uninterruptible Power Supply"] n0 -->|802.1Q trunk, inter-VLAN| n2 n0 -->|10G Ethernet, DSCP EF| n1 n1 -->|Inbound WAN inspection| n2 n3 -->|SNMP v3, syslog| n0 n4 -->|NTP/PTP distribution| n0 n5 -->|DNS queries, DHCP leases| n0 n6 -->|Conditioned AC power| n0 n6 -->|SNMP v3 power status| n3
Network Infrastructure Subsystem — Internal
| Entity | Hex Code | Description |
|---|---|---|
| ANI/ALI Database Interface | 40ED7159 | Automatic Number Identification and Automatic Location Identification query interface retrieving caller identity and location data. For wireline calls, queries ALI database via NENA-02-501 protocol. For wireless Phase II, retrieves location from MPC/GMLC via MLP or HELD protocol. For NG911, queries Location Information Server via HELD dereferencing. Returns location data within 2 seconds of call arrival. Provides civic address, geodetic coordinates with uncertainty, and location source metadata to the call-taker workstation display. |
| Automatic Call Distribution Engine | 51B77B19 | Intelligent call routing engine distributing incoming emergency calls to available call-taker positions based on configurable rules: skill-based routing (language, call type), geographic assignment, load balancing, and priority queuing. Maintains real-time state of all call-taker positions (available, busy, wrap-up, logged-out). Supports overflow routing to backup PSAPs and mutual aid partners. Routes calls within 500ms of SIP gateway handoff. Implements NENA i3 queue management with priority levels for callback, transfer, and text-to-911 sessions. |
| Automatic Vehicle Location Module | 55F57219 | GPS-based vehicle tracking module that collects position reports from field units at configurable intervals (default 10 seconds in-service, 60 seconds out-of-service). Receives NMEA 0183 data from vehicle-mounted GPS antenna, packages with unit ID and timestamp, and transmits to the Mobile Data Gateway. Supports geofencing for automatic status changes (e.g., arrival at incident scene). Position data feeds the CAD unit tracking display and GIS routing engine. Accuracy requirement: CEP 3m under open sky, 10m in urban canyon. |
| CAD Database and Event Logger | 40853358 | Persistent storage component for all CAD operational data including incident records, unit activity history, dispatch actions, and system audit trails. Uses a high-availability database cluster (active-passive with synchronous replication) to ensure zero data loss. Maintains incident records with full event chronology for post-incident analysis and legal discovery. Supports real-time queries for active incident lookups (sub-100ms response) and complex historical queries for reporting (response within 5 seconds for 90-day windows). Implements data retention policies compliant with state records retention statutes (typically 7-10 years for emergency call records). Provides CJIS-compliant encryption at rest and role-based access controls for sensitive incident data. Must sustain 5000+ write transactions per minute during peak operations. |
| Call Handling Subsystem | 50B57358 | NG911-compliant call reception and processing subsystem for a metropolitan PSAP. Receives voice calls via SIP trunking over ESInet, legacy CAMA trunks from PSTN, RTT text-to-911, and telematics data (ACN/connected vehicle) via NENA i3 ECRF/LVF. Performs ANI/ALI lookup for wireline, Phase II wireless ALI with uncertainty polygons, and device-based location for smartphones. Manages call queuing with priority override for callbacks and abandoned calls. Supports call transfer (blind/consultative) to secondary PSAPs and agencies. Handles 150+ concurrent calls during surge events with <15 second average queue time. Must maintain call audio throughout transfer chain. |
| Call Recording System | 54E53359 | Continuous audio and metadata recording system capturing 100% of emergency call audio, radio transmissions routed through the dispatch console, and text-to-911 session transcripts. Records in uncompressed PCM or G.711 codec at minimum 8kHz sample rate with NICL-compliant timestamping synchronized to GPS/NTP within 10ms. Stores recordings with incident correlation metadata (ANI, ALI, incident number, call-taker ID) for minimum retention period per state statutes (typically 90 days to 7 years). Supports instant playback for active incident review and forensic export in standard formats (WAV, MP3) with chain-of-custody metadata. |
| Call-Taker Workstation | D4AD7818 | Integrated dispatch position hardware and software providing call-takers with multi-screen display of caller location on GIS map, incident entry forms, call controls (answer, hold, transfer, conference, release), real-time text display for text-to-911, and protocol-guided interrogation scripts (EMD/EFD/EPD). Includes IP desk phone or USB headset with noise cancellation, dual or triple monitor configuration, and keyboard/mouse interface. Supports simultaneous handling of voice call and text session. Each workstation connects to the ACD for call state, ANI/ALI for location, and CAD for incident creation. |
| CJIS Query Proxy | 50A53859 | Security-hardened proxy server that mediates all Criminal Justice Information Services (CJIS) and NCIC database queries from field MDTs. Enforces CJIS Security Policy 5.9 requirements including advanced authentication, audit logging of every query, encryption at rest and in transit (FIPS 140-2), and operator certification validation. Routes queries to state CJIS switch via dedicated VPN tunnel. Supports vehicle registration, driver license, wanted persons, and stolen property queries with sub-3-second response time. |
| Computer-Aided Dispatch Subsystem | 51F77B59 | Core dispatch engine for a metropolitan PSAP handling 800,000+ calls/year across police, fire, and EMS disciplines. Creates incident records from call data, applies MPDS/EMD/EFD/EPD protocol-based priority classification, and recommends units based on proximity (AVL), capability, jurisdiction, and run card rules. Manages unit status lifecycle (available, dispatched, en route, on scene, transport, clear). Supports multi-agency incidents with unified command tracking. Provides real-time dashboard of pending calls, active incidents, and unit deployment. Maintains duplicate incident detection within 200m/5min window. Processes 2,000+ status changes per hour during peak operations. Must support configurable business rules per agency/jurisdiction. |
| Core LAN Switching Fabric | 50A57018 | Redundant Layer 2/Layer 3 Ethernet switching fabric forming the backbone of a Tier-1 PSAP network. Dual-stack core switches in a collapsed-core topology with sub-50ms failover via VSS or StackWise Virtual. Carries all inter-subsystem traffic including SIP signalling for NG9-1-1, RTP voice streams from radio consoles, CAD database replication, and GIS tile serving. Supports 802.1Q VLANs segregating voice, data, management, and CJIS traffic per NFPA 1221 and CJIS Security Policy v5.9. Minimum 10 Gbps inter-switch links with 1 Gbps access ports. Must sustain zero-packet-loss forwarding during failover of any single switch or link. |
| Dispatch Decision Support Module | 41F73B09 | Algorithmic recommendation engine that suggests optimal unit assignments for each incident based on multiple weighted criteria: geographic proximity (using road-network distance, not Euclidean), unit capability match (incident type vs unit type), current workload per unit, response time predictions using historical data and real-time traffic, and mutual aid agreements for cross-jurisdiction incidents. Implements automatic dispatch for high-priority calls when no dispatcher action occurs within configurable timeout (default 30 seconds). Supports run-card/response plan rules that define mandatory multi-unit responses for specific incident types (e.g., structure fire = 2 engines + 1 ladder + 1 battalion chief + 2 ambulances). Must generate recommendations within 2 seconds of incident creation. |
| Dispatch Radio Console | D0ED7018 | Multi-channel IP-based radio console system used by PSAP dispatchers to communicate with field units over P25 trunked radio. Supports simultaneous monitoring of 20+ talk groups, selective transmit on any monitored channel, emergency alert detection with automatic audio unmute, talk group patching for multi-agency incidents, and instant recall recording. Connects to Radio Gateway Controller via RTP/RTCP over dedicated VLAN. Primary human interface for voice dispatch — failure means dispatchers cannot communicate with police, fire, or EMS units. Typical implementations: Motorola MCC 7500/7600, Harris Symphony, Zetron ACOM. |
| Dispatcher Workstation Interface | 50ED7318 | The dispatch operator console providing the primary human-machine interface for emergency dispatchers. Displays an integrated view combining GIS map with unit positions, active incident list with priority color-coding, recommended unit assignments, call queue status, and radio channel assignments. Supports keyboard-driven workflows with single-keystroke dispatch commands for time-critical operations. Provides split-screen capability for handling multiple concurrent incidents. Integrates text messaging with field units via MDT interface. Renders incident timeline view showing all state transitions and associated units. Must achieve display refresh under 500ms for unit position updates and support 4+ simultaneous monitor outputs per dispatch position. Compliant with NENA PSAP ergonomic guidelines for 12-hour shift operation. |
| DNS and DHCP Services | 40B77318 | Redundant DNS and DHCP infrastructure for the PSAP providing name resolution and dynamic IP address management for all networked devices. Split-horizon DNS architecture: internal zones for PSAP hosts and external-facing zones for ESInet interoperability. DHCP with relay agents across VLANs, issuing addresses with VLAN-specific lease times and options (NTP server, TFTP for IP phone provisioning). Active-active DNS servers with zone transfer replication and sub-second failover. Critical dependency: if DNS fails, SIP URI resolution for NG9-1-1 call routing fails, and CAD-to-CAD links using DNS-based service discovery lose connectivity. |
| Emergency Dispatch System | 50F57BD9 | Public Safety Answering Point (PSAP) system for receiving, triaging, and dispatching emergency services (police, fire, EMS) in a mid-to-large metropolitan area serving 500,000+ population. Handles 911/999 voice calls, NG911 text-to-911, and telematics data. Integrates Computer-Aided Dispatch, GIS mapping, P25 digital radio, mobile data terminals, and records management. Must meet NENA i3 standards for NG911, NFPA 1221 for reliability (99.999% availability), and maintain sub-60-second call answer times per FCC benchmarks. Operates 24/7/365 with hot-standby failover. Interfaces with telephone service providers via ESInet, neighboring PSAPs for mutual aid, and state/federal reporting systems (NIBRS, NFIRS). |
| Encryption Key Management Module | 40B77B59 | P25 AES-256 encryption key management system supporting Over-the-Air Rekeying (OTAR) per TIA-102.AACA. Manages key encryption keys (KEKs) and traffic encryption keys (TEKs) for up to 5000 subscriber radios. Performs scheduled key rotation, emergency key zeroization, and selective unit revocation. Interfaces with Key Management Facility (KMF) and Key Fill Devices (KFDs). CJIS Security Policy v5.9 compliant for law enforcement radio encryption. |
| ESInet SIP Gateway | 50B57118 | Session Initiation Protocol gateway terminating incoming NG911 calls from the Emergency Services IP Network. Handles SIP INVITE, UPDATE, BYE, and REFER transactions for voice, RTT (real-time text), and video media. Performs SIP-to-internal call routing translation, enforces TLS 1.2+ mutual authentication with ESInet border control functions, and provides SRTP key negotiation for encrypted media. Must process concurrent SIP transactions for 150+ simultaneous calls with < 100ms call setup contribution. Interfaces with ECRF/LVF for location validation and with the ACD for call distribution. |
| Firewall and Intrusion Prevention System | 51B53959 | Next-generation firewall cluster providing stateful packet inspection, deep packet inspection, and inline intrusion prevention for the PSAP perimeter and internal zone boundaries. Enforces CJIS Security Policy v5.9 network segmentation: isolates CJIS-connected systems from general PSAP traffic, restricts inter-VLAN flows to authorised protocols and ports, and terminates IPsec VPN tunnels for NCIC/state CJIS queries from mobile data terminals via FirstNet. Active-passive HA pair with sub-second stateful failover. Processes up to 5 Gbps throughput with IPS enabled without exceeding 1ms added latency for voice traffic VLANs. |
| FirstNet LTE Communications Module | D4E55058 | Band 14 FirstNet LTE radio module embedded in or connected to the MDT providing priority and preemption (QPP) data connectivity for public safety. Supports LTE-A Cat 12 with peak 600 Mbps downlink. Implements MCPTT (Mission Critical Push-to-Talk) over LTE as backup voice path. Manages multiple APN profiles: primary FirstNet, secondary commercial LTE roaming, tertiary satellite backhaul for rural coverage. Includes embedded SIM with FirstNet subscriber identity. Antenna is vehicle-roof-mounted with 2x2 MIMO. |
| Geocoding Engine | 51F77159 | Address geocoding and reverse-geocoding service for the emergency dispatch system. Converts street addresses, intersections, and common place names to WGS84 coordinates for incident location plotting. Supports MSAG (Master Street Address Guide) validation for 911 address verification. Must resolve addresses within 200ms with fallback to coordinate-based location when address resolution fails. Maintains a local MSAG database synchronized with the regional addressing authority. |
| Geographic Information System Subsystem | 50F57318 | Spatial data engine and map display for a PSAP serving a metropolitan area of 1,500+ square miles. Provides real-time geocoding of addresses against MSAG-validated street centerline database with 98%+ first-attempt match rate. Displays AVL positions of 500+ field units updated every 10 seconds via GPS. Calculates drive-time routing for unit recommendation using real-time traffic data where available. Manages PSAP jurisdiction boundaries, police beats, fire districts, EMS zones, and mutual aid areas as spatial layers. Supports reverse geocoding for wireless Phase II lat/lon positions. Integrates aerial imagery, building footprints, and floor plans for large structures. Must re-render map view within 500ms of pan/zoom for dispatcher responsiveness. |
| Incident Management Engine | 51B57B59 | Core CAD component that creates, classifies, prioritises, and manages the full lifecycle of emergency incidents. Receives incident creation requests from Call-Taker Workstations (incident type, location, caller data, priority). Applies NIMS/ICS-based incident classification rules to assign priority levels (Emergency, Urgent, Routine). Manages incident state transitions: Created → Dispatched → En Route → On Scene → Resolved → Closed. Supports multi-agency incident merging when multiple calls reference the same event. Handles priority-based queuing with sub-second state transitions for high-priority events. Must support 500+ concurrent active incidents in a large metropolitan PSAP. |
| Incident Report Database | 40853359 | Relational database (typically Oracle or PostgreSQL) storing the canonical record of every emergency incident handled by the PSAP. Stores incident reports, unit activity logs, caller information, disposition codes, and linked multimedia (audio recordings, images). Must comply with state records retention statutes (typically 5-10 years for incident records, 30 days minimum for audio). Supports structured queries for statistical reporting (UCR/NIBRS), FOIA requests, and investigative case building. Read-heavy workload with complex joins across incident, unit, and caller tables. |
| Interoperability Gateway | 50A57858 | ISSI (Inter-RF Subsystem Interface) and CSSI (Console Subsystem Interface) gateway enabling cross-agency radio interoperability for mutual aid. Bridges P25 trunked systems from different vendors and different frequency bands (VHF, UHF, 700/800 MHz). Supports up to 48 simultaneous cross-patched talk groups. Implements ISSI Group Call, Unit-to-Unit Call, and Emergency services per TIA-102.BACA. Critical during multi-agency responses to wildfires, mass casualty events, and HAZMAT incidents. |
| Map Tile Server | 50E57108 | Web map tile server providing pre-rendered and on-demand raster/vector map tiles for the dispatcher workstation GIS display. Serves OpenStreetMap-compatible tile layers including street networks, aerial imagery, parcel boundaries, hydrants, and jurisdiction boundaries. Must sustain 200+ concurrent tile requests at sub-200ms response time to support smooth pan/zoom across 24+ dispatcher workstations. Uses z/x/y tile addressing with caching at edge CDN nodes within the PSAP LAN. |
| Mobile Data Gateway Server | 50B57118 | Server-side middleware at the PSAP that bridges the CAD system to the cellular/FirstNet data network. Manages authenticated sessions with 200+ concurrent MDTs. Converts CAD dispatch messages into compressed mobile-optimized payloads. Implements store-and-forward queuing for units in dead zones. Provides WebSocket-based persistent connections with heartbeat monitoring at 15-second intervals. Runs as redundant active-standby pair with sub-5-second failover. |
| Mobile Data Subsystem | 50FD7A59 | Field communications and data terminal subsystem connecting 500+ police, fire, and EMS vehicles to the PSAP via cellular (LTE/FirstNet) and Wi-Fi networks. Mobile Data Terminals (MDTs) receive CAD dispatch assignments with incident details, location, and routing. Officers/medics update status via MDT touchscreen, reducing radio traffic by 40-60%. Supports NCIC/NLETS query from the field for wants/warrants, vehicle registration, and driver's license. Provides secure messaging between units and dispatch. Reports GPS position every 10 seconds for AVL. Supports pre-arrival instructions display for EMS (EMD cards). Must operate on FirstNet Band 14 with priority and preemption during network congestion. |
| Mobile Data Terminal Application | 40FD7119 | Ruggedized in-vehicle software application running on MDT hardware (typically Panasonic Toughbook or Motorola LEX L11). Displays dispatch assignments, incident details, map overlays, unit status buttons, and NCIC/CJIS query forms. Receives push notifications from CAD. Operates over FirstNet Band 14 LTE with fallback to commercial LTE. Must maintain session state across coverage gaps using store-and-forward. Supports touch and keyboard input in moving vehicles under vibration. |
| Network Infrastructure Subsystem | 50A53018 | Resilient IP network backbone for a Tier-1 PSAP with 99.999% availability requirement per NFPA 1221. Provides redundant 10GbE LAN fabric connecting all PSAP workstations, servers, and subsystems via dual-core switches with sub-50ms failover. WAN connectivity via dual diverse-path fiber to ESInet for NG911 call delivery, plus legacy CAMA trunk interface. Dedicated MPLS circuits to backup PSAP site 15 miles away with active-active database replication. Integrated cybersecurity stack: next-gen firewall, network IDS/IPS, SIEM integration, and micro-segmentation between subsystem VLANs. Supports QoS for voice/radio traffic prioritization (DSCP EF marking). UPS-backed with 30-minute battery runtime plus generator transfer within 10 seconds. |
| Network Management and Monitoring System | 40F77308 | Centralised network operations platform for the PSAP providing SNMP v3 polling, syslog aggregation, NetFlow analysis, and real-time health dashboards for all network infrastructure components. Monitors link utilisation, switch CPU/memory, firewall session counts, and WAN circuit availability. Generates SNMP traps and email/SMS alerts when thresholds are breached (link down, CPU >80%, latency >5ms on voice VLANs). Maintains historical performance data for capacity planning with 12-month retention. Integrates with the Supervisor Dashboard Module for network status visibility to dispatch supervisors during major incidents. |
| Radio Communications Subsystem | 54ED7218 | P25 Phase II TDMA digital radio dispatch console subsystem for a multi-agency PSAP. Provides 24 simultaneous radio channels across police, fire, and EMS talkgroups via IP-connected dispatch consoles. Supports channel patching for multi-agency interoperability during major incidents. Integrates ISSI gateway for cross-system P25 interoperability with neighboring jurisdictions and federal agencies. Provides instant recall recording of all radio traffic with 90-day retention. Supports emergency button (orange button) activation with automatic console alert and audio priority. Console audio mixing allows dispatchers to monitor 6+ channels simultaneously with selectable transmit. Must maintain <150ms voice latency end-to-end for real-time tactical communications. |
| Radio Gateway Controller | 51F57018 | IP-based gateway bridging the dispatch console network to the P25 Phase II TDMA trunked radio infrastructure. Converts VoIP (G.711/IMBE vocoder) to P25 ISSI fixed-station interface protocol. Manages talk group affiliations, channel grants, and PTT arbitration for console positions. Handles site trunking failover when master site controller is unreachable. Maintains heartbeat with all connected base stations. Processes approximately 500 PTT events per minute during peak operations. Failure isolates the dispatch center from the entire radio network. |
| Radio Logging Recorder | D4C41259 | Dedicated audio recording system capturing 100% of radio transmissions across all monitored talk groups. Records transmitter unit ID, talk group, timestamp (GPS-synchronized NTP), and audio with minimum 8kHz/16-bit quality. Stores recordings for minimum 7 years per state retention requirements. Supports instant replay for dispatchers (last 60 seconds per channel). Provides chain-of-custody metadata for legal proceedings. Separate from telephony call recording to ensure radio-specific compliance. |
| Records Management Subsystem | 40A53359 | Incident records, voice logging, and compliance reporting subsystem for a PSAP processing 800,000+ calls/year. Archives complete incident lifecycle from call receipt through unit clear with all CAD actions timestamped. Records all telephony audio (100% call recording) and radio traffic with dual-redundant recorders. Stores screen recordings of dispatcher workstations for QA review. Generates NIBRS-compliant incident reports for law enforcement and NFIRS reports for fire service. Provides statistical reporting on response times, call volumes, and unit utilization for operational management. Supports legal discovery with chain-of-custody metadata. Data retention: voice recordings 5 years, CAD logs 7 years, per state statute. Must support 50+ concurrent retrieval queries without degrading recording performance. |
| Records Search and Retrieval Engine | 50E73B19 | Full-text and structured search engine (typically Elasticsearch or SOLR backed) providing rapid retrieval of incident records across millions of historical entries. Supports fuzzy name matching, address proximity search, date range queries, and incident type filtering. Used by investigators, supervisors, and records clerks. Must return results within 2 seconds for single-field queries across 5 years of data (approximately 2 million incident records for a metro PSAP). Enforces role-based access control ensuring sealed juvenile records and protected caller information are only visible to authorized personnel. |
| Report Generation Module | 51E77B58 | Automated report generator producing standardized statistical and compliance reports from incident data. Generates FBI UCR (Uniform Crime Reporting) and NIBRS (National Incident-Based Reporting System) submissions, state-mandated monthly activity reports, response time analytics, and ad-hoc custom reports. Outputs in PDF, CSV, and XML formats. Scheduled reports run nightly during low-activity periods. Must handle data aggregation across 100,000+ incidents per year for statistical accuracy. |
| Retention and Purge Manager | 41B73B79 | Automated compliance module that enforces jurisdiction-specific records retention policies. Monitors record age against configurable retention schedules (incident reports: 7 years, audio recordings: 180 days to 2 years depending on call type, CAD event logs: 5 years). Generates retention expiration alerts, executes certified purge operations with cryptographic deletion verification, and maintains purge audit logs for regulatory compliance. Must support legal hold overrides that suspend purging for records subject to litigation or investigation. |
| Routing Engine | 41F73308 | Road network routing engine computing turn-by-turn travel time and distance estimates for dispatch recommendation. Uses a weighted road graph incorporating speed limits, one-way restrictions, traffic signal density, historical response-time data, and real-time traffic feeds. Must compute shortest-time routes between any two points in the jurisdiction within 500ms to support the 2-second recommendation window. Supports emergency vehicle routing with configurable signal preemption assumptions. |
| Spatial Database | 40A53158 | PostGIS-based geospatial data store containing all geographic layers used by the emergency dispatch system: jurisdiction boundaries, ESZ (Emergency Service Zones), fire management zones, police beats, EMS response areas, hydrant locations, hazmat sites, school zones, hospital locations, and road centerlines. Serves as the authoritative geographic reference for all spatial queries. Updated quarterly from county GIS and maintained by GIS administrators. Supports spatial indexing for point-in-polygon queries completing within 50ms. |
| Supervisor Dashboard Module | 50ED7B08 | Real-time operational oversight component for PSAP supervisors and shift commanders. Aggregates system-wide metrics: call queue depth and oldest-waiting-call age, average and 95th-percentile response times by incident type, unit utilization rates by district and agency, active incident count by priority, and dispatcher workload balance. Provides configurable threshold-based alerts (visual and audible) for queue overload (>5 calls waiting or >60 seconds oldest call), response time degradation, and unit availability drops below minimum staffing levels. Supports drill-down from summary metrics to individual incidents and units. Generates shift-handoff reports and daily statistical summaries. Refreshes dashboard at 5-second intervals per SYS-REQS-007. Must support web-based remote access for off-site supervisors via authenticated HTTPS connection. |
| Talkgroup Management Module | 40B77B58 | Software module managing P25 talk group assignments, dynamic regrouping, and talk group patching for multi-agency incidents. Maintains mapping between dispatch positions and talk group affiliations. Supports NENA-standard mutual aid talk groups. Handles priority preemption for emergency traffic. Configures up to 500 talk groups across multiple zones. Integrates with CAD for automatic talk group assignment based on incident type and jurisdiction. |
| Text-to-911 Gateway | 50F77359 | Gateway processing text-based emergency communications received via the ESInet text control centre. Supports SMS-based text-to-911, RTT (Real-Time Text) per RFC 4103, and SIP MESSAGE-based text sessions. Converts between text transport protocols and presents unified text session interface to call-taker workstations. Maintains session state for multi-message conversations, handles session timeout and reconnection. Must deliver text messages to call-taker display within 1 second of receipt. Stores complete text transcripts for evidentiary records. |
| Unit Tracking and Status Module | 40B57319 | Real-time tracking component for all field units (police, fire, EMS vehicles) using AVL (Automatic Vehicle Location) data received via Mobile Data Terminals or dedicated GPS feeds at 5-second update intervals. Maintains unit status codes (Available, Dispatched, En Route, On Scene, Out of Service) with timestamp logging. Integrates with GIS for map display of unit positions. Provides proximity calculations for dispatch recommendations. Tracks unit capabilities (e.g., ALS vs BLS ambulance, ladder truck vs engine) and shift assignments. Must handle 2000+ simultaneous unit tracks in a metropolitan service area with position update latency under 3 seconds from GPS fix to map display. |
| WAN and ESInet Gateway | 50B57018 | Edge routing and WAN termination equipment connecting the PSAP to the Emergency Services IP Network (ESInet), PSTN via SIP trunks, regional backup PSAPs, and the public internet for CAD-to-CAD interoperability. Handles BGP peering with ESInet service provider and MPLS VPN termination for inter-PSAP links. Supports policy-based routing to prioritise NG9-1-1 SIP INVITE traffic over all other WAN flows. Dual redundant routers with VRRP or HSRP, each with independent WAN uplinks from diverse carriers. Must maintain ESInet connectivity during single-carrier failure with convergence under 5 seconds. |
| Component | Belongs To |
|---|---|
| Call Handling Subsystem | Emergency Dispatch System |
| Computer-Aided Dispatch Subsystem | Emergency Dispatch System |
| Geographic Information System Subsystem | Emergency Dispatch System |
| Radio Communications Subsystem | Emergency Dispatch System |
| Mobile Data Subsystem | Emergency Dispatch System |
| Records Management Subsystem | Emergency Dispatch System |
| Network Infrastructure Subsystem | Emergency Dispatch System |
| ESInet SIP Gateway | Call Handling Subsystem |
| Automatic Call Distribution Engine | Call Handling Subsystem |
| ANI/ALI Database Interface | Call Handling Subsystem |
| Call-Taker Workstation | Call Handling Subsystem |
| Text-to-911 Gateway | Call Handling Subsystem |
| Call Recording System | Call Handling Subsystem |
| Incident Management Engine | Computer-Aided Dispatch Subsystem |
| Unit Tracking and Status Module | Computer-Aided Dispatch Subsystem |
| Dispatch Decision Support Module | Computer-Aided Dispatch Subsystem |
| Dispatcher Workstation Interface | Computer-Aided Dispatch Subsystem |
| CAD Database and Event Logger | Computer-Aided Dispatch Subsystem |
| Supervisor Dashboard Module | Computer-Aided Dispatch Subsystem |
| Dispatch Radio Console | Radio Communications Subsystem |
| Radio Gateway Controller | Radio Communications Subsystem |
| Talkgroup Management Module | Radio Communications Subsystem |
| Interoperability Gateway | Radio Communications Subsystem |
| Radio Logging Recorder | Radio Communications Subsystem |
| Encryption Key Management Module | Radio Communications Subsystem |
| Map Tile Server | Geographic Information System Subsystem |
| Geocoding Engine | Geographic Information System Subsystem |
| Routing Engine | Geographic Information System Subsystem |
| Spatial Database | Geographic Information System Subsystem |
| Mobile Data Terminal Application | Mobile Data Subsystem |
| Mobile Data Gateway Server | Mobile Data Subsystem |
| CJIS Query Proxy | Mobile Data Subsystem |
| Automatic Vehicle Location Module | Mobile Data Subsystem |
| FirstNet LTE Communications Module | Mobile Data Subsystem |
| Incident Report Database | Records Management Subsystem |
| Records Search and Retrieval Engine | Records Management Subsystem |
| Retention and Purge Manager | Records Management Subsystem |
| Report Generation Module | Records Management Subsystem |
| Core LAN Switching Fabric | Network Infrastructure Subsystem |
| WAN and ESInet Gateway | Network Infrastructure Subsystem |
| Firewall and Intrusion Prevention System | Network Infrastructure Subsystem |
| Network Management and Monitoring System | Network Infrastructure Subsystem |
| Time Synchronization Service | Network Infrastructure Subsystem |
| DNS and DHCP Services | Network Infrastructure Subsystem |
| Uninterruptible Power Supply System | Network Infrastructure Subsystem |
| From | To |
|---|---|
| ESInet SIP Gateway | Automatic Call Distribution Engine |
| ANI/ALI Database Interface | Call-Taker Workstation |
| Text-to-911 Gateway | Automatic Call Distribution Engine |
| Call Recording System | ESInet SIP Gateway |
| Call Recording System | Call-Taker Workstation |
| Call-Taker Workstation | Computer-Aided Dispatch Subsystem |
| Incident Management Engine | Dispatch Decision Support Module |
| Unit Tracking and Status Module | Dispatch Decision Support Module |
| Dispatch Decision Support Module | Dispatcher Workstation Interface |
| Dispatcher Workstation Interface | Incident Management Engine |
| Incident Management Engine | CAD Database and Event Logger |
| CAD Database and Event Logger | Supervisor Dashboard Module |
| Unit Tracking and Status Module | CAD Database and Event Logger |
| Incident Management Engine | Supervisor Dashboard Module |
| Dispatch Radio Console | Radio Gateway Controller |
| Radio Gateway Controller | Talkgroup Management Module |
| Radio Gateway Controller | Interoperability Gateway |
| Radio Logging Recorder | Radio Gateway Controller |
| Encryption Key Management Module | Radio Gateway Controller |
| Dispatch Radio Console | Talkgroup Management Module |
| Geocoding Engine | Spatial Database |
| Routing Engine | Spatial Database |
| Map Tile Server | Spatial Database |
| Routing Engine | Dispatch Decision Support Module |
| Map Tile Server | Dispatcher Workstation Interface |
| Geocoding Engine | ANI/ALI Database Interface |
| Mobile Data Terminal Application | FirstNet LTE Communications Module |
| Mobile Data Terminal Application | Automatic Vehicle Location Module |
| FirstNet LTE Communications Module | Mobile Data Gateway Server |
| Mobile Data Gateway Server | CJIS Query Proxy |
| Mobile Data Terminal Application | CJIS Query Proxy |
| Mobile Data Gateway Server | Incident Management Engine |
| Mobile Data Gateway Server | Unit Tracking and Status Module |
| Automatic Vehicle Location Module | Unit Tracking and Status Module |
| Records Search and Retrieval Engine | Incident Report Database |
| Retention and Purge Manager | Incident Report Database |
| Report Generation Module | Incident Report Database |
| Incident Report Database | CAD Database and Event Logger |
| Incident Report Database | Call Recording System |
| Incident Report Database | Radio Logging Recorder |
| Core LAN Switching Fabric | Firewall and Intrusion Prevention System |
| Core LAN Switching Fabric | WAN and ESInet Gateway |
| WAN and ESInet Gateway | Firewall and Intrusion Prevention System |
| Network Management and Monitoring System | Core LAN Switching Fabric |
| Time Synchronization Service | Core LAN Switching Fabric |
| DNS and DHCP Services | Core LAN Switching Fabric |
| Uninterruptible Power Supply System | Core LAN Switching Fabric |
| Core LAN Switching Fabric | ESInet SIP Gateway |
| Core LAN Switching Fabric | Radio Gateway Controller |
| Core LAN Switching Fabric | CAD Database and Event Logger |
| WAN and ESInet Gateway | ESInet SIP Gateway |
| Firewall and Intrusion Prevention System | CJIS Query Proxy |
| Incident Management Engine | Radio Gateway Controller |
| Records Search and Retrieval Engine | Spatial Database |
| Component | Output |
|---|---|
| ESInet SIP Gateway | Authenticated SIP sessions |
| Automatic Call Distribution Engine | Routed call assignments |
| ANI/ALI Database Interface | Caller location and identity data |
| Call Recording System | Timestamped audio and text recordings |
| Text-to-911 Gateway | Unified text sessions |
| Incident Management Engine | Classified and prioritised incident objects |
| Unit Tracking and Status Module | Real-time unit positions and status data |
| Dispatch Decision Support Module | Optimal unit assignment recommendations |
| Dispatcher Workstation Interface | Dispatch commands and incident updates |
| CAD Database and Event Logger | Persistent incident records and audit trails |
| Supervisor Dashboard Module | Aggregated operational metrics and alerts |
| Dispatch Radio Console | dispatcher voice transmissions and talk group patches |
| Radio Gateway Controller | P25 RF channel grants and VoIP-to-RF bridged audio |
| Talkgroup Management Module | talk group affiliation tables and dynamic regrouping commands |
| Interoperability Gateway | cross-agency patched audio channels |
| Radio Logging Recorder | timestamped radio transmission recordings with unit ID metadata |
| Encryption Key Management Module | encrypted traffic encryption keys and OTAR rekey commands |
| Map Tile Server | rendered map tiles (raster/vector) |
| Geocoding Engine | WGS84 coordinates from addresses |
| Routing Engine | travel time and route estimates |
| Spatial Database | geospatial query results |
| Mobile Data Terminal Application | dispatch assignment displays and unit status updates |
| Mobile Data Gateway Server | mobile-optimized dispatch payloads and session state |
| CJIS Query Proxy | NCIC/CJIS query responses and audit trail records |
| Automatic Vehicle Location Module | GPS position reports with unit ID at 10-second intervals |
| FirstNet LTE Communications Module | encrypted LTE data transport with QPP priority |
| Incident Report Database | canonical incident records and audit trails |
| Records Search and Retrieval Engine | filtered incident search results with role-based redaction |
| Retention and Purge Manager | retention compliance reports and certified purge audit logs |
| Report Generation Module | UCR/NIBRS submissions and statistical reports |
| Core LAN Switching Fabric | Layer 2/3 packet forwarding for all PSAP inter-subsystem traffic |
| WAN and ESInet Gateway | ESInet and WAN connectivity for NG9-1-1 call ingress and inter-PSAP links |
| Time Synchronization Service | Stratum-1 NTP/PTP time reference for all PSAP subsystems |
| Firewall and Intrusion Prevention System | Stateful packet inspection and CJIS-compliant network segmentation |