In Phase 1, we are testing the core communication control and network selection logic that forms the backbone of the Communications Control Software with WiFi, LTE, 5G, and P25. This phase focuses on the Communications Controller working with simplified representations of the Radio Firmware and Mobile Application, along with basic control channel behavior. As a result, we will be directly testing the following requirements from the original document: FR-1 Push to Talk behavior that sends a request to the control channel to join a talk group when the user activates PTT, FR-3 automatic switching between WiFi, 5G, LTE, and P25 to select the most stable connection, FR-4 emergency alerts that are prioritized and sent immediately to the command center and related units, FR-8 reporting abnormal conditions and switching to a backup communication path, and FR-9 recording time, channel, participating units, and users for each call and alert event.
We will also indirectly test FR-2 and FR-6 by having the controller operate with predefined talk groups and multiuser communication flows that assume group definitions already exist, even though user-facing group management and cross department workflows are not yet fully integrated. The tests in this phase will involve sending control and signaling requests from simulated radios and mobile clients into the Communications Controller, observing network selection decisions, verifying that PTT sessions and emergencies are correctly established and torn down, and confirming that abnormal network conditions trigger failover and are reflected in the system logs.
| Test Case Id | Test Case Objective | Test Case Description | Expected Results |
|---|---|---|---|
| P1-01 | Verify basic Push-to-Talk session establishment for a single unit (FR-1). | Using a simulated radio, the test harness sends a PTT request to join a predefined talk group over a stable primary network. The Communications Controller negotiates with the control channel stub to establish a session and allocate any required resources. | Controller sends a join request to the control channel; the session state for the unit transitions from idle to active in the talk group; the controller acknowledges the established session back to the simulated radio client. |
| P1-02 | Confirm PTT session establishment for multiple units in the same talk group (FR-1, FR-6). | Several simulated radios, all configured with the same existing talk group, sequentially send PTT join requests via the test harness. The Communications Controller processes each request using the same control channel and network abstraction layer. | All units are admitted into the talk group according to controller rules; each join is acknowledged; the internal state reflects all participating units in the session without conflicts or dropped requests. |
| P1-03 | Validate automatic network selection on initial session setup (FR-3). | The network simulator exposes WiFi, LTE, 5G, and P25 links with predefined quality levels. A simulated radio sends a PTT join request. The Communications Controller must choose the most stable network based on the configured selection algorithm. | The controller selects the network that matches the configured stability/priority policy and records the chosen path in session state. The join request completes successfully using that network. |
| P1-04 | Verify automatic network handover when the active network degrades (FR-3, FR-8). | Start a PTT session over a selected primary network. While the session is active, the network simulator gradually degrades the primary link beyond acceptable thresholds. The Communications Controller must detect the degradation and switch the session to a more stable alternate network without explicit user action. | The controller detects degradation based on configured metrics and switches the session to a backup network. The session remains logically active; the controller updates its internal state to reflect the new path and issues any necessary control messages to the control channel stub. |
| P1-05 | Ensure emergency alerts are prioritized and routed immediately (FR-4). | With normal PTT traffic already active, a simulated radio issues an emergency alert request to the Communications Controller. The controller must treat this request with higher priority than standard PTT join/leave operations. | The emergency alert is accepted and processed ahead of any queued non-emergency traffic. The controller sends alert messages to the command-center endpoint stub and all relevant units, and marks the originating unit/session as in an emergency state. |
| P1-06 | Verify emergency alerts generate appropriate log entries (FR-4, FR-9). | Trigger one or more emergency alert requests from different simulated radios and let the controller process and clear them. After execution, query the system log store through the test harness to inspect recorded events. | For each emergency alert, logs include at minimum: timestamp, originating unit, associated talk group, alert type, and any network path information. Logged entries appear in the correct order and can be correlated back to the originating requests. |
| P1-07 | Confirm detection and reporting of abnormal network conditions (FR-8). | While a PTT session is active, the network simulator injects abnormal conditions on the current network path but does not fully terminate the link. The controller must recognize the abnormal state and report it. | The controller flags the affected network as abnormal, raises an internal alarm or status indication, and records the condition in the logs. If policy dictates that the session remain on the current link, no unintended teardown occurs; otherwise, failover is initiated per configuration. |
| P1-08 | Verify automatic switchover to a backup communication path on failure (FR-8). | Establish a PTT session on a primary network. The network simulator then forces a hard failure of that network. The Communications Controller must switch the active session to a configured backup network and continue operation. | The controller detects the failure, selects an available backup network, transitions the session onto the backup, and updates its internal state. The session remains active from the simulated radio's perspective, and a corresponding failover event is logged. |
| P1-09 | Validate logging of call and session metadata for PTT flows (FR-9). | Execute a sequence of normal PTT sessions involving one or more simulated radios and talk groups. At the end of the sequence, query the log repository to inspect the records associated with these sessions. | For each session, logs capture at least: start and end time, talk group, channel or network used, participating units, and any failover events. Entries are complete, consistent with observed controller behavior, and can be matched to the sequence of test actions. |
| P1-10 | Confirm that preconfigured talk groups are correctly honored by the controller (FR-2, FR-6). | Initialize the Communications Controller with a predefined set of talk groups and member assignments. Use simulated radios to request PTT sessions for valid and invalid group IDs, and to attempt to join groups where membership should or should not be allowed. | For valid combinations, the controller establishes sessions using the existing group definitions. For invalid group IDs or unauthorized membership, the controller rejects the request and records an appropriate error or denial event in its logs, without impacting existing sessions. |