HK1114982A1 - Method and apparatus for enhanced file distribution in multicast or broadcast - Google Patents

Abstract

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.

Description

Method and apparatus for enhanced file distribution in multicast or broadcast

Claim priority under 35 U.S.C § 119

This patent application claims priority from U.S. provisional application No. 60/669,505 entitled "Method and Apparatus to enhanced file distribution for Mobile Broadcast Applications", filed on 8.4.2005, which is assigned to the assignee of the present invention and is expressly incorporated herein by reference.

Technical Field

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

Background

The global network interconnection enables rapid access to information regardless of geographic distance. Fig. 1 shows a simplified schematic diagram of a global network connection, generally referred to as the internet, represented by reference numeral 20. The internet 20 is essentially a number of networks having different levels of hierarchy linked together. The internet 20 operates under the Internet Protocol (IP) promulgated by the Internet Engineering Task Force (IETF). Details of the IP may refer to Request for comments (RFC) 791 issued by the IETF.

Connected to the internet 20 are various individual networks, sometimes referred to as Local Area Networks (LANs) or Wide Area Networks (WANs), depending on the network size. Some such networks 22, 24, and 26 are shown in fig. 1.

Within each of networks 22, 24, and 26, there may be various pieces of equipment connected to and in communication with each other. Just a few examples are computers, printers, and servers, which are commonly referred to as nodes. When a node communicates outside its own network via the internet 20, the node needs to send data packets to corresponding nodes in other networks under IP. Similarly, packets sent out by corresponding nodes in other networks to the originating node must also conform to IP.

Different types of applications necessitate different levels of protocols to operate in conjunction with IP. To illustrate a few examples. Assume that a node 28 in the network 22 attempts to download a file from another node 30 in the network 26. For file transfers, a higher level protocol known as File Transfer Protocol (FTP) is used very often. FTP is referred to RFC959 issued by the IETF. As such, the data packets sent by node 30 to node 28 must conform to, among other things, FTP and IP.

As another example, assume a node 28 in the network 22 browses a website, proposed by another node 32 in the network 24, via the Internet 20. At this point, nodes 28 and 32 may use another higher level protocol, referred to as the hypertext transfer protocol (HTTP). HTTP may refer to RFC 2616 issued by IETF. Also, the exchanged data packets must comply with HTTP and IP, among other things.

The exemplary protocols FTP and HTTP are carried via another intermediate level protocol known as the Transmission Control Protocol (TCP). TCP may refer to RFC 793. Under TCP, the goal is to transmit data accurately. In this way, erroneous data is always retransmitted. TCP and protocols that rely on TCP (e.g., FTP and HTTP) are commonly used for one-to-one applications.

Technological advances have made data-intensive data transfers possible. For example, networks capable of handling high bandwidth allow multimedia file exchanges, such as audio and video files that typically hold large amounts of data. File delivery via conventional unicast methods may be inefficient when a large number of nodes receive the multimedia file. The files, among other things, need to be first copied and then individually transferred to each node. Accordingly, there is a need to develop other types of protocols suitable for broadcast or multicast services to address the increased need for one-to-many applications.

To meet this need, the file delivery over unidirectional transport (FLUTE) protocol has been designed specifically for multicast file distribution applications. The FLUTE protocol may refer to RFC 3926 entitled "FLUTE-FILeDelivery over Universal Transport" issued by the IETF on 11/14/2003. In multicast sessions, the traffic flow is more or less unidirectional. That is, reverse data traffic is limited, if at all. Such one-way use is common in broadcast or multicast applications where there is one communication source that sends data to many receivers.

Data transported under the FLUTE protocol is carried over the User Datagram Protocol (UDP), rather than TCP as in the HTTP and FTP protocols. Under UDP, erroneous data is not typically retransmitted. For accurate data transmission, the FLUTE protocol typically transmits data in a redundant manner and uses an error correction scheme.

Using the FLUTE protocol, one or more files are transferred during a file delivery session. The file is carried in data packets in the form of Asynchronous Layered Coding (ALC), called ALC packets. Depending on the file length, each file may be transmitted in one or more ALC packets. The file is called an object. Objects may be identified by file attributes contained in a File Delivery Table (FDT). At the receiver side, the original file is reconstructed from the ALC packets depending on the file properties. The received file object may not be processed until the corresponding file attribute is correctly received. To achieve higher reliability of FDT reception, replicated FDT instances (instances) are typically inserted with payload data in ALC packets sent to the receiver. To this end, the FDT and the content file are transmitted more or less simultaneously. As such, even if the content file is received correctly (which is not typically the case), the receiver needs to receive the FDT correctly, extract the file attributes from the FDT, and then process the received content file. I.e. successful decoding and subsequent rendering of the received file depends more or less simultaneously on the successful downloading of the file attributes needed to process the ALC package. Such dependencies inevitably lead to delays and often adversely affect the quality of the content presentation. In addition, users who do not have the correct file attributes very often make multiple attempts to obtain the desired file attributes, thereby testing the communication channel type. This may therefore not be the most efficient use of the available communication resources.

Therefore, there is a need to provide more efficient schemes for better quality broadcasts and additionally a need to more economically utilize communication resources.

Disclosure of Invention

In a communication system providing a broadcast service, files for broadcasting in the broadcast service are accessible to a user. The content of the broadcast file is transmitted in one communication session. The file attributes required for processing the broadcast file are separately transmitted in another communication session. According to the configuration, receiving the file attribute before the content file enables more efficient download and processing of the broadcast file.

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

Drawings

FIG. 1 is a schematic diagram of a global network connection;

FIG. 2 is a schematic diagram of a node and network included in an exemplary embodiment of the invention;

FIG. 3 is a schematic diagram of a protocol stack showing hierarchical levels;

FIG. 3A is a more detailed schematic representation of the FLUTE protocol;

FIG. 4 is a schematic diagram showing one set of methods of the CFD method operating under the FLUTE protocol;

FIG. 5 is a schematic diagram showing a CFD method operating in accordance with an exemplary embodiment of the present invention;

FIG. 6 is a timing diagram showing file transfers and presentations performed during different time windows;

FIG. 7 is a flowchart showing file retrieval and processing according to an exemplary embodiment of the present invention;

FIG. 8 is a flowchart showing file transfer according to an exemplary embodiment of the present invention;

FIG. 9 is a schematic diagram showing an exemplary compact ALC data packet;

FIG. 10 is a schematic diagram showing another compact package format suitable for file transfer via wireless communication;

FIG. 11 is a schematic diagram of a portion of circuitry of a node configured to receive and process broadcast files in accordance with an exemplary embodiment of the present invention; and

FIG. 12 is a schematic diagram of a portion of circuitry of a node configured to communicate broadcast files in accordance with an exemplary embodiment of the invention.

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 will be appreciated that one of ordinary skill in the art will realize that the invention may be practiced without the use of these specific details. In other instances, well-known structures and processes are not described in detail in order to avoid obscuring the description of the present invention with unnecessary detail. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Fig. 2 shows a simplified schematic diagram of an exemplary embodiment of the present invention. The overall system is generally referred to by the reference numeral 40. In communication system 40, only two networks 42 and 44 are shown for simplicity and clarity of illustration. The networks 42 and 44 are linked by a backbone network 46, such as an intranet or the internet.

It is assumed that in this embodiment, the network 42 is operated by a service provider. The service provider installs a node 48 in the network 42. In this example, node 48 is referred to as a Broadcast Service Distributor (BSD). The content server 48 may be designed to hold broadcast content and associated broadcast information provided by the service provider.

In the network 44, there is a subscriber node 50 that is capable of receiving services, including services provided by the server node 48 via the backbone network 46. In this embodiment, node 50 is depicted as a wireless device, such as a Personal Digital Assistant (PDA), mobile computer, or cellular telephone, to name a few examples. The network 44 supports wireless technologies such as the cdma2000 standard set forth by 3GPP2 (third generation partnership project 2), where 3GPP2 is an association of several international standards bodies, including the TIA/EIA (telecommunications industry association/electronic industry association) in the united states. It should be noted that the network 40 may also support other standards, such as the WCDMA (wideband code division multiple access) standard promulgated by 3GPP (third generation partnership project), which is coordinated and supported by different european standards bodies. Another example is the standard developed by the Forward Link (FLO) forum, which is an association of various agencies in the wireless industry that facilitates standardization for use in FLO networks.

Subscriber unit 50 communicates with network 44 via a Radio Access Network (RAN) 52. The RAN 52 includes a base station controller/packet data control function (BSC/PDF)54 connected to a plurality of Base Stations (BS)66A through 66N. In the network 44, a Packet Data Serving Node (PDSN)68 and a Broadcast Serving Node (BSN)70 are constructed. Both the PDSN 68 and the BSN70 provide the functionality to interface between the backbone network 46 and the RAN 52 in the network 44. The BSN70 is installed more for multicast or broadcast use, while the PDSN 68 mostly handles unicast applications. In this specification, the terms multicast and broadcast are used interchangeably.

In the network 44, there is another server, referred to as a broadcast multicast service (BCMCS) content server 63, connected to the BSN 70. Typically, the BCMCS content server 63 pre-stores broadcast content and data related to the broadcast content, including data provided by the content server 48 and communicated via the backbone network 46.

In an exemplary embodiment, communications between certain nodes are depicted as being performed wirelessly. It should be understood, however, that this need not always be the case. Non-wireless communication via various other means between those nodes is also applicable. For example, instead of a wireless device, the node 50 may be a fixed computer or another server in communication with the network 44 via an optical link or a conventional conductive cable.

Assume in this embodiment that backbone network 46 supports Internet Protocol (IP). Before describing the operational details, it is necessary to first explain generally the processing of data packets during packet data communications via various levels of protocols of different hierarchies, and their interrelationships under IP.

In network communication technologies, protocols are layered according to the Open Systems Interconnection (OSI) model as set forth by the international organization for standardization (ISO) and the international telecommunication union-telecommunication standards sector (ITU-T). This is intended to facilitate interoperability of multi-vendor equipment. That is, each level of the protocol hierarchy has its own specification. Thus, as long as the specification of a particular hierarchical level is met, development of the level product is guaranteed to be compatible with other levels of other products.

Fig. 3 schematically shows a stack of protocols of a hierarchical level, which is commonly referred to as a "protocol stack", and is generally represented by reference numeral 72. The IP protocol stack 72 is constructed in accordance with the Internet Engineering Task Force (IETF) model, which is similar to, but not exactly the same as, the OSI model. According to the IETF model, the IP protocol stack 72 has five layers, starting from layer 1 to layer 5. Thus, data packets issued by a node (such as node 48 or 50 shown in fig. 2) must be processed through the protocol stack 72. The protocol stack 72 is built into the node in the form of software or hardware or a combination thereof. Similarly, data packets received by the same node must be processed through the same protocol stack 72 but in reverse order.

Take an example for illustration. Assuming that a data packet is processed so as to originate from a node, such as node 48 (fig. 2), the data packet is first established according to one of the protocols in the application layer, i.e., layer 5. Layer 5 includes hypertext transfer protocol (HTTP), Service Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), real-time transport protocol (RTP), and file delivery over unidirectional transport/asynchronous layered coding (FLUTE/ALC) protocols. Assume further that the data packet is the product of a VoIP (voice over internet protocol) conversation. The data packets must be formatted according to RTP in layer 5.

Time sensitive data packets, such as those generated according to RTP in layer 5, need to be processed in real time. In particular, defective packets are typically not resent but simply discarded in order to avoid blocking the transmission of other upcoming data packets. RTP packets are therefore typically carried via the User Datagram Protocol (UDP) in layer 4 (transport layer). Therefore, packets from RTP in layer 5 must be explicitly represented further from UDP in layer 4.

On the other hand, if the data packet originates from another protocol in layer 5, such as FTP, the data packet is typically sent via the Transmission Control Protocol (TCP) in layer 4. Under TCP, correct delivery of data packets is of utmost importance. In this way, the defective packet is always retransmitted, although the entire data transmission process may be slowed down.

The packet after passing through this transport layer (layer 4) is added with information such as source and destination port numbers.

The data packet is then sent to the network layer (layer 3) for processing after passing through the transport layer (layer 4). In this particular case, the resulting data packet from layer 4 must be reformatted according to IP (e.g., according to the source and destination addresses of the added data packet).

The packet must then be constructed to fit whatever protocol is applicable in the link layer (layer 2). For example, if the server node 48 is connected to the network via Ethernet, layer 2 would be in the form of an Ethernet protocol as set forth in IEEE 802.3 publication issued by the Institute of Electrical and Electronics Engineers (IEEE).

The bottom layer of the protocol stack 72 in fig. 5 is the physical layer (layer 1), which handles the physical implementation of packet transmission. For example, in fig. 2, if the communication link between the node 48 and the network 42 is a conventional wired link, the physical layer (layer 1) is concerned with both the hardware circuitry on the node 48 and the interface circuitry of the network 42. As another example, in fig. 2, if the communication link between node 50 and BS 66A is an air interface. In this case, the physical layer (layer 1) is associated with the air space and the hardware circuits of the RAN 52 that transceive signals via the air space.

Reference is now made back to fig. 3. For a data packet received by the exemplary node 50 (fig. 2), the data packet must be processed through the same protocol stack 72 but in reverse order (i.e., from layer 1 to layer 5).

The operation of an exemplary broadcast process in system 40 is described herein. In fig. 2, it is assumed that node 48 (i.e., the BSD) is installed in network 42 by a service provider that provides broadcast services to subscribers, of which node 50 is one, as previously mentioned. In this case, for example, the node 50 may roam from another network to the network 44 and seek access to a news clip, such as 7:00p.m. news available from a service provider operating the network 42.

If the network 44 supports broadcast services, the network 44 often maintains a broadcast channel for the available services. The information of the available services may be organized in the form of downloadable files. Alternatively, the same information may be presented in the form of a continuous stream of real-time visual data.

It is assumed in this exemplary embodiment that the available services are aggregated into a downloadable file in a manner similar to a broadcast Service Guide (SG) published by the association Open Mobile Alliance (OMA), which includes various entities in the wireless industry, service providers, hardware and software providers, and network operators, for the purpose of unifying various standards in a wireless communication system. Details of SG are set forth in publications OMA-TS-BCAST-Service-Guide-Vl. & # $ issued by OMA.

To this end, while in the network 44, the user of the node 50 needs to refer to the SG to obtain the available services. For this purpose, the SG must be downloaded from the network 44. The user of node 50 then selects the service sought from the SG and then tunes to the channel carrying the service as provided in the SG.

For certain services (e.g., music download), the user of node 50 may first download the sought file and enjoy the downloaded file at a later time. For other services (e.g. a news broadcast session) the content of the sought file is downloaded and presented more or less simultaneously. I.e. the sought service is presented in real time, as is the file download associated with the service. Said method entails several drawbacks. In particular, because successful presentation of the file content depends not only on successful downloading of the content itself, but also on successful downloading of the file attributes required to process the content file. Such dependencies inevitably lead to delays and often adversely affect the user's experience with the presentation of the content. In addition, to better ensure reliable packet reception, redundant data is typically transmitted. Thus, as explained further below, this may not result in the most efficient use of available communication resources.

It is assumed that the file content of the service sought is delivered via the FLUTE/ALC protocol. To ensure correct data transfer, the disc File Distribution (CFD) method is conventionally used in conjunction with the FLUTE/ALC protocol. FIG. 3A shows a more detailed schematic representation of the FLUTE/ALC protocol, and will be discussed further later. FIG. 4 shows a method of a CFD scheme operating under the FLUTE/ALC protocol.

In fig. 4, reference numeral 74 denotes a file. A piece of multimedia content, such as a news clip in this example, may contain multiple files. In file 74, each of packets #1 through #5 represents an ALC packet. ALC packets containing a File Delivery Table (FDT)78 also configured in ALC protocol format are associated with the delivery of each file 74.

In the FDT 78, various parameters or attributes required for decoding the packets #1 to #5 are included. The parameters may include, but are not limited to, a file name, a file Identifier (ID), a source location of the file (i.e., URI), a presentation time, a file size, a content type, an encoding scheme, a Forward Error Correction (FEC) type, and FEC related parameters, as well as security related parameters, if applicable.

In the CFD method, a file is transmitted multiple times. In this example, the file 74 including the content packets #1 through #5 is transmitted with the associated FDT 78 a first time in a first pass 73 and then a second time in a second pass 75. In the first pass 73, the FDT 78 is transmitted before the content packets #1 to # 5. In the second pass 75, the same FDT 78 is transmitted at the end of the content packets #1 through # 5.

One purpose of repeatedly transmitting each file is to eliminate the need for all receivers to be perfectly time aligned for receiving the file. I.e. there is no need to synchronize the receivers for the purpose of receiving the file.

Another reason for repeatedly transmitting each file is to ensure correctness during data transfer in the event that the FEC scheme is not installed or even if installed, the FEC mechanism cannot operate. To achieve this, the CFD method is designed to include three scenarios as represented by scenarios A, B and C shown in fig. 4. In addition to the three scenarios A, B and C, a failed file download may be announced.

In scenario A, assume that node 50 attempts to download file 74. During the first pass 73, the node 50 needs to successfully receive the FDT 78. Assume that the download of the FDT 78 in the first pass 73 is successful and error free. The node 50 then receives subsequent packets #1 through # 5. Assume that the download of all packets #1 to #5 in the first pass 73 is also successful. The node 50 may use the information in the FDT 78 downloaded from the first pass 73 to decode the data in all packets #1 through #5 for the entire file 74 combination.

In scenario B, during the download of the file 74 in the first pass 73, it is assumed that the retrieval of the FDT package 78 was successful. The retrieval of all the content packets #1 to #5 in the first pass is successful in addition to the data packet # 3. It is assumed that the FEC mechanism implemented does not work. In this case, the node 50 must wait until the second pass 75 occurs before receiving the same data packet #3 during the second pass 75 to compensate for the corresponding defective packet #3 received in the first pass 73. The node 50 may then use the information from the FDT 78 obtained from the first pass to decode all packets for reconstruction of the file 74.

In scenario C, even if all data packets #1 through #5 were downloaded correctly in first pass 73, the node fails to receive the FDT 78 correctly in first pass 73. In this case, the node 50 must wait until the second pass 75 occurs before retrieving the corresponding FDT 78 to compensate for the erroneous FDT 78 from the first pass 73 for correct decoding of all the packets of the file 74.

Under unfavorable signal reception conditions, the additional steps performed on top of the FEC as described above in scenarios A, B and C may not be able to correct any erroneous data. That is, as previously mentioned, a failure to download the file 74 may be notified. In scenario B, the loss of packet #3 may only affect the quality of file 74 during presentation. However, in scenario C, unsuccessful retrieval of the FDT 78 may result in the loss of the entire file 74, since the entire file 74 may not be processed without the FDT 78. In this case, the node 50 may have to wait until the next carousel cycle occurs, which may be many time periods, such as the time periods extended by the time passes 73 and 75, simply to have another chance to obtain the FDT 78. If this happens, additional time delays and communication channel occupancy are unavoidable. If the device 50 is a mobile device as in this example, the additional time delay translates into additional power consumption of the battery of the device 50. In mobile communications, maintenance of battery life is extremely important.

According to an exemplary embodiment of the invention, the FDT and the content data packets are not received within the frequency band as conventionally practiced. In fact, as will be described later, the file attributes and content data are received out-of-band.

Hereinafter, the term "in-band" is to be interpreted to mean the transfer of information via the same transmission channel and further substantially within the same transmission session. An example of in-band information transfer is shown and described in the transmission process of fig. 4. On the other hand, the term "out-of-band" is to be interpreted as meaning the transfer of information via different transmission sessions, irrespective of whether the transfer passes through the same transmission channel or different transmission channels, as exemplified by the transmission procedure shown in fig. 5 and described below.

Reference is now made to fig. 5. In this embodiment, the file attributes 82 (e.g., the file attributes previously mentioned as being included in the FDT 78) are transmitted separately, i.e., out-of-band rather than in-band, as compared to the payload data (e.g., packets #1 through # 5).

Preferably, the FA transmits via the network 44 (fig. 2) and in a broadcast channel. For example, the FA may be part of the SG mentioned previously. The SG and thus the FA are first obtained by the node 50 seeking broadcast service. That is, the FA 82 is obtained during the first communication session 81. After properly retrieving the FA 82, the node 50 may then tune to the channel to obtain a content file (e.g., file 84) according to the information provided in the SG. That is, the content file is obtained during the second communication session 86. As shown in fig. 5, there is no FDT inserted with the content file package. In fact, the content files (e.g., files 83 and 84) are designed to be transmitted continuously and uninterruptedly. In other words, the content file is downloaded during communication session 86 only after confirming that node 50 has correctly retrieved FA 82 earlier during communication session 81. Thus, situations can be avoided where successful processing of a file is dominated by successful downloading of the respective FDT when both the file and the FDT are within the frequency band and received as described above.

During the transmission process, if a defective packet is found (e.g., packet #4 in file 84 during first pass 85, and represented by reference numeral 90 in fig. 5), and further assuming that the installed FEC mechanism fails to correct defective packet #4, the corresponding packet #4 in second pass 87 may be retrieved for repair. If the repair process is unsuccessful, there may be some degradation in the quality of the file 84 during presentation. However, the situation in failure scenario C as shown in fig. 4 and as described above may never occur. The reason is that the FA 82 has been successfully received earlier during the communication session 81 as stated previously.

Operating in the manner as described above, there is no need to occupy any in-band channel for FDT transmission. Whereby the content file retrieval can be performed more surely. File acquisition time may also be substantially reduced. Thus, congestion in the communication channel may be mitigated, which in turn may result in more efficient use of available communication resources. Additionally, if the node 50 (FIG. 2) is a mobile device, a shorter file acquisition time means less time is required to wake up the battery of the node 50 during the downloading of the content file. Thus, battery power can be saved.

It should be further noted that the FA 82 shown in fig. 5 is one of many FAs required to be obtained for properly decoding all files of the sought service session, of which the file 84 is one. However, the FA 82 has many common attributes for retrieval of not only the file 84 but also other files such as the neighboring file 83. Thus, all FAs can be organized as one master FA suitable for file retrieval of all files in a transmission session. Alternatively, instead of the primary FA, the aggregated FA may be divided into two parts. The first part may hold file attributes that are considered long-term. The attributes may include file name, file ID, file location, presentation time, and distribution time window. On the other hand, attributes that are considered to be relatively short-lived may be placed in the second portion of the FA. The short-term attributes may include application file size, transmission file size, content type, encoding scheme, FEC type and parameters, and security related parameters. The first portion may remain in the SG relatively unchanged over time. The second portion may be periodically updated in the SG to reflect changing conditions.

As mentioned previously, certain files may be downloaded first and later executed by the user at a time selected by the user. Examples are music files and software update files. Other files may be downloaded first but are preferably presented at a particular time. An example is a news broadcast session as will be described below. In either case, according to another aspect of the present invention, the content file acquisition and presentation need not be performed simultaneously. Instead, file acquisition may be performed separately and prior to the file rendering process.

For ease of explanation, more specific examples are illustrated. Reference is now made back to fig. 2. Assume in this example that the user of node 50 wants to watch a news broadcast, typically available at 7:00p.m. via regular television broadcasts. In SGs broadcast via the network 44, relevant information about 7:00p.m. news clips is generally available. Network 44 has this information from service providing network 42 via backbone network 46. In the SG, two time windows, i.e., "Distribution Window (DW)" and "Presentation Window (PW)" may be specified. Fig. 6 shows the configuration.

In DW, a time window is specified in which the node 50 needs to be activated in order to receive the files of a 7:00p.m. news conversation. For example, from 5:00p.m. to 6:30p.m., which is the time interval during which the node 50 may power on to receive a news file, in this example. On the other hand, the PW identifies the presentation time of the downloaded news conversation, which in this example is from 7:00p.m. to 7:30p.m. That is, during this time interval, the downloaded file will appear as 7:00p.m. news. An additional benefit of separating the DW from the PW is to allow subscribers to download files before the presentation time to avoid traffic channel overload during presentation times that typically coincide with peak times. Even with a large traffic load in the network 44 during the DW, individual file downloads can be slowly streamed to their respective receivers in small flows and properly completed before the PW begins.

Based on the information provided by the SG, it is assumed that the node 50 is powered on and starts to receive news clips during a time period from 5:25p.m. to 5:37 p.m.. The time required for download (12 minutes in this example) may be shorter than the presentation time (30 minutes in this case) if appropriate file compression techniques are implemented.

The previously mentioned method of node 50 is shown in the flow chart of fig. 7. Fig. 8 shows a corresponding method practiced by network 44.

According to yet another aspect of the present invention, the transfer of payload data may be further streamlined.

For file content download, the FLUTE/ALC protocol may be used. As mentioned previously, unlike in FTP, where the packets are transported via the TCP transport layer (FIG. 3), the packets in FLUTE/ALC are carried on the UDP transport layer. FTP is more likely to be suitable for one-to-one applications and often retransmits erroneous packets, but this slows down the overall transmission process. The FLUTE/ALC protocol, carried over UDP, is designed to be suitable for multicast or broadcast applications. Erroneous data is typically not retransmitted. In fact, errors in data transmission are reduced by using an appropriate Forward Error Correction (FEC) scheme.

Referring now to FIG. 3A, the FLUTE/ALC protocol is shown schematically and generally represented by reference numeral 96. The data packets of the FLUTE protocol are carried by the ALC protocol. The ALC Protocol is set forth in the publication RFC3450 entitled "Asynchronous Layered Coding (ALC) Protocol isolation" issued by IETF in 12 months 2002. ALC protocol is one of the basic protocols proposed for multicast delivery. Data transfer involving ALC does not require uplink signaling (i.e., signaling from the receiver to the transmitter) and uses FEC for reliable data retrieval. ALC also utilizes Layered Coding Transport (LCT) structure block 98 for multi-rate Congestion Control (CC)97 and FEC structure block 99 for reliable content delivery. LCT was described in IETF publication RFC 3451 entitled "Layered Coding Transport (LCT) Building Block" on month 12 2002. FEC is also described in RFC 3453 issued by the IETF.

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

Fig. 9 shows an exemplary compact ALC data packet identified by reference numeral 94 formatted to be more compliant with conventional ALC packets detailed in RFC 3450. The ALC packet format 94 is designed to be identical to the broadcast/multicast service (MBMS) published by 3GPP2 in the published document 3GPP ts 23.346. The main difference between the format shown in the data packet 84 and the format detailed in document 3gpp ts 23.346 is any in-band transmission that lacks file description information (i.e. file attributes required to process the payload of the data packet 94).

Fig. 10 shows another exemplary compact packet format, represented by reference numeral 96. Data packet 96 is substantially pipelined and suitable for use in a wireless communication environment. In particular congestion control information is avoided. As in a wireless environment where the wireless medium is a single access device, congestion control for regulating multiple access devices at different data rates is not necessary. In the data packet 94 shown in fig. 9, the overhead is 16 bytes. For the data packet 96 shown in fig. 10, the overhead is only 8 bytes.

Fig. 11 schematically shows a part of a hardware implementation of an apparatus, such as the node 50 shown in fig. 2, according to an exemplary embodiment of the invention, which is denoted by reference numeral 100. The apparatus 100 may be constructed and incorporated in various forms, such as a laptop computer, PDA, or cellular telephone, to name a few.

The apparatus 100 comprises a central data bus 102 linking several circuits together. The circuits include a CPU (central processing unit) or controller 104, receive circuitry 106, transmit circuitry 108, and memory unit 110.

If the apparatus 100 is part of a wireless device, the receive and transmit circuits 106 and 108 may be connected to Radio Frequency (RF) circuits, but are not shown in the drawing. The receive circuitry 106 processes and buffers the received signals before sending them out to the data bus 102. On the other hand, the transmit circuit 108 processes and buffers the data from the data bus 102 before it is sent out of the device 100. The CPU/controller 104 performs data management functions of the data bus 102 and further performs general data processing functions, including executing the instructional contents of the memory unit 110.

Instead of being separately disposed as shown in fig. 11, the transmit circuitry 108 and receive circuitry 106 may alternatively be part of the CPU/controller 104.

The memory unit 110 includes a set of instructions, generally represented by reference numeral 101. In this embodiment, the instructions comprise, for example, portions of the protocol stack functionality 112 that are particularly capable of handling the FLUTE/ALC protocol as described above. The set of instructions also includes a broadcast client function 114 capable of performing the method shown and described in fig. 7.

In this embodiment, the memory unit 110 is a RAM (random access memory) circuit. Exemplary instruction portions 112 and 114 are software routines or modules. The memory unit 110 may be connected to another memory circuit (not shown) of a volatile or non-volatile type. Alternatively, memory unit 110 may be comprised of other circuit types, such as EEPROM (electrically erasable programmable read Only memory), EPROM (electrically programmable read Only memory), ROM (read Only memory), ASIC (application specific Integrated Circuit), magnetic disks, optical disks, and other types known in the art.

Fig. 12 schematically shows a portion of a hardware implementation of a broadcast server, such as the BSN apparatus 70 shown in fig. 2, which is represented by reference numeral 120. The apparatus 120 comprises a central data bus 122 linking several circuits together. The circuits include a CPU (central processing unit) or controller 124, a receive circuit 126, a transmit circuit 128, a database storage unit 129, and a memory unit 131.

The receive and transmit circuits 126 and 128 may be connected to a network data bus (not shown) to which the device 120 is linked. The receive circuit 126 processes and buffers signals received from a network data bus (not shown) before routing the signals to the internal data bus 122. Transmit circuit 128 processes and buffers the data from data bus 122 before it is sent out from device 120. Alternatively, the transmit circuitry 128 and the receive circuitry 126 may be collectively referred to as interface circuitry. The CPU/controller 124 performs the data management duties of the data bus 122 and performs general data processing functions, including executing the instructional contents of the memory unit 131. The database storage unit 129 stores data such as SG and content files having various parameters.

The memory unit 131 includes a set of instructions, generally represented by reference numeral 121. In this embodiment, the instructions include, among other parts, a protocol stack 132 and a broadcast host 134. Memory cell 131 may be comprised of memory circuit types as mentioned above and will not be repeated further. The functions of the protocol stack 121 and the broadcast host 134 include sets of instructions according to the present invention such as shown in fig. 3 and 8 and as previously described.

It should be further noted that the processes as described and shown in fig. 7 and 8 above may also be encoded as computer-readable instructions executing 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 (e.g., CPUs/controllers 104 and 124 shown and described in fig. 11 and 12, respectively) for execution. The medium may be of the storage type and may take the form of a volatile or non-volatile storage medium as also previously described, such as the memory units 110 and 131 described in fig. 11 and 12, respectively. The media may also be of the transmission type and may include coaxial cables, copper wire, fiber optic cables, and the air interfaces that carry acoustic or electromagnetic waves capable of carrying signals readable by machines or computers.

Finally, as described in this embodiment, the node BSD 48 is described as being installed in the service provider's network 42. This may not always be the case. It is possible to install the BSD 48 in another network that does not belong to the service provider. In addition, out-of-band transmission channels as described in the exemplary embodiments may be logically or physically distinguished as commonly practiced in spread spectrum communication techniques. In addition, different out-of-band conversations may be identified by different port numbers rather than time separation as previously mentioned. Thus, for example, in fig. 5, the FDT may be transmitted over the UDP of layer 4 (fig. 3) via one destination port corresponding to the first transmission session. The content file may be transmitted over UDP at layer 4 via another destination port number during the second transmission session. In addition, it should also be clear that the flow charts in fig. 7 and 8 are also adapted to download and execute files, such as music files, according to user selections. For example, a user may collect and autonomously determine file distributions and file presentation windows from the SG. Additionally, the backbone network is depicted as operating under IP, as described in the exemplary embodiment. Other protocols than IP are possible. For example, in a FLO network, a protocol according to the article entitled "FLO Air Interface Specification" (floforum 2005.001) issued by the FLO forum would be applicable. In a FLO network, instead of SG, the corresponding file attributes can be placed in System Information (SI), the details of which can be consulted in the document floforum 2006.005 issued by the FLO forum. Additionally, any logic blocks, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented in hardware, software, firmware, or combinations thereof. It will be understood by those skilled in the art that these and other changes in form and details may be made therein without departing from the scope and spirit of the invention.

Claims (28)

1. A file download method for broadcasting in a communication system, comprising:

receiving a file attribute of at least one file for processing the broadcast in a first communication session; and

receiving the at least one file of the broadcast in a second communication session separate from the file attributes;

wherein the file attributes are received prior to the at least one file and are used to reconstruct the at least one file.

2. The method of claim 1, further comprising:

receiving the file attribute via a first communication channel; and

receiving the at least one file via a second communication channel.

3. The method of claim 1, wherein the communication system supports Internet Protocol (IP), the method further comprising:

receiving the file attribute via a first port number over a User Datagram Protocol (UDP) of the IP; and

receiving the at least one file via a second port number over the UDP of the IP.

4. The method of claim 1, further comprising receiving a plurality of files of the broadcast in succession in the second communication session, and receiving the file attributes for processing the plurality of files in the first communication session, wherein the first communication session is earlier than the second communication session.

5. The method of claim 1, wherein the at least one file comprises a plurality of data packets, the method further comprising not receiving any file attributes in each of the data packets for processing the at least one file.

6. The method of claim 1, further comprising receiving a plurality of files of the broadcast in the second communication session, and further comprising processing the plurality of files using certain of the file attributes, wherein the certain file attributes are commonly shared among the plurality of files for processing the plurality of files.

7. The method of claim 1, further comprising providing time information for presenting the at least one file of the broadcast in the file attribute so as to allow presentation of the at least one file at a predetermined time.

8. A file delivery method for broadcasting in a communication system, comprising:

transmitting a file attribute of at least one file for processing the broadcast in a first communication session; and

transmitting the at least one file of the broadcast in a second communication session separately from the file attributes;

wherein the file attributes are received prior to the at least one file and are used to reconstruct the at least one file.

9. The method of claim 8, further comprising:

transmitting the file attribute via a first communication channel; and

transmitting the at least one file via a second communication channel.

10. The method of claim 8, wherein the communication system supports Internet Protocol (IP), the method further comprising:

sending the file attribute over a User Datagram Protocol (UDP) of the IP via a first port number; and

transmitting the at least one file over the UDP of the IP via a second port number.

11. The method of claim 8, further comprising sending a plurality of files of the broadcast in succession in the second communication session, and sending the file attributes for processing the plurality of files in the first communication session, wherein the first communication session is earlier than the second communication session.

12. The method of claim 8, wherein the at least one file comprises a plurality of data packets, the method further comprising not providing any file attributes in each of the data packets for processing the at least one file.

13. The method of claim 8, further comprising sending a plurality of files of the broadcast in the second communication session, and further comprising providing certain of the file attributes in the first communication session, wherein the certain file attributes are commonly shared among the plurality of files for processing the plurality of files.

14. The method of claim 8, further comprising time information for presenting the at least one file of the broadcast in the file attribute.

15. An apparatus configured to receive broadcasts in a communication system, comprising:

means for receiving file attributes for processing at least one file of the broadcast in a first communication session; and

means for receiving the at least one file of the broadcast in a second communication session separate from the file attributes;

wherein the file attributes are received prior to the at least one file and are used to reconstruct the at least one file.

16. The apparatus of claim 15, further comprising:

means for receiving the file attribute via a first communication channel; and

means for receiving the at least one file via a second communication channel.

17. The apparatus of claim 15, wherein the communication system supports Internet Protocol (IP), the apparatus further comprising:

means for receiving the file attribute via a first port number over a User Datagram Protocol (UDP) of the IP; and

means for receiving the at least one file via a second port number over the UDP of the IP.

18. The apparatus of claim 15, further comprising means for continuously receiving a plurality of files of the broadcast in the second communication session, and means for receiving the file attributes for processing the plurality of files in the first communication session, wherein the first communication session is earlier than the second communication session.

19. The apparatus of claim 15, wherein the at least one file comprises a plurality of data packets, wherein each of the data packets does not include any file attributes for processing the at least one file.

20. The apparatus of claim 15, further comprising means for receiving a plurality of files of the broadcast in the second communication session, and further comprising means for processing the plurality of files using certain of the file attributes that are commonly shared among the plurality of files for processing the plurality of files.

21. The apparatus of claim 15, wherein the file attribute contains time information for presenting the at least one file of the broadcast so as to allow presentation of the at least one file at a predetermined time.

22. A file delivery apparatus for broadcasting in a communication system, comprising:

means for transmitting file attributes of at least one file used to process the broadcast in a first communication session; and

means for transmitting the at least one file of the broadcast in a second communication session separately from the file attributes;

wherein the file attributes are received prior to the at least one file and are used to reconstruct the at least one file.

23. The apparatus of claim 22, further comprising:

means for transmitting the file attribute via a first communication channel; and

means for transmitting the at least one file via a second communication channel.

24. The apparatus of claim 22, wherein the communication system supports Internet Protocol (IP), the apparatus further comprising:

means for transmitting the file attribute via a first port number over a User Datagram Protocol (UDP) of the IP; and

means for sending the at least one file over the UDP of the IP via a second port number.

25. The apparatus of claim 22, further comprising means for continuously sending a plurality of files for the broadcast in the second communication session, and means for sending the file attributes for processing the plurality of files in the first communication session, wherein the first communication session is earlier than the second communication session.

26. The apparatus of claim 22, wherein the at least one file comprises a plurality of data packets, the apparatus further comprising means for not providing any file attributes in each of the data packets for processing the at least one file.

27. The apparatus of claim 22, further comprising means for sending a plurality of files of the broadcast in the second communication session, and further comprising means for providing certain of the file attributes in the first communication session, wherein the certain file attributes are commonly shared among the plurality of files for processing the plurality of files.

28. The apparatus of claim 22, wherein the file attribute comprises time information for presenting the at least one file of the broadcast.