EP1733519A1 - Verfahren zur steuerung des datenverkehrs in eimem paketnetz - Google Patents

Verfahren zur steuerung des datenverkehrs in eimem paketnetz

Info

Publication number
EP1733519A1
EP1733519A1 EP05717166A EP05717166A EP1733519A1 EP 1733519 A1 EP1733519 A1 EP 1733519A1 EP 05717166 A EP05717166 A EP 05717166A EP 05717166 A EP05717166 A EP 05717166A EP 1733519 A1 EP1733519 A1 EP 1733519A1
Authority
EP
European Patent Office
Prior art keywords
traffic
packet network
routes
node
lsps
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP05717166A
Other languages
English (en)
French (fr)
Inventor
Johannes Riedl
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
Siemens Corp
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 AG, Nokia Siemens Networks GmbH and Co KG, Siemens Corp filed Critical Siemens AG
Publication of EP1733519A1 publication Critical patent/EP1733519A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • 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/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering

Definitions

  • Is used in a packet network e.g.
  • the IP network uses a special procedure (e.g. multi-protocol label switching, MPLS for short) to transport part or all of the traffic along certain paths (so-called label switched paths, LSP for short) it eg
  • MPLS multi-protocol label switching
  • LSP label switched paths
  • RSVP Exactly one LSP is set up from the ingress router to the egress router using RSVP. After RSVP detects the failure of the LSP, RSVP tries to find an alternative way to the destination. Result: slow troubleshooting
  • At least two ⁇ LSPs are set up from the ingress router to the egress router with or without the help of RSVP; one of them is the “Primary LSP", the others are “Secondary LSPs".
  • Primary LSP means that only this LSP is used for the data transport as long as the data transport is not disturbed by an error on this LSP. If an error is detected on the primary LSP, the first secondary LSP is used. If this is also not available, the second secondary LSP is used, etc.
  • Ingress router and egress router must be the same for all LSPs (primary and secondary). This means that protection against failure of the egress router (s) is not possible.
  • MPLS-TE MPLS Traffic Engineering
  • auto-bandwidth feature is not available by default for the secondary LSP. This can result in the secondary LSP not being able to provide enough bandwidth after an error, which results in packet loss and thus a loss in quality of the connections concerned.
  • Detour LSPs are predefined for an LSP: For each fault that should be taken into account, such a detour LSP is defined: e.g. For each router through which the LSP is running (destination nodes excluded), a detour can be defined that bypasses the next link and the next router and returns to the original LSP as soon as possible. The result: quick troubleshooting, but no protection option for the LSP egress router, time-consuming, no bandwidth guarantee after a failure
  • the invention is explained in more detail below, the drawing comprising three figures supporting the explanation.
  • the figures represent an exemplary section of a packet network which comprises two subnetworks LAN A and LAN B and intermediate networks which contain the routers Ri to R8.
  • the LSPs should be as disjx ⁇ nkt as possible (with the exception of the LSP ingress router) and configured so that the traffic from the router R ⁇ to the LAN B is distributed as evenly as possible between the two LSPs (load balancing) (this load distribution can, for example, result from this can be realized that the N LSPs have the same LSP metric (ie the same evaluation value with regard to the length qualification of the
  • LSPs LSPs
  • ECMP Equal Cost Multi-Path
  • LSPi and LSP 2 should actually be disjoint (except for Ri). This can be achieved, for example, by using RSVP and CSPF (Constraint-Based Shortest Path First) with the help of the "Link Coloring" concept for the construction of the LSPs, which is shown in the example network according to FIGS. 1 to 3 can be done as follows: The links R] .

Landscapes

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

Abstract

Wird in einem IP-Netzwerk das Multi-Protokoll-Label-Switching verwendet, um einen Teil des Verkehrs entlang bestimmter Wege (Label Switched Paths) zu transportieren, so es ist z.B. beim Transport von Daten, die zu einer Echtzeit-Anwendung wie Sprach- oder Videoübertragung gehören notwendig, dass im Fehlerfall (Link- oder Routerfehler) der betroffene Verkehr möglichst schnell umgeleitet wird und damit auf einem Alternativweg zum Ziel gelangt. Die Erfindung löst diese Aufgabe.

Description

Beschreibung
Verfahren zur Steuerung des Datenverkehrs in einem Paketnetz 1. Problem, das der Erfindung zugrunde liegt
Wird in einem Paketnetz, z.B. dem IP-Netzwerk ein spezielles Verfahren verwendet (z.B. das Multi-Protokoll-Label- Switching, kurz MPLS) , um einen Teil des Verkehrs oder auch den gesamten Verkehr entlang bestimmter Wege (sogenannter Label Switched Paths, kurz LSP) zu transportieren, so ist es z.B. beim Transport von Daten, die zu einer Echtzeit- Anwendung wie Sprach- oder Videoübertragung gehören notwendig, dass im Fehlerfall (Link- oder Routerfehler) der betrof- fene Verkehr möglichst schnell umgeleitet wird und damit auf einem Alternativweg zum Ziel gelangt.
2. Bisherige Lösung des genannten Problems
Im Wesentlichen gibt es drei bekannte Möglichkeiten, den Datenverkehr im Fehlerfall auf alternative LSPs umzuleiten:
a) LSP-Aufbau via RSVP (Resource Reservation Protocol) , keine speziellen Schutzmassnahmen:
Es wird genau ein LSP vom Ingress-Router bis zum Egress- Router mit Hilfe von RSVP aufgebaut. Nachdem RSVP den Ausfall des LSP erkannt hat, versucht RSVP einen alternativen Weg zum Ziel zu finden. Folge: langsame Fehlerbehebung
• In einem großen Netz dauert es in einem Fehlerfall lange, bis alle betroffenen LSPs wiederhergestellt sind (fällt ein Link/Router aus, so sind i.A. viele LSPs gleichzeitig betroffen) : das ist nicht akzeptabel für Echtzeit- Anwendungen. b) Primary/Secondary LSP:
Es werden mindestens zwe± LSPs vom Ingress-Router bis zum Egress-Router mit oder ohne Hilfe von RSVP aufgebaut; einer davon ist der "Primary LSP", die anderen sind "Secondary LSPs". "Primary LSP" bedeutet dabei, daß nur dieser LSP für den Datentransport verwendet wird, solange der Datentransport nicht durch einen Fehler auf diesem LSP gestört wird. Wird ein Fehler auf dem primary LSP erkannt, so wird der erste se- condary LSP verwendet. Ist auch dieser nicht verfügbar, so wird der zweite secondary LSP verwendet, usw.
Folge: schnelle Fehlerbehebung, aber keine Schutzmöglichkeit des LSP Egress-Routers und keine Bandbreitengarantie nach einem Ausfall.
• Ingress-Router und Egress-Router müssen für alle LSPs (primary und secondary) gleich sein. Damit ist kein Schutz gegen einen Ausfall des (der) Egress-Router (s) möglich.
• Wird MPLS-TE (MPLS Traffic Engineering) verwendet, so ist die automatische Bandbreitenreservierung (auto-bandwidth- feature) nicht standardgemäß für den secondary LSP verfüg- bar. Das kann zur Folge haben, dass der secondary LSP nach einem Fehlerfall nicht genügend Bandbreite zur Verfügung stellen kann, was sich in Paketverlust und damit Qualitätseinbußen der betroffenen Verbindungen äußert.
c) MPLS Fast ReRoute (MP-LS FRR)
Für einen LSP werden eine Anzahl von sog. "Detour LSPs" vordefiniert: Für jeden Fehlerfall, der berücksichtigt sein soll, wird ein solcher detour LSP definiert: z.B. kann für jeden Router, durch den der LSP läuft (Zielknoten ausgeschlossen) ein detour definiert werden, der den nächsten Link und den nächsten Router umgeht und so bald wie möglich wieder in den ursprünglichen LSP mündet . Folge: schnelle Fehlerbehebung, aber keine Schutzmöglichkeit des LSP Egress-Routers, aufwendig, keine Bandbreitengarantie nach einem Ausfall
• Auch hier kann der Egress-Router nicht geschützt werden. • Die Anzahl der zu verwaltenden (detour) LSPs kann bei langen LSPs und großen Netzen enorm groß werden.
• Standardgemäß ist keine Bandbreitenreservierung für detour LSPs vorgesehen. Damit können im Fehlerfall keinerlei Bandbreiten garantiert werden .
3. Erfindungsgemäße Lösung des genannten Problems
Im folgernden wird die Erfindung näher erläutert, wobei die Zeichnung, die drei Figuren umfasst, die Erläuterung unterstützt. Die Figuren stellen einen beispielhaften Ausschnitt eines Paketnetzes dar, der zwei Sub-Netze LAN A und LAN B so- wie Zwischen-Netze umfasst, die die Router Ri bis R8 enthalten.
Gemäß der Erfindung werden für einen Teil des Verkehrs oder den gesamten Verkehr, der aus einer bestimmten Quelle (in den Figuren LAN A) stammt und der über den Eingangsknoten (= LSP Ingress Router) für das erfindungsgemäße Verfahren (in den Figuren Router t)verläuft, N > 2 primary LSPs (d.h. LSPs, die im fehlerfreien Fall für den Datentransport verwendet werden) in Richtung Ziel (in den Figuren LAN B) eingerichtet (in den Figuren ist N = 2) . Die Ausgangsknoten (= LSP Egress Router) für das erfindungsgemäße Verfahren sollten möglichst nicht für alle LSPs die gleichen sein (Rj = Router j ) .
Die LSPs sollten möglichst disjxαnkt (mit Ausnahme des LSP Ingress Routers) und so konfiguriert sein, dass der Verkehr vom Router Rα hin zum LAN B per Lastverteilung (load balan- cing) auf beide LSPs möglichst gleichmäßig verteilt wird (diese Lastverteilung kann z.B. dadurch realisiert werden, dass den N LSPs die gleiche LSP—Metrik (d.h. der gleiche Be- wertungs-Wert hinsichtlich der Längen-Qualifizierung der
LSPs) zugewiesen wird und ECMP (Equal-Cost-Multi-Path) für die LSPs aktiviert wird, woraufhin der Verkehr zum Ziel-LAN auf alle LSPs aufgeteilt wird, die die gleiche Metrik besitzen) . Fällt nun eine LSP-Komponente, z.B. ein Link und/oder ein Router auf einem der beiden LSPs (z.B. LSPi) aus, so erhält der Router Ri eine entsprechende Fehlermeldung. Darauf- hin ermittelt der Router Rx den von dem Fehler betroffenen
LSP und schließt lediglich diesen LSP vom load balancing aus . In den gemäß Figur 2 und 3 gezeigten Fällen (Link Fehler, Router Fehler) bedeutet dies, dass gar kein load balancing mehr stattfindet, da ja nur noch ein LSP zum Ziel verfügbar ist; deshalb wird hier nun der gesamte Verkehr über den LSP2 transportiert .
War jedoch N > 3, so findet auch nach Auftreten eines Fehlers ein load balancing durch den Router R_ statt, jedoch nur noch über N-l LSPs.
Bemerkung:
Um den Vorteil der Erfindung voll zur Geltung zu bringen, sollten LSPi und LSP2 tatsächlich disj nkt sein (bis auf Ri) . Dies kann beispielsweise dadurch erreicht werden, dass RSVP und CSPF (Constraint-Based Shortest Path First) unter zu Hil- fenahme des "Link Coloring" Konzeptes für den Aufbau der LSPs verwendet werden, was in dem Beispiel-Netzwerk gemäß der Figuren 1 bis 3 wie folgt geschehen kann: Die Links R].-R2, R2- R3 und R3-R werden "rot" markiert; die Links R5-R6, R6~R und R7~R8 werden "grün" markiert; die Links R1-R5, R2-Re, R3-R7 und R4-R8 werden sowohl "rot" als auch "grün" markiert (Markieren bedeutet dabei, dass die Links bestimmten administrativen Gruppen zugeordnet werden, nämlich den Gruppen "rot" und "grün"; dabei ist es zulässig und nötig, dass manche Links mehr als einer solchen Gruppe angehören) . Nun wird RSVP so konfiguriert, dass LSPi nur "rote" Links und LSP2 nur grüne Links verwendet. 4. Vorteile der erfindungsgemäßen Lösung
• Schutz des (der) Egress-Router (s) : Auch wenn der LSP Egress Router (in obigem Beispiel R bzw. -R8) ausfällt, sind die übrigen LSPs voll verfügbar. Dies ist weder mit "MPLS FastReRoute" noch mit "MPLS primary/secondary LSP" realisierbar.
• Schnelle Fehlerbehebung: Im Fehlerfall muss lediglich der defekte LSP aus dem Load Balancing vom LSP Ingress Router (in obigem Beispiel Ri) ausgeschlossen werden. Das führt zu sehr kleinen Ausfallzeiten.
• Einfach realisierbar: Die Anzahl der verwendeten LSPs wird vergleichsweise klein gehalten: um absolute Sicherheit gegenüber m-fach-Fehler zu erhalten benötigt man (m+1) LSPs. In obigem Beispiel ist m=l .
• Bandbreitengarantie auch im Fehlerfall: Alle Features (wie z.B. das Auto-bandwidth-feature, das darin besteht, daß die für die LSPs reservierte Bandbreite dynamisch der aktuellen VerkehrsSituation angepasst wird) , die für primary LSPs verfügbar sind, können für alle LSPs genutzt werden (sogar im Fehlerfall) . Für secondary/detour LSPs steht oft nur eine verringerte Featureauswahl zur Verfügung.

Claims

Patentansprüche
1. Verfahren zur Steuerung des Datenverkehrs in einem Paketnetz, demgemäß a) ein Teil des Verkehrs oder der gesamte Verkehr, der aus einem ersten Subnetz (LAN A) des Pa-ketnetzes stammt und dessen Ziel in einem zweiten Subnetz (LAN B) des Paketnetzes liegt, über einen bestimmten Knoten (Rl) des Paketnetzes geführt wird, b) von dem genannten Knoten veranlasst wird, dass für den genannten Verkehr in Richtung des Ziel-Subnetzes mindestens zwei Wege eingerichtet werden, c) der Verkehr über die genannten eingerichteten Wege verteilt transportiert wird, d) einer der genannten Wege von der genannten Verteilung des Verkehrs ausgeschlossen wird, wenn dieser Weg von dem Ausfall einer Komponente betroffen ist .
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die genannten Wege so eingerichtet werden, dass sie mit Ausnahme des ersten Knotens ausschließlich über verschiedene Knoten führen.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die genannten Wege in Richtung Zi-el-Subnetz so eingerichtet werden, dass sie nicht an einem Knoten des Paketnetzes enden, sondern an verschiedenen Knoten.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass es sich bei dem genannten Paketnetz um das IP-Netz und bei den genannten Knoten um Router handelt.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass das genannte Einrichten der Wege mithilfe von MPLS realisiert wird, wobei die genannten Wege dann als LSPs (Label- switched Paths) bezeichnet werden.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass a) die genannten Wege (LSPs) mit Hilfe von RSVP (Resource Reservation Protocol) aufgebaut werden, b) die Eigenschaft der Wege, untereinander disjunkt zu sein, unter Zuhilfenahme von CSPF (Constraint Shortest Path First) und eines "Link Coloring" Konzeptes er- zielt wird.
7. Knoten eines Paketnetzes, a) der veranlasst, dass für einen Teil des Verkehrs oder den gesamten Verkehr, der über ihn verläuft und dessen Ziel in einem Subnetz des Paketnetzes liegt, mindestens zwei vorgegebene Wege eingerichtet werden, b) der den genannten Verkehr im ehlerfreien Fall über die genannten eingerichteten Wege verteilt, c) der einen der genannten Wege von der genannten Verteilung des Verkehrs ausschließt, wenn er erfährt, daß dieser Weg durch den Ausfall einer Weg-Komponente betroffen ist.
8. Knoten nach Anspruch 7, dadurch gekennzeichnet, dass er das Einrichten der genannten Wege in Richtung Ziel so steuert, dass sie nicht an einem Knoten, sondern an verschiedenen Knoten enden.
9. Knoten nach Anspruch 7 oder 8 , dadurch gekennzeichnet, dass es sich bei dem Paketnetz um das IP-Netz und bei den genannten Knoten um Router handelt .
EP05717166A 2004-04-06 2005-04-04 Verfahren zur steuerung des datenverkehrs in eimem paketnetz Withdrawn EP1733519A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004016941A DE102004016941A1 (de) 2004-04-06 2004-04-06 Verfahren zur Steuerung des Datenverkehrs in einem Paketnetz
PCT/EP2005/051498 WO2005099186A1 (de) 2004-04-06 2005-04-04 Verfahren zur steuerung des datenverkehrs in eimem paketnetz

Publications (1)

Publication Number Publication Date
EP1733519A1 true EP1733519A1 (de) 2006-12-20

Family

ID=34964687

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05717166A Withdrawn EP1733519A1 (de) 2004-04-06 2005-04-04 Verfahren zur steuerung des datenverkehrs in eimem paketnetz

Country Status (3)

Country Link
EP (1) EP1733519A1 (de)
DE (1) DE102004016941A1 (de)
WO (1) WO2005099186A1 (de)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6081511A (en) * 1996-08-14 2000-06-27 Cabletron Systems, Inc. Load sharing for redundant networks
US6112249A (en) * 1997-05-30 2000-08-29 International Business Machines Corporation Non-disruptively rerouting network communications from a secondary network path to a primary path
JP3695362B2 (ja) * 2001-07-12 2005-09-14 日本電気株式会社 通信コネクション迂回システム
JP4297636B2 (ja) * 2001-08-21 2009-07-15 富士通株式会社 伝送システム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2005099186A1 *

Also Published As

Publication number Publication date
WO2005099186A1 (de) 2005-10-20
DE102004016941A1 (de) 2005-10-27

Similar Documents

Publication Publication Date Title
EP1584161A1 (de) Verfahren und anordnung zum routing von datenpaketen in einem paketvermittelnden datennetz
DE60209096T2 (de) Schnelles Pfadwiederherstellungsverfahren in Label-Vermittlungsnetzwerken und Netzwerkanordnung zur Ausführung des Verfahrens
EP1623541B1 (de) Verfharen und netzknoten fuer eine selbst-regulierende, autonome und dezentrale verkehrsverteilung in einem mehrwege-netz
WO2012101054A1 (de) Verfahren zum erhöhen der qualität der datenübertragung in einem paketbasierten kommunikationsnetz
EP1629642A1 (de) Verfahren für eine Verkehrsverteilung mittels Hash-Codes entsprechend einer Soll-Verkehrsverteilung in einem paketorientierten Netz mit Mehrwege-Routing
DE10219153A1 (de) Verfahren zur Überprüfung der Durchgängigkeit von Verbindungen in MPLS-Netzen
EP2775677B1 (de) Verfahren zur Übertragung von Datenpaketen in einem Datennetz aus einer Vielzahl von Netzknoten
EP1262084B1 (de) Verfahren zum ersatzschalten von übertragungseinrichtungen in mpls-netzen
DE10237584B4 (de) Verfahren zur Verwaltung von Ressourcen beim Aufbau eines Ersatzpfades in einem transparent schaltbaren Netzwerk
EP1733519A1 (de) Verfahren zur steuerung des datenverkehrs in eimem paketnetz
DE10337465B4 (de) Verfahren zum Routing von Datenpaketen in einem mehrere Netzknoten aufweisenden paketvermittelnden Kommunikationsnetz
EP1488582A1 (de) Verfahren für den betrieb und die überwachung von mpls-netzen
EP1313347A1 (de) Routing in Übertragungsnetzen
DE10324370B4 (de) Netzknoten eines paketvermittelnden Kommunikationsnetzes und Verfahren zur Verkehrsverteilung von Datenverkehr in einem paketvermittelnden Kommunikationsnetz
DE10308614A1 (de) Verfahren und Anordnung zum Routing von Datenpaketen in einem paketvermittelnden Datennetz
EP1894363A1 (de) Verfahren und unabhängiges kommunikationsteilnetz zum ermitteln labelvermittelter routen in einem solchen kommunikationsteilnetz
DE602006000136T2 (de) Vorreservierung von Ressourcen für Verbindungswege in einem Kommunikationsnetz an Kommunikation von Anschriften von Päckchen oder von Etiketten
DE10260640A1 (de) Verfahren zur Topologie-Erkennung und Weglenkung von Datenpaketen in einem Pakete vermittelnden Ring
DE10328620B4 (de) Verfahren und Netzknoten zur Wegesuche in einem paketvermittelnden Kommunikationsnetz
DE10340809A1 (de) Optimierung der Routenbestimmung in einem Netz mit Mehrwege-Routing
WO2005101754A1 (de) Netz-ausgangs-bezogenes policing
DE10325017A1 (de) Statistisches Verfahren für eine Verkehrsverteilung entsprechend Verkehrs-Verteilgewichten in einem paketorientierten Netz mit Mehrwegerouting
WO2005004412A1 (de) Versand von ip-datenpaketen über signatur-schalt-pfade
WO2005034442A1 (de) Schnelle fehlerreaktion in lose vermaschten ip-netzen
DE102005059268A1 (de) Ressourcen-effizientes lokales Umleiten in Kommunikationsnetzen mit Transport von Verkehr über Pfade

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060825

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE ES FR GB IT

R17C First examination report despatched (corrected)

Effective date: 20070112

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE ES FR GB IT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20070724