WO2001024442A2 - Verfahren zur unterscheidung zwischen nutzdaten und oam-daten bei einer verbindungslosen paketvermittlung - Google Patents

Verfahren zur unterscheidung zwischen nutzdaten und oam-daten bei einer verbindungslosen paketvermittlung Download PDF

Info

Publication number
WO2001024442A2
WO2001024442A2 PCT/DE2000/003217 DE0003217W WO0124442A2 WO 2001024442 A2 WO2001024442 A2 WO 2001024442A2 DE 0003217 W DE0003217 W DE 0003217W WO 0124442 A2 WO0124442 A2 WO 0124442A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
oam
length
frame
packet
Prior art date
Application number
PCT/DE2000/003217
Other languages
English (en)
French (fr)
Other versions
WO2001024442A3 (de
Inventor
Joachim Charzinski
Dominic Axel Schupke
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
Publication of WO2001024442A2 publication Critical patent/WO2001024442A2/de
Publication of WO2001024442A3 publication Critical patent/WO2001024442A3/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/168—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP] specially adapted for link layer protocols, e.g. asynchronous transfer mode [ATM], synchronous optical network [SONET] or point-to-point protocol [PPP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/325—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the network layer [OSI layer 3], e.g. X.25
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery

Definitions

  • the invention relates to a method according to the preamble of claim 1.
  • IP packets Internet protocol
  • IP packets have a variable length.
  • IP packets carrying user data are to be distinguished from those which transmit control data relating to network or link management. The latter are called OAM packets.
  • the IP packets are transmitted in frames.
  • an IP packet is integrated into the frame structure (encapsulation) on the transmission side, for which purpose a frame information field is provided in the frame. This is preceded by a frame header. There is information about e.g. filed the beginning of the frame and the package length. A field for error detection is also provided, in which the result of checksum calculations is stored. For example, CRC test sequences (Cyclic Redundancy Check) can be used as checksum calculations. Information describing the transmission process is thus stored in the frame header.
  • the transmission frame defined in this way essentially consists of an indication of the start of the integrated IP packet, the length of the IP packet and a CRC field and the IP packet itself.
  • the actual user data to be transmitted are thus kept in the frame information field and are further processed by the receiving device.
  • user data also considered OAM data.
  • the length of the frame information field is limited to the range between 0 and 65535 bytes.
  • the frames in which user data are transmitted (user data packet, user data frames) must now be distinguished from those which transmit OAM data (OAM packet, OAM frame).
  • OAM packet OAM packet
  • a special marking of the OAM frames is made in the frame header.
  • SDL Simple Data Link
  • a field is provided in the frame header in which a length indicator is stored as a marker. In the case of user data frames, this only specifies the length of the subsequent IP user data packet.
  • the length indicator only indirectly indicates the length of the subsequent OAM packet.
  • the receiving institution evaluates this field. If, for example, a value of 50 is entered here, this means that a user data packet with a length of 50 bytes is transmitted in the frame information field. If, on the other hand, one of the values 1, 2 or 3 is entered, the IP packet integrated in the frame information field is an OAM packet.
  • the packet type of the OAM packet can be determined using the length indicator. In this prior art, the length of the subsequent OAM packet has a fixed size of 6 bytes.
  • the integrated IP packet is a user data packet or an OAM packet.
  • the value carried in the length field of the frame header is greater than 3, it is a user data packet.
  • the value carried is taken as the length of the user data packet. Otherwise, ie if the value carried is less than 4, it is an OAM packet.
  • the carried value is actually defined as a length indicator, it cannot simply be used here as the length of the OAM packet. Rather, a register must be addressed in which the length (6 bytes) is stored. Such a procedure is therefore associated with increased hardware expenditure.
  • the invention has for its object to show a way how an efficient transmission and detection of IP packets can be carried out in frames with little hardware.
  • An advantage of the invention is in particular that the length indicator generally directly indicates the length of the user data and OAM data carried along, and is entered in the length field provided for this purpose. If the length is less than a predetermined threshold value, the data carried in the frame information field are interpreted as user data and otherwise as OAM data.
  • FIG. 2 shows the integration of an OAM packet in a frame
  • FIG. 1 shows the typical structure of a frame. Accordingly, a frame head RK and a frame information part NR are provided.
  • the frame header RK there is a field Fla provided that serves for synchronization and detection of the beginning of the frame.
  • a length indicator representative of the length of the IP packet is specified in a length field L and the result of a checksum calculation in a field CRC.
  • An IP user data packet NP is entered in the frame information field NR.
  • Fig. ' 2 it is now proposed to generally transmit the length of an IP packet. This means that the length of both a user data packet and an OAM packet can always be found directly in the length field L. An OAM packet should also have a variable length.
  • IP user data packets
  • a frame with a length value of 20 to 65535 is always a frame with user data packet and that values from 1 to 19 in the length field L is always an OAM package. It is therefore not necessary to implement a length indicator.
  • the packet length of an OAM packet can be determined directly, i.e. the value entered in the length field L is taken, a link to a register having a length specification as in the prior art is not necessary here. In particular, such an approach has the advantage that simple evaluations can be carried out and thus hardware expenditure is saved.
  • a substructure can be defined in the frame.
  • the OAM packet can then be segmented in this substructure.

Landscapes

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

Abstract

Bei zeitgemäßen Übertragungssystemen werden Nutzdaten und OAM-Daten in IP-Paketen übertragen, die ihrerseits in Rahmen eingebunden sind. Beim Stand der Technik wird zur Unterscheidung im Rahmenkopf (RK) eine spezielle Markierung (L) vorgenommen, die noch in eine absolute Länge umzusetzen ist. Damit ist ein erhöhter Hardwareaufwand verbunden. Die Erfindung schafft hier Abhilfe, indem direkt die Länge (L) der mitgeführten Nutzdaten und OAM-Daten eingetragen wird. Falls diese größer als 19 Bytes ist, sind die nachfolgenden Daten als Nutzdaten und andernfalls als OAM-Daten zu interpretieren.

Description

Beschreibung
Verfahren zur Unterscheidung zwischen Nutzdaten und OAM-Daten bei einer verbindungslosen Paketvermittlung.
Die Erfindung betrifft ein Verfahren gemäß dem Oberbegriff von Patentanspruch 1.
Bei zeitgemäßen Informationsverarbeitungssystemen werden In- formationen in IP-Paketen (Internetprotokoll) übertragen.
Hierbei handelt es sich um eine verbindungslose Vermittlung, mittels der keine dauernde Verbindung zwischen der sendenden und der empfangenden Einrichtung erstellt wird. Die IP-Pakete weisen eine variable Länge auf. Hierbei sind Nutzdaten tra- gende IP-Pakete von solchen zu unterscheiden, die Steuerdaten bezüglich der Netz- oder Linkverwaltung übertragen. Letztere werden als OAM-Pakete bezeichnet.
Die Übertragung der IP-Pakete erfolgt in Rahmen. Hierzu wird sendeseitig jeweils ein IP-Paket in eine Rahmenstruktur eingebunden (Einkapselung) , wozu im Rahmen ein Rahmeninformationsfeld vorgesehen ist. Diesem wird ein Rahmenkopf vorangestellt. Dort sind Informationen über z.B. den Rahmenanfang und die Paketlänge abgelegt. Ferner ist ein Feld zur Fehler- erkennung vorgesehen, in dem das Resultat von Prüfsummenbe- rechnungen abgelegt ist. Als PrüfSummenberechnungen können beispielsweise CRC-PrüfSequenzen (Cyclic Redundancy Check) verwendet werden. Im Rahmenkopf sind somit den Übertragungsvorgang näher beschreibende Informationen abgelegt. Der der- art definierte Übertragungsrahmen besteht somit im wesentlichen aus einer Angabe über den Anfang des eingebundenen IP- Paketes, der Länge des IP-Paketes sowie einem CRC-Feld und dem IP-Paket selbst.
Im Rahmeninformationsfeld werden somit die eigentlichen zu übertragenden Nutzdaten geführt, die von der empfangenden Einrichtung weiterverarbeitet werden. Als Nutzdaten werden dabei auch OAM-Daten betrachtet. Die Länge des Rahmeninfor- mationsfeldes ist auf den Bereich zwischen 0 und 65535 Bytes beschränkt.
Empfangsseitg müssen nun die Rahmen, in denen Nutzdaten übertragen werden (Nutzdatenpaket, Nutzdatenrahmen) von denen unterschieden werden, die OAM-Daten übertragen (OAM-Paket, OAM- Rahmen) . Beim Stand der Technik wird hierzu im Rahmenkopf eine spezielle Markierung der OAM-Rahmen vorgenommen.
Beispielhaft sei hier auf das SDL (Simple Data Link) Protokoll der Firma Lucent verwiesen. Hier ist im Rahmenkopf ein Feld vorgesehen, in dem als Markierung ein Längenindikator abgelegt ist. Dieser gibt lediglich bei Nutzdatenrahmen di- rekt die Länge des nachfolgenden IP-Nutzdatenpaketes an. Im
Falle von OAM-Rahmen gibt der Längenindikator lediglich indirekt die Länge des nachfolgenden OAM-Paketes an.
Die empfangende Einrichtung wertet dieses Feld aus. Ist hier beispielsweise ein Wert 50 eingetragen, so bedeutet dies, daß im Rahmeninformationsfeld ein Nutzdatenpaket mit einer Länge von 50 Byte übertragen wird. Ist hingegen einer der Werte 1, 2 oder 3 eingetragen, so handelt es sich bei dem im Rahmeninformationsfeld eingebundenen IP-Paket um ein OAM-Paket. Der Pakettyp des OAM-Paketes kann anhand des Längenindikators bestimmt werden. Die Länge des nachfolgenden OAM-Paketes weist bei diesem Stand der Technik eine feste Größe von 6 Byte auf.
Dies bedeutet somit, daß im Falle des Auftretens eines IP- Rahmens zunächst eine Überprüfung daraufhin stattfindet, ob es sich bei eingebunden IP-Paket um ein Nutzdatenpaket oder ein OAM-Paket handelt. In ersterem Fall d.h. wenn der im Längenfeld des Rahmenkopfes mitgeführte Wert größer als 3 ist, handelt es sich um ein Nutzdatenpaket. Der mitgeführte Wert wird als Länge des Nutzdatenpaketes herangenommen. Andernfalls d.h. wenn der mitgeführte Wert kleiner als 4 ist, handelt es sich um ein OAM-Paket. Obwohl der mitgeführte Wert eigentlich als Längenindikator definiert ist, kann er hier nicht ohne weiteres als Länge des OAM-Paketes herangenommen werden. Vielmehr ist ein Register zu adressieren, in dem die Länge (6 Byte) abgelegt ist. Eine derartige Vorgehensweise ist somit mit einem erhöhten Hardwareaufwand verbunden.
Der Erfindung liegt die Aufgabe zugrunde, einen Weg aufzuzeigen, wie eine effiziente Übertragung und Erkennung von IP- Paketen in Rahmen bei geringem Hardwareaufwand vorgenommen werden kann.
Vorteilhaft an der Erfindung ist insbesondere, daß der Längenindikator generell direkt die Länge der mitgeführten Nutzdaten und OAM-Daten angibt, und in das hierzu vorgesehene Längenfeld eingetragen wird. Falls die Länge kleiner als ein vorgegebener Schwellenwert ist, werden die im Rahmeninformationsfeld geführten Daten als Nutzdaten und andernfalls als OAM-Daten interpretiert.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
Die Erfindung wird im folgenden anhand eines Ausführungsbei- spiels näher erläutert:
Es zeigen:
Figur 1 die typische Struktur eines Rahmens mit Rahmenkopf sowie Rahmeninformationsteil,
Figur 2 die Einbindung eines OAM-Paketes in einen Rahmen,
Gemäß Fig. 1 ist die typische Struktur eines Rahmens aufgezeigt. Demgemäß ist ein Rahmenkopf RK sowie ein Rahmeninformationsteil NR vorgesehen. Im Rahmenkopf RK ist ein Feld Fla vorgesehen, das zur Synchronisation und Erkennung des Rahmenanfangs dient. In einem Längenfeld L ist ein für die Länge des IP-Paketes repräsentativer Längenindikator angegeben und in einem Feld CRC das Ergebnis einer PrüfSummenberechnung. Im Rahmeninformationsfeld NR ist ein IP-Nutzdatenpaket NP eingetragen.
Gemäß Fig.' 2 wird nun vorgeschlagen, die Länge eines IP-Paketes generell mitzuübertragen. Dies bedeutet, daß die Länge sowohl eines Nutzdatenpaketes und eines OAM-Paketes stets direkt dem Längenfeld L entnehmbar ist. Ein OAM-Paket soll hierbei ebenfalls eine variable Länge aufweisen können.
Da die Nutzdatenpakete (IP) nur Längen von 20 bis 65535 Bytes haben können, wird nun erfindungsgemäß festgelegt, daß es sich bei einem Rahmen mit einem Längenwert von 20 bis 65535 immer um einen Rahmen mit Nutzdatenpaket handelt und daß es sich bei Werten von 1 bis 19 im Längenfeld L immer um OAM-Pa- kete handelt. Die Umsetzung eines Längenindikators ist damit nicht erforderlich. Empfangsseitg kann dann durch Auswertung der im Längenfeld L eingetragenen Paketlänge entschieden werden, ob das im Rahmeninformationsfeld NR eingebundene IP- Paket ein Nutzdatenpaket NP oder ein OAM-Paket OAM ist. Als Kriterium hierfür gilt ein Schwellenwert der Paketlänge von 19 Bytes. Das Ermitteln der Paketlänge eines OAM-Paketes kann direkt erfolgen, d.h. es wird der im Längenfeld L eingetragene Wert genommen, eine Verknüpfung mit einem, eine Längenangabe aufweisenden Register wie beim Stand der Technik ist hier nicht erforderlich. Insbesondere ist mit einer der- artigen Vorgehensweise der Vorteil verbunden, daß einfache Auswertungen vorgenommen werden können und damit Hardware- Aufwand gespart wird.
Sollen längere OAM-Pakete als 19 Byte im Rahmen übertragen werden, kann eine Substruktur im Rahmen definiert werden. In dieser Substruktur kann dann eine Segmentierung des OAM-Paketes vorgenommen werden.

Claims

Patentansprüche
1. Verfahren zur Unterscheidung zwischen Nutzdaten und OAM- Daten bei einer verbindungslosen Paketvermittlung, mittels der die Nutzdaten und die OAM-Daten zwischen wenigstens einer sendenden und einer empfangenden Einrichtung in einem Rahmen übertragen werden, der jeweils aus einem Rahmenkopf (RK) sowie einem Rahmeninformationsfeld (NR) gebildet wird, wobei in ersterem Informationen bezüglich des Übertragungsvorganges und in letzterem die Nutzdaten oder die OAM-Daten eingefügt sind, und wobei in ersterem (RK) ein Längenindikator (L) bezüglich der Länge der mitgeführten Nutzdaten und/ oder OAM- Daten geführt wird, dadurch gekennzeichnet, daß der Längenindikator (L) direkt die Länge der mitgeführten Nutzdaten und OAM-Daten angibt, daß falls die Länge (L) größer als ein vorgegebener Schwellenwert ist, die im Rahmeninformationsfeld geführten Daten als Nutzdaten und andernfalls als OAM-Daten interpretiert werden.
2 . Verfahren nach Anspruch 1 , d a d u r c h g e k e n n z e i c h n e t , daß die im Rahmeninformationsfeld (RI) geführten Nutzdaten und OAM-Daten als IP-Pakete eingefügt werden.
3. Verfahren nach Anspruch 1, 2, dadurch gekennzeichnet, daß der Schwellenwert 19 Bytes beträgt.
4. Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, daß OAM-Daten, die eine größere Breite als der Schwellenwert aufweisen, in eine Substruktur des Rahmens eingefügt werden.
PCT/DE2000/003217 1999-09-28 2000-09-15 Verfahren zur unterscheidung zwischen nutzdaten und oam-daten bei einer verbindungslosen paketvermittlung WO2001024442A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19946440.5 1999-09-28
DE19946440 1999-09-28

Publications (2)

Publication Number Publication Date
WO2001024442A2 true WO2001024442A2 (de) 2001-04-05
WO2001024442A3 WO2001024442A3 (de) 2002-04-18

Family

ID=7923570

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2000/003217 WO2001024442A2 (de) 1999-09-28 2000-09-15 Verfahren zur unterscheidung zwischen nutzdaten und oam-daten bei einer verbindungslosen paketvermittlung

Country Status (1)

Country Link
WO (1) WO2001024442A2 (de)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0294133A2 (de) * 1987-06-05 1988-12-07 AT&T Corp. Protokolle für sehr schnelle optische lokale Netze
WO1998031127A1 (en) * 1997-01-06 1998-07-16 Cabletron Systems, Inc. Buffered repeater with independent ethernet collision domains

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0294133A2 (de) * 1987-06-05 1988-12-07 AT&T Corp. Protokolle für sehr schnelle optische lokale Netze
WO1998031127A1 (en) * 1997-01-06 1998-07-16 Cabletron Systems, Inc. Buffered repeater with independent ethernet collision domains

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DOSHI B T ET AL: "A simple data link protocol for high-speed packet networks" BELL LABS TECHNICAL JOURNAL,BELL LABORATORIES,US, Bd. 4, Nr. 1, Januar 1999 (1999-01), Seiten 85-104, XP002129088 ISSN: 1089-7089 *

Also Published As

Publication number Publication date
WO2001024442A3 (de) 2002-04-18

Similar Documents

Publication Publication Date Title
DE60014852T2 (de) Headerkompression in echtzeitdiensten
EP0827312A2 (de) Verfahren zur Änderung der Konfiguration von Datenpaketen
DE102007041143B4 (de) Verfahren zum Analysieren von gleichzeitig übertragenen, verschlüsselten Datenströmen in IP-Netzwerken
DE60101531T2 (de) Rahmenformat des UMTS Protokolls zur Unterstützung von Dienstqualitäten
EP2264926B1 (de) Verfahren zum Betreiben eines Mobilfunknetzes
WO2009027157A1 (de) Verfahren zum analysieren von gleichzeitig übertragenen, verschlüsselten datenströmen
DE10017062A1 (de) Verfahren zum Betreiben eines Mobilfunknetzes
WO2001024442A2 (de) Verfahren zur unterscheidung zwischen nutzdaten und oam-daten bei einer verbindungslosen paketvermittlung
DE10226394B4 (de) Verfahren zur Datenübertragung
EP0802635A2 (de) Verfahren zur Übertragung von codierten Daten
WO2001003361A1 (de) Verfahren zur überwachung der bitübertragungsgüte bei paketorientierter übertragung
DE19705678A1 (de) Verfahren zur Übertragung multimedialer Daten
DE60004809T2 (de) Telekommunikationsnetz und verfahren zur übertragung von verwaltungsdaten
DE10201846A1 (de) Automatisches Synchronisationsschema zur Härtung von ATM-Zellen
EP1362448A1 (de) Verfahren und vorrichtung zur datenübertragung gemäss einem hybrid-arq-verfahren
DE10210742A1 (de) Netzoptimierte Nutzung von End-to-End Protokollen
EP1239632B1 (de) System zum Übertragen eines Datenpaketstromes variabler Datenrate zwischen Netzwerken
EP0954946B1 (de) Verfahren zum übertragen von sprachinformationen in atm-zellen
DE19922172B4 (de) Verfahren und Vorrichtung zum Erkennen und Korrigieren von digitalen PCM-Codewörtern innerhalb eines übertragenen Datenstroms
EP0981258B1 (de) Verfahren zur digitalen Übertragung von Informationen und/oder Daten auf einer Übertragungsstrecke
DE19840506A1 (de) Verfahren zur Synchronisation von mindestens zwei Datenströmen zwischen Teilnehmern eines Kommunikationssystems
DE102007018832B3 (de) Verfahren und Einrichtung zur Reduktion der Datenmenge in einem paketorientiertem Datennetz
WO2003026188A2 (de) Verfahren und vorrichtung zur datenübertragung in einem mobilkommunikationsnetz
EP1079569A1 (de) Verfahren zur Übertragung von Zusatzinformationen bei der Übertragung von Datenpaketen
EP0949836A1 (de) Verfahren zur Signalisierung zwischen einem Endgerät eines ISDN-Anschlusses und einer Vermittlungsstelle sowie Anordnung und Vorrichtung zur Durchführung des Verfahrens

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): 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

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): 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

122 Ep: pct application non-entry in european phase