MCX: service family and functional architecture

MCX is more than a voice server

Niko needs voice communication; an on-board application needs data exchange. MCX is the collective term for the standardised Mission-Critical services MCPTT, MCData and MCVideo. They share foundations but perform different communication tasks. An MCX client uses the particular service; server functions process its state and communication. [S23; S50]

MCPTT means Mission Critical Push To Talk. It supports, among other capabilities, voice with controlled permission to speak. MCData provides different data services. MCVideo addresses Mission-Critical video. A service's existence within MCX does not establish that it is required by the FRMCS profile being considered or implemented in a product. The selected FRMCS service edition specifies MCPTT ad hoc group communication and MCData IP Connectivity and Short Data Service. [S09, clauses 5.1.1 and 6.2]

Shared foundations, separate service states

The common architecture includes identity, configuration and security functions. A client can therefore be correctly identified without being authorised for every communication type. Authorisation grants a particular use. The service server applies the service's rules; the SIP Core alone does not decide every service-specific detail.

IP Connectivity, or IPCon, is the MCData service for IP communication between integrated endpoints. Short Data Service, or SDS, is a message-oriented data service. A continuous IP connection and a short message are different service models. Video carried as a data stream does not automatically demonstrate use of MCVideo either.

Where the client resides

With tight coupling, the application contains MCX client functions. With loose coupling, the application uses a programming interface while FRMCS equipment performs client procedures. The precise arrangement depends on the application profile. Talbahn cannot therefore select coupling solely according to product preference. The on-board and gateway lessons apply this distinction in detail. [S10, clauses 5.6–5.7]

A service is not proof of availability

An MCX server may be reachable while identity verification, media distribution or application integration fails. For voice, Talbahn must observe participation, floor and audible speech. For data, it checks session, data flow and processing by the remote application. Both cases use the common service architecture but require different success evidence.

Check your understanding

A supplier demonstrates video over a data connection and claims that this proves MCVideo and all FRMCS services. What distinctions are missing?

Model answer

Media content and the communication service used are not the same. Identify the actual service, its profile, the implementation and the tested combination. A successful data stream demonstrates neither MCVideo procedures nor voice functions or failure behaviour. Evidence must match the particular use case.

What to remember

MCX is a service family. Shared foundations connect the services, but their procedures and success conditions differ.

Your Talbahn case file

Assign voice, a data connection and a short message to service models. For each model, record what “successful” means to the application.