CN101286862B - Method for synchronizing and switching multicast service between main and standby in access device - Google Patents
Method for synchronizing and switching multicast service between main and standby in access device Download PDFInfo
- Publication number
- CN101286862B CN101286862B CN200710090523XA CN200710090523A CN101286862B CN 101286862 B CN101286862 B CN 101286862B CN 200710090523X A CN200710090523X A CN 200710090523XA CN 200710090523 A CN200710090523 A CN 200710090523A CN 101286862 B CN101286862 B CN 101286862B
- Authority
- CN
- China
- Prior art keywords
- mainboard
- message
- slave board
- multicast
- response
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 230000005540 biological transmission Effects 0.000 claims description 9
- 238000007689 inspection Methods 0.000 claims description 4
- 238000011144 upstream manufacturing Methods 0.000 abstract description 8
- 230000001360 synchronised effect Effects 0.000 description 5
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 241001269238 Data Species 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention provides a method for synchronizing and changing over multicast business in access equipment, which comprises that a main board receives a protocol message and checks the authority of the protocol message when the access equipment is running. If the protocol message fails in the authority check, the process comes to an end; if the protocol message passes the authority check, the process continues; the main board sends the protocol message to an alternative board and judges whether to carry out the synchronizing process of messages or not; if main/ alternative changeover happens in the access equipment, the alternative board sends a request for synchronizing the billing data to the main board and waits for a response from the main board; if receiving a response from the main board, the alternative board judges whether to stop the process or continue to send synchronizing request to the main board; if receiving no response after a plurality of trials, the alternative board does not change over with the main board. The method adopted by the invention guarantees the durative downward delivery of the video stream during the main/ alternative changeover of the access equipment, without affecting the video on demand of users; and no extra message is send to the upstream equipment and users in the process; the main/alternative changeover process is completely invisible to the downstream and upstream equipment.
Description
Technical field
The present invention relates to a kind of multicast service, particularly relate to multicast service in a kind of access device active and standby synchronously with the method for switching.
Background technology
Along with networks development, traditional point-to-point data transmission service can not satisfy user's demand like WWW, Telnet (TELNET), FTP business such as (file transfer protocol are hereinafter to be referred as FTP).More and more users hopes to enjoy colourful large-data operation service,, multimedia remote education live like the network teleconference, remote medical consultation with specialists, the Internet or the like.If these professional point to point links that use transmit, will cause network congestion, postpone to increase, and cause occurring network bottleneck.In order to alleviate network bottleneck, these business all need adopt the multicasting technology transmission, promptly adopt point to save bandwidth to multiple spot or multiple spot to the transmission of multiple spot, alleviate network load.
In access device,, adopt this working method of activestandby hot backup usually for reliability and the survivability that system is provided.Adopt the active and standby mechanism of master control borad, in the time of can guaranteeing that soft, hardware fault appears in a master control borad, another piece master control borad can be taken over job, and system is run well.After masterslave switchover takes place,, answer below the As soon as possible Promising Policy some for multicast service:
1. the multicast configuration data of new mainboard is consistent with former mainboard.
2. masterslave switchover does not influence upstream equipment and delivers to group broadcasting video frequency and flow to access device.
3. masterslave switchover does not influence multicast video streams and is forwarded to the user, promptly keeps in the reversed process user online all the time.
4. the user's ticket on the new mainboard is consistent with former mainboard.
5. the User Status on the new mainboard is consistent with former mainboard, like user's preview state (like the preview number of times that is left, current preview state) etc.
6. satisfying in above-mentioned 5, the resource that access device expends when normal operation and at masterslave switchover the time is as much as possible little, does not influence regular traffic as far as possible.
In sum, with the resource consumption of minimum, multicast service when reaching masterslave switchover " zero influence " is a target of considering multicast service masterslave switchover problem.
Summary of the invention
In view of this, the object of the present invention is to provide a kind of realize multicast service in the access device active and standby synchronously with the method for switching, when masterslave switchover, do not influence multicast service.
For realizing above-mentioned purpose, multicast service provided by the invention is active and standby to be may further comprise the steps with the method for switching synchronously:
Step 4, if access device generation masterslave switchover, then slave board sends for the synchronization request of call bill data and waits for that mainboard responds to mainboard, if receive response, then finishes this ticket synchronizing process or continue to send synchronization request to mainboard according to the message determining of responding; If after repeatedly attempting, do not receive response yet, then slave board is not switched with mainboard.
May further comprise the steps in the said step 3:
After step 201, above-mentioned mainboard are received effective multicast protocol message, above-mentioned multicast protocol message is sent to slave board;
Step 202 if above-mentioned slave board is received the multicast protocol message that mainboard sends, then sends it back the message of answering to mainboard;
Step 203, if after above-mentioned mainboard is received the response of slave board, this message synchronizing process finishes.
In the described step 201, the mode that the multicast protocol message is sent to slave board is the asynchronous message mode, and it also can be other any suitable manner, after the slave board that the multicast protocol message sends, timer is set; In step 203, if after above-mentioned mainboard is received the response of slave board, close this timer; If the response that mainboard is not still received slave board at timer then, and the transmission number of times of above-mentioned multicast protocol message do not reach predetermined number, then will send above-mentioned multicast protocol message once more to slave board, resets timer, changes step 202 over to; Otherwise, cancellation message synchronizing process.
In described step 201; If being multicast request, the multicast protocol message joins message; Then mainboard judges according to user right whether this multicast request joins message effective, if the user right inspection is passed through, then this multicast request joins message effectively; If user right inspection is not passed through, then this multicast request join message invalid.
May further comprise the steps in the said step 4:
Step 301, if access device generation masterslave switchover, slave board is received the mainboard switching messages;
Step 302, slave board sends the synchronization request for call bill data to mainboard;
After step 303, mainboard are received above-mentioned synchronization request, the call bill data in a district is sent to slave board as the message of responding;
Step 304 if slave board is received the message of response, then finishes or continues according to the message determining of responding to send synchronization request to mainboard.
After said step 302, slave board starts timer; In said step 304, slave board is received the back timeing closing device of receiveing the response, if the timer of slave board then, does not still receive the message of the response of mainboard, and the transmission number of times of above-mentioned synchronization request do not reach predetermined number, then changes step 302 over to; If after repeatedly attempting, do not receive response yet, then slave board is not switched with mainboard.
In said step 304,, otherwise continue to send the synchronization request of next district's call bill data to mainboard if the end that the message of above-mentioned response has finished for all call bill data districts have sent sign then finishes whole ticket synchronizing process.
The present invention adopt multicast service in a kind of access device active and standby synchronously with the method for switching, guarantee that video flowing continues to issue when not only making the access device masterslave switchover, do not influence user's video request program; The multicast configuration data of new mainboard is consistent with former mainboard; User's ticket on the new mainboard is consistent with former mainboard with User Status; And in this process, do not have extra message to be sent to upstream equipment and user, whole masterslave switchover process is invisible to upstream equipment and upstream device fully.
Description of drawings
Fig. 1 is the structural representation of the active and standby environment of multicast service access device.
Fig. 2 is dialogue mechanism and the overtime retransmission mechanism sketch map that the multicast protocol message sends in the present invention's one preferred embodiment.
Fig. 3 is dialogue mechanism and the overtime retransmission mechanism sketch map that call bill data is switched in the present invention's one preferred embodiment.
Fig. 4 is the synchronous flow chart of protocol massages during the access device operate as normal in the present invention's one preferred embodiment.
Fig. 5 is the multicast service process chart during access device masterslave switchover in the present invention's one preferred embodiment.
Embodiment
Below in conjunction with accompanying drawing and specific embodiment the present invention is done to introduce further, but not as to qualification of the present invention.
Fig. 1 is the sketch map of the active and standby environment of multicast service access device of the present invention; As shown in Figure 1; Access device 17 connects user 16; And the port one 8 through mainboard 14 is connected multicast router 13 with the port one 9 of slave board 15, and multicast router 13 passes through the multicast data flow of network 12 receptions from multicast source server 11.When user's 16 certain group broadcasting program of request; Can send based on IGMP (Internet Group Management Protocol; Hereinafter to be referred as IGMP) the message that adds of request give access device 17; 17 couples of these users' 16 of access device authority is judged, after affirmation can insert, user 16 is added in the reception tabulation of this multicast group.After the multicast data flow from multicast source server 11 arrived access device 17, access device 17 just can copy to user 16 and other users that file a request according to the reception tabulation of this multicast group.Similar; When user 16 stops to receive certain multicast service; Just can send the message of leaving based on the request of IGMP and give access device 17, access device 17 can send a certain number of group-specific query message to user 16 at certain intervals, if user 16 does not reply in the response time; Then with user 16 deletion from the reception tabulation of this multicast group, access device 17 no longer duplicates multicast data flow to user 16.Though the port one 9 of slave board 15 is connecting multicast router 13, it is in the disable state, so multicast data flow can not arrive slave board 15.
When masterslave switchover took place, the port one 8 of former mainboard 14 transferred the disable state to, new mainboard, and the port one 9 of promptly former slave board 15 transfers enabled to, and multicast data flow arrives new mainboard 15, makes that multicast service can continue to issue.
When describing the access device operate as normal of the present invention's one preferred embodiment in conjunction with Fig. 2 and Fig. 4, the handling process of multicast protocol message.When the multicast protocol message is a multicast request when joining message, step 41, mainboard 14 receives that the request that user 16 sends joins message.Step 42,14 couples of these users 16 of mainboard carry out scope check, if through scope check, forward step 43 to; If do not pass through, then abandon this request and join message.Step 43, this request joined message is dealt into slave board 15, and mainboard 14 gets into steps 44 then.Step 44; With the multicast handling process that this request joins message and sends into mainboard 14, at this moment, mainboard 14 adds user 16 in the reception tabulation of this multicast group; Access device copies to each user according to the reception tabulation of this multicast group, and this user 16 just can receive multicast data flow.Almost carry out step 45 simultaneously, slave board 15 receives request and joins message.Step 46; The multicast handling process that request on the slave board 15 joins message and also gets into slave board 15; Slave board 15 also adds user 16 in the reception tabulation of this multicast group; Slave board 15 copies to each user according to the reception tabulation of this multicast group, but because the port one 9 of slave board 15 is in the disable state, so multicast data flow can not arrive slave board 15.The above function of slave board 15 can be accomplished by the exchange chip on the slave board 15, also can be accomplished by other suitable any chips.
When the multicast protocol message is the multicast request leave message, at first carry out step 41, mainboard 14 is received the multicast request leave message that user 16 sends.Carry out step 43 then, mainboard 14 should ask leave message to be sent to slave board 15; Step 44, after this request leave message sends to mainboard 14, the multicast handling process that just gets into mainboard 14.Simultaneously, mainboard 14 is with user 16 deletion from the reception tabulation of this multicast group, and access device is to tabulate according to the reception of this multicast group to copy to each user, and user 16 just no longer receives this multicast data flow.Almost simultaneously; Carry out step 45, slave board 15 receives the request leave message that mainboard 14 sends, and carry out step 46 then; Request leave message on the slave board 15 also gets into the multicast message handling process of slave board 15, and slave board 15 is also with user 16 deletion from the reception tabulation of this multicast group.
Above-mentioned multicast request joins message and the multicast request leave message all belongs to the multicast protocol message; Because the multicast protocol message almost gets into the multicast message handling process of mainboard 14 and slave board 15 simultaneously respectively; Therefore the state of mainboard 15 and slave board 15 port 18,19 is just the same, comprises that state in this channel place multicast group of channel that the user receiving, user, user are to preview state of channel or the like.
When mainboard 14 is synchronized to slave board 15 with the multicast protocol message, can arrive slave board 15 reliably in order to guarantee the multicast protocol message, adopted acknowledgement messaging and failure retransmission mechanism to guarantee the transmission of multicast protocol message.Simultaneously adopt asynchronous message to send and reply to the taking of motherboard resources in order to reduce as far as possible.After mainboard 14 is received effective multicast protocol message, through asynchronous message the multicast protocol message is sent to slave board 15, i.e. Pkt send=1; And start a timer; Be Time out=0, and to write down this multicast protocol message be which sends number of times, i.e. g_pkt=1; After slave board is received the message that mainboard 14 sends over, send out the mainboard 14 of receiveing the response, i.e. a Pkt ack=1; If mainboard 14 receive is receiveed the response, timeing closing device then, and the message synchronizing process finishes.If the timer of mainboard 14 is then, still do not receive receiveing the response of slave board 15, then need reset timer, the multicast protocol message is sent certain number of times once more; For example, send the multicast protocol message to slave board Pkt send=2, g_pkt=2; Start a timer, i.e. Time out=0, but failure; Then retransmit Pkt send=2, triplicate is until Time out=3; In this process as receive the Pktack=2 of receiveing the response of slave board 15, just prove that slave board 15 received protocol massages, mainboard 14 changes protocol massages over to the multicast handling process of oneself at once.This process can repeat repeatedly until Pkt send=n, Pkt ack=n.
In conjunction with Fig. 3 and Fig. 5, in the time of can obtaining the access device masterslave switchover of the present invention's one preferred embodiment to the handling process of multicast service.Step 51, when masterslave switchover took place, slave board 15 can be received the masterslave switchover message that system sends.Step 52, slave board 15 be to mainboard 14 transmit telephone bill synchronization of data requests, Cdr req=1, and open a timer, Time out=0 is such as being set to 1 second or any suitable time.Step 53, mainboard 14 is received the synchronization request of the call bill data of slave board 15.Step 54, mainboard 14 sends to slave board 15, Cdrack=1 with the call bill data in a district as receiveing the response.If step 56, slave board 15 receive are receiveed the response, timeing closing device then, and request ticket process this time finishes.Another kind of situation, if the timer expiry of slave board 15, Cdr req=2; TimeOut=0 does not still receive receiveing the response of mainboard 14, then resets timer; The request synchronization message is sent certain number of times once more; As fail and retransmit three times, in this process as receive receiveing the response of mainboard 14, then this time request ticket process successfully finishes.Simultaneously, slave board 15 needs to judge whether this is receiveed the response is that all call bill data districts have sent the end sign that finishes, if then whole ticket synchronizing process finishes, and Cdr end, otherwise the synchronization request of the call bill data in next district is sent in continuation to mainboard 14.
The active and standby synchronous and reverse treatment method of multicast service of the present invention can keep other data except that the ticket that does not send of mainboard 14 and slave board 15 in full accord in the access device normal operating conditions.The chip multicast setting of slave board 15 is also in full accord with mainboard 14.Like this, in the generation masterslave switchover, as long as group business stream one is transformed on the slave board 15, just can be forwarded to the user at once, be the influence of the complete imperceptible masterslave switchover of user.Simultaneously, because all User Status are in full accord on mainboard 14 and the slave board 15, so do not need upstream device and the extra transmission request of upstream device to join message and query message in the masterslave switchover.Processing for ticket; Because generally in normal operation; Call bill data (such as 5 minutes) at set intervals will report network management system after perhaps reaching some (such as 90); Therefore need synchronous call bill data generally speaking all seldom (less than 90) in the masterslave switchover, a synchronous data field is just passable.Even because some special circumstances, be connected with network management system such as access device and fault to have occurred, accumulated many call bill datas on the mainboard, through processing, affirmation mechanism and the retransmission mechanism of packing, also can guarantee not losing of user's ticket.So processing method provided by the invention can be with less resource consumption, multicast service when reaching masterslave switchover " zero influence ".
The above is merely preferred embodiment of the present invention, is not to be used for limiting practical range of the present invention; If do not break away from the spirit and scope of the present invention, the present invention is made amendment or is equal to replacement, all should be encompassed in the middle of the protection range of claim of the present invention.
Claims (7)
- In the access device multicast service active and standby synchronously with the method for switching, it is characterized in that, may further comprise the steps:Step 1, during the access device operation, mainboard receives protocol massages, and it is carried out scope check;Step 2, if the scope check failure, this process finishes; If scope check passes through, change step 3 over to;Step 3, mainboard sends to slave board with above-mentioned protocol massages and judges whether to carry out the message synchronizing process;Step 4, if access device generation masterslave switchover, then slave board sends for the synchronization request of call bill data and waits for that mainboard responds to mainboard, if receive response, then finishes this ticket synchronizing process or continue to send synchronization request to mainboard according to the message determining of responding; If after repeatedly attempting, do not receive response yet, then slave board is not switched with mainboard.
- 2. method according to claim 1 is characterized in that, may further comprise the steps in the said step 3:After step 201, above-mentioned mainboard are received effective multicast protocol message, above-mentioned multicast protocol message is sent to slave board;Step 202 if above-mentioned slave board is received the multicast protocol message that mainboard sends, then sends it back the message of answering to mainboard;Step 203, if after above-mentioned mainboard is received the response of slave board, this message synchronizing process finishes.
- 3. method according to claim 2 is characterized in that, in the said step 201, the mode that the multicast protocol message is sent to slave board is the asynchronous message mode, after the multicast protocol message sends to slave board, timer is set; In the said step 203,, then close this timer if above-mentioned mainboard is received the response of slave board; If the response that mainboard is not still received slave board at timer then, and the transmission number of times of above-mentioned multicast protocol message do not reach predetermined number, then will send above-mentioned multicast protocol message once more to slave board, resets timer, changes step 202 over to; Otherwise, cancellation message synchronizing process.
- 4. method according to claim 2; It is characterized in that; If the protocol massages that mainboard receives in the step 1 is the multicast protocol message; And said multicast protocol message is that multicast request joins message, and then mainboard carries out scope check to it and is specially: mainboard judges according to user right whether effective this multicast request joins message;In the step 2, if the user right inspection is passed through, then this multicast request joins message effectively, changes step 201 over to; If user right inspection is not passed through, then this multicast request joins message invalidly, and this process finishes.
- 5. method according to claim 1 and 2 is characterized in that may further comprise the steps in the said step 4:Step 301, if access device generation masterslave switchover, slave board is received the mainboard switching messages;Step 302, slave board sends the synchronization request for call bill data to mainboard;After step 303, mainboard are received above-mentioned synchronization request, the call bill data in a district is sent to slave board as the message of responding;Step 304 if slave board is received the message of response, then finishes or continues according to the message determining of responding to send synchronization request to mainboard.
- 6. method according to claim 5 is characterized in that, after said step 302, slave board starts timer; In said step 304, slave board is received the back timeing closing device of receiveing the response, if the timer of slave board then, does not still receive the message of the response of mainboard, and the transmission number of times of above-mentioned synchronization request do not reach predetermined number, then changes step 302 over to; If after repeatedly attempting, do not receive response yet, then slave board is not switched with mainboard.
- 7. method according to claim 5; It is characterized in that, in said step 304, if the end that the message of above-mentioned response has finished for all call bill data districts have sent sign; Then finish whole ticket synchronizing process, otherwise continue to send the synchronization request of the call bill data in next district to mainboard.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710090523XA CN101286862B (en) | 2007-04-09 | 2007-04-09 | Method for synchronizing and switching multicast service between main and standby in access device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200710090523XA CN101286862B (en) | 2007-04-09 | 2007-04-09 | Method for synchronizing and switching multicast service between main and standby in access device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101286862A CN101286862A (en) | 2008-10-15 |
| CN101286862B true CN101286862B (en) | 2012-07-04 |
Family
ID=40058844
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200710090523XA Expired - Fee Related CN101286862B (en) | 2007-04-09 | 2007-04-09 | Method for synchronizing and switching multicast service between main and standby in access device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101286862B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102196397B (en) * | 2010-03-18 | 2015-06-03 | 中兴通讯股份有限公司 | Method and system for improving bill record construction integrity and charging data function |
| CN108234358B (en) * | 2017-12-29 | 2021-09-21 | 新华三技术有限公司 | Multicast message transmission method, device and machine readable storage medium |
| CN111131500B (en) * | 2019-12-31 | 2022-11-04 | 苏州盛科通信股份有限公司 | Method and system for switching main multicast and standby multicast in two layers |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1437348A (en) * | 2002-02-04 | 2003-08-20 | 深圳市中兴通讯股份有限公司 | Real-time synchronizing method for data in both main and spare board in communication system |
| CN1499802A (en) * | 2002-11-11 | 2004-05-26 | ��Ϊ��������˾ | Method for realizing reliable transfering transaction by using mechanism of state machine |
| EP1708379A1 (en) * | 2004-02-25 | 2006-10-04 | Huawei Technologies Co., Ltd. | Communication system having backup function for several series devices and method for carrying out the function of switching |
| CN1852144A (en) * | 2005-09-06 | 2006-10-25 | 华为技术有限公司 | Main/standby board back-up in access-in apparatus and rearranging method therefor |
| CN1852246A (en) * | 2005-11-25 | 2006-10-25 | 华为技术有限公司 | Method for multi-cast broadcasting flow distribution node to receive multi-cast broadcasting flow |
-
2007
- 2007-04-09 CN CN200710090523XA patent/CN101286862B/en not_active Expired - Fee Related
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1437348A (en) * | 2002-02-04 | 2003-08-20 | 深圳市中兴通讯股份有限公司 | Real-time synchronizing method for data in both main and spare board in communication system |
| CN1499802A (en) * | 2002-11-11 | 2004-05-26 | ��Ϊ��������˾ | Method for realizing reliable transfering transaction by using mechanism of state machine |
| EP1708379A1 (en) * | 2004-02-25 | 2006-10-04 | Huawei Technologies Co., Ltd. | Communication system having backup function for several series devices and method for carrying out the function of switching |
| CN1852144A (en) * | 2005-09-06 | 2006-10-25 | 华为技术有限公司 | Main/standby board back-up in access-in apparatus and rearranging method therefor |
| CN1852246A (en) * | 2005-11-25 | 2006-10-25 | 华为技术有限公司 | Method for multi-cast broadcasting flow distribution node to receive multi-cast broadcasting flow |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101286862A (en) | 2008-10-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101420362B (en) | Method, system and router for multicast flow switching | |
| ES2336703T3 (en) | A METHOD OF CARRYING OUT MULTIDIFUSION IN AN ACCESS DEVICE BASED ON A SWITCH OF MAIN BOARD AND SAFEGUARD PLATE. | |
| KR100248080B1 (en) | Method of error control for multiparty multimedia communications | |
| EP1334586B1 (en) | Subgroup multicasting in a communications network | |
| US7719959B2 (en) | Achieving super-fast convergence of downstream multicast traffic when forwarding connectivity changes between access and distribution switches | |
| CN101192964B (en) | Master/slave switching system and method for multicast source | |
| CN101136730A (en) | Credible synchronization method of distributed network equipment | |
| US20090316573A1 (en) | System and method for transmitting messages using a redundancy mechanism | |
| McCanne | Scalable multimedia communication using IP multicast and lightweight sessions | |
| CN102075343A (en) | An out-of-band management realization method, a system for the same and an out-of-band management switch | |
| CN101964719B (en) | Based on the data processing method of master control board switching, line card and master control borad | |
| Sabata et al. | Transport protocol for reliable multicast: TRM | |
| CN101286862B (en) | Method for synchronizing and switching multicast service between main and standby in access device | |
| CN102347906B (en) | Multi-cast method and multi-cast network system | |
| CN101873260B (en) | Multicast streaming forwarding method and routing equipment | |
| CN101247541B (en) | Method for implementing multimedia multicast service of mobile communications network | |
| EP2571201A1 (en) | Method, device and system for forwarding data under protocol independent multicast (pim) dual join | |
| CN113973020A (en) | Method, device and system for sending multicast message | |
| CN100421410C (en) | Method for realizing mobile communication network multimedia enhancement service | |
| Berket | The intergroup protocols: Scalable group communication for the internet | |
| CN100499583C (en) | Method for realizing simplified IGMP multicast surrogate | |
| KR20080009858A (en) | Multicasting system and network device for agency transmission of data, and method for agency transmission of data thereof | |
| CN100542142C (en) | Change the method and apparatus of three-layer network appliance Interface status | |
| CN110716827B (en) | Hot backup method suitable for distributed system and distributed system | |
| Huang et al. | Group leader election under link-state routing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20171207 Address after: 15 No. 532200 the Guangxi Zhuang Autonomous Region Jiangzhou District of Chongzuo City Stone Forest Avenue Patentee after: Pan Rongqiong Address before: 510640 Guangdong City, Tianhe District Province, No. five, road, public education building, unit 371-1, unit 2401 Patentee before: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. Effective date of registration: 20171207 Address after: 510640 Guangdong City, Tianhe District Province, No. five, road, public education building, unit 371-1, unit 2401 Patentee after: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. Address before: 518057 Nanshan District high tech Industrial Park, Guangdong, South Road, science and technology, ZTE building, legal department Patentee before: ZTE Corp. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20181026 Address after: 510640 2414-2416 of the main building 371, five mountain road, Tianhe District, Guangzhou, Guangdong. Patentee after: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. Address before: 532200 15, Shilin Avenue, Chongzuo, the Guangxi Zhuang Autonomous Region Patentee before: Pan Rongqiong |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20181218 Address after: 221351 Industrial Park, Zhuang Town, Pizhou City, Xuzhou, Jiangsu Patentee after: XUZHOU POWER THAI STEEL STRUCTURE Co.,Ltd. Address before: 510640 2414-2416 of the main building 371, five mountain road, Tianhe District, Guangzhou, Guangdong. Patentee before: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd. |
|
| CF01 | Termination of patent right due to non-payment of annual fee | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120704 Termination date: 20180409 |