Es ist bereits bekannt, das QSIG-Protokoll
für private
Telekommunikationsnetze einzusetzen. Bei der Vernetzung von TK-Anlagen
unterschiedlicher Hersteller stellt dieses Protokoll ein leistungsstarkes,
standardisiertes Signalisierungssystem dar. Es ist eine vom Standardisierungsgremium
ETSI anerkannte Plattform für Entwicklungen
bei der heterogenen Vernetzung von TK-Anlagen. Die Standardisierung
erfolgt auf internationaler Ebene durch ISO/IEC und im europäischen Raum
durch ETSI und ECMA, wobei eine gegenseitige Harmonisierung der
Standards angestrebt wird. Das QSIG-Protokoll heißt offiziell
'D-KanaI-Protokoll am Q-Referenzpunkt'. Der Q-Referenzpunkt ist der logische Signalisierungspunkt
zwischen zwei TK-Anlagen. Die physikalische Anbindung erfolgt am
C-Referenzpunkt. QSIG arbeitet auf der dritten Schicht, der Vermittlungsschicht des
OSI-7-Schichten-Modells.
Die Verbindungen zwischen den einzelnen
Netzknoten des privaten Telekommunikationsnetzes werden durch Standleitungen
und/oder Wählleitungen
und/oder IP(Internet-Protokoll)-Strecken (über so genannte IP-Gateways)
realisiert, wobei hier beliebige Konfigurationen in einem Netz auftreten
können.
Solche privaten Telekommunikationsnetze sind über sogenannte Gateways mit
dem öffentlichen
Telekommunikationsnetz verbindbar. Die Grundlagen des QSIG-Protokolls
bilden die Basic Calls (BC), also die Basismeldungen, und das Generic
Function Protocol (GF), also generische Funktionen.
In BC sind der Verbindungsauf- und
-abbau, sowie die Fehlerbehandlung beinhaltet. Aufbau und Abbau
von QSIG-Verbindungen zwischen den einzelnen Knoten des privaten
Telekommunikationsnetzes werden demnach mittels Meldungen aus dem
BC vorgenommen.
Das GF stellt die Protokollmechanismen
für die
Steuerung von Supplementary Services (Ergänzende Dienste) und Additional
Network Features (zusätzliche
Netzwerkmerkmale) bereit. Die Supplementary Services (SS) sind Leistungsmerkmale,
die das QSIG-Protokoll für
die Nutzer des TK Netzverbundes zur Verfügung stellt. Unter Addtional
Network Features (ANF) finden sich Funktionen, die unabhängig vom
Nutzer die Verwaltung von Verbindungen oder die Leistungen des gesamten
Netzes verbessern. Für
Hersteller, denen die Basis-Leistungsmerkmale von QSIG (automa tischen
Rückruf,
Rückruf
bei frei, Rufumleitung, Anrufüberweisung,
Anrufumleitung, Rufabfangen, u.a.) nicht ausreichen, bietet QSIG
die Generic Functional Procedures (QSIG GF). Diese standardisierte
Methode dient zum Transport von Nicht-Standard-Funktionen und zum Message-Handling
im QSIG-Netzwerk.
Folgende Standards beschreiben die
grundlegende Kommunikation bei QSIG, den sogenannten Basic Call:
ETS 300 172 Edition 3, ISO/IEC 11 572 Edition 2 und ECMA 143, 3rd
Edition. Die Standards für
Rufumleitung, die im Folgenden sogenannte Diversion sind beschrieben
in: ETS (European Telecommunications Standard) 300 257, Edition
1; ISO (International Standard Organisation)/IEC (International
Electrotechnical Commision) 13873, Edition 1 und ECMA (European
Computer Manufacturers Association) 174. Allgemeine Angaben können bei
QSIG im Teil Common Information abgelegt werden, welcher die Standards
umfaßt:
ETS 301 820:2000 und ISO/IEC 15 772:1998. Zusätzliche Leistungsmerkmale können im
QSIG Standard Generic Functions hinterlegt werden, welcher umfaßt: ETS
300 239, Edition 2, ISO/IEC 11 582, Edition 1 und ECMA 165.
Die angegebenen QSIG-Standards gestatten
es, die definierten Funktionen dann zu nutzen, wenn die beteiligten
Endgeräte
in Anlagen angeschaltet sind, die über QSIG-Leitungen oder QSIG-Wählverbindungen miteinander
verbunden sind. Diese QSIG-Funktionen können auch über QSIG-Wählverbindungen genutzt werden,
sobald der Betreiber des öffentlichen
Netzes ein Interworking mit QSIG zulässt. Bei dieser virtuellen Vernetzung
ist somit ein gebührenfreier
Aufbau möglich.
Kommt es dann zur Gesprächsverbindung,
ist diese gebührenpflichtig.
Standleitungen bzw. Festverbindungen erübrigen sich hiermit.
Der QSIG-Standard von Diversion kennt
eine Optimierung mit einer 'abschnittsweisen Wegeumschaltung', welche
im folgenden als Forward Switching bezeichnet wird. Dabei wird die
Served User PINX zur Rerouting PINX. Wird diese Rerouting-Anforderung von der
Originating PINX abgelehnt, weil diese beispielsweise den Service
nicht unterstützt,
so führt
die Served User PINX das Forward Switching (Rerouting) selbst durch.
Die ablehnende Anlage wird über
die Rufumleitung informiert.
Dieses Forward Switching kann auch
in der Served User PINX erzwungen werden, indem das Senden der Rerouting-Anforderung
unterdrückt
und die Rufumleitung unmittelbar selbst ausgeführt wird. In diesem Zusammenhang
ist aber eine 'Rufumleitung mit Entscheidung' ebenso wenig möglich wie
ein späteres
Auslösen der
Verbindung (Late Release).
Es ist Aufgabe der Erfindung, ein
Verfahren bereitzustellen, welches eine 'Rufumleitung mit Entscheidung'
in einem Netzverbund mit mindestens abschnittsweiser QSIG-Signalisierung
bei reduzierten Kosten ermöglicht.
Diese Aufgabe wird durch ein Verfahren
nach Anspruch 1 gelöst.
Ein wesentlicher Gedanke des erfindungsgemäßen Verfahrens
ist dass eine Rerouting-Anforderung in die Originating PINX über QSIG
geschickt wird und sich somit die rufenden TK-Anlage entscheiden
kann, ob ein erneuter Verbindungsaufbau zum Rufumleitungsziel stattfinden
soll. Dabei wird der erste Verbindungsaufbau grundsätzlich ausgelöst. Es findet
kein erneuter Verbindungsaufbau statt, wenn sich die rufende TK-Anlage
dazu entscheidet, das Rufumleitungsziel nicht erreichen zu wollen.
Damit wird das Merkmal 'Rufumleitung mit Entscheidung' in einem
QSIG-Netzverbund und einem virtuellen QSIG-Netzverbund nutzbar gemacht.
Das Verfahren baut auf den Generic
Functions (ETS 300239 ISO/IEC 11582, ECMA 165), dem ROSE(Remote
Operation Service Element)-Konzept (CCITTX.219/X.229), ASN.1 (X.208/X.209),
den Common Information (ETS 301 820: 2000, ISO/IEC 15772: 1998)
und Diversion (ETS 300 257, ISO/IEC 13873, ECMA 174) auf.
Das ROSE-Konzept definiert die Umgebung,
um zusätzliche
Funktionen zu realisieren. Es findet Anwendung bei den standardisierten
Supplementary Services, es wird aber auch zur Steuerung herstellerspezifischer
Supplementary Services eingesetzt. Die ROSE-Aktionen (RO-Invoke,
RO-Result, RO-Error, RO-Reject-U, RO-Reject-P) werden auf vier Protokollelemente
abgebildet. Solche Protokollelemente werden im Englischen als Application
Protocol Data Unit (APDU) bezeichnet. Die vier Proto kollelemente
sind: RO-Invoke, RO-Return-Result, RO-Return-Error, RO-Reject. Die
ROSE-Protokollelemente werden mittels des FACILITY-Informationselementes übertragen.
Das FACILITY-Informationselement wird entweder mit Basic-Calls,
d.h. Meldungen wie SETUP, ALERT, CONNECT, PROGRESS oder DISCONNECT übertragen
oder, falls keine Basic-Calls zur Verfügung stehen, mit der dann zu
verwendenden Meldung FACILITY. Es können mehrere ROSE-Protokollelemente
in einem FACILITY-Informationselement
enthalten sein.
Der Steuerparameter wird in der ersten
SETUP-Meldung und dort im Common Information Segment transportiert.
Damit wird beim ersten Verbindungsaufbau in der Meldung SETUP die
Information abgelegt, dass die gerufene TK-Anlage das Leistungsmerkmal
'Rufumleitung mit Entscheidung (RUE)' aktiviert hat. Diese Information
wird im Common Information Fach (CmnExtData: NetDevice: feature-list:
RUE) zur Serve User PINX transportiert. Dieses ist wiederum ein
Kriterium, um eine Rerouting-Anforderung in die Originating PINX über QSIG
ro schicken und sich somit die rufende TK-Anlage entscheiden kann,
ob ein erneuter Verbindungsaufbau zum Rufumleitungsziel stattfinden
soll. Der erste Verbindungsaufbau wird grundsätzlich ausgelöst, und es
findet kein erneuter Verbindungsaufbau statt, wenn sich die rufende
TK-Anlage dazu entscheidet, das Rufumleitungsziel nicht erreichen
zu wollen. Die Served User PINX wird mit einem DISC (disconnect)
ausgelöst und
der Vorgang ist beendet. Entscheidet sich die rufende TK-Anlage
jedoch für
einen erneuten Aufbau zum Rufumleitungsziel, wird die SETUP-Meldung
zur Diverted-to PINX geschickt. Weitere Abläufe entsprechen dem QSIG-Standard
für Diversion.
Die Generic Functions und ROSE gestatten
die Definition von Leistungsmerkmalen sowohl auf der Ebene der Standardisierung
als auch die Definition proprietärer
Merkmale. Das hier beschriebene Verfahren 'Rufumleitung mit Entscheidung'
im QSIG-Netzverbund stellt dabei ein proprietäres Merkmal dar. Gleichzeitig ergibt
sich eine Wegeoptimierung im QSIG-Netzverbund, wobei bei einer virtuellen
Verbindung (QSIG-Wählverbindungen) über das
Amt eine Kostenoptimierung hinzutritt, da hier noch Gebühren für einen
Zweitaufbau einer Verbindung eingespart werden können.
Von Vorteil ist es, wenn das alternative
Durchlaufen der Schritte b1 oder b2 des Anspruchs 1 aus der gerufenen
TK-Anlage heraus gesteuert wird. Dies wird zum einen durch den QSIG-Standard
unterstützt,
zum anderen wird eine einfache Prozessführung unter Ausschluss weiterer
TK-Anlagen oder beteiligter Endgeräte gewährleistet.
Bevorzugt wird eine ROSE Operation
in der ersten SETUP-Meldung und dort im Common Information Segment
transportiert. Diese ROSE-Operation ist herstellerspezifisch definiert,
kann aber netzwerkübergreifend
dort verwendet werden, wo Hersteller anderer TK-Anlagen den QSIG-Standard
in ihren Geräten
unterstützen.
In einer Domäne
müssen
deshalb mindestens die Originating PINX und damit die Rerouting
PINX und die Served User PINX dieser propietäre Lösung implementiert haben. Eine
Konfiguration zur Rufumleitungsentscheidungsmöglichkeit ist die Zusammenfassung
von der Originating PINX und Rerouting PINX.
Bevorzugt wird weiterhin die ROSE-Operation
in dem Facility-Informationselement abgelegt. Dies entspricht wiederum
dem QSIG-Standard und gewährleistet
eine Transparenz des Verfahrens auch in heterogener Umgebung, d.h. über Grenzen
privater und öffentlicher
Netze hinweg und zwischen Anlagen verschiedener Hersteller.
Insbesondere wird das Facility-Informationselement
mit der Codierung RejectAny-UnrecognizedOperation
verschickt wird. Damit wird erzwungen, dass die Served User PINX,
die das erfindungsgemäße Verfahren
nicht unterstützt,
eine Reject-APDU
zur Originating PINX schickt, was diese dann als Zurückweisung
der 'Rufumleitung mit Entscheidung' wertet. Damit werden auch die
TK-Anlagen in das erfindungsgemäße Verfahren
einbezogen, die dieses selbst nicht unterstützen.
In der Praxis wird die Kommunikationsstrecke
zwischen den TK-Anlagen in der Regel QSIG-Festverbindungen und/oder
Wählverbindungen
umfassen. Damit wird das erfindungsgemäße Verfahren sowohl in privaten
Netzen (Festverbindungen) als auch öffentlichen Netzen (Wählverbindungen)
nutzbar gemacht, wenn auch in den letzteren das QSIG-Protokoll durch
den entsprechenden Netzwerkbetreiber (carrier), wie z.B. ARCOR unterstützt wird.
Von besonderem Vorteil ist er, wenn
die Kommunikationsstrecke zwischen den TK-Anlagen ganz oder teilweise über QSIG-IP-Gateways
oder das Internet geführt
ist. Die genannten Gateways bieten dabei Zugänge zu weltverbreiteten Netzwerken,
womit das erfindungsgemäße Verfahren
für besonders
viele Nutzer erreichbar und damit nutzbar wird.
Die Rufziel-TK-Anlage kann identisch
mit der rufenden oder der gerufenen TK-Anlage sein. Unabhängig davon,
welche der beteiligten TK-Anlagen das Rufziel enthält, ist
damit eine entsprechende Flexibilität des erfindungsgemäßen Verfahrens
gewährleistet.
Zum Signalisieren von Meldungen über ISDN
werden ausschließlich
D-Kanal-Verbindungen genutzt, womit das erfindungsgemäße Verfahren
sowohl bei Verbindungen mit als auch ohne Nutzkanalbelegung (ISDN-B-Kanäle), also
als reine Signalisierungsverbindung, durchgeführt werden kann.
Im folgenden wird das erfindungsgemäße Verfahren
anhand eines Ausführungsbeispiels
näher erläutert. Es
zeigen:
1 den
erfindungsgemäßen Verfahrensablauf
anhand von zwischen den beteiligten TK-Anlagen ausgetauschten Meldungen
im Fall einer erfolgreich durchgeführten Rufumleitung mit Entscheidung;
2 das
erfindungsgemäße Verfahren
anhand der zwischen den beteiligten TK-Anlagen ausgetauschten Meldungen im
Fall ohne Rufumleitungsentscheidungsmöglichkeit; und
3 ein
QSIG-Protokollmodell als Blockschaltbild mit dem neuen Merkmal SS-Steuerung für Rufumleitung.
Die 1 zeigt
das erfindungsgemäße Verfahren
anhand der zwischen den beteiligten TK-Anlagen Originating und Rerouting
PINX 11, Served User PINX 12 und Diverted-to PINX 13 ausgetauschten
Meldungen im Falle einer erfolgreich durchgeführten Rufumleitung mit Entscheidung.
In dieser Konstellation wird angenommen, dass das Leistungsmerkmal
'Rufumleitung mit Entscheidung' (RUE) an der Originating PINX 11 aktiviert
ist.
Die in den ausgetauschten Meldungen
SETUP, FACILITY, ALERT und CONNECT im Zuge des Verfahrens übertragenen
ROSE-Operationen sind der entsprechenden Meldung jeweils unterhalb
des Richtungspfeils zugeordnet. Diese ROSE-Operationen sind: cmnInform.inv
(Invoke), callRerouting.inv (Invoke), callRerouting.rr (Return Result),
divertingLegInformation2.inv (Invoke) und divertingLegInformation3.inv
(Invoke).
Will ein Anrufer nun aus der Originating
PINX 11, also der rufenden TK-Anlage, eine Verbindung mit der
Served User PINX 12, also der gerufenen TK-Anlage, herstellen,
wird zunächst
beim ersten Verbindungsaufbau die Meldung SETUP an die Served User
PINX 12 geschickt. In dieser ist die Information abgelegt,
dass in der Originating PINX 11 das Leistungsmerkmal RUE
aktiviert ist. Diese Diversion-Information ist in der Common Information
(cmnInform.inv) und dort im Fach (CmnExtData: NetDevice: feature-list:
RUE) hinterlegt.
An der Served User PINX 12 wird
nun der Steuerparameter RUE ausgewertet und bei Vorliegen einer Rufumleitung,
im vorliegenden Fall von der Served User PINX 12 an die
Diverted-to PINX 13, eine Facility-Meldung mit Inhalt callRerouting.inv
zurückgegeben.
Diese Meldung wird von der Originating PINX mit der Meldung FACI-LITY und dem Inhalt
callRerouting.rr bestätigt.
Die Originating PINX 11 wird
nun zur Rerouting PINX 11 und löst die Verbindung mit der Meldung
DISC (disconnect) aus. Dies geschieht grundsätzlich, wenn das Leistungsmerkmal
RUE an der Originating PINX 11 unterstützt wird und eine Rufumleitung
an der Served User PINX 12 vorliegt.
Die Linie L markiert dabei den Status,
bei dem der Anrufer nun entscheiden kann, ob ein erneuter Verbindungsaufbau
zu der Diverted-to PINX 13, also der Rufziel-TK-Anlage stattfinden
soll oder nicht. Dies kann z.B. dann der Fall sein, wenn der Anrufer
mit der Rufumleitungsnummer alternativ zum eigentlich gewünschten Gesprächspartner
sein Sekretariat oder seine Vertretung erreichen kann. Ist dies
für den
Anrufer nicht von Interesse, kann er sich auch dafür entscheiden,
diese Rufumleitung nicht zu nutzen, d.h. keinen erneuten Verbindungsaufbau,
diesmal zur Diverted-to PINX 13 anzufordern.
Entscheidet er sich aber für eine Rufumleitung,
wird in einer weiteren SETUP-Meldung mit Inhalt divertingLegInformation2.inv
ein erster Verbindungsaufbauwunsch an die Diverted-to PINX 13 geschickt.
Ist die Diverted-to PINX 13 zum Verbindungsaufbau bereit,
schickt diese eine ALERT-Meldung, gefolgt von einer CONNECT-Meldung
mit Inhalt divertingLegInformation3.inv an die Originating und Rerouting
PINX 11 zurück. Damit
ist eine Gesprächsverbindung
auch zwischen der Originating bzw. Rerouting PINX 11 und
der Diverted-to PINX 13 aufgebaut.
Die 2 zeigt
den erfindungsgemäßen Verfahrensablauf
anhand der zwischen den beteiligten TK-Anlagen Originating PINX 11,
Served User PINX und Rerouting PINX 12 und Diverted-to
PINX 13 ausgetauschten Meldungen im Fall ohne Rufumleitungsentscheidungsmöglichkeit.
Es wird hier davon ausgegangen, dass das TK-Endgerät der Originating
PINX 11 das Leistungsmerkmal 'Rufumleitung mit Entscheidung'
nicht aktiviert hat.
Die in den Meldungen SETUP, FACILITY
und CONNECT im Zuge des Verfahrens übertragenen ROSE-Operationen
sind hier ebenfalls der entsprechenden Meldung jeweils unterhalb
des Richtungspfeils zugeordnet. Diese ROSE-Operationen sind: cmnInform.inv
(Invoke), divertingLegInformation1.inv (Invoke), divertingLegInformation2.inv
(Invoke) und divertingLegInformation3.inv (Invoke).
Wieder wird im ersten Verbindungsaufbau
eine SETUP-Meldung mit Inhalt cmnInform.inv an die Served User PINX 12 geschickt.
Diesmal ist im Fach (CmnExtData: NetDevice: feature-list: RUE) der
Steuerparameter RUE nicht gesetzt. Liegt nun ei ne Rufumleitung an
der Served User PINX 12 vor, wird diese zur Rerouting PINX 12 und
sendet direkt eine SETUP-Meldung mit Inhalt divertingLegInformation2.inv
an die Diverted-to PINX 13, welche das Rufziel enthält.
Ist die Diverted-to PINX 13 zum
Verbindungsaufbau bereit, sendet diese eine ALERT-Meldung an die Rerouting
PINX 12 zurück,
welche wiederum die Originating PINX 11 mit der FACILITY-Meldung
mit Inhalt diverting LegInformation1.inv über die Rufumleitung informiert.
In einer folgenden ALERT-Meldung signalisiert die Rerouting PINX 12 weiterhin
ihre Bereitschaft zum Verbindungsaufbau mit der Originating PINX 11. Schließlich wird
die Verbindung von der Diverted-to PINX 13 mittels einer
CONNECT-Meldung mit Inhalt divertingLegInformation3.inv zu der Rerouting
PINX 12 und schließlich
von dieser mittels einer CONNECT-Meldung mit Inhalt divertingLegInformation3.inv
zu der Originating PINX 11 hergestellt.
Damit ist für den Anrufer, welcher das
Leistungsmerkmal 'Rufumleitung mit Entscheidung' nicht aktiviert
hat, das Rufumleitungsziel in der Diverted-to PINX 13 aus
der Originating PINX 11 automatisch erreichbar.
Es ist also nicht zwingend erforderlich,
eine Rerouting-Anforderung in die Originating PINX 11 über QSIG
zu schicken, wenn diese die Funktionalität 'Rufumleitung mit Entscheidung'
nicht nutzt. Ist allerdings das Rufumleitungsziel in der Originating
PINX 11 zu finden, kann auch auf den in 1 gezeigten Verfahrensablauf zurückgegriffen
werden und die Rerouting-Anforderung in die Originating PINX 11 geschickt
werden. In diesem Fall würde
es Sinn machen, das Rerouting der Originating PINX 11 zu überlassen,
da sonst von der Served User PINX 12 ein Zweitaufbau gestartet
und dadurch eine zweite QSIG-Leistung benötigt werden würde. Im virtuellen
Netzverbund könnte
dies auch wiederum Gebühren
verursachen.
Ist das Rufumleitungsziel aber in
der Served User PINX 12 oder aber, wie beschrieben, in
der Diverted-to PINX 13 zu finden, ist eine Optimierung
mit einer Forward Switching zweckmäßig, wobei die Served User
PINX 12 zur Rerouting PINX 12 wird. Diese Optimierung
ist im QSIG-Netzverbund eine Wegeoptimierung, bei einer virtuellen
Verbindung (QSIG-Wählverbindungen) über das
Amt ergibt sich zusätzlich noch
ein Kostenvorteil, da hier noch Gebühren für den Zweitaufbau eingespart
werden können.
Das Rufumleitungsziel als Kriterium einer Wahlbewertung kann nur
in der Served User PINX 12 ausgewertet werden.
Die ROSE-Operation zur Steuerung
des Verfahrens in der Served User PINX 12 wird im Informationselement
Facility der SETUP-Meldung für
den ersten Verbindungsaufbau mit Inhalt cmnInformation.inv übertragen.
Dieses Facility-Informationselement wird mit der Kodierung SourceEntity:
EndPINX und DestinationEntity: End-PINX als Kodierung für die Network-Facility-Extension
verschickt. Die Kodierung des Facility-Informationselementes für die Interpretation-APDU
ist dabei mit RejectAnyUnrecognizedOperation gewählt.
In der folgenden Tabelle sind formal
die Inhalte der privaten Erweiterungen von Common Information (CMN)
aufgelistet. Die formale Definition legt nicht nur den Inhalt der
Signalisierung fest, sondern auch einen sogenannten Identifier,
der diese Signalisierungsinformation innerhalb von QSIG eindeutig
kennzeichnet (cmnInform::={newforgsig Cmn_Inform(12)}.
Hier findet sich auch der Speicherplatz
des Steuerparameters RUE im Fach CmnExtData: NetDevice: feature-list:
RUE.
3 zeigt
das QSIG-Protokollmodell als Blockschaltbild mit einer Koordinierungsfunktion
(Coordinate Function) 21, einer Rufsteuerung (Call Control) 22 und
einer Reihe von SS-Steuerungen (Supplementary Service Control) 23.
Das neue Merkmal 'Rufumleitung mit Entscheidung' wird aus der SS-Steuerung
für Rufumleitung 23' gesteuert.
Zur Kennung dienen weitere Service-Elemente
wie ROSE (Remote Operation Service Element), ACSE (Access Control
and Signalling Element) und DSE (Distributed Systems Environment).
Das erfindungsgemäße Rufumleitungsverfahren 23' ist
mit der Koordinierungsfunktion 21 verbunden, über welche
die SS-Steuerung für
Diversion 23' die Dienste von ROSE nutzt. Die Koordinierungsfunktion 21 ist
weiterhin mit der GFT-Steuerung (Generic Functional Transport Control) 24 verbunden.
Die GFT-Steuerung 24 zeigt
zwei Arten von Diensten. Zum einen die Transportdienstleistung für Protokollelemente
zwischen Funktionen, die auf verschiedenen TK-Anlagen ablaufen,
und zum anderen den Aufbau und Abbau von Verbindungen ohne Nutzkanalbelegung,
welches Signalisierungsverbindungen sind. Die GFT-Steuerung 24 ist
mit einer Protokollsteuerung (Protocol Control) 25 verbunden,
die die Übertragung
von Protokoll-Elementen zwischen benachbarten TK-Anlagen leistet
und den Aufbau und Abbau von Signalisierungsverbindungen zwischen
benachbarten TK-Anlagen. Auch die Rufsteuerung (Call Control) 22 ist
mit der Koordinierungsfunktion 21 und der Protokollsteuerung
(Protocol Control) 25 verbunden. Die Protokollsteuerung 25 übergibt
bzw. empfängt
Daten. Der Signalling Carriage Mechanism (SCM) 26, also
der Signalisierungsmechanismus, gibt dann die Meldungen auf eine
Leitung 27 oder empfängt
sie von der Leitung 27.
An dieser Stelle sei darauf hingewiesen,
dass alle oben beschriebenen Teile für sich alleine gesehen und
in jeder Kombination, insbesondere die in den Zeichnungen dargestellte
Details als erfindungswesentlich beansprucht werden. Abänderungen
hiervon sind dem Fachmann geläufig.