EP1287660A2 - Verfahren zum übertragen von sprachinformationen über ein internetprotokoll - Google Patents

Abstract

Verfahren zum Übertragen von Sprachinformationen über ein Internetprotokoll, die in Paketen zwischen wenigstens 2 Knoten über ein Link Layer Protokoll (PPP) ausgetauscht werden, indem die Header der Pakete komprimiert werden, und mit einem verbindungsorientierten Übertragungsprotokoll (MPLS), mit dessen Hilfe ein Tunnel zwischen den wenigstens 2 Knoten unidirektional erstellt werden kann, dadurch gekennzeichnet, dass zwischen den beiden Knoten in Vorwärts- und Rückrichtung jeweils ein Tunnel aufgebaut wird, dass anschliessend beide Tunnel zu einer bidirektionalen Verbindung kombiniert werden, wodurch eine bidirektionale Kommunikation ermöglicht wird,dass über jeweils einen Tunnel die Pakete des Link Layer Protokolls (PPP) geführt werden.

Description

  



  Beschreibung Verfahren zum Übertragen von Sprachinformationen über ein Internetprotokoll.



  Die Erfindung betrifft ein Verfahren gemäss dem Oberbegriff von Patentanspruch 1.



  Im Rahmen der Konvergenz von Sprach-und Datennetzen kommt der Übertragung von Sprache über IP Netze (Voice over IP,   VoIP)    eine immer grössere Bedeutung zu. Als Internetprotokoll haben sich Protokolle wie z. B. TCP/IP oder UDP/IP herauskristallisiert. Beim TCP Protokoll wird eine Sicherung durchgeführt, d. h. im Verlustfalle eines Paketes wird dieses erneut angefordert und übertragen. Beim UDP Protokoll hingegen entfällt diese Sicherung.



  Aus diesem Grund wird die Sprachübertragung beim Stand der Technik mit Hilfe eines Real-Time Protokolls wie z. B. dem   RTP    Real-Time Protokoll über UDP/IP gesteuert. Die Sprachinformationen tragenden Pakete sind meist relativ klein (Nutzteil ca. 40-80 Bytes). Zusätzlich wird dem die Nutzinformationenen tragenden Nutzteil des Paketes, ein Kopfteil (Header) vorangestellt, der ebenfalls eine Grösse von ca. 40 Byte aufweist. Letztendlich bedeutet dies, dass ein zu übertragendes Sprachpaket im Extremfall einen Nutzteil von 40 Byte aufweist, dem ein etwa gleich grosser Header vorangestellt ist.



  Das Paket weist somit einen Overhead von 100 % auf, so dass die Bandbreiten-Effizienz einer solchen Lösung als sehr gering anzusehen ist.



  In der IETF existieren verschiedene Konzepte zur Verbesserung dieser Bandbreiten-Effizienz bei   VoIP.    Diese basieren in der Regel auf einer Kompression der Header. Hierbei sind im wesentlichen 2 Verfahren bekannt, nämlich Link-basierte sowie Tunnel-basierte Verfahren :  Bei den Link-basierten Verfahren wird der gesamte   RTP    Header auf eine Grösse von 2-4 Bytes reduziert. Das Verfahren wird deshalb als Link-basiert bezeichnet, da das Verfahren lediglich auf die Übertragung zwischen zwei direkt benachbarten Knoten angewendet wird. Die Realisierung erfolgt mit Hilfe von PPP als Link-Layer Protokoll. Dieses Verfahren hat jedoch den Nachteil, dass die sehr aufwendige Kompression in jedem Knoten entlang einer   VoIP    Verbindung zwischen 2 Teilnehmern durchgeführt werden muss.

   Dies führt zu hoher Komplexität und hohen Kosten und ist bei hohen Bitraten nur sehr schwer zu realisieren.



  Bei   Tunnel-basierten    Verfahren erfolgt die Kompression End to End an den Eingangs-/Ausgangsknoten des Tunnels. Hierbei wird ein Tunnel zunächst zwischen 2 Knoten aufgebaut, über den dann später die Sprachinformationen übertragen werden. Der Aufbau des Tunnels erfolgt über ein zu Beginn der Übertragung gesendetes Signalisierungspaket oder administrativ. Da die Sprachinformationen im Tunnel übertragen werden, sind diese für die dazwischenliegenden Knoten unsichtbar.



  Es wurde bereits ein einfaches Verfahren zur Header Kompression bei MPLS (Multi Protocol Label Switching) vorgeschlagen.



  Dieses Verfahren erreicht bei   VoIP    jedoch lediglich eine Reduktion des Headers auf ca. die Hälfte der ursprünglichen 40 Byte. Die Effizienz des   Ubertragungsvorganges    ist damit nicht sonderlich hoch.



  Ein weiteres bekanntes Verfahren verwendet das bekannte L2TP Protokoll als Tunnel-Protokoll, mit dessen Hilfe sowohl PPP Multiplexing wie auch   RTP    Header Kompression End-End realisiert wird. Diese vorgeschlagene Lösung hat den Vorteil, mit der standardisierten RTP Header Kompression kompatibel zu sein. Ausserdem können mehrere Sprachpakete zu einem grösseren Paket kombiniert werden. Problematisch hieran ist, dass auch hier nur eine Reduktion des Headers auf ca. die Hälfte der ursprünglichen 40 Byte erreichbar ist. Ferner ist auch hier die   Dienstgüte    nicht sonderlich hoch, da beispielsweise keine Ressourcen reserviert werden können (verbindungsloses Protokoll).



  Der vorliegenden Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, wie eine effizientere Übertragung von Sprachinformationen über IP Netze erreicht werden kann.



  Vorteilhaft an der Erfindung ist, dass anstelle des bekannten L2TP Tunnel-Mechanismus der MPLS Tunnel-Mechanismus verwendet wird. Damit ist eine bessere Effizienz gegeben. Erfindungsgemäss wird   RTP    Kompression und PPP Multiplexing innerhalb eines MPLS Tunnels realisiert.



  Damit ist insofern eine hohe Effizienz gegeben, da anstelle von 36 Bytes für den kombinierten IP/UDP/L2TP Header nur der MPLS Header (4 Bytes) sowie der PPP Header (1-2 Bytes) übertragen werden muss. Ferner sind hier eine garantierte Bandbreite und   Dienstgüte    gegeben. Dies liegt darin begründet, dass MPLS Tunnel verbindungsorientiert sind und demzufolge sowohl garantierte Bandbreiten (durch explizite Reservierung) als auch geringe Verzögerungsschwankungen ermöglichen. Diese Anforderungen können beim Aufbau des Tunnels signalisiert werden.



  Ein weiterer Vorteil der Erfindung ist darin zu sehen, dass keine Reihenfolgefehler entstehen. So kann durch eine entsprechende Parameterisierung sichergestellt werden, dass die Paketreihenfolge innerhalb des Tunnels erhalten bleibt. Eine Rekonstruktion der ursprünglichen Paketreihenfolge wie bei L2TP entfällt somit.



  Darüberhinaus bringt die erfindungsgemässe Vorgehensweise eine hohe Zuverlässigkeit mit sich. So kann ein mit MPLS Protection Switching ausgerüsteter MPLS Tunnel im Fehlerfall sehr schnell umgeschaltet oder wiederhergestellt werden. L2TP ist im Gegensatz dazu von der Konvergenz der IP Routing  Protokolle abhängig, so. dass   Knoten-oder Leitungsausfälle    zu Unterbrechungen von mehreren 10 Sekunden führen können.



  Letztlich ist ein besonderer Vorteil der Erfindung in einer kontrollierten Auswahl der Wege insofern zu sehen, dass der Weg eines MPLS Tunnels im Netz durch den Betreiber direkt beeinflusst werden kann. Mit Hilfe von MPLS Explicit Routing können so einzelne Knoten oder Gruppen von Knoten entlang des Weges vorgegeben werden. Auf diese Weise kann der Sprachverkehr gezielt durch das Netz gesteuert werden, um beispielsweise langsame oder unzuverlässige Leitungen zu umgehen.



  Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.



  Die Erfindung wird im folgenden anhand eines   figürlich    dargestellten Ausführungsbeispieles näher erläutert.



  Es zeigen : Fig 1 ein Paketformat, das für die Übertragung von PPP in
MPLS verwendbar ist, Fig 2 den erfindungsgemässen Algorithmus In Fig.   1    ist beispielhaft ein Paketformat aufgezeigt, das für die Übertragung von PPP in MPLS verwendet werden kann.



  Demgemäss folgt das PPP Protokoll Feld direkt auf den MPLS Header. Die PPP Nutzdaten können beispielsweise mehrere komprimierte   RTP    Pakete enthalten. Damit ergibt sich ein minimaler Overhead von 4 Bytes pro Sprachpaket, zuzüglich MPLS und PPP Header von 5 oder 6 Bytes. Bei 10 Sprachpaketen von je 40 Bytes in einem MPLS Paket ergibt sich somit eine Bandbreiteneffizienz von 400/446 oder rund   90%.   



  Im folgenden werden in Fig. 2 die einzelnen Schritte für den Aufbau eines Tunnels am Beispiel von TE-RSVP als Signalisierprotokoll beschrieben :  In einem ersten Schritt wird zunächst der Aufbau eines unidirektionalen MPLS Tunnels von einer Seite initiiert. Der Aufbau des Tunnels erfolgt mit Hilfe des TE-RSVP Signalisierprotokolls. Dieses enthält ein Label Request Objekt, welches u. a. das zu übertragende Protokoll definiert. Hier muss der Wert   Ox880B    für PPP angegeben werden.



  Das Session Attribute Objekt des TE-RSVP Signalisierprotokolls enthält einen Session Namen, der im Prinzip frei wahlbar ist. Der Session Name muss allerdings den Tunnel eindeutig für Eingangs-und Ausgangsknoten identifizieren. Der Session Name zusammen mit den IP Adressen von Eingangs-und Ausgangsknoten muss somit eindeutig sein.



  Ferner muss das LSP Tunnel Session Objekt die IP Adresse des Eingangsknotens als Extended Tunnel ID enthalten. Diese Adresse wird später zur Adressierung beim Aufbau des Tunnels in Rückrichtung genutzt.



  Letztlich wird in der Regel für den Tunnel eine Bandbreite reserviert, und es können spezielle Delay-Anforderungen signalisiert werden.



  Mit der Angabe dieser Informationen wird der Tunnel in Vorwärtsrichtung aufgebaut. In einem zweiten Schritt wird nun der   Tunnelaufbau    in Rückrichtung durchgeführt. Der Knoten am Tunnelausgang (in Vorwärtsrichtung gesehen) erkennt anhand des Protokolltyps PPP, dass eine bidirektionale Kommunikation notwendig ist, und leitet seinerseits den Aufbau des Tunnels in Rückrichtung ein. Sowohl Protokolltyp als auch Session Name müssen zwingend mit der Vorwärtsrichtung übereinstimmen.



  Zusammen mit den IP Adressen der Endpunkte wird dadurch die Kombination der beiden Tunnel zu einem bidirektionalen Link ermöglicht. Als Zieladresse wird die IP Adresse des Eingangsknotens verwendet, die beim Tunnelaufbau in Vorwärtsrichtung festgelegt wurde. 



  Sobald beide Tunnel erfolgreich aufgebaut sind und die Kombination zu einem bidirektionalen Link erfolgt ist, kann in einem dritten Schritt die Konfiguration des Links durch das PPP Protokoll beginnen. Ab diesem Zeitpunkt geht die Steuerung auf das PPP Protokoll über, der MPLS Tunnel wird ab diesem Zeitpunkt lediglich als Punkt zu Punkt Link-Layer Verbindung gesehen. Das PPP Protokoll kann nun den Einsatz von   RTP    Kompression und PPP Multiplexing festlegen, soweit dies von beiden Endpunkten des Tunnels unterstützt wird. Der MPLS Tunnel erscheint dabei aus Sicht von PPP als Punkt-Punkt Link.



  PPP Pakete werden als Payload in MPLS Paketen übertragen.