EP1821491B1 - A multicast realizing method in access device based on main and backup board switching - Google Patents

A multicast realizing method in access device based on main and backup board switching Download PDF

Info

Publication number
EP1821491B1
EP1821491B1 EP06775464A EP06775464A EP1821491B1 EP 1821491 B1 EP1821491 B1 EP 1821491B1 EP 06775464 A EP06775464 A EP 06775464A EP 06775464 A EP06775464 A EP 06775464A EP 1821491 B1 EP1821491 B1 EP 1821491B1
Authority
EP
European Patent Office
Prior art keywords
board
multicast
active
standby
data
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.)
Not-in-force
Application number
EP06775464A
Other languages
German (de)
French (fr)
Other versions
EP1821491A1 (en
EP1821491A4 (en
Inventor
Jinning Huawei Technologies Co. Ltd YU
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of EP1821491A1 publication Critical patent/EP1821491A1/en
Publication of EP1821491A4 publication Critical patent/EP1821491A4/en
Application granted granted Critical
Publication of EP1821491B1 publication Critical patent/EP1821491B1/en
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2858—Access network architectures
    • H04L12/2861—Point-to-multipoint connection from the data network to the subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2869—Operational details of access network equipments
    • H04L12/2878—Access multiplexer, e.g. DSLAM
    • H04L12/2879—Access multiplexer, e.g. DSLAM characterised by the network type on the uplink side, i.e. towards the service provider network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • 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/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/58—Association of routers
    • 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/58—Association of routers
    • H04L45/586—Association of routers of virtual routers
    • 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/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity

Definitions

  • the present invention relates to communication technology and in particular, it relates to a method for ensuring IP multicast service quality in access devices.
  • Active and standby hot switchover refers to two identical boards operating simultaneously, one board is active and one board functions as a standby.
  • many access devices that support multicast video services support active and standby hot switchover. Consequently, when the active board breaks down, the system automatically switches over to the standby board.
  • control board and network board are all in one, so when active board to standby board switchover occurs it cuts off transmission of the multicast video stream.
  • client online and offline behavior is dynamic and unpredictable, the method used in the current technology is that client online data is not processed. Consequently, after switchover all online clients become offline. If a client wishes to watch a program, they must actively reorder the program in the same way as it originally came online.
  • the aim of switchover is to reduce failure time of a single board and its effect on service to an absolute minimum.
  • switchover causes all multicast clients to go offline, it affects all clients on every port of this access device, which is inconsistent with the motive and aim of switchover.
  • the standby board does not backup the CDR (Call Detail Record)
  • the new active board following switchover, will lose the multicast service CDR.
  • the provider uses the CDR to calculate client's video reception charge; this clearly causes the provider to suffer a significant loss.
  • CN1437348A discloses a method for synchronizing data between the active board and the standby board in a communication system, including: setting a data buffer in the active board and the standby board respectively; once data is changed in the active board, writing the changed data of the active board into the buffer; the buffer processes the data; when the data in the buffer reaches a specified quantity, the real-time synchronization process of the active board reads data from the buffer and sends it to the real-time synchronization process of the standby board; updating the database of the standby board and returning the operation result to the active board; if the operation result is synchronization success, deleting the corresponding data in the buffer; otherwise, resending data until the records in the buffer are empty.
  • WO99/03038A discloses a method for detecting a failure in a fault-tolerant computer system and a corresponding fault-tolerant computer system.
  • the computer system is able to detect failures associated with a primary input/output processors as well as with a standby input/output processors, and is also able to discriminate between failures of the input/output processors and communication failures in the data communication network itself.
  • the purpose of the invention is to provide a method that ensures the quality of IP multicast service, keeps clients online during switchover of access devices, ensures an uninterrupted multicast stream, and decreases the impact of switchover on the multicast service.
  • method for implementing multicast in an access device based on switchover between an active board and a standby board comprising: a maintaining a real time communication between a standby board and an active board, and checking an operating status of the active board at all times;
  • the new active board sends a multicast data stream request to an upstream router based on saved data.
  • This invention also provides an access device according to claim 9.
  • Various embodiments are provided according to the dependent claims.
  • Adopting the technical scheme of this invention guarantees that clients remain online during switchover, ensures an uninterrupted video stream, and thereby ensures that the switchover from active to standby does not significantly affect clients. Moreover, clients' multicast service CDR will not be lost which protects the interests of the provider.
  • Figure 1 shows an implementation example of a multicast video network for the present invention, in which the access device supports system switchover.
  • Figure 2 is a procedural flowchart showing the system backup process between active and standby board.
  • Figure 3 is a procedural flowchart for showing the system switchover process between active and standby board.
  • FIG. 1 illustrates a simple example of an IP multicast video network for the present invention, in which the access device supports system switchover.
  • the network is comprised of a video source, ATM/IP network, access device, remote terminal unit (RTU), and Video-on-Demand (VOD) terminal.
  • the access device comprises a main board (active board and standby board) and service board; the uplink port of the main board connects to a remote video source via an IP/ATM network, and an edge router (not shown in this figure) that supports multiple multicast protocols (for example, including IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery) protocols) connects to the access device.
  • IGMP Internet Group Management Protocol
  • MLD Multicast Listener Discovery
  • the service board (such as an xDSL (digital subscriber line) board) connects to the VOD terminal (such as a TV with STB, PC, laptop, Personal Data Assistant (PDA), multimedia mobile phone, etc.) via an RTU (Remote Terminal Unit) (such as an ADSL (Asymmetric Digital Subscriber Line) modem).
  • RTU Remote Terminal Unit
  • ADSL Asymmetric Digital Subscriber Line
  • an access device to remote clients, such as, via PSTN (using optical fiber, twisted pair or other transmission medium), WIMAX (World Interoperability for Microwave Access) and other methods of network access (such as wireless broadband access).
  • the access device described in the above network structure can be a digital subscriber line access multiplexer (DSLAM) or any other access device.
  • DSL digital subscriber line access multiplexer
  • a multicast join message is sent, such as an IGMP report message.
  • the service board then forwards the message to the main board, and the main board then sends the multicast join message to an upstream router.
  • Requests for video streams are sent from routers to the video server using a multicast routing protocol (e.g. PIM-SM (Protocol Independent Multicast - Sparse Mode), PIM-DM (Protocol Independent Multicast-Dense Mode), or MSDP (Multicast Source Discovery Protocol).
  • PIM-SM Process Independent Multicast - Sparse Mode
  • PIM-DM Protocol Independent Multicast-Dense Mode
  • MSDP Multicast Source Discovery Protocol
  • This invention provides flowcharts showing the system backup and switchover processes between the active board and standby board, as shown in figures 2 .
  • the active board is a master control board currently in a working state
  • the standby board is a master control board currently in a backup state.
  • the hot data backup process shown in figure 2 comprises the execution steps for the active board and the standby board.
  • the VOD terminal When a multicast client connects to the network via the VOD terminal of an RTU, the VOD terminal creates a multicast join message from the client's VOD request and sends this to the access device; said method then starts to execute step 110.
  • step 110 the access device receives a multicast client join message and passes it to the main board for processing.
  • step 112 the main control board checks whether the client's multicast request has authority to watch the program and determines the next step according to the check result. If the client does not have authority, go to step 113: the client fails to go online and this method concludes. If the client has authority, then execute step 114.
  • step 114 the access device processes the multicast client and brings it online, generates an online record for the multicast client, sets items in the hardware forwarding table for the video multicast stream, and forwards the video stream from the uplink port of the active board to the client port. In this way, the multicast client can receive the video stream.
  • the standby board executes step 120.
  • the standby board periodically checks whether data on the active board has changed.
  • the standby board detects a data change on the active board (comprising client online record, channel the client is currently watching, channel number, channel status, and timer status) and then sends a backup request to the active board.
  • the active board executes step 116.
  • the active board sends the requested data to the standby board thus ensuring consistency of data between the active board and standby board.
  • the standby board receives the data sent by the active board and sets the items in the hardware forwarding table in the standby board according to the client's online record. Because the uplink port of the standby board is inactive, it does not forward a video stream, thus the items in the hardware forwarding table in the standby board does not interfere with or affect stream forwarding in the active board.
  • a multicast client When a multicast client goes offline (not shown in figure 2 ), it generates a corresponding CDR in the active board. Meanwhile, the online record for the multicast client changes and corresponding items in the hardware forwarding table are deleted.
  • the standby board detects changes to the multicast client online record, multicast client offline record and multicast client CDR on the active board, and sends a backup request to the active board. The active board then sends the requested data to the standby board and the standby board also deletes corresponding items in its hardware forwarding table according to the multicast client offline record and other data. At this point, the multicast client CDR is already backed up on the standby board.
  • the above process ensures that multicast client online and offline dynamic data, call detail records and item settings in the hardware forwarding table on the standby board are identical to those on the active board.
  • the active board in figure 3 is a master control board currently in a working state; the standby board is a master control board currently in a backup state.
  • the system switches from a hot data backup phase to the switchover phase, a particular process for implementing the switchover between the active board and the standby board is as follows.
  • step 118 the active board fails and executes step 124; the standby board detects the abnormal status of active board, immediately implements switchover from the active board to the standby board and the standby board becomes the active board.
  • step 126 is executed; the new active board (i.e. the former standby board) sends multicast join request messages to the upstream router according to the multicast client online records, in order to avoid aging of forwarding table in the upstream router and to ensure an uninterrupted multicast stream.
  • the new active board i.e. the former standby board
  • multicast streams can be transferred to multicast clients quickly.
  • the period of stream interruption during switchover is merely the time it takes to restore communication links between the new active board (i.e. the former standby board) and service boards. The time it takes is in microseconds.
  • step 128 the new active board checks backup data; for example, it checks the logical relationship among backup data to ensure data accuracy and integrity.
  • step 130 is executed; the new active board sends multicast query messages to multicast clients to obtain their current status.
  • the new active board is unable to process protocol messages for a short period of time because it is busy checking each item of data backed up from the old active board, Therefore, during this checking period, the new active board is unable to perform normal processing of multicast query messages and multicast quit messages.
  • it To prevent aging of multicast clients and the inability of multicast clients to go offline, after completing data checks, it must immediately send IGMP query messages to the multicast client in order to ensure the access device obtains the current status of multicast clients as quickly as possible.
  • FIG. 2 illustrates the process of data backup and switchover between active board and standby board.
  • the hot data backup only shows the hot data backup process for multicast clients during the process of coming online.
  • the principle of hot data backup for multicast clients during the process of going offline is consistent with the hot data backup process illustrated in Fig.2 , except that the hot data backup for multicast clients during the process of going offline includes additionally the hot backup for the multicast client CDR.
  • Adopting the method of active and standby data backup and switchover in this invention maintains data consistency in the active and standby boards while operating, and when the active board fails, the standby board becomes the new active board.
  • the new active board sends IGMP report messages to upstream routers requesting the required video stream, and immediately transfers streams to multicast clients using the same hardware forwarding table items as the original active board. Accordingly, it keeps multicast clients online, maintains an uninterrupted video stream, and ensures the multicast client CDR is not lost during the switchover process from active to standby.
  • the new active board sends IGMP query messages to multicast clients to obtain their current status, thus enabling immediate processing of client requirements.
  • a method of the present invention can reduce the impact of active board failure on multicast services and improves multicast service quality.
  • the access device in this invention has an active board and a standby board.
  • the standby board maintains real time communication with the active board, and checks the working status of the active board at any time. Switchover from the active board to the standby board is implemented according to the active board failure detected.
  • the access device presented in this invention is also installed with a backup module, a checking module, a status request module and a multicast stream request module.
  • the backup module, checking module, status request module, and multicast stream request module can be installed in the standby board, and of course, can also be installed independently to the standby board.
  • the backup module is primarily used to change data on the standby board based on changes to multicast client dynamic data in the active board.
  • the multicast client dynamic data comprises: multicast client online record, channel currently being watched by the multicast client, channel number, channel status, timer status, multicast client offline record, multicast client CDR (Call Detail Record), etc..
  • the backup module can refresh the standby board's multicast client CDR according to changes in the multicast client's dynamic data, set or delete items in the hardware forwarding table of the standby board, etc. The detailed method is as described above.
  • the checking module is primarily used to check the accuracy and/or integrity of the data backed up by the Backup Module, after switchover from the active board to the backup board has been performed.
  • the backup board does not process multicast join and multicast leave messages sent by multicast clients during this process normally.
  • the request status module in this invention sends online status query messages to multicast clients. In this way, the post switchover new active board can correctly obtain the multicast client's current status.
  • the multicast stream request module is primarily used once switchover is finished to send multicast stream request messages to the upstream router according to the multicast client online record, channel currently being watched by the multicast client, channel number, channel status, and other data.
  • the upstream router can send the requested multicast data stream to the new active board based on the multicast stream requests it receives.
  • the new active board following switchover provides the multicast client with a multicast service with an uninterrupted multicast stream according to the multicast client online record, channel currently being watched by the multicast client, channel number, channel status, multicast client CDR and other data.
  • the new active board following switchover contains a backup of the multicast user CDR, the access device main board switchover process does not cause loss of the multicast user CDR information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Hardware Redundancy (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer And Data Communications (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

This present invention discloses a type of active and standby board backup and switchover method for access devices, comprising: maintain real time communications between standby board and active board, and check the operating status of the active board at all times; refresh standby board data based on changes to multicast client dynamic data in the active board; perform switchover from the active board to the standby board based on the active board failure detected; the new active board sends a multicast join request to the upstream router based on its saved data. Multicast client dynamic data comprises: multicast client online record, multicast client CDR (Call Detail Record), etc. Adopting the method of this invention guarantees that clients remain online during switchover, ensures an uninterrupted video stream, and thereby ensures that the switchover from active to standby does not significantly affect multicast services for multicast clients. Moreover, clients' multicast service CDR will not be lost, which protects the interests of the provider.

Description

    Field of the Invention
  • The present invention relates to communication technology and in particular, it relates to a method for ensuring IP multicast service quality in access devices.
    • Background of the Invention
  • As networking technology and the Internet has developed, a huge variety of high-bandwidth multimedia applications have appeared, such as video conferencing, e-learning, telemedicine, Internet broadcasting, and so on. However, conventional networks were designed for classical point-to-point communication in order to guarantee reliable data transmission, and the vast majority of transport protocols used are also point-to-point. In this type of conventional network, high-bandwidth multimedia applications necessarily result in network congestion, increased latency and network bottlenecks. People have proposed many different solutions to relieve these bottlenecks, such as increasing bandwidth, changing network traffic structure, and applying IP multicast technology. Because IP multicast can effectively save network bandwidth and decrease network load, this technology has been widely applied.
  • To improve the reliability of communication devices, a scheme using active and standby devices with hot switchover is often applied. Active and standby hot switchover refers to two identical boards operating simultaneously, one board is active and one board functions as a standby. Currently, many access devices that support multicast video services support active and standby hot switchover. Consequently, when the active board breaks down, the system automatically switches over to the standby board.
  • In the majority of current access devices, the control board and network board are all in one, so when active board to standby board switchover occurs it cuts off transmission of the multicast video stream. Because client online and offline behavior is dynamic and unpredictable, the method used in the current technology is that client online data is not processed. Consequently, after switchover all online clients become offline. If a client wishes to watch a program, they must actively reorder the program in the same way as it originally came online.
  • The aim of switchover is to reduce failure time of a single board and its effect on service to an absolute minimum. However, if switchover causes all multicast clients to go offline, it affects all clients on every port of this access device, which is inconsistent with the motive and aim of switchover. Besides, because failure of a single board is unpredictable, if the standby board does not backup the CDR (Call Detail Record), when an active board fails, the new active board, following switchover, will lose the multicast service CDR. The provider uses the CDR to calculate client's video reception charge; this clearly causes the provider to suffer a significant loss.
  • Hence, how to keep clients online during the switchover process, ensure an uninterrupted multicast video stream, and lessen the impact on multicast service is an issue we must consider during switchover.
    CN1437348A discloses a method for synchronizing data between the active board and the standby board in a communication system, including: setting a data buffer in the active board and the standby board respectively; once data is changed in the active board, writing the changed data of the active board into the buffer; the buffer processes the data; when the data in the buffer reaches a specified quantity, the real-time synchronization process of the active board reads data from the buffer and sends it to the real-time synchronization process of the standby board; updating the database of the standby board and returning the operation result to the active board; if the operation result is synchronization success, deleting the corresponding data in the buffer; otherwise, resending data until the records in the buffer are empty.
    In addition, WO99/03038A discloses a method for detecting a failure in a fault-tolerant computer system and a corresponding fault-tolerant computer system. The computer system is able to detect failures associated with a primary input/output processors as well as with a standby input/output processors, and is also able to discriminate between failures of the input/output processors and communication failures in the data communication network itself.
    • Summary of the Invention
  • The purpose of the invention is to provide a method that ensures the quality of IP multicast service, keeps clients online during switchover of access devices, ensures an uninterrupted multicast stream, and decreases the impact of switchover on the multicast service.
  • According to this invention, method for implementing multicast in an access device based on switchover between an active board and a standby board is provided, said method comprising: a maintaining a real time communication between a standby board and an active board, and checking an operating status of the active board at all times;
  • changing data in the standby board based on a change to multicast client dynamic data in the active board;
  • performing a switchover from the active board to the standby board based on a detected failure of the active board ; and
  • the new active board sends a multicast data stream request to an upstream router based on saved data.
  • This invention also provides an access device according to claim 9. Various embodiments are provided according to the dependent claims.
  • Adopting the technical scheme of this invention guarantees that clients remain online during switchover, ensures an uninterrupted video stream, and thereby ensures that the switchover from active to standby does not significantly affect clients. Moreover, clients' multicast service CDR will not be lost which protects the interests of the provider.
    • Brief Description of the Drawings
  • Figure 1 shows an implementation example of a multicast video network for the present invention, in which the access device supports system switchover.
  • Figure 2 is a procedural flowchart showing the system backup process between active and standby board.
  • Figure 3 is a procedural flowchart for showing the system switchover process between active and standby board.
    • Detailed Description of the Embodiments
  • Figure 1 illustrates a simple example of an IP multicast video network for the present invention, in which the access device supports system switchover. In the diagram shown, the network is comprised of a video source, ATM/IP network, access device, remote terminal unit (RTU), and Video-on-Demand (VOD) terminal. Among these, the access device comprises a main board (active board and standby board) and service board; the uplink port of the main board connects to a remote video source via an IP/ATM network, and an edge router (not shown in this figure) that supports multiple multicast protocols (for example, including IGMP (Internet Group Management Protocol) and MLD (Multicast Listener Discovery) protocols) connects to the access device. The service board (such as an xDSL (digital subscriber line) board) connects to the VOD terminal (such as a TV with STB, PC, laptop, Personal Data Assistant (PDA), multimedia mobile phone, etc.) via an RTU (Remote Terminal Unit) (such as an ADSL (Asymmetric Digital Subscriber Line) modem). According to different types of service boards and VOD terminals, there are many ways to connect an access device to remote clients, such as, via PSTN (using optical fiber, twisted pair or other transmission medium), WIMAX (World Interoperability for Microwave Access) and other methods of network access (such as wireless broadband access). The access device described in the above network structure can be a digital subscriber line access multiplexer (DSLAM) or any other access device.
  • During IP multicast services, when a multicast client comes online, a multicast join message is sent, such as an IGMP report message. The service board then forwards the message to the main board, and the main board then sends the multicast join message to an upstream router. Requests for video streams are sent from routers to the video server using a multicast routing protocol (e.g. PIM-SM (Protocol Independent Multicast - Sparse Mode), PIM-DM (Protocol Independent Multicast-Dense Mode), or MSDP (Multicast Source Discovery Protocol). The video stream then follows the transmission circuit taken by the previous message to the uplink port of the main board; then the main board and service board forward them to the client making the request based on a forwarding table. When the currently operating main board breaks down, the access device automatically switches over to the standby board.
  • To ensure that the multicast clients remain online during system switchover, the video stream is not cut off and the multicast client CDR is not lost, thereby the impact on multicast service is minimized as much as possible. This invention provides flowcharts showing the system backup and switchover processes between the active board and standby board, as shown in figures 2.
  • Figure 2 below describes in detail the hot data backup implementation process for this invention. In figure 2, the active board is a master control board currently in a working state; the standby board is a master control board currently in a backup state.
  • The hot data backup process shown in figure 2 comprises the execution steps for the active board and the standby board.
  • When a multicast client connects to the network via the VOD terminal of an RTU, the VOD terminal creates a multicast join message from the client's VOD request and sends this to the access device; said method then starts to execute step 110.
  • In step 110, the access device receives a multicast client join message and passes it to the main board for processing.
  • Then step 112 is executed; the main control board checks whether the client's multicast request has authority to watch the program and determines the next step according to the check result. If the client does not have authority, go to step 113: the client fails to go online and this method concludes. If the client has authority, then execute step 114.
  • In step 114, the access device processes the multicast client and brings it online, generates an online record for the multicast client, sets items in the hardware forwarding table for the video multicast stream, and forwards the video stream from the uplink port of the active board to the client port. In this way, the multicast client can receive the video stream.
  • During logon, the standby board executes step 120. In as much as the system maintains real time communication between the active board and standby board, the standby board periodically checks whether data on the active board has changed. When a multicast client goes online and the active board generates a client online record, the standby board detects a data change on the active board (comprising client online record, channel the client is currently watching, channel number, channel status, and timer status) and then sends a backup request to the active board.
  • Next, the active board executes step 116. The active board sends the requested data to the standby board thus ensuring consistency of data between the active board and standby board.
  • Next, in step 122, the standby board receives the data sent by the active board and sets the items in the hardware forwarding table in the standby board according to the client's online record. Because the uplink port of the standby board is inactive, it does not forward a video stream, thus the items in the hardware forwarding table in the standby board does not interfere with or affect stream forwarding in the active board.
  • When a multicast client goes offline (not shown in figure 2), it generates a corresponding CDR in the active board. Meanwhile, the online record for the multicast client changes and corresponding items in the hardware forwarding table are deleted. At this point the standby board detects changes to the multicast client online record, multicast client offline record and multicast client CDR on the active board, and sends a backup request to the active board. The active board then sends the requested data to the standby board and the standby board also deletes corresponding items in its hardware forwarding table according to the multicast client offline record and other data. At this point, the multicast client CDR is already backed up on the standby board.
  • The above process ensures that multicast client online and offline dynamic data, call detail records and item settings in the hardware forwarding table on the standby board are identical to those on the active board.
  • The following describes the system switchover process in detail with reference to figure 3.
  • The active board in figure 3 is a master control board currently in a working state; the standby board is a master control board currently in a backup state. When a failure in the active board occurs, the system switches from a hot data backup phase to the switchover phase, a particular process for implementing the switchover between the active board and the standby board is as follows.
  • In step 118, the active board fails and executes step 124; the standby board detects the abnormal status of active board, immediately implements switchover from the active board to the standby board and the standby board becomes the active board.
  • Thereupon, step 126 is executed; the new active board (i.e. the former standby board) sends multicast join request messages to the upstream router according to the multicast client online records, in order to avoid aging of forwarding table in the upstream router and to ensure an uninterrupted multicast stream. Because the items in the hardware forwarding table in the new active board (i.e. the former standby board) is already set, multicast streams can be transferred to multicast clients quickly. The period of stream interruption during switchover is merely the time it takes to restore communication links between the new active board (i.e. the former standby board) and service boards. The time it takes is in microseconds.
  • Afterwards, step 128 is executed, the new active board checks backup data; for example, it checks the logical relationship among backup data to ensure data accuracy and integrity.
  • Following this, step 130 is executed; the new active board sends multicast query messages to multicast clients to obtain their current status. During switchover, the new active board is unable to process protocol messages for a short period of time because it is busy checking each item of data backed up from the old active board, Therefore, during this checking period, the new active board is unable to perform normal processing of multicast query messages and multicast quit messages. To prevent aging of multicast clients and the inability of multicast clients to go offline, after completing data checks, it must immediately send IGMP query messages to the multicast client in order to ensure the access device obtains the current status of multicast clients as quickly as possible.
  • Figure 2 illustrates the process of data backup and switchover between active board and standby board. In this figure, the hot data backup only shows the hot data backup process for multicast clients during the process of coming online. The principle of hot data backup for multicast clients during the process of going offline is consistent with the hot data backup process illustrated in Fig.2, except that the hot data backup for multicast clients during the process of going offline includes additionally the hot backup for the multicast client CDR.
  • Adopting the method of active and standby data backup and switchover in this invention maintains data consistency in the active and standby boards while operating, and when the active board fails, the standby board becomes the new active board. The new active board sends IGMP report messages to upstream routers requesting the required video stream, and immediately transfers streams to multicast clients using the same hardware forwarding table items as the original active board. Accordingly, it keeps multicast clients online, maintains an uninterrupted video stream, and ensures the multicast client CDR is not lost during the switchover process from active to standby. In addition, after completing checks on backup data, the new active board sends IGMP query messages to multicast clients to obtain their current status, thus enabling immediate processing of client requirements. In summary, a method of the present invention can reduce the impact of active board failure on multicast services and improves multicast service quality.
  • The access device in this invention has an active board and a standby board. The standby board maintains real time communication with the active board, and checks the working status of the active board at any time. Switchover from the active board to the standby board is implemented according to the active board failure detected. The access device presented in this invention is also installed with a backup module, a checking module, a status request module and a multicast stream request module. The backup module, checking module, status request module, and multicast stream request module can be installed in the standby board, and of course, can also be installed independently to the standby board.
  • The backup module is primarily used to change data on the standby board based on changes to multicast client dynamic data in the active board. Here, the multicast client dynamic data comprises: multicast client online record, channel currently being watched by the multicast client, channel number, channel status, timer status, multicast client offline record, multicast client CDR (Call Detail Record), etc.. The backup module can refresh the standby board's multicast client CDR according to changes in the multicast client's dynamic data, set or delete items in the hardware forwarding table of the standby board, etc. The detailed method is as described above.
  • The checking module is primarily used to check the accuracy and/or integrity of the data backed up by the Backup Module, after switchover from the active board to the backup board has been performed.
  • During the checking procedure, the backup board does not process multicast join and multicast leave messages sent by multicast clients during this process normally. Hence, to prevent aging of multicast client online status and the inability to go offline, after checking is completed by the checking module, the request status module in this invention sends online status query messages to multicast clients. In this way, the post switchover new active board can correctly obtain the multicast client's current status.
  • The multicast stream request module is primarily used once switchover is finished to send multicast stream request messages to the upstream router according to the multicast client online record, channel currently being watched by the multicast client, channel number, channel status, and other data. In this way, the upstream router can send the requested multicast data stream to the new active board based on the multicast stream requests it receives. The new active board following switchover provides the multicast client with a multicast service with an uninterrupted multicast stream according to the multicast client online record, channel currently being watched by the multicast client, channel number, channel status, multicast client CDR and other data. In addition, because the new active board following switchover contains a backup of the multicast user CDR, the access device main board switchover process does not cause loss of the multicast user CDR information.
  • In the above description of the access device, the specific representation of online status query request messages, multicast data stream request messages and access devices are as described in the above method.

Claims (12)

  1. A method for implementing multicast in an access device based on switchover between an active board and a standby board, said method comprising:
    maintaining a real-time communication between a standby board and an active board, and checking (120) an operating status of the active board at all times;
    characterized in that the method further comprises:
    changing (116) data in the standby board based on a change to multicast client dynamic data in the active board;
    performing (124) a switchover from the active board to the standby board based on a detected failure of the active board; and
    the new active board sending (126) a multicast data stream request message to an upstream router based on saved data.
  2. The method according to claim 1, wherein after the switchover from the active to the standby is completed,
    the new active board checks (128) accuracy and/or integrity of backup data.
  3. The method according to claim 2, wherein after the step of checking (128) accuracy and/or integrity of the backup data is completed,
    the new active board sends (130) an online status query request to a multicast client.
  4. The method according to claim 3, wherein the online status query request comprises:
    an Internet Group Management Protocol, IGMP, query message and a Multicast Listener Discovery, MLD, protocol query message.
  5. The method according to claim 1, wherein the multicast client dynamic data comprise one or more of the following: a multicast client online record, a channel currently being watched by a multicast client, a channel number, a channel status, a multicast client offline record, and a multicast client Call Detail Record, CDR.
  6. The method according to claim 5, wherein the changing data in the standby board based on a change to multicast client dynamic data in the active board includes: refreshing data on the standby board for multicast client online record, channel currently being watched by a multicast client, channel number and channel status based on a change in the online record, the channel currently being watched by the multicast client, the channel number, and the channel status on the active board; and refreshing a multicast client CDR for the standby board according to said multicast client online/offline record, and setting or deleting items in a hardware forwarding table of the standby board.
  7. The method according to any one of claims 1 to 6, wherein said access device comprises a Digital Subscriber Line Access Multiplexer, DSLAM.
  8. The method according to any one of claims 1 to 6, wherein the multicast data stream request message comprises an IGMP report message and an MLD protocol report message.
  9. An access device comprising an active board and a standby board, the access device being adapted for the standby board to maintain a real time communication with the active board, to check an operating status of the active board at all times, and to perform a switchover from the active board to the standby board based on a detected failure of the active board,
    characterized in that said access device also comprises:
    a backup module adapted to change data in the standby board based on a change to multicast client dynamic data in the active board; and
    a multicast stream request module adapted to send, after the switchover from the active to the backup is completed, a multicast data stream request message to an upstream router based on data stored on the new active board, causing the upstream router to send a multicast data stream to the new active board after the switchover.
  10. The device according to claim 9, wherein said access device also comprises a checking module adapted to check accuracy and/or integrity of the backup data in the backup module, after the switchover from the active board to the backup board is completed.
  11. The device according to claim 10, wherein said access device also comprises a status request module adapted to send an online status query request message to a multicast client after the checking module completes its checking, causing the new active board to obtain a multicast client current status after the switchover.
  12. The device according to claim 9 , wherein the backup module is comprised in the standby board or separate from the standby board.
EP06775464A 2005-09-06 2006-08-23 A multicast realizing method in access device based on main and backup board switching Not-in-force EP1821491B1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB2005100993763A CN100440799C (en) 2005-09-06 2005-09-06 Main/standby board back-up in access-in apparatus and rearranging method therefor
PCT/CN2006/002146 WO2007028315A1 (en) 2005-09-06 2006-08-23 A multicast realizing method in access device based on main and backup board switching

Publications (3)

Publication Number Publication Date
EP1821491A1 EP1821491A1 (en) 2007-08-22
EP1821491A4 EP1821491A4 (en) 2008-02-20
EP1821491B1 true EP1821491B1 (en) 2009-12-23

Family

ID=37133614

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06775464A Not-in-force EP1821491B1 (en) 2005-09-06 2006-08-23 A multicast realizing method in access device based on main and backup board switching

Country Status (7)

Country Link
US (1) US20070140155A1 (en)
EP (1) EP1821491B1 (en)
CN (2) CN100440799C (en)
AT (1) ATE453281T1 (en)
DE (1) DE602006011269D1 (en)
ES (1) ES2336703T3 (en)
WO (1) WO2007028315A1 (en)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101179366B (en) * 2006-11-06 2011-04-20 中兴通讯股份有限公司 Method of synchronizing master/slave data of digital subscriber line access multiplexer
CN101286862B (en) * 2007-04-09 2012-07-04 中兴通讯股份有限公司 Method for synchronizing and switching multicast service between main and standby in access device
US20090029714A1 (en) * 2007-07-25 2009-01-29 Rudrapatna Ashok N Method of allocating bandwidth for transmission of channel quality information
CN101488879B (en) * 2008-01-15 2013-09-11 上海贝尔阿尔卡特股份有限公司 Failure protection method and apparatus in network appliance for Ethernet spanning tree protocol
US7975166B2 (en) * 2008-03-05 2011-07-05 Alcatel Lucent System, method and computer readable medium for providing redundancy in a media delivery system
WO2010000172A1 (en) * 2008-06-30 2010-01-07 华为技术有限公司 Method, system, receiving end device and multicast source device for multicast protection
CN101677347B (en) * 2008-09-18 2012-09-05 中兴通讯股份有限公司 Method of preventing loss of phone bill due to switching of service control processor (CP)
CN101848399B (en) * 2009-03-24 2013-01-09 华为技术有限公司 Nondestructive changeover method, nondestructive changeover equipment and switching equipment
CN101510890B (en) * 2009-03-31 2012-07-04 华为技术有限公司 Method and communication equipment for holding protocol state
US8406398B2 (en) * 2009-05-15 2013-03-26 Level 3 Communications, Llc Call detail record data refinement and reporting
CN101562513B (en) * 2009-05-25 2012-02-29 中兴通讯股份有限公司 Method and device for switching main veneers and standby veneers
CN101651553B (en) * 2009-09-03 2013-02-27 华为技术有限公司 User side multicast service primary and standby protecting system, method and route devices
CN101876962B (en) * 2009-12-15 2013-04-10 龙芯中科技术有限公司 Method and device for controlling hot plug of master/slave board
CN102480479A (en) * 2010-11-30 2012-05-30 中兴通讯股份有限公司 Business processing method and system
CN103294156B (en) * 2012-02-24 2016-03-02 联想(北京)有限公司 On-line Control device, control method and digital processing device at any time
US9774386B2 (en) 2013-03-15 2017-09-26 E.F. Johnson Company Distributed simulcast architecture
CN104283795B (en) * 2014-10-11 2018-04-10 新华三技术有限公司 A kind of multicast list brush new method and apparatus
US10009422B1 (en) * 2015-09-21 2018-06-26 EMC IP Holding Company LLC Backup management based on client device statuses
CN109005679B (en) * 2017-04-07 2020-08-04 深圳市泰德创新科技有限公司 Audio synchronization system for redundant design of conference discussion system
CN107547277B (en) * 2017-08-29 2020-09-08 新华三技术有限公司 Method for realizing virtualization control board and network communication equipment
CN108234615B (en) * 2017-12-25 2021-05-07 新华三技术有限公司 Table item processing method, mainboard and main network equipment
CN111491334B (en) * 2019-01-29 2021-05-25 中兴通讯股份有限公司 Load sharing method, device, system, single board and storage medium
CN110380876B (en) * 2019-06-26 2022-02-18 视联动力信息技术股份有限公司 Group chat service implementation method, device, system, terminal, server and medium
CN111131500B (en) * 2019-12-31 2022-11-04 苏州盛科通信股份有限公司 Method and system for switching main multicast and standby multicast in two layers
CN112187578B (en) * 2020-09-28 2022-11-25 新华三信息安全技术有限公司 Table entry generation method, device and equipment
CN112615901B (en) * 2020-11-26 2022-07-12 新华三大数据技术有限公司 Method for sending user request by client and storage system

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6331983B1 (en) * 1997-05-06 2001-12-18 Enterasys Networks, Inc. Multicast switching
US5983371A (en) * 1997-07-11 1999-11-09 Marathon Technologies Corporation Active failure detection
WO2001060000A1 (en) * 2000-02-11 2001-08-16 Convergent Networks, Inc. Methods and systems for creating, distributing and executing multimedia telecommunications applications over circuit and packet switched networks
JP4365998B2 (en) * 2000-07-21 2009-11-18 株式会社日立製作所 Multicast communication method and communication apparatus
US7058010B2 (en) * 2001-03-29 2006-06-06 Lucent Technologies Inc. Controlled switchover of unicast and multicast data flows in a packet based switching system
US20050021833A1 (en) * 2001-08-29 2005-01-27 Frank Hundscheid Method and device for multicasting in a umts network
CN1264304C (en) * 2002-02-04 2006-07-12 中兴通讯股份有限公司 Real-time synchronizing method for data in both main and spare board in communication system
US6763019B2 (en) * 2002-03-05 2004-07-13 Nokia Corporation Method and system for authenticated fast channel change of media provided over a DSL connection
US6947375B2 (en) * 2003-01-27 2005-09-20 Nokia Inc. System and method for network card switchovers in an IP network
KR100534625B1 (en) * 2003-02-18 2005-12-07 삼성전자주식회사 method and apparatus for reliable routing information exchange in distributed router
JP4170929B2 (en) * 2003-03-28 2008-10-22 株式会社エヌ・ティ・ティ・ドコモ Mobile communication system, mobile terminal, and mobile communication method
US7016328B2 (en) * 2003-06-24 2006-03-21 Tropos Networks, Inc. Method for allowing a client to access a wireless system
US7929424B2 (en) * 2003-10-31 2011-04-19 Ericsson Ab Switchover for broadband subscriber sessions
US7961690B2 (en) * 2006-07-07 2011-06-14 Symbol Technologies, Inc. Wireless switch network architecture implementing mobility areas within a mobility domain

Also Published As

Publication number Publication date
US20070140155A1 (en) 2007-06-21
CN100440799C (en) 2008-12-03
ATE453281T1 (en) 2010-01-15
EP1821491A1 (en) 2007-08-22
ES2336703T3 (en) 2010-04-15
WO2007028315A1 (en) 2007-03-15
DE602006011269D1 (en) 2010-02-04
EP1821491A4 (en) 2008-02-20
CN1852144A (en) 2006-10-25
CN101160917A (en) 2008-04-09

Similar Documents

Publication Publication Date Title
EP1821491B1 (en) A multicast realizing method in access device based on main and backup board switching
US7590749B2 (en) Method and apparatus for multicast management of user interface in a network access device
US7228356B2 (en) IGMP expedited leave triggered by MAC address
US6826612B1 (en) Method and apparatus for an improved internet group management protocol
EP2521298B1 (en) Method and apparatus for ensuring quality of service of internet protocol television live broadcast service
US8145778B2 (en) Method and system for transitioning streamed digital video content between stream servers in a digital video network
US8270294B2 (en) Method and apparatus for implementing multicast service
US20140233563A1 (en) Multicast processing method and device
EP1965545B1 (en) Method for preventing the dispatch of dual multicast streams
US20090316573A1 (en) System and method for transmitting messages using a redundancy mechanism
US20070153791A1 (en) Method for rapidly recovering multicast service and network device
JP2013500651A (en) Primary and standby protection system, method and routing device for user-side multicast service
WO2011035599A1 (en) Method and inquiring device for implementing switching in network fault
CN101202705A (en) Method and router for increasing multicast reliability
CN100527680C (en) Method and device for automatically identifying multicast agent device interface types
US20070274310A1 (en) Method and system for processing abnormally becoming power off of a terminal of multicast user
EP1983713A1 (en) Method for operating a network element and according device as well as communication system comprising such device
CN114143569B (en) Webpage recording and live broadcasting method and system
KR101144408B1 (en) Network access system and method having redundancy structure
CN101286862A (en) Method for synchronizing and switching multicast service between main and standby in access device
JP3790169B2 (en) STREAM DISTRIBUTION DEVICE, METHOD AND PROGRAM, AND RECORDING MEDIUM CONTAINING STREAM DISTRIBUTION PROGRAM
CN113286101B (en) Audio and video stream switching method and device
CN117675774A (en) Streaming media data transmission method and device and electronic equipment

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

AK Designated contracting states

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 IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK YU

RIN1 Information on inventor provided before grant (corrected)

Inventor name: YU, JINNINGHUAWEI TECHNOLOGIES CO. LTD

A4 Supplementary search report drawn up and despatched

Effective date: 20080121

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/14 20060101ALI20080115BHEP

Ipc: H04L 29/06 20060101AFI20070523BHEP

Ipc: H04L 12/56 20060101ALI20080115BHEP

Ipc: H04L 12/28 20060101ALI20080115BHEP

Ipc: G06F 11/20 20060101ALI20080115BHEP

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080527

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REF Corresponds to:

Ref document number: 602006011269

Country of ref document: DE

Date of ref document: 20100204

Kind code of ref document: P

REG Reference to a national code

Ref country code: NL

Ref legal event code: T3

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 2336703

Country of ref document: ES

Kind code of ref document: T3

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

LTIE Lt: invalidation of european patent or patent extension

Effective date: 20091223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100423

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100323

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100423

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100324

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20100924

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100831

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100831

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20100823

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20100624

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091223

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 10

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 11

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 12

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20180807

Year of fee payment: 13

Ref country code: ES

Payment date: 20180905

Year of fee payment: 13

Ref country code: IT

Payment date: 20180725

Year of fee payment: 13

Ref country code: FR

Payment date: 20180712

Year of fee payment: 13

Ref country code: NL

Payment date: 20180815

Year of fee payment: 13

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20180822

Year of fee payment: 13

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602006011269

Country of ref document: DE

REG Reference to a national code

Ref country code: NL

Ref legal event code: MM

Effective date: 20190901

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20190823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190901

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190831

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20200303

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190823

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190823

REG Reference to a national code

Ref country code: ES

Ref legal event code: FD2A

Effective date: 20210108

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20190824