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

Verfahren zum übertragen von sprachinformationen über ein internetprotokoll Download PDF

Info

Publication number
WO2001095583A2
WO2001095583A2 PCT/DE2001/001976 DE0101976W WO0195583A2 WO 2001095583 A2 WO2001095583 A2 WO 2001095583A2 DE 0101976 W DE0101976 W DE 0101976W WO 0195583 A2 WO0195583 A2 WO 0195583A2
Authority
WO
WIPO (PCT)
Prior art keywords
tunnel
protocol
ppp
mpls
nodes
Prior art date
Application number
PCT/DE2001/001976
Other languages
English (en)
French (fr)
Other versions
WO2001095583A3 (de
Inventor
Thomas Theimer
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to AU2001267320A priority Critical patent/AU2001267320A1/en
Priority to EP01944956A priority patent/EP1287660A2/de
Priority to CA002411677A priority patent/CA2411677A1/en
Publication of WO2001095583A2 publication Critical patent/WO2001095583A2/de
Publication of WO2001095583A3 publication Critical patent/WO2001095583A3/de

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/825Involving tunnels, e.g. MPLS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • H04L47/801Real time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/006Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC

Definitions

  • the invention relates to a method according to the preamble of claim 1.
  • VoIP Voice over IP
  • Protocols such as e.g. TCP / IP or UDP / IP crystallized out.
  • the TCP protocol is backed up, i.e. if a parcel is lost, it will be requested and transferred again.
  • UDP User Datagram Protocol
  • the packets carrying voice information are usually relatively small (useful part approx. 40 - 80 bytes).
  • the useful part of the packet carrying the useful information is preceded by a header, which also has a size of approximately 40 bytes.
  • this means that, in extreme cases, a speech packet to be transmitted has a useful part of 40 bytes, which is preceded by a header of approximately the same size.
  • the packet thus has an overhead of 100%, so that the bandwidth efficiency of such a solution can be regarded as very low.
  • tunnel-based methods compression takes place end to end at the entrance / exit nodes of the tunnel.
  • a tunnel is initially set up between 2 nodes, through which the voice information is later transmitted.
  • the tunnel is set up via a signaling packet sent at the start of the transmission or administratively. Since the voice information is transmitted in the tunnel, it is invisible to the nodes in between.
  • Another known method uses the known L2TP protocol as a tunnel protocol, with the help of which both PPP multiplexing and RTP header compression end-end is realized.
  • This proposed solution has the advantage of being compatible with the standardized RTP header compression.
  • multiple language packs can be combined into one larger pack.
  • the problem here is that only a reduction of the header to about half of the original 40 bytes can be achieved here.
  • the quality of service particularly high because, for example, no resources can not be reserved (Getting Connected loose proto ⁇ col).
  • the present invention has for its object to show a way how a more efficient transmission of voice information over IP networks can be achieved.
  • An advantage of the invention is that the MPLS tunnel mechanism is used instead of the known L2TP tunnel mechanism. This gives better efficiency.
  • RTP compression and PPP multiplexing are implemented within an MPLS tunnel.
  • Another advantage of the invention is that there are no sequence errors. Appropriate parameterization can be used to ensure that the packet sequence is preserved within the tunnel. A reconstruction of the original packet order as with L2TP is therefore not necessary.
  • the procedure according to the invention entails high reliability.
  • an MPLS tunnel equipped with MPLS Protection Switching can be switched over or restored very quickly in the event of an error.
  • L2TP is from the convergence of IP routing Protocol dependent, so that node or line failures can lead to interruptions of several 10 seconds.
  • a particular advantage of the invention can be seen in a controlled selection of the routes in that the route of an MPLS tunnel in the network can be influenced directly by the operator.
  • MPLS Explicit Routing individual nodes or groups of nodes can be specified along the way. In this way the Pubver- can be specifically controlled traffic through the network to bypass example ⁇ as slow unreliable lines or.
  • Fig. 1 shows a packet format for the transmission of PPP in
  • the PPP protocol field directly follows the MPLS header.
  • the PPP user data can contain, for example, several compressed RTP packets. This results in a minimum overhead of 4 bytes per language packet, plus MPLS and PPP headers of 5 or 6 bytes. With 10 voice packets of 40 bytes each in an MPLS packet, this results in a bandwidth efficiency of 400/446 or around 90%.
  • a first step the establishment of a unidirectional MPLS tunnel is initiated from one side.
  • the construction of the tunnel is done using the TE-RSVP signaling protocol ⁇ .
  • the value 0x88OB for PPP must be specified here.
  • the session attribute object of the TE-RSVP signaling protocol contains a session name, which is in principle freely selectable. However, the session name must uniquely identify the tunnel for input and output nodes. The session name together with the IP addresses of input and output nodes must therefore be unique.
  • the LSP tunnel session object must contain the IP address of the input node as an extended tunnel ID. This address will later be used for addressing when building the tunnel in the reverse direction.
  • a bandwidth is usually reserved for the tunnel and special delay requests can be signaled.
  • the tunnel is built in the forward direction.
  • the tunnel is now built in the reverse direction.
  • Tunnel exit (seen in the forward direction) recognizes from the PPP protocol type that bidirectional communication is necessary and in turn initiates the construction of the tunnel in the reverse direction. Both protocol type and session

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

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, daß zwischen den beiden Knoten in Vorwärts- und Rückrichtung jeweils ein Tunnel aufgebaut wird, daß anschließend beide Tunnel zu einer bidirektionalen Verbindung kombiniert werden, wodurch eine bidirektionale Kommunikation ermöglicht wird,daß ü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äß 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ößere 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 Nutzinformation- enen tragenden Nutzteil des Paketes, ein Kopfteil (Header) vorangestellt, der ebenfalls eine Größe von ca. 40 Byte auf- weist. Letztendlich bedeutet dies, daß ein zu übertragendes Sprachpaket im Extremfall einen Nutzteil von 40 Byte aufweist, dem ein etwa gleich großer Header vorangestellt ist. Das Paket weist somit einen Overhead von 100 % auf, so daß die Bandbreiten-Effizienz einer solchen Lösung als sehr ge- ring 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 we- sentlichen 2 Verfahren bekannt, nämlich Link-basierte sowie Tunnel-basierte Verfahren: Bei den Link-basierten Verfahren wird der gesamte RTP Header auf eine Größe 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, daß die sehr aufwendige Kompression in jedem Knoten entlang einer VoIP Verbindung zwischen 2 Teilnehmern durchgeführt werden muß. 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 Switc ing) vorgeschlagen. Dieses Verfahren erreicht bei VoIP jedoch lediglich eine Re- duktion des Headers auf ca. die Hälfte der ursprünglichen 40 Byte. Die Effizienz des Übertragungsvorganges 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. Außerdem können mehrere Sprachpakete zu einem größeren Paket kombiniert werden. Problematisch hieran ist, daß 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 ( erbindungsloses Proto¬ koll) .
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, daß anstelle des bekannten L2TP Tunnel-Mechanismus der MPLS Tunnel-Mechanismus verwendet wird. Damit ist eine bessere Effizienz gegeben. Erfindungsgemäß 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 muß. Ferner sind hier eine garantierte Bandbreite und Dienstgüte gegeben. Dies liegt darin begründet, daß 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, daß keine Reihenfolgefehler entstehen. So kann durch eine entsprechende Para eterisierung sichergestellt werden, daß die Paketreihenfolge innerhalb des Tunnels erhalten bleibt. Eine Rekonstruktion der ursprünglichen Paketreihenfolge wie bei L2TP entfällt somit.
Darüberhinaus bringt die erfindungsgemäße 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 daß 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, daß der Weg eines MPLS Tunnels im Netz durch den Betreiber direkt beeinflußt 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 Sprachver- kehr gezielt durch das Netz gesteuert werden, um beispiels¬ weise 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äßen Algorithmus
In Fig. 1 ist beispielhaft ein Paketformat aufgezeigt, das für die Übertragung von PPP in MPLS verwendet werden kann. Demgemäß 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 uni- direktionalen MPLS Tunnels von einer Seite initiiert. Der Aufbau des Tunnels erfolgt mit Hilfe des TE-RSVP Signalisier¬ protokolls. Dieses enthält ein Label Request Objekt, welches u.a. das zu übertragende Protokoll definiert. Hier muß der Wert 0x88OB für PPP angegeben werden.
Das Session Attribute Objekt des TE-RSVP Signalisierprotokolls enthält einen Session Namen, der im Prinzip frei wähl- bar ist. Der Session Name muß allerdings den Tunnel eindeutig für Eingangs- und Ausgangsknoten identifizieren. Der Session Name zusammen mit den IP Adressen von Eingangs- und Ausgangsknoten muß somit eindeutig sein.
Ferner muß 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 Vor- wä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, daß 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 Eingangs- knotens verwendet, die beim Tunnelaufbau in Vorwärtsrichtung festgelegt wurde. Sobald beide Tunnel erfolgreich aufgebaut sind und die Kom¬ bination 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 Steuer- ung 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 Tun- nel erscheint dabei aus Sicht von PPP als Punkt-Punkt Link. PPP Pakete werden als Payload in MPLS Paketen übertragen.
PCT/DE2001/001976 2000-06-07 2001-05-22 Verfahren zum übertragen von sprachinformationen über ein internetprotokoll WO2001095583A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2001267320A AU2001267320A1 (en) 2000-06-07 2001-05-22 Method for transmitting voice information via an internet protocol
EP01944956A EP1287660A2 (de) 2000-06-07 2001-05-22 Verfahren zum übertragen von sprachinformationen über ein internetprotokoll
CA002411677A CA2411677A1 (en) 2000-06-07 2001-05-22 Method for transmitting voice information over an internet protocol

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10028143.5 2000-06-07
DE10028143 2000-06-07

Publications (2)

Publication Number Publication Date
WO2001095583A2 true WO2001095583A2 (de) 2001-12-13
WO2001095583A3 WO2001095583A3 (de) 2002-06-27

Family

ID=7644964

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2001/001976 WO2001095583A2 (de) 2000-06-07 2001-05-22 Verfahren zum übertragen von sprachinformationen über ein internetprotokoll

Country Status (6)

Country Link
US (1) US20030149718A1 (de)
EP (1) EP1287660A2 (de)
CN (1) CN1436417A (de)
AU (1) AU2001267320A1 (de)
CA (1) CA2411677A1 (de)
WO (1) WO2001095583A2 (de)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1379036A1 (de) * 2002-07-03 2004-01-07 Alcatel System und Verfahren für den automatischen Aufbau eines Etikettvermittlungsweges(LSP) in Rückwärtsrichtung
WO2006052117A1 (en) * 2004-11-15 2006-05-18 Samsung Electronics Co., Ltd. Apparatus and method for compressing headers in a broadband wireless communication system
WO2007030988A1 (fr) * 2005-09-14 2007-03-22 Huawei Technologies Co., Ltd. Procede destine a mettre en place un systeme et un tunnel d'ingenierie de trafic bidirectionnel ainsi que le routeur correspondant
WO2009006484A1 (en) 2007-07-02 2009-01-08 Silicon Image, Inc. Operation of media interface to provide bidirectional communications
EP2216942A1 (de) * 2008-05-08 2010-08-11 Huawei Technologies Co., Ltd. Verfahren zum aufbauen eines tunnels und system zur realisierung eines tunnelaufbaus

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7467018B1 (en) 2002-11-18 2008-12-16 Rockwell Automation Technologies, Inc. Embedded database systems and methods in an industrial controller environment
US20060133412A1 (en) * 2004-12-22 2006-06-22 Rockwell Automation Technologies, Inc. Integration of control and business applications using integration servers
US7706895B2 (en) * 2005-02-25 2010-04-27 Rockwell Automation Technologies, Inc. Reliable messaging instruction
CN100338928C (zh) * 2005-03-04 2007-09-19 中国人民解放军理工大学 在无线网络中建立双向虚电路的方法
US7565351B1 (en) 2005-03-14 2009-07-21 Rockwell Automation Technologies, Inc. Automation device data interface
US8488616B2 (en) * 2005-04-05 2013-07-16 Cisco Technology, Inc. Building multipoint-to-multipoint label switch paths
US7233830B1 (en) * 2005-05-31 2007-06-19 Rockwell Automation Technologies, Inc. Application and service management for industrial control devices
KR100723873B1 (ko) * 2005-12-08 2007-05-31 한국전자통신연구원 멀티 프로토콜 레이블 스위칭 네트워크 시스템에서 고품질서비스 제공 방법 및 장치
US7899044B2 (en) * 2006-06-08 2011-03-01 Alcatel Lucent Method and system for optimizing resources for establishing pseudo-wires in a multiprotocol label switching network
US20090016334A1 (en) * 2007-07-09 2009-01-15 Nokia Corporation Secured transmission with low overhead
CN101237699B (zh) * 2008-02-29 2010-12-08 中兴通讯股份有限公司 无线网络节点与接入服务器之间建立多隧道的控制方法
CN101415005B (zh) 2008-11-24 2013-04-17 华为技术有限公司 一种实现业务转发的方法、系统和设备
CN104954593A (zh) * 2015-05-19 2015-09-30 重庆金美通信有限责任公司 Voip资源预留和传输压缩实施方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6466985B1 (en) * 1998-04-10 2002-10-15 At&T Corp. Method and apparatus for providing quality of service using the internet protocol
US6507577B1 (en) * 1998-11-12 2003-01-14 Nortel Networks Limited Voice over internet protocol network architecture
US6522627B1 (en) * 1998-11-12 2003-02-18 Nortel Networks Limited Managing internet protocol connection oriented services
US6680943B1 (en) * 1999-10-01 2004-01-20 Nortel Networks Limited Establishing bi-directional communication sessions across a communications network

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
AWDUCHE D ET AL.: "Requirements for Traffic Engineering Over MPLS (RFC 2702)" REQUEST FOR COMMENT, [Online] September 1999 (1999-09), XP002185031 Gefunden im Internet: <URL:http://www.simpleweb.org/ietf/rfcs/co mplete/rfc2702.txt> [gefunden am 2001-11-28] *
See also references of EP1287660A2 *
THEIMER T: "Tunneling Multiplexed Compressed RTP in MPLS" INTERNET DRAFT, Juni 2000 (2000-06), Seiten 1-10, XP002185030 *
WILLIS D: "Integrating voice and data" NETWORK COMPUTING, 18 OCT. 1999, CMP MEDIA INC, USA, Bd. 10, Nr. 21, Seiten 50-52, 54, 56, 58, 60, 64, 66, 68, 71, 73, XP001050317 ISSN: 1046-4468 *
XIAO X ET AL: "INTERNET QOS: A BIG PICTURE" IEEE NETWORK, IEEE INC. NEW YORK, US, Bd. 13, Nr. 3, M{rz 1999 (1999-03), Seiten 8-18, XP000875017 ISSN: 0890-8044 *

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1379036A1 (de) * 2002-07-03 2004-01-07 Alcatel System und Verfahren für den automatischen Aufbau eines Etikettvermittlungsweges(LSP) in Rückwärtsrichtung
US8014380B2 (en) 2002-07-03 2011-09-06 Alcatel Lucent Method and system for automatically establishing a return label switched path
WO2006052117A1 (en) * 2004-11-15 2006-05-18 Samsung Electronics Co., Ltd. Apparatus and method for compressing headers in a broadband wireless communication system
WO2007030988A1 (fr) * 2005-09-14 2007-03-22 Huawei Technologies Co., Ltd. Procede destine a mettre en place un systeme et un tunnel d'ingenierie de trafic bidirectionnel ainsi que le routeur correspondant
WO2009006484A1 (en) 2007-07-02 2009-01-08 Silicon Image, Inc. Operation of media interface to provide bidirectional communications
US7836223B2 (en) 2007-07-02 2010-11-16 Silicon Image, Inc. Operation of media interface to provide bidirectional communications
EP2216942A1 (de) * 2008-05-08 2010-08-11 Huawei Technologies Co., Ltd. Verfahren zum aufbauen eines tunnels und system zur realisierung eines tunnelaufbaus
EP2216942A4 (de) * 2008-05-08 2013-02-20 Huawei Tech Co Ltd Verfahren zum aufbauen eines tunnels und system zur realisierung eines tunnelaufbaus
US8472450B2 (en) 2008-05-08 2013-06-25 Huawei Technologies Co., Ltd. Method and system for establishing tunnels
US9118556B2 (en) 2008-05-08 2015-08-25 Huawei Technologies Co., Ltd. Method and system for establishing tunnels

Also Published As

Publication number Publication date
US20030149718A1 (en) 2003-08-07
CA2411677A1 (en) 2001-12-13
CN1436417A (zh) 2003-08-13
EP1287660A2 (de) 2003-03-05
WO2001095583A3 (de) 2002-06-27
AU2001267320A1 (en) 2001-12-17

Similar Documents

Publication Publication Date Title
WO2001095583A2 (de) Verfahren zum übertragen von sprachinformationen über ein internetprotokoll
EP0929884B1 (de) Verfahren zur übertragung von daten in einem telekommunikationsnetz und switch zur durchführung des verfahrens
DE602005002831T2 (de) Verfahren zur Bereitstellung einer Echtzeitkommunikationsverbindung
DE10133473C1 (de) Verfahren zur optimierten Nutzung von SCTP (Stream Control Transmission Protocol) in MPLS (Multi Protocol Label Switching) Netzen
EP1252787A1 (de) Verfahren zum betreiben eines mobilfunknetzes
WO2001089232A2 (de) Verfahren zum umlegen eines tunnels zwischen knoten eines gprs-systems
EP2055112B1 (de) Kommunikationsnetz mit leitungs- und paketvermittelnder steuerung
DE102006027708B3 (de) Verfahren zur Optimierung einer Kommunikationsverbindung in einem paketvermittelten Sprachdatennetzwerk
DE10231958B4 (de) Verfahren und System zum Übertragen von Datenpaketen über ein Netzwerk an ausgewählte mehrere Bestimmungsorte, sowie computerlesbares Medium
WO2009089850A1 (de) Verfahren zum betreiben eines kommunikationsnetzes, switch und kommunikationsnetz
EP1317820B1 (de) Verfahren zum aufbau von verbindungen mit vorgegebener dienstgüte für ein paketorientiertes kommunikationsnetz mit einem resourcenmanager
EP1261177B1 (de) Verfahren und Vorrichtung zum Einstellen der Bandbreite einer Verbindung zwischen mindestens zwei Kommunikationsendpunkten in einem Datennetz
EP1266493B1 (de) Verfahren und anordnung zum übertragen eines datenpakets von einer ersten vermittlungseinheit an eine zweite vermittlungseinheit in einem datennetz
EP1236372A2 (de) Verfahren zum betreiben eines mobilfunknetzes
EP1191754B1 (de) Verfahren zum Steuern einer Datenumsetzung beim Übergang einer Verbindung zwischen einem paketvermittelten und einem leitungsvermittelten Kommunikationsnetz
EP1261175A2 (de) Verfahren zur Weiterleitung von Datenpaketen in Routern von Kommunikationsnetzen
EP1782589B1 (de) Verfahren zum umschalten einer kommunikationsverbindung von einem ersten verbindungsweg auf einen zweiten verbindungsweg
EP1313289A2 (de) Verfahren zur Übertragung von Rückkanal-Daten in einer Verbindung zwischen einem Endgerät und einem Server eines Paketvermittlungsnetzes
DE10053213A1 (de) Verfahren zum Übertragen digitaler Daten über mehrere Datenübertragungsnetze, zugehörige Einheiten und zugehöriges Programm
EP1257145B1 (de) Verfahren und Vorrichtungen zur Datenübertragung mit zeitlich veränderlicher Datenrate
EP1099326A2 (de) Verfahren zur verbindung von endgeräten mit externen modems
DE10244710A1 (de) Verfahren zur Protokollauswahl für eine Übermittlung von Datennpaketen
EP0998093A2 (de) Verfahren zur Übertragung von Rückkanal-Daten in einer Verbindung zwischen einem Endgerät und einem Server eines Paketvermittlungsnetzes
DE10038182C2 (de) Verfahren zum Umlegen eines Tunnels zwischen Knoten eines GPRS-Systems
EP1977567A1 (de) Verfahren zum routen von verbindungen in einem paketvermittelnden kommunikationsnetz

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AU CA CN US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AU CA CN US

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: 2001944956

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2001267320

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 10276097

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2411677

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 018109055

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2001944956

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2001944956

Country of ref document: EP