-
GEBIET DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft einen zerlegten Vermittlungsknoten
und ein Verfahren zum Betreiben desselben. Spezieller betrifft die
vorliegende Erfindung ein Verfahren zum Steuern eines Mediengateways
eines zerlegten Vermittlungsknotens, um das Mediengateway in die
Lage zu versetzen, gemultiplexte Verbindungen abzuwickeln.
-
ALLGEMEINER STAND DER TECHNIK
-
Es
besteht ein erhebliches Interesse an der Verwendung paketbasierter
anstelle von leitungsbasierten Trägertransportmechanismen in
Telekommunikationsnetzen, um Benutzerdaten, zum Beispiel Sprachverkehr, zu
transportieren. Die Gründe
hierfür
hängen
sowohl mit Verbesserungen der Effizienz als auch mit potentiellen
Kosteneinsparungen zusammen. Viel Beachtung wurde zum Beispiel der
Verwendung von Internetprotokoll-(IP-)Netzen zum Transportieren
von Benutzerinformationen zwischen Netzknoten geschenkt. IP-Netze haben den Vorteil,
dass sie von Übertragungsressourcen
einen effizienten Gebrauch machen, indem sie Paketvermittlung verwenden,
und infolge der weit verbreiteten Anwendung der Technologie relativ
kostengünstig sind
(im Gegensatz zu spezialisierter oder firmenspezifischer Kommunikationstechnologie).
Außerdem
besteht Interesse an der Verwendung anderer Transportmechanismen,
darunter AAL1/2/5, FR usw.
-
Der
Standard ISUP, welcher die Einrichtung und Steuerung von Rufverbindungen
in einem Telekommunikationsnetz behandelt, ist eng mit leitungsbasierten
Trägertransportmechanismen
verknüpft
und nicht ohne Weiteres für
eine Verwendung mit paketbasierten Transporttechnologien wie etwa
IP und AAL2 geeignet. Insofern haben verschiedene Standardisierungsgremien,
darunter das ITU-T, ETSI und ANSI, die Spezifizierung eines Protokolls
zur Steuerung von Verbin dungen in Erwägung gezogen, welches unabhängig von
dem zugrunde liegenden Transportmechanismus ist. Dies kann als ein
Heraustrennen von Trägersteuerungs-Funktionen
aus dem Protokoll angesehen werden, welche lediglich das Festlegen
der Parameter (einschließlich
des Anfangs- und Endpunktes) der "Röhre" betreffen, durch
welche Benutzerebenen-Daten zwischen Knoten transportiert werden
und welche für
den Trägertransportmechanismus
spezifisch sind. Das neue Protokoll, das als Bearer Independent
Call Control (BICC, trägerunabhängige Verbindungssteuerung)
bezeichnet wird, hält Verbindungssteuerungsfunktionen
fest, wie etwa die Dienste, die für eine Verbindung zwischen
gegebenen rufenden und gerufenen Teilnehmern (z. B. Rufweiterleitung)
aufgerufen werden, und das Gesamt-Routing von Benutzerebenen-Daten. 1a zeigt
die herkömmliche
integrierte Verbindungssteuerungs- und Trägersteuerungs-Struktur von
ISUP, während 1b die
vorgeschlagene neue, getrennte Struktur zeigt. Es ist anzumerken,
dass an den Verbindungsstellen zwischen verschiedenen Trägernetzen,
d. h. zwischen verschiedenen Transportmedien, ein Gateway-Knoten
vorhanden ist, welcher sowohl die Verbindungssteuerungs-(Call Control,
CC-)Funktionen als auch die Trägersteuerungs-(Bearer Control,
BC-)Funktionen erfordert. Dieser Knoten wird als ein Gateway-Knoten
bezeichnet.
-
Infolge
der Aufteilung CC/BC wird eine neue Schnittstelle zwischen den CC-Funktionen
und den BC-Funktionen freigelegt. Es wird ein Protokoll benötigt, um
eine Kopplung zwischen den CC-Funktionen und den BC-Funktionen zu
ermöglichen,
wenn ein Knoten in einer aufgeteilten Umgebung implementiert wird.
Ein solches Schnittstellenprotokoll ist das "Media Gateway Control Protocol" (MGCP), während ein
anderes, das von der IETF MEGACO Gruppe entwickelt wurde, die Bezeichnung
H.248 trägt.
Gemäß H.248
wird die CC-Funktion als der "Mediengateway-Controller" (Media Gateway Controller,
MGC) bezeichnet, und die BC-Funktion wird als das "Mediengateway" (Media Gateway,
MG) bezeichnet. Der MGC und das MG werden manchmal als die Call-Serving-Funktion
(CSF) bzw. die Bearer-Interworking-Funktion (BIWF) bezeichnet, wobei
der MGC für
die Verbindungssteuerungs-Signalisierung (z. B. ISUP, BICC, H.225,
SIP usw.) verantwortlich ist und das MG für die Abschlusseinrichtung
des (der) physischen Träger(s)
verantwortlich ist, der (die) mit den Benutzerebenen-Daten einer
Verbindung (z. B. TDM-Schaltkreis, RTP-Strom, AAL2-Kanäle usw.)
verknüpft
ist (sind). Eine Trägersteuerung,
wie etwa Q.AAL2, IPBCP und SDP, kann entweder in dem MG oder in
dem MGC implementiert sein.
-
Die
Notwendigkeit des MGCP ist in 2 dargestellt,
welche zwei Peer-Gateway-Knoten zeigt, welche sowohl auf der CC-Ebene
(MGC) als auch auf der BC-Ebene (MG) miteinander kommunizieren.
H.248 beschreibt Ressourcen, die auf der Trägerebene in dem MG verfügbar sind
(z. B. Eingänge,
Ausgänge,
Konnektivität,
Verbindungsbearbeitung usw.) anhand von "Kontexten" und "Abschlusseinrichtungen". Ein Kontext, der durch
eine Kontext-ID identifiziert wird, ist ein logisches Konzept, das
durch eine auf der BC- und/oder CC-Ebene gespeicherte Datenstruktur verkörpert wird,
welche eine Verbindung innerhalb der BC-Funktionen unter Verwendung
mindestens einer Abschlusseinrichtung definiert. Eine Abschlusseinrichtung
stellt einen physikalischen Endpunkt dar, mit welchem ein Träger physisch
oder logisch verbunden ist, und ihr kann eine von einer Anzahl von
physikalischen Eigenschaften zugewiesen sein, zum Beispiel ein Transporttyp
(Leitung, IP, ATM), ein Medien- oder Codec-Typ (GSM, G.711) oder
eine Prioritätsebene. 3 zeigt
einen einfachen Kontext 1 mit zwei Abschlusseinrichtungen T1 und
T2. Dieser könnte
zum Beispiel eine herkömmliche
Sprachverbindung zwischen zwei Teilnehmern darstellen, wobei T1
den Eingangsanschluss oder die ankommende Leitung für den rufenden
Teilnehmer zu der BC-Schicht darstellt und T2 den Ausgangsanschluss
oder die abgehende Leitung für
den gerufenen Teilnehmer von der BC-Schicht darstellt.
-
WO 01/49045 beschreibt
ein Kommunikationssystem, in welchem eine Aufteilung zwischen der
Verbindungssteuerungs- und der Trägersteuerungs-Ebene vorhanden
ist. Dieses Dokument betrifft insbesondere das Routing von mit der
Verbindungssteuerung zusammenhängenden
Daten von einem herkömmlichen
SS7 Signalisierungsnetz zu einem Netz mit der geteilten Architektur.
-
ITU-T
hat ein Profil für
die Verwendung des Kerns des H.248 Protokolls, H.248.1, in BICC-basierten Netzen
entwickelt. Dieses ist in der Empfehlung Q.1950 "Bearer independent call bearer control
protocol" enthalten.
Dieses Dokument profiliert praktisch H.248.1 und gibt an, welche
Erweiterungen zu unterstützen
sind. In die Tiefe gehende Prozeduren werden für rufbezogene und nicht rufbezogene
Szenarien dokumentiert, und das Dokument stellt eine Verknüpfung zu
den BICC-Prozeduren her, die in Q.1902.4 definiert sind. Für Mobilfunknetze
hat das 3GPP ebenfalls eine Profildokumentation für die Verwendung
von H.248.1 über
die Schnittstelle Mediengateway-Controller – Mediengateway hinweg erstellt.
In der technischen Spezifikation 29.232 "Media Gateway Controller (MGC) – Media
Gateway (MGW) Interface; Stage 3" ist
dieses Profil detailliert beschrieben. TS 29.232 stellt dieselbe
Detailebene wie Q.1950 zur Verfügung.
Die folgende Erörterung
betrifft Modifikationen und Ergänzungen
zu Q.1950 und TS 29.232, aus welchen wiederum die Spezifikation
neuer Pakete für
H.248 resultieren wird.
-
Ein
zerlegter Vermittlungs-(oder Gateway-)Knoten muss typische Telekommunikationsdienste
unterstützen.
Insbesondere muss ein Vermittlungs-Gateway Multiplexverbindungen
unterstützen,
bei denen eine Anzahl von Leitungen zusammen gemultiplext ist, zum
Beispiel um einem Teilnehmer oder anderem Benutzer eine Verbindung
mit hoher Bandbreite zur Verfügung
zu stellen, insbesondere um die Hochgeschwindigkeitsübertragung
von Daten, Audio und Video zu ermöglichen. Solche gemultiplexten
Verbindungen werden gewöhnlich
in den heutigen ISUP-basierten leitungsvermittelten Netzen verwendet,
und der Dienst wird als ein N·64K
Dienst bezeichnet (wobei N die Anzahl von (ISUP-gesteuerten) Leitungen
angibt, die gemultiplext werden, um die Verbindung zu bilden, und
64K die Datenrate einer einzelnen Leitung ist). 4 zeigt
schematisch das Multiplexing von vier 64K-Leitungen, um eine Verbindung
mit einer effektiven Bandbreite von 256K bereitzustellen. Definitionen
des N·64K
Dienstes werden gegeben in:
- ITU-T Empfehlung Q.763 (12/1999),
Signalisierungssystem Nr. 7 – ISDN-Benutzerteile,
Formate und Codes, und
- ITU-T Empfehlung Q.764 (12/1999), Signalisierungssystem Nr.
7 – ISDN-Benutzerteil
Signalisierungsprozeduren.
-
Bei
einer N·64K
Verbindung ist es notwendig, dass das Mediengateway Daten von einer
Menge von "ankommenden" Leitungen in der
richtigen Reihenfolge empfängt
und diese Daten auf einer Menge von "abgehenden" Leitungen ebenfalls in der richtigen
Reihenfolge ausgibt. Diese Leitungen auf jeder Seite können zusammenhängend (d.
h. aufeinander folgend) oder nicht zusammenhängend sein. Außerdem kann
sich die Reihenfolge der Leitungen auf den zwei Seiten unterscheiden.
Zum Beispiel kann die Reihenfolge de Leitungen auf der ankommenden
Seite CIC1, CIC2, CIC3 sein, während
auf der abgehenden Seite die Reihenfolge CIC1, CIC3, CIC2 sein kann.
Das Mediengateway muss eine Leitungszuweisungs-Abbildung erzeugen oder erhalten, um
Multiplexverbindungen korrekt abzuwickeln.
-
Ein
Problem beim Implementieren von Unterstützung für Multiplexverbindungen ist,
dass die notwendige Funktionalität
zwischen dem MGC und dem MG verteilt werden muss. Da die Kommunikation
zwischen diesen zwei Entitäten
von existierenden Gatewaysteuerungs-Protokollen abhängt, hängen der
Umfang und die Flexibilität
des Dienstes von dem gewählten Protokoll
ab. Das H.248 Kernprotokoll (H.248.1) spezifiziert eine Befehlsnachrichtenstruktur
für Nachrichten,
die von dem MGC zu dem MG gesendet werden. Ein Beispiel einer Befehlsnachricht
zum Erzielen eines Multiplex ist Folgendes:
-
Gemäß H.248.1
ist der Typparameter (Mux) des Multiplexdeskriptor-Feldes statisch
definiert als ein Element aus der folgenden Aufzählung: H.221, H.223, H.226
und V.76. Standardmäßig werden
bei H. 248 alle Daten, die auf irgendeiner der spezifizierten Abschlusseinrichtungen
des spezifizierten Kontextes ankommen, auf alle anderen Abschlusseinrichtungen
ausgegeben, d. h. eine vollständig
vermaschte Verbindung. Diese "Konferenz"-Konfiguration ist
in 5 schematisch dargestellt. Das Einstellen des
Typparameters Mux auf einen bestimmten statischen Typ, z. B. H.221,
hat dann zur Folge, dass dieses Verhalten insofern modifiziert wird,
als die Daten, die auf den in dem Multiplex spezifizierten Abschlusseinrichtungen
empfangen werden, auf diejenigen ausgegeben werden, die in dem Multiplex
nicht spezifiziert sind. Jedoch für den N·64K Dienst müssen Daten,
die von dem Multiplex empfangen werden, zu den anderen Abschlusseinrichtungen
in einer gewissen Reihenfolge ausgege ben werden. Der Multiplexdeskriptor
des gegenwärtigen
H.248 Protokolls gestattet es nicht, diese Reihenfolge anzugeben,
und daher kann das gegenwärtige
H.248 den N·64K
Dienst nicht unterstützen.
-
KURZDARSTELLUNG DER ERFINDUNG
-
Das
Problem, dem die vorliegende Erfindung gewidmet ist, ist das der
Ermöglichung
von Multiplexsitzungen im Rahmen der Einschränkungen, die Originalherstellern
und Betreibern durch die relevanten Mediengateway-Steuerungsprotokolle,
z. B. H.248, auferlegt werden.
-
Das
H.248.1 Protokoll ermöglicht
die effektive Erweiterung des Protokolls, um neuer Funktionalität und neuen
Diensten Rechnung zu tragen. Benutzer (z. B. Originalhersteller,
Netzbetreiber, Konsortien, Benutzergruppen usw.) können eine
detaillierte Spezifikation bei der Behörde IANA (Internet Assigned
Numbers Authority) hinterlegen, welche das H.248.1 Protokoll verwaltet,
wobei die Spezifikation die Funktionalität oder den Dienst definiert.
Die Behörde
kann auch selbst eine solche Spezifikation erzeugen. Unter der Annahme,
dass die Spezifikation akzeptiert wird, wird sie als ein "Paket" bezeichnet, und
sie erhält
eine eindeutige Paketidentität.
Wie in der obigen Befehlsnachrichten-Struktur dargestellt, enthält die Befehlsnachricht
ein Feld zur Einfügung
einer oder mehrerer Paketidentitäten.
Pakete sind optional in Mediengateways implementiert, so dass zusätzliche
Funktionalität
und/oder zusätzliche
Dienste bereitgestellt werden. Andere Mediengateway-Steuerungsprotokolle
können ähnliche
Protokollerweiterungen benutzen, welche ebenfalls als "Pakete" bezeichnet werden
können.
-
Die
Befehlsnachrichten-Struktur ermöglicht
die Einfügung
einer oder mehrerer Eigenschaften für jede Paketidentität. Diese
Eigenschaften werden durch das Mediengateway verwendet, wenn das
identifizierte Paket implementiert wird.
-
Die
Erfinder der vorliegenden Erfindung haben erkannt, dass das Problem
der Abwicklung von Multiplexdiensten an einem zerlegten Vermittlungsknoten
gelöst
werden kann, indem ein oder mehrere geeignete Pakete spezifiziert
werden und indem diese Pakete an dem Mediengateway implementiert
werden.
-
Gemäß einem
ersten Aspekt der vorliegenden Erfindung wird in einem Telekommunikationsnetz
ein Verfahren zur Steuerung eines Mediengateways bereitgestellt,
um eine Multiplexsitzung unter Verwendung eines Mediengateway-Controllers
abzuwickeln, wobei das Mediengateway und der Mediengateway-Controller unter
Verwendung eines Schnittstellenprotokolls kommunizieren, das Befehlsnachrichten
mit einer Struktur vorsieht, die enthält:
ein Kontextfeld zur
Identifizierung eines Kontextes des Mediengateways;
ein Abschlusseinrichtungsfeld
zur Identifizierung einer oder mehrerer Abschlusseinrichtungen des
Mediengateways, die in den Kontext einbezogen sind;
mindestens
einen Deskriptor zum Definieren von Eigenschaften des Kontextes;
und
eine Paketidentität,
wobei
das Verfahren umfasst:
in dem Mediengateway-Controller, Erzeugen
einer Befehlsnachricht, die diese Struktur hat und einen Multiplexdeskriptor
enthält,
der eine Paketkennung aufweist, wobei die Paketkennung ein Paket
identifiziert, das in dem Mediengateway implementiert wird, um eine
Multiplexsitzung abzuwickeln;
Senden der erzeugten Befehlsnachricht
von dem Mediengateway-Controller zum Mediengateway; und
im
Mediengateway, Einrichten des in der Nachricht identifizierten Kontextes
gemäß dem spezifizierten
Paket.
-
Es
ist klar, dass ein Mediengateway-Controller eine Multiplexsitzung,
die mit einer Befehlsnachricht zusammenhängt, aus irgendeinem von einer
Anzahl von verschiedenen Gründen
erzeugen kann. Zum Beispiel kann der Mediengateway-Controller eine
Verbindungsaufbau-Anforderung von einem Peer-Mediengateway-Controller auf der Verbindungssteuerungs-Ebene empfangen,
wobei diese Anforderung eine Multiplexsitzung identifiziert (die
Anforderung kann die ankommenden Leitungen identifizieren, die an
der Multiplexsitzung beteiligt sind). Stattdessen kann auch eine
Aufbau-Nachricht über
ein GSTN (z. B. PSTN oder PLMN) empfangen werden, mit welchem der
Mediengateway-Controller gekoppelt ist.
-
Es
ist außerdem
klar, dass das Schnittstellenprotokoll, das verwendet wird, um zwischen
dem Mediengateway und dem Mediengateway-Controller zu kommunizieren,
normalerweise ein standardisiertes Schnittstellenprotokoll sein
wird. Jedoch können
an diesem Protokoll geringfügige Änderungen
vorgenommen werden, in Abhängigkeit
von den Anforderungen von Herstellern und Betreibern.
-
Der
Begriff "Einrichten" wird hier in dem
Sinne verwendet, dass er sowohl die Erzeugung eines neuen Kontextes
als auch die Modifikation eines existierenden Kontextes umfasst.
-
Ausführungsformen
der vorliegenden Erfindung stellen ein flexibles Mittel zur Implementierung
von Multiplexdiensten in einem zerlegten Vermittlungsknoten bereit.
Falls die Erfindung auf H.248 angewendet wird, ist eine Syntaxänderung
an dem H.248.1 Protokoll erforderlich, um Pakete in den Multiplexdeskriptor
einzuführen.
Danach ist keine Modifikation des existierenden Schnittstellensteuerungs-Protokolls erforderlich,
um die neue Multiplex-Funktionalität zu unterstützen. Es
müssen
nur ein oder mehrere neue Pakete bei der das Protokoll verwaltenden
Behörde
spezifiziert werden. Da eine Anzahl von Eigenschaften in eine Befehlsnachricht
für jedes
identifizierte Paket eingefügt
werden kann, kann ein hohes Niveau der Steuerung des Dienstes durch
den Mediengateway-Controller aufrechterhalten werden.
-
Die
vorliegende Erfindung ist insbesondere, obwohl nicht ausschließlich, auf
das H.240 Mediengateway-Steuerungsprotokoll anwendbar, und darauf,
das Bereitstellen eines N·64K
Dienstes an einem zerlegten Vermittlungsknoten zu ermöglichen.
-
Gemäß einem
zweiten Aspekt der vorliegenden Erfindung wird ein Mediengateway-Controller
bereitgestellt, der ein Schnittstellenprotokoll verwendet, das Befehlsnachrichten
mit einer Struktur vorsieht, die enthält:
ein Kontextfeld zur
Identifizierung eines Kontextes des Mediengateways, auf das sich
die Nachricht bezieht;
ein Abschlusseinrichtungsfeld zur Identifizierung
einer oder mehrerer Abschlusseinrichtungen des Mediengateways, die
in den Kontext einbezogen sind;
mindestens einen Deskriptor
zum Definieren von Eigenschaften des Kontextes; und
eine Paketidentität,
wobei
der Mediengateway-Controller umfasst:
Verarbeitungsmittel zum
Erzeugen einer Befehlsnachricht, die diese Struktur hat und einen
Multiplexdeskriptor enthält,
der eine Paketkennung aufweist, wobei die Paketkennung ein Paket
identifiziert, das in einem Mediengateway implementiert wird, um
eine Multiplexsitzung abzuwickeln;
Ein-/Ausgabemittel zum Koppeln
mit Ein-/Ausgabemitteln eines Mediengateways; und
Übertragungsmittel
zum Senden der erzeugten Befehlsnachricht von dem Mediengateway-Controller
zu einem Mediengateway über
die Ein-/Ausgabemittel des Mediengateway-Controllers.
-
Gemäß einem
dritten Aspekt der vorliegenden Erfindung wird ein Mediengateway
bereitgestellt, das dafür
eingerichtet ist, bei Verwendung durch einen Mediengateway-Controller
unter Verwendung eines Schnittstellenprotokolls gesteuert zu werden,
das Befehlsnachrichten mit einer Struktur vorsieht, die enthält:
ein
Kontextfeld zur Identifizierung eines Kontextes des Mediengateways,
auf das sich die Nachricht bezieht;
ein Abschlusseinrichtungsfeld
zur Identifizierung einer oder mehrerer Abschlusseinrichtungen des
Mediengateways, die in den Kontext einbezogen sind;
mindestens
einen Deskriptor zum Definieren von Eigenschaften des Kontextes;
und
eine Paketidentität,
wobei
das Mediengateway umfasst:
Verarbeitungs- und Speichermittel
zum Implementieren mindestens eines Paketes;
Ein-/Ausgabemittel
zum Koppeln mit Ein-/Ausgabemitteln eines Mediengateway-Controllers;
Empfangsmittel,
die mit den Ein-/Ausgabemitteln des Mediengateways gekoppelt sind,
zum Empfangen einer Befehlsnach richt, die dieselbe Struktur hat
und die einen Multiplexdeskriptor enthält, der eine Paketkennung aufweist,
wobei die Paketkennung ein Paket identifiziert, das in einem Mediengateway
implementiert wird, um eine Multiplexsitzung abzuwickeln und um
zu bewirken, dass die Verarbeitungs- und Speichermittel das identifizierte
Paket implementieren.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
1a zeigt
in Blockschaltbildform die Architektur eines herkömmlichen
Telekommunikationsnetzes;
-
1b zeigt
in Blockschaltbildform eine Netzarchitektur, in welcher das Verbindungssteuerungs-Protokoll
unabhängig
von dem Transportmechanismus ist;
-
2 zeigt
die Protokollschichten in zwei Peer-Gateway-Knoten, welche sowohl auf der CC-Ebene als
auch auf der BC-Ebene
miteinander kommunizieren;
-
3 zeigt
schematisch einen einfachen Kontext, der zwei Abschlusseinrichtungen
umfasst;
-
4 zeigt
schematisch einen N·64K
Multiplexdienst, bei welchem vier 64K Leitungen gemultiplext werden,
um eine einzige Verbindung mit einer Bandbreite von 256K bereitzustellen;
-
5 zeigt
schematisch die Standard-Konferenzkonfiguration, die aus der Hinzufügung von
Abschlusseinrichtungen zu einem Kontext durch eine Befehlsnachricht
gemäß dem H.246
Protokoll resultiert;
-
6 zeigt
in Form einer auseinander gezogenen Ansicht die Struktur einer H.248
Befehlsnachricht; und
-
7 zeigt
schematisch einen Kontext, der in einem Mediengateway zum Abwickeln
einer Multiplexverbindung erzeugt wurde.
-
AUSFÜHRLICHE BESCHREIBUNG BEVORZUGTER
AUSFÜHRUNGSFORMEN
-
Die
folgende Beschreibung einer bevorzugten Ausführungsform der Erfindung betrifft
das H.248 Mediengateway-Steuerungsprotokoll. Es ist jedoch klar,
dass die Erfindung auch auf andere Mediengateway-Steuerungsprotokolle
anwendbar ist, welche mit dem H.248 Protokoll Merkmale gemeinsam
haben.
-
Es
wird auf 6 Bezug genommen; eine Befehlsnachricht
gemäß dem H.248.1
Protokoll umfasst Kopfteil-(Header-)Felder, Nutzdaten-(Payload-)Felder,
einen Deskriptor und optional ein Feld, welches ein Paket identifiziert
und welches einen oder mehrere Parameter dieses Feldes enthält. Wie
oben erläutert,
entspricht ein Paket einem Dienst oder einer Funktionalität, welche
nicht in dem H.248.1 Kernprotokoll spezifiziert ist, welche jedoch
bei der entsprechenden Behörde
eingereicht und von dieser akzeptiert worden ist. Der Dienst oder
die Funktionalität
wird (otional) in einem zerlegten Vermittlungsknoten implementiert,
in dem Mediengateway. Ein Mediengateway-Controller kann den Dienst
oder die Funktionalität
aufrufen, indem er die Identität
des Paketes in das entsprechende Feld der Befehlsnachricht einfügt. Ein
Beispiel eines Paketes ist das "Ankündigungspaket" H.248.7, welches
Signale definiert, um dem Mediengateway-Controller zu ermöglichen
anzufordern, dass das Mediengateway Ankündigungen abspielt.
-
"Typ" ist in dem H.248
Protokoll statisch definiert als Aufzählungen (H.221, H.223, H.226,
V.76). 7 zeigt eine N·64K Dienstkonfiguration,
in welcher Abschlusseinrichtungen Ta, Tb, Tc mit Abschlusseinrichtungen Td, Te bzw. Tf verbunden sind. Um diesen N·64K Dienst
zu implementie ren, kann die Aufzählungsliste
auf zweierlei Weise aktualisiert werden:
- 1.
Ein weiterer (statischer) Aufzählungspunkt
kann hinzugefügt
werden, welcher Typ = N·64K
spezifiziert.
- 2. Ein weiterer Aufzählungspunkt
kann definiert werden als "anderer". Dieser Typ weist
auf ein neues Paket hin, welches den geforderten Multiplexdienst
oder die geforderte Multiplexfunktion implementiert. Die Paketidentität ist in
dem Multiplexdeskriptor enthalten. Der Deskriptor würde die
folgende Struktur aufweisen:
MuxDeskriptor (Typ, (Abschlusseinrichtung
1, Abschlusseinrichtung 2, Abschlusseinrichtung 3, ...], Paket-Mux-Typ).
-
Für das spezielle
Beispiel des N·64K
Dienstes:
MuxDeskriptor (anderer, [Abschlusseinrichtung 1,
Abschlusseinrichtung 2], N·64K).
-
Die
Implementierung von Option 1 erfordert dann eine Aktualisierung
der Syntax von H.248. Die Implementierung von Option 2 erfordert
ebenfalls eine Syntax-Aktualisierung. Bei Option 2 können jedoch,
nachdem die Aktualisierung vorgenommen worden ist, weitere Multiplexdienste
durch Einführung
neuer Pakete hinzugefügt
werden. Es besteht keine Notwendigkeit, für jeden Dienst weitere Syntax-Aktualisierungen
vorzunehmen.
-
An
sich ist Option 2 restriktiv, da die Eigenschaften des N·64K Dienstes
statisch sind und der Multiplexdeskriptor keine Spezifikation von
Parametern ermöglicht,
um die Eigenschaften eines Multiplex weiter zu definieren. Eine
größere Flexibilität kann eingeführt werden,
indem zu dem Multiplexdeskriptor zusätzliche Felder hinzugefügt werden,
um die Spezifikation von N·64K
Diensteigenschaften zu ermöglichen.
Die Verwendung von Eigenschaften würde zu der folgenden Struktur
von Befehlsnachrichten führen:
MuxDeskriptor
(Typ, [Abschlusseinrichtung 1, Abschlusseinrichtung 2, Abschlusseinrichtung
3, ...], Paket-Mux-Typ, (Mux_Eigenschaft1, Mux_Eigenschaft2, Mux_Eigenschaft3,
...)
-
Zum
Beispiel:
MuxDeskriptor (anderer, (Abschlusseinrichtung 1,
Abschlusseinrichtung 2], N·64K,
[N·64KTyp
= zusammenhängend,
Leitungszuweisungs-Abbildung = 00101000).
-
Um
Option 2, erweitert durch die Verwendung von Eigenschaften, zu implementieren,
werden die folgenden Ergänzungen
zu existierenden Standards/Empfehlungen vorgeschlagen, wobei die
BIWF analog zu dem Mediengateway ist und die CSF analog zu dem Mediengateway-Controller
ist. Ein Symbol "?" stellt ein Jokerzeichen
dar, das in dem gegebenen Protokoll oder Standard noch zu definieren
ist. Es ist anzumerken, dass der Text entsprechend den Anforderungen
der verschiedenen Protokolle angeordnet (formatiert, mit einem Kopfteil
versehen usw.) ist und dazu bestimmt ist, in Verbindung mit diesen
Protokollen gelesen zu werden.
-
(A) Ergänzungen zu der ITU-T Empfehlung
Q.1950 (07/2001) für
N·64K
-
Die
folgenden Objekte sind die Signalisierungsobjekte, die durch die
Befehle in den Transaktionen zu transportieren sind.
- 1. Leitungszuweisungsplan: Gibt den Leitungszuweisungsplan (Circuit
Assignment Map) an, wie in ITU-T Q.763/§ 3.69 definiert.
- 2. N × 64K
Typ: Gibt an, ob der N × 64K
Dienst zusammenhängend
oder nicht zusammenhängend
ist. Definition von "zusammenhängend" (contiguous) und "nicht zusammenhängend" (non-contiguous)
siehe ITU-T Q.763/§ 1.2.
- 3. N × 64K
Abschlusseinrichtungen-Liste: Dies ist die liste von Abschlusseinrichtungen,
welche der Anzahl N von Leitungen entsprechen, die erforderlich
sind, um den N × 64K
Dienst zu realisieren. Diese kann der BIWF zur Verfügung gestellt
oder von ihr angefordert werden.
-
N × 64K
CBC Leistungsmerkmale-Satz (Capability Set)
-
Wie
nach Q.1950/$6, mit den folgenden Ergänzungen.
-
Erforderliche Standardpakete
-
Das
folgende Paket ist zu verwenden, wenn der N × 64K Dienst über die
CBC Schnittstelle hinweg verwendet wird:
- • H.248 Anhang
M.? N × 64K
Leitungspaket
-
CBC Prozeduren
-
Wie
nach Q.1950/§7.
-
CBC Prozeduren/Verbindungsbezogen
-
Dieser
Abschnitt enthält
die verbindungsbezogenen Prozeduren für den N × 64K Dienst, wenn er in Verbindung
mit Q.1950 verwendet wird.
-
CSM Transaktionen
-
Die
folgende Transaktion wird verwendet, um anzugeben, dass eine Prozedur
durch das CSM einzuleiten ist. Die Transaktion führt zu Befehlen, die über die
CBC-Schnittstelle gesendet werden. Tabelle B.1/Q.1950 – Verbindungsbezogene, durch
CSM eingeleitete Transaktionen auf der CBC-Schnittstelle
| Transaktion | Beschreibung |
| n × 64K | Diese
Transaktion wird verwendet, um der BIWF anzuzeigen, dass der n × 64K Dienst
verwendet wird. Diese Transaktion liefert der BIWF Informationen
darüber
oder fordert von ihr Informationen darüber an, ob der N × 64K Typ
zusammenhängend
oder nichtzusammenhängend
ist. Sie kann auch den Leitungszuweisungsplan anfordern, wenn die
BIWF die Abschlusseinrichtungen liefert, welche verwendet werden. |
-
Wenn
die Transaktion "N × 64K" erforderlich ist,
wird die folgende Prozedur eingeleitet:
Ein Befehl ADD.req,
MOD.req oder MOV.req (1) wird mit der folgenden Information gesendet.
- (1) ADD.req/MOD.req/MOV.req (..., N × 64K) CSM
an BIWF (siehe Tabelle 1 weiter unten)
-
Bei
Empfang des Befehls (1) muss die BIWF:
- • Dem N × 64K Dienst
entsprechend dem N × 64K
Typ, dem Leitungszuweisungsplan und der N × 64K Abschlusseinrichtungen-Liste Leitungen zuweisen.
- • Falls
die CSF den N × 64K "Nichtzusammenhängend" anfordert und die
BIWF auffordert, die Kennungen (Ids) der Abschlusseinrichtungen
zu wählen,
muss die BIWF den Leitungszuweisungsplan zurücksenden, so dass die CSF die
Abschlusseinrichtungen in dem Multiplex auf die richtige Weise verknüpfen kann.
- • Falls
die CSF die BIWF auffordert, die N × 64K Abschlusseinrichtungen-Liste
zu wählen,
muss sie N Kennungen (Ids) von Abschlusseinrichtungen (z. B. Tid1,
Tid2, Tid?) in der N × 64K
Abschlusseinrichtungen-Liste liefern.
- • Die
Antwort auf die Anforderungen in Befehl (2) senden.
-
Nach
Abschluss der Verarbeitung von Befehl (1) wird ein Befehl (2) ADD.resp,
MOD.resp oder MOV.resp gesendet.
- (2) ADD.resp/MOD.resp/MOV.resp
BIWF an CSM
(siehe Tabelle 2 weiter unten)
-
Formate und Codes
-
In
diesem Abschnitt wird die Codierung des N × 64K Dienstes dargestellt,
wenn er mit dem CBC Protokoll verwendet wird.
Formate und Codes – Allgemeines
Wie
nach Q.1950/§ 11.1.
Formate
und Codes – Befehle
Wie
nach Q.1950/§ 11.2.
Formate
und Codes – Signalisierungsobjekte
-
Tabelle B.2/Q.1950 – Zuordnungstabelle CBC Signalisierungsobjekt
zu H.248 Codierung (siehe Tabelle 3 weiter unten)
-
(B) Neues H.248 Paket zum Definieren des
N·64K
Dienstes
-
Diese
Ergänzung
kann als H.248 Anhang M.? N × 64K
Paket bezeichnet werden. H.248 Anhang M.? beschreibt ein Paket, das
dazu dient, die Verwendung des N × 64K Dienstes in einer geteilten
CSF und BIWF Architektur zu ermöglichen.
Wie in H.248 definiert, ist ein "Paket" (Package) eine Erweiterung
von H.248, welche ein spezifisches Verhalten unterstützt.
-
Umfang
-
- Paketname: N × 64K
Circuit Package (Leitungspaket)
- Paket-ID: N × 64k,
0 × 00??
-
Paketbeschreibung:
-
Dieses
Paket ermöglicht
die Verwendung des zusammenhängenden
und nicht zusammenhängenden N × 64K Dienstes.
Definition der N × 64K
Prozeduren siehe ITU-T Q.764/§ 2.1.13.
Es definiert einen Multiplextyp für N × 64K, eine Angabe "zusammenhängend" oder "nicht zusammenhängend" und die Fähigkeit,
einen Leitungszuweisungsplan zu spezifizieren.
-
Version: 1
-
-
Eigenschaften
-
- Eigenschaftsname: N × 64K
Typ
- Eigenschafts-Eid: Typ, 0 × 0001
-
Beschreibung:
-
Diese
Eigenschaft gibt an, ob die N × 64K
Verbindung zusammenhängend
oder nicht zusammenhängend
ist. Definition von "zusammenhängend" (contiguous) und "nicht zusammenhängend" (non-contiguous) siehe
ITU-T Q.763/§ 1.2.
-
Mögliche
Werte:
-
- Zusammenhängend,
[0 × 0001]
- Nichtzusammenhängend,
[0 × 0002]
- Definiert in: Mux Descriptor
- Charakteristische Merkmale: Lesen/Schreiben
- Eigenschaftsname: Leitungszuweisungsplan
- Eigenschafts-ID: CAM, 0 × 0002
-
Beschreibung:
-
Diese
Eigenschaft gibt den Leitungszuweisungsplan an, wie in ITU-T Q.763/§ 3.69 definiert.
-
Mögliche
Werte:
-
Binärcodierung
-
Der
Inhalt des Leitungszuweisungsplans wird codiert, wie in ITU-T Q.763/§ 3.69 angegeben.
-
Textcodierung
-
Der
Inhalt des Leitungszuweisungsplans wird codiert, wie in ITU-T Q.763/§ 3.69 angegeben,
in dem hexadezimalen Format, das in H.248 B.3 Hexadezimale Oktett-Codierung
angegeben ist. Zum Beispiel ist das Format des Parameterfeldes des
Leitungszuweisungsplans in der folgenden Tabelle dargestellt.
-
-
Figur
1/H.248 Anhang M.? – Parameterfeldes
des Leitungszuweisungsplans
-
Verwendung des Abbildungs-Typs
-
0
0 0 0 1 0 Bei 2048 kbit/s Digitalpfad Abbildungsformat (64 kbit/s
Basisrate), und wenn Leitung 1 und 4 verwendet werden, wäre die resultierende
Textcodierung: 02 09 00 00 00.
- Definiert in: Mux Descriptor
- Charakteristische Merkmale: Lesen/Schreiben
-
MUX-Name
-
- Mux-Name: N × 64K
- Mux-ID: N × 64K,
0 × 0001
-
Beschreibung:
-
Dieser
Multiplexname gibt an, dass der N × 64K Dienst verwendet wird
und dass gemultiplexte Abschlusseinrichtungen verwendet werden.
Einzelheiten der N × 64K
Prozeduren siehe ITU-T Q.764/§ 2.1.13.
-
Prozeduren
-
Eine
CSF kann den N × 64K
Dienst anfordern, indem sie den entsprechenden H.248 Befehl mit
einem Multiplexdeskriptor ausgibt, der N × 64K als den Mux-Typ angibt.
Die CSF kann der BIWF auch anzeigen, ob zusammenhängendes
oder nicht zusammenhängendes
N × 64K
verwendet wird. Die CSF kann auch die BIWF auffordern, zwischen "Zusammenhängend" und "Nichtzusammenhängend" zu wählen. Definition
von "Zusammenhängend" (Contiguous) und "Nichtzusammenhängend" (Non-contiguous)
siehe ITU-T Q.763/§ 1.2.
Der Parameter Leitungszuweisungsplan kann auch von der BIWF angefordert
oder der BIWF gegeben werden. Definition der Verwendung des Leitungszuweisungsplans
siehe ITU-T Q.763/§ 3.69.
Der Multiplexdeskriptor erfordert, dass die CSF Abschlusseinrichtungen
spezifiziert, die an dem Multiplex beteiligt sind. Die CSF kann die
Identitäten
der Abschlusseinrichtungen liefern, die mit den Leitungen verknüpft sind,
die an dem N × 64K Dienst
beteiligt sind. Die CSF kann auch die Identitäten der Abschlusseinrichtungen
liefern, die mit den Leitungen verknüpft sind, die an dem N × 64K Dienst
beteiligt sind. In diesem Falle müsste die CSF ein CHOOSE "?" für
N Abschlusseinrichtungen ausgeben, die an dem N × 64K Dienst beteiligt sind.
-
Beispiel 1
-
Die
CSF möchte
N × 64K,
nicht zusammenhängend,
für einen
3 × 64K
Dienst anfordern und möchte, dass
die BIWF den Leitungszuweisungsplan wählt.
Mux = Anderer {?,
?, ?, ?}, N × 64K,
N × 64K/Typ=nicht
zusammenhängend,
N × 64K/cam
= ?
-
Beispiel 2
-
Die
CSF möchte
N × 64K,
zusammenhängend,
für einen
2 × 64K
Dienst anfordern und den Leitungszuweisungsplan angeben.
Mux
= Anderer {A, B}, N × 64K,
N × 64K/Typ=nicht
zusammenhängend,
N × 64K/cam=
02 09 00 00 00
-
(C) Ergänzungen zu dem H.248 Multiplexdeskriptor
-
Dieser
Beitrag schlägt
Ergänzungen
zu dem H.248 Multiplexdeskriptor vor, um eine Definition von Multiplexen
und zugehörigen
Eigenschaften unter Verwendung von Paketen zu ermöglichen.
-
Dieser
Beitrag schlägt
vor, die Fähigkeit
hinzuzufügen,
in der Lage zu sein:
- • Dem Multiplexnamen in einem
Paket zu definieren.
- • Zu
definieren, dass eine Eigenschaft in dem Multiplexdeskriptor auftritt.
-
Es
wird vorgeschlagen, die folgenden Änderungen vorzunehmen:
-
Multiplexdeskriptor
-
Bei
Multimedia-Verbindungen wird eine Anzahl von Medienströmen auf
einer (möglicherweise
anderen) Anzahl von Trägern
transportiert. Der Multiplexdeskriptor verknüpft die Medien und die Träger. Der
Deskriptor beinhaltet den Multiplextyp:
H.221,
H.223,
H.226,
V.76,
-
Paket-definierte
Multiplextypen (anderer),
Mögliche
Erweiterungen
und eine Menge von Abschlusseinrichtungs-IDs,
welche die gemultiplexten Eingänge,
geordnet, darstellen, zum Beispiel: Mux = H.221{MyT3/1/2,
MyT3/2/13, MyT3/3/6, MyT3/21/22}
-
Der
Multiplex kann auch Eigenschaften enthalten, die mit dem Multiplex
selbst verknüpft
sind. Diese Eigenschaften können
auch in einem Paket definiert sein. Werte von Eigenschaften können unterspezifiziert sind.
-
Eine
neue Einstellung des Mux-Deskriptors ersetzt die vorhergehende Einstellung
dieses Deskriptors in dem MG vollständig. Daher muss der MGC, um
Informationen von der vorhergehenden Einstellung aufzubewahren,
diese Informationen in die neue Einstellung einfügen. Wenn der MGC bestimmte
Informationen aus dem existierenden Deskriptor löschen möchte, sendet er lediglich (in
einem Modify-Befehl) den Deskriptor, in dem die unerwünschte Information
herausgestrichen ist, zurück.
-
Eigenschaften
-
Eigenschaften,
die durch das Paket definiert sind, welche spezifizieren:
- Eigenschaftsname:
nur deskriptiv
- Eigenschafts-ID: Ist eine Kennung
...
-
Definiert in:
-
Die
Eigenschaften sind in den gegebenen H.248 Deskriptoren definiert.
LocalControl (Lokale Steuerung) ist für stromabhängige Eigenschaften bestimmt.
TerminationState (Abschlus seinrichtungs-Zustand) ist für stromunabhängige Eigenschaften
bestimmt. ContextAttribute (Kontextattribut) ist für Eigenschaften
bestimmt, welche den Kontext als ein Ganzes beeinflussen, d. h.
Mischungs-Eigenschaften. Mux-Deskriptor ist für Eigenschaften bestimmt, welche
die charakteristischen Merkmale eines Multiplex beeinflussen. Es
ist zu erwarten, dass diese die häufigsten Fälle darstellen, doch es ist
möglich,
dass Eigenschaften in anderen Deskriptoren definiert werden. Kontext-Eigenschaften
MÜSSEN
in dem Deskriptor ContextAttribute definiert werden.
-
Mux-Typ
-
- Mux-Name: nur ein deskriptiver Name
- MuxID: Ist eine Kennung des Multiplex
-
Beschreibung:
-
Diese
beschreibt den Typ von Multiplex.
- H.248 Anhang A ASN.1 Syntax-Spezifikation
-
-
-
Für einen
Fachmann ist klar, dass verschiedene Modifikationen an den oben
beschriebenen Ausführungsformen
vorgenommen werden können,
ohne den Rahmen der vorliegenden Erfindung zu verlassen.
