-
Die
vorliegende Erfindung bezieht sich auf den Bereich der Kommunikationsnetze
und insbesondere auf Netze zur Beförderung der Sprache, umfassend
ein oder mehrere Unternetze mit Leitungsschaltung und ein oder mehrere
Unternetze zur Übertragung
von Paketen mit Gateway-Schnittstellen
für ihre
gegenseitigen Verbindungen.
-
Die
Entwicklung des Internet-Netzes hat stark zum Erscheinen und dann
zur Ausdehnung von Telekommunikationsdiensten beigetragen, die dafür vorgesehen
sind, entsprechend der Protokollfolge dieses Netzes zu arbeiten,
und zwar insbesondere gemäß dem Netzwerkschichtprotokoll
IP ("Internetprotokoll", Request for Comments
(RFC) 760, Internet Engineering Task Force (IETF), Januar 1980).
-
Die
Fernsprechdienste, die zunächst
um Leitungsschalttechniken herum entwickelt wurden und dann vor
kürzerer
Zeit auf IP-Netzen vorgeschlagen wurden, sind ein Beispiel dieser
Erneuerung. Man entwirft heute leistungsstarke integrierte Netze,
die Dienste zur Beförderung
der Sprache und Daten anbieten, die vollständig nach dem IP-Protokoll arbeiten.
-
Die
zugrunde liegenden wirtschaftlichen und technischen Anforderungen
verlangen jedoch eine Entwicklungsweise ohne Bruch, so dass ein
Technologiesprung vernünftigerweise
nicht in Betracht kommen kann. Es ist ein Zwischenschritt in Betracht
zu ziehen, während
dessen sich heterogene Netze entwickeln, die sich aus der Verbindung
von herkömmlichen
Vermittlungsstellennetze (PABX, "Private
Automatic Branch eXchange")
mit ganz nach dem IP-Protokoll arbeitenden Netzen ergeben. Eine
Architektur, die die Entfaltung der IP-Telefoniedienste gestatten, ist
in der Schrift "An
architecture for residential Internet telephony service", HUITEMA C et al.
(IEEE NETWORKS, IEEE INC, vol. 23, Nr. 3, Mai 1999) beschrieben.
-
Derartige
heterogene Netze können
beispielsweise ein oder mehrere örtliche
Netze umfassen (LAN, "Local
Area Networks"),
die nach dem IP-Protokoll arbeiten und die mit einem oder mehreren
herkömmlichen
PABX-Netzen verbunden sind, die ein so genanntes "Multi-Sites"-Netz bilden.
-
In
ein PABX-Netz ist im Allgemeinen eine Einheit von Fernsprechanwendungen
integriert, und zwar unter anderem eine Anwendung der Supervision
der Verbindungswege. Für
jeden Verbindungsweg, der von der Topologie des Netzes zugelassen wird,
bestimmt eine solche Anwendung in Abhängigkeit von Daten der topologischen
Beschreibung des Netzes, zu denen sie Zugang hat, und von der Kommunikation
zugeordneten Eingangsparametern, einen Verbindungsweg, der anschließend reserviert und
dann verwendet werden kann.
-
Die
Bestimmung eines solchen Wegs, genauer gesagt die Wahl der topologischen
Knoten, die längs
des Wegs aufeinander folgen, findet vorzugsweise unabhängig von
der verwendeten Technologie statt, um jeweils diese Knoten verbindende
Arterien zu bilden. Der Prozess steigt nicht unter die Netzschicht
in dem OSI-Bezugsmodell. Beispielsweise macht es für die Anwendung
der Supervision der Verbindungswege keinen Unterschied, ob der Weg
zwischen zwei Knoten einen MIC-Weg mit 64 kbit/s oder einen LAN
unter IP wählt).
Dann übernimmt
es ein Verbindungsschichtprozess, den Verbindungsweg einzusetzen,
d.h. die geeigneten Ressourcen längs des
bestimmten Wegs zu reservieren und die Verwendung dieser Ressourcen
zu verwalten.
-
Bei
der Konfigurierung des PABX-Netzes gestattet eine Netzverwaltungssoftware,
die Arterien zu deklarieren, die einen Verkehr von einem bestimmten Typ
transportieren können.
Die Parameter dieser Deklarierung umfassen insbesondere den Arterientyp, die
entsprechenden topologischen Knoten, die Transportparameter des
Sprachverkehrs (insbesondere die Codierungsgesetze) usw.. Die Topologie
des PABX-Netzes ist also bei mindestens manchen der Anwendungen
des Netzes bekannt, insbesondere Anwendungen der Supervision und
des Einsatzes der Verbindungswege.
-
Diese
Intelligenz fehlt bei den Netzen, die nach dem IP-Protokoll arbeiten.
In einem solchen Netz findet nämlich
das Routing der Datagramme, gleichgültig, ob sie Sprache befördern oder
nicht, über
interne Mechanismen des Netzes statt, die nicht mit den Kundenanwendungen
interagieren, um den von jedem Paket eingeschlagenen Weg zu bestimmen.
Nur der IP-Adresse des Empfängers
wird Rechnung getragen. Das RSVP-Protokoll ("Resource ReSerVation Protocol", RFC 2205, IETF,
Sept. 1997), das dazu bestimmt ist, die den Nutzern von IP-Netzen
gebotene Dienstqualität
zu erhöhen,
bringt keine Änderung,
da es sich auf die IP-Routingmechanismen
stützt,
und bleibt ein Werkzeug des IP-Netzes, und zwar im Gegensatz zu
den PABX-Netzen, in die spezifisch Werkzeuge zur Supervision und
zum Einsatz der Wege integriert sind.
-
Der
Erfolg der IP-Netze hat zur Entwicklung von Anwendungen für den Transport
der Sprache auf IP-Netzen geführt,
die auf die Dauer den Ersatz der herkömmlichen PABX-Netze durch Multidienst-IP-Netze
erkennen lassen. Die Mehrheit der Entwickler untersucht Systeme,
die vollständig
nach dem IP-Protokoll arbeiten. Die Lösungen, die für die heterogenen
Netze bestimmt sind, die zu einem Teil aus einem oder mehreren Netzen
zur Übertragung gemäß dem IP- Protokoll und zum
anderen Teil aus einem oder mehreren PABX-Netzen bestehen, sind wenig
untersucht.
-
Ein
Ziel der vorliegenden Erfindung ist es, die Interaktion zwischen
den verschiedenen Netztypen, aus denen sich ein heterogenes Kommunikationsnetz
zusammensetzt, zu verbessern, um die Verwendung der globalen Ressourcen
des Netzes zu optimieren.
-
Zu
diesem Zweck schlägt
die Erfindung, ein Verfahren zum Aufbau von Verbindungswegen zwischen
Zugriffspunkten eines Kommunikationssystems vor, wobei das Kommunikationssystem
umfasst: mindestens ein Netz zur Übertragung von Paketen, das
eine erste Familie von Zugriffspunkten verschafft, Schaltmittel,
die mit Verbindungsschnittstellen, die eine zweite Familie von Zugriffspunkten verschaffen,
und mit mindestens einer Gateway-Schnittstelle mit dem Netz zur Übertragung
von Paketen ausgerüstet
sind, Rufverarbeitungsmittel, die mindestens einen Rufserver einschließen, um Konfigurierungs-
und Kontextdaten zu speichern, die Terminals betreffen, die mit
dem System durch die Zugriffspunkte verbunden sind, und um diese
Terminals betreffende Signalisierungsbehandlungen auszuführen, und
mindestens einen Konfigurationsverwalter, der mit den Rufverarbeitungsmitteln
zusammenarbeitet, um einen Verbindungswegaufbaumodus aus einem ersten
Modus, der von Mechanismen des Netzes zur Übertragung von Paketen gesteuert wird,
und einem zweiten Modus auszuwählen,
der von Mechanismen der Schaltmittel gesteuert wird. Die Mechanismen
der den zweiten Modus steuernden Schaltmittel werten vordefinierte
Daten aus, die eine Topologie des Kommunikationssystems beschreiben,
die aus zu den Schaltmitteln gehörenden topologischen
Knoten und topologischen Wegen zusammengesetzt ist, die im Inneren
der Schaltmit tel zwischen Paaren von topologischen Knoten zugelassen
sind. Man ordnet jedem Zugriffspunkt einen jeweilig zu den Schaltmitteln
gehörenden
topologischen Bezugsknoten zu, so dass der topologische Bezugsknoten
jedes Zugriffspunkts der zweiten Familie von diesem Zugriffspunkt
aus zugänglich
ist, ohne über
das Netz zur Übertragung
von Paketen zu gehen. Der Aufbau eines Verbindungswegs zwischen
Zugriffspunkten, um erste und zweite Terminals, die jeweils mit
diesen Zugriffspunkten verbunden sind, in Verbindung zu setzen,
umfasst die folgenden Schritte:
- – Schaffung
einer ersten Rufverarbeitungsaufgabe in einem dem ersten Terminal
zugeordneten Rufserver;
- – Bildung,
durch die erste Rufverarbeitungsaufgabe, einer Aufbaumitteilung,
die mindestens eine Nummer des ersten Terminals, eine Angabe der Familie
des Zugriffspunkts, mit dem der erste Terminal verbunden ist, und
den topologischen Bezugsknoten dieses Zugriffspunkts einschließt;
- – als
Antwort auf den Empfang dieser Aufbaumitteilung Schaffung einer
zweiten Rufverarbeitungsaufgabe in einem dem zweiten Terminal zugeordneten
Rufserver; und
- – Abfrage
des Topologieservers durch die zweite Rufverarbeitungsaufgabe auf
der Basis der Familien und der topologischen Bezugsknoten der Zugriffspunkte,
mit denen der erste und der zweite Terminal jeweilig verbunden sind,
um Rufkonfigurierungsdaten zu erhalten, die den für den Verbindungsweg
zwischen diesen Zugriffspunkten gewählten Aufbaumodus angeben.
-
Auf
diese Weise kann die Kenntnis der Topologie eines PABX-Netzes durch
den Verwalter des Systems im Maßstab
des heterogenen Systems gemäß der Erfindung
zweckmäßig ausgewertet
werden. Der Verwalter verfügt über eine
große Elastizität, um seine
bestehende Anlage, die im Allgemeinen aus herkömmlichen PABX entsteht, sich
entwickeln zu lassen, indem hier nach dem IP-Protokoll arbeitende
Unternetze hinzugefügt
werden. Er kann sein System so konfigurieren, dass die Mechanismen
für Wegaufbau
und -supervision der PABX-Welt oder für diejenigen der IP-Welt verwendet
werden können.
So kann er auch die progressive Entwicklung seiner Anlage in Richtung
einer IP-Architektur
ins Auge fassen.
-
Insbesondere
können
die Mechanismen des ersten Modus (PABX) in manchen Rufkonfigurationen
selektiv privilegiert werden, indem in der Topologie mindestens
ein topologischer Weg zwischen zwei topologischen Knoten mit einem
Abschnitt, der zum Netz zur Übertragung
von Paketen gehört,
zugelassen wird, während
mindestens ein anderer topologischer Weg zwischen zwei topologischen
Knoten mit einem Abschnitt, der zu dem Netz zur Übertragung von Paketen gehört, nicht
zugelassen ist, um die Mechanismen des ersten Modus IP zwischen
den Terminals zu privilegieren, die mit den den letztgenannten Knoten
zugeordneten Zugriffspunkten verbunden sind.
-
Ein
anderer Aspekt der vorliegenden Erfindung bezieht sich auf ein Kommunikationssystem, umfassend
ein Netz zur Übertragung
von Paketen, das eine erste Familie von Zugriffspunkten verschafft,
Schaltmittel, die mit Verbindungsschnittstellen, die eine zweite
Familie von Zugriffspunkten verschaffen, und mindestens eine Gateway-Schnittstelle mit
dem Netz zur Übertragung
von Paketen ausgerüstet
ist, Mittel zur Rufverarbeitung, um Konfigurierungs- und Kontextdaten
zu speichern, die mit dem System über die Zugriffspunkte verbundene
Terminals betreffen, und um diese Terminals betreffende Signalisierungs verarbeitungen
durchzuführen,
und mindestens einen Konfigurationsverwalter, der mit den Rufverarbeitungsmitteln
gemäß einem
Verfahren, wie es oben definiert wurde, zusammenwirkt, um einen
Verbindungswegaufbaumodus aus einem ersten Modus, der durch Mechanismen
des Netzes zur Übertragung
von Paketen gesteuert wird, und einem zweiten Modus, der durch Mechanismen
der Schaltmittel gesteuert wird, auszuwählen.
-
Weitere
Merkmale und Vorteile der Erfindung ergeben sich aus der nachstehenden
Beschreibung von nicht begrenzenden Ausführungsbeispielen unter Bezugnahme
auf die beiliegende Zeichnung. In dieser zeigen:
-
1 ein
Schema eines erfindungsgemäßen Kommunikationssystems,
-
2 eine
Darstellung des Signalisationsflusses bei dem Aufbau eines Rufs
zwischen zwei Terminals gemäß der Erfindung,
-
3 und 4 Organigramme
von Verfahren, die von einem erfindungsgemäßen Topologieserver ausführbar sind.
-
1 zeigt
zur Veranschaulichung ein Beispiel eines Kommunikationssystems,
das ein Leitungsvermittlungsnetz 1 umfasst, das aus vier
Vermittlungseinrichtungen (PABX) 10, 20, 30, 50 besteht.
Jedes PABX hat eine clusterförmige
Organisation. Es umfasst auf diese Weise eine oder mehrere Clusterkontrolleinheiten
(UCG) 11–12, 21–23, 31–33, 51,
die jeweils eine Einheit von Zugriffspunkten zum System aufweisen.
Die Zugriffspunkte können
je nach den gewünschten
Kompatibilitäten
des Systems als Schnittstel le mit verschiedenen Typen von Leitungen
dienen. Man kann insbesondere Zugriffspunkte für den Anschluss von gebräuchlichen
Fernsprechterminals 60–62,
analogen Terminals (einfache Terminals S63 oder "intelligente" Terminals) oder digitalen Terminals
(Terminals X.25, RNIS...) vorsehen. Um gegebenenfalls Kommunikationen
mit Mobilterminals 63 (beispielsweise CT2 oder DECT) zu gestatten,
können
manche der UCG Funkzugriffspunkte aufweisen, die mit Funkanschlüssen 64 bzw. 65 verbunden
sind.
-
Jede
UCT besitzt ausreichende Ressourcen, um die Kommunikationen zwischen
ihren eigenen Zugriffspunkten zu stützen, insbesondere einen Rufserver.
-
Jeder
PABX 10, 20, 30, der mehrere UCG umfasst,
ist mit einer Transportschleife 14, 24, 34 ausgerüstet, die
die Austausche zwischen UCGs gestattet, so dass die Kommunikationen
zwischen mehreren zu diesem PABX gehörenden Zugriffspunkten gestützt werden.
Beispielsweise kann die Schleife 14, 24, 34 eine
digitale Leitung mit 40 Mbit/s sein, die in geteilter Zeit organisiert
ist, um 512 Leitungsvermittlungskanäle ("Leitungskanäle") und 70 Paketvermittlungskanäle ("Paketkanäle") zu tragen. Die
Leitungskanäle
sind für
die Zugriffspunkte vorgesehen, deren Betrieb die Reservierung einer
Leitungsressource verlangt, während
die Paketkanäle
für die
Zugriffspunkte vorgesehen sind, die durch Paketvermittlungskommunikationen
verwendet werden, sowie für die
Austausche von Steuerungen des Vermittlungssystems selbst (insbesondere
die Signalisierungsfunktionen). Die nicht dargestellten Steuereinheiten sind
in den PABX 10, 20, 30 vorgesehen, um
den Betrieb der Beförderungsschleifen 14, 24, 34 zu
supervisieren.
-
Wenn
das System mehrere PABX umfasst, sind eventuell Inter-PABX-Leitungen 70–72, 74 (beispielsweise
private oder an einen öffentlichen
Operator vermietete MIC-Leitungen) zwischen manchen ihrer UCG 12, 22, 31, 33, 51 vorgesehen.
-
Bei
dem dargestellten Beispiel arbeitet das PABX-Netz 1 mit
zwei lokalen Netzen (LAN) 2, 3 zusammen, die das
IP-Protokoll stützen. Dieses
bildet ein heterogenes Gesamtnetz: die LAN, die Pakete übertragen,
koexistieren mit den PABX, die zumindest was den Sprachverkehr betrifft,
Leitungen schalten.
-
Der
PABX 10 ist mit dem LAN 2 über einen Zugriffspunkt seines
UCG 11 verbunden. Derartige UCG, Gateway-UCG genannt, sind
mit einer oder mehreren Gateway-Schnittstellen
versehen, die jeweils eine bestimmte Adresse in dem IP-Netz haben. Die
Verbindung zwischen den Netzen 1 und 3 ist mit Hilfe
von Gateway-Schnittstellen 54, 55 (GW) ausgeführt, die
mit den UCG 23, 51 verbunden sind. Diese Gateway-Schnittstellen 54, 55 befinden
sich außerhalb
der UCG 23, 51, sind jedoch funktionell denjenigen ähnlich,
die dem UCG 11 eingegliedert sind. Sie entsprechen beispielsweise
der Norm H.323 der UIT-T. Die Arbeitsweise der Gateways H.323 wurde während der
Arbeiten des Projekts TIPHON ("Telecommunications
and Internet Protocol Harmonisation Over Networks") der ETSI ("European Telecommunication
Standard Institute")
spezifiziert. Das Modell H.323 definiert drei Einheiten: den Gatekeeper,
das Gateway oder GW und den Terminal. Die Funktionen des Gateways
von H.323 sind auf drei Module verteilt: das Signalisierungsgateway
("Signalling Gateway" oder SG), das Media-Gateway
("Media GateWay" oder MGW) und der
Media-Gateway-Controller oder MGC. Das Media-Gateway wandelt von
einem ersten Netztyp kommende Ströme in ein For mat um, das einem
zweiten Netztyp entspricht. Die Signalisierungsbehandlungen, die
den Aufbau einer Verbindung durch das Media-Gateway betreffen, werden von
dem Gateway-Controller MGC ausgeführt.
-
Verschiedene
Terminals 66, 67, 69, "IP-Terminals" genannt, sind direkt
mit den LAN 2, 3 verbunden und werden durch zwei
jeweils mit den LAN 2, 3 verbundene Rufserver 52, 53 verwaltet.
Die Rufserver 52, 53 können nach standardisierten
Protokollen arbeiten, beispielsweise gemäß der Norm H.323. Ein IP-Terminal
ist beispielsweise ein Fernsprechterminal 66, 69,
in den eine IP-Schnittstelle integriert ist, oder ein Mikrorechner 67,
der eine Fernsprechanwendung auf IP-Netz ausführt, beispielsweise vom Typ
Operator.
-
Auf
an sich bekannte Weise können
die gebräuchlichen
Terminals 68, 75–77, 79 mit
den LAN 2, 3 über
Media-Gateways (MGW) 81–84 verbunden sein,
die gegebenenfalls durch Media-Gateway-Controller (MGC) (in 1 nicht
dargestellt) gesteuert werden, die Protokolle wie Megaco stützen (vgl. "Megaco Protocol", Internet Draft,
IETF, 21. Februar 2000). Diese Terminals sind beispielsweise vom
Typ S.63 (68, 75) oder RNIS (76, 79)
oder drahtlose Terminals (77), die über Funkanschlüsse 78, 85 angeschlossen
werden, die mit manchen MGW 81, 84 verbunden sind.
Obwohl dies nicht obligatorisch ist, ist es vorteilhaft, wenn diese
gebräuchlichen
Terminals 68, 75–77, 79 durch
die mit dem LAN verbundenen Rufserver 52, 53 verwaltet
werden.
-
Ein
MGW 81–84 ist
in der Lage, Leitungen zwischen den gebräuchlichen Terminals zu schalten, die
mit ihm direkt verbunden sind. Die Definitionslogik der Wege zwischen diesen
gebräuchlichen
Terminals ist also denen, die im PABX-Netz gültig sind, näher als
diejenigen des IP-Netzes 2, 3 (Beförderung
von Datagrammen vom Typ "best
effort"). Bei der
Konfiguration des Systems unterscheidet man zwei Familien von Zugriffspunkten:
- – Die "klassischen" Zugriffspunkte,
die von UCG 11–12, 21–23, 31–33, 51 und
von den MGW 81–84 geboten
werden, mit denen klassische Terminals 60–63, 68, 75–77, 79 verbunden
sind. Die Mechanismen der Supervision und des Einsatzes der in den
PAX 10, 20, 30, 50 vorgesehenen
Kommunikationswege sind gewöhnlich
auf diese Zugriffspunkte anwendbar;
- – Die
von den LAN 2, 3 gebotenen IP-Zugriffspunkte,
mit denen die IP-Terminals 66, 67, 69 verbunden
sind. Auf Höhe
dieser Zugriffspunkte sind es die zum IP-Netz gehörenden Mechanismen (IP-Routing,
gegebenenfalls RSVP, H.323/TCP/IP), die den Aufbau der Kommunikationswege
gestatten.
-
Beispielsweise
wird die Signalisierung auf dem IP-Netz gemäß der Norm UIT-T H.323 in Sessions
des Transportprotokolls TCP übertragen,
die zwischen zwei Rufservern oder zwischen einem IP-Terminal und
seinem Rufserver erstellt werden.
-
Für die codierte
Sprachübertragung
auf den IP-Unternetzen 2, 3 verwendet man, wie
es üblich
ist, das Transportprotokoll UDP ("User Datagram Protocol", RFC 768, IETF,
August 1980) oder die Echtzeitprotokolle RTP und RTCP. Verschiedene
Sprachcodierung/-decodierungs-Arten können von den IP-Terminals 66, 67, 69 verwendet
werden. Im Falle von H.323 kann die Audiocodierung gemäß einer
der Empfehlungen G.711, G.722, G.723.1, G.728 und G.729 von UIT-T
sein.
-
Jeder
Rufserver des Systems verwaltet eine Einheit von Kundenterminals.
Jeder Kunde verfügt über Informationen
zur Identifikation des ihm zugeordneten Rufservers, an den er seine
Anfragen richtet.
-
Ein
direkt mit einem LAN 2, 3 verbundener IP-Terminal 66, 67, 69 kennt
a priori nur die IP-Adresse seines Rufservers 52, 53 oder
eines Gateways (Gatekeeper H.323), das ihm gestattet, diesen Server
zu erreichen, wenn dieser in dem PABX-Netz 1 gelegen ist.
-
Ein
an das PABX-Netz angeschlossener klassischer Terminal kennt seinerseits
einen UCG ("Bezugs-UCG"), der den zugeordneten
Rufserver immer erreichen kann und in den dieser eingegliedert ist.
Dieser Bezugs-UCG ist vorteilhafterweise als derjenige gewählt, mit
dem der Terminal direkt verbunden ist (andernfalls, insbesondere
wenn es sich um einen mobilen Terminal 63 handelt, kann
er ihn über Paketkanäle des PABX-Netzes
erreichen).
-
Der
Rufserver, der einem gebräuchlichen Terminal 68, 75–77, 79 zugeordnet
ist, der über
einen MGW 81–84 mit
einem LAN 2, 3 verbunden ist, kann (i) in diesem
MGW gelegen sein (wenn dieser solche Funktionalitäten besitzt),
(ii) ein Server 52, 53 des LAN sein oder (iii)
in einem UCG des Multi-Sites-Netzes 1 befindlich sein.
Im Fall (i) greift der Terminal direkt auf seinen Rufserver zu.
In den Fällen
(ii) und (iii) übernimmt
der MGW es, die ihn betreffende Signalisierung von und zu dem Rufserver
gegebenenfalls über
einen MGC und/oder einen Gateway 54, 55 abzulösen.
-
Der
Begriff topologischer Knoten eines Netzes entspricht im Allgemeinen
einer körperlichen
Einrichtung, mit der mindestens eine körperliche Führung (körperliches Kabel, optische
Faser, Luftschnittstelle usw.) verbunden ist, auf der ein Kommunikationsfluss
fließen
kann. Eine topologische Verbindung entspricht einer körperlichen
Führung,
auf der ein Kommunikationsfluss zwischen zwei Endknoten fließen kann.
Zwei topologische Knoten werden "benachbart" genannt, wenn sie
durch eine topologische Verbindung direkt verbunden sind, ohne der
Zwischenschaltung eines zusätzlichen
topologischen Knotens. Ein topologischer Weg zwischen zwei nicht notwendigerweise
benachbarten topologischen Endknoten besteht in einer Folge von
topologischen Verbindungen, die es gestatten, diese Knoten Schritt
für Schritt
zu verbinden. Zwei verschiedene topologische Knoten werden "zusammenhängend" genannt, wenn mindestens
ein topologischer Weg besteht, von dem sie die Endknoten sind.
-
Die
Anwendungen des PABX-Netzes 1, die mit der Supervision
und dem Einsatz der Kommunikationswege betraut sind, benutzen eine
durch Konfigurierung des Systems definierte Topologie, die aus Knoten,
Verbindungen und topologischen Wegen besteht. Bei einer typischen
Ausführung
sind die bei der Konfigurierung des Systems betrachteten topologischen
Knoten des Netzes 1 UCG (sie könnten aber auch PABX oder Schnittstellen
sein).
-
Die
Erfindung sieht vor, als topologische Knoten Einrichtungen zu deklarieren,
die von dem PABX-Netz nur über
das IP-Netz zugänglich
sind, obwohl der Verwalter des Netzes 1 a priori keine
Kenntnis von der Topologie der LAN 2, 3 hat. Diese
Einrichtungen sind typischerweise die MGW 81– 84,
die den mit ihnen verbundenen Terminals einen Dienst vom Typ Leitung
gewährleisten.
-
Topologische
Wege, von denen ein Endknoten aus einem MGW 81–84 besteht,
können
auf diese Weise in der Topologie zugelassen werden, die von den
Anwendungen der Supervision und des Einsatzes der Kommunikationswege
des PABX-Netzes berücksichtigt
werden.
-
Dagegen
wird es allgemein vorgezogen, topologische Wege zwischen zwei miteinander
direkt durch einen LAN verbundenen MGW nicht zuzulassen, da die
IP-Mechanismen an die Rufe, die sie beide ins Spiel bringen, gut
angepasst sind.
-
Topologische
Wege zwischen zwei MGW können
jedoch insbesondere in dem besonderen Fall (der nicht der häufigste
ist) zugelassen werden, indem das IP-Netz mehrere nicht zusammenhängende Unternetze
(LAN) umfasst. Im Fall von 1 wird es beispielsweise
vorgezogen, keinen topologischen Weg zwischen den MGW 81 und 84 und
auch nicht zwischen den MGW 82 und 83 zuzulassen,
während es
vorzuziehen ist, einen topologischen Weg zwischen den MGW 82 (oder 83)
und 81 (oder 84) zuzulassen. Der Verwalter des
Systems verfügt über eine große Flexibilität in der
Bildung dieser Wege.
-
Erfindungsgemäß ist jeder
Zugriffspunkt des Systems einem topologischen Knoten eines PABX-Netzes,
topologischer Bezugsknoten genannt, zugeordnet.
-
Jeder "klassische" Zugriffspunkt des PABX-Netzes 1 ist
vorteilhafterweise dem topologischen Bezugsknoten, der seinem UCG
entspricht, zugeordnet. Beispielsweise sind die UCG 11, 21, 32 und 33 die
topologischen Bezugsknoten der Zugriffspunkte, mit denen die Terminals 60, 62, 63 und 61 jeweilig
verbunden sind.
-
Ebenso
sind die anderen klassischen Zugriffspunkte, die von dem mit dem
LAN 2, 3 verbundenen MGW 81–84 gebildet
werden, den diesen MGW 81–84 jeweils entsprechenden
topologischen Bezugsknoten zugeordnet. Mit anderen Worten, jede Media-Gateway-Vorrichtung
(MGW) des Systems wird als ein topologischer Knoten des Netzes 1 betrachtet
und wird als topologischer Bezugsknoten seiner Zugriffspunkte deklariert.
-
Bei
einem Zugriffspunkt für
einen direkten Zugriff auf einen LAN, an den ein IP-Terminal 66, 67, 69 angeschlossen
ist, kann der topologische Bezugsknoten ein MGW sein, der mit demselben
LAN verbunden ist und vorteilhafterweise in Nähe des Zugriffspunktes gelegen
ist. Dieser topologische Bezugsknoten kann auch ein UCG des Netzes 1 sein, der
mit einem Gateway mit demselben LAN ausgerüstet ist. Insbesondere wenn
der Rufserver eines IP-Terminals einem Rufserver eines Gateway-UCG 11 entspricht,
ist es vorteilhaft, wenn dieser der topologische Bezugsknoten des
Zugriffspunktes dieses Terminals ist.
-
Die
Entsprechung zwischen jedem Zugriffspunkt, mit dem ein Terminal
des Systems verbunden ist, und seinem topologischen Bezugsknoten
ist eine der Daten, die für
den Terminal in seinem Rufserver beispielsweise mit Hilfe einer
Entsprechungstafel ("Look-Up-Table") gespeichert sind.
Dies gestattet es zu vermeiden, dass die Terminals Daten, die den
topologischen Bezugsknoten ihrer Zugriffspunkte betreffen, kennen
müssen.
-
Bei
dem in 1 dargestellten Beispiel umfasst das System zwei
Topologieserver 90, von denen der eine mit einem Zugriffspunkt
des UCG 11 des PABX 10 und der andere direkt mit
dem LAN-Netz 3 verbunden ist. Diese beiden Server enthalten
im Wesentlichen dieselben Daten und sie führen dieselben weiter unten
beschriebenen Prozeduren aus, wobei je nach dem Rufserver, der ihn
abfragt, der eine oder der andere abgefragt wird. Es sei bemerkt,
dass auch zahlreiche andere Implementierungen möglich sind, d.h. man kann beispielsweise
einen einzigen Topologieserver vorsehen, der von der Gesamtheit
des Systems aus zugänglich
ist, oder einen Topologieserver für jedes Unternetz 1, 2, 3,
oder man kann den Topologieserver in Form von Tafeln ausführen, die
einfach in jedem Rufserver gespeichert sind, der ihn abfragen kann.
-
In
dem besonderen Fall, in dem das IP-Netz 2, 3 nicht
vollständig
zusammenhängend
ist (wie in 1), enthält der Topologieserver 90 außerdem eine
Tafel mit doppeltem Eingang, "Tafel
der IP-Wege" genannt,
in der IP-Adressenpaare
von Terminals und Gateways festgehalten sind, zwischen denen ein Kommunikationsweg
besteht, der ganz von dem IP-Teil des Systems gestützt ist.
Vorteilhafterweise verwendet man den Begriff Gemeinschaft, der als eine
Einheit von IP-Adressen definiert wird. Dies gestattet es, die Maße der Tafel
der IP-Wege zu begrenzen, die nun Paare von Gemeinschaften enthält. Im Beispiel
von 1 kann man auf diese Weise zwei Gemeinschaften
definieren, deren jede aus den IP-Adressen der LAN 2 und 3 besteht.
-
Der
Aufbau eines Telefonrufs zwischen zwei Teilnehmerterminals wird
durch eine Rufsignalisierungsphase initiali siert, in deren Verlauf
der Weg, den die Sprachsignale nehmen, bestimmt wird.
-
Im
Diagramm von 2 werden die einen Terminal
betreffenden Signalisierungsverarbeitungen (Rufhälfte) durch eine Rufverarbeitungsaufgabe (TAP)
verwaltet, die von dem Rufserver des Terminals ausgeführt wird.
Der linke Teil jedes Diagramms entspricht der rufenden Rufhälfte und
der rechte Teil der gerufenen Rufhälfte.
-
Die
Rufsignalisierung beginnt mit einem Informationsaustausch zwischen
dem rufenden Terminal 110 und der Rufverarbeitungsaufgabe 111,
die ihm entspricht. Diese Aufgabe 111 wurde beispielsweise
von dem Rufserver des rufenden Terminals 110 bei Empfang
einer Meldung geschaffen, die das Zugreifen dieses Terminals auf
die Leitung signalisiert. Sie adressiert an dem Terminal die Testsignale, die
die dem Benutzer zuzuleitenden Informationen codieren (Anzeigen,
Töne, ...)
und gewinnt die vom Benutzer gelieferten Daten, um seine Anfrage
zu definieren (Funktionswahl, Nummernwahl, ...). Wenn sie über ausreichende
Informationen verfügt,
sendet der Rufserver in das System eine Aufbaumeldung (SET UP),
die insbesondere die folgenden Elemente umfasst:
- – die Telefonnummer
des gerufenen Terminals 120, die durch den Benutzer des
rufenden Terminals 110 direkt oder indirekt definiert wird;
- – den
Verbindungstyp des rufenden Terminals, der in den Tafeln seines
die Aufgabe TAP 111 ausführenden Rufservers ausgeführt ist;
dieses Element gestattet es insbesondere, die Terminals zu unterscheiden,
die mit den "klassischen" Zugriffspunkten
verbunden sind, und diejenige, die mit den IP-Zugriffspunkten verbunden
sind;
- – der
topologische Bezugsknoten des Zugriffspunkts des rufenden Terminals,
der seinem Rufserver bekannt ist, wie oben erwähnt wurde;
- – bei
einem rufenden Terminal vom klassischen Typ, eine entsprechende
körperliche
Einrichtungsnummer, die die Schnittstelle des PABX bezeichnet, mit
der der Terminal verbunden ist;
- – bei
einem rufenden Terminal vom Typ IP eine Angabe der Codierungen und
der Durchsätze,
mit denen er kompatibel ist (beispielsweise G.711 allein oder G.711
+ G723.1);
- – bei
einem rufenden Terminal vom Typ IP, die IP-Adresse des Terminals im Netz 2, 3,
eine UDP-Portnummer,
die er auf die Sprechfunkübertragung
gemäß dem RTP-Protokoll
verwendet, und eine andere UDP-Portnummer für die Übertragung der Kontrollinformationen
gemäß dem Protokoll
RTCP.
-
Die
Rufserver, zu denen diese Mitteilung gesendet wird, analysieren
die Nummer des gerufenen Terminals. Nur der Rufserver, der die Mitteilung
berücksichtigt,
indem er eine Aufgabe 121 zur Verarbeitung der ankunftsseitigen
Rufhälfte
(TAP) schafft, ist derjenige des gerufenen Terminals. Diese Aufgabe 121 fragt
einen Topologieserver 90 ab, um eine Konfigurierung des
Rufs zu bestimmen.
-
Der
Topologieserver 90 wird auf der Basis von zwei Sätzen von
Parametern abgefragt, deren einer sich auf den rufenden Terminal 110 und
deren anderer sich auf den gerufenen Terminal 120 bezieht. Jeder
Satz von Parametern, der sich auf einen Terminal bezieht, umfasst:
- – den
Verbindungstyp des Terminals, das heißt die Familie (klassisch oder
IP) seines Zugriffspunkts;
- – die
Identität
des topologischen Bezugsknotens des Zugriffspunkts des Terminals.
-
Bei
dem rufenden Terminal werden diese Parameter von der Aufgabe TAP 121 in
der empfangenen Aufbaumeldung erhalten. Bei dem gerufenen Terminal
werden sie von der Aufgabe 121 in den Daten des Terminals
gelesen, die im Rufserver gespeichert sind, und zwar mit Hilfe der
in der empfangenen Aufbaumeldung erhaltenen Telefonnummer.
-
Der
Topologieserver 90 sendet zum Rufserver eine Angabe eines
Aufbaumodus, der ausgewählt
wurde, um den Kommunikationsweg zu definieren. Zwei Moden sind möglich: ein
Modus ("IP-Modus"), in dem die Mechanismen
des IP-Netzes die Einsetzung des Weges steuern, der andere Modus ("PABX-Modus"), in dem die Mechanismen
des PABX-Netzes diese Einsetzung steuern.
-
Im
ersten Fall arbeiten die Aufgaben TAP zusammen, um die in Entsprechung
zu bringenden IP-Adressen zu erhalten. Die eine oder die andere dieser
Adressen kann bereits verfügbar
sein, wenn es diejenige des rufenden oder gerufenen Terminals vom
Typ IP ist. Wenn die Verwendung eines Gateways auf der rufenden
Seite oder auf der gerufenen Seite erforderlich ist, reserviert
der entsprechende Rufserver Ressourcen dieses Gateways (UDP-Portnummern)
und liefert dann an sein Homolog die IP-Adresse und die reservierten
Ressourcen dieses Gateways. Die Aufgaben TAP liefern nun die zutreffenden
IP-Adressen und UDP-Ports zu den Terminals oder Gateways, die sie
supervisieren, damit die Kommunikation gemäß den gebräuchlichen IP-Mechanismen ablaufen
kann.
-
Im
zweiten Fall arbeiten die Aufgaben TAP zusammen, um die körperlichen
Adressen von topologischen Knoten zu erhalten, die in Entsprechung
zu bringen sind. Im Fall eines IP-Terminals ist dieser Knoten nicht
notwendigerweise der topologische Bezugsknoten des Zugriffspunkts:
er entspricht einem Gateway, der von dem Rufserver auf der Basis
des Bezugsknotens des anderen Terminals identifiziert wurde (wenn
beispielsweise der klassische Terminal 61 den IP-Terminal 69 ruft,
liefert die von dem Server 53 für die gerufene Seite ausgeführte Aufgabe
TAP die körperliche
Adresse eines Gateways 54 oder 55, die es gestattet,
den UCG 33 des rufenden Terminals 61 zu erreichen,
und nicht diejenige des MGW 81, der den Bezugsknoten des
Terminals 69 bildet). Die Anwendungen, die die Kommunikationswege
in dem PABX-Netz 1 supervisieren und einsetzen, übernehmen
es nun, die Ressourcen, die für
die in Aufbau begriffene Kommunikation erforderlich sind, zu reservieren
und dann zu aktivieren. Nach Aufbau der Kommunikation supervisieren
sie weiterhin den Kommunikationsweg, um die relevanten Ereignisse
den Rufservern zu signalisieren.
-
Wenn
die Aufgabe TAP auf der gerufenen Seite über die erforderlichen Informationen
verfügt, sendet
sie zum gerufenen Terminal 120, wenn er verfügbar ist,
das den eingehenden Anruf anzeigende Testsignal und sendet zur Aufgabe
TAP 111 auf der rufenden Seite eine Alarmmeldung, um dem
gerufenen Terminal den Klingelbeginn zu signalisieren. Diese Alarmmeldung
wird zum rufenden Terminal 110 in Form eines Signals zurückübertragen.
Wenn der gerufene Terminal auf die Leitung zugreift, wird das Ereignis
der Aufgabe TAP 121 signalisiert, die dieses der Aufgabe
TAP 111 in einer Verbindungsmeldung mitteilt, die in Form
eines Signals dem rufenden Terminal 110 zurückübertragen
wird. Die Kommunikation kann nun auf gebräuchliche Weise ablau fen. Wenn
einer der Terminals eingehängt
wird, wird der andere davon über
die Aufgaben TAP 111, 121 in Kenntnis gesetzt,
bevor diese sich zurückziehen.
-
Der
Topologieserver kann auch von dem Rufserver auf der rufenden Seite
im Fall des Empfangs einer Transferantragsmeldung ("TRANSFER") abgefragt werden.
-
3 zeigt
ein Verfahren, das für
den Topologieserver anwendbar ist, um dem Rufserver zu antworten,
der ihn abfragt, indem die beiden oben genannten Parametersätze erzeugt
werden.
-
Ein
erster Schritt 130 dieses Verfahren besteht in einem Test,
um zu überprüfen, ob
die Verbindung jedes der Terminals, des Rufenden und des Gerufenen,
vom Typ IP ist. Wenn dies der Fall ist, fragt der Topologieserver
gegebenenfalls die Tafel der IP-Wege in einem Schritt 135 auf
der Basis der IP-Adressen der Terminals oder gegebenenfalls ihrer Gemeinschaftsnummern
ab, was gestattet, sicherzugehen, dass ein IP-Kommunikationsweg
zwischen den beiden Terminals aufgebaut werden kann. Wenn das Eingangspaar
nicht in der Tabelle der IP-Wege steht (der Test 135 der
Existenz eines IP-Wegs misslingt), wählt der Topologieserver 90 den
PABX-Modus und antwortet entsprechend dem Rufserver. Wenn der Test 135 positiv
ist (oder wenn das IP-Netz verbunden ist), wählt er dagegen den IP-Modus.
-
Wenn
mindestens einer der Zugriffspunkte der Terminals vom klassischen
Typ ist (gemäß dem Test 130),
bestimmt der Server 90, ob die topologischen Bezugsknoten
der beiden Zugriffspunkte identisch sind (Test 131). Im
Fall der Identität
hängt der gewählte Aufbaumodus
davon ab, ob ge mäß dem Test 134 die
Zugriffspunkte des rufenden und des gerufenen Terminals beide vom
klassischen Typ sind. Wenn ja, wählt
der Topologieserver den PABX-Modus, wenn nein, wählt er den IP-Modus.
-
Wenn
die topologischen Bezugsknoten der Zugriffspunkte des rufenden und
des gerufenen Terminals laut Test 131 verschieden sind,
prüft der
Server 90 im Schritt 132, ob der topologische
Weg zwischen den beiden betreffenden topologischen Knoten in der
bei der Konfigurierung des Systems definierten Topologie zugelassen
ist. Wenn er es ist, wird der PABX-Modus gewählt. Wenn nicht, fragt der
Server 90 gegebenenfalls die Tafel der IP-Wege im Schritt 133 auf
der Basis der IP-Adressen der Terminals oder ihrer Gemeinschaftsnummern
ab. Wenn das Eingangspaar nicht in der Tafel der IP-Wege steht (der
Test 133 misslingt), signalisiert der Topologieserver 90 dem
Rufserver eine Unmöglichkeit
des Aufbaus des verlangten Verbindungswegs. Eine solche Fehlermeldung
ist für
den Verwalter des Systems nützlich,
der diese Umstände
als Anzeichen für
einen Konfigurationsfehler betrachtet. Wenn der Test 133 positiv
ist (oder wenn das IP-Netz zusammhängend ist), wählt er den
IP-Modus.
-
Die
Erfindung sieht bei einer Abwandlung die Möglichkeit für jeden Zugriffspunkt des Systems
vor, vor der Anfrage des Aufbaus des Rufs auf der rufenden Seite
abgesehen von seinem Ursprungstyp einen zusätzlichen Typ anzugeben (IP
bei einem klassischen Zugriffspunkt und klassisch bei einem IP-Zugriffspunkt).
-
Der
entsprechende Rufserver schreibt nun die dieser Erscheinungsform
betreffenden Parameter in eine Ressourcentafel ein. Jede Tafel wird
befragt, sobald ein verwalte ter Terminal an einem Ruf teilnimmt,
dessen Konfigurierung die Reservierung von Kommunikationswegressourcen
erfordert, die ihm vorübergehend
ein zusätzliches
Aussehen verleihen, und wird bei der Unterdrückung des letzten Rufkontextes
für diesen
Terminal aktualisiert. Ein solcher Terminal besitzt somit ein doppeltes
Aussehen, ein ursprüngliches
und ein virtuelles.
-
Die
Ressourcentafel wird von der Rufverarbeitungsaufgabe der rufenden
Seite vor der Sendung der Rufaufbaumeldung befragt. Diese Meldung
kann gegebenenfalls die das doppelte Aussehen des rufenden Terminals
betreffenden Parameter enthalten. Ebenso kann bei Empfang der Rufaufbaumeldung der
Rufserver des gerufenen Terminals seine Ressourcentafel befragen,
um dem Topologieserver die Parameter mitzuteilen, die ein eventuelles
doppeltes Aussehen des gerufenen Terminals betreffen. Auf diese
Weise kann die Abfragemeldung des Topologieservers abgesehen von
den Elementen, die oben beschrieben wurden, die Parameter enthalten,
die das doppelte Aussehen des Zugriffspunkts des rufenden Terminals
und/oder dasjenige des Zugriffspunkts des gerufenen Terminals enthalten.
-
Die
Antwort des Topologieservers wird nun gemäß dem in 4 dargestellten
Verfahren bestimmt.
-
Der
erste Schritt 130 dieses Verfahrens besteht in einem Test,
um nachzuprüfen,
ob die Verbindung des rufenden Terminals und des gerufenen Terminals
vom Typ IP ist. Wenn die Zugriffspunkte beide vom Typ IP sind, ist
die Verarbeitung der Anfrage identisch mit dem vorhergehenden Fall
(Test 135).
-
Wenn
die Terminals nicht beide vom Typ IP sind, wird der ihren Verbindungstyp
betreffende Test 134 ausgeführt, um zu bestimmen, ob ihre
Zugriffspunkte beide vom klassischen Typ sind. Wenn dies der Fall
ist, werden die topologischen Bezugsknoten der beiden Terminals
in dem Test 131 verglichen. Wenn die topologischen Bezugsknoten
identisch sind, wählt
der Server 90 den PABX-Modus. Wenn sie verschieden sind,
wird der Test 132 durchgeführt, um zu bestimmen, ob sie
die Endknoten eines von der Konfiguration zugelassenen topologischen
Wegs bilden.
-
Wenn
dieser Test 132 positiv ist, wird ein zusätzlicher
Test 137 ausgeführt,
um zu bestimmen, ob die Zugriffspunkte des rufenden und des gerufenen Terminals
beide eine ergänzende
Erscheinungsform haben (in diesem Fall der Figur eine IP-Erscheinungsform).
Wenn dies der Fall ist, führt
der Topologieserver den oben genannten Schritt 135 aus,
um zu bestimmen, ob ein IP-Weg besteht oder nicht, den die Verbindung
einschlagen kann. Wenn ja, wählt
er den IP-Modus. Wenn nicht, wählt
er den PABX-Modus, desgleichen wenn der Test 137 negativ
ist.
-
Wenn
der Test 132 negativ ist, führt der Topologieserver 90 den
Schritt 133 aus, um zu bestimmen, ob ein IP-Weg besteht
oder nicht, den die Verbindung einschlagen kann. Wenn dieser Test 133 negativ
ist, sendet der Topologieserver eine Abbruchantwort. Wenn er positiv
ist, wählt
er den IP-Modus.
-
Wenn
die beiden Terminals Zugriffspunkte von verschiedenen Typen haben
(Test 134), ist einer von den beiden vom klassischen ursprünglichen
Typ, und der Topologieserver 90 überprüft im Test 138, ob er
ein zusätzliches
Aussehen besitzt (in diesem Fall IP). Wenn das der Fall ist, führt der
Topologieserver den oben genannten Schritt 133 aus. Wenn
nicht, prüft
er, ob die topologischen Bezugsknoten der Zugriffspunkte der Terminals
identisch sind (Test 131). Im Fall der Identität führt er auch
den Schritt 133 aus. Wenn nicht, geht der Topologieserver
auf den oben erwähnten
Schritt 132 über.