A method of broadcasting data from a multicast source (S) to a plurality of receivers (CL) in a telecommunications network (1) in accordance with a broadcasting strategy, including: a step (E40) of receiving parameters (STAT, AG, CS); a step (E50) of adjusting said strategy as a function of said parameters; and in the event of modification of said strategy, a step (E70) of broadcasting in a multicast signaling channel, an identifier of this new broadcasting strategy.
|
12. A source of data broadcast to a plurality of receivers in a telecommunications network,
the source comprising:
means for broadcasting data and an identifier, the data being broadcast in accordance with a first broadcasting strategy identified by the identifier;
means for receiving, from a supervisor, parameters relating to the data broadcasting;
means for adjusting said first broadcasting strategy as a function of said parameters to obtain a new broadcasting strategy; and
means for broadcasting, in a multicast signaling channel, an identifier of the new broadcasting strategy, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
1. A method of broadcasting data from a multicast source to a plurality of receivers in a telecommunications network, wherein said source performs a process comprising:
broadcasting data and an identifier, the data being broadcast in accordance with a first broadcasting strategy identified by the identifier;
receiving, from a supervisor, parameters relating to the broadcasting of data by the source;
adjusting said first broadcasting strategy as a function of said parameters to obtain a new broadcasting strategy; and
broadcasting in a multicast signaling channel, an identifier of the new broadcasting strategy, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
15. A source of data broadcast to a plurality of receivers in a telecommunications network, said source comprising:
a component configured to broadcast data and an identifier, the data being broadcast in accordance with a first broadcasting strategy identified by the identifier;
a component configured to receive, from a supervisor, parameters relating to the data broadcasting;
a component configured to adjust said first broadcasting strategy as a function of said parameters to obtain a new broadcasting strategy; and
a component configured to broadcast, in a multicast signaling channel, an identifier of the new broadcasting strategy, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
14. A receiver of at least one data stream broadcast by at least one multicast source in a first telecommunications network in accordance with a broadcasting strategy, said receiver comprising:
means for receiving, by means of a multicast signaling channel, data and an identifier, the data being broadcast by the at least one source in accordance with a first broadcasting strategy identified by the identifier;
means for sending, to a broadcast supervisor of said network, statistics concerning the reception, by the receiver, of fragments of data of said stream;
means for detecting, in the multicast signaling channel broadcast by the source of said data, an identifier of a new broadcasting strategy used by said source;
means for obtaining the new broadcasting strategy; and
means for implementing the new strategy for receiving said data, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
9. A method of receiving at least one data stream broadcast by at least one multicast source in a first telecommunications network in accordance with a broadcasting strategy, wherein at least one receiver performs a process comprising:
receiving, by means of a multicast signaling channel, data and an identifier, the data being broadcast by the at least one source in accordance with a first broadcasting strategy identified by the identifier;
sending, to a broadcast supervisor of said network, statistics concerning the reception, by said receiver, of fragments of said data broadcast by the source in accordance with said strategy;
detecting, in the multicast signaling channel broadcast by the source of said data, an identifier of a new broadcasting strategy used by said source;
obtaining the new broadcasting strategy; and
using the new strategy for receiving said data, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
4. A method of supervising the broadcasting of data sent by a multicast source to a plurality of receivers in a telecommunications network in accordance with a broadcasting strategy, wherein a supervisor performs a process comprising:
sending, to at least one of said receivers, information relating to the source, said information including an identification of a multicast signaling channel associated with the source intended to broadcast an identifier of said strategy;
obtaining, from the receiver, statistics concerning the reception, by said receiver, of fragments of said data broadcast by the source in accordance with said strategy;
obtaining, from the obtained statistics, parameters including:
an aggregate data item including receiving bit rates expected by a plurality of said receivers; or
characteristics of a new strategy, defined by the supervisor, for broadcasting said data; and
sending said parameters to said source, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
17. A receiver of at least one data stream broadcast by at least one multicast source in a first telecommunications network in accordance with a broadcasting strategy, said receiver comprising:
a component configured to receive, by means of a multicast signaling channel, data and an identifier, the data being broadcast by the at least one source in accordance with a first broadcasting strategy identified by the identifier,
a component configured to send, to a broadcast supervisor of said network, statistics concerning the reception, by said receiver, of fragments of said data broadcast by the source in accordance with said strategy;
a component configured to detect, in the multicast signaling channel broadcast by a source of said data, an identifier of a new broadcasting strategy used by said source;
a component configured to obtain the new broadcasting strategy, and
a component configured to implement the new strategy for receiving said data, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
13. A supervisor of the broadcasting of data sent by a multicast source to a plurality of receivers in a telecommunications network in accordance with a broadcasting strategy, said supervisor comprising:
means for sending, to at least one of said receivers, information relating to the source, said information including an identification of a multicast signaling channel associated with the source intended to broadcast an identifier of said strategy;
means for obtaining, from at least one of said receivers, statistics concerning the reception, by said receiver, of fragments of said data broadcast by the source in accordance with said strategy;
means for obtaining, from the obtained statistics, parameters including:
an aggregate data item including receiving bit rates expected by a plurality of said receivers; or
characteristics of a new strategy, defined by the supervisor, for broadcasting said data; and
means for sending said parameters to said source, wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
16. A supervisor of the broadcasting of data sent by a multicast source to a plurality of receivers in a telecommunications network in accordance with a broadcasting strategy, said supervisor comprising:
a component configured to send, to at least one of said receivers, information relating to the source, said information including an identification of a multicast signaling channel associated with the source intended to broadcast an identifier of said strategy;
a component configured to obtaining, from at least one of said receivers, statistics concerning the reception, by said receiver, of fragments of said data broadcast by the source in accordance with said strategy;
a component configured to obtain, from the obtained statistics, parameters including:
an aggregate data item including receiving bit rates expected by a plurality of said receivers; or
characteristics of a new strategy, defined by the supervisor, for broadcasting said data; and
a component configured to send said parameters to said source wherein each of the first strategy and the new strategy take into account factors comprising the number of streams used by a source and the characteristics of each of those streams.
2. The broadcasting method according to
statistics on reception of fragments of said data by at least one of said receivers;
a receiving bit rate expected by at least one of said receivers;
a maximum number of streams that said network is able to support;
an aggregate data item including receiving bit rates expected by a plurality of said receivers; and
characteristics of said new broadcasting strategy defined by the supervisor.
3. A computer program including instructions for executing the data broadcasting method according to
5. The supervision method according to
obtaining the maximum number of streams broadcast simultaneously in said network; and
sending that number to said source.
6. The supervision method according to
sending a request to a router of said network for it to monitor the subscription of the receivers broadcast connected to that router to the multicast streams broadcast in said network.
7. A computer program including instructions for executing the data receiving method according to
8. A computer program including instructions for executing the supervision method according to
10. The receiving method according to
11. The receiving method according to
at least one rate of loss of said data on said at least one stream is evaluated; and
at least one of said streams is unsubscribed from if said loss rate exceeds a predetermined threshold.
|
|||||||||||||||||||||||||||
This is a U.S. National Phase Application under 35 USC §371 of International Application PCT/FR2009/051776, filed on Sep. 22, 2009.
This application claims the priority of French application Ser. No. 08/56562 filed on Sep. 30, 2008, the content of which is hereby incorporated by reference.
The field of the present invention is that of telecommunications networks known as “multibroadcast” networks in which a source is able to broadcast data to a plurality of destinations.
In such networks, routers construct a replication tree between the source and the destinations with the result that a data packet passes only once over each link of the network and is replicated by the routers to reach each of the destinations.
This kind of broadcasting technique is known as a “multicast” technique.
Using such a replication tree allows massive broadcasting of information with maximum optimization of the network resources.
In contrast, multicast broadcast networks are known to be inherently unreliable because the data is transported under the UDP protocol, i.e. in non-connected mode.
The document “P2P Multicast Library” available at http://pml.sourceforge.net/Technology/ proposes a method of making a multicast network reliable in which destinations of a broadcast stream are able to recover fragments of the stream that they have not received from peers of a peer-to-peer network.
In that method, a source of the peer-to-peer network sends the various destinations a message including the characteristics of a strategy for broadcasting of the data by that source.
That method has a major drawback in that it is necessary, as is usual in peer-to-peer networks, for the source to know the destinations to which it must send these strategy characteristics.
Furthermore, a method of that kind requires that the sending of the strategy characteristics be secure, for example through the use of an error correction code mechanism or a specific protocol by means of which the destinations may request resending of the strategy characteristics, either of which solutions is liable to cause great congestion in the network if the number of destinations or the frequency of changes of strategy by the source increases.
One aspect of the invention is directed to a method of broadcasting data from a multicast source to a plurality of receivers in a telecommunications network in accordance with a broadcasting strategy.
This method includes:
Another aspect of the invention is directed to a source of data broadcast to a plurality of receivers in a telecommunications network according to a broadcasting strategy, this source including:
Generally speaking, the invention provides for adjusting the strategy for broadcasting of data by the sources as a function of parameters fed back to the sources.
In the present document, the strategy for broadcasting of data by a source is defined by the number of streams used by that source and the characteristics of each of those streams.
According to an embodiment of the invention, after each strategy modification, the source broadcasts an identifier of the new strategy on a multicast signaling channel in order to inform the receivers of it.
By means of this feature, it is not necessary for the source to know the destination of the change of strategy information.
Moreover, sending a strategy identifier rather than the characteristics of the strategy itself has the advantage of avoiding the provision of a specific security mechanism making the destinations responsible for recovering the strategy themselves in unicast messages that are inherently secure.
According to an embodiment of the invention, the parameters fed back to the sources may be of different kinds.
For example, it may be a question of statistics on the reception of fragments of the data by one or more receivers, which statistics may relate to the number of fragments received or to the number of fragments not received.
It may also be a question of the bit rates at which one or more receivers expect to receive.
It may further be a question of an aggregate data item (for example an average) comprising bit rates at which a plurality of receivers expect to receive.
In the above three situations, the source itself defines its new strategy on the basis of the received parameters and implements it after broadcasting an identifier of the new strategy in the multicast signaling channel.
According to an embodiment of the invention, the parameters fed back to the source may also be characteristics of the new strategy. In this situation, the source does not define the new strategy itself, but applies that which is imposed on it.
Another aspect of the invention is directed to a method of supervising the broadcasting of data sent by a multicast source to a plurality of receivers in a telecommunications network in accordance with a broadcasting strategy.
This method includes:
Another aspect of the invention is directed to a supervisor of the broadcasting of data sent by a multicast source to a plurality of receivers in a telecommunications network in accordance with a broadcasting strategy, the supervisor including:
According to an embodiment of the invention, a supervisor is introduced that is responsible for collecting from a plurality of receivers statistics on the reception of fragments of data and for defining, on the basis of those statistics, the parameters to be fed back to a source.
Those parameters include an aggregate data item representing bit rates at which a plurality of receivers expect to receive, the source being responsible for defining its broadcasting strategy on the basis of this aggregate data item or characteristics of the new strategy defined by the supervisor and imposed on the source.
In one particular implementation of the invention, the supervision method includes:
This feature advantageously limits the number of multicast streams broadcast simultaneously in the network.
On reception of such information, a broadcast source is able to modify its strategy to limit the number of streams that it sends so as to guarantee that the total number of multicast streams broadcast in the network does not exceed this maximum number.
In one particular implementation of the invention, the supervision method includes:
Another aspect of the invention is directed to a method of receiving at least one data stream broadcast by at least one multicast source in a telecommunications network in accordance with a broadcasting strategy, the method including:
Another aspect of the invention is directed to a receiver of at least one data stream broadcast by at least one multicast source in a telecommunications network in accordance with a broadcasting strategy, this receiver including:
In one particular implementation, this method includes a step of sending statistics on the reception of stream fragments to a broadcast supervisor of the invention.
In one particular embodiment of the invention, the receiver also sends the above-mentioned entity an ideal receiving bit rate required by the receiver.
In one particular embodiment of the invention, the receiver obtains at least one data fragment from a peer of a peer-to-peer network.
In one particular embodiment of the invention, to define the new strategy for receiving said data:
The particular features and advantages of the data source, the supervisor, and the receiver of the invention are similar to those of the data broadcasting method, the supervision method, and the receiving method referred to above.
In one particular implementation, the various steps of the broadcasting, supervision, and receiving methods are determined by instructions of computer programs.
Other aspects of the invention include:
These programs may use any programming language and take the form of source code, object code or a code intermediate between source code and object code, such as a partially-compiled form, or any other desirable form.
Another aspect of the invention is directed to a storage medium readable by a computer and including instructions of a computer program for executing the steps of the broadcasting method referred to above.
Another aspect of the invention is directed to a storage medium readable by a computer and including instructions of a computer program for executing the steps of the supervision method referred to above.
Another aspect of the invention is directed to a storage medium readable by a computer and including instructions of a computer program for executing the steps of the receiving method referred to above.
Each of the above information media may be any entity or device capable of storing the program. For example, the medium may include storage means, such as a read-only memory (ROM), for example a compact disk (CD) ROM or a micro-electronic circuit ROM, or magnetic storage means, for example a floppy disk or a hard disk.
Moreover, each of these information media may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio or by other means. The program of the invention may in particular be downloaded over an Internet-type network.
Alternatively, each of these information media may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute the method in question or to be used in its execution.
Other features and advantages of the present invention emerge from the description given below with reference to the appended drawings, which show one non-limiting embodiment of the invention. In the figures:
The content CONT is generally stored in a file. If a multicast source S or a customer receiver CL has a limit on the size of files that it can manipulate, this file may be divided into a plurality of blocks in order to be able to broadcast it. Otherwise, the content CONT consists of only one block.
In the embodiment described here, a customer receiver CL is required to be able to verify the integrity of received data and each block is divided into one or more fragments, the size of a fragment being defined as a function of the mechanism used to verify its integrity.
At the most atomic level, each fragment is divided into segments. A segment may be encapsulated in a UDP packet to be broadcast in the network 1 by a multicast source S.
According to the invention, broadcasting a data content CONT may involve one or more multicast sources S, each source using one or more multicast streams.
The number of streams used by a multicast source S and the characteristics of each of those streams define the multibroadcasting strategy of the source S. Each strategy has a sequence number SEQ that uniquely identifies it.
In this example, a multicast supervisor SUP_MC informs the customer receivers CL of the multicast sources S and the streams broadcast by those sources. To this end, in the embodiment described here, the multicast supervisor SUP_MC includes a list LS of the multicast sources S and the streams FL broadcast by those sources.
In the embodiment described here, a multicast source S has the hardware architecture of a conventional computer, as represented in
This kind of multicast source S includes a processor 11, a random-access memory (RAM) 12, and a read-only memory (ROM) 13. This read-only memory 13 constitutes a storage medium of the invention, readable by the multicast source S, in which is stored a computer program of the invention, that program including instructions for executing the steps of a broadcasting method of the invention, the principal steps E10 to E70 of that method being represented in
The multicast source S includes means for registering with the multicast server SUP_MC.
According to the invention, the multicast source S may vary its broadcasting strategy while broadcasting a data content D.
In the embodiment described here, the multicast source S includes a rewritable non-volatile flash memory 15 in which it stores the elements ELT defining its current multibroadcasting strategy.
The multicast source S also includes means 14 for communicating via the network 1, enabling it in particular to receive data sent by the multicast supervisor SUP_MC and to broadcast over the network:
According to the invention, when a multicast source S changes strategy, it modifies the sequence number SEQ sent in the heartbeat multicast signaling channel to advise the customer receivers CL of the change.
According to the invention, a multicast source S informs the multicast supervisor SUP_MC of any change of strategy by sending it the updated elements ELT, these including the adjusted characteristics INF_FL of each of the streams sent by that source S and the characteristics CHB of its heartbeat signaling stream.
In the embodiment described here, the customer receivers CL also have the hardware architecture of a conventional computer, as represented in
This kind of customer receiver CL includes a processor 21, a random-access memory (RAM) 22, and a read-only memory (ROM) 23. This read-only memory 23 constitutes a storage medium of the invention, readable by the customer receiver CL, on which is stored a computer program of the invention including instructions for executing the steps of a receiving method of the invention, the principal steps G10 to G80 of that method being represented in
The customer receiver CL also includes means 24 for sending data to the multicast supervisor SUP_MC or for consulting it obtain a list of the multicast sources S and the characteristics ELT of the streams FL broadcast by those sources. In the embodiment described here, the communications means 24 use the HTTP protocol and the requests to the multicast supervisor SUP_MC are HTTP GET messages.
The customer receiver CL includes means 25 for implementing the IGMP multicast access protocol, these means enabling this customer to subscribe to the traffic sent by a multicast source S so as to receive the heartbeat signaling multicast stream and the content stream or streams broadcast by that source S. These means are known to the person skilled in the art and are not described in detail here.
According to the invention, the customer receiver CL is able to detect a change of sequence number SEQ in the heartbeat multicast signaling stream and to interpret such a change as representing a change of broadcasting strategy by the multicast source S sending that stream. Following such detection, the customer receiver CL of the invention is able to consult the multicast supervisor MC to obtain the elements ELT of the new strategy.
In the embodiment described here at least some customer receivers CL are peers of a peer-to-peer network 2.
These receivers CL use communications means 26 to communicate with each other over the peer-to-peer network to exchange fragments of the content CONT that they have received either directly from other peers (in unicast mode) or as multibroadcast by one or more multicast sources S. They are also able to verify the integrity of these fragments.
To this end they may for example use a reliability enhancement method as described in the document WO 2007/085763.
In the embodiment described here, the peer-to-peer network 2 is a file distribution network of the file swarming type using the BitTorrent protocol or a similar protocol and in which each customer receiver CL that is a peer of this network can send the other peers file fragments even before receiving the file completely.
In this embodiment, the system of the invention includes a unicast supervisor SUP_CC with which a customer receiver CL may register to obtain a list of other peers of the peer-to-peer network 2 with which it may communicate to exchange file fragments corresponding to a given content.
The customer receivers CL of the invention include means for regularly sending the multicast supervisor SUP_MC statistics STAT on the reception of the content and possibly an ideal receiving bit rate EXP_DB. In the embodiment described here, these statistics STAT include a list of fragments received by this customer receiver CL and a list of fragments not received by this customer receiver CL.
These statistics STAT relate at least to the fragments broadcast by the multicast sources S. If a customer receiver CL is also a peer of the peer-to-peer network 2, these statistics STAT also relate to the fragments received in unicast mode from other peers.
According to the invention, the customer receiver CL includes means 21, 22, 23 for defining and modifying its receiving strategy. These means are further described below with reference to the step G80 of the receiving method used by this receiver.
In the embodiment described here, the multicast supervisor SUP_MC also has the hardware architecture of a conventional computer, as represented in
It includes a processor 31, a random-access memory (RAM) 32, and a read-only memory (ROM) 33. This read-only memory 33 constitutes a storage medium of the invention, readable by the multicast supervisor SUP_MC, on which is stored a computer program of the invention including instructions for executing the steps of a supervision method of the invention, the principal steps F10 to F80 of that method being represented in
The multicast supervisor SUP_MC includes means for registering a multicast source having one or more streams to transmit. To this end, in the embodiment described here, it manages a database BD_REG that includes for each registered multicast source S the parameters of the heartbeat signaling streams and the characteristics of the data streams sent by that source.
In one particular embodiment of the invention, the elements ELT sent by a multicast source S to the multicast supervisor SUP_MC for registration purposes are:
In the embodiment described here, the multicast supervisor SUP_MC stores these new elements ELT in the database BD_REG.
In the embodiment described here, the multicast supervisor SUP_MC includes means 24 for communicating over the network 1, enabling it in particular to communicate with a multicast source S using the TCP protocol.
In the embodiment described here, the multicast supervisor SUP_MC uses these means 24 to set up a communications channel C1 with each multicast source S registered with it.
According to the invention, the multicast supervisor SUP_MC includes means for receiving from at least one customer receiver CL statistics STAT on the fragments received or not received by that customer receiver, possibly the ideal multicast receiving bit rate EXP_DB for that customer receiver CL, and information INF_S on the multicast sources S from which this customer receiver CL receives the heartbeat signaling streams.
In the embodiment described here, the multicast supervisor SUP_MC stores this information in a database BD_STAT.
In the embodiment described here, the communications means 34 of the supervisor SUP_MC enable it to monitor the routers R of the network 1 to limit the maximum number NB_FL of multicast streams broadcast simultaneously in the network 1.
According to the invention, the multicast supervisor SUP_MC includes means 31, 32, 33 for aggregating in an aggregate data item AG the ideal bit rate EXP_DB, possibly the statistics STAT, and the information INF_S on the multicast sources.
In the embodiment described here, the aggregate data item AG created by the multicast supervisor SUP_MC for a multicast source S and a particular content includes:
In the embodiment described here, the aggregate data item AG is stored in the database BD_STAT.
According to the invention, the multicast supervisor SUP_MC includes means for making this aggregate data item AG available to the multicast source S concerned. In the embodiment described here, the multicast supervisor SUP_MC sends the aggregate data item AG to a multicast source S in the communications channel C1 set up between the multicast supervisor SUP_MC and the source S by its communications means 34.
In another embodiment, the multicast supervisor SUP_MC sends a multicast source S the characteristics CS of the strategy that it is to deploy.
According to the invention, a multicast source S includes means for adjusting its sending strategy as a function of aggregate data items AG received from the multicast supervisor SUP_MC and possibly strategy characteristics CS indicated thereby.
During a step E10, a multicast source S registers with the multicast supervisor SUP_MC, sending it the elements ELT including the parameters CHB of the heartbeat flux and the characteristics SEQ, INF_FL of each stream that it sends. This information is stored by the multicast supervisor SUP_MC in the database BD_REG during a step F10.
The multicast supervisor SUP_MC and the multicast source S then set up a communications channel C1 on which they are able to communicate using the TCP protocol, respectively during a step F20 and a step E20. In the embodiment described here, this channel C1 is set up at the initiative of the supervisor SUP_MC.
It is assumed that at least one customer receiver CL consults the multicast supervisor SUP_MC during a step G10 to obtain the list of the multicast sources S broadcasting a content CONT of interest to it. In the embodiment described here, this consultation is effected by means of the HTTP message GET. The customer receiver preferably indicates in this request the maximum receiving bit rate accepted by this customer.
On reception of such a request, the multicast supervisor SUP_MC communicates to the customer receiver CL during a step F30 the multicast sources S broadcasting with a bit rate acceptable to the customer receiver CL and, for each of those sources, the information CHB on the heartbeat signaling channel of the source and the information INF_FL on each stream broadcast by that source.
It is assumed that the multicast source S begins to broadcast during a step E30:
To receive data broadcast by a multicast source S, a customer receiver CL subscribes during a step G20 to the heartbeat signaling channel and to one or more streams broadcast by that source S, the multicast supervisor SUP_MC having communicated the information on these various streams to it during the step F30.
It is assumed in this example that a customer receiver CL is a peer of the peer-to-peer network 2 and is also seeking to be able to exchange fragments of the content CONT with other peers of this network.
To this end, the peer registers with the unicast supervisor SUP_UC during a step G30 and obtains from that server a list of peers of the peer-to-peer network 2 seeking to exchange fragments of this content.
In the embodiment described here, during a step F40 the supervisor SUP_MC sends a request RQ to a router R of the network for that router to monitor the subscription of the receivers that are connected to it to the multicast streams broadcast in the network. To be more precise, this subscription monitoring consists in verifying that a receiver does not access streams other than those to which it subscribed during the step G20.
Then, during a step F45, supervisor SUP_MC obtains the maximum number NB_FL of streams that can be broadcast simultaneously in the network.
According to the invention, a customer receiver CL regularly sends the multicast supervisor SUP_MC during a step G40 the statistics STAT on the fragments received or not received by that customer receiver CL, the ideal multicast receiving bit rate EXP_DB for that customer receiver CL, and information INF_S on the multicast sources S from which this customer receiver CL receives the heartbeat streams. The multicast supervisor SUP_MC receives and stores these statistics in the database BD_STAT during a step F50.
During a step F60, the multicast supervisor SUP_MC aggregates in an aggregate data item AG the statistics STAT, the ideal bit rate EXP_DB expected by each receiver, the maximum number of streams NB_FL that the network 1 is able to support, and the information on the multicast sources. The multicast supervisor SUP_MC stores this aggregate data item AG in the database BD_STAT during this same step F60.
Then, during a step F70, the multicast supervisor SUP_MC sends the aggregate data item AG via the channel C1 set up with the source S concerned to that source so that the latter source is able to adjust its strategy. Alternatively, it imposes a strategy on it by communicating to it the characteristics CS of the latter strategy. This aggregate data item AG or the strategy characteristics CS are received by the source during a step E40.
The multicast source S adjusts its strategy during a step E50 as a function of the aggregate data item or the characteristics of the strategy CS defined by the supervisor.
As soon as it modifies its sending strategy, the multicast source S sends the multicast supervisor SUP_MC during a step E60 the elements ELT of the updated new strategy, including the adjusted characteristics INF_FL of each of the streams sent by the source S and the characteristics CHB of its heartbeat stream.
These updated elements ELT are stored by the multicast supervisor SUP_MC during a step F80.
Simultaneously, during a step E70, the multicast source S modifies the sequence number SEQ sent in the heartbeat signaling stream that it is broadcasting to inform the customer receivers CL of its change in broadcasting strategy.
The customer receiver CL detects the new sequence number during a step G60 of its receiving method.
It may then decide during a step G80 to modify its receiving strategy by subscribing to new multicast broadcasting channels (discovered by consulting the multicast supervisor SUP_MC during a step G70), by unsubscribing from some multicast channels or by looking for some missing fragments on the peer-to-peer network 2.
To define its receiving strategy, a customer receiver CL preferably detects the multibroadcast streams that it is able to receive, subscribes to those streams, detects segments received incorrectly in those streams, waits a particular time in the hope of receiving the missing segments following the change of strategy of one or more multicast sources, and as a last resort obtains the missing segments from the peers of the peer-to-peer network 2.
In one particular embodiment of the invention, if a customer receiver detects a high number of lost packets, it unsubscribes from one or more multicast streams. This characteristic has the advantage of making it possible to control congestion in the multicast network 1 by preventing a customer receiver CL subscribing to a number of streams that is too high given the capacities of the network 1.
To this end, in one particular embodiment of the invention a customer receiver CL determines the total segment loss rate and the loss rate per stream.
If the loss rate relates to only one or some streams, it is probable that the network is a congestion between the multicast source S of that stream and the customer receiver CL. In this situation the customer receiver CL could unsubscribe from this stream temporarily, hoping that the congestion disappears.
However, if the loss rate is distributed across all the streams, the customer receiver CL reduces the number of streams to which it subscribes and seeks to obtain the missing fragments from the peers of the network 2.
As explained above, the invention has the advantage that it makes it possible to modify the strategies for broadcasting of a content by a multicast source.
In a manner that is not limiting on the invention, the invention may use the following broadcasting strategies:
Morin, Thomas, Dugoujon, David, Lejeune, Sabine, Hennequin, Jean-Baptiste
| Patent | Priority | Assignee | Title |
| 10749790, | Jan 15 2019 | Cisco Technology, Inc. | Multicast-based content distribution for IoT networks using bit index explicit replication (BIER) |
| Patent | Priority | Assignee | Title |
| 7325073, | Jun 28 2002 | Meta Platforms, Inc | Peer to peer video on demand system selectively using client and server to forward the requested video program to another client |
| 7697450, | Nov 30 2005 | ARRIS ENTERPRISES LLC | Method and apparatus for broadcast in an ad hoc network with dynamic selection of relay nodes |
| 7865137, | May 06 2002 | TUNNEL IP LLC | Music distribution system for mobile audio player devices |
| 7894377, | Dec 31 2002 | MOTOROLA SOLUTIONS, INC | Method and system for group communications |
| 20060159117, | |||
| 20060212907, | |||
| 20070223620, | |||
| 20080013503, | |||
| EP1434385, | |||
| EP1615403, | |||
| WO2005117345, | |||
| WO2007085763, | |||
| WO2007113447, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Sep 22 2009 | France Telecom | (assignment on the face of the patent) | / | |||
| Apr 11 2011 | LEJEUNE, SABINE | France Telecom | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027417 | /0351 | |
| Apr 18 2011 | MORIN, THOMAS | France Telecom | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027417 | /0351 | |
| May 16 2011 | DUGOUJON, DAVID | France Telecom | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027417 | /0351 | |
| May 26 2011 | HENNEQUIN, JEAN-BAPTISTE | France Telecom | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 027417 | /0351 | |
| May 28 2013 | France Telecom | Orange | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 032698 | /0396 |
| Date | Maintenance Fee Events |
| Oct 28 2013 | ASPN: Payor Number Assigned. |
| Apr 21 2017 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Apr 21 2021 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Date | Maintenance Schedule |
| Nov 26 2016 | 4 years fee payment window open |
| May 26 2017 | 6 months grace period start (w surcharge) |
| Nov 26 2017 | patent expiry (for year 4) |
| Nov 26 2019 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Nov 26 2020 | 8 years fee payment window open |
| May 26 2021 | 6 months grace period start (w surcharge) |
| Nov 26 2021 | patent expiry (for year 8) |
| Nov 26 2023 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Nov 26 2024 | 12 years fee payment window open |
| May 26 2025 | 6 months grace period start (w surcharge) |
| Nov 26 2025 | patent expiry (for year 12) |
| Nov 26 2027 | 2 years to revive unintentionally abandoned end. (for year 12) |