Lotos, die formale Spezifikationsmethode. deren zugrunde liegendes Systemmodell und verwendete Beschreibungselemente in der vorangegangenen Folge dieser Artikelserie erläutert wurden, wird in dieser Folge dazu benutzt. eine Spezifikation des Beispielprotokolls. wie in der ersten Folge dargestellt. zu erstellen.
Die Spezifikation des Beispiels in Lotos unterteilt sich in zwei Teile. Bild 1 zeigt die Deklaration der benötigten abstrakten Datentypen, während Bild 2 die eigentlichen Prozeßdefinitionen enthält.
Zunächst einige kurze Bemerkungen zu den Datentypen: Unser Beispiel soll aus Gründen der Vereinfachung keine Variablen und keine Operationen auf irgendwelchen Datentypen enthalten. Es sind lediglich einige Konstanten notwendig um die verschiedenen Ereignisse auf den Interaktionspunkten zu unterscheiden. Daher ist hier eine sehr einfache Typdeklaration möglich.
Als erstes wird aus einer Bibliothek der Datentyp boolean eingebracht, der die grundlegenden Booleschen Operationen enthalten soll. Danach werden die PDUs (Protocol Data Units) deklariert, die für das Beispiel benötigt werden. Jeder PDU-Typ ist als eine Konstante definiert. In der formalen Schreibweise der abstrakten Datentypen wird eine Konstante als Funktion ohne Parameter, die einen konstanten Wert liefert, angesehen. Diese Definitionen sind hinter dem Schlüsselwort opns angeführt. An dieser Stelle werden alle Operationen angegeben, die zu dem definierten Datentyp gehören.
Entsprechend sind im Typ serviceprimitives die relevanten Service-Primitive der zu spezifizierenden Ebene 3 (n_service) und der darunter liegenden Ebene 2 (1_service) des D-Kanal-Protokolls zusammengefaßt.
Bild 2 zeigt die Prozeßdefinitionen, die das Verhalten des D-Kanal-Protokolls in Lotos spezifizieren. Im folgenden sollen die Prozeßdefinitionen genauer erläutert werden. Wir gehen dabei sequentiell durch das Beispiel (Bild 2) und beschreiben die Semantik verbal. Die speziellen Operatoren von Lotos in Tabelle 1 (siehe CW Nr. 42/85, Seite 26) noch einmal wiederholt.
Der nach außen sichtbare Prozeß, das heißt das Gesamtverhalten, wird durch estab_n_conn definiert. Es erhält die Namen der Interaktionspunkte für Kommunikation mit dem Service User und dem Service Provider als formale Parameter übergeben. Im Sinne der schrittweisen Verfeinerung wird hier zunächst einmal festgelegt, daß der Verbindungsaufbau alternativ (angezeigt durch den Auswahl-Operator) aktiv (conn_act) oder passiv (con_pas) geschehen kann. Die beiden getrennten Prozeßdefinitionen folgen dann nach dem Schlüsselwort where.
Im weiteren werden als formale Namen für die Interaktionspunkte nur noch u für den Service User Interaktionspunkt und p für den Service Provider Interaktionspunkt angegeben. Das ist zulässig, da diese Namen ähnlich wie die formalen Parameter von Prozeduren bei herkömmlichen Programmiersprachen nur Bedeutung als Platzhalter haben und beliebig ersetzt werden können.
Nun wird der Prozeß des aktiven Verbindungsaufbaus definiert. Es wird eingeleitet durch einen Connect Request von seiten des Service users. Daraufhin sendet die Ebene 3 eine Setup PDU an die Vermittlungsstelle.
Abhängig von der Antwort (Empfang einer Setup_Ack PDU oder einer Call_Sent PDU) wird der Prozeß der Wählziffernübermittlung (Send_Info) eingeleitet oder auf die Reaktion des gerufenen Teilnehmers im Prozeß ringing gewartet.
Wenn noch Wählziffern übermittelt werden müssen, wird der Prozeß Send_Info aktiviert. Hier gibt es nun drei Möglichkeiten:
- Der Benutzer gibt eine Wählziffer ein (Info_sending_Req.) Dann reicht die Ebene 3 die Wählziffer in einer Info PDU weiter und der Prozeß Send_Info wird neu aktiviert, um die Übermittlung weiterer Wählziffern zu ermöglichen.
- Die Vermittlungsstelle erkennt die Vollständigkeit der Wählziffernfolge, schickt eine Cal_Sent PDU und aktiviert den Ruf beim gerufenen Teilnehmer. Unsere Ebene 3 erwartet in diesem Fall die Reaktion des gerufenen Teilnehmers in ringing,
- In dem Fall, daß die Vermittlungsstelle nicht erkennen kann, ob die Rufnummer komplett ist, bleibt die Call_Sent PDU aus, und die Reaktion des gerufenen Teilnehmers wird direkt weitergemeldet. Dieser Fall ist mit der dritten Alternative in Send_Info berücksichtigt.
Der Prozeß ringing reagiert auf die möglichen Reaktionen des gerufenen Teilnehmers (Alert oder Conn). Bei Alert zeigt die Vermittlungsstelle erst später das Akzeptieren der Verbindung durch conn an.
In jedem Fall ist mit Empfang der conn PDU der aktive Verbindungsaufbau beendet. Das wird mit exit angezeigt.
Der passive Verbindungsaufbau (das heißt wenn die Vermittlungsstelle ruft) ist einfacher zu spezifizieren, da in der hier benutzten ISDN Untermenge nur wenige unterschiedliche Möglichkeiten existieren.
Eingeleitet wird der passive Verbindungsaufbau immer durch Empfang einer Setup PDU von der Vermittlungsstelle. Dann kann unsere Ebene 3 in verschiedenen Weisen reagieren:
- Falls die Ebene 3 zu einem Gerät gehört, das nicht kompatibel zu dem angeforderten Dienst ist, reagiert sie überhaupt nicht und aktiviert den übergeordneten Prozeß estab_n-_conn erneut, um bereit für einen folgenden Verbindungsaufbauvorgang zu sein.
- Falls das Gerät zwar kompatibel, aber gerade besetzt ist, sendet die Ebene 3 eine Rel PDU, wartet auf den Empfang einer Rel_Ack PDU und aktiviert den übergeordneten Prozeß erneut.
- Falls das Gerät kompatibel und nicht belegt ist, wird dies der Vermittlungsstelle durch eine Alert PDU mitgeteilt.
Diese alternativen Möglichkeiten sind durch die Auswahl-Operatoren im Prozeß conn_pas dargestellt, wobei jede behaviour expression bedingt ausgeführt wird (Guarding-Operator).
Wenn der Teilnehmer (unser Benutzer) den Hörer abnimmt und damit Connect_Req signalisiert, senden wir eine Conn PDU auf die Vermittlungsstelle, die diese mit Conn_Ack quittiert. Dann ist die Verbindung erfolgreich aufgebaut, was durch exit angezeigt wird.
*Die Autoren, Klaus-Peter Fischer (Dipl.-Math.) und Stephan Hesse (Dipl.-Inform.), sind Software Entwickler speziell für Kommunikationssysteme sowie Berater auf diesem Gebiet bei der Telenet GmbH, Geschäftsstelle Rhein-Main.