USSD-Übersicht

Unstructured Supplementary Service Data (USSD) ist ein Kommunikationsprotokoll zur Kommunikation von GSM-Geräten (Global System for Mobile Communications) mit Mobilfunkanbietern (Mobile Operators, MO).

USSD lässt sich leichter durch einen Vergleich mit seinem verwandten Standard verstehen: Short Message Service (SMS). USSD und SMS sind beide GSM-Standards. Das bedeutet, dass sie als Features mit der zweiten Generation mobiler Geräte eingeführt wurden. Im Gegensatz zu SMS stellt USSD jedoch eine sitzungsbasierte Verbindung dar. SMS wird für kurze Nachrichten ohne Sitzung verwendet, USSD hingegen für die Steuerung und Kontrolle eines mobilen Geräts. Da eine Sitzung erforderlich ist, unterstützt USSD anders als SMS keine Speicher- und Weiterleitungsfunktionen. Sowohl USSD- als auch SMS-Nachrichten werden mit GSM-kompatiblen 7-Bit-Zeichen gesendet. Mit USSD sind jedoch 184 Zeichen möglich, bei SMS hingegen nur 160.

USSD-Nachrichten können mit einem Mobiltelefon gesendet werden, indem die Wählhilfe geöffnet und ein Code eingegeben wird. Nicht alle Codes werden von jedem Telefon oder MO unterstützt. In einigen Fällen kann die Telefonsoftware oder das Betriebssystem das manuelle Senden von Codes verhindern. Ein erforderlicher Code, der implementiert werden muss, ist *#06#. Dieser Code gibt den International Mobile Equipment Identifier (IMEI) des Modems zurück, aber einige Telefone lassen nicht zu, dass Sie ihn direkt wählen. Wenn Sie herkömmliche Methoden zum Ermitteln der IMEI-Nummer des Modems über die Einstellungen Ihres Telefons befolgen, wurde diese Nummer mit diesem Code abgerufen.

Wenn die Telefonhardware den Befehl eines Codes wie im IMEI-Beispiel direkt verarbeiten kann, wird keine Netzwerksitzung initiiert. Andere Codes, die eine Netzwerkkommunikation erfordern, öffnen eine Sitzung und senden dann eine Nachricht, die aus einem Befehl und ggf. erforderlichen Parametern besteht. Ein Beispiel hierfür ist ein Code, der Ihren aktuellen Saldo und den Tarifstatus beim MO überprüft.

USSD in Windows wird als WinRT-API-Oberfläche implementiert. Die Implementierungsklassen dieser Schnittstelle dienen als Zustandsautomat für USSD-Sitzungen, aber sie überlassen es letztendlich dem WWAN-Dienst, die Hauptlast zu übernehmen. Diese APIs werden mit einem Factorymuster implementiert.

Implementieren von USSD

Wichtig ist, dass die öffentlich zugängliche API durch die IDL definiert wird. Die Implementierung kann daher verwirrend sein, insbesondere, wenn Sie mit WinRT nicht vertraut sind. Diese Verwirrung mag teilweise von der scheinbar mehrdeutigen Verwendung des Wortes „Factory“ kommen. Eine Factory kann entweder auf eine Klassenimplementierung einer statischen Schnittstelle oder auf eine echte Factory verweisen, die eine aktivierbare Schnittstelle für eine Laufzeitklasse bereitstellt.

In diesem Thema werden WinRT-Konzepte besprochen und anschließend wird die Implementierung anhand dieser Konzepte beschrieben. In der IDL finden Sie jederzeit weitere Erläuterungen.

Schnittstellen

Schnittstellen definieren die Application Binary Interface (ABI). Sie beschreiben die Funktionen, die Sie für jede Klasse aufrufen können, mit der die Schnittstelle implementiert wird.

Laufzeitklassen

Dies sind die tatsächlichen Klassen. Sie stellen anhand des Namens dar, was letztendlich als Klassennamen für die ABI verfügbar gemacht wird. Jede Laufzeitklasse verfügt möglicherweise über null oder mehr Schnittstellen (muss jedoch mindestens eine Standardschnittstelle deklarieren, wenn sie eine oder mehrere Schnittstellen enthält), null oder mehr statische Schnittstellen und ggf. ein aktivierbares Tag. Jede dieser Schnittstellen wird in verschiedenen Dateien als unterschiedliche „Impl“-Klassen implementiert, aber sie scheinen eine einzelne, einheitliche Klasse für die ABI zu sein.

Eine typische Schnittstelle in Form von Instanzmethoden für ein vorhandenes Objekt angezeigt.

Eine statische Schnittstelle wird dem Client in Form von statische Methoden für die Laufzeitklasse selbst dargestellt.

Ein aktivierbares Tag definiert die Factoryschnittstelle, die eine Instanz einer Laufzeitklasse erzeugt. Dies ist für den Client vollständig verschleiert und wird als Konstruktor für diese Laufzeitklasse angezeigt.

USSD-Implementierung

Ablauf: Öffnen, Senden, Empfangen, Schließen.

Öffnen, Senden

1. Der Client verwendet eine der statischen Funktionen „UssdSession.CreateFromNetworkAccountId“ oder „UssdSession.CreateFromNetworkInterfaceId“, um das UssdSession-Objekt zu erstellen.

2. Unabhängig von der aufgerufenen API ist eine Netzwerkschnittstellen-ID erforderlich, um eine UssdSession zu initialisieren. Im Fall von *NetworkAccountID werden Schritte zum Abrufen der Netzwerkschnittstellen-ID aus der Konto-ID ausgeführt. CreateInternal() wird aufgerufen, um eine Instanz von UssdSession zu erstellen und Initialize() für die neu erstellte Instanz aufzurufen. Während der Initialisierungsschritte wird ein Arbeitsthread ausgelöst, und ein Ereignishandle zum Auslösen von Ereignissen für den Thread wird erstellt. Die Schritte 3 und 4 finden auch während des Initialize() der Instanz statt.

3. Initialize() wird für das WwanWrapper-Memberobjekt aufgerufen. Diese Funktion akzeptiert eine statische Rückruffunktion sowie einen Kontext, damit die statische Funktion den Rückruf einem Objektkontext zuordnen kann.

4. WwanWrapper öffnet ein Handle für WwanService, listet Schnittstellen auf und abonniert USSD-Benachrichtigungen, indem ein statischer Rückruffunktionszeiger und „dies“ als Kontext bereitgestellt wird.

5. Das UssdSession-Objekt wird an den Client zurückgegeben.

6. Der Client erstellt eine neue UssdMessage, indem er den Konstruktor mit einer Nachrichtenzeichenfolge aufruft. WinRT verschleiert die UssdMessageFactory in diesem Prozess.

7. Der Client ruft SendMessageAndGetReplyAsync für das Sitzungsobjekt auf und übergibt die UssdMessage-Instanz.

8. Zu diesem Zeitpunkt erstellt SendMessageAndGetReplyAsync ein spezielles Vorgangsobjekt namens UssdSendMessageAndGetReplyOperation. Der Name erweckt den Eindruck, dass das Objekt die Logik einer einzelnen Nachricht kapselt, die vom Stapel gesendet wird (und auf Antwort wartet), aber dies ist nicht der Fall. WinRT erfordert einen speziellen Ausgabeparameter für asynchrone Vorgänge, den wir als 2. Parameter in der Definition für diese Funktion sehen.

   HRESULT SendMessageAndGetReplyAsync(
               [in] UssdMessage* message,
               [out, retval] Windows.Foundation.IAsyncOperation<UssdReply>** asyncInfo);
   

   Es ist die IUssdSendMessageAndGetReplyOperation, eine benannte Schnittstelle über typedef, die diesen Parameter erfüllt, indem sie verspricht, dass dieser Vorgang zwangsläufig eine UssdReply zurückgibt. Diese Schnittstelle ist nicht in der IDL definiert, sondern wird von der UssdSendMessageAndGetReplyOperationImpl-Klasse implementiert. Beachten Sie, dass der Header für diese Klasse eine spezielle Erweiterung hat:

   class UssdSendMessageAndGetReplyOperationImpl :
       public Microsoft::WRL::RuntimeClass<
           Windows::Networking::NetworkOperators::IUssdSendMessageAndGetReplyOperation,
           Windows::Internal::AsyncBaseFTM<IUssdSendMessageAndGetReplyCompletedHandler, Microsoft::WRL::SingleResult>>
   

   Mit dem UssdSendMessageAndGetReplyOperation-Objekt kann WinRT die Komplexität dieses asynchronen Vorgangs und die damit verbundenen Kompartimentierungs- und Speicherproxys verschleiern. Weitere Informationen finden Sie unter SendMessageAndGetReplyAsync.

   Zunächst sollten Sie verstehen, dass mit dem oben beschriebenen asynchronen Vorgang einfach ein Rückruf in das UssdSession-Objekt erfolgt, welches die Logik für diesen Vorgang tatsächlich enthält. Wir können uns der Einfachheit halber vorstellen, dass die Arbeit hier direkt von UssdSession gekapselt wird. Wir können nun feststellen, dass trotz der asynchronen Natur nur eine UssdMessage gleichzeitig gesendet werden kann.

   Funktionsweise der SendMessageAndGetReplyAsync-Funktion:

   • Das UssdSession-Objekt wechselt in den Status „Ausgelastet“, speichert den Inhalt der UssdMessage und löst die asynchrone Aktion aus.
   • OnOperationStart() ist der Einstiegspunkt für die asynchrone Logik. Gehen Sie bei diesem Szenario davon aus, dass keine aktive Sitzung vorhanden ist. Diese Funktion erstellt ein WWAN_USSD_REQUEST-Objekt mit RequestType=WwanUssdRequestInitiate.
   • Die Schritte 9 und 10 werden als Aktionen dieser Funktion ausgeführt.

9. m_wwanWrapper.SendRequest wird aufgerufen, um die Übergabe der Nachricht an WwanService zu verarbeiten.

10. WwanWrapper verwendet das WwanService-Handle, um WwanService-APIs zum Ausführen der Aktion aufzurufen.

Receive

Nach Schritt 10 befinden wir uns in einem Zustand, in dem eine Anforderung an WwanService gesendet wurde, um eine neue USSD-Sitzung zu initialisieren und eine USSD-Nachricht unter dieser Sitzung zu senden. Nach einiger Zeit ist die Antwort verfügbar.

11. WwanService ruft die in Schritt 4 bereitgestellte statische Rückruffunktion mit dem ebenfalls angefügten Kontext auf.
12. Der Kontext wird verwendet, um die WwanWrapper-Instanz abzurufen und NotificationCallback() aufzurufen.
13. WwanWrapper folgt demselben Muster wie Schritt 11 und ruft einen statischen Rückruf für UssdSession auf, der den in Schritt 3 gespeicherten Kontext bereitstellt.
14. Ähnlich wie in Schritt 12 wird mit dem Kontext der Rückruf für eine Instanz von UssdSession aufgerufen.
15. Die UssdSession speichert die WWAN_USSD_EVENT (unter einer Sperre) und benachrichtigt den Workerthread, sodass er das Ereignis behandelt.
16. HandleOperationReply() übernimmt das vorhandene UssdSendMessageAndGetReplyOperationImpl-Objekt und übergibt die Ereignisdaten an den internen Handler.
17. Der Vorgang erstellt und UssdReply und ruft FireCompletion() auf, um die asynchrone Aktion als abgeschlossen zu markieren.
18. WinRT verschleiert den Abschluss der asynchronen Aktion an den Client. (Entweder wurde auf die Aktion gewartet oder gibt eine Rückruflogik.)

In derselben Sitzung können weitere Nachrichten gesendet werden. Wenn die Sitzung beibehalten wurde, lautet der zukünftige RequestType WwanUssdRequestContinue.

Schließen

Nach Schritt 18 hat der Client die Antwort auf seine UssdMessage erhalten. Er kann die aktive UssdSession weiterhin verwenden, um zusätzliche Nachrichten zu senden. Wir gehen davon aus, dass der Client zu einem späteren Zeitpunkt Close() manuell auf der UssdSession aufruft. Wenn der Client Close() nicht explizit aufruft, wird er während des Destruktors von UssdSession aufgerufen.

19. Der Client ruft Close() für die UssdSession-Instanz auf.
20. Eine WWAN_USSD_REQUEST wird mit RequestType=WwanUssdRequestCancel erstellt.
21. Die Anforderung wird wie in Schritt 9 an m_wwanWrapper gesendet.
22. Die Anforderung wird wie in Schritt 10 an WwanService gesendet.

Das Ergebnis dieser Anforderung ist unwichtig. Die Sitzung wird in jeder Hinsicht geschlossen. Selbst in einem Extremfall, in dem die Nachricht irgendwie nie übermittelt wird, überschreibt eine neue USSD-Sitzung immer eine vorhandene Sitzung.

Hardware Lab Kit (HLK)-Tests

Siehe Schritte zum Installieren von HLK.

Stellen Sie in HLK Studio eine Verbindung mit dem Mobilfunkmodemtreiber des Geräts her, und führen Sie den Test aus: Win6_4.MB.GSM.Data.TestUssd.

MB USSD: Handbuch zur Problembehandlung

• Sammeln und decodieren Sie die Protokolle mithilfe der Anweisungen unter Sammeln von Protokollen für mobiles Breitband.

• Schlüsselwörter zum Filtern

  1. OID_WWAN_USSD
  2. NDIS_STATUS_WWAN_USSD
  3. WWAN_USSD_REQUEST
  4. WWAN_USSD_EVENT

Weitere Informationen

MB-USSD-Vorgänge