Method and apparatus for enhanced file distribution in multicast or broadcast

In a communication system providing broadcast services in which files for broadcast are accessible by the users. Contents of the broadcast files and the file attributes required to process the broadcast files are separately sent. As arranged, receiving the file attributes ahead of the content files allow more efficient download and processing of the broadcast files.

BACKGROUND

The present invention generally relates to data communications, and more particularly, to enhanced file distribution in data communication systems in multicast or multicast environments.

Interconnecting of networks globally allows information to be swiftly accessed irrespective of geographical distances.FIG. 1shows a simplified schematic drawing of the global connection of networks, commonly referred to as the Internet signified by the reference numeral20. The Internet20is in essence many networks with different levels of hierarchy linked together. The Internet20is operated under the Internet Protocol (IP) promulgated by the Internet Engineering Task Force (IETF). Details of the IP can be found in Request for Comments (RFC) 791 published by the IETF.

Connected to the Internet20are various individual networks, sometimes called local area networks (LANs) or wide area networks (WANs) depending on the network sizes. Shown inFIG. 1are some of such networks22,24, and26.

Within each of the networks22,24and26, there can be various pieces of equipment connected to and in communication with each other. Examples are computers, printers, and servers, to name just a few, which are commonly called nodes. When a node communicates beyond its own network via the Internet20, the node needs to send data packets in compliance with the IP to the corresponding node in the other network. Likewise, data packets sent out by the corresponding node in the other network to the initiating node have also to conform with the IP.

Different types of applications necessitate different levels of protocols operating in conjunction with the IP. Take a few examples for illustration. Suppose the node28in the network22tries to download a file from another node30in the network26. For file transfer, very often, a higher order protocol called the File Transfer Protocol (FTP) is used. The FTP can be found in RFC 959 published by the IETF. As such, data packets sent by the node30to the node28have to conform with, among other things, the FTP and the IP.

As another example, suppose the node28in the network22browses through the Internet20a website posed by yet another node32in the network24. This time, the nodes28and32possibly use another higher order protocol, called the Hyper Text Transfer Protocol (HTTP). The HTTP can be found in RFC 2616 published by the IETF. Again, the exchanged data packets have to conform with, among other things, the HTTP and the IP.

The exemplary protocols FTP and HTTP are carried through still another intermediate level protocol, called the Transport Control Protocol (TCP). The TCP can be found in RFC 793. Under the TCP, the objective is to transmit data accurately. As such, erroneous data are always retransmitted. The TCP and the protocols that ride on the TCP, such as the FTP and HTTP, are commonly employed for one-to-one applications.

Advances in technologies make data intensive data transfers possible. For instance, networks capable of handling high bandwidths allow exchanges of multi-media files, such as audio and video files which normally hold massive data. When a large number of nodes receive such multimedia files, file delivery via conventional unicast methods may be inefficient. Among other things, the files need first to be replicated and thereafter delivered individually to each node. Consequently, there is a need to develop other types of protocols to address the increasing demand for one-to-many applications, suitable to be used for broadcast or multicast services.

To meet the demand, the File Delivery over Unidirectional Transport (FLUTE) protocol, specifically suitable for multicast file distribution applications, has been devised. The FLUTE protocol can be found in RFC 3926, published by the IETF, entitled “FLUTE—File Delivery over Unidirectional Transport,” Nov. 14, 2003. In a multicast session, traffic flow is more or less unidirectional. That is, reverse data traffic is limited, if at all existent. Such unidirectional usage is common in broadcast or multicast applications in which there is one communication source sending data to many receivers.

Data transmitted under the FLUTE protocol are carried on the top of the User Datagram Protocol (UDP), instead over the TCP as in the HTTP and FTP protocols. Under the UDP, erroneously data are not normally resent. For accurate data transmission, the FLUTE protocol normally transmits data in redundancy and uses error correcting schemes.

Using the FLUTE protocol, one or more files are transported during a file delivery session. The files are carried in data packets in the form of asynchronous layered coding (ALC), called the ALC packets. Depending on its length, each file may be transmitted in one or more ALC packets. The files are called objects. The objects are identifiable by file attributes contained in a file delivery table (FDT). At the receiver's end, the file attributes are relied on to reconstruct the original file from the ALC packets. The received file objects cannot be processed until the corresponding file attributes are correctly received. For higher reliability of FDT reception, duplicate FDT instances are typically interposed with the payload data in the ALC packets sent to the receivers. Heretofore, the FDTs and the content files are more or less transmitted concurrently. As such, even if the content files are correctly received, which is not always the case, a receiver needs to correctly receive the FDTs, extract the file attributes from the FDTs and thereafter processing the received content files. That is, a successful decoding and the subsequent presentation of a received file depend on a successful download of the file attributes needed for processing the ALC packet, more or less at the same time. Such dependence unavoidably introduces delays and often negatively impacts the quality of the content presentation. Furthermore, users without the correct file attributes very often make multiple attempts to acquire the needed file attributes, thereby typing communication channels. As a result, it may not be the most efficient use of available communication resources.

Accordingly, there is a need to provide more efficient schemes for better quality of broadcasts and in addition more economical utilization of communication resources.

SUMMARY

In a communication system providing broadcast services in which files for broadcast are accessible by the users. Contents of the broadcast files are sent in a one communication session. The file attributes required to process the broadcast files are separately sent in another communication session. As arranged, receiving the file attributes ahead of the content files allow more efficient download and processing of the broadcast files.

These and other features and advantages will be apparent to those skilled in the art from the following detailed description, taken together with the accompanying drawings, in which like reference numerals refer to like parts.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purpose of explanation. It should be appreciated that one of ordinary skill in the art would realize that the invention may be practiced without the use of these specific details. In other instances, well known structures and processes are not elaborated in order not to obscure the description of the invention with unnecessary details. Thus, the present invention is not intended to be limited by the embodiments shown, but is to be accorded with the widest scope consistent with the principles and features disclosed herein.

FIG. 2shows a simplified schematic drawing of an exemplary embodiment of the invention. The overall system is generally signified by the reference numeral40. In the communication system40, only two networks42and44are shown for reasons of simplicity and clarity in explanation. The networks42and44are linked by a backbone network46, such as an intranet or the Internet.

Suppose in this embodiment, the network42is operated by a service provider. The service provider installs a node48in the network42. In this example, the node48is called a broadcast service distributor (BSD). The content server48can be designed to hold broadcast contents and also associated information of the broadcast provided by the service provider.

In the network44, there is a subscriber node50capable of receiving services, including services provided by the server node48via the backbone network46. In this embodiment, the node50is depicted as a wireless device, such as a personal digital assistant (PDA), a mobile computer, or a cellular telephone, to name just a few. The network44supports wireless technologies such as the cdma2000 standards as set forth by the 3GPP2 (Third Generation Partnership Project 2), which is a consortium of several international standards bodies, including the TIA/EIA (Telecommunications Industry Associations/Electronic Industries Associations) of the United States. It should be noted that the network40can also support other standards, such as the WCDMA (Wideband Code Division Multiple Access) standards promulgated by the 3GPP (Third Generation Partnership Project), coordinated and supported by various European standards entities. Another example is the standards developed by the Forward Link Only (FLO) Forum, which is an association of various entities in the wireless industry promoting standardization for use in the FLO networks.

The subscriber unit50communicates with the network44via a radio access network (RAN)52. The RAN52includes a base station controller/packet data control function (BSC/PDF)54connected to a plurality of base stations (BSs)66A-66N. In the networks44, there is implemented a packet data serving node (PDSN)68and a broadcast serving node (BSN)70. Both the PDSN68and the BSN70serve the function of interfacing between the backbone network46and the RAN52in the network44. The BSN70is installed more toward multicast or broadcast usage while the PDSN68mostly deals with unicast applications. In this specification, the terms multicast and broadcast are used interchangeably.

In the network44, there is another server, called the broadcast multicast service (BCMCS) content server63connected to the BSN70. In general, the BCMCS content server63pre-stores broadcast contents and associated data of the broadcast contents, including that provided by the content server48, transferred via the backbone network46.

In the exemplary embodiment, communications among some of the nodes are depicted as carried out wirelessly. However, it should be appreciated that it need not always be the case. Non-wireless communications via various other means among those nodes are also applicable. For example, instead of a wireless device, the node50can be a stationary computer or another server communicating with the network44via optical links or conventional conductive cables.

Suppose in this embodiment, the backbone network46supports the Internet Protocol (IP). Prior to describing the operational details, it helps first to explain generally the processing of a data packet during packet data communications via the various levels of protocols of different hierarchies and their mutual relationships operating under the IP.

In the art of network communications, protocols are hierarchized in accordance with the Open System Interconnection (OSI) model, as set forth by the International Organization for Standardization (ISO) and the International Telecommunication Union-Telecommunications Standards Sector (ITU-T). The purpose is to facilitate multi-vendor equipment interoperability. That is, each level of protocol hierarchy has its own specifications. As such, as long as the specifications of a particular hierarchy level are met, developments of products in that level are assured to be compatible with other products in other levels.

FIG. 3schematically shows a stack of protocols in hierarchical order, commonly referred to as the “protocol stack,” and is generally signified by the reference numeral72. The IP protocol stack72is structured in conformance with the Internet Engineering Task Force (IETF) model which is similar to but not exactly the same as the OSI model. In accordance with the IETF model, the IP protocol stack72has five layers, starting from Layer1to Layer5. Thus, a data packet sent out by a node, such as the node48or50as shown inFIG. 2, has to be processed through the protocol stack72. The stack of protocols72is built in the node in the form of software or hardware, or a combination thereof. Likewise, a data packet received by the same node has to be processed through the same protocol stack72but in the reverse order.

Take an example for illustration. Suppose a data packet is processed to be sent out from a node, for instance the node48(FIG. 2), the data packet is first created in accordance with one of the protocols in the application layer, i.e., Layer5. Layer5includes the Hyper Text Transfer Protocol (HTTP), Service Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), Real Time Transfer Protocol (RTP), and the File Delivery Over Unidirectional Transport/Asynchronous Layered Coding (FLUTE/ALC) protocol. Further suppose the data packet is a product of a VoIP (Voice over Internet Protocol) session. The data packet thus has to be formatted in accordance with the RTP in Layer5.

Time sensitive data packets, such as the data packet resulted from the RTP in Layer5, need to be processed in real time. Specifically, defective packets are not normally resent but instead simply dropped so as not to obstruct transmissions of other oncoming data packets. RTP data packets are therefore normally carried via the User Data packet Protocol (UDP) in Layer4, the transport layer. Accordingly, the data packet from the RTP in Layer5has further to be formulated in accordance with the UDP in Layer4.

On the other hand, if the data packet originates from other protocols in the Layer5, such as the FTP, the data packet is normally sent via the Transport Control Protocol (TCP) in Layer4. Under the TCP, accurate delivery of the data packet is of prime importance. As such, defective packets are always resent, albeit possibly slowing down the overall data transmission process.

Data packets after passing through this transport layer, Layer4, are added with information such as the source and destination port numbers.

The data packet after going through the transport layer, Layer4, is then sent to the network layer, Layer3, for processing. In this particular case, the resultant data packet from Layer4has to be formatted again in accordance with the IP, for instance, with the source and destination addresses of the data packet added.

Thereafter, the data packet has to be framed to fit into whatever protocol is applicable in the link layer, Layer2. For example, if the server node48is connected to the network via the Ethernet, then Layer2would be in the form of a Ethernet protocol, as set forth in the document no. IEEE 802.3, published by the Institute of Electrical and Electronics Engineers (IEEE).

The bottom-most layer of the protocol stack72inFIG. 5is the physical layer, Layer1, which deals with the physical implementation of the transmission for the data packet. For example, inFIG. 2, if the communication link between the node48and the network42is a conventional wire link, then the physical layer, Layer1, concerns with hardware circuitry on both the nodes48and the interface circuitry of the network42. As another example, inFIG. 2, if the communication link between the node50and the BS66A is the air interface. In that case, the physical layer, Layer1, relates to the air space and the hardware circuitry of the RAN52transceiving signals via the air space.

Reference is now returned toFIG. 3. As for a data packet received by the exemplary node50(FIG. 2), the data packet has to be processed through the same protocol stack72but in the reverse order, that is, from Layer1to Layer5.

The operations of an exemplary broadcast process in the system40is herein described. InFIG. 2, as mentioned earlier, it is assumed that the node48, i.e., the BSD, is installed in the network42by the service provider providing broadcast services to subscribers in which the node50is one of such subscribers. For example in this case, the node50may be roaming from another network to the network44and seeks access of a news clip, for instance, the 7:00 p.m. news available from the service provider operating the network42.

If the network44supports broadcast services, oftentimes, the network44maintains a broadcast channel for the available services. The information for the available services can be organized in the form of a downloadable file. Alternatively, the same information can be presented in the form of a constant stream of real-time viewable data.

Suppose in this exemplary embodiment, the available services are grouped together as a downloadable file in a manner similar to the broadcast Service Guide (SG), as promulgated by the Open Mobile Alliance (OMA), a consortium of various entities in the wireless industry, including service providers, hardware and software vendors, and network operators, etc., for purpose of unifying the various standards in wireless communications. Details of the SG are set forth in a publication published by the OMA, OMA-TS-BCAST-Service-Guide-V1.

Heretofore, while in the network44, the user of the node50needs to refer to the SG for the available services. For that purpose, the SG has to be downloaded from the network44. The user of the node50then selects the sought service from the SG and thereafter tunes to the channel carrying the service, as provided in the SG.

For some services, such as downloading of music, the user of the node50can download the sought files first and enjoy the downloaded files later. For other services, such as a news broadcast session, contents of the sought files are downloaded and presented more or less simultaneously. That is, the sought service is presented in real time, so is the download of the files associated with the service. There are several drawbacks associated with such an approach. Among other things, since a successful presentation of the file content depends on the successful download not only of the content itself, but also the successful download of the file attributes needed to process the content files. Such dependence unavoidably introduces delays and often negatively affects the user's experience associated with the content presentation. In addition, to better assure reliable data packet reception, redundant data are normally sent. Consequently, it may not result in the most efficient use of available communication resources, as explained further below.

Suppose the content of the files of the sought services are transported via the FLUTE/ALC protocol. To ensure accurate data transport, conventionally, the Carousel File Distribution (CFD) method is used in conjunction with the FLUTE/ALC protocol.FIG. 3Ashows a more detailed schematic representation of the FLUTE/ALC protocol and will be further discussed later.FIG. 4shows the methodology of the CFD scheme operating under the FLUTE/ALC protocol.

InFIG. 4, a file is signified by the reference numeral74. A piece of multimedia content, such as the news clip in this example, may comprise a multiple number of files. In the file74, each ALC data packet is signified by one of the data packets #1-#5. Associated with the delivery of each file74is an ALC data packet containing a file delivery table (FDT)78, which is also configured in the ALC protocol format.

In the FDT78, various parameters or attributes needed to decode the data packets #1-#5are included. Such parameters may comprise, but not limited to, the file name, the file identification (ID), source location of the file (i.e., the URI), the presentation time, the file size, the content type, the encoding scheme, the forward error correction (FEC) type and the FEC-related parameters, and security-related parameters, if applicable.

Under the CFD method, a file is transmitted multiple times. In this example, the file74which includes the content packets #1-#5along with the associated FDT78, are transmitted first time in the first pass73, and then a second time in a second pass75. In the first pass73, the FDT78is transmitted ahead of the content packets #1-#5. In the second pass75, the same FDT78is transmitted at the end of the content packets #1-#5.

One purpose of transmitting each file repeatedly is to eliminate the requirement that all receivers be properly time-aligned to receive the file. That is, there is no need to synchronize the receivers for purpose of receiving the file.

The other reason for transmitting each file repeatedly is to ensure accuracy during data transport, in the event that when there is no FEC scheme installed, or even if installed, the FEC mechanism fails to operate. To accomplish this end, the CFD method is designed to encompass three scenarios, as identified by Scenarios A, B and C shown inFIG. 4. Beyond the three Scenarios A, B and C, a failed file download can be declared.

In Scenario A, suppose the node50tries to download the file74. During the first pass73, the node50needs to successfully receive the FDT78. Assume the download of the FDT78in the first pass73is successful without error. Then the node50receives the subsequent data packets #1-#5. Assume the download of all the data packets #1-#5in the first pass73is also successful. Using the information in the downloaded FDT78from the first pass73, the node50can decode the data in all the packets #1-#5for the assembly of the entire file74.

In Scenario B, during the download of the file74in the first pass73, suppose retrieval of the FDT packet78is successful. Retrieval of all the content packets #1-#5in the first pass is also successful except the data packet #3. Suppose the implemented FEC mechanism does not function. In that case, the node50has to wait until the second pass75to receive the identical data packet #3during the second pass75to compensate for the corresponding defective packet #3received in the first pass73. Thereafter, using information from the FDT78obtained from the first pass, the node50can decode all the data packets for the reconstruction of the file74.

In Scenario C, the node fails to correctly receive the FDT78in the first pass73, even though all the data packets #1-#5are correctly downloaded in the first pass73. In that case, the node50has to wait until the second pass75to retrieve the corresponding FDT78to compensate for the erroneous FDT78from the first pass73for the correct decoding of all the data packets of the file74.

Under unfavorable signal reception conditions, the extra steps implemented on the top of the FEC as described above in Scenarios A, B and C may not be able to correct any corrupt data. That is, as mentioned earlier, the download of the file74can be declared a failure. In Scenario B, the loss of the data packet #3may only affect the quality of the file74during presentation. However, in Scenario C, the unsuccessful retrieval of the FDT78may result in the loss of the entire file74, because without the FDT78, the whole file74cannot be processed. In that case, the node50may have to wait until the next carousal cycle, which can be many time periods, such as the time periods extended by the time passes73and75, down the road merely to have another chance for the acquisition of the FDT78. Should that occur, additional time delay and tying up of communication channels are unavoidable. If the device50is a mobile device, as in this example, extra time delay translates into additional power consumption in the battery of the device50. In mobile communications, preservation of battery life is of significant importance.

In accordance with the exemplary embodiment of the invention, the FDTs and the content data packets are not received in-band as conventionally practiced. Instead, the file attributes and the content data are received out-of-band, as will be described later.

Hereinafter, the term “in-band” is construed to mean transport of information through the same transmission channel and further substantially within the same transmission session. An example of an in-band information transport is as shown and described in the transmission process ofFIG. 4. On the other hand, the term “out-of-band” is construed to mean transport of information through different transmission sessions, irrespective of whether such a transport is through the same transmission channel or a different transmission channel, as exemplified by the transmission process shown inFIG. 5and as described below.

Reference is now referred toFIG. 5. In this embodiment, the file attributes82, such as the file attributes included in the FDTs78as mentioned previously, are transmitted separately, i.e., out-of-band instead of in-band, as compared to the payload data, such as the data packets #1-#5.

Preferably, the FAs are transmitted by the network44(FIG. 2) and in a broadcast channel. For example, the FAs can be part of the SG as mentioned earlier. The SG and thus the FAs are first acquired by the node50which seeks the broadcast service. That is, the FAs82are acquired during a first communication session81. After the correct retrieval of the FAs82, the node50may then tune to the channel according to the information provided in the SG to acquire the content files, such as the file84. That is, the content files are acquired during a second communication session86. As shown inFIG. 5, there are no FDTs interposed with the content file packets. Rather, the content files (e.g., the files83and84) are designedly to be continuously and uninterruptedly transmitted. Phrased differently, the content files are downloaded during the communication session86only after it is assured that the node50has correctly retrieved the FAs82earlier during the communication session81. Consequently, the situation where the successful processing of a file is at the mercy of a successful download of the corresponding FDT, when both the file and the FDT are received in-band and as described above can be avoided.

During the transmission process, if a defective data packet, for example the data packet #4in the file84during the first pass85and is denoted by the reference numeral90inFIG. 5, is found, and further suppose the installed FEC mechanism fails to correct the defective packet #4, the corresponding data packet #4in the second pass87can be retrieved for repair. If the repair process is not successful, there may be a certain degradation of quality of the file84during presentation. However, the situation as in the failed Scenario C shown inFIG. 4and as described above can never occur. The reason is the FAs82have been successfully received earlier during the communication session81, as earlier stated.

Operating in the manner as described above, there is no need to tie up any in-band channels for the transmission of the FDTs. Content file retrieval can thereby be executed with more certainty. File acquisition time can also be substantially curtailed. Consequently, congestion among communication channels can be eased, which in turn can result in more efficient use of available communication resources. Furthermore, if the node50(FIG. 2) is a mobile device, shorter file acquisition time means shorter time needed to wake up the battery of the node50during the download of the content files. Accordingly, battery power can be conserved.

It further should be noted that the FA82shown inFIG. 5is one among many FAs needed to be acquired for the proper decoding of all the files for the sought service session, in which the file84is one of such files. However, the FA82has many common attributes for the retrieval of not only the file84but also for other files, such as the neighboring file83. Accordingly, all the FAs can be organized as one master FA suitable for file retrieval of all files in a transmission session. As an alternative, instead of a master FA, an aggregated FA can be divided into two portions. The first portion can hold file attributes that are considered long-lived. Such attributes may include the file name, the file ID, the file location, the presentation time, and the distribution time window. On the other hand, attributes that are deemed relatively short-lived can be placed in the second portion of the FA. Short-lived attributes may include the application file size, the transmitted file size, the content type, the encoding scheme, the FEC-type and parameters, and the security-related parameters. The first portion can remain in the SG relatively unchanged over time. The second portion can be updated periodically in the SG to reflect the changing conditions.

As mentioned earlier, some files can be downloaded first and later executed by the user at a time chosen by user. Examples are music files and files for software updates. Other files can be downloaded first but preferred to be presented at a specific time. An example is a news broadcast session as will be described below. In either case, in accordance with another aspect of the invention, content file acquisition and presentation need not be carried out simultaneously. Instead, file acquisition can be executed separately and ahead of the file presentation process.

For ease of explanation, a more specified example is illustrated. Reference is now returned toFIG. 2. Suppose in this example, the user of the node50wants to watch a news broadcast normally available at 7:00 p.m via regular television broadcast. In the SG broadcasted by the network44, associated information concerning the 7:00 p.m. news clip is usually available. The network44has such information from the service providing network42via the backbone network46. In the SG, it may specify two time windows, namely, a “distribution window (DW)” and a “presentation window (PW).”FIG. 6shows such an arrangement.

In the DW, a time window is specified in which the node50needs to be activated in order to receive the files for the 7:00 p.m. news session. For instance, in this example, from 5:00 p.m. to 6:30 p.m., that is the time intervals during which the node50can be powered on to receive the news files. On the other hand, the PW identified the presentation time of the downloaded news session, in the example, from 7:00 p.m. to 7:30 p.m. That is, during this time span, the downloaded files will be presented as the 7:00 p.m. news. An additional benefit of separating the DW from the PW is allow subscribers to download files in advance of the presentation time so as to avoid traffic channel overloading during presentation times which normally coincide with peak hours. Even in the event of heavy traffic load in the network44during the DW, individual file downloads can still be slowly trickled down to their respective receivers and be completed well before the start of the PW.

Based on the information provided by the SG, suppose the node50is powered on and activated during the time period from 5:25 p.m. to 5:37 p.m. for the receipt of news clip. The time required for the download, in this example 12 minutes, can be shorter than the time for presentation, in this case 30 minutes, if appropriate file compression techniques are implemented.

The aforementioned method for the node50are shown in the flowcharts ofFIG. 7.FIG. 8shows the corresponding method practiced by the network44.

In accordance with yet another aspect of the invention, transport of payload data can further be streamlined.

For the download of the file content, the FLUTE/ALC protocol may be employed. As mentioned earlier, unlike the FTP in which data packets are transported via the TCP transport layer (FIG. 3), data packets in the FLUTE/ALC are carried over the UDP transport layer. The FTP is geared more toward one-to-one applications and erroneous packets are normally retransmitted, albeit slowing down the overall transmission process. The FLUTE/ALC protocol carried via the UDP is designed to be suitable for multicast or broadcast applications. Erroneous data are not normally retransmitted. Instead, errors in data transmissions are curtailed by employing appropriate forward error correction (FEC) schemes.

Reference is now made toFIG. 3A, which schematically shows the FLUTE/ALC protocol generally signified by the reference number96. Data packets for the FLUTE protocol are transported carried by the ALC protocol. The ALC protocol is set forth in the publication RFC 3450, published by the IETF, entitled “Asynchronous Layered Coding (ALC) Protocol Instantiation” December 2002. The ALC protocol is one of the basic protocols proposed for multicast transport. Data transport involving ALC requires no uplink signaling, i.e., signaling from the receiver to the transmitter, and employs the use of FEC for reliable data retrieval. The ALC also utilizes the Layered Coding Transport (LCT) building block98for multi-rate congestion control (CC)97and the FEC building block99for reliable content delivery. The LCT is described in the IETF publication, RFC 3451, entitled “Layered Coding Transport (LCT) Building Block,” December 2002. The FEC is described in RFC 3453, also published by the IETF.

The FLUTE protocol represents an application of the ALC for multicast file delivery. However, the conventional FLUTE/ALC protocol is primarily designed for non-mobile environments. In a wireless environment where battery power needs to be conserved and air-link bandwidths are precious, the file download process can further be streamlined. To accomplish this end, each data packet in the payload can be designed to be more compact.

FIG. 9shows an exemplary compact ALC data packet, identified by the reference numeral94, which is formatted to be more in compliance with the conventional ALC packet as specified in RFC 3450. The ALC packet format94is designedly to be identical to the broad/multicast service (MBMS) as promulgated by the 3GPP2 in a published document 3GPP TS 23.346. The main difference between the format as shown in the data packet84and that as specified in the document 3GPP TS 23.346 is the absence of any in-band transmission of file description information, i.e., the file attributes needed to process the payload of the data packet94.

FIG. 10shows another exemplary compact packet format signified by the reference numeral96. The data packet96is substantially streamlined and is suitable for use in a wireless communication environment. Among other things, the congestion control information is dispensed with. As in a wireless environment, the wireless medium is the sole access means, congestion control for regulating multiple access means at different data rates need not be necessary. In the data packet94shown inFIG. 9, the overhead is 16 bytes. As for the data packet96shown inFIG. 10, the overhead is only 8 bytes.

FIG. 11schematically shows the part of the hardware implementation of an apparatus, such as the node50shown inFIG. 2, signified by the reference numeral100in accordance with the exemplary embodiment of the invention. The apparatus100can be built and incorporated in various forms, such as a laptop computer, a PDA, or a cellular phone, to name just a few.

The apparatus100comprises a central data bus102linking several circuits together. The circuits include a CPU (Central Processing Unit) or a controller104, a receive circuit106, a transmit circuit108, and a memory unit110.

If the apparatus100is part of a wireless device, the receive and transmit circuits106and108can be connected to a radio frequency (RF) circuit but is not shown in the drawing. The receive circuit106processes and buffers received signals before sending out to the data bus102. On the other hand, the transmit circuit108processes and buffers the data from the data bus102before sending out of the device100. The CPU/controller104performs the function of data management of the data bus102and further the function of general data processing, including executing the instructional contents of the memory unit110.

Instead of separately disposed as shown inFIG. 11, as an alternative, the transmit circuit108and the receive circuit106can be parts of the CPU/controller104.

The memory unit110includes a set of instructions generally signified by the reference numeral101. In this embodiment, the instructions include, portions such as the protocol stack function112capable of processing, among other things, the FULTE/ALC protocol as described above. The set of instructions also include a broadcast client function114capable of executing the method as shown and described inFIG. 7.

In this embodiment, the memory unit110is a RAM (Random Access Memory) circuit. The exemplary instruction portions112and114are software routines or modules. The memory unit110can be tied to another memory circuit (not shown) which can either be of the volatile or nonvolatile type. As an alternative, the memory unit110can be made of other circuit types, such as an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM (Electrical Programmable Read Only Memory), a ROM (Read Only Memory), an ASIC (Application Specific Integrated Circuit), a magnetic disk, an optical disk, and others well known in the art.

FIG. 12schematically shows the part of the hardware implementation of a broadcast server, such as the BSN apparatus70shown inFIG. 2and is signified by the reference numeral120. The apparatus120comprises a central data bus122linking several circuits together. The circuits include a CPU (Central Processing Unit) or a controller124, a receive circuit126, a transmit circuit128, a data base storage unit129, and a memory unit131.

The receive and transmit circuits126and128can be connected to a network data bus (not shown) where the apparatus120is linked to. The receive circuit126processes and buffers received signals from the network data bus (not shown) before routing to the internal data bus122. The transmit circuit128processes and buffers the data from the date bus122before sending out of the apparatus120. Alternatively, the transmit circuit128and the receive circuit126can be collectively called the interface circuit. The CPU/controller124performs the duty of data management of the data bus122and for the function of general data processing, including executing the instructional content of the memory unit131. The database storage unit129stores data, such as the SGs with their various parameters and the content files.

The memory unit131includes a set of instructions generally signified by the reference numeral121. In this embodiment, the instructions include portions, among other things, a protocol stack132and a broadcast host134. The memory unit131can be made of memory circuit types as mentioned above and are not further repeated. The functions for the protocol stack121and the broadcast host134include the instructional sets in accordance with the invention such as shown inFIGS. 3 and 8and as described previously.

It should further be noted that the processes as described and shown inFIGS. 7 and 8above can also be coded as computer-readable instructions carried on any computer-readable medium known in the art. In this specification and the appended claims, the term “computer-readable medium” refers to any medium that participates in providing instructions to any processor, such as the CPU/controller104and124shown and described inFIGS. 11 and 12, respectively, for execution. Such a medium can be of the storage type and may take the form of a volatile or non-volatile storage medium as also described previously, for example, in the description of the memory units110and131inFIGS. 11 and 12, respectively. Such a medium can also be of the transmission type and may include a coaxial cable, a copper wire, an optical cable, and the air interface carrying acoustic or electromagnetic waves capable of carrying signals readable by machines or computers.

Finally, described in the embodiment, the node the BSD48is described as installed in the network42of the service provider. This may not always be the case. It is possible that the BSD48be installed in another network not owned by the service provider. Moreover, out-of-band transmission channels as described in the exemplary embodiment can be distinguished either logically or physically, as commonly practiced in the art of spread-spectrum communications. In addition, the different out-of-band sessions can be identified by different port numbers, other than time separations as aforementioned. Thus, for instance, inFIG. 5, the FDTs can be transmitted under over the UDP of Layer4(FIG. 3) via one destination port corresponding to the first transmission session. The content files can be transmitted over the UDP of Layer4via another destination port number during the second transmission session. In addition, it should also be clear that the flow chats inFIGS. 7 and 8also apply to downloading and executing of files at the user's choice, such as a musical file. For example, the user can glean from the SG and determines on his or her own the file distribution and file presentation windows. Furthermore, described in the exemplary embodiment, the backbone network is depicted as operated under the IP. Other protocols other than the IP are possible. For example, in a FLO network, the protocol according to the document, floforum2005.001, entitled “FLO Air Interface Specification” published by the FLO Forum, would be applicable. In the FLO network, instead of the SG, the corresponding file attributes can be put in the System Information (SI), details of which can be found in the document floforum2006.005, published by the FLO Forum. In addition, any logical blocks, circuits, and algorithm steps described in connection with the embodiment can be implemented in hardware, software, firmware, or combinations thereof. It will be understood by those skilled in the art that theses and other changes in form and detail may be made therein without departing from the scope and spirit of the invention.