DE60031303T2

DE60031303T2 - Verfahren und einrichtung zur effizienten anwendungsschicht-vermittlung für gemultiplexte-internet-medienströme

Info

Publication number: DE60031303T2
Application number: DE60031303T
Authority: DE
Inventors: Jarno Rajahalme; Pekka Pessi
Original assignee: Nokia Internet Communications Inc
Current assignee: Nokia Inc
Priority date: 1999-12-28
Filing date: 2000-12-28
Publication date: 2007-05-24
Anticipated expiration: 2020-12-29
Also published as: WO2001048976A2; DE60031303D1; EP1247420B1; US6829254B1; WO2001048976A9; WO2001048976A3; AU2741701A; EP1247420A2

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Diese Erfindung betrifft im Allgemeinen IP-Fernsprechwesen bzw. IP-Telefonie und insbesondere ein Verfahren und eine Vorrichtung zum Bereitstellen einer effizienten Vermittlung für gemultiplexte Internetprotokoll-Medienströme auf der Anwendungsschicht.
2. Beschreibung des Standes der Technik
Traditionell wurde Sprache über leitungsvermittelte Netzwerke (CSN) übertragen, die speziell für Sprachübertragung ausgelegt waren, zum Beispiel PSTN und GSM. Während der letzten 20 Jahre haben sich Telefonsysteme stetig verbessert und verändert, indem das Wirtschaftsleben von zuverlässiger Kommunikation zur Überwindung von Zeit- und Entfernungsbarrieren abhängig wurde. Folglich wurden unternehmensweite Kommunikationsplattformen entwickelt, um ein breites Angebot an Telefondiensten zur Verfügung zu stellen. Die auf diesen Plattformen verfügbaren Netzwerkdienste schließen automatisches Routing mit geringsten Kosten (Least-Cost-Routing) und Dienstklassen-Routing (Class-of-Service-Routing) sowie Anwendungen, wie zum Beispiel Sprachpost (Voice-Mail), Mobilitäts- und Anrufzentralen ein.
Im selben Zeitraum nahm auch Paketvermittlung zum, um zuverlässige und leicht zu verwendende Dateiübertragung, Transaktionsverarbeitung und Informationszugriff bereitzustellen. Paketvermittelnde Systeme wurden zuerst als proprietäre Systeme, die über private Leitungen betrieben wurden, implementiert. Heutzutage hat sich jedoch Paketvermittlung zu standardbasierenden, virtuellen Leitungsnetzwerken, wie zum Beispiel der Rahmenweiterleitung und asynchroner Transfermodus (bzw. Asynchronous Transfer Mode, ATM) sowie dem Internet entwickelt. Die Entwicklung und weite Implementierung des Ethernet in den 1980er Jahren führte zu Brücken- und Router- sowie erst kürzlich zur lokalen Bereichs netzwerk-(bzw. Local Area Network, LAN)-Vermittlung. Die Übertragungsgeschwindigkeiten haben sich erhöht, die Preise sich verringert und weltweit gibt es nun mehr als 200 Millionen Internet- und Ethernet-Anwender.
Derzeit besteht ein großes Interesse an der Sprachübertragung über paketvermittelte Netzwerke (bzw. Packet Swichted Networks, PSN). Die nächste große Entwicklung in der Telekommunikation wird die Zusammenführung des Internet mit Mobiltelefonen und anderen Geräten sein, wie zum Beispiel den persönlichen digitalen Assistenten (bzw. Personal Digital Assistants, PDAs). Bald werden Konsumenten kleine Kommunikationsgeräte verwenden, die Merkmale, wie zum Beispiel mobile Telefone, Internetterminals, Musiksysteme, Videosysteme, Kameras etc., in sich vereinen. Weiter bietet das Internet und die wachsende Konvergenz um das Internetprotokoll (IP) große Gelegenheiten für das Wirtschaftsleben, neue Märkte zu erobern, Kunden besser zu bedienen, Kosten zu reduzieren und die Produktivität zu verbessern.
Die größte Herausforderung, mit der die IP-Telefonie konfrontiert wird, wird die Aufnahme geschäftskritischer Anwendungen sein. Diese schließen Anrufzentralen (Call Centers), interaktive Sprachantwort (Interactive Voice Response, IVR) und andere sprachaktivierte Anwendungen, Mobilitäts- und Einzelnummer-Roaming-Dienste und vereinheitlichtes Benachrichtigen ein.
Diese Anwendungstypen betonen die Notwendigkeit der IP-Telefonie, um das schwierige Problem der Übertragungsqualität anzusprechen. Im Laufe der Zeit wurde das Telefonnetzwerk sehr zuverlässig und liefert einen beständigen Dienst mit hoher Qualität. Im Gegensatz ist in heutigen Intra-Netzen und dem öffentlichen Internet die Dienstqualität nicht existent. Zeiten für das Herunterladen von Dateien und die erforderliche Zeit, um eine Netzseite aufzurufen, variieren und die Zeit für eine E-Mail, um ihr beabsichtigtes Ziel zu erreichen, ist von vielen Netzwerkfaktoren abhängig. Im Mittelpunkt der meisten Anstrengungen stand die Erhöhung der Bandbreite der Internetlinks, um die Dienstqualität zu verbessern. Jedoch stellt Erhöhen der Bandbreite nur eine teilweise Lösung auf kurze Sicht dar. Auf lange Sicht sind andere Strategien erforderlich.
Im Moment bieten IP-Netzwerke eine einzige Dienstklasse, die beste Bemühung (Best Effort) genannt wird, die keinerlei Dienstqualität (bzw. Quality of Service, QoS) für Anwendungen garantieren kann. Um verzögerungssensitive Anwendungen, wie zum Beispiel Sprache und interaktives Multimedia, zu unterstützen, gab es viele Vorschläge, die der Internet Engineering Task Force (IETF) eingereicht wurden, dafür, wie QoS in IP-Netzwerken zu integrieren sei. Diese Vorschläge schließen differenzierten Dienst (diff-serv), integrierte Dienste (int-serv) und Mehrprotokoll-Kennzeichen-Vermittlung (bzw. Multi Protocol Label Switching, MPLS) ein. Trotz dieser Anstrengungen ist QoS in IP noch exklusiv und es könnte einige Zeit dauern, bevor sie sich über das globale Internet entfaltet hat.
Wie oben vorgeschlagen, ist IP-Telefonie als eine potenzielle Anwendung aufgetaucht, um die herkömmlichen Telefonunternehmen mit dem Angebot von Ferntelefondiensten über das Internet zu niedrigen Preisen herauszufordern. Es gibt eine große Anzahl von Ausstattungsherstellern, die IP-Telefonie-Gateways und Zubehör anbieten, um einen IP-Telefondienst Unternehmenskunden und Internetdienstanbietern (bzw. Internet Service Providers, ISPs) zur Verfügung zu stellen. IP-Telefonstandards, wie zum Beispiel H.323, H.225 und H.245 sind standardisiert worden, um die rasende Entwicklung von IP-Telefondiensten im weltweiten Internet zu verbessern. Trotzdem ist IP-Telefonie keine Realität im öffentlichen Internet heutzutage, es war erfolgreicher in Intra-Netwerk- und virtuellen privaten Netzwerk-(VPN)-Umgebungen.
In Versuchen haben IP-Telefondienste demonstriert, dass sie das Potenzial besitzen, die Sprachqualität, die durch herkömmliche Telefonnetzwerke angeboten wird, zu erfüllen. Folglich wird erwartet, dass das Wachstum der IP-Telefon-Gateways in Unternehmens- und ISP-Umgebungen in den kommenden Jahren exponentiell ansteigt. IP-Telefon-Gateways handeln als Schnittstelle zwischen den bestehenden PSTN- und PBX-Netzwerken und IP-Netzwerken. Dieses Verfahren ermöglicht es einem PSTN-Anwender, andere PSTN-Anwender, die über IP-Telefon-Gateways verbunden sind, anzurufen, sodass der Bedarf an einem Telefonnetzwerk für große Entfernungen beseitigt wird.
In einer IP-Telefonverbindung sind zwei Seiten der PSTN/PBX-Anwender (zwei Zweige desselben Unternehmens) durch IP-Telefon-Gateways verbunden. In einer solchen Anwendung wird ein Telefonanruf zwischen PSTN/PBX-Anwendern, die sich an beiden Seiten der Gateways befinden, über eine separate Echtzeittransportprotokoll-/Anwenderdatagrammprotokoll-/Internetprotokoll-(bzw. Real-time Transport Protocol/User Datagram Protocol/Internet Protocol, RTP/UDP/IP)-Verbindung übertragen. RTP ist ein Internetprotokoll zum Übertragen von Echtzeitdaten, wie zum Beispiel Audio und Video. RTP selbst garantiert keine Echtzeitauslieferung von Daten, stellt aber Mechanismen für die sendende und empfangende Anwendung bereit, um das Strömen bzw. Streamen von Daten (bzw. Data Streaming) zu unterstützen. Typischerweise läuft RTP auf dem UDP-Protokoll, obwohl die Spezifikation im Allgemeinen ausreichend wäre, andere Transportprotokolle zu unterstützen. Das Anwenderdatagrammprotokoll ist ein verbindungsloses Protokoll, das, ähnlich wie TCP, auf IP-Netzwerken läuft. Unähnlich zu TCP/IP, stellt UDP/IP sehr wenig Fehlerbehebungsdienste bereit, wobei es stattdessen einen direkten Weg anbietet, um Datagramme über ein IP-Netzwerk zu senden und zu empfangen.
IP-Telefonie-Gateways stellen eine Schnittstelle zwischen den bestehenden leitungsvermittelten Telefonnetzwerken (wie zum Beispiel PSTN und GSM) und den paketvermittelten IP-Datennetzwerken bereit. In herkömmlichen IP-Telefonieanwendungen, erzeugen Telefonanrufe zwischen PSTN-Anwendern, die durch ein Paar von IP-Telefonie-Gateways verbunden sind, um ankommende PSTN-Sprachsamples zu komprimieren, Pakete mit Größen, die sich im Bereich von 5 bis 20 Bytes pro Sprachsample bewegen.
Zum Beispiel erzeugt G.723.1 (der populärste IP-Telefonie-Codec und der zwingend vorgeschriebene Codec mit niedriger Bitrate für Sprache über IP (bzw. Voice over IP, VoIP) des Internationalen Multimedia Telekonferenz-Konsortiums (bzw. International Multimedia Teleconferencing Consortium, IMTC) erzeugt ein 20-Byte-Sprachpaket mit 30-ms-Intervallen. Viele in zellenförmigen Umgebungen verwendete Codecs erzeugen kleinere als ein 10-Byte-Paket pro Sprachsample. Pakete mit kleiner Größe unterliegen einem großen Overhead, wenn sie unter Verwendung des Echtzeittransportprotokolls (RTP) übertragen werden. Der RTP/UDP/IP-Overhead beträgt 40 Bytes (12 + 8 + 20) für ein einfaches Sprachpaket. zum Beispiel erhöht ein 10-Byte-Paket, das über RTP/UDP/IP übertragen wird, den Overhead auf 80% (40 Byte Overhead/50 Byte Overhead plus Paket).
Zusätzlich wird für jede Anrufanforderung eine einzelne UDP/IP-Verbindung (ein Paar an UDP-Ports) zwischen den Gateways aufgebaut, wobei es erforderlich ist, einen großen Status (Speicher) an den Telefonie-Gateways zu verwalten, wodurch diese weniger skalierbar gemacht werden.
Verkehrsstau in IP-Netzwerken führt zu Paketverlust an Routern und UDP besitzt keinerlei Neuübertragungsmechanismus, um verlorene Pakete wieder herzustellen. Auch sind Echtzeitanwendungen, wie zum Beispiel Sprache, für Verzögerungen intolerant, die durch Neuübertragung verursacht werden. In einem herkömmlichen RTP-Verfahren wird jedes individuelle Sprachpaket als ein IP-Paket übertragen, was eine große Anzahl an Paketen zwischen den Gateways erzeugt. Dieses starke Verkehrsvolumen stellt eine potenzielle Situation für Verkehrsstauung und Paketverlust an IP-Routern dar.
Um dieses Problem zu lösen, wurde ein Verfahren und eine Vorrichtung mit effizientem Echtzeittransportprotokoll-Multiplexing zum Transport komprimierter Sprache zwischen IP-Telefonie-Gateways vorgeschlagen in einer parallel anhängigen und gemeinschaftlich eingetragenen U.S.-Patentanmeldung S/N 09/137,276, von Baranitharan Subbiah, mit dem Titel "METHOD AND APPARATUS FOR PROVIDING EFFICIENT USER MULTIPLEXING IN A REAL-TIME PROTOCOL PAYLOAD FOR TRANSPORTING COMPRESSED SPEECH BETWEEN IP TELEPHONY GATEWAYS", auf die hier als "Subbiah" Bezug genommen wird. Subbiah beschreibt ein Protokoll, das Unwirtschaftlichkeiten der Bandbreitennutzung bei der Übertragung kurzer Pakete zwischen Knoten, die durch ein IP-Netzwerk verbunden sind, beseitigt, wobei das Verfahren und die Vorrichtung einer Anzahl an Anwendern ermöglicht, eine einzige RTP/UDP/IP-Verbindung gemeinsam zu nutzen bzw. zu teilen. Das Protokoll enthält Erzeugen eines Kopfes bzw. Headers für eine Vielzahl von Datenpaketen, wobei jeder Header eine Identifizierung bzw. Kennung eines Anwenders, der einem Paket zugeordnet ist, zur Verfügung stellt, Hinzufügen jedes Headers zu dem damit zugeordneten Datenpaket, um Mini-IP-Nutzlasten bzw. Mini-IP-Payloads zu bilden, Multiplexen der Mini-IP-Nutzlasten in eine RTP-Nutzlast und Übertragender RTP-Nutzlast über eine einzige RTP/UDP/IP-Verbindung.
Während Subbiah ein Verfahren und eine Vorrichtung offenbart zum Bereitstellen von Multiplexen auf Anwendungsschicht in IP-Netzwerken, um das Problem von einem großen Header-Overhead für Pakete mit kleinen Nutzlasten zu beseitigen, bleiben einige Probleme bestehen. Zum Beispiel, wenn das Multiplexing nur zwischen zwei IP-Knoten verwendet wird, gibt es keine Notwendigkeit zur Vermittlung. Jedoch, wenn komplexere Topologien berücksichtigt werden, tritt das Vermittlungsproblem der gemultiplexten Ströme auf.
Dokument D1: GB-A-2 322 515 betrifft ein Anpassungsschicht-Vermittlungsnetzwerk, in dem funktionelle Partitionierung eine Trennung zwischen dienstspezifischen Unterschichten und gemeinsamen Teil-Unterschichten zur Verfügung stellt.
Es ist daher ersichtlich, dass ein Bedarf an einem Verfahren und einer Vorrichtung besteht, die effizientes Vermitteln von gemultiplexten Strömen zur Verfügung stellen.
ZUSAMMENFASSUNG DER ERFINDUNG
Um die oben beschriebenen Einschränkungen im Stand der Technik zu beseitigen und um andere Einschränkungen, die beim Lesen und Verstehen der vorliegenden Beschreibung offensichtlich werden, zu beseitigen, offenbart die vorliegende Erfindung ein Verfahren und eine Vorrichtung zur effizienten Vermittlung gemultiplexter Ströme.
Die vorliegende Erfindung löst die oben beschriebenen Probleme durch Bereitstellen eines Verfahrens und einer Vorrichtung, die gemultiplexte Rahmen mit Kanalkennungen in gemultiplexten Strömen auf entsprechende Ausgabeströme und Kanalkennungen abbilden.
Ein System gemäß den Prinzipien der vorliegenden Erfindung enthält eine Vielzahl von Eingabeports zum Empfangen von Paketen zum Vermitteln, eine Vielzahl von Ausgabeports, wobei jeder der Vielzahl von Ausgabeports eine Ausgabewarteschlange besitzt, und ein Vermittlungswerk, das zwischen der Vielzahl von Eingabe- und Ausgabeports angeordnet ist, wobei das Vermittlungswerk von der Vielzahl von Ports empfangene gemultiplexte Ströme zu der Vielzahl von Ausgabeports vermittelt, wobei das Vermittlungswerk einen gemultiplexten Eingabestrom, zu dem ein empfangenes Paket gehört, identifiziert, die Kanalkennung von jedem Rahmen in dem empfangenen Paket merkt, einen gemultiplexten Ausgabestrom und zu dem gemultiplexten Eingabestrom korrespondierende Kanalkennung und eine Kanalkennung für jeden Rahmen in dem empfangenen Paket identifiziert, und jeden Rahmen zur Übertragung in die Ausgabewarteschlange, die dem identifizierten korrespondierenden gemultiplexten Strom und Kanalkennung zugeordnet ist, einfügt.
Andere Ausführungsbeispiele eines Systems gemäß den Prinzipien der Erfindung können alternative oder optionale zusätzliche Aspekte einschließen. Ein solcher Aspekt der vorliegenden Erfindung besteht darin, dass das Vermittlungswerk bestimmt, wenn eine Ausgabewarteschlange voll ist, und den Inhalt der Ausgabewarteschlange, wenn festgestellt wird, dass die Ausgabewarteschlange voll ist, sendet.
Ein anderer Aspekt der vorliegenden Erfindung besteht darin, dass das System weiter eine Eingabe-IP/ATM-Schnittstelle an jedem der Vielzahl von Ports enthält, zum Empfangen gemultiplexter IP-Pakete und zum Wandeln der empfangenen gemultiplexten IP-Pakete in ATM-Zellen als Pakete zum Vermitteln.
Ein anderer Aspekt der vorliegenden Erfindung besteht darin, dass die Eingabe-IP/ATM-Schnittstelle ein empfangenes gemultiplextes IP-Paket in eine ATM-Zelle wandelt durch Merken des Multiplex-Stroms, zu dem ein empfangenes gemultiplextes IP-Paket gehört, Identifizieren der Kanalkennung für jeden Medienrahmen in dem empfangenen gemultiplexten IP-Paket, Erzeugen einer neuen ATM-Nutzlast mit einem ATM-Zellenheader, wobei der ATM-Header ein VPI:VCI-Paar enthält, das von dem gemerkten gemultiplexten Strom und der identifizierten Kanalkennung abgebildet wurde, und Senden der neuen ATM-Nutzlast, die den Rahmenheader als ein neues Paket zum Vermitteln enthält.
Ein anderer Aspekt der vorliegenden Erfindung besteht darin, dass die Rahmen zum Übertragen in den Ausgabewarteschlangen ATM-Zellen mit einer Nutzlast enthalten.
Ein anderer Aspekt der vorliegenden Erfindung besteht darin, dass das System weiter Ausgabe-IP/ATM-Schnittstellen enthält, die jedem der Vielzahl an Ausgabeports zugeordnet sind, zum Wandeln von ATM-Zellen in gemultiplexte IP-Pakete, wobei die IP/ATM-Schnittstellen, die die ATM-Zellen in gemultiplexte IP-Pakete wandeln, das VPI:VCI-Paar jeder der von den Warteschlangen als Rahmen zur Übertragung empfangenen ATM-Zellen merken, das VPI:VCI-Paar jeder der von den Warteschlangen als Rahmen zum Übertragen empfangenen ATM-Zellen in einen identifizierten gemultiplexten einer Kanalkennung zugeordneten Strom abbilden, die Nutzlast als ein Rahmen in eine IP-Ausgabewarteschlange des identifizierten gemultiplexten Stroms mit der Kanalkennung einfügen und die IP-Ausgabewarteschlange übertragen, wenn festgestellt wird, dass die IP-Ausgabewarteschlange voll ist.
Ein anderer Aspekt der vorliegenden Erfindung besteht darin, dass die Ausgabe-IP/ATM-Schnittstelle die Sequenznummer, Längenanzeige aus der ATM-Zelle wieder herstellt.
Diese und verschiedene andere Vorteile und neue Merkmale, die die Erfindung charakterisieren, werden im Einzelnen in den hieran angehängten Ansprüchen aufgezeigt und bilden einen Teil hiervon. Jedoch für ein besseres Verständnis der Erfindung, ihrer Vorteile und der durch ihre Verwendung erreichten Ziele, soll Bezug auf die Zeichnungen genommen werden, die einen weiteren Teil hiervon bilden und auf die begleitende Beschreibung, in der es veranschaulichte und beschriebene bestimmte Beispiele einer Vorrichtung gemäß der Erfindung gibt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Nun wird Bezug auf die Zeichnungen genommen, in denen gleiche Bezugszeichen durchgehend entsprechende Teile repräsentieren:
1 zeigt ein Anwendungsszenario, in dem zwei Seiten eines PSTN/PBX durch IP-Telefonie-Gateways verbunden sind;
2 veranschaulicht MINI-IP-Header zur Verwendung in gemultiplexten Paketen von unterschiedlichen Anwendern in einer einzigen Nutzlast gemäß der vorliegenden Erfindung;
3 veranschaulicht das Multiplexen von MINI-IP-Nutzlasten in einem RTP-Paket, das den MINI-IP-Header verwendet;
4 veranschaulicht das Problem beim Routing gemultiplexter Ströme in einer nicht-trivialen Topologie;
5 veranschaulicht das Multiplexing-Schema gemäß der vorliegenden Erfindung;
6 veranschaulicht das Vermittlungsverfahren, das durch ein Vermittlungswerk gemäß der vorliegenden Erfindung durchgeführt wird;
7 veranschaulicht eine Hardware-Implementierung des Vermittlungsverfahrens der vorliegenden Erfindung;
8a u. 8b veranschaulichen Flussdiagramme der Prozesse, die von den IP/ATM-Schnittstellen durchgeführt werden; und
9 veranschaulicht ein Blockdiagramm einer Hardware-Implementierung der vorliegenden Erfindung.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
In der folgenden Beschreibung des beispielhaften Ausführungsbeispiels wird Bezug auf die begleitenden Figuren genommen, die einen Teil hiervon bilden, und in denen im Wege einer Veranschaulichung das bestimmte Ausführungsbeispiel gezeigt ist, in dem die Erfindung angewendet werden kann. Es ist verständlich, dass andere Ausführungsbeispiele verwendet werden können, da strukturelle Veränderungen durchgeführt werden können ohne von dem Umfang der vorliegenden Erfindung abzuweichen.
Die vorliegende Erfindung stellt ein Verfahren und eine Vorrichtung zum effizienten Vermitteln von gemultiplexten Strömen durch Abbilden gemultiplexter Rahmen mit Kanalkennungen in gemultiplexten Strömen auf entsprechende Ausgabeströme und Kanalkennungen.
1 zeigt ein Anwendungsszenario 100, in dem zwei Seiten des PSTN/PBX 100, 112 (zwei Zweige desselben Unternehmens) durch IP-Telefonie-Gateways 120, 122 verbunden sind. In einer derartigen Anwendung wird ein Telefonanruf zwischen PSTN/PBX-Anwendern 110, 112, die an beiden Seiten der Gateways 120, 122 angeordnet sind, durch eine separate RTP/UDP/IP-Verbindung übertragen. Die an dem Telefonie-Gateway verwendeten Codecs zur Komprimierung ankommender PSTN/PBX-Sprachanrufe erzeugen Pakete mit einer Größe, die sich im Bereich von 5 bis 20 Bytes bewegt.
Zum Beispiel spezifiziert der IP-Telefonie-Standard G.723.1 einen Codec, der ein 20-Byte-Paket an dem Intervall eines 30-ms-Sprachsamples erzeugt. Viele Codecs, die in zellenförmigen Umgebungen verwendet werden, erzeugen ein kleines Paket, zum Beispiel im Durchschnitt ein 10-Byte-Paket pro Sprachsample. Diese Pakete mit kleiner Größe erfordern einen großen Overhead, wenn sie unter Verwendung des Echtzeit-Transportprotokolls (RTP) übertragen werden.
Der RTP/UDP/IP-Overhead beträgt 40 Bytes (12 + 8 + 20) für jedes Sprachpaket. Wenn zum Beispiel ein 10-Byte-Paket via RTP/UDP/IP übertragen wird, dann beträgt der Overhead 80%, das heißt 40/50. Zusätzlich wird für jeden Anruf ein Paar an separaten UDP/IP-Verbindungen, eine in jede Richtung, zwischen den Gateways 120, 122 aufgebaut, wobei eine große Zahl an Protokollsteuerblöcken (Speicher), die an den Telefonie-Gateways 120, 122 zu verwalten sind, erforderlich ist.
Verkehrsstauung in IP-Netzwerken führt zu Paketverlust an Routern und UDP besitzt keinen Neuübertragungsmechanismus, um verlorene Pakete wieder herzustellen. Außerdem sind Echtzeitanwendungen, wie zum Beispiel Sprache, intolerant für durch Neuübertragung verursachte Verzögerung. In einem herkömmlichen RTP-Verfahren wird jedes individuelle Sprachpaket als ein separates IP-Paket übertragen, was eine große Anzahl an Paketen zwischen Gateways erzeugt. Dieses hohe Verkehrsvolumen stellt eine potenzielle Situation für Verkehrsstauung und Paketverlust an IP-Routern dar.
Der große Overhead, um kleine Pakete (komprimierte Sprache) durch RTP/UDP/IP zu übertragen, war einer der Nachteile der IP-Telefonie. Um den Overhead zu minimieren, wird RTP/UDP/IP-Header-Kompression bzw. -Komprimierung für Links mit langsamer Geschwindigkeit angewendet. Jedoch erfordert dieses Verfahren an Routern Kompression/Dekompression sowie einigen zusätzlichen Verarbeitungs-Overhead.
Die 2 und 3 veranschaulichen die Verwendung von MINI-IP-Headern, um den Header-Overhead gemäß dem MINI-IP-Protokoll zu reduzieren. Selbst ohne Kompression kann noch eine gleiche oder bessere Bandbreiteneffizienz erreicht werden. Overhead wird durch Multiplexen von zwei oder mehreren (zum Beispiel bis zu 256) Verbindungen mit geringer Bitrate in einer einzigen RTP/IP/UDP-Verbindung reduziert, die einen MINI-IP-Header 202, wie in 2 veranschaulicht, verwendet. Jedoch werden Fachleute erkennen, dass die vorliegende Erfindung nicht auf den bestimmten in 2 veranschaulichten MINI-IP-Header ist, beschränkt werden soll, sondern dass der MINI-IP-Header 202, der in 2 veranschaulicht ist, lediglich zur Veranschaulichung gezeigt ist. Eher werden Fachleute erkennen, dass der MINI-IP-Header 202 Multiplexen von mehreren Paketen mit kleiner Größe, wie in 3 veranschaulicht, ermöglicht.
Um einen einzelnen Anwender unter der Anzahl von Anwendern, die sich die RTP-Verbindung teilen, zu identifizieren, ist jedem Anwender eine einzigartige Kanalkennung (bzw. Channel Identifier, CID), zugeordnet, die während des Verbindungsaufbaus ausgehandelt wird. Die CID-Aushandlungsprozedur wird durch MINI-IP-Signalisierung ausgeführt, die eine TCP/IP-Verbindung für einen zuverlässigen Transport verwendet. Die geeignetsten Anwendungsszenarios für MINI-IP-Verfahren schließen IP-Telefonie-Gateways, die PSTN/PBX/GSM-Anwender verbinden, ein.
Um Mini-Pakete, die auf einer einzigen RTP-Nutzlast gemultiplext sind, zu identifizieren, verwendet MINI-IP einen 2-Byte-Header, genannt MINI-IP-Header bzw. MINI-IP-Kopf, für jedes Mini-Paket. Der MINI-IP-Header 202, wie in 2 gezeigt, schließt eine Kanalkennung (CID) 210 und eine Längenanzeige (bzw. Length Indicator, LI) 212 ein. Der MINI-IP-Header 202 ermöglicht es vielen Anwendern, sich eine einzige RTP/UDP/IP-Verbindung zu teilen, wobei so der RTP/UDP/IP-Overhead pro Paket reduziert wird.
Wie in 2 veranschaulicht, schließt der MINI-IP-Header ein CID-Feld 210 ein, welches einen einzigen Anwender unter den Anwendern, die eine einzige RTP/UDP/IP-Verbindung besitzen, identifiziert. Eine CID 210 wird zum Zeitpunkt der Anforderung für Zugriff auf das IP-Netzwerk zugeordnet und bleibt unverändert die Verbindungszeit hindurch. Die Länge des CID-Felds 210 beträgt 8 Bits, was die Anzahl der Anwender pro einzelner RTP-Verbindung auf 256 beschränkt.
Das LI-Feld 212 zeigt die Größe der Nutzlast (Sprachpaket) an und die 6 Bits erlauben ein Maximum von 64 Byte für eine Nutzlast. Die variable Größe des LI-Felds 212 erlaubt verschiedenen Codecs, sich eine einzige Verbindung zu teilen und bietet jeder Verbindung mit niedriger Bitrate, die MINI-IP-Verfahren verwendet, flexiblen Transport an. Die Größe des LI-Felds 212 ist auf 64 Bytes beschränkt, da die meisten der heute verfügbaren Codecs (G.723.1, G.729) Pakete mit weniger als 20 Bytes pro Sprachsample erzeugen.
Wie oben erwähnt, werden Fachleute erkennen, dass die obige Veranschaulichung von MINI-IP-Headern nicht beabsichtigt, die Erfindung zu beschränken, aber dass andere MINI-IP-Headerkonfigurationen und -größen gemäß der vorliegenden Erfindung verwendet werden könnten. Zum Beispiel könnte die Länge des Feldes innerhalb des 2-Byte-Formats modifiziert werden. Weiter könnten andere Felder ersetzt werden und die Länge der Felder bedeutet nicht, darauf beschränkt zu sein, einen MINI-IP-Header mit 2 Bytes zur Verfügung zu stellen. Nichtsdestoweniger werden Fachleute erkennen, dass Erhöhungen der Gesamtgröße des MINI-IP-Headers proportional den Gesamt-Overhead erhöhen werden, wenn mehrere MINI-IP-Pakete zusammen gemäß der Erfindung gemultiplext werden. Daher werden Fachleute erkennen, dass jeder MINI-IP-Header, der Multiplexing von mehreren Paketen mit kleiner Größe ermöglicht, zu jedem Mini-Paket hinzugefügt wird, bevor es mit anderen Mini-Paketen zu einer RTP-Nutzlast, wie in 3 veranschaulicht, zusammengesetzt wird, und was eine ordentliche Verarbeitung mehreren Mini-Pakete ermöglicht, verwendet werden kann, ohne von dem Bereich der vorliegenden Erfindung abzuweichen.
Das Zusammensetzen von Mini-Paketen zu einer einzelnen RTP/UDP/IP-Nutzlast 300 ist in 3 gezeigt. Die Mini-Pakete 310 folgen dem RTP-Header 312 und jedes Mini-Paket 320 ist durch den 2-Byte-MINI-IP-Header 312 abgegrenzt. Dieser Ansatz erfordert einen einfachen Demultiplex-Algorithmus am Empfänger. Da der MINI-IP-Header 312 in der RTP-Nutzlast 300 für die Zwischen-IP-Router transparent ist, verursacht das MINI-IP gemäß der vorliegenden Erfindung keine Probleme im Hinblick auf IP-Paketweiterleitung und andere Funktionalität auf der IP-Schicht. Die herkömmlichen Headerfehlersteuerungen (bzw. Header Error Controls, HEC), die sich in vielen Protokollen finden, ist ausgeschlossen, da MINI-IP sich auf die Prüfsumme auf höherer Schicht (UDP-Prüfsumme) stützt, um die Header und Nutzlast vor beliebigen Übertragungsfehlern zu schützen.
Die MINI-IP-Steuerung ist das Schlüsselelement, das zu einem IP-Telefonie-Gateway hinzugefügt wird, um das MINI-IP-Verfahren zu implementieren. Die Hauptfunktion der MINI-IP-Steuerung sind:

i. Aushandlung der Kanalkennung mit einem entferntem Gateway auf eine Verbindungsanforderung hin
ii. Multiplexen von Sprachpaketen von einer Anzahl von Anwendern in eine einzige RTP-Nutzlast
iii. Zerlegen von MINI-IP-Paketen aus der RTP-Nutzlast
iv. Kommunizieren mit der entfernten Steuerung, um beliebige Anforderung und/oder Steuernachricht weiterzuleiten.

Jedoch wirft die Verwendung von einem derartigen Multiplex-Schema in nichttrivialen Topologien das Problem des Routings auf. 4 veranschaulicht das Routingproblem mit gemultiplexten Strömen in einer nichttrivialen Topologie 400. In 4 sind Multiplexer/Demultiplexer 410–428 an der Grenze eines Kernpaketnetzwerks 430 veranschaulicht. Ein Datenstrom 440 ist gezeigt, der zwischen Multiplexer/Demultiplexer 450 und Multiplexer/Demultiplexer 428 fließt. Von Multiplexer/Demultiplexer 428 kann gesehen werden, dass die individuellen Ströme 460 gewöhnlich nicht die gleiche Route bzw. den gleichen Leitweg von Ende zu Ende durch das Netzwerk verwenden. Mit anderen Worten individuelle Sprachrahmen 460 müssen unabhängig voneinander an einigen Punkten in dem Netzwerk 430 geroutet bzw. geleitet werden.
Da viele Rahmen, die zu mehreren Medien-Strömen gehören, zu einem Netzwerkpaket gemultiplext sind, kann das darunter liegende Paketnetzwerk das Routing nicht ohne Trennung der gemultiplexten Ströme 440 in viele unabhängige Netzwerkströme 460 durchführen. Sobald demultiplext wird, erhöht sich der Header-Overhead pro Paket von 1 bis 2 Bytes auf bis zu 50 Bytes (eine typische Nutzlast beträgt 10 bis 20 Bytes pro Rahmen). Im schlimmsten Falle erhöht sich die Paketzahl bis zum 100-Fachen. In einem derartigen Kernnetzwerk 430 wird der Durchsatz durch den Overhead pro Paket begrenzt. Daher reduziert Demultiplexen das durchschnittliche Multiplexen auf dem gesamten Netzwerk 430 deutlich.
Gemäß der vorliegenden Erfindung wird jeder Medien-Rahmenstrom einzigartig identifiziert. 5 veranschaulicht Vermitteln von gemultiplexten IP-Strömen 500 auf Anwendungsschicht. Zum Beispiel wird in 5 jeder Medien-Rahmen mit einer Kanalkennung (CID) 510–514, zum Beispiel 1_n , 2_n , ... 6_n , identifiziert bzw. gekennzeichnet. Das heißt, jede CID 510–514 ist einem bestimmten gemultiplexten Strom, zum Beispiel S₁, zugeordnet. Darüber hinaus wird jeder Multiplex-Strom einzigartig gekennzeichnet durch das <Ziel-IP-Adresse, UDP-Portnummer>-Paar 530–534, auf dem die gemultiplexten Pakete zu empfangen sind. Der Empfänger soll nur von der beabsichtigten Quelle empfangen. Zufällige oder bösartige Pakete, die von anderen Quellen gesendet wurden, sollen verworfen werden, wenn sie empfangen werden. Diese Informationen können dann verwendet werden, um zu entscheiden, wie die individuellen Medien-Rahmen korrekt zu routen bzw. zu leiten sind.
Gemäß der vorliegenden Erfindung werden gemultiplexte Ströme in speziellen Netzwerkknoten vermittelt, wobei so der Paketheader-Overhead und die Last, die für das Netzwerk durch zahlreiche Pakete und Flüsse verursacht wird, vermieden wird. Da die Vermittlung anwendungsspezifisch ist, kann die Vermittlung leicht optimiert und in Hardware implementiert werden.
Zum Beispiel veranschaulicht Tabelle 1 unten eine Vermittlungstabelle.
TABELLE 1
Es sei angemerkt, dass die Kanalkennungen, die oben definiert wurden, in den ankommenden und abgehenden Multiplex-Strömen dieselben sind, um eine leichtere Veranschaulichung zu ermöglichen. Jedoch werden Fachleute erkennen, dass in einer echten Situation die Kanalkennungen wahrscheinlich in der Eingabe und der Ausgabe unterschiedlich sind.
Bezug nehmend auf 5 und Tabelle 1 kann gesehen werden, dass CID 1_n mit dem gemultiplexten Rahmenstrom S₁ zu dem gemultiplexten Ausgaberahmenstrom S₄ geroutet wird. Ähnlich werden CIDs 2_n , 4_n und 5_n mit gemultiplextem Rahmenstrom S₁, S₂ bzw. S₃ zum gemultiplexten Ausgaberahmenstrom S₅ geroutet. Schließlich werden CIDs 3_n und 6_n mit gemultiplextem Rahmenstrom S₃ bzw. S₁ zum gemultiplexten Ausgaberahmenstrom S₆ geroutet.
Die Vermittlung kann von einem Schalter bzw. Switch gemäß dem Flussdiagramm, das in 6 veranschaulicht ist, durchgeführt werden. Für jeden abgehenden Multiplex-Strom wird eine Ausgabewarteschlange 610 verwaltet. Eine Entscheidung wird dahingehend getroffen, ob die Warteschlange voll ist 630. Wenn die Warteschlange voll ist 634, wird ihr Inhalt gesendet 640. Der Füllgrad der Warteschlange kann durch die gespeicherte Datenmenge, durch die Zeit seit der der erste Medienrahmen in die Warteschlange aufgenommen wurde oder durch beliebige andere Mittel bestimmt werden.
Die Anfangsformation der Multiplex-Ströme und die zugeordneten Vermittlungstabellen werden in der Aufbauphase der Medienrahmenströme eingerichtet. Das Vermittlungsverfahren gemäß der vorliegenden Erfindung wird auf jeden der empfangenen gemultiplexten Pakete angewendet. Zuerst wird der Multiplex-Strom S_in, zu dem das Paket gehört, gemerkt. Dann wird für jeden Medienrahmen in dem Paket die Kanalkennung CID_in des Medienrahmens gemerkt 622, ein passendes der S_in:CID_in von der Vermittlungstabelle gefunden 624 und die korrespondierende S_out:CID_out wird gemerkt 626 und der Medienrahmen wird in die Ausgabewarteschlange von S_out mit der Kanalkennung CID_out eingefügt 628. Falls die Warteschlange nicht voll ist, werden zusätzliche Pakete verarbeitet 632.
Das obige Vermittlungsverfahren kann, wie in 7 veranschaulicht, in Hardware implementiert werden. Dies verringert Kosten, da es keiner Mehrzweck-CPU, keines Betriebssystems, keiner großen Mengen an Speicher, etc. bedarf. Die Verzögerung ist dann deterministisch mit weniger Jitter und wahrscheinlich höherem Durchsatz. Schließlich kann existierende ATM-Vermittlungshardware für auf IP basierendes Multiplex-Paketvermitteln wiederverwendet werden.
In 7 ist ATM-Vermittlungshardware veranschaulicht. IP-Ströme 710–714 sind gezeigt, die durch empfangende IP/ATM-Schnittstellen 720–724 empfangen wurden und an dem Ausgang des ATM-Switch 700 durch Ausgabe-IP/ATM-Schnittstellen 730–734 zur Verfügung gestellt werden. Für jedes empfangene gemultiplexte IP-Paket wandelt die empfangende IP/ATM-Schnittstelle 720–724 IP-Pakete in ATM-Zellen. Für jede ATM-Zelle, die durch das ATM-Vermittlungswerk 740 verarbeitet wurde, wandelt die Ausgabe-IP/ATM-Schnittstelle 730–734 ATM-Zellen in IP-Pakete.
8a und 8b veranschaulichen Flussdiagramme 800, 850 für die Prozesse, die von den IP/ATM-Schnittstellen durchgeführt werden. Von IP zu ATM, wie in 8a veranschaulicht, werden IP-Pakete am Eingang einer Eingabe-IP/ATM-Schnittstelle 810 empfangen. Der Multiplex-Strom S_in, zu dem dieses Paket gehört, wird gemerkt 812 und für jeden Medienrahmen in dem Paket wird die Kanalkennung CID_in des Medienrahmens gemerkt 814. Eine neue ATM-Nutzlast wird mit dem ATM-Zellenheader (VPI:VCI-Paar, das vom S_in:CID_in abgebildet ist) und den Mediendaten, einschließlich der Rahmenheaderinformationen (zum Bei spiel abgebildet auf AAL5 CPCS-PDU-Nachlauf) erzeugt 816 und die erzeugten Zellen werden an das ATM-Vermittlungswerk gesendet 818, wodurch die Eingabe-IP/ATM-Schnittstellenverarbeitung bis zusätzliche IP-Pakete empfangen werden, abgeschlossen wird 820.
An dem ATM-Vermittlungswerk werden die ATM-Zellen gemäß einer Vermittlungstabelle geroutet, zum Beispiel wie in Tabelle 1 oben veranschaulicht und unter Bezug auf 6 beschrieben. Fachleute werden erkennen, dass im Fall einer ATM-Vermittlungshardware die Multiplex-Stromkennung, das Kanalkennungspaar 1:1 auf das Triplet aus der ATM-Schnittstellenkennung, virtuellen Pfadkennung und virtuellen Kanalkennung abgebildet wird. Alle möglichen reservierten Werte für die VPI und/oder VCI können durch Blockierung der Verwendung der entsprechenden Kanalkennungen und Portnummern auf der IP-Seite vermieden werden. Entsprechend wird die Vermittlungstabelle des ATM-Vermittlungswerks mit den VPI:VCI-auf-VPI:VCI-Abbildungen, ähnlich zu den Abbildungen, die in der Tabelle 1 veranschaulicht sind, gefüttert.
Von ATM zu IP, wie in 8b veranschaulicht, verlassen die ATM-Zellen die Warteschlangen des ATM-Vermittlungswerks und werden den Ausgabe-IP/ATM-Schnittstellen 860 zur Verfügung gestellt. Für jedes empfangene Paket wird das VPI:VCI-Paar des Pakets erkannt und auf S_out:CID_out, abgebildet 862. Die Mediennutzlast wird als ein Medienrahmen in die IP-Ausgabewarteschlange von S_out mit der Kanalkennung CID_out, eingefügt, wobei außerdem die Sequenznummer, die Längenanzeige etc. wieder hergestellt wird 864 (zum Beispiel aus dem AAL5-artigen CPCS-PDU-Nachlauf). Das IP-Paket wird dann an der Ausgabe zur Verfügung gestellt 866.
9 veranschaulicht ein Blockdiagramm einer Vermittlung 900 zum Vermitteln gemultiplexter IP-Medienströme gemäß der vorliegenden Erfindung. Eine ATM-Vermittlung gemäß der vorliegenden Erfindung enthält einen Prozessor 910 und Speicher oder Zwischenspeicher bzw. Puffer 912, der in wahlfreiem Zugriffsspeicher (bzw. Random Access Memory, RAM) enthalten sein kann oder irgendeiner anderen Speicherkonfiguration. Der Prozessor 910 arbeitet unter der Steuerung eines Betriebssystems (nicht gezeigt) und ist konfiguriert, ein oder mehrere Computerprogramme auszuführen, die in 9 durch die "Schachtel" 930 inner halb des Blocks, der den Prozessor 910 anzeigt, repräsentiert wird. Im Allgemeinen können die Computerprogramme 930 berührbar in einem computerlesbaren Medium oder Träger 940 verkörpert sein. Die Computerprogramme 930 können von dem computerlesbaren Medium oder Träger 940 in Speicher 912 zur Ausführung durch den Prozessor 910, wie oben mit Bezug auf die 5 bis 8b beschrieben, geladen werden.
Das Computerprogramm 930 enthält Befehle bzw. Instruktionen, die, wenn sie durch den Prozessor 910 gelesen und ausgeführt werden, den Prozessor 910 veranlassen, die notwendigen Schritte durchzuführen, um die Schritte oder Elemente der vorliegenden Erfindung auszuführen. ATM-Zellen werden über Ports 942 empfangen, in Speicher 912 zwischengespeichert bzw. gepuffert und über Ports 942 unter Kontrolle des Prozessors 910 übertragen, der Portvermittlung wie oben unter Bezug auf die 5 bis 8b zur Verfügung stellt. Fachleute werden daher erkennen, dass Speicher 912 in Speichervorrichtungen zum Ablaufenlassen des Programms 930 und zum Puffern bzw. Zwischenspeichern von ATM-Zellen getrennt werden kann oder eine einzige Speichervorrichtung sein können.
Weiter, obwohl eine beispielhafte Systemkonfiguration in 9 veranschaulicht ist, werden Fachleute erkennen, dass eine beliebige Anzahl von unterschiedlichen Konfigurationen, die ähnliche Funktionen durchführen, gemäß der vorliegenden Erfindung verwendet werden können.
Zusammenfassend stellt die vorliegende Erfindung effizientes Vermitteln von gemultiplexten Medienrahmenströmen auf der Anwendungsschicht zur Verfügung. Weiter kann gemäß der vorliegenden Erfindung ATM-Hardware verwendet werden, um eine effiziente Hardware-basierte Implementierung zur Verfügung zu stellen.

Claims

Verfahren zum Vermitteln gemultiplexter Ströme in einer ATM-Vermittlung mit: Empfangen (620) eines Pakets zum Vermitteln, wobei das Paket eine Vielzahl von Rahmen aufweist; Identifizieren eines gemultiplexten Eingabestroms, zu dem das empfangene Paket gehört; Merken (622) einer ersten Kanalkennung (CID_in) jedes Rahmens in dem empfangenen Paket; Identifizieren (624) eines gemultiplexten Ausgabestroms und einer zweiten Kanalkennung (CID_out), die dem gemultiplexten Eingabestrom und der ersten Kanalkennung (CID_in) entsprechen, für jeden Rahmen in dem empfangenen Paket; und Einfügen (628) jedes Rahmens zur Übertragung in eine Ausgabewarteschlange, die mit dem identifizierten entsprechenden gemultiplexten Ausgabestrom und der zweiten Kanalkennung (CID_out) verknüpft ist.
Verfahren gemäß Anspruch 1, wobei es weiter Feststellen (630), wenn eine Wartenschlange voll ist, und Senden (640) der Inhalte der Wartenschlange, wenn festgestellt wird, dass die Warteschlange voll ist, aufweist.
Verfahren gemäß Anspruch 2, wobei der Schritt Empfangen eines Pakets zum Vermitteln weiter Umwandeln empfangener gemultiplexter IP-Pakete in ATM-Zellen aufweist.
Verfahren gemäß Anspruch 3, wobei der Schritt Umwandeln empfangener gemultiplexter IP-Pakete in ATM-Zellen weiter aufweist: Empfangen (810) eines gemultiplexter IP-Pakets; Merken (812) des gemultiplexter Stroms, zu dem dieses Paket gehört; Identifizieren (814) der ersten Kanalkennung (CID_out) für jeden Medienrah men in dem empfangenen Paket; Erzeugen (816) einer neuen ATM-Nutzlast mit einem ATM-Zellenheader, wobei der ATM-Header ein VPI:VCI-Paar, das aus dem gemerkten gemultiplexten Strom und der identifizierten ersten Kanalkennung (CID_in) abgebildet worden ist, beinhaltet; und Senden (818) der neuen ATM-Nutzlast, einschließlich des Rahmenheaders, als ein Paket zum Vermitteln.
Verfahren nach Anspruch 2, wobei die Rahmen zur Übertragung in der Wartenschlange ATM-Zellen aufweisen und wobei der Schritt Senden der Inhalte der Wartenschlange weiter Umwandeln der ATM-Zellen in gemultiplexte IP-Pakete aufweist.
Verfahren gemäß Anspruch 5, wobei der Schritt Umwandeln von ATM-Zellen in gemultiplexte IP-Pakete weiter aufweist: Empfangen von ATM-Zellen mit einer Nutzlast aus den Warteschlangen als Pakete zur Übertragung; Merken des VPI:VCI-Paars jeder der ATM-Zellen, die aus den Warteschlangen als Pakete zur Übertragung empfangen wurden; Abbilden des VPI:VCI-Paars jeder der ATM-Zellen, die aus den Wartenschlangen als Pakete zur Übertragung empfangen wurden, auf einen identifizierten gemultiplexten Strom, der mit einer Kanalkennung verknüpft ist; Einfügen der Nutzlast als ein Rahmen in eine IP-Ausgabewarteschlange des identifizierten gemultiplexten Stroms mit der Kanalkennung; und Übertragen der IP-Ausgabewarteschlange, wenn festgestellt wird, dass die IP-Ausgabewarteschlange voll ist.
Verfahren gemäß Anspruch 6, wobei es weiter Wiederherstellen einer Sequenznummer und eines Längenanzeigers aus der ATM-Zelle aufweist.
ATM-Vermittlung mit einer Vielzahl von Eingabeports (942) zum Empfangen von Paketen zum Vermitteln, wobei die Pakete eine Vielzahl von Rahmen besitzen, einer Vielzahl von Ausgabeports (942), wobei jeder der Vielzahl der Ausgabeports (942) eine Ausgabewarteschlange besitzt; und einem Vermittlungswerk, das zwischen der Vielzahl von Eingabe- und Ausgabeports angeordnet ist, wobei das Vermittlungswerk gemultiplexte Ströme, die von der Vielzahl von Eingabeports empfangen wurden, zu der Vielzahl von Ausgabeports vermittelt, wobei das Vermittlungswerk konfiguriert ist, einen gemultiplexten Eingabestrom, zu dem ein empfangenes Paket gehört, zu identifizieren, Mittel besitzt, die angepasst sind, eine erste Kanalkennung (CID_in) jedes Rahmens in dem empfangenen Paket zu merken, konfiguriert ist, einen gemultiplexten Ausgabestrom und eine zweite Kanalkennung (CID_out), die dem gemultiplexten Eingabestrom und der ersten Kanalkennung (CID_in) entsprechen, für jeden Rahmen in dem empfangenen Paket, zu identifizieren, und konfiguriert ist, jeden Rahmen zur Übertragung in die Ausgabewarteschlange, die mit dem identifizierten korrespondierenden gemultiplexten Ausgabestrom und der zweiten Kanalkennung (CID_out) verknüpft ist, einzufügen.
ATM-Vermittlung gemäß Anspruch 8, wobei das Vermittlungswerk Mittel zum Feststellen, wenn eine Ausgabewartschlange voll ist, und Mittel zum Senden der Inhalte der Ausgabewarteschlange, wenn festgestellt wird, dass die Ausgabewarteschlange voll ist, besitzt.
ATM-Vermittlung gemäß Anspruch 9, wobei sie weiter eine Eingabe-IP/ATM-Schnittstelle (720–724) an jedem der Vielzahl von Eingabeports zum Empfangen gemultiplexter IP-Pakete und Umwandeln der empfangenen gemultiplexten IP-Pakete in ATM-Zellen als Pakete zum Vermitteln aufweist.
ATM-Vermittlung gemäß Anspruch 10, wobei die Eingabe-IP/ATM-Schnittstelle (720 bis 724) besitzt Mittel zum Umwandeln eines empfangenen gemultiplexten IP-Pakets in eine ATM-Zelle durch Merken des Multiplexstroms, zu dem ein empfangenes gemultiplextes IP-Paket gehört, Identifizieren der Kanalkennung für jeden Medienrahmen in dem empfangenen gemultiplexten IP-Paket, Erzeugen einer neuen ATM-Nutzlast, die einen ATM-Zellenheader besitzt, wobei der ATM-Header ein VPI:VCI-Paar beinhaltet, das aus dem gemerkten gemultiplexten Strom und der identifizierten Kanalkennung abgebildet wurde, und Senden der neuen ATM-Nutzlast, einschließlich des Rahmenheaders, als ein Paket zum Vermitteln.
ATM-Vermittlung gemäß Anspruch 9, wobei die Rahmen zum Übertragen in den Ausgabewartschlangen ATM-Zellen, die eine Nutzlast besitzen, aufweisen.
ATM-Vermittlung gemäß Anspruch 12, weiter aufweisend Ausgabe-IP/ATM-Schnittstellen (730–734), die mit jeder der Vielzahl von Ausgabeports zum Umwandeln von ATM-Zellen in gemultiplexte IP-Pakete verbunden sind, wobei die Ausgabe-IP/ATM-Schnittstellen Mittel zum Umwandeln der ATM-Zellen in gemultiplexte IP-Pakete besitzen, das VPI:VCI-Paar jeder der ATM-Zellen, die aus den Wartenschlangen als Rahmen zur Übertragung empfangen worden sind, merken, das VPI:VCI-Paar jeder der ATM-Zellen, die aus der Warteschlange zum Rahmen als Übertragung empfangen wurden, auf einen identifizierten gemultiplexten Strom, der mit einer Kanalkennung verknüpft ist, abbilden, die Nutzlast als ein Rahmen in einer IP-Ausgabewarteschlange des identifizierten gemultiplexten Stroms mit der Kanalkennung einfügen, und die IP-Ausgabewartschlange, wenn festgestellt wird, dass die IP-Ausgabewartschlange voll ist, übertragen.
ATM-Vermittlung gemäß Anspruch 13, wobei die Ausgabe-IP/ATM-Schnittstelle konfiguriert ist, eine Sequenznummer und einen Längenanzeiger aus der ATM-Zelle wiederherzustellen.
Herstellungsartikel für eine prozessorgestützte ATM-Vermittlung, wobei der Herstellungsartikel aufweist ein computerlesbares Medium mit Befehlen zum Bewirken, dass ein Prozessor ein Verfahren ausführt, das aufweist: Empfangen (620) eines Pakets zum Vermitteln, wobei das Paket eine Vielzahl von Rahmen besitzt; Identifizieren eines gemultiplexten Eingabestroms, zu dem das empfangene Paket gehört; Merken (622) einer ersten Kanalkennung (CID_in) jedes Rahmens in dem empfangenen Paket; Identifizieren (624) eines gemultiplexten Ausgabestroms und einer zweiten Kanalkennung (CID_out), der dem gemultiplexten Eingabestrom und der ersten Kanalkennung (CID_in) entsprechen, für jeden Rahmen in dem empfangenen Paket; und Einfügen (628) jedes Rahmens zur Übertragung in eine Ausgabewart schlange, die mit dem identifizierten entsprechenden gemultiplexten Ausgabestrom und der zweiten Kanalkennung (CID_out) verknüpft ist.
Herstellungsartikel gemäß Anspruch 15, wobei er weiter Feststellen, wenn eine Warteschlange voll ist, und Senden der Inhalte der Warteschlange, wenn festgestellt wird, dass die Warteschlange voll ist, aufweist.
Herstellungsartikel gemäß Anspruch 16, wobei der Schritt des Empfangens eines Pakets zum Vermitteln weiter Umwandeln empfangener gemultiplexter IP-Pakete in ATM-Zellen aufweist.
Herstellungsartikel gemäß Anspruch 17, wobei der Schritt des Umwandelns empfangener gemultiplexter IP-Pakete in ATM-Zellen weiter aufweist: Empfangen (810) eines gemultiplexten IP-Pakets; Merken (812) des gemultiplexten Stroms, zu dem das Paket gehört; Identifizieren (814) der ersten Kanalkennung (CID_in) für jeden Medienrahmen in dem empfangenen Paket; Erzeugen (816) einer neuen ATM-Nutzlast, die einen ATM-Zellenheader besitzt, wobei der ATM-Header ein VPI:VCI-Paar beinhaltet, das aus dem gemerkten gemultiplexten Strom und der identifizierten Kanalkennung abgebildet ist; und Senden (818) der neuen ATM-Nutzlast, einschließlich des Rahmenheaders, als ein Paket zum Vermitteln.
Herstellungsartikel gemäß Anspruch 16, wobei die Rahmen zum Übertragen in der Warteschlange ATM-Zellen aufweisen und der Schritt des Sendens der Inhalte der Warteschlangen weiter Umwandeln der ATM-Zellen in gemultiplexte IP-Pakete aufweist.
Herstellungsartikel gemäß Anspruch 19, wobei der Schritt des Umwandelns von ATM-Zellen in gemultiplexte IP-Pakete weiter aufweist: Empfangen von ATM-Zellen, die eine Nutzlast besitzen, aus den Warteschlangen als Pakete zum Übertragen; Merken des VPI:VCI-Paars jeder der ATM-Zellen, die aus den Warteschlangen als Pakete zum Übertragen empfangen wurden; Abbilden des VPI:VCI-Paars jeder der ATM-Zellen, die aus den Warten schlangen als Pakete zum Übertragen empfangen wurden, auf einen identifizierten gemultiplexten Strom, der mit einer Kanalkennung verknüpft ist; Einfügen der Nutzlast als ein Rahmen in eine IP-Warteschlange des identifizierten gemultiplexten Stroms mit der Kanalkennung; und Übertragen der IP-Ausgabewarteschlange, wenn festgestellt wird, dass die IP-Ausgabewarteschlange voll ist.
Herstellungsartikel gemäß Anspruch 20, wobei er weiter Wiederherstellen der Sequenznummer, des Längenanzeigers aus der ATM-Zelle aufweist.