USSD - Unstructured Supplementary Service Data

USSD steht für Unstructured Supplementary Service Data. Es ist ein GSM-Protokoll, das ähnlich wie SMS zum Austausch von Informationen bzw. Nachrichten zwischen Handy und Netz dient. USSD-Kommandos werden über den FACCH (Fast Associated Control Channel) übertragen, der ca. 5x schneller als der für SMS verwendete SACCH (Slow Associated Control Channel) ist.

Bekannteste Beispiele sind die Rufumleitungen. Z.B. **61*Nummer*11*10#[send] wobei 61 für "Rufweiterleitung falls keine Antwort" steht, 11 für Sprachanrufe und 10 für die Verzögerung in Sekunden. Die gebräuchlichsten Kommandos dieser Art stellt der Handy-Hersteller im Menü des mobilen Telefons wesentlich verständlicher zur Verfügung, denn diese Folgen von Zahlen und Zeichen sind nicht so leicht zu merken.

Bei der UltraCard von Vodafone macht man mit *133#[send] die aktuelle Karte zur Haupt-Karte, die SMS und MMS empfangen soll. Mit *132#[send] überprüft man den Status der Karte, die im Handy steckt.
Bei T-Mobile lauten die entsprechenden Codes für die MultiSIM *222#[send] und *221#[send].
so aktiviert man die UltraCard

Eine weitere, heute aber nicht mehr benötigte Anwendung war, dass die Netzbetreiber per USSD auch das Telefonieren mit Prepaid-Karten im Ausland ermöglichten, wenn die direkte Wahl noch nicht möglich war. Dazu wurde über die Zeichenfolge veranlasst, dass von Deutschland aus eine Verbindung aufgebaut wird, die sofort berechnet werden kann. Telefon-Verbindungen aus dem Ausland wurden nämlich oft erst Wochen später an den deutschen Netzbetreiber gemeldet, und das könnten Besitzer von Prepaid-Karten ausnutzen …

USSD heißt nicht automatisch, dass eine Kommunikation über Funk erfolgt:
Mit *#0000# kann man schnell die Firmware-Version eines Handys abfragen.
Mit *#06# erfährt man die IMEI (die Gerätenummer) des Telefons auf dem man dieses Kommando eingibt.

Hier die Listen der deutschen Netzbetreiber, welche USSD-Codes in ihren Netzen unterstützt werden:
Telekom, Vodafone (Infofax 374) und O2.

Wer als Netzbetreiber überlegt, USSD-Anwendungen zu offerieren, sollte sich mit den Möglichkeiten eines USSD Browsers vertraut machen. Ein Anbieter war z.B. Sicap. Weitere Anbieter von USSD-Plattformen sind z.B. Jinny, Nokia und Syniverse.

Hier ein ausführliches Interview mit einem Nokia-Produkt-Manager, in dem eine Reihe von Einsatzmöglichkeiten von USSD vorgestellt werden. Es stammt aus 1999, ist aber fast unverändert relevant.
 

(Quelle / Source: GSMail Special Report December 10, 1999)

### GSMag Special Report ###

### Squaring the Circle in VAS. USSD Permits Innovative Approaches ###

Germany (gsmag) - When in autumn 1999, Swiss carrier Swisscom introduced the first genuine prepaid roaming - without the involvement of third party transaction systems or the necessity for user identification - the possibility to offer such a system took by surprise even many inside observers. At the heart of this and other potential value added services lies "Unstructured Supplementary Service Data", USSD in short. USSD combines the advantages of CSD with many of the strengths which made SMS a success. GSMag has spoken about USSD to Thomas Purkop, Product Manager at Nokia Networks Communications in Düsseldorf (Germany) (meanwhile changed the employer).

### SIGNALLING CHANNELS, TRAFFIC CHANNELS, AND MMI CODES ###

Much like is the case with ISDN, in simplified terms, GSM uses two types of channels for call management and -completion: Signalling channels and traffic channels.

While the latter type of channels carries volume data such as voice or circuit switched data calls (CSD), control channels carry meta-information about calls, the short message service (SMS), and can be used for signalling purposes, such as sending user initiated control information. While mostly network services (such as call forwarding or call barring) are requested by initiating actions from modern day GSM terminals' menu structure, at its core lie the so called MMI (or Man Machine Interface) codes. As an example, to forward all incoming voice calls to another number in case of no reply within 10 seconds, a user could key in the following MMI code:

**61*<target_number>*11*10#[SEND]

where

61 = action "call forward if no answer"
(target number to be entered without the angle brackets)
11 = voice calls
10 = delay in seconds

If and when initiated by the user pressing the [SEND] button of his mobile terminal, the signalling channel will be used to trigger the required action and inform the user about the result of his request.

While part of the name space for 2-digit "action" codes were reserved within ETSI's original standard GSM specifications, "action" codes beginning with digit "1" were left open for individual carriers' use (as apparently is the case with MMI codes initiating with digit "7").

### ENTER USSD ###

In principle, mobile originated USSD makes use of the same MMI mechanism while significantly extending the possibilities for a flexible use of the GSM control channel for value added services (VAS). In addition, USSD phase 2 also provides mechanisms for terminal destined data communications allowing dialogue structures. Unlike SMS however, USSD's speciality is its session oriented paradigm.

A typical user initiated request will be any one to three digit combination of "*" and "#", followed by a 1n[n] "action" code. The two terminating digits contain information about routing (to HLR or VLR?) and handling (which action shall be triggered at the application side?) of the information contained in a number string that follows the "action" MMI code. The "payload" portion of an initiating message consists of "*" and up to 182 7 bit (numerical) characters, terminated by "#" and [SEND].

Basically any user initiated USSD request can be processed and routed to a USSD handler at MSC, VLR or HLR levels. USSD handlers usually consist of special gateway platforms, similar to the known short message service centres for SMS applications. As an example, Nokia offer a USSD centre which comes integrated with their family of Artus messaging platforms and can be accessed by third party applications supporting a superset of the CIMD2 protocol.

While, according to ETSI-specs, USSD message handlers can be positioned at any hierarchy level, Nokia currently supports platforms at HLR-level.

In many aspects similar to the way in which an SMS message would be processed by a third party application, USSD requests can be forwarded and processed by such apps.

### ASK WHAT USSD CAN DO FOR YOUR COMPANY ###

"USSD as a bearer for value added services has been overshadowed for a while now by other technologies like WAP, and it is difficult to bring home the system's benefits with carriers" says N.N., product manager for USSD at Nokia Networks Communication in Düsseldorf (Germany): "USSD can help to enable session oriented and text based data communications. Unlike SMS, which transmits short text messages in batch mode, USSD enables dialog sequences between users and applications."

USSD based services could fill a gap that, prior to a significant market entry of GPRS services and the availability of both terminals and infrastructure for the packet switched data service, cannot be filled either by CSD or SMS (cf. Fig. 1).
 
Feature SMS USSD CSD
Physical bearer channel in the network Control Control Control
Approximate throughput 160 bps 400 bps 9600 bps
Session oriented (dialogue possible) No Yes Yes
Paging user for each message Mostly Yes No No
Store and forward possible? Yes No No
Can applications recognise MSISDN? Yes Yes No
Is it possible to transfer data active call Yes Yes No
Possibility to use network initiated services? Yes Yes No
Roaming possible? Yes Yes Yes
Direct person to person messaging Yes No No

Fig. 1: Properties of USSD, SMS, and CSD compared

Beyond the user initiating dialogues with an application by sending an MMI-code, and much like SMS, USSD (phase 2) can also be used to send information to a user's terminal, either to ask for (an alphanumerical) user reply or to initiate a dialogue between the user and an application.

What the grey technical facts may not reveal at first sight are the possibilities for a creative combination of USSD's strengths:

### POSSIBLE APPLICATIONS ###

Swisscom of Switzerland currently uses USSD as a means of enabling real prepaid roaming: The user sends an MMI string to Swisscom's messaging centre at HLR, containing the USSD "action" code plus the called party's telephone number from any GSM network (home or visited). As a result, a few seconds later the user gets a callback with a ring tone of the called number initiated by Swisscom.

Other applications which have been created with USSD are SIM-toolkit downloads from the network and billing applications (SmarTone in Hong Kong).

"Chat servers, location based info systems and call management applications are other examples where USSD can be used to create added value" says Purkop. A typical USSD dialogue structure either enables the user to initiate a session by sending an MMI code (preferably from SIM card memory), or "OK" information received from the network, receive a menu structure which can be scrolled and allows selections, or enter alphanumerical information to be sent back to an application at its request, much like the well known FORMS in html. "A combination of USSD with, say, SMS also enables other popular services". Explains Purkop: "For example, you may wish to allow your user to download ring tones via SMS, enabling a preselection via a USSD menu dialogue."

### SO, WHERE IS THE CATCH? ###

Since USSD uses the SDCCH control channel, it does draw on the resources of a network's switching structure. However "in the Nokia implementation there are safety margins how much USSD can take up the NSS resources to protect against resource problems", explains Nokia product management.

Billing for USSD services itself however may remain a problem, as it appears that little thought has been given to the topic of non-carrier-originated (third party) services or information.

As is the case with SMS and other data VAS, at least Nokia's product line comes without inbuilt billing interfaces for third parties. This in turn might prove to be a stumbling block for USSD, as has been the case with SMS and likely will be the case for WAP in absence of innovative pricing models for the time being. Carriers themselves have often shown a lack of imagination and flexibility in the past to implement VAS applications which succeed in the market place.

+++ End of GSMail Special Report December 10, 1999 +++

zur Startseite von dafu.de | Impressum | Datenschutz-Erklärung (DSGVO)