WO2003075518A1 - Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen - Google Patents

Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen Download PDF

Info

Publication number
WO2003075518A1
WO2003075518A1 PCT/DE2003/000609 DE0300609W WO03075518A1 WO 2003075518 A1 WO2003075518 A1 WO 2003075518A1 DE 0300609 W DE0300609 W DE 0300609W WO 03075518 A1 WO03075518 A1 WO 03075518A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
block
information
request message
service
Prior art date
Application number
PCT/DE2003/000609
Other languages
English (en)
French (fr)
Inventor
Christian Winkler
Karl Schrodi
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 EP03714659A priority Critical patent/EP1481516A1/de
Publication of WO2003075518A1 publication Critical patent/WO2003075518A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/18—End to end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware

Definitions

  • the subject matter of the application relates to a method for setting up a connectionless, packet-oriented connection across different networks.
  • NGNs Next Generation Networks', NGNs
  • telecommunications applications starting with telephony and video (conference) communication to real multimedia applications
  • traditional and future data services from file transfer via email, web surfing, e-co-merce to 'electronic infotainment'
  • suitable signaling methods must be used to register and provide the necessary network resources to ensure the application-specific requirements for network services, e.g. bez. a quality of service (QoS) or a corresponding reliability and availability of the services from the perspective of the user.
  • QoS quality of service
  • NGNs will be based on Internet Protocol (IP) technology, i.e. the information is transported in packet form and a priori without a connection, advantageously using the statistical traffic behavior of the packet-oriented information transmission.
  • IP Internet Protocol
  • the architecture of the networks clearly differentiates between the control of services and applications ('Service Control') and the transport of information ('Network Control').
  • Service Control' the control of services and applications
  • 'Network Control' the transport of information
  • the actual transport of the (useful) information to be exchanged within the framework of the service takes place at the network level.
  • the necessary (control) information for determining the necessary resources and settings of the network are exchanged via signaling. Since the service control, which is independent of the network, does not know the network structure and the possible routes through the network, a 'horizontal' signaling between network nodes and possibly neighboring subnetworks is also required.
  • Figure 1 shows an example of the resulting architecture. If two network operators offer diverging network services (see definition at the end of the text), then either a suitable mapping between the respective different network services must be agreed for a transition or the original requirement definition must be provided to individually select a suitable network service. Possibly. can also provide additional information about the sub-networks that have already been run through (and thus used up)
  • a set of 'well known network services' (essentially the CBR, VBR, ABR, UBR and GFR) with properties defined by the standardization are available for selection and can be requested directly via the signaling. Since properties such as e.g. the QoS, which have already been determined, only have to be given a (also standardized) description of the delivered traffic (e.g. by parameters such as peak rate and sustainable rate in the case of VBR). (Of course, the requirements regarding the QoS only apply if certain boundary conditions, e.g. regarding the maximum number of nodes passed, etc., are met.)
  • IP-based networks there are a number of approaches from the activities of the Internet Engineering Task Force (ETF) that aim at a possible provision of QoS.
  • ETF Internet Engineering Task Force
  • the most far-reaching approach (and thus probably the closest prior art for this invention report) is the concept of 'Integrated Services' (IntServ).
  • IntServ 'Integrated Services'
  • Signaling procedure is based on the 'Resource Reservation Protocol' (RSVP, RFC 2205 and RFC 2210 ff.)) And works according to the following basic principle: At the starting point of a communication relationship (sender) a 'Path Message' is sent, which is basically the way through the network to explore. It contains a description of the traffic to be generated by the transmitter (transmitter TSpec) and an area (RSVP ADSpec) in which the subnetworks and network nodes passed provide information about their
  • the receiver uses it to create
  • MPLS see e.g. RFC3031
  • LDP 'Label Distribution Protocol
  • Such a protocol can of course also be used to signal further requirements (e.g. in relation to QoS etc.).
  • LDP 'Label Distribution Protocol
  • Requirements for the desired network services e.g. B. with regard to a Quality of Service (QoS) or a reliability and availability of the services.
  • QoS Quality of Service
  • the signaling does not include only one
  • RSVP For a successful reservation, only one complex process is necessary in each network instance concerned (with RSVP there are two: exploring in the forward pass and reserving in the reverse pass).
  • the proposed approach can be used not only for signaling QoS requirements but also for or in
  • Step a request message is sent from the source side to the sink side.
  • either a confirmation or a rejection is sent back to the source page.
  • the method supports unidirectional data flows, since it must be assumed in IP networks that traffic going in and out of a bidirectional communication relationship does not necessarily take the same route. For bidirectional communication relationships, the procedure is to be applied separately for each direction.
  • Flow of information is interrupted (for a longer period) or terminates and / or a limit value for a maximum permissible interruption time of the information flow, • the permissibility or non-permissibility of a sequence reversal of the data packets (packet reordering) and / or limit values for the permissible scope of reordering,
  • block 1 there is only a bandwidth value (e.g. an average or peak value) and in block 2 there is only a maximum permitted packet delay.
  • block 2 can also remain empty if no further requirements are made or these are covered by the third information block (see below).
  • a specific, network-wide specified network service ('well known network service') can be requested from the source or its agent or proxy if one exists and is desired. If this is not the case, this block remains (initially) empty. In this case (i.e. whenever this block is empty), block 3 can be used at the transitions between different network domains (subnetworks, also access networks are subnetworks! To request network services (locally) agreed between these subnetworks.
  • the procedure then proceeds in such a way that the first subnet in the flow direction of the request message selects a network service that is agreed with the second subnet and matches the requirements in blocks 1 and 2 (which only has to be valid between these two) and enters it in the request message and passes this on to the second subnet.
  • the second subnet evaluates the information, makes the necessary reservations and settings, deletes block 3 of the request message and proceeds again at the transition to the third subnet in accordance with the rule described.
  • the received network service request can also be directly mapped to a network service agreed with the subsequent subnet. In the case of non-identical network service specifications, however, there is a risk of 'rocking up', ie an upgrade to increasingly high-quality services, since the service in the next subnet should not have any worse properties than the one used locally.
  • the block 2 information (if available) can be evaluated in each subnetwork regardless of the existence of useful block 3 information. If this is meaningful enough, the (locally or globally specified) network service to be used in this subnet can be selected on this basis. In special cases (option) it is also possible to deviate from the network service that may be notified in block 3 ('overrun').
  • the evaluation of the block 2 information is mandatory if no valid or usable block 3 information is available. The basic assumption is that block 1 information is always evaluated.
  • the order of the blocks or the general arrangement of the information elements in the request message can of course be determined as desired. If the blocks can be individually and uniquely identified by appropriate labeling, only the individual blocks need to be standardized and the request message can be constructed or assembled practically freely and in a modular manner ('option principle'). Only the blocks that are really necessary in individual cases need to be installed. Alternatively, the overall structure of the notification could of course be firmly agreed (standardized).
  • the determining body can (optionally) immediately send back an 'early rejection' along the previously reserved path. With the 'early rejection' all reserved resources are released again.
  • a rejection or
  • the request message will contain a message header that clearly identifies it and from others
  • Block 1 is 'mandatory', the rest are optional.
  • the contents and representations of blocks 1, 2 and 4 require standardization.
  • block 3 contains only one number (e.g. encoded in 7 or 8 bits).
  • the number 5 would then specify the network service agreed with the identification number 5.
  • An additional information carrier (bit or byte) could indicate whether it is a global or only a locally agreed network service if this information was not already implicitly contained in the identification number.
  • a network service specifies certain properties for the transport of packets through a network. These properties are determined by the network (statistically, with a certain
  • the parameters describing the properties of a network service can also include the specification of the reliability or the availability (blocking probability) of the network service.
  • the network services offered by a network can in principle be freely specified within the limits of the technical possibilities of the network. Possible influencing parameters in a Appropriate definitions range from the requirements of the application classes to be transferred to the business and tariff considerations of the operator.
  • IRT Interactive Real-Time
  • Real-time communication e.g. video access
  • TAS Transactional and signaling
  • BE Best effort
  • WWW WWW

Landscapes

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

Abstract

Für ein paketorientiertes, verbindungsloses, heterogenes Netz wird ein Verfahren vorgeschlagen, bei dem zur Anmeldung und Bereitstellung der erforderlichen Netzressourcen zur Sicherstellung der anwendungsspezifischen Anforderungen an die Netzdienste, wie z. B. Quality of Service, eine Anforderungsmeldung von der Quellenseite zur Senkenseite und eine Rückmeldung von der Senkenseite zur Quellenseite geschickt wird. Durch die Anforderungsmeldung, in der die Beiträge der einzelnen Netze aufsummierbar sind, sind die Netzressourcen reservierbar.

Description

Beschreibung
Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen
Der Anmeldungsgegenstand betrifft ein Verfahren zum Einrichten einer verbindungslosen, paketorientierten Verbindung über verschiedene Netze hinweg.
In zukünftigen 'konvergierten' Kommunikationsnetzen ( 'Next Generation Networks', NGNs) , die sowohl klassische und neue Telekommunikationsanwendungen (angefangen bei Telefonie- und Video (konferenz) kommunikation bis hin zu echten Multimediaanwendungen) als auch traditionelle und zukünftige Datendienste (vom File-Transfer über Email, Web-Surfing, e- Co merce bis hin zu 'Electronic Infotainment ' ) unterstützen sollen, müssen geeignete Signalisierverfahren zur Anmeldung und Bereitstellung der erforderlichen Netzressourcen zur Sicherstellung der anwendungsspezifischen Anforderungen an die Netzdienste, z.B. bez. einer Quality of Service (QoS) oder einer entsprechenden Zuverlässigkeit und Verfügbarkeit der Dienste aus der Sicht des Nutzers, eingesetzt werden.
Dabei sind (neben einigen anderen) die folgenden wesentlichen Randbedingungen zu berücksichtigen:
NGNs werden auf der Internet-Protokoll-Technik (IP) aufsetzen, d.h. der Informationstransport erfolgt in Paketform und a priori verbindungslos unter vorteilhafter Ausnutzung des statistischen Verkehrsverhaltens der paketorientierten Informationsübertragung .
Die Architektur der Netze trennt ganz klar zwischen der Steuerung der Dienste und Anwendungen ('Service Control') sowie dem Informationstransport ('Network Control'). Auf der Ebene der Service Control werden die (Ende-zu-Ende- ) Beziehungen zwischen den Nutzern und die Vereinbarungen über Art, Umfang und Eigenschaften etc. des bzw. der in Anspruch zu nehmenden Services bearbeitet. Auf der Network-Ebene erfolgt der eigentliche Transport der im Rahmen des/der Services auszutauschenden (Nutz-) Information. Die notwendigen (Steuer-) Informationen zur Bestimmung der dazu erforderlichen Ressourcen und Einstellungen des Netzes werden über eine Signalisierung ausgetauscht. Da die vom Netz unabhängige Service Control die Netzstruktur und die möglichen Wege durch das Netz nicht kennt, ist dafür auch eine 'horizontale' Signalisierung zwischen Netzknoten und ggf. benachbarten Teilnetzen erforderlich.
Im Rahmen der zunehmenden Globalisierung bei gleichzeitiger massiver Deregulierung der nationalen und regionalen Märkte ist mit einer verstärkten Heterogenität der Netze zu rechnen. Neben der soeben angesprochenen Aufteilung der vertikal übereinander liegenden Aufgaben von Netz-, Service- und AnwendungsSteuerung wird auch im horizontalen Bereich Wettbewerb und damit verbunden eine Differenzierung zwischen verschiedenen Netzbetreibern stattfinden. Ein einfaches
Beispiel für die sich daraus ergebende Architektur zeigt Fig 1. Bieten zwei Netzbetreiber divergierende Netzdienste (siehe Definition am Ende des Textes) an, so muß für einen Übergang entweder eine geeignete Abbildung zwischen den jeweiligen verschiedenartigen Netzdiensten vereinbart werden oder es muß die ursprüngliche Anforderungsdefinition bereitgestellt werden, um jeweils individuell einen geeigneten Netzdienst auswählen zu können. Ggf. kann dabei auch eine zusätzliche Information über den in den bis dahin durchlaufenen Teilnetzen bereits eingebuchten (und damit verbrauchten)
Anteil an verschiedenen Budgets (z.B. packet loss oder delay) hilfreich oder sogar notwendig sein.
I. In den klassischen Telefonnetzen gibt es meist nur einen einheitlichen (Basis-) Netzdienst, der sich z.B. im ISDN auf die Bereitstellung eines sog. B-Kanals (64 kbit/s Übertragungskapazität) abbilden läßt. Auch die Eigenschaften darauf aufbauender Varianten (z.B. durch Kanalbündelung) sind netzweit einheitlich standardisiert. Solche standardisierte 'well known network Services' können über verschiedenen Teilnetze hinweg einheitlich signalisiert und direkt angefordert und genutzt werden. Eine weitere Vereinfachung bei der Nutzung solcher Dienste ergibt sich aus der Einheit von Netz- und Service-Steuerung, die in jedem Netzknoten integriert bereitgestellt und auch genutzt werden. Eine Diensteanforderung wird dann von Knoten zu Knoten weitergegeben, wobei jeder Knoten die erforderlichen Netz-Ressourcen bereitstellt.
II. Auch im Bereich der ATM-Technik (Asynchronous
Transfer Mode) , deren Entwicklung mit dem Ziel einer Erweiterung des ISDN hin zu einem breitbandigen und multimedia-fähigen B-ISDN vorangetrieben wurde, gilt die integrierte Bereitstellung von Netz- und Service- Steuerung. Ein Satz von 'well known network Services' (im Wesentlichen sind das CBR, VBR, ABR, UBR und GFR) mit durch die Standardisierung festgelegten Eigenschaften steht zur Auswahl und kann über die Signalisierung direkt angefordert werden. Da über den Netzdienst Eigenschaften, wie z.B. die QoS, bereits bestimmt sind, muß daneben nur noch eine (ebenfalls standardisierte) Beschreibung des angelieferten Verkehrs (z.B. durch Parameter wie Peak Rate und Sustainable Rate im Falle von VBR) mitgegeben werden. (Die Vorgaben bez. der QoS gelten natürlich nur dann, wenn gewisse Randbedingungen, z.B. bez. der maximalen Anzahl durchlaufener Knoten etc., eingehalten werden.)
III. Für IP-basierte Netze gibt es aus den Aktivitäten der Internet Engineering Task Force ( ETF) eine Reihe von Ansätzen, die auf eine mögliche Bereitstellung von QoS hinzielen. Der am weitesten gehende Ansatz (und somit wohl der für diese Erfindungsmeldung nächstliegende Stand der Technik) ist das Konzept der 'Integrated Services' (IntServ). Das zugehörige
Signalisierverfahren basiert auf dem 'Resource Reservation Protocol ' (RSVP, RFC 2205 und RFC 2210 ff.)) und arbeitet nach dem folgenden Grundprinzip: Am Ausgangspunkt einer Kommunikationsbeziehung (Sender) wird eine 'Path Message' losgeschickt, die quasi den Weg durch das Netz erkunden soll. Sie enthält eine Beschreibung des von dem Sender zu generierenden Verkehrs (Sender TSpec) und einen Bereich (RSVP ADSpec) , in den die durchlaufenen Teilnetze und Netzknoten Information über ihre
Eigenschaften und Fähigkeiten, die für die Behandlung des zu erwartenden Datenstromes von Bedeutung sein könnten, eintragen. Nach der Ankunft der Path Message an der Datensenke (Receiver) , erstellt der Receiver mit Hilfe dieser
Informationen eine RSVP FlowSpec, die nun in einer 'Reservation Message' entlang des erkundeten Pfades durch das Netz zurück zum Sender geschickt wird und dabei entsprechende Ressourcen reserviert und den Pfad für die Nutzung einstellt.
Dieses Verfahren ist sehr universell, aber auch immens aufwendig, da es versucht, jeder nur denkbaren Eventualität im Netz Rechnung zu tragen und aus einem Gesamtbild eine entsprechende Reservierungsstrategie abzuleiten. Die hohe
Komplexität führt zu einer sehr eingeschränkten Skalierbarkeit und damit auch nur einer beschränkten Nutzbarkeit. b) Der 'Differentiated Services' Ansatz (DiffServ, s. z.B. RFCs 2474 und 2475) beschränkt sich auf eine einfache Markierung der Datenpakete entsprechend ihrer Zugehörigkeit zu einer Verkehrsklasse. Damit kann die Klassenzugehörigkeit über die Grenzen von Netzdomänen hinweg (d.h. zwischen verschiedenen Teilnetzen) signalisiert werden und eine unterschiedliche ('differenzierte') Behandlung der Datenpakete verschiedener Verkehrsklassen in den einzelnen Netzknoten (dargestellt durch sog. 'Per Hop Behaviours ' , z.B. RFCs 2597, 2598) vorgenommen werden. Aussagen über gewünschte oder tatsächlich erzielbare Ende-zu-Ende-Eigenschaften in komplexen Netzen sind bei diesem Vorgehen in der Regel aber nicht möglich.
c) MPLS (s. z.B. RFC3031) wird häufig im Zusammenhang mit QoS und Zuverlässigkeit von Netzen zitiert. Es verwendet fest eingestellte Pfade, die über ein sog. 'Label Distribution Protocol' (LDP) avisiert werden. Ein solches Protokoll kann natürlich auch zur Signalisierung weitergehender Anforderungen (z.B. in Bezug auf QoS etc.) verwendet werden. In diesem Zusammenhang wird sehr häufig eine
Erweiterung von RSVP mit Einschluß der Label Distribution vorgeschlagen (s. auch RFCs 3209, 3210) . Damit erbt ein MPLS-Anwender aber neben dem Verlust der Vorteile des freien Routens (Einschränkung auf feste Pfade) zusätzlich auch noch die Komplexität und die Skalierbarkeitsprobleme des IntServ-Konzeptes . Alle genannten Ansätze adressieren mehr oder weniger nur eine Teilproblematik der komplexen NGN-Signalisierungsaufgabe und zeigen deshalb auch nur Lösungen für die jeweiligen Teilbereiche auf. Der einzige umfassende Ansatz, RSVP, disqualifiziert sich aufgrund seiner hohen Komplexität und der damit verbundenen Probleme im praktischen Einsatz selbst. Eine brauchbare Lösung, die der Gesamtproblematik (auch über das reine Thema der QoS hinaus) gerecht wird und unter den verschiedenartigen möglichen Randbedingungen einer NGN- Implementierung sinnvoll und wirtschaftlich einsetzbar ist, ist derzeit offenbar nicht bekannt.
Ein einfacher Lösungsansatz ergäbe sich natürlich unter der Annahme der ausschließlichen Verwendung global standardisierter und verfügbarer 'well known network Services' (vgl. oben 'ATM'). Ein Zustandekommen einer entsprechenden Vereinbarung muß aber mit zunehmendem Wettbewerb zwischen den Betreibern (Deregulierung) und auch verschiedenen Standardisierungsgremien als eher unwahrscheinlich angesehen werden.
Dem Anmeldungsgegenstand liegt das Problem zugrunde, für ein paketorientiertes, verbindungsloses Kommunikationsnetz ein Verfahren zur Anmeldung und Bereitstellung der erforderlichen Netzressourcen zur Sicherstellung der anwenderspezifischen
Anforderungen an die gewünschten Netzdienste, z. B. bezüglich einer Quality of Service (QoS) oder einer Zuverlässigkeit und Verfügbarkeit der Dienste, zur Verfügung zu stellen.
Das Problem durch die Merkmale des kennzeichnenden Teils des Anspruchs 1 gelöst.
Mit dem Anmeldungsgenestand verbundene Vorteile:
- Die Signalisierung beinhaltet nicht nur eine
Verkehrsbeschreibung, sondern explizit und konkret die Anforderungen der Verkehrsquelle z.B. in Bezug auf QoS und/oder Reliability des angeforderten Dienstes.
- Die Signalisierung enthält zusätzlich optional eine Network Service-Spezifikation/Anforderung mit entweder globaler (netzweit) oder lokaler (nur am aktuellen Peering Point) Bedeutung.
Optionale Auswertung der konkreten Anforderungen auch dann, wenn eine Network Service-Spezifikation zur Anforderung eines konkret definierten Netzdienstes vorliegt (Möglichkeit eines 'Overrun').
Gleichzeitiges Reservieren der Ressourcen und Prüfen der Einhaltung der verschiedenen Netzbudgets (z.B. bez. packet loss, delay oder delay Variation) in einem einzigen Netzdurchlauf . - Optionaler modularer Aufbau der Anforderungsmeldung erlaubt freie Auswahl und Zusammenstellung der Inhalte.
- Einfache Grundstruktur und modularer Aufbau ermöglichen eine Vielzahl von Varianten bez. des Gesamtablaufes einer Reservierung bzw. Ablehnung.
Weitere Vorteile:
• Das Verfahren reduziert den Aufwand für die Signalisierung von Anforderungen und die Reservierung geeigneter Netzressourcen auf ein Minimum und erlaubt dabei eine zuverlässige Prüfung des Einhaitens der
Anforderungen.
• Das Verfahren ist unabhängig von spezifischen Eigenschaften einzelner Teilnetze und ohne besondere Voraussetzungen in beliebigen, heterogen aufgebauten NGNs einsetzbar.
• Durch die explizite Signalisierung der Anforderungen kann in jedem Teilnetz der optimale (sowohl bez. Erfüllung der reinen Anforderungen als auch bez.
Wirtschaftlichkeit) Netzdienst gewählt werden.
• Die Option, einen (global oder lokal) 'vereinbarten' Netzdienst zu wählen, erleichtert sowohl die Standardisierung als auch das Peering zwischen Teilnetzen.
• Für eine erfolgreiche Reservierung ist in jeder betroffenen Netzinstanz nur ein komplexer Vorgang notwendig (bei RSVP sind es zwei: Erkunden im Vorwärtsdurchlauf und Reservieren im Rückwärtsdurchlauf) .
• Ein erfolgreicher Wegeaufbau kann schnell abgewickelt werden (ein Durchlauf, eine direkte Quittung) . Bei Nichterfolg kann die zusätzliche Verzögerung durch den Wiederabbau als eine Art implizite Überlastabwehr zur Verzögerung einer erneuten Anfrage genutzt werden. (Geringe Effizienz-Einbussen bez. der Auslastung, bedingt durch 'Reservierung vor Freigabe', müssen bei allen Reservierungsverfahren in Kauf genommen werden. ) • Die zeitliche Koinzidenz von Anfrage und Reservierung garantiert die Verfügbarkeit der 'erkundeten' Wegeeigenschaften.
• Das 'Aufsammeln' der Wegeeigenschaften gibt größtmögliche Freiheit bez. der in den Teilnetzen verwendeten Mechanismen und Technologien und ermöglicht dennoch eine sehr gute Einschätzung des Erreichens oder Nichterreichens der Anforderungen.
Der vorgeschlagene Ansatz kann nicht nur für die Signalisierung von QoS-Anforderungen sondern auch für oder in
Kombination mit Anforderungen jedweder sonstigen Art, z.B. bez. Zuverlässigkeit und Verfügbarkeit der angeforderten Netzdienstleistung, eingesetzt werden. Der Anmeldungsgegenstand wird im folgenden als
Ausführungsbeispiel in einem zum Verständnis erforderlichen
Umfang anhand einer Figur näher erläutert . Das Signalisierverfahren weist zwei Schritte auf. Im ersten
Schritt wird eine Anforderungsmeldung von der Quellenseite zur Senkenseite geschickt. Im zweiten Schritt wird entweder eine Bestätigung oder eine Ablehnung zur Quellenseite zurückgeschickt. Das Verfahren unterstützt unidirektionale Datenflüsse, da in IP-Netzen davon ausgegangen werden muß, daß hin- und zurücklaufender Verkehr einer bidirektionalen Kommunikationsbeziehung nicht notwendigerweise denselben Weg nimmt. Für bidirektionale Kommunikationsbeziehungen ist das Verfahren für jede Richtung separat anzuwenden.
Die Anforderungsmeldung hat ihren Ursprung entweder bei der Quelle selbst oder bei einem für diese tätigen Agenten oder Proxy. In jedem Falle passiert sie das Zugangsnetz, an das die Quelle angeschlossen ist, und marschiert dann durch eines oder mehrere der verschiedene Teilnetze des Gesamtnetzes zum Zugangsnetz der Senke und endet schließlich entweder in der Senke selbst oder einem für diese tätigen Agenten oder Proxy. Die Anforderungsmeldung beinhaltet in einem ersten Informationsblock (Block 1) eine Beschreibung des von der Quelle zu senden beabsichtigten Verkehrs (z.B.
Bandbreiteninformation, Variabilität/Burstiness, etc. (vgl. z.B. RSVP TSpec) ) und zusätzlich in einem zweiten Informationsblock (Block 2) eine genaue Beschreibung verschiedener konkreter Anforderungen/Randbedingungen, die auf dem Weg durch das Netz erfüllt/eingehalten werden müssen. Dazu können z.B. gehören:
• Grenzwerte für QoS-Parameter wie packet loss, packet delay oder packet delay Variation, • Grenzwerte für die Wahrscheinlichkeit, daß der
Informationsfluß (für längere Zeit) unterbrochen wird bzw. abbricht und/oder ein Grenzwert für eine maximal zulässige Unterbrechungszeit des Informationsflusses, • die Zulässigkeit oder Nicht-Zulässigkeit einer Reihenfolgevertauschung der Datenpakete (packet reordering) und/oder Grenzwerte für den zulässigen Umfang eines Reorderings,
• ... In einem sehr einfachen Beispiel könnte z.B. im Block 1 nur ein Bandbreitenwert (z.B. ein Mittel- oder Spitzenwert) und im Block 2 nur eine maximal zulässige Paketverzögerung stehen. Selbstverständlich kann der Block 2 auch leer bleiben, wenn keine weiteren Anforderungen gestellt werden oder diese durch den dritten Informationsblock (s.u.) abgedeckt sind.
In einem dritten Informationsblock (Block 3) kann von der Quelle bzw. deren Agent oder Proxy ein konkreter, netzweit spezifizierter Netzdienst ('well known network service') angefordert werden, falls ein solcher existiert und gewünscht wird. Ist dies nicht der Fall, so bleibt dieser Block (zunächst) leer. In diesem Falle (also wann immer dieser Block leer ist) kann Block 3 an den Übergängen zwischen verschiedenen Netzdomänen (Teilnetzen, auch Zugangsnetze sind Teilnetze!) zur Anforderung von zwischen diesen Teilnetzen (lokal) vereinbarten Netzdiensten benutzt werden. Die Prozedur läuft dann so ab, daß das in Flußrichtung der Anforderungsmeldung erste Teilnetz einen mit dem zweiten Teilnetz vereinbarten und zu den Anforderungen in den Blöcken 1 und 2 passenden Netzdienst (der nur zwischen diesen beiden Gültigkeit haben muß) auswählt und in die Anforderungsmeldung einträgt und diese an das zweite Teilnetz weitergibt. Das zweite Teilnetz wertet die Information aus, nimmt die erforderlichen Reservierungen und Einstellungen vor, löscht den Block 3 der Anforderungsmeldung und verfährt am Übergang zum dritten Teilnetz wieder entsprechend der beschriebenen Regel . Optional kann aber auch ein direktes Mapping der empfangenen Netzdienst-Anforderung auf einen mit dem nachfolgenden Teilnetz vereinbarten Netzdienst erfolgen. Bei nicht identischen Netzdienst-Spezifikationen besteht dabei jedoch die Gefahr eines 'Aufschaukelns ' , d.h. eines Aufsteigens zu immer höherwertigen Diensten, da der Dienst im nächsten Teilnetz keine schlechteren Eigenschaften haben sollte als der lokal genutzte.
Als weitere Option kann in jedem Teilnetz unabhängig vom Vorhandensein einer brauchbaren Block-3-Information eine Auswertung der Block-2-Information (soweit vorhanden) vorgenommen werden. Ist diese aussagekräftig genug, so kann auf dieser Basis der in diesem Teilnetz zu verwendende (lokal oder global spezifizierte) Netzdienst ausgewählt werden. In speziellen Fällen (Option) kann dabei auch von dem ggf. in Block 3 avisierten Netzdienst abgewichen werden ('Overrun'). Die Auswertung der Block-2-Information ist dann verpflichtend, wenn keine gültige oder brauchbare Block-3- Information verfügbar ist. Als Grundannahme wird davon ausgegangen, daß die Block-1-Information immer ausgewertet wird.
Ein vierter Informationsblock (Block 4) dient dem Aufsammeln von Information über den 'Verbrauch' der im Block 2 vorgegebenen 'Anforderungsbudgets ' . Als einfaches Beispiel können hier z.B. die erwarteten (maximalen) Delays in den durchlaufenen Teilnetzen aufsummiert und gegen den in Block 2 angegebenen Grenzwert geprüft werden. (Alternativ könnten auch die Einzelwerte jedes Teilnetzes einfach nur eingetragen werden und an einer anderen (zentralen) Stelle zur Überprüfung gegenüber den Anforderungen ausgewertet werden.)
Diese 'Konformitätsprüfung' ist erforderlich, weil die einzelnen Teilnetze unabhängig voneinander und mit völlig unterschiedlichen Mechanismen und auch unterschiedlich spezifizierten Netzdiensten arbeiten können. Nur bei der durchgehenden Verfügbarkeit und Verwendung eines 'well known network service' kann evt . darauf verzichtet werden, wenn dieser entsprechend umfassend und ausreichend genau spezifiziert ist. Zusätzlich kann in diesem Block auch Information über die gewählte Route eingetragen werden, falls diese nicht eindeutig vorbestimmt ist.
Die Reihenfolge der Blöcke bzw. die generelle Anordnung der Informationselemente in der Anforderungsmeldung kann natürlich beliebig festgelegt werden. Sind die Blöcke durch entsprechende Kennzeichnung individuell eindeutig identifizierbar, so müssen nur die einzelnen Blöcke standardisiert werden und die Anforderungsmeldung kann daraus praktisch frei und modular aufgebaut bzw. zusammengestellt werden ('Options-Prinzip'). Dabei müssen nur die im Einzelfall wirklich notwendigen Blöcke eingebaut werden. Alternativ könnte natürlich auch die Gesamtstruktur der Meldung fest vereinbart (standardisiert) werden.
Erreicht die Anforderungsmeldung die zuständige Instanz auf der Senkenseite (Senke oder deren Agent/Proxy) und liegen die aufgesammelten 'Verbrauchswerte' im Block 4 im zulässigen Rahmen gemäß Block 2 so wird eine Bestätigungsmeldung an die anfordernde Instanz auf der Quellenseite zurückgeschickt, woraufhin das Senden des Informationsflusses freigegeben werden kann. Die Bestätigungsmeldung enthält ggf. auch die im Block 4 der Anforderungsmeldung aufgesammelte Routeninformation. Die Bestätigungsmeldung kann einen beliebigen Weg zu ihrem Ziel nehmen. Übersteigen die aufgesammelten Verbrauchswerte den zulässigen Rahmen so wird eine Ablehnungsmeldung zurückgeschickt. Die Ablehnungsmeldung enthält ggf. Teile der oder auch die gesamte im Block 4 der Anforderungsmeldung aufgesammelte
Information. Damit ergeben sich die folgenden Hauptvarianten: I. Die Ablehnungsmeldung wird 'entlang des
Anforderungspfades' zurückgeschickt. Dabei werden die reservierten Ressourcen Schritt für Schritt wieder freigegeben.
II. Die Ablehnungsmeldung wird auf einem beliebigen Weg zurückgeschickt. Die anfordernde Instanz kann dann entweder a) das Angebot zu den gegenüber der Anforderung schlechteren Bedingungen annehmen und den
Informationsfluß freigeben oder b) die Ablehnung für diesen Versuch akzeptieren. In diesem Falle muß die anfordernde Instanz unverzüglich eine Releaseanforderung entlang dem immer noch reservierten Pfad senden, um die blockierten Ressourcen wieder freizugeben.
Auch während des Durchlaufes der Anforderungsmeldung durch das Netz kann ggf. bereits ein Mangel an Ressourcen, die Nichtverfügbarkeit eines passenden Netzdienstes oder das Überschreiten der Anforderungsspezifikation festgestellt werden. In einem solchen Fall kann (optional) von der feststellenden Instanz sofort eine 'vorzeitige Ablehnung' entlang des bisher reservierten Pfades zurückgeschickt werden. Mit der 'vorzeitigen Ablehnung' werden alle reservierten Ressourcen wieder freigegeben. Selbstverständlich bleibt es im Falle einer Ablehnung (bzw.
Akzeptanz einer Ablehnung gem. II.b) , s. oben) der anfragenden Instanz freigestellt, einen weiteren Versuch mit denselben oder modifizierten Anforderungen zu starten.
Grundsätzlich wird die Anforderungsmeldung einen Meldungskopf beinhalten, der sie eindeutig identifiziert und von anderen
Meldungen unterscheidet . In diesem Kopf können auch grundlegende Informationen übertragen werden. Die nachfolgenden 'Blöcke' werden zur Unterscheidung und Abgrenzung ebenfalls exakt markiert. Block 1 ist 'mandatory', die übrigen sind optional. Die Inhalte und Darstellungen der Blöcke 1, 2 und 4 bedürfen einer Standardisierung Block 3 beinhaltet im einfachsten Fall nur eine Nummer (z.B. codiert in 7 oder 8 Bit) . Die Nummer 5 würde dann den mit der Kennnummer 5 vereinbarten Netzdienst spezifizieren. Ein zusätzlicher Informationsträger (Bit oder Byte) könnte anzeigen, ob es sich um einen globalen oder einen nur lokal vereinbarten Netzdienst handelt, falls diese Information nicht schon implizit in der Kennnummer enthalten wäre.
Ein Netzdienst legt bestimmte Eigenschaften für den Transport von Paketen durch ein Netz fest. Diese Eigenschaften werden vom Netz (statistisch, mit einer bestimmten
Wahrscheinlichkeit) garantiert. Zu den die Eigenschaften beschreibenden Parametern eines Netzdienstes können neben den üblichen QoS Parametern wie Verzögerung oder Verlust auch die Angabe der Zuverlässigkeit oder die Verfügbarkeit (Blockierungswahrscheinlichkeit) des Netzdienstes gehören.
Die von einem Netz angebotenen Netzdienste können im Prinzip in den Grenzen der technischen Möglichkeiten des Netzes frei spezifiziert werden. Mögliche Einflussparameter bei einer zweckmäßigen Festlegung reichen von den Anforderungen der zu übertragenden Anwendungsklassen bis hin zu geschäftlichen und tariflichen Überlegungen des Betreibers.
Beispiel für einen Satz von Netzdiensten, der die gängigen Anwendungen abdeckt :
1. Emergency Network Control (ENC) - Netz-interner Steuerungsverkehr (z.B. Signalisierung)
2. Interactive Real-Time (IRT) - Interaktive Realzeitkommunikation (z.B. Videokonferenzen)
3. Non-Interactive Real-Time (NIRT) - nicht-interaktive
Realzeitkommunikation (z.B. Videoabruf) 4. Transactional and Signalling (TAS) - transaktionsorientierte Anwendungen (z.B. E-Commerce) 5. Best Effort (BE) - Klassischer Datenverkehr ohne besondere Anforderungen (z.B. WWW)

Claims

Patentansprüche
1. Verfahren zum Einrichten einer verbindungslosen, paketorientierten Verbindung über verschiedene Netze hinweg, wobei eine Anforderungsmeldung, in der mehrere Blöcke aufnehmbar sind, von der Quellenseite zur Senkenseite geschickt wird, in dem ersten Block der Anforderungsmeldung eine Beschreibung des von der Quelle zu senden beabsichtigten Verkehrs aufnehmbar ist und eine Rückmeldung von der Senkenseite zur Quellenseite geschickt wird.
2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass ein zweiter Block der Anforderungsmeldung eine Beschreibung der auf dem Weg einzuhaltenden Anforderungen aufweist.
3. Verfahren nach Anspruch 2 dadurch gekennzeichnet, dass in einem dritten Block ein spezifischer Netzdienst anforderbar ist.
4. Verfahren nach Anspruch 2 oder 3 dadurch gekennzeichnet, dass in einem vierten Block die im zweiten Block vorgegebenen Anforderungen akkumulierbar sind.
5. Verfahren nach einem der Ansprüche 2 bis 4 dadurch gekennzeichnet, dass in einem fünften Block Informationen über die gewählte Route ablegbar sind.
6. Verfahren nach einem der vorstehenden Ansprüche dadurch gekennzeichnet, dass in einem Block die Vergebührungs-/charging- Informationen der einzelnen Netze akkumulierbar sind.
7. Verf hren nach einem der vorstehenden Ansprüche dadurch gekennzeichnet, dass die Anforderungsmeldung vor Erreichen der Senkeseite an die
Quellenseite zurückgesandt wird, wenn eine in der
Anforderungsmeldung vorgegebene Anforderung nicht erfüllt ist.
PCT/DE2003/000609 2002-03-01 2003-02-26 Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen WO2003075518A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP03714659A EP1481516A1 (de) 2002-03-01 2003-02-26 Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10209048A DE10209048A1 (de) 2002-03-01 2002-03-01 Verfahren zur Signalisierung von Diensteanforderungen in heterogenen Netzen
DE10209048.3 2002-03-01

Publications (1)

Publication Number Publication Date
WO2003075518A1 true WO2003075518A1 (de) 2003-09-12

Family

ID=27762573

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/000609 WO2003075518A1 (de) 2002-03-01 2003-02-26 Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen

Country Status (3)

Country Link
EP (1) EP1481516A1 (de)
DE (1) DE10209048A1 (de)
WO (1) WO2003075518A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8005137B2 (en) 2005-03-25 2011-08-23 Samsung Electronics Co., Ltd. Video coding and decoding method using weighted prediction and apparatus for the same

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016119080B4 (de) 2016-10-07 2020-11-12 Condias Gmbh Vorrichtung zum elektrochemischen Behandeln von Abwasser

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6163807A (en) * 1997-11-03 2000-12-19 British Telecommunications Public Limited Company Packet network
DE10038878C1 (de) * 2000-08-09 2002-01-10 Siemens Ag Verfahren zum Aufbau einer Verbindung mit vorgegebener Dienstgüte zwischen Kommunikationsnetzen mit Resourcenmanagern

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6163807A (en) * 1997-11-03 2000-12-19 British Telecommunications Public Limited Company Packet network
DE10038878C1 (de) * 2000-08-09 2002-01-10 Siemens Ag Verfahren zum Aufbau einer Verbindung mit vorgegebener Dienstgüte zwischen Kommunikationsnetzen mit Resourcenmanagern

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ALMESBERGER W ET AL: "SRP: a scalable resource reservation protocol for the Internet", COMPUTER COMMUNICATIONS, BUTTERWORTHS & CO. PUBLISHERS LTD, GB, vol. 21, no. 14, 15 September 1998 (1998-09-15), pages 1200 - 1211, XP004146581, ISSN: 0140-3664 *
CHUNG T W K ET AL: "Flow Initiation and ReServation Tree (FIRST): a new Internet resource reservation protocol", COMMUNICATIONS, COMPUTERS AND SIGNAL PROCESSING, 1999 IEEE PACIFIC RIM CONFERENCE ON VICTORIA, BC, CANADA 22-24 AUG. 1999, PISCATAWAY, NJ, USA,IEEE, US, 22 August 1999 (1999-08-22), pages 361 - 364, XP010356600, ISBN: 0-7803-5582-2 *
JEONG S-H ET AL: "QoS support for UDP/TCP based networks", COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, NL, vol. 24, no. 1, 1 January 2001 (2001-01-01), pages 64 - 77, XP004227542, ISSN: 0140-3664 *
KRASNODEMBSKI K ET AL: "END-TO-END QOS PROVISIONING ACROSS HETEROGENEOUS DOMAINS", PROCEEDINGS OF THE IEEE CONFERENCE 2000 ON HIGH PERFORMANCE SWITCHING AND ROUTING. HEIDELBERG, GERMANY, JUNE, 26 - 29, 2000, PROCEEDINGS OF THE IEEE CONFERENCE ON HIGH PERFORMANCE SWITCHING AND ROUTING, NEW YORK, NY: IEEE, US, 26 June 2000 (2000-06-26), pages 333 - 341, XP001075719, ISBN: 0-7803-5884-8 *
ROB NEILSON ET AL: "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment Version 0.7", IEEE INTERNET DRAFT, XX, XX, August 1999 (1999-08-01), pages 1 - 30, XP002186975 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8005137B2 (en) 2005-03-25 2011-08-23 Samsung Electronics Co., Ltd. Video coding and decoding method using weighted prediction and apparatus for the same
US8396123B2 (en) 2005-03-25 2013-03-12 Samsung Electronics Co., Ltd. Video coding and decoding method using weighted prediction and apparatus for the same

Also Published As

Publication number Publication date
DE10209048A1 (de) 2003-09-18
EP1481516A1 (de) 2004-12-01

Similar Documents

Publication Publication Date Title
DE60109809T2 (de) Verfahren und system für betriebsmittelreservierungen in einem multicast-netzwerk
DE69916747T2 (de) Verfahren zur Bereitstellung von Dienstgüte in IP-Netzwerken für verzögerungsempfindliche Verkehr
DE60102367T2 (de) Netzoptimierungsmethode
DE69919569T2 (de) Verwaltung von verbindungsorientierten diensten über das internet-protokoll
DE60017622T2 (de) Auf RSVP-basiertes Tunnelprotokoll zum Bereitstellen von integrierten Diensten
DE60032669T2 (de) Vorrichtung und Verfahren zur Bandbreitenüberwachung
DE60117476T2 (de) Bidirektionales Reservierungsprotokoll
DE60204645T2 (de) Ressourcenverwaltung in heterogenen dienstqualitätsbasierten Paketnetzwerken
DE60003525T2 (de) Übertragung von dienstqualitätsabbildungsinformation in einem paketfunknetz
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
DE60221261T2 (de) Verfahren und anordnung in einem ip-netzwerk
DE60103338T2 (de) Etikettvermitteltes Kommunikationsnetzwerk
EP1451980B1 (de) Verfahren zur uebertragung von daten von applikationen mit unterschiedlicher qualität
DE102006022046B4 (de) Verfahren zum Ermöglichen einer Steuerung der Dienstqualität und/oder der Dienstvergebührung bei Telekommunikationsdiensten
EP1428361B1 (de) Verkehrsbegrenzung mittels zulässigkeitsprüfung für ein paketorientiertes verbindungsloses netz mit qos niveau übertragung
DE102004008376A1 (de) Verfahren und System zum Schaffen einer garantierten Qualität des Dienstes in einem IP-Netz
DE60012736T2 (de) Verfahren zur leitwegerzeugung für mehrfachdatenverkehr
EP1398907B1 (de) Verfahren zur Kontrolle von Übertragungsressourcen eines paketorientierten Kommunikationsnetzes bei Topologieänderungen
EP1908234A1 (de) Verfahren zur steuerung von ressourcen in netzelementen eines telekommunikationsnetzes
EP1249154B1 (de) Verfahren und vorrichtung zur zugangssteuerung eines kommunikationsnetzes
DE10100609A1 (de) Verfahren zum Vergebühren bei der Datenübertragung, zugehörige Einheiten, Zugehöriges Programm und elektronischer Gutschein
EP1665676B1 (de) Verfahren zur laststeuerung in einem paketdatennetz
EP1481516A1 (de) Verfahren zur signalisierung von diensteanforderungen in heterogenen netzen
EP1266496B1 (de) Verfahren und anordnung zur zulässigkeitsprüfung einer dienstnutzung
EP1374627B1 (de) Verfahren und system zum effizienten verwalten von ressourcen in mpls netzwerken

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK 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)
WWE Wipo information: entry into national phase

Ref document number: 2003714659

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2003714659

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2003714659

Country of ref document: EP