FIELD OF THE INVENTION
A novel broadcasting method called co-casting is proposed, where the users participating in a broadcast co-operate in order to receive a stream of any content such as audio/video/data any other type of content transportable on a network that can be transported on a network and also, depending on their available bandwidth, pass on the stream to other clients who in turn pass on the stream to some more clients; thus forming chains of transmission, and thereby reducing the average bandwidth and computation required at the server to feed an audio/video stream to a client, and thus also serving more clients in the webcast. The clients participating in the broadcast also share information about other clients in the network who can potentially provide the stream feed.
BACKGROUND OF THE INVENTION AND PRIOR ART
This section cites other patents/patent applications which deal with webcasting or at least have titles close to the concept being described in this document. Along with the citations are also brief descriptions of the contents of the citations.
• Method for internet distribution of music and other streaming media Patent Number: 20050111662; Fiedler, Mark Geoffrey;
- Talks of storing increasing number of clients connected to a server by adding supplementary servers.
- Talks also of buffering streamed content from server, so user can "go back" and listen.
• Apparatus and method for efficient live webcasting and network connectivity Patent Number: 20030035386; Sullivan, Mark;
Talks of satellite channels for efficient webcasting
• Live broadcasting method and its system for SNG webcasting studio Patent Number: 20040226047; Lin, Jyh-Bor; Chai, Jeff; Lai, Liang-Yi;
- Teaching program broadcasted by connecting to a server
• Real time webcasting system and method for multicasting various multimedia contents through multichannel Patent Number: 20020031097; Jung, Yeon Tae;
Method for combining data originating from various stations (multichannel), so that one stream can be streamed to webcast listeners. However none of these aforementioned citations disclose the invention of the instant Application wherein the method for broadcasting on a network by sharing of streams and stream sources among clients availing the broadcast.
Webcasting is a term used to denote broadcasting of media streams on the web. The traditional way of implementing this is for an entity such as a company to host a powerful server or farm of servers with a huge bandwidth to allow any end user to connect to the server system. Each user is fed with stream directly from the server system. If there are 100,000 users concurrently connected, the server system will have to pump 100,000 packets of audio/video. This is compute-intensive. Number of servers required goes up. Assuming a bandwidth of 20 kbps for two audio streams, the server system needs to have a 2 Gbps link to serve 100,000 users.
OBJECTS OF THE INVENTION
The primary object of the invention is to provide method for broadcasting on a network by sharing of streams and stream sources among clients availing the broadcast.
The another object of the present invention is to form chains of transmission, and thereby reducing the average bandwidth and computation required at the server to feed an audio/video stream to a client, and thus also serving more clients in the webcast.
Yet another object of the present invention is to provide method which allows each client to dynamically learn from clients in the network topology about the existence of other client(s) that provide(s) the feed.
Yet another object of the present invention is to provide method for clients to advertise themselves for forwarding the stream and client provides feed for more than one client attached to it depending on the bandwidth and computation power available at the feeder client.
Yet another object of the present invention is to provide method which allows a client to initiate contact with other client(s) and the client is allowed to send requests to multiple feeder clients to pick up the stream from any of the connections.
Yet another object of the present invention is to provide method wherein the client is independently allowed to become a server, the user using the client providing his or her own content as feed, either publicly or to a closed set of users permitted by the user providing the feed.
Yet another object of the present invention is to provide method wherein a client can automatically detect the presence of other clients and take the feed from them, without a server playing a role in procuring such a feed.
STATEMENT OF THE INVENTION
The present invention relates to a method for broadcasting on a network by sharing of streams and stream sources among clients availing the broadcast.
BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 shows (a) Traditional Webcasting and (b) Example of Proposed Method. Figure 2 shows continuing the chain when a client in between disconnects. Figure 3 shows clients can start as many outgoing streams as their bandwidth and computation capacity permit.
Figure 4 shows possible alternate or backup connection. Figure 5 shows Reverse Channel Mechanism and Looping.
Figure 6 shows Users starting their own streams and others accessing them. DETAILED DESCRIPTION OF THE INVENTION
The present invention relates to a method for broadcasting on a network by sharing of
streams and stream sources among clients availing the broadcast.
Yet another embodiment of the present invention is requesting a server for a stream by a
new client; redirecting the new client to existing client(s) by the server for the stream or
in the absence of which, the server providing the stream itself; and creating chain(s) of
transmission through the redirected client for co-operative broadcasting.
Still another embodiment of the present invention is the streams are media streams
selected from a group comprising Data, Audio or Video or any other type of content
transportable on a network.
Still another embodiment of the present invention is a server can start one or more chains of transmission.
Still another embodiment of the present invention is the server can maintain data to attach the clients to the optimal chain and location within the chain.
Still another embodiment of the present invention is the number of clients that are added to a chain is in accordance with the delay that is tolerable.
Still another embodiment of the present invention is the method reduces bandwidth and computing power of the server.
Still another embodiment of the present invention is the client has the option of having a control connection with the server to log in or learning of other clients providing the stream feed automatically by dynamically sensing the network or by contacting a repository of available feeder clients.
Still another embodiment of the present invention is the server decides whether a client gets a feed directly from the server or from another client.
Still another embodiment of the present invention is the method provides feedback through the control connection to the server when the client fails to get the feed. Still another embodiment of the present invention is the method allows each client to dynamically learn from clients in the network topology about the existence of other client(s) that provide(s) the feed.
Still another embodiment of the present invention is the method provides for clients to advertise themselves for forwarding the stream.
Still another embodiment of the present invention the client provides feed for more than one client attached to it depending on the bandwidth and computation power available at the feeder client.
Still another embodiment of the present invention is the client is fitted internally or externally with a reverse channel mechanism to send back a media stream to the server. Still another embodiment of the present invention is the reverse channel can be looped back at the server to add to the media stream originating at the server. Still another embodiment of the present invention is the method allows a client to initiate contact with other client(s).
Still another embodiment of the present invention is the client is allowed to send requests to multiple feeder clients to pick up the stream from any of the connections. Still another embodiment of the present invention is the client retains the other feeds / feed sources in its repository, as backup.
Still another embodiment of the present invention is the new client is positioned in the chain in tune with its network environment and restrictions.
Still another embodiment of the present invention is the client is independently allowed to become a server, the user using the client providing his or her own content as feed, either publicly or to a closed set of users permitted by the user providing the feed. Still another embodiment of the present invention is the user starting his or her own content stream can advertise the availability of such a stream through the server. Still another embodiment of the present invention is the clients can share and feed media streams amongst themselves, without the server playing a role in such transactions. Still another embodiment of the present invention is a number of servers are provided to share the same stream content to load balance incoming client requests. Still another embodiment of the present invention is the servers dish out multiple content streams for the client to choose the content stream of his choice to receive and to forward. Still another embodiment of the present invention is a mechanism exists to continue feed to the clients, which were getting a feed from a feeder client that logged out or disconnected from the system.
Still another embodiment of the present invention is a client can automatically detect the presence of other clients and take the feed from them, without a server playing a role in procuring such a feed.
A novel broadcasting method called co-casting is proposed, where the users participating in a broadcast co-operate in order to receive a stream (*) of any content (such as audio/video/data) that can be transported on a network and also, depending on their available bandwidth, pass on the stream to other clients who in turn pass on the stream to some more clients; thus forming chains of transmission, and thereby reducing the average bandwidth and computation required at the server to feed an audio/video stream to a client, and thus also serving more clients in the webcast. The clients participating in the broadcast also share information about other clients in the network who can potentially provide the stream feed (#).
* The terms stream, media stream and content denote audio or video or data or any other content that can be transported on a network, and any combinations of these.
# The terms feeder and feeder clients denote entities or clients (for example: PC software, net radio hardware or mobile phone software) used by participants in the broadcast which can provide content feed to other clients.
Webcasting is a term used to denote broadcasting of media streams on the web. The traditional way of implementing this is for an entity such as a company to host a powerful server or farm of servers with a huge bandwidth to allow any end user to connect to the server system. Each user is fed with stream directly from the server system. If there are 100,000 users concurrently connected, the server system will have to pump 100,000 packets of audio/video. This is compute-intensive. Number of servers required goes up. Assuming a bandwidth of 20 kbps for two audio streams, the server system needs to have a 2 Gbps link to serve 100,000 users.
The instant invention is illustrated in Fig.l (b). Suppose a server feeds content to the first user who logs in. Now when the second user logs in, she need not get the live content feed from the server but instead from the first user; the third user can get the feed from the second and so on in a chain. In this way, the computation and bandwidth at the server goes down, as it is feeding only one client. If the server machine is a powerful machine and has a lot of bandwidth, it can go on to start more than one chain of users. As far as the end user is concerned, her bandwidth consumption is generally the equivalent of a one-to-one VoIP call: One incoming stream and one outgoing stream. The user may allow more outgoing streams from her terminal, depending on the bandwidth available and computation capacity. The server can maintain the data required to attach the clients to the optimal chain and location within the chain. The number of clients that can be added to a chain is limited by the delay that can be tolerated for a live broadcast. The number of clients who get the streaming increases with two factors: o The max number of users in a chain, o The number of chains initiated from the server
Bandwidth Reduction:
Let us assume a maximum chain length of 100 and the number of chains as 1000. In Fig. 1 (b), it means m = 1000. Further assume the same 20kbps bandwidth for two audio streams. A server system will directly feed 1000 users who are at the top of the 1000 chains. So the server system will need 1000 x 20kbps = 20Mbps. Now in each chain, there are 100 users. So the total number of users = 100 x 1000 = 100,000. So, effectively, to support 100,000 users, we need only 20Mbps as against the 2Gbps required for traditional webcasting methods. This is a 100 times reduction.
Lesser Server Deployments:
We have seen that the bandwidth required is reduced substantially with the new method. Also, the computing power required to pump out streams to 100,000 streams will reduce 100 times, as the number of clients getting the feed directly from the server is that much lesser. This implies that the total number of servers required to be deployed for servicing a certain number of clients is substantially lesser.
What happens when a client in the middle of a chain logs out of the system? How will the clients who were below that client continue to get the feed? Refer Fig. 2.
This can be handled in two ways:
o Each client can be made to have a control connection with the server to log in. The server decides whether a client gets a feed directly from the server or from another client. For eg, if client C22 in Fig. 1 (b) logs out or gets disconnected from the server, the server will identify the event and take up the task of allocating client C21 to feed C23. In the case where the client continues to fail getting the feed (this can be a feedback to the server through the control connection, when no packets arrive at the client), the server may decide to start a new chain to accommodate the client.
o Another method is to allow each client to dynamically learn from the network topology about the existence of another client who can provide the feed, so it can shift to the other client to procure the feed. For eg:
a. A client may know of several sources of the stream initially, but connects to one of them. If the feed from that client gets cut, it may try the next one in its repository. Also, other clients may advertise themselves for the streams they propagate.
b. If the client is unable to get the feed from feeder clients it knows of, it can ask those feeder clients for other feeder clients they know of.
The delay is the highest to the last in the chain. However, the length of the chain can be optimized to achieve acceptable delays. If the streaming content is that of a live event - for eg: one may not mind a 30 second delay if he or she is listening to or watching a cricket match - the chain's maximum length can be designed to suit this deferred live co- casting.
Other aspects of the Invention:
1. Depending on the bandwidth and computation power available at the client machine, the client can be made to provide feed for more than one client attaching to it. Please refer Fig. 3.
2. Each client can be fitted with a reverse channel mechanism so that it can also have an option to send back a media stream to the server directly, if the server allows such an interaction. The server may also choose to loop or attach the reverse channel to the main channels, feeding all clients with one client's reverse channel contents. Please refer Fig. 5. An example of this is a celebrity interview, where the interviewer takes a question from an audience and transmits the question on broadcast. The reverse channel can be built in to the client or can be an external entity.
3. Each client can have a control connection with a server to notify the server if it is not receiving the stream, so that the server can allocate another feeder or provide several potential feeders to the client.
4. As shown in Fig. 3, there can be several servers. The servers may provide the same stream content (load sharing mode) or provide different streams to which the clients may tune in.
5. Each client can also be independently allowed to become a server, starting a content feed of that user's content. The availability of that user's content can be advertised through the main server, by contacting the main server. Please refer Fig. 6.
6. A user who wants to start a content feed of her content may also inform / advertise to a set of users by other means such as email or word of mouth. This restricts the users picking up her content feed to a set of users desired by her.
7. One client who gets into a chain as shown in Fig. 1(b) may co-operate and feed at least one other client in the chain. Apart from that, however, this client may start a chain of its own, which need not be part of the main system. That is, without the server playing a role. For eg: C22 in Fig. 1 (b), apart from feeding C23, can also feed another client C221. However, unlike as in the case of C23, if C22 disconnects from the main chain, the system will not take care of providing feed to C221 and its successors.
8. Referring to Fig. 2, if a client logs out or disconnects from the system, the client chains that depend on that client for their feed can either get their feed from another client(s) allocated by the main server or may choose a client from a repository of available client names, or may already have a repository of other such sources.
9. When a client comes online, it may initiate contact with several other clients to get several feeds and if it successfully receives a feed from more than one other client, can choose to keep only one of them and stop the other feeds. However, it may retain in its repository of other sources, the other sources as backup. Please refer Fig. 4.
10. The chain to which a new client is attached and the position in the chain will be in tune with the client's network environment and restrictions. The server can keep track of the network environment of a client and place it accordingly. Examples include, but are not limited to:
o A client who is behind a symmetric NAT (in which case it is difficult for that client to send UDP packets to other clients behind other NATs) can be attached to a client who has a public IP. o Or if a client is behind a UDP firewall, it could get a feed from a either a public IP or a server on TCP, and so on.
11. A client - Client A - may initially get to know of some feeder clients (say clients X, Y and Z) from the server or a website. These feeder clients in turn may know of other feeder clients (M, N and O), which they can reveal to client A. So client A can now contact the other feeder clients. The network thus grows dynamically. The server can wash its hands off the client A, without maintaining state, once it has given A the feeders X, Y and Z.
12. Where network elements/devices can be sensed, a client can automatically detect other clients providing a stream and approach them for the stream. An example includes but is not limited to Bluetooth networks where one device on Bluetooth detects another in proximity. In this case again, a server need not play any role in procuring the feed for the client.
13. As bandwidth infrastructure increases a huge range of services such as Network Radio, Network TV and many others can use this invention to effectively broadcast content.

We claim;
1. A method for broadcasting on a network by sharing of streams and stream sources among clients availing the broadcast.
2. The method as claimed in claim 1, wherein said method comprising steps of;
i. requesting a server for a stream by a new client;
ii. redirecting the new client to existing client(s) by the server for the stream or in the absence of which, the server providing the stream itself; and
iii. creating chain(s) of transmission through the redirected client for co¬operative broadcasting.
3. The method as claimed in claim 1, wherein the streams are media streams selected from a group comprising Data, Audio or Video or any other type of content transportable on a network.
4. The method as claimed in claim 1, wherein a server can start one or more chains of transmission.
5. The method as claimed in claim 1, wherein the server can maintain data to attach the clients to the optimal chain and location within the chain.
6. The method as claimed in claim 1, wherein the number of clients that are added to a chain is in accordance with the delay that is tolerable.
7. The method as claimed in claim 1, wherein the method reduces bandwidth and computing power of the server.
8. The method as claimed in claim 1, wherein the client has the option of having a control connection with the server to log in or learning of other clients providing the stream feed automatically by dynamically sensing the network or by contacting a repository of available feeder clients.
9. The method as claimed in claim 1, wherein the server decides whether a client gets a feed directly from the server or from another client.
10. The method as claimed in claim 8, wherein the method provides feedback through the control connection to the server when the client fails to get the feed.
11. The method as claimed in claim 1, wherein the method allows each client to dynamically learn from clients in the network topology about the existence of other client(s) that provide(s) the feed.
12. The method as claimed in claim 1, wherein the method provides for clients to advertise themselves for forwarding the stream.
13. The method as claimed in claim 1, wherein the client provides feed for more than one client attached to it depending on the bandwidth and computation power available at the feeder client.
14. The method as claimed in claim 1, wherein the client is fitted internally or externally with a reverse channel mechanism to send back a media stream to the server.
15. The method as claimed in Claim 14, wherein the reverse channel can be looped back at the server to add to the media stream originating at the server.
16. The method as claimed in claim 1, wherein the method allows a client to initiate contact with other client(s).
17. The method as claimed in claim 16, wherein the client is allowed to send requests to multiple feeder clients to pick up the stream from any of the connections.
18. The method as claimed in claims 16 and 17, wherein the client retains the other feeds / feed sources in its repository, as backup.
19. The method as claimed in claim 1, wherein the new client is positioned in the chain in tune with its network environment and restrictions.
20. The method as claimed in claim 1, wherein the client is independently allowed to become a server, the user using the client providing his or her own content as feed, either publicly or to a closed set of users permitted by the user providing the feed.
21. The method as claimed in claim 20, wherein the user starting his or her own content stream can advertise the availability of such a stream through the server.
22. The method as claimed in claim 21, wherein the clients can share and feed media streams amongst themselves, without the server playing a role in such transactions.
23. The method as claimed in claim 1, wherein a number of servers are provided to share the same stream content to load balance incoming client requests.
24. The method as claimed in claim 1, wherein the servers dish out multiple content streams for the client to choose the content stream of his choice to receive and to forward.
25. The method as claimed in Claim 1, wherein a mechanism exists to continue feed to the clients, which were getting a feed from a feeder client that logged out or disconnected from the system.
26. The method as claimed in claim 1, wherein a client can automatically detect the presence of other clients and take the feed from them, without a server playing a role in procuring such a feed.
27. The method for broadcasting on a network substantially as herein above described with reference to the accompanying drawings.
Dated this 25th day of August, 2006
OfK&S PARTNERS
ATTORNEY FOR THE APPLICANT