DE3903257C2 - - Google Patents

Description

Die Erfindung betrifft ein Kommunikationssystem bei Telefonvermittlungsanlagen nach dem Oberbegriff des Anspruchs 1. Ein derartiges Kommunikationsverfahren ist aus der CCITT-Empfehlung Fascicle VIII.7 - Rec X.410, insbesondere aus der dortigen Fig. 4 und Seite 97 ff. bekannt.

Damit es einer externen Steuervorrichtung möglich ist, mit einer Telefonvermittlungsanlage zu kommunizieren, wurden bereits eine Reihe von Kommunikationsproto­ kollen entwickelt. Nach diesen Protokollen ist es mög­ lich, daß eine externe Steuervorrichtung, beispiels­ weise ein Hauptrechner von der Telefonvermittlungsanlage Informationen erhält, die sich beispielsweise auf den Zustand von Anschlußschaltungen für externe und interne Leitungen beziehen, um die Datenbasis der Tele­ fonvermittlungsanlage analysieren zu können und um eine externe Steuerung der Anlage zu ermöglichen.

Ein solches bekanntes Protokoll ist beispielsweise das ACD System der Technotron Infoswitch Corporation, welches eine Befehlssprache verwendet, die eine externe Steuerung einer Telefonvermittlungsanlage durch einen entfernt stehenden Hauptrechner ermöglicht.

Ein anderes durch IBM entwickeltes Protokoll trägt den Namen Netview PC, dient als Bestandsführungsprogramm und kann als Terminalschnittstelle bei einer Ver­ mittlungsanlage verwendet werden.

Beide Protokolle weisen den Nachteil auf, daß sie nicht konform sind zu den eingeführten Standards zur Erleichterung des internationalen Nachrichtenaustauschs wie sie von der CCITT definiert sind und als Open Systems Interconnect gezeichnet werden.

Die OSI Empfehlungen definieren standardisierte Datenübermittlungsprotokolle, die von den bedeutenden Herstellern von Kommunikationssytemen im internationalen Maßstab übernommen werden sollen, damit die in den verschiedenen Ländern durch unterschiedliche Hersteller hergestellten Systeme miteinander entsprechend den standardisierten Protokollen kommunizieren können.

Beispielsweise definiert die CCITT Empfehlung X.410 ein Remote Operations Services ROS zur Ausführung einer ferngesteuerten Rufverbindung, die dazu dient, interaktive Anwenderschichtprotokolle zu strukturieren. Die X.410 Empfehlung legt sogenannte Operation Protocol Data Units OPDU fest, welche zwischen den Anwenderschichteinrichtungen ausgetauscht werden, um eine Operation anzufordern und über deren Ergebnis zu berichten.

Dabei existieren drei prinzipiell verschiedene Typen von OPDU′s, die Anforderungs- OPDU, die Ergebnis-OPDU und die Fehler-OPDU. Die Anforderungs-OPDU wird von einer anfordernden Anwenderstelle abgesendet, wenn diese die Unterstützung einer ausführenden Anwenderstelle wünscht. Sie besteht aus der Anforderungs­ identifizierung, dem Befehl für die gewünschte Operation und einem Argument hierzu. Die Ergebnis-OPDU wird, nach erfolgreicher Erledigung des Auftrages, von der ausführenden Anwenderstelle an die anfordernde Anwenderstelle zurückgesen­ det. Sie besteht aus der Anforderungsidentifierung und dem Ergebnis der Opera­ tion. Die Fehler-OPDU wird bei nichterfolgreicher Erledigung des Auftrages von der ausführenden Anwenderstelle an die anfordernde Anwenderstelle zurückgesendet. Sie besteht aus der Anforderungsidentifizierung, der Fehleridentifizierung und einem dazugehörenden Fehlerparameter. Sämtliche OPDU-Operationen sind speicher­ lose, unabhängige Prozeduren. Nach Eintreffen der Anforderungs-OPDU bei der ausführenden Anwenderstelle wird unmittelbar die Ergebnis-(oder Fehler-)OPDU kodiert und zurückgesendet. Damit ist die Transaktion abgeschlossen.

Die X.410 Empfehlung definiert den vorerwähnten Remote Operations Service ROS, der an der Spitze eines Reliable Transfer Server RTS verläuft, durch den eine Information entweder auf monologe Weise oder in dialoger Weise übermittelt wird. Im Fall der dialogen Arbeitsweise wird die Übermittlung der Dateneinheiten bestimmt durch eine Umkehr, die zwischen den Endpunkten (beispielsweise Anwendereinrichtungen) innerhalb der Kommunikationssysteme übermittelt wird. Das RTS paßt jedoch nicht gut zu der Ausführung von ferngesteuerten Operationen bei Telefonanlagen. Die Vorgänge in Telefonanlagen verlaufen asynchron und müssen verarbeitet werden, wenn sie auftreten, d. h., der Zeitfaktor ist hierbei von erster Bedeutung. Die RTS Session, wie sie durch die Norm X.410 ROS definiert ist, ist jedoch nicht in der Lage, eine Anforderung oder ein Ergebnis zu jedem gegebenen Zeitpunkt zu akzeptieren. Vielmehr kann eine Anforderung oder deren Resultat beim RTOS nur akzeptiert werden, wenn damit eine Umkehr übermittelt wird.

Bei Telefonanlagen können zudem verschiedene Operationen eine Resourcen-Zuteilung in einer angesteuerten Anwenderstelle bewirken. Unter Resourcen sind Teile der Vermittlungsanlage, die dort angeschlossenen Leitungen, Apparate und sonstige Bauteile zu verstehen. Eine Resourcenzuteilung bei einer Telefonanlage ist beispielsweise erforderlich, wenn der Hauptrechner einen Überwachungsbefehl erzeugt und damit eine Überwachung eines bestimmten Telefonapparates anfordert, was der Telefonvermittlungsanlage übermittelt wird, die daraufhin dem Hauptrechner Rufinformationen bezüglich dieses Telefonapparates übermittelt und wobei gleichzeitig bewirkt wird, daß die Telefonvermittlungsanlage sich daran erinnert, daß diese Überwachung vom Rechner angefordert wurde. Die Tatsache, daß die Telefonanlage sich daran erinnern muß, einen bestimmten Telefonapparat kontinuierlich zu überwachen, ist ein Beispiel einer Situation, wo die Ausführung der Operation über den Zeitpunkt hinweg ausgeführt wird, wo über das erste Ergebnis der Operation dem Rechner berichtet wird. Um für Fernsteuerungsaufgaben ein standardisiertes Anwendungsschichtprotokoll verwenden zu können, ist es also notwendig, daß die nachfolgenden Ausführungen einer angeforderten Operation zur ursprünglich angeforderten Operation zugeordnet sind.

Die ferngesteuerten Operationen nach X.410 Empfehlung bestehen in der Anforderung der Operation und der Rückmeldung eines Resultats. Nach der X.410 Empfehlung wird eine solche Transaktion fortgeführt, bis sie entweder vom Hauptrechner oder von der Telefonvermittlungsanlage unterbrochen wird. Die Anforderungsidentifizierung ID der X.410 Empfehlung reicht nicht aus, um einen Transaktions-Identifikationscode für die ferngesteuerte Operation zu übermitteln, der für eine Resourcenzuteilung erforderlich ist, da die Anforderungsdateneinheiten OPDU nur in der Lage sind, eine einzige, ursprüngliche Operation zu definieren.

Es besteht die Aufgabe, das Kommunikationssystem so auszubilden, daß es sich für die Anwendung bei Telefonanlagen eignet, indem jede beteiligte Anwender­ stelle die Adresse der jeweils anderen kennt und auf eine Anforderung beliebig viele Antwortdatensätze zu beliebiger Zeit folgen, welche alle der anfordernden Anwenderstelle übermittelt werden.

Gelöst wird diese Aufgabe mit den kennzeichnenden Merkmalen des Anspruches 1. Vorteilhafte Ausgestaltungen sind den Unteransprüchen entnehmbar.

Gemäß der vorliegenden Erfindung werden vom Hauptrechner und von der Vermittlungsanlage Anforderungsadressenfelder und Server Adressenfelder erzeugt und codiert, welche in allen Anforderungs- und Ergebnisdateneinheiten OPDU enthalten sind. Falls beispielsweise der Hauptrechner wünscht, eine ferngesteuerte Operation, die eine Resourcenstelle betrifft, anzufordern, dann erzeugt und codiert die Anwenderstelle innerhalb des Hauptrechners eine OPDU-Anforderung, die ein Anforderungsadressenfeld enthält, welches zur Identifizierung der anfordernden Anwenderstelle dient. Das Server Adressenfeld dagegen wird mit einer 0 belegt, da der Hauptrechner nicht weiß, welche Anwenderstelle in der Vermittlungsanlage die vom Rechner gewünschte Operation ausführt.

Nach Empfang der OPDU-Anforderung durch die Vermittlungsanlage bestimmt diese eine ihrer Anwenderstellen, die die Operation auszuführen hat und eine Server Adresse wird durch die ausführende Anwenderstelle zugeordnet und als OPDU-Ergebnis der anfordernden Adresse übermittelt. Nach diesem Adressenaustausch weiß jede Anwenderstelle die Adresse der jeweils anderen. Alle nachfolgenden Rufzustandsinformationen der Vermittlungsanlage, die eine zu überwachende Vorrichtung betreffen, können dann von der Anwenderstelle der Vermittlungsanlage der durch die Anforderungsadresse definierten Anwenderstelle des Hauptrechners zugeführt werden. Dies ermöglicht dem Hauptrechner, die übermittelten Rufzustandsnachrichten der ursprünglichen Operationsanforderung zuzuordnen.

Gemäß der vorliegenden Erfindung werden also OPDU-Operationsdatensignale erzeugt, welche der anfordernden Anwenderstelle zugeordnet sind. Des weiteren werden OPDU-Operationsdatensignale erzeugt, die der Anwenderstelle zugeordnet sind, die die angeforderte Operation auszuführen hat.

Die Erfindung wird nachfolgend an Hand der Zeichnung und der Anhänge näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm des Kommunikationssystems und;

Fig. 2 ein Blockdiagramm des Leitungsschichtformats gemäß einem bevorzugten Ausführungsbeispiel.

Figurenbeschreibung

Die Fig. 1 zeigt ein allgemeines Blockschaltbild eines Kommunikationssystems, bestehend aus einem Hauptrechner 1 und einer Telefonvermittlungsanlage 3.

In der Praxis weisen der Hauptrechner 1 und die Telefonvermittlungsanlage 3 zusätzliche Elemente auf, wie beispielsweise Terminals, Speicher, Periphereinheiten usw. Der Hauptrechner 1 und die Telefonvermittlungsanlage 3 sind miteinander verbunden über eine standardisierte RS-232 Leitung, die an RS-232 Senderempfänger 5 und 7 im Hauptrechner 1 und in der Telefonvermittlungsanlage 3 angeschlossen ist. Bei dem Hauptrechner 1 handelt es sich beispielsweise um den Rechner VAX/VMS der Digital Equipment Corporation und bei der Telefonvermittlungsanlage um eine Anlage SX 2000 der Anmelderin. Die RS-232 Sender-Empfänger bilden die physikalische OSI Kommunikationsschicht. Die RS-232 Leitung 9 überträgt synchrone Datensignale von 1,2 Kilobits bis zu 64 Kilobits pro Sekunde.

Die RS-232 Sender-Empfänger 5 und 7 sind an entsprechenden Leitungsschichtsteuerschaltern angeschlossen, wie beispielsweise an HDLC Steuerschaltungen 11 und 13 zur Ausführung eines OSI Leitungsschichtprotokolls (beispielsweise LAPB, wie in der CCITT Empfehlung X.25 von 1984 definiert).

Mit den HDLC Steuerschaltungen 11 und 13 sind Hauptsteuerschaltungen 15 und 17 verbunden zur Ausführung der Transport/Sitzungs/Präsentationsschicht des standardisierten OSI Kommunikationsprotokolls.

Die Telefonvermittlungsanlage 3 weist weiterhin eine Schaltzentrale 19 auf, die beispielsweise aus einer digitalisierten Schaltmatrix besteht, an welche eine Vielzahl von Amts- und internen Leitungsschaltungen sowie andere Periphereinheiten angeschlossen sind. Auf der Zeichnung sind beispielsweise dargestellt Nebenstellenapparate 21, 23, 25, die an die Schaltzentrale 19 angeschlossen sind, über welche die Verbindung unter der Steuerung der Hauptsteuerschaltung 17 hergestellt wird.

In entsprechender Weise können mehrere Periphereinheiten, wie beispielsweise Datenterminals, LANs usw. an den Hauptrechner 1 oder die Telefonvermittlungsanlage 3 angeschlossen sein.

Um eine Fernoperation einer Anwenderschicht zu veranlassen, codiert eine der Hauptsteuerschaltungen, beispielsweise die Hauptsteuerschaltung 15 des Hauptrechners 1, eine Anwenderschichtnachricht, die einer bestimmten Anwenderstelle zugeordnet ist und welche zum Empfang einer weiteren Anwendungsstelle übermittelt wird, beispielsweise der Hauptsteuerschaltung 17 der Telefonvermittlungsanlage 3 zur Ausführung der angeforderten Anwenderschichtoperation.

Wird beispielsweise gewünscht, daß der Hauptrechner 1 den Zustand eines bestimmten Telefonapparats der Telefonvermittlungsanlage überwacht, beispielsweise des Apparates 21, dann wird folgende Ereignisfolge ausgeführt:

Als erstes fordert der Hauptrechner 1 eine TRANSLATE-Prozedur an, um eine logische Geräteidentifikation LID (Logical Equipment Identifier) und andere den Telefonapparat 21 betreffende Informationen zu erhalten. Eine logische Geräteidentifikation ist ein von der Telefonanlage gelieferter Wert, der sich auf eine Resource der Telefonanlage bezieht, wie beispielsweise auf einen Telefonapparat, eine externe oder eine interne Leitungsschaltung usw. Die Resourcen können aus einer bestimmten Vorrichtung wie im Falle eines Telefonapparates bestehen, können jedoch auch eine logische Konstruktion betreffen, wie beispielsweise ein Freisuchen. Die TRANSLATE Operation wird durchgeführt, damit der Hauptrechner eine externe Adresse zu einer LID auflösen kann und irgendein Synonym für diese Adresse erhält. Die TRANSLATE Prozedur übermittelt auch Informationen zurück, welche die Art der Resource der Telefonvermittlungsanlage beschreiben.

Der Anhang A verdeutlicht die Folge der hexadezimalen Signale, welche die Anforderung der Fernoperation der Anwendungsschicht charakterisiert, wie sie von der Hauptsteuerschaltung 15 des Hauptrechners erzeugt wird.

Die im Anhang A gezeigte Tabelle, als auch die Tabellen nach Anhang B bis J stellen Beispiele für Anforderungen bei einer Fernoperation gemäß der vorliegenden Erfindung dar. Hierbei ist anzumerken, daß die Struktur und der Inhalt der OPDU und ihrer hexadezimalen Repräsentationen mit der Protokollentwicklung variieren können.

Wie der Anhang A zeigt, ist die Fernoperationsanforderung OPDU aufgebaut in Übereinstimmung mit der OSI Empfehlung X.410 und umfaßt eine Folge, bestehend aus einer Anforderung ID (Invoke ID), einer Operation und einem Parameter (Argument). Zusätzlich zu dem Standardprotokoll X.410 ist innerhalb der Argumentfolge ein Anforderungsadressenfeld und ein Server Adressenfeld definiert. Gemäß dem gezeigten Beispiel wird eine Anforderungsadresse (Invoke Adress) von 50 (Dezimal) durch die Anwenderschicht Software innerhalb der Hauptsteuerschaltung 15 erzeugt zur Bestimmung der Adresse der Anwenderstelle (Application Entitiy) innerhalb des Hauptrechners 1, die die TRANSLATE Prozedur anfordert.

Das Server Adressenfeld ist Null, wodurch angezeigt wird, daß die TRANSLATE Operation in Übereinstimmung mit dem Standardprotokoll X.410 eine unabhängige Transaktion ist. Da der Hauptrechner 1 nicht weiß, welche Anwenderstelle der Telefonvermittlungsanlage 3 die TRANSLATE Anforderung bedient, ordnet also die Hauptsteuerschaltung 15 der Server Adresse eine Null zu. Wie nachfolgend noch beschrieben wird, erzeugt die Telefonvermittlungsanlage 3 eine Server Adresse, die dazu dient, die Anwenderstelle in der Telefonvermittlungsanlage zu definieren, die die TRANSLATE Prozedur ausführt und diese Adresse dem Hauptrechner 1 innerhalb der Ergebnis-OPDU für die TRANSLATE Prozedur übermittelt.

Eine Anzahl von Eingangswerten kann für die TRANSLATE Prozedur spezifiziert werden, wie Directory Number DN, PBX Resource Name, Physikalische Ortsidentifikation PLID, (Physical Location Identifier), Leitungsnummer, (Trunk Number) und logische Geräte ID (Logical Equipment Instance). Im Beispiel nach Anhang A ist lediglich die Directory Nummer, beispielsweise DN=1201 spezifiziert. Die Directory Nummer identifiziert die spezielle Resource in der Telefonvermittlungsanlage, d. h., im behandelten Beispiel wird der Telefonapparat 21 mit der Directory Nummer 1201 identifiziert.

Im obigen Beispiel fehlt die Intersect Translation-Qualifikation (Intersect Trans) der OPDU Anfrage für die TRANSLATE Prozedur. Der Intersect Trans Qualifier wird durch die anfordernde Anwenderstelle dazu verwendet, den anfänglichen TRANSLATE Eingang mit einem zweiten Eingang zu qualifizieren, der den rückkehrenden Wert im OPDU Ergebnis bewirkt, um die Kreuzungsstelle der beiden Eingänge zu erhalten. Wird beispielsweise die TRANSLATE Operation angefordert für eine spezielle Leitung eines an mehrere Leitungen angeschlossenen Telefonapparats, wobei diese Leitung mehrfach auftritt, dann liefert die anfordernde Anwenderstelle eine Directory Nummer für die mehrfach auftretende Leitungsgruppe als ersten Eingang und die Prime Directory Nummer des Apparats, an den diese spezielle Leitung angeschlossen ist als Intersect Trans Type innerhalb der OPDU Argumentensequenz der Anforderung. Die bedienende Anwenderstelle innerhalb der Telefonvermittlungsanlage 3 übermittelt sodann die logische Geräteidentifikation LID innerhalb des Ergebnis-OPDU zurück.

Die hexadezimale Codedarstellung der OPDU Anforderung des Beispiels nach Anhang A steht in Übereinstimmung mit dem X.409 Nachrichtensignalformat. Im speziellen repräsentieren die beiden ersten Oktetts (Bytes zu 8 Bits) "A1 19" einen context specific constructor identifier mit einem ID Code von "1" und einer Länge von 19 (hex) (25 dezimal) Oktetten. Die Oktette "30" und "17" bestimmen eine Folge von 23 Elementen (17 hex).

Das erste Element der OPDU Anforderungssequenz gemäß der X.410 Empfehlung ist die Anforderungsidentifikation ID, welche die Anforderung identifiziert, die der angeforderten Operation zugeordnet ist, damit eine Operation von der anderen Operation unterschieden werden kann, welche die anfordernde Anwenderstelle der angeforderten Anwenderstelle übermittelt. In Übereinstimmung mit dem X.410 Standardprotokoll kann die anfordernde Anwenderstelle eine Anforderungsidentifizierung immer wiederverwenden, einschränkend vorausgesetzt, daß sie diese Identifizierung, die zuvor einer Anforderung zugeordnet war, solange nicht wiederverwenden kann, als die Anwenderstelle auf die vorherige Anforderung eine Antwort erwartet, diese jedoch noch nicht eingegangen ist.

Die X.409 Standardnotation für die Anforderungsidentifizierung ID weist einen Wert von 300 auf und ist im Anhang A wiedergegeben als "02 02 01 2C" was eine ganze Zahl bezeichnet, die eine Länge von zwei Oktetts und einen Wert von 012C (hex) aufweist (300 Dezimal).

Der X.410 Operationscodewert für die angeorderte TRANSLATE Operation in Übereinstimmung mit dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist ein Wert von 3 (Dezimal) zugeordnet. Dieser Wert wird gemäß X.409 hexadezimal repräsentiert als eine ganze Zahl (gekennzeichnet durch das Oktett "02"), welche eine Länge von 1 (gekennzeichnet durch das Oktett "01") und einen Wert von "03" aufweist.

Die X.410 Argumentfolge ist hexadezimal codiert als "30 OE", was eine Folge einer Länge von 14 (Dezimal) entspricht.

Wie schon vorstehend erwähnt, werden gemäß der vorliegenden Erfindung Anforderungs- und Server Adressenfelder definiert, um asynchrone Fernoperationen innerhalb der X.410 Empfehlung auszubauen, damit eine Anwendung bei Telefonanlagen durchgeführt werden kann. Die Anforderungsadresse von 50 (Dezimal) wird hexadezimal dargestellt als "53", was ein Anwendungsgrundelement bedeutet mit einem Identifizierungscode ID von 19 (Dezimal) einer Länge von "01" und einem Wert von "32" (Dezimal). Der ID Code ist eine aus Merkzahlen bestehende Identifikation in Übereinstimmung mit X.409. In entsprechender Weise ist die Server Adresse hexadezimal dargestellt durch "53 01 00", entsprechend einer Server Adresse von Null, wie oben erwähnt.

Die Eingangswerte der TRANSLATE Operation werden also, wie vorstehend erwähnt, durch das Trans-type Element, welches den Typ der Übersetzung spezifiziert, innerhalb der Anforderungsargumentfolge definiert, wobei gemäß der vorliegenden Erfindung die X.409 Notation verwendet wird. Diese ist in Anhang B dargestellt.

Die hexadezimale Darstellung innerhalb des Trans-type Elements für eine gewählte Directory Nummer wird somit wie folgt definiert: "81" bedeutet einen Kontext spezifischen aus Grundelementen bestehenden Identifikationscode für die "Directory Number", der eine Länge von "04" Oktetten und einen Wert von "31 32 33 31" oder 1201 (Dezimal) aufweist, wobei "33" der numerische Wert des ASCII-Codes für die Zahl "3" bedeutet.

Die X.409 Kodierung, die bei der Mitteilung für die Anwenderschicht gemäß Anhang A verwendet wird, enthält ausreichend Informationen zur Implementierung der Präsentations-, Sitzungs- und Transport-OSI-Schichten, welche erforderlich sind, um die Nachricht an die Telefonvermittlungsanlage 3 zu richten und um sie dort zu sammeln. Im speziellen sind die Senderadresse (Anforderungsadresse) und die Empfängeradresse (Server Adresse) innerhalb der Argumentsequenz des Anforderungssignals enthalten, um eine Sitzungsschichtadressierung durchzuführen, die es der Anwendungsstelle ermöglicht, die Anwendernachricht an die geeignete Anforderungsstelle zu leiten. Normalerweise ist gemäß dem OSI Protokoll innerhalb der Sitzungs-Transportschicht eine Feldlänge oder ein anderer Rahmen erforderlich, um es zu ermöglichen, daß die Leitungsschichtrahmen in Anwenderschichtadressen korrekt wiederzusammengestellt werden. Gemäß der X.409 Kodierung, die in der in Anhang A dargestellten Präsentationsschicht verwendet wird, wird das erste Längsfeld in der Nachricht (der X.410 OPDU Identifikation folgend) durch die Sitzungsschicht bei der Server Anwenderstelle innerhalb der Telefonvermittlungsanlage dazu verwendet, die OPDU Anforderung zusammenzusetzen.

Die vollkodierte Anwenderschichtnachricht (einschließlich Transport-, Sitzungs- und Präsentationsschichtinformation) wird von der Hauptsteuerschaltung (15) übermittelt und von der HDLC Steuerschaltung 11 empfangen. Die HDLC Steuerschaltung 11 setzt den geforderten Leitungsschichtrahmen, Fehlerkorrektur und Rückübermittlungsinformation in bekannter Weise ein. Gemäß einem erfolgreichen Prototyp führt die HDLC Steuerschaltung ein LAPB aus, wie in der CCITT Empfehlung X.25 (1984) definiert.

Da alle Kodier- und Nachrichtenleitweg Informationen innerhalb der Anwenderschichtnachricht enthalten sind, können die Schichten zwischen der Leitungsschicht und der Präsentationsschicht undefiniert bleiben, womit unter Verwendung dieser Schichten zukünftige Kommunikationsprotokolle möglich sind. Gemäß der vorliegenden Erfindung wird also ein Punkt zu Punkt Protokoll errichtet, in welchem jedes Ende des Zwischengliedes verantwortlich ist für die Behandlung der Netzwerkschichterfordernisse innerhalb seines eigenen Netzwerks. Bei jedem Netzwerk werden daher die Transport- und Sitzungsschichten dargestellt durch ein Null-Oktett, welches den zu übermittelnden X.409/410-Daten vorangesetzt ist. Das Format der zwischen den HDLC Steuerschaltungen 11 und 13 zu übermittelnden Nachrichten und damit das Format des Nachrichtenaustausches zwischen den Senderempfängern 5 und 7 ist in Fig. 2 gezeigt.

Die physikalische Schicht Anforderungs-OPDU Nachricht wird über den Senderempfänger 5 dem physikalischen OSI Schichtmedium übermittelt, das, wie oben erwähnt, eine standardisierte RS-232 Leitung 9 ist. Die physikalische Schichtnachricht wird durch den RS-232 Empfänger 7 der Telefonvermittlungsanlage 3 empfangen und von dort der HDLC Steuerschaltung 13 zugeführt, und zwar entsprechend dem Format der Fig. 2. Die HDLC Steuerschaltung 13 decodiert die Leitungsschichtinformation und leitet die Schichtdaten Netzwerk, Transport, Sitzung, Präsentation und Anwender an die Hauptsteuerschaltung 17 weiter.

Die Hauptsteuerschaltung 17 decodiert die X.409/410 Anwenderschichtnachricht und bestimmt die Anwenderstelle, welche die angeforderte TRANSLATE Operation bedienen soll und führt als Antwort ein Ergebnis OPDU zum Hauptrechner 1 zurück zur Bestätigung der erfolgreichen Ausführung der angeforderten Prozedur. Das Ergebnis OPDU ist in Anhang C wiedergegeben.

Das Ergebnis OPDU entspricht im wesentlichen der X.410 Spezifikation. Zusätzlich sind jedoch innerhalb der Ergebnissequenz Anforderungsadressen und Server Adressenfelder enthalten. Die Anforderungsadresse beispielsweise, die in Anhang B dargestellt ist, ist 50 (Dezimal) womit der Leitweg festgelegt ist, um das Ergebnis OPDU der anfordernden Anwenderstelle im Hauptrechner zuleiten zu können, die Server Adresse wird durch 99 (Dezimal) definiert, zur Identifikation der Anwenderstelle innerhalb der Telefonvermittlungsanlage 3, welche die TRANSLATE Prozedur ausgeführt hat.

Der von der TRANSLATE Operation zurückgeführte Wert ist somit ein logischer Descriptor, der eine logische Geräteidentifikation LID enthält, welche in anderen Anwenderschichtprozeduren innerhalb der Telefonvermittlungsanlage 3 dazu verwendet wird, eine bestimmte Resource innerhalb der Anlage 3 zu identifizieren. Zusätzlich wird eine Beschreibung der Resource zurückgeführt. Wird beispielsweise durch die LID identifiziert, daß die Resource ein Telefonapparat ist, dann wird die Apparateart, die Directory Nummer, Name und PLID ebenfalls zurückgeführt. Für den Fall, daß die logische Geräteidentifikation LID als Resource eine Fernleitung identifiziert, dann wird die Leitungsnummer, der Name, PLID und Art der Leitung rückübermittelt. Handelt es sich bei der Resource um einen Leitweg, dann wird die Anzahl der Leitungen in der Leitungsgruppe, die dem Leitweg zugeordnet ist, übermittelt. Zusätzliche Resourcen können durch die Geräteidentifikation in Beantwortung der TRANSLATE Prozedur wie folgt beschrieben werden: Route List, Route Plan, Hunt Group, Multicall Group and Key Line Group. Das Ergebnis OPDU, welches zurückgeführt wird in Verbindung mit der Übersetzung von zusätzlichen Resourcen umfaßt spezifische Informationen von jedem dieser Bereiche.

Zurückkommend auf das in den Anhängen A und C dargestellte Beispiel besteht die zurückgeführte logische Geräteidentifikation LID aus 32 (Dezimal) mit einer Directory Nummer, die den Wert 1201 hat, einem auf die Telefonvermittlungsanlage bezogenen Resourcennamen "Mary Called", einem PLID zur Identifikation eines spezifischen Orts der Resourcen Hardware innerhalb der Telefonvermittlungsanlage 3 sowie eine zusätzliche Information betreffend die Art des Telefonapparats und die Attribute dieses Apparats.

Unter Verwendung der von der Telefonvermittlungsanlage 3 erhaltenen logischen Geräteidentifikation kann dann die Anwenderstelle innerhalb des Hauptrechners 1 bestimmen, daß der identifizierte Telefonapparat (Directory Nummer 1201, zugehörend zu Marry Called) zu überwachen ist, wobei die Telefonvermittlungsanlage 3 veranlaßt wird, eine Rufzustandsnachricht an den Hauptrechner 1 zu übermitteln und zwar jeweils wenn der Apparatezustand sich ändert (beispielsweise Hörer aufgelegt - Hörer abgenommen, wählen, aufhalten, schalten usw.).

Die Anwenderstelle innerhalb des Hauptrechners 1 erzeugt also eine Anforderungs-OPDU zum Einleiten einer Überwachung der Resource, welche durch die zuvor übersetzte Geräteidentifikation LID identifiziert wurde, was in Anhang D gezeigt ist.

Wie Anhang D wiedergibt, wird durch die Anwender Software der Hauptsteuerschaltung 15 eine neue Anforderungsidentifikation von 301 (Dezimal) erzeugt zur Identifizierung der angeforderten Überwachungsprozedur. Da die TRANSLATE Prozedur jedoch eine unabhängige Transaktion ist, kann die vorherige Anforderungsidentifikation von 300 (Dezimal) wiederverwendet werden.

Ein Operationscode von 20 (Dezimal) wird zur Identifikation der Überwachungsprozedur verwendet und eine Parametersequenz wird erzeugt zur Spezifizierung der Geräteidentifikation LID, welche von der zuvor ausgeführten TRANSLATE Prozedur erhalten wurde. Weiterhin wird eine Überwachungsfilterinformation erzeugt, die nachfolgend im einzelnen noch beschrieben wird. Zusätzlich wird eine Anforderungsadresse von 51 (Dezimal) erzeugt zur Identifikation der angeforderten Anwenderstelle innerhalb des Hauptrechners 1, weiterhin wird eine Server Adresse von Null erzeugt, da der Hauptrechner 1 nicht weiß, welche Anwenderstelle innerhalb der Telefonvermittlungsanlage 3 die Anforderung bedient.

Wie vorstehend erwähnt, wird vom Hauptrechner 1 eine Überwachungsprozedur veranlaßt, um die Aktivität irgendeiner Resource innerhalb der Telefonvermittlungsanlage zu überwachen. Die angeforderte Überwachungsprozedur führt dazu, daß die Telefonvermittlungsanlage 3 unmittelbar eine Rufzustandsmitteilung zurückübermittelt in bezug auf die zu überwachende Resource, welche einer speziellen Filterung unterworfen ist. Die Rufzustandsnachricht gibt den augenblicklichen Zustand der Resource wieder. Es wird jedoch keine historische Information über eine Rufverbindung erzeugt, die soeben aufgebaut wird. Falls bei der Resource nur ein bestimmter Rufzustand durch die Überwachungsprozedur überwacht werden soll und dieser Zustand bei der Übermittlung der Anforderung nicht vorhanden ist, dann wird nach der Anforderung nicht unmittelbar von der Telefonvermittlungsanlage 3 die Rufzustandsmitteilung übermittelt. Diese wird vielmehr erst dann erzeugt und abgesandt, wenn bei der Resource dieser zu überwachende Zustand auftritt.

Bei der Parametersequenz der Überwachungsanforderungsnachricht identifiziert die logische Geräteidentifikation LID von 32 (Dezimal) den innerhalb der Telefonvermittlungsanlage 3 zu überwachenden Telefonapparat 21 (Directory Nummer 1201). Der vorerwähnte Monitorfilter ist ein Selektor, der bestimmt, welche spezielle Funktion des Telefonapparates für den Hauptrechner von Interesse ist und somit überwacht werden soll. Dieser Befehl wird ausgedrückt durch eine Bitfolge von Rufzuständen, gefolgt durch ein Boolean Kennzeichen, das kennzeichnet, ob über alle Zustände zu berichten ist und ein weiteres Boolean Kennzeichen, das anzeigt, ob eine Namensinformation in den Rufzustandsmitteilungen enthalten sein soll.

In Beantwortung der empfangenen Zustandsanforderungs­ nachricht, welche die vorerwähnten Filterzustände enthält, informiert sodann die Telefonvermittlungsanlage 3 den Hauptrechner 1 lediglich über die Aktivitäten, die den speziellen Filterzuständen entsprechen. Die Mindestanzahl von Rufzuständen, die eine Bestimmung ermöglichen, ob ein Telefonapparat frei ist oder mit Aktivitäten beschäftigt ist, sind die Zustände frei, wählen und belegt.

Wie schon zuvor erwähnt, wird die Server Adresse in der Anforderungsnachricht OPDU als ein Null Oktett ausgedrückt. Die Rufzustandsnachrichten, wie sie von der Anwenderstelle in der Telefonanlage erzeugt werden, werden dann an die Server Adresse im Hauptrechner übermittelt, wie sie im Anforderungsadressenfeld der Überwachungsanforderungsnachricht OPDU enthalten ist.

Wie der Anhang D zeigt, sind alle Zustände, Ereignisse und Namensinformationen im Anforderungsbefehl spezifiziert und sind somit in dem von der Telefonvermittlungsanlage generierten Rufzustandssignal enthalten und dem Hauptrechner 1 übermittelt.

Das Überwachungsergebnis OPDU führt lediglich die Anforderungsidentifikation von 301 (Dezimal) und eine Ergebnisfolge zurück, welche die Anforderungsadresse 51 (Dezimal) und eine Server Adresse von 52 aufweist. Wie schon oben erwähnt, wird eine Rufzustandsnachricht von der Telefonvermittlungsanlage 3 dem Hauptrechner 1 zurückgeführt, nachdem ein Überwachungsbefehl erzeugt wurde. Hierdurch wird die Anwenderstelle im Hauptrechner über den gegenwärtigen Zustand des identifizierten Telefonapparats informiert, sowie darüber, welche Merkmale dieser Apparat aufweist, die Art des aufgebauten Rufes, den Namen des anderen Teilnehmers und seine Nummer sowie eine Geräteidentifikation, die den überwachten Telefonapparat identifiziert. Diese Prozedur wird auch von der Telefonvermittlungsanlage 3 durchgeführt, wenn sich ein Zustand des überwachten Telefonapparats ändert. Wie oben erwähnt, können die in der Rufzustandsnachricht enthaltenen Informationselemente gefiltert werden entsprechend der Parameterfolge im Überwachungsanforderungs-OPDU.

Ist beispielsweise der überwachte Apparat 21 frei, dann erzeugt die Telefonvermittlungsanlage 3 ein Rufzustandsanforderungs- OPDU gemäß Anhang E.

Gemäß Anhang E wird eine neue Anforderungsidentifikation ID von 303 (Dezimal) durch die Hauptsteuerschaltung 17 der Telefonvermittlungsanlage 3 erzeugt zur Identifikation der speziellen Rufzustandsanforderung OPDU. Ein Operationscode von 23 (Dezimal) wird erzeugt in Übereinstimmung mit dem X.410 Protokoll zur Identifikation der Rufzustandsprozedur. Eine Parameterfolge wird erzeugt, die eine Anforderungsadresse von 52 (Dezimal) enthält zur Identifikation der Anwenderstelle innerhalb der Telefonanlage 3, welche die Rufzustandsmitteilungen erzeugt sowie eine Server Adresse von 51 (Dezimal) entsprechend der Anwenderstelle im Hauptrechner 1, welche die Überwachungsprozedur angefordert hat. Weiterhin wird eine Geräteidentifikation LID von 32 (Dezimal) dazu verwendet, die Identität des Telefonapparates 21 als zu überwachenden Apparat zu bestätigen. Eine Rufreferenzidentifikation (0) wird erzeugt, die anzeigt, daß bei dem zu überwachenden Apparat keine Zustandsänderung auftritt. Der Rufreferenzwert wird in Situationen verwendet, wo augenblicklich Rufverbindungen aufgebaut werden. Ein Apparat, der frei ist, (wie in Anhang E) oder der nicht erreichbar ist, weist einen Rufreferenzwert von 0 auf.

Der Rufreferenzwert wird benötigt, um zwischen Rufverbindungen der gleichen Geräteidentifikation LID unterscheiden zu können. Es ist möglich, daß infolge von Ausblendsituationen beim überwachten Apparat ein Ruf verloren­ geht und eine Neurufverbindung aufgebaut wird, bevor der Hauptrechner 1 davon informiert wird. Falls beispielsweise der Hauptrechner 1 eine Anforderungsprozedur für den ersten Ruf übermittelt, dann wird die Telefonvermittlungsanlage 3 einen Fehler OPDU zurücksenden, da der verwendete Rufbezug sich auf eine alte, nicht mehr bestehende Rufverbindung bezieht.

Die Überwachungs Server Adresse von 51 (Dezimal) bleibt während der gesamten Überwachungssession die gleiche. Der Rufreferenzwert jedoch ändert sich jeweils, wenn der Apparat in den Wählzustand eintritt. Ein neuer Rufreferenzwert wird auch immer dann erzeugt, wenn der Apparat in eine Rufverbindung eintritt und er zuvor frei war. Die Verwendung des Rufreferenzwertes stellt also sicher, daß die Anforderungsruffunktion, die nachfolgend noch im einzelnen beschrieben wird, auf die augenblickliche Rufverbindung bezogen ist.

Ein Reihenpositionswert von 0 wird von der Anwenderstelle, die den Rufzustand innerhalb der Telefonvermittlungsanlage 3 anfordert, erzeugt zur Anzeige daß bei der überwachten Vorrichtung keine weitere Rufverbindungsanforderung ansteht. Dieses Feld braucht nicht in allen Fällen verwendet werden. Es ist primär für Datenverbindungen vorgesehen, wo die gegenwärtige Stelle in der Reihe von Bedeutung ist, falls die Reihe lang ist. Sprechverbindungen innerhalb der Reihe erhalten normalerweise den Wert 0 außer der Apparat ist Teil einer automatischen Rufverteilung ACD.

Ein Rufzustandswert von 1 wird erzeugt von der Anwenderstelle um anzuzeigen, daß der Telefonapparat 21 nicht belegt ist. Ein Rufereigniswert von 0 wird erzeugt zur Anzeige eines "Nicht-Rufereignisses" und ein Ruftypwert von 0 wird erzeugt zur Anzeige eines "Nicht-Ruftyps" und beim Telefonapparat 21 als erlaubt auszuführende Merkmale werden mit "redial" bezeichnet.

Falls der Ruftyp ein Nicht-Ruftyp ist, dann ist es nicht erforderlich, dem Hauptrechner 1 eine spezielle Ruftypinformation zu übermitteln. Die Rufzustands- und Rufereigniswerte geben dem Hauptrechner 1 ausreichend Informationen, um den Rufzustand abzuschätzen. Die Telefonvermittlungsanlage 3 kann Teilnehmerinformationen übermitteln, falls gewünscht wird, sicherzustellen, daß Teilnehmerinformationen mit korrekten Daten auf den neuesten Stand gebracht werden.

Die Nicht-Rufereignisinformation wird verwendet, wenn eine Rufzustandsmitteilung erstmals gesendet wird in Beantwortung eines Überwachungsbefehls und wenn über keine Ereignisinformation zu berichten ist.

Der Features Allowed Wert in Form einer Bit Kartierung zeigt die Merkmale an, welche im gegenwärtigen Rufzustand angefordert werden können. Dies ist hilfreich zur Anzeige eines genauen Menues für den Ruf zu einem Benutzer, der sich an einem mit dem Hauptrechner 1 verbundenen Terminal befindet. Der Features Allowed Wert kann von einer Telefonanlage zur anderen unterschiedlich sein, weist jedoch eine allgemein übliche Darstellung auf.

Normalerweise nach dem X.410 Protokoll wird der Hauptrechner 1 ein Ergebnis OPDU in Beantwortung einer empfangenen Rufzustandsnachricht von der Anlage 3 erhalten. Gemäß der vorliegenden Erfindung jedoch wird für die Rufzustandsnachricht ein Ergebnis OPDU nicht definiert. Der Grund hierfür besteht darin, daß die Rufzustandsnachrichten dem stärksten Verbindungsverkehr Rechnung tragen müssen. Die Hauptsteuerschaltung 17 der Telefonvermittlungsanlage 3 sollte daher nicht überlastet werden durch das Verarbeiten empfangener und zurückgeführter Resultate für die angeforderten Rufzustandsoperationen, da die zurückgeführten Resultate OPDU keine nützlichen Informationen für die Anlage 3 enthalten.

Im Fall, daß ein Anrufer von einer anderen Anlage (Joe Caller am Apparat 23 entsprechend der Directory Nummer 1200) versucht, die Directory Nummer 1201 anzuwählen, dann sendet die Telefonvermittlungsanlage 3 eine andere Rufzustandsmitteilung, die anzeigt, daß der Apparat, der durch die logische Geräteidentifikation LID 32 identifiziert ist, seinen Zustand von unbesetzt zu besetzt geändert hat, sowie eine Information, wer anruft, was in Anhang F wiedergegeben ist.

Die in bezug auf Anhang F beschriebene Rufzustandsmitteilung zeigt an, daß LID 32 durch den Rufzustandswert 5 (Dezimal) charakterisiert ist, womit angezeigt ist, daß der Apparat sich im Belegtzustand befindet infolge eines ankommenden Rufs, welcher durch einen Rufreferenzwert von 638 (Dezimal) identifiziert ist. Der Rufereigniswert zeigt die neue Rufverbindung an und der Ruftypwert wird definiert als Nichtruftyp.

Die erlaubten Funktionsmerkmale für den Apparat 21 zu diesem Zeitpunkt bestehen in einer Antwort oder einer Rufweiterleitung. Die für Marry Called zur Verfügung stehende Optionen bestehen also zu diesem Zeitpunkt nach dem Beispiel des Anhangs F darin, den Ruf zu beantworten, wobei dann, wenn nach einer bestimmten Zeitdauer der Anruf nicht beantwortet wird, der Ruf an eine zuvor programmierte Stelle weitergeleitet wird.

Die Rufzustandsmitteilung enthält zusätzlich Informationen, die den Teilnehmer betreffen, der den Apparat 21 anwählt. Die Directory Nummer der anrufenden Vermitt­ lungsanlage wird mit 1200 definiert und der Name dieses Teilnehmers wird identifiziert als Joe Caller.

Falls Marry Called den Anruf annimmt, dann wechselt der Zustand des Apparats 21 vom Belegtzustand zum Verbindungszustand. Beide Teilnehmer können nunmehr miteinander sprechen. Demgemäß erzeugt die Anlage 3 eine weitere Rufzustandsmitteilung für den Hauptrechner 1, wie in Anhang G dargestellt. Die Rufzustandsinformation der Nachrichtenfolge nach Anhang G kann wie folgt zusammengefaßt werden:

CALL-STATUS (Rufzustand) =
logical-equiment-id:
32
(Apparateidentifikation) @	call-reference:	638
(Rufbezug) @	queue-position:	0
(Stellung in der Reihe) @	call-state:	CONNECTED
(Rufzustand)	(verbunden)
call-event:	answer-invoked
(Rufereignis)	(Antwort angefordert)
call-type:	two-party-call
(Rufart)	(Zwei-Teilnehmer-Ruf)
features-allowed:	cons-hold + disconnect + dall-hold
(erlaubte Funktionen)	(Verbindung halten + unterbrechen + Ruf halten)
other-party-name:	CALLER, JOE
(Name des anderen Teilnehmers) @	other-party-ext:	1200
(Nummer des anderen Teilnehmers) @	third-party-name: @	third-party-ext:

Falls Marry Called beim Apparat 21 den Hörer nicht annimmt, wechselt der Zustand vom Verbindungszustand in den nichtbelegten Zustand, und eine weitere Rufzustandsmitteilung wird von der Telefonvermittlungsanlage 3 erzeugt und dem Hauptrechner 1 übermittelt, wie dies Anhang H zeigt. Die Rufzustandsinformation der Mitteilungsfolge nach Anhang H kann wie folgt zusammengefaßt werden:

CALL-STATUS (Rufzustand) =
logical-equiment-id:
32
(Apparateidentifikation) @	call-reference:	0
(Rufbezug) @	queue-position:	0
(Stellung in der Reihe) @	call-state:	IDLE
(Rufzustand)	(nicht belegt)
call-event:	this-party-on-hook
(Rufereignis)	(Teilnehmerhörer aufgelegt)
call-type:	nil-call-type
(Rufart)	(Nichtruftyp)
features-allowed:	redial
(erlaubte Funktionen)	(wählen)
other-party-name: @	(Name des anderen Teilnehmers) @	other-party-ext: @	(Nummer des anderen Teilnehmers) @	third-party-name: @	third-party-ext:

Für den Fall, daß die Anwenderstelle des Hauptrechners, welche die Überwachungsprozedur angefordert hat, die Beendigung der weiteren Überwachung des Apparats 21 wünscht, dann wird eine Stoppüberwachungsnachricht an die Vermittlungsanlage 3 gemäß Anhang I übermittelt.

Die vereinfachten Beispiele gemäß den Anhängen A bis I stellen ein besonders einfaches Szenario zur Verdeutlichung der Prinzipien der vorliegenden Erfindung dar. Viele weitere und kompliziertere Anwendungen können jedoch gemäß der vorliegenden Erfindung ausgeführt werden. Zusätzlich zu den Prozeduren TRANSLATE, Überwachung, Rufzustand und Stoppüberwachung können weitere Telefon- und Kontrollprozeduren durchgeführt werden. Beispielsweise kann vom Hauptrechner 1 eine Prozedur INITIATE CALL veranlaßt werden, die für eine Rufverbindung von einer bestimmten Resource, beispielsweise vom Apparat 21, nach einer vorbestimmten Stelle zugunsten der identifizierten Resource bevollmächtigt. Weiterhin kann der Hauptrechner 1 eine Rufverbindung freigeben, die innerhalb der Telefonvermittlungsanlage 3 aufgebaut wird.

Zusätzlich zu den Überwachungs- und Stoppüberwachungsprozeduren kann eine Interrogate Überwachungsprozedur von den Anwenderstellen der Vermittlungsanlage 3 und/oder des Hauptrechners 1 angefordert werden um den Zustand einer angeforderten Überwachungsprozedur bei der jeweils anderen Anwenderstelle zu bestimmen. Wurde beispielsweise von einer bestimmten Vorrichtung über eine bestimmte Zeitdauer hinweg keine Rufzustandsmitteilung empfangen, dann kann entweder die Anlage 3 oder der Hauptrechner 1 verifizieren, daß das tatsächlich eine Überwachungsprozedur für die bestimmte Vorrichtung aktiv ist.

Weiterhin kann der Hauptrechner 1 eine Prozedur anfordern, um innerhalb der Vermittlungsanlage 3 eine Funktion zu aktivieren, zugunsten eines Rufs auf den Bezug genommen ist durch eine bestimmte Rufreferenznummer durch Verwendung einer Anforderungsrufprozedur. Es ist auch möglich, daß entweder der Hauptrechner oder die Vermittlungsanlage eine Programmfunktion anfordern um der anfordernden Anwenderstelle zu ermöglichen, eine Funktion zugunsten eines bestimmten Teils der beiden Anlagen, beispielsweise zugunsten des Servers zu programmieren oder zu entprogrammieren. Somit kann der Hauptrechner 1 diese Prozedur dazu verwenden, eine Prozedur der Telefonvermittlungsanlage zu programmieren. Alternativ dazu ist es möglich, daß die Vermittlungsanlage 3 diese Funktion dazu verwenden kann, den Hauptrechner zu programmieren.

Eine Vielzahl von Steuerprozeduren beispielsweise für die angeschlossenen Geräte können ausgeführt werden, durch welche der Hauptrechner einen bestimmten Telefonapparat belegen kann, in seine Anzeige einschreiben kann und vom Apparat Kastenanschläge empfangen kann. Die Telefonapparate können entweder aufgeteilt oder exklusiv belegt werden. In der aufgeteilten Arbeitsweise übernimmt die Vermittlungsanlage 3 die Steuerung des Apparats von der Anwenderstelle des Hauptrechners, falls der Telefonapparat für Telefonoperationen benötigt wird. Wird beispielsweise am Apparat 25 der Hörer abgenommen, während die Anwenderstelle des Rechners diesen Apparat benutzt, dann teilt dies die Vermittlungsanlage 3 dem Hauptrechner 1 mit, so daß dieser die Steuerung über den Apparat beendet. Bei der exklusiven Belegung wird ein Telefonapparat von der Sicht der Vermittlungsanlage als belegt angesehen.

Zusätzlich können Anwendersteuerprozeduren durchgeführt werden, um eine richtige OSI Anwenderschichtintegration zwischen speziellen Telefonapparaten und Anwendern zu ermöglichen, die im Hauptrechner 1 angeordnet sind. Diese Kontrollprozeduren ermöglichen es dem Hauptrechner 1 die Anwender in der Vermittlungsanlage 3 zu identifizieren und einen Zugriffmechanismus zu diesen Anwendern zu definieren, die ihrerseits einem Benutzer des speziellen Telefonapparats präsentiert werden.

Beispielsweise macht der Hauptrechner 1, der eine Anwendung durchführt, die Anwendung der Vermittlungsanlage 3 bekannt, indem er eine DEFINE APPLICATION Mitteilung erzeugt und übermittelt. Die Vermittlungsanlage 3 macht diese Anwendung dem Benutzer des Telefonapparats durch Anzeige am Telefonapparat bekannt oder stellt einen Funktionszugriffscode zur Verfügung. Die Vermittlungsanlage 3 unterrichtet sodann den Hauptrechner 1, falls der Benutzer diese Anwendung anfordert. Der Hauptrechner 1 wirkt dann mit dem Teilnehmerapparat in der gleichen Weise zusammen, wie mit einem einfachen Terminal unter Verwendung der oben erwähnten Vorrichtungskontrollprozeduren (belegter Apparat, Eingabe in die Anzeige, Empfang von Tastenbetätigungen usw.). Hat der Hauptrechner 1 diese Anwendung beendet, gibt er den Telefonapparat für den normalen Gebrauch frei.

So kann beispielsweise auf diese Weise ein im Hauptrechner 1 aufgebautes Textnachrichtensystem so ausgedehnt werden, daß mittels der Apparate innerhalb der Vermittlungsanlage die für diese Apparate bestimmten Mitteilungen über ein Display am Telefon abgelesen werden können.

Verschiedene ferngesteuerte Operationen werden nachfolgend an Hand des Anhangs J beschrieben.

Die Ausführung der ferngesteuerten Operationen erfolgt bei der folgenden Erfindung in Übereinstimmung mit den OSI Empfehlungen X.409 und X.410. Damit eine Anpassung an die asynchrone Natur der Telefonvorgänge vorgenommen werden kann, werden jedoch innerhalb der Parameter- und Ergebnisfolgen Anforderungsadressen und Serveradressenfelder vorgesehen. Gemäß der vorliegenden Erfindung weist die Serveranwenderstelle ein Gedächtnis auf über die laufende Operation im Gegensatz zur X.410 Empfehlung, bei der alle Prozeduren speicherlose unabhängige Transaktionen sind.

Im Falle der zuvor erwähnten Überwachungsprozedur kann für eine gegebene Geräteidentifikation gleichzeitig mehr als eine Überwachungsfunktion aktiv sein. Die Serveradresse, welche im Ergebnis OPDU zurückgeleitet wird, muß für den Augenblick dieser Operation bei der Server Anwenderstelle einzig sein. Jede Überwachungsprozedur ist versehen mit einer Serveradresse, die es der Vermittlungsanlage 3 ermöglicht, die spezielle Instanz der Überwachung zu identifizieren. Die Vermittlungsstelle 3 kann Überwachungsserveradressen einzeln über eine gegebene Geräteidentifikation LID zuteilen, jedoch nicht notwendigerweise einzeln über mehrere Überwachungen bei verschiedenen Geräteidentifikationen. Die Kombination einer Serveradresse und einer Geräteidentifikation müssen sich zu einem gegebenen Zeitpunkt auf eine Überwachungsfunktion bei der Vermittlungsanlage 3 beziehen. Der Hauptrechner 1 muß diese Serveradresse bei allen folgenden Mitteilungen verwenden, die an die Vermittlungsanlage 3 in bezug auf die geforderte Operation gerichtet werden, wie beispielsweise die der Überwachungsfunktion nachfolgende Stoppüberwachungsfunktion.

An Stelle einer RS-232 Leitung 9 kann auch eine PCM-Verbindungsleitung oder ein anderes Leitungssystem verwendet werden, damit die anfordernde und die antwortende Anwenderstelle mit einander entsprechendem OSI Protokoll kommunizieren können. Es ist auch möglich, die Anforderungs- und Serveradressenfelder aus der Anwenderschicht zu entnehmen, um sie beispielsweise in der Sitzungsschicht zu plazieren.

Vorstehend wurde der Datenaustausch zwischen einem Hauptrechner und einer Telefonvermittlungsanlage beschrieben. Der gleiche Datenaustausch kann jedoch auch vorgenommen werden zwischen zwei Telefonvermittlungsanlagen oder zwischen zwei Hauptrechnern.

Der Gegenstand der Erfindung ist anwendbar bei Vermittlungsanlagen, an die mehrere hundert Telefonapparate, Datenterminals sowie Amtsleitungen angeschlossen sind.

Claims (12)

1. Kommunikationsverfahren zur Ausführung von ferngesteuerten Steuer- und Überwachungsaufgaben zwischen zwei Rechnereinheiten unter Verwendung des Open Systems Interconnect Communication Protocols, wobei die eine Rechnereinheit durch eine ihrer Anwenderstellen ein Anforderungssignal erzeugt, das der anderen Rechnereinheit übermittelt wird, die eine ihrer Anwenderstellen zur Ausführung der Steuer- und Überwachungsaufgaben bestimmt und ein Resultatsignal der einen Rechnereinheit zurückübermittelt, dadurch gekennzeichnet, daß das Anforderungssignal Adreßdaten zur Identifizierung der anfordernden Anwenderstelle und das Antwortsignal Adreßdaten zur Identifizierung der ausführenden Anwenderstelle enthält, diese Adreßdaten den Leitweg und den Empfänger der Anforderungs- und Antwortsignale bestimmen und die ausführende Anwenderstelle durch Kenntnis dieser Adreßdaten alle nachfolgenden Antwortdatensätze an die anfordernde Anwenderstelle übermitteln kann.

2. Kommunikationsverfahren nach Anspruch 1, dadurch gekennzeichnet, daß die eine Rechnereinheit ein Hauptrechner (1) und die andere Rechnereinheit eine Telefonvermittlungsanlage (3) ist.

3. Kommunikationsverfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß das Antwortsignal ein Fehlerdatensignal ist, wenn die ausführende Anwenderstelle die angeforderte Aufgabe nicht ausführt.

4. Kommunikationsverfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß das Antwortsignal ein Zurückweisungssignal ist, wenn die ausführende Anwenderstelle ein falsch formatiertes Anforderungssignal erhält.

5. Kommunikationsverfahren nach Anspruch 2, dadurch gekennzeichnet, daß der Hauptrechner (1) zusätzliche Überwachungssignale nach dem OSIC- Protokoll übermittelt, die die Telefonvermittlungsanlage nach der Durchführung der angeforderten Aufgabe abfragt.

6. Kommunikationsverfahren nach Anspruch 2, dadurch gekennzeichnet, daß das Anforderungssignal aus einem die Aufgabe beendenden Rückstellsignal besteht.

7. Kommunikationsverfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß das Ergebnissignal ein logisches Geräteidentifizierungssignal enthält, das die Stelle definiert, bei welcher die ausführende Anwenderstelle die Aufgabe ausführt.

8. Kommunikationsverfahren nach Anspruch 2, dadurch gekennzeichnet, daß die Aufgabe in der Errichtung einer Rufverbindung von einem Anschluß der Telefonanlage (3) zu einem weiteren Anschluß besteht, wobei die Anschlüsse durch das Anforderungssignal bestimmt werden.

9. Kommunikationsverfahren nach Anspruch 2, dadurch gekennzeichnet, daß die Aufgabe in der Freigabe einer Rufverbindung zwischen einem Anschluß der Telefonvermittlungsanlage (3) und einem weiteren Anschluß besteht, wobei die Anschlüsse durch das Anforderungssignal bestimmt werden.

10. Kommunikationsverfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß das Antwortsignal Parameterdaten enthält, die die Parameter des Ergebnisses der durchgeführten Aufgabe aufweisen.

11. Kommunikationsverfahren nach Anspruch 3, dadurch gekennzeichnet, daß das Antwortsignal aus den Adreßdaten, einem Fehlercode sowie Parameterdaten besteht, wobei der Fehlercode den Fehler und die Parameterdaten die Parameter des Fehlers angeben.

12. Kommunikationsverfahren nach Anspruch 4, dadurch gekennzeichnet, daß das Antwortsignal aus den Adreßdaten und Problemdaten, die die Ursache der Zurückweisung und des Anforderungssignals spezifizieren, besteht.