MCX: Dienstefamilie und Funktionsarchitektur

MCX ist mehr als ein Sprachserver

Niko benötigt Sprachkommunikation, eine Fahrzeuganwendung benötigt Datenaustausch. MCX ist der Sammelbegriff für die standardisierten Mission-Critical-Dienste MCPTT, MCData und MCVideo. Sie nutzen gemeinsame Grundlagen, erfüllen aber unterschiedliche Kommunikationsaufgaben. Ein MCX-Client nimmt den jeweiligen Dienst in Anspruch; Serverfunktionen bearbeiten dessen Zustand und Kommunikation. [S23; S50]

MCPTT bedeutet Mission Critical Push To Talk. Es unterstützt unter anderem Sprache mit geregeltem Sprechrecht. MCData stellt verschiedene Datendienste bereit. MCVideo behandelt Mission-Critical-Video. Aus der Existenz eines Dienstes in der MCX-Familie folgt weder seine Verpflichtung im betrachteten FRMCS-Profil noch seine Implementierung in einem Produkt. Die verwendete FRMCS-Serviceausgabe konkretisiert MCPTT-Ad-hoc-Gruppenkommunikation sowie MCData IP Connectivity und Short Data Service. [S09, Abschnitte 5.1.1 und 6.2]

Gemeinsame Grundlagen, eigene Dienstzustände

Die gemeinsame Architektur umfasst Identitäts-, Konfigurations- und Sicherheitsfunktionen. Ein Client kann deshalb korrekt identifiziert sein, ohne für jede Kommunikationsart autorisiert zu sein. Autorisierung bedeutet die Freigabe einer konkreten Nutzung. Der Dienstserver wertet die für den Dienst geltenden Regeln aus; der SIP Core allein entscheidet nicht über jedes fachliche Detail.

IP Connectivity, kurz IPCon, bezeichnet hier den MCData-Dienst für IP-Kommunikation zwischen angebundenen Endpunkten. Short Data Service, kurz SDS, ist ein nachrichtenorientierter Datendienst. Eine kontinuierliche IP-Verbindung und eine kurze Nachricht sind unterschiedliche Dienstmodelle. Auch ein Video, das als Datenstrom übertragen wird, beweist nicht automatisch die Nutzung von MCVideo.

Wo der Client sitzt

Bei Tight Coupling enthält die Anwendung die MCX-Client-Funktionen. Bei Loose Coupling nutzt die Anwendung eine Programmierschnittstelle, während FRMCS-Ausrüstung die Client-Verfahren übernimmt. Die genaue Zuordnung hängt vom Anwendungsprofil ab. Deshalb darf die Talbahn die Kopplungsart nicht allein nach einer Produktvorliebe wählen. Die Fahrzeug- und Gateway-Lektionen wenden diese Unterscheidung konkret an. [S10, Abschnitte 5.6–5.7]

Ein Dienst ist kein Verfügbarkeitsbeweis

Ein MCX-Server kann erreichbar sein, während Identitätsprüfung, Medienverteilung oder Anwendungsanbindung nicht funktionieren. Für den Sprachfall muss die Talbahn Teilnahme, Sprechrecht und hörbare Sprache beobachten. Für den Datenfall prüft sie Sitzung, Datenfluss und die Verarbeitung durch die Gegenanwendung. Beide Fälle nutzen die gemeinsame Dienstarchitektur, brauchen aber unterschiedliche Erfolgsnachweise.

Prüfe dein Verständnis

Ein Anbieter demonstriert Video über eine Datenverbindung und erklärt damit MCVideo sowie alle FRMCS-Dienste für nachgewiesen. Welche Unterscheidungen fehlen?

Musterantwort

Medieninhalt und verwendeter Kommunikationsdienst sind nicht dasselbe. Zu klären sind der tatsächlich genutzte Dienst, sein Profil, die Implementierung und die geprüfte Kombination. Ein erfolgreicher Datenstrom belegt weder MCVideo-Verfahren noch Sprachfunktionen oder das Verhalten bei Ausfällen. Der Nachweis muss zum jeweiligen Anwendungsfall passen.

Das nimmst du mit

MCX bildet eine Dienstefamilie. Gemeinsame Grundlagen verbinden die Dienste, ihre Abläufe und Erfolgsbedingungen bleiben verschieden.

Deine Talbahn-Fallakte

Ordne Sprache, Datenverbindung und kurze Nachricht einem Dienstmodell zu. Halte für jedes Modell fest, was «erfolgreich» aus Sicht der Anwendung bedeutet.