FIELD OF INVENTION

The present invention generally relates to a wireless multicast announcement method, and particularly relates to a wireless multicast announcement method using Hypertext Transfer Protocol (HTTP). BACKGROUND OF THE INVENTION

Traditionally, Internet Protocol (IP) allows hosts to communicate in a variety of ways. The most common schemes involve unicast communication (i.e., one host communicating with one client) and broadcast communication (i.e., one host communicating with all clients). A third scheme provided by IP is multicasting, where one host communicates with a group of clients.

In multicasting, message streams broken into packets are delivered to a group identified by a single multicast group address. The sender uses the multicast group address as the destination address of a datagram to send packets to all the members of the multicast group. Thus, using multicasting, any host can send packets to a group, and members of the group receive the packets. Multicasting allows one host to serve many clients, while sending the packets only once. Typically, multicast packets are User Datagram Protocol (UDP) packets. A common use of multicast communication is for sending digital audio/video streams. When an audio/video stream is sent to a multicast address, multicast enabled routers forward the packets across any interface that has hosts or routers that have joined the associated multicast address. The one-to-many relationship between a single multicast stream source and the many clients allows efficient delivery of the audio/video stream. Further, the packets containing the multicast media stream may be advertised to potential clients using Session Announcement Protocol (SAP). SAP packets, in turn, are used to deliver Session Description Protocol (SDP) messages. To announce a multicast session, the multicast source multicasts (i.e., sends packets using a multicast address) packets periodically to a well-known multicast group carrying an SDP description of the session that is going to take place. Clients that wish to know which sessions are going to be active simply listen to the same well-known multicast group, and receive those announcement packets. The content of the SAP and SDP message provides potential clients with information associated with the multicast source, the multicast address to receive the multicast stream (i.e., IP addressing information for "tuning into" the multicast message stream), and the content of the multicast stream. Specifically, an individual SAP packet contains the IP multicast address information for the session which it describes.

One problem with SAP is that both the multicast sender and receiver must be capable of handling SAP and SDP. SAP is not yet a ubiquitous protocol found on every computer.

Another limitation of SAP is that there is limitation on how much information can be embedded inside each SAP message. There is so little information about the streamed multimedia that can help the receiver to decide which stream to watch from the SAP alone. This will eventually lead to overhead and unnecessary bandwidth usage when the receiver has to browse along every media stream to find what he or she likes.

In addition, SAP announcement can only be sent from the media source itself. No third party can do the announcement on behalf of the media source. This means that the receiver must have a communication session with every multicast sender. This is acceptable if there's only a few sender out there, but when the number of senders increases, the network will be more congested by the SAP messages alone.

Yet another problem with SAP is it is the sender that chooses where to send the announcement. The receiver can opt for which stream to watch, but not which announcement to receive.

Accordingly, there is a need for a method that allows multicast announcement through a protocol that:

· Already exists in most end-users' nodes;

• Is flexible on how much and what kind of information can be embedded within the announcement;

• Can be passed through or even to one single proxy

• Capable of offering flexibility and options to end-users

SUMMARY OF THE INVENTION

This invention relates to a method of sending multicast announcements that addresses the problems mentioned above. It is proposed to use a different protocol type in sending the multicast announcements. The best choice for this application is Hypertext Transfer Protocol (HTTP), as it is a common protocol that is compatible with the vast majority of end user nodes. As such, this invention concerns a method of providing multicast multimedia announcement using a HTTP. This invention also concerns a method of allowing a HTTP/TCP/IP Internet Protocol announcement application to communicate with a RTP/UDP/IP Real-time Transport Protocol multimedia stream application. This invention also relates to a method for sending multicast service announcements in multimedia streaming comprising the steps of:

a) sending a service announcement each from a plurality of sending nodes to a dedicated announcement server, each said service announcement associated with a multimedia stream;

b) converting said service announcements into a hypertext transfer protocol message, said hypertext transfer protocol message comprising details of each said multimedia stream;

c) sending said hypertext transfer protocol message from the announcement server to at least one receiving node;

d) selecting based on said hypertext transfer protocol message a multimedia stream to be subscribed to by the said receiving node; and

e) subscribing to said multimedia stream by sending a request message from the receiving node to the sending node.

In a preferred embodiment, the receiving node communicates only with said announcement server to access said hypertext transfer protocol message. The dedicated server periodically checks for said service announcements from said sending node. Also, the said hypertext transfer protocol message is able to communicate with a real-time transport protocol associated with multimedia streams.

This invention further relates to a method of providing a multicast service announcement using a hypertext transfer protocol for sending a service announcement from an announcement server to at least one receiving node. The receiving node communicates only with said announcement server to access said hypertext transfer protocol service announcement. The hypertext transfer protocol service announcement is able to communicate with a real-time transport protocol associated with multimedia streams. By using a proxy announcement server for every multicast source, the receiving node will only have to communicate with that server to get updates on available multicast streams. This announcement server can get the updates from multicast sources periodically. So instead of having a mesh-like communication between multiple senders and multiple receivers, there is a more efficient star-like topology whereby a lot of bandwidth can be saved.

In mesh communication (not mesh network or mesh topology), the number of communication sessions is the number of senders times the number of receivers. For example, if there are three sending nodes and three receiving nodes, the number of sessions is 3 x 3 = 9. As the number of senders and receivers increase, the number of communication sessions will increase exponentially. With a proxy announcer, the number of communication sessions will only be the number of senders plus the number of receivers. So for the case with three sending nodes and three receiving nodes, the number of sessions is 3 + 3 = 6. The number of sessions increases linearly with the number of senders and receivers.

Other objects and further features of the present invention will be apparent from the following detailed description when read in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF DRAWINGS Figure 1 shows a flowchart depicting an overall process in an embodiment of this invention.

Figure 2 shows a flowchart depicting the announcement process in an embodiment of this invention. Figure 3 shows a process flow of the receiving node in an embodiment of this invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

With reference to Figure 1 , there is shown a plurality of sending nodes (10) for communicating multicast multimedia streams such as but not limited to video and music streams to a receiving node (30). There may be, in other embodiments, a plurality of receiving nodes (30). Each of the sending nodes (10) and receiving node (30) incorporate a computer. The computer includes, for example, a main control unit such as a CPU, and storage units such as a ROM (Read Only Memory) and a RAM (Random Access Memory). The computer also includes inputs/outputs such as a keyboard, mouse, display or a touch panel, and a communication unit such as a wireless network card. These constituent elements are connected via a bus and controlled by causing the main control unit to execute programs stored in the storage unit.

In multicasting, multimedia streams are broken into packets that are delivered to a group identified by a single multicast group address. The sending node (10) uses the multicast group address as the destination address of a datagram to send packets to all the members of the multicast group. Thus, using multicasting, any host can send packets to a group, and members of the group receive the packets. Multicasting allows one host to serve many clients, while sending the packets only once. Typically, multicast packets are User Datagram Protocol (UDP) packets. A common use of multicast communication is for sending digital audio/video streams. When an audio/video stream is sent to a multicast address, multicast enabled routers forward the packets across any interface that has hosts or routers that have joined the associated multicast address. The one-to-many relationship between a single multicast stream source and the many clients allows efficient delivery of the audio/video stream. The packets containing the multicast media stream are advertised to potential clients (receiving nodes (30)) by sending out service announcement messages (40) containing some information about the multicast stream packet it is sending. A dedicated announcement server (20) periodically checks for these announcement messages from each sending node (10) and converts them into a hypertext transfer protocol (HTTP) message (50) that is a union or grouping of all the individual service announcement messages (40) received. The group HTTP message is then transmitted to a receiving node or nodes (30). The HTTP message is able to contain more information than a service announcement that uses the known Service Announcement Protocol (SAP). As such, it may include such information as the message length, type and even provide a preview of the multimedia stream. The receiving node (30) need only communicate with the announcement server (20) to receive announcements. The receiving node (30) or an operator thereof then selects which multimedia stream is to be accepted and from which sending node (10). The receiving node (30) then sends a subscription request (60) directly to the sending node (10) for the selected multimedia stream. The selected multimedia stream is then transmitted directly from the sending node (10) to the receiving node (30).

Referring now to Figure 2, there is shown a typical configuration of an embodiment of this invention. A plurality of sending nodes (10) transmits service announcements (40) to a dedicated announcement server (20). The dedicated announcement server (20) converts the service announcements (40) into a hypertext transfer protocol (HTTP) message (50) that is a union or grouping of all the individual service announcement messages (40) received. The group HTTP message is then transmitted to a plurality of receiving nodes (30). The HTTP message is able to contain more information than a service announcement that uses the known Service Announcement Protocol (SAP). It may include such information as the message length, type and even provide a preview of the multimedia stream. The receiving node (30) need only communicate with the announcement server (20) to receive announcements. The receiving node (30) or an operator thereof then selects which multimedia stream is to be accepted and from which sending node (10). The receiving node (30) then sends a subscription request directly to the sending node for the selected multimedia stream. The selected multimedia stream is then transmitted directly from the sending node (10) to the receiving node (30).

Figure 3 shows a process flow of the receiving node. The process starts with the start of a HTTP client within the receiving node. Next, the HTTP announcement transmitted by the announcement server is fetched. The list of announcements is viewed. If no stream is selected, the HTTP announcement list is fetched and the list is viewed again. Once a particular stream is selected, an execution message is sent from the receiving node to the sending node transmitting the multimedia stream to request subscription of the selected multimedia stream. The selected multimedia stream is then watched or played on a display on or connected to the receiving node. There are also options to change the stream while the media is being watched or played.

It should be noted that the invention has been described with reference to a few exemplary and preferred embodiments in order to demonstrate the principles and concepts of the invention. The invention is not limited to the embodiments described herein. As will be understood by those skilled in the art, modifications may be made to the embodiments described herein and all such modifications are within the scope of the invention.