Crew Mobilisation and Acknowledgement

Overview#

Turn an accepted unit recommendation into a documented mobilisation order in seconds, with two-tap crew confirmation across radio, mobile, and pager channels, all without dispatcher rekeying.

The Crew Mobilisation and Acknowledgement module takes an accepted unit recommendation, builds a parallel mobilisation order across every available bearer, and captures crew acknowledgement through a minimal two-step confirmation flow. Each unit progresses through a defined operational status sequence, and every transition is recorded on the unified incident timeline so the canonical incident view reflects the full mobilisation choreography from the moment the order is issued to the moment the crew clears.

Key Features#

• Multi-Channel Mobilisation Order: A single accepted recommendation is pushed in parallel over the responder mobile data terminal app, TETRA SDS short-data messages to the in-vehicle radio, and an optional pager fallback, so a crew is reached by whichever bearer is available at the time.

• Two-Tap Crew Acknowledgement: Both the mobile app and the radio terminal surface a clear acknowledge action requiring only two deliberate taps, eliminating ambiguity about whether the crew has actually seen and accepted the job.

• Documented Status State Machine: Unit progress moves through a defined sequence, assigned, en-route, on-scene, at-hospital, and clear, so the operational picture has a consistent shape for every job regardless of crew type or vehicle.

• Durable Assignment Ledger: Each status transition is written as an immutable record linked to the vehicle and crew, giving a reliable audit of who was mobilised, where they were sent, and when each transition occurred.

• CloudEvent Status Stream: Every state change is published as a CloudEvents 1.0 envelope so downstream systems and the unified incident timeline can react to crew movement without polling. The event type identifies each specific transition, making selective subscription straightforward.

• Secure Mobile Push Channel: Mobile delivery is signed using HMAC SHA-256 following the Standard Webhooks specification, and the responder app authenticates with OAuth 2.0 PKCE so neither dispatcher nor crew handles long-lived shared secrets.

Use Cases#

Live Ambulance Mobilisation#

A nearest-suitable ambulance is recommended by the intelligent dispatch module, the dispatcher accepts the recommendation, and the crew acknowledges the job from the cab before leaving the station yard. The incident record updates automatically without the dispatcher rekeying any status.

Radio-First Crews#

Crews operating in areas where mobile data coverage is unreliable receive the mobilisation order over TETRA SDS and send acknowledgement from the radio terminal. The same status state machine applies whether the crew uses the mobile app or the radio.

Mixed Vehicle Estates#

Organisations with older vehicles can route delivery to pager while newer vehicles use the mobile data terminal. Both paths feed the same status sequence and the same assignment ledger, so the operational and audit picture is consistent across the fleet.

Cross-Bearer Audit and After-Action Review#

The assignment ledger records which channel delivered the mobilisation order and which channel returned the acknowledgement. After-action reviews and formal enquiries can reconstruct the exact communication sequence for any incident.

Unified Incident Replay#

A controller or investigator rebuilding an incident sees the complete mobilisation choreography, assigned, en-route, on-scene, at-hospital, clear, on the same timeline as the originating call, any clinical events, and partner-agency updates.

Integration#

Customers and partners connect to the Crew Mobilisation and Acknowledgement capability through the platform's standard interfaces.

• REST and GraphQL surfaces: The mobile data terminal and any authorised system can submit crew acknowledgements and status updates over REST. Status history and assignment records are queryable through the GraphQL API with standard tenant-scoped authentication.

• CloudEvents webhooks: Downstream systems subscribe to unit-status-changed events by registering a webhook endpoint. Payloads are signed using the Standard Webhooks HMAC SHA-256 scheme so receivers can verify integrity and origin with commodity libraries.

• OAuth 2.0 PKCE for mobile clients: The responder mobile app obtains a short-lived session token using the PKCE flow. No long-lived secrets are embedded in the app binary, and token exchange is bound to the authenticated crew member's identity.

• Normalised mobilisation model: The mobilisation order follows an interoperable resource-messaging structure compatible with EDXL-RM, so partner agencies and mutual-aid systems can consume the same payload without bespoke adapters.

• TETRA SDS gateway: The TETRA short-data leg connects through a standards-conformant SDS gateway. Inbound and outbound SDS frames follow the ETSI air-interface and SDS profile specifications, keeping integration with existing radio infrastructure vendor-neutral.

• Incident timeline integration: Each acknowledgement and status event is appended to the unified incident timeline as a CloudEvents envelope, keeping the canonical incident view authoritative across all channels and systems involved in a response.

Open Standards#

• ETSI TS 100 392-2: TETRA voice and data air interface; defines the status code semantics and PDU structure used for in-vehicle mobilisation and acknowledgement messages.

• ETSI TS 103 269-1 D15: TETRA Short Data Service (SDS) profile; governs PDU layout, segmentation rules, and protocol identifier values for short-data mobilisation messages.

• ETSI TS 100 392-3-7: TETRA Inter-System Interface (ISI) over IP; defines the frame envelope for TETRA-IP gateway interconnection with partner agency radio infrastructure.

• ETSI EN 300 392-7: TETRA security specification covering PEI authentication and AES-CMAC link-layer integrity for deployments that extend protection to the air interface.

• ETSI ETS 300 392-13: TETRA Location Information Protocol (LIP); used for GPS poll PDUs that accompany the status state machine to provide crew location context.

• EDXL-RM 1.0 (OASIS): Emergency Data Exchange Language Resource Messaging; the mobilisation order is shaped as an interoperable resource-messaging envelope so mutual-aid partners can consume the same payload.

• CloudEvents 1.0 (CNCF): Every unit-status transition is published as a CloudEvents envelope, enabling any compliant subscriber to consume the status stream without bespoke transport code.

• Standard Webhooks (HMAC SHA-256): Secure push delivery to the responder mobile app uses the Standard Webhooks signing scheme, allowing receivers to verify payload integrity and origin using standard HMAC tooling.

• OAuth 2.0 with PKCE (RFC 7636): The responder mobile app authenticates using the Proof Key for Code Exchange extension, binding mobilisation and acknowledgement traffic to a verified crew session without embedding static secrets.

• 3GPP TS 23.379 (MCPTT): The architecture is designed to allow future migration of the mobilisation channel onto Mission-Critical Push-To-Talk over broadband without changes to the order model or status state machine.

Security and Compliance#

All mobilisation orders and acknowledgement confirmations are tied to an authenticated session. The assignment ledger is written as an append-only record, ensuring that no transition can be silently altered after the fact. Webhook delivery is integrity-protected using HMAC SHA-256, and the TETRA link layer supports AES-CMAC protection for deployments that require air-interface security. Access to mobilisation endpoints is scoped to the authenticated tenant and requires an authorised crew or dispatcher identity.

Last Reviewed: 2026-05-05 / Last Updated: 2026-05-05