Distribution of multicast data to users

DISTRIBUTION OF MULTICAST DATA TO USERS FIELD OF THE INVENTION

The present invention relates generally to communication networks and particularly to methods of multicast transmission.

BACKGROUND OF THE INVENTION

Data transmission networks are used to provide different types of data. Some data, such as real time telephony, must be provided quickly, and it is acceptable if a small portion of the data is lost. For other types of data, such as executable programs and other files, an entire data file must be received without any loss. In the IP protocol suite, the UDP protocol is used for data requiring fast delivery, while TCP is used for data requiring reliable delivery (i.e., without any loss). In the TCP protocol, the receiver continuously transmits acknowledgements on the data it receives, and retransmissions are performed when data was not acknowledged.

When it is desired to provide the same data to many users, multicasting may be used, in order to reduce the bandwidth consumption. In multicasting, a single transmission is listened to by a plurality of receivers. It is generally not practical for each receiver to provide continuous acknowledgements of the multicast data directly to the transmitter. Various methods, such as described in U.S. Patent 5,541,927 by Kristol, Paul and Sabnani and in U.S. patent 6,269,080 to Kumar, the disclosures of which are incorporated herein by reference, were suggested to reduce the number of acknowledgements transmitted to the transmitter, by designating one or more representative acknowledgement providers. In addition, it has been suggested, for example in U.S. patent 5,727,002, the disclosure of which is incorporated herein by reference, to use a NAK acknowledgement method, in which receivers send acknowledgements only for data they did not receive.

Generally, when a packet was not received by one or more of the receivers, the sender re-multicasts the packet to all the receivers. In some cases, however, when only a single receiver needs to receive a retransmission, the packet is transmitted to that receiver on a pointto-point connection, if such a connection is available.

Cellular phones can be used for receiving video clips and other data, in addition to their use for point to point telephone communication. Multicasting the data to the cellular phones or to other mobile stations allows efficient use of the available bandwidth, such that large amounts of data can be provided to the cellular phones without requiring prohibitive amounts of bandwidth. In some cases, users are required to subscribe to a multicast service if they desire to receive the data. Upon subscribing, the users receive a decoding key which they use in decoding the multicast data. The key may be changed periodically in order to prevent users terminating their subscription from being able to decode data transmitted after the end of their subscription period.

A user does not always want to subscribe for a service for a long duration. For 5 example, in some cases it may be desired to allow users to pay for each piece of data they receive, separately. In order to provide a reliable service, it is important to bill clients only if they actually received the multicast data. In addition, in order to maximize revenues it is desired to maximize the number of users receiving the multicast data.

In some networks, most users are generally continuously listening to the multicast 10 channel, such that a multicast message may be transmitted to the users, if desired, without previous notice. In other networks, however, the receivers are not continuously tuned onto the multicast channel and the receivers must be notified about the transmission in order to tune onto the channel at the designated time. Mobile stations, for example, are generally assigned a wireless channel only when the data is actually transmitted, in order to conserve battery power 15 and bandwidth. In such networks, the data source generally transmits a notification message to the mobile stations, instructing them to tune onto the multicast channel.

U.S. patent 6,453,438 to Miller et al., the disclosure of which is incorporated herein by reference, describes a method for managing multicast of data to receivers on a receiver list. The receivers on the list are notified on the upcoming data transmission and are requested to 20 reply as to whether they will receive the data. Receivers responding that they will not be able to receive the transmission are added to a recovery list. At a later time, an attempt is made to provide the data to the receivers on the recovery list.

The transmission of multicast data in a cell of a cellular network generally requires higher power transmission levels than unicast data, in order to allow for all the receivers in the 25 cell to receive the data. Higher transmission power levels consume more system resources, especially in noise-budget cellular networks (e.g., CDMA).

U.S. patent 6,360,076 to Segura et al., the disclosure of which is incorporated herein by reference, describes a method of adjusting the transmission power to the locations of the receivers in the cell. Thus, the power and/or bandwidth consumption may be reduced when the - 30 receivers are located, for example, close to the transmitter.

U.S. patent publication 2003/0007499 to Rajahalme, the disclosure of which is incorporated herein by reference, suggests determining whether to use multicast, unicast or a combination of multicast and unicast (i.e., some users receive the data in a multicast transmission, others in a unicast transmission) in providing data to subscribers within a specific cell. According to the ‘499 publication, broadcasting to the whole cell uses a lot of power and usually requires a robust channel coding, because there is no feedback possibility for the receivers to indicate lost frames. The ‘499 publication states that the invention is based on the premise that the membership of the group communication is known when allocating radio resources for the group communication delivery.

The combination of multicast and unicast is suggested for use when it would be cheapest to deliver the data by multicast, but some of the group members are not able to receive the broadcast for one reason or another. In other words, the multicast group is handled as subgroups to which the multicast packet is delivered using different methods.

SUMMARY OF THE INVENTION

A general aspect of the present invention relates to using less than optimal measures for delivering multicast data to receivers and supplementing receivers that did not receive the multicast data properly in point to point unicast transmissions.

An aspect of some embodiments of the invention relates to multicasting a data file to a list of receivers, in a network in which receivers are not continuously tuned to a multicast transmission channel. The method includes transmitting a notification on an upcoming multicast session, for example including the channel on which the multicast will be transmitted, to the receivers and performing the multicast session thereafter without receiving acknowledgements for the notification. It is noted that a receiver that did not receive the notification will not be able to receive the multicast transmission. Not using any acknowledgement measures for the notification may result in a lower percentage of receivers that receive the data file during the multicast transmission. In accordance with the present invention, the cost of unicasting the file to a larger number of receivers, due to the fact that they did not receive the file during multicast, is preferred over the cost of receiving acknowledgements from each of the receivers, for receiving the notification.

Optionally, the notification is transmitted several times in order to minimize the chances of a receiver not receiving the notification due to sporadic noise or a transient problem in the receiver. Alternatively or additionally, the notification is transmitted with a high protection level (e.g., a strong FEC). When the receivers are cellular units, the receivers that do not receive the notification are generally shut off or not located in a serviced cell and in most cases would not be able to receive the multicast transmission even if they received the notification.

In some embodiments of the invention, the file is delivered to each of the receivers on the list using at most a single application layer unicast connection for acknowledgement of data reception and receiving data portions not received during the multicast transmission. Optionally, beyond the single application layer unicast connection, no other transport layer (layer 4, e.g., TCP) connections are established for delivering the multicast file. In some embodiments of the invention, beyond the single application layer unicast connection, no other. network layer (layer 3, e.g., IP) transmission is performed in relation to the delivery of the file.

In some of these embodiments, no acknowledgements (including negative acknowledgements) are transmitted during the data delivery. In some embodiments of the invention, the receivers cannot transmit acknowledgements unless a unicast connection is established between the receiver and a data server.

In some networks, receivers cannot transmit uplink messages to the transmitter while they are tuned onto the multicast channel. The switching between a multicast channel and a unicast channel required for uplink transmission is generally resource consuming and therefore it is desired to minimize the number of times a receiver switches between unicast and multicast channels. In addition, when there are a large number of receivers, it is desired to reduce the number of unicast connections established with the transmitter.

In some embodiments of the invention, the delivered file is encrypted with one or more keys. Optionally, the keys are provided to the receiver in a same unicast connection in which the receiver acknowledges receiving the entire data file and/or receives supplementary portions of the data file or the entire data file. Thus, the entire data file is provided to each of the users using a single unicast connection in addition to the multicast transmission.

Alternatively, the key is provided to at least some of the users in a unicast connection separate from the unicast connection used for acknowledgement and/or for data supplement. In accordance with this alternative, each receiver optionally uses at most two unicast connections to receive the data file and any data required for decoding the file. Optionally, no more than 10-20% of the receivers of the file use two unicast connections, while the remaining receivers use only a single unicast connection. The two unicast connections performed by some of the receivers are optionally performed consecutively without the receiver tuning onto the multicast channel between the unicast connections. This alternative is optionally used, for example, when the user reviews a portion of the received data before determining whether to view the rest of the data.

Optionally, beyond the two unicast connections, no other transport layer (layer 4, e.g., TCP) or even network layer (layer 3, e.g., IP) transmissions are performed in relation to the delivery of the file.

An aspect of some embodiments of the invention relates to multicasting a data file to a list of receivers, in which the file is delivered to each of the receivers on the list using at most a single application layer unicast connection for acknowledgement of data reception and receiving data portions not received during the multicast transmission.

An aspect of some embodiments of the invention relates to a method of multicast delivery of a data file to receivers. The method includes encoding the data file and providing one or more keys required for decoding the file only after the data is provided to the receiver. Providing the key only after the data is provided allows using the request for the key as an acknowledgment of receiving the file. In addition, providing the key only after the data transmission reduces the time available for users to illegally disseminate keys.

In some embodiments of the invention, the data file multicast to users includes a nonencrypted preview portion and at least one encrypted portion. The user may view the preview portion and accordingly determine whether to request the key for the encrypted portion. In some embodiments of the invention, the at least one encrypted portion may include a plurality of portions and the user may determine, independently from each other, for which portions to request decryption keys. Optionally, the user may request the key for each portion at different times. Alternatively or additionally, the user may determine whether to request a key for one of the portions based on viewing one or more of the portions for which a key was previously received. Providing a plurality of portions together reduces the amount of signaling required for the delivery of the plurality of portions to the receivers.

An aspect of some embodiments of the invention relates to a method of multicast delivery of a data file to receivers. The method includes estimating one or more transmission parameter values required to provide the multicast data, on the average, to a percentage of receivers lower than 100% and using the estimated parameter value for multicast transmission. The receivers that statistically do not receive the data during the multicast transmission are optionally provided the data in supplementary unicast transmissions. The percentage of receivers for which the transmission parameters are adjusted is selected so that the cost of providing the supplementary data in unicast is lower than the extra cost required for adjusting the transmission parameters at a higher level. Optionally, the estimation is adjusted to a level of reception of between about 90-95% of the receivers.

The estimation is optionally performed before each transmission, based on the current conditions (e.g., number of receivers, locations of receivers, noise level) of the network. Alternatively or additionally, the estimation is performed based on predetermined tests and/or assumptions for a plurality of transmissions.

The transmission parameters optionally include the transmission power used, the amount of redundancy used in the transmission, the transmission rate and/or any other parameter that affects the energy per bit of the transmission.

An aspect of some embodiments of the invention relates to a method of providing encrypted data to a receiver. The data is optionally provided by a first mobile network service provider, while the key for decrypting the data is provided by a second mobile network service provider. The first service provider optionally does not allocate the IP address used to receive the data. In some embodiments of the invention, the data is provided through a different gateway GPRS support node (GGSN) than the GGSN through which the key is provided.

In some embodiments of the invention, the data is provided in a multicast data delivery.

An aspect of some embodiments of the invention relates to a method of receiving multicast data, in which receivers are notified on an upcoming multicast session and then determine whether to tune onto the multicast channel on which the data is provided. Allowing the receivers to view the notification on a multicast session as a recommendation, rather than an instruction, allows the notification to be provided without specifically identifying the exact group of receivers to which the notification is directed. Thus, for example, when a file is transmitted a second time for those receivers that did not receive the file the first time, there is no need to identify the receivers that are to receive the second transmission in the notification, or to have the other receivers receive the file a second time.

In addition, the user may be queried whether to receive the data file after the notification is received, or may otherwise program the receiver on which files to receive, without involving the data server in the process.

In some embodiments of the invention, the receiver manages a table that indicates the multicast groups to which the receiver is subscribed. The receiver table is optionally managed in addition to a subscriber list managed by a transmission controller that provides the multicast data. Upon receiving the notification, the receiver determines the group or groups to which the data file referred to by the notification belongs and consults the table to determine whether to receive the data file. Alternatively, the user is queried. In some embodiments of the invention, the table indicates what is to be done if the user does not provide an answer (e.g., the user is not near the receiver, the receiver is powered off). In some embodiments of the invention, the rules on whether to receive a file, query the user and/or not receive a file may depend on one or more external parameters not related to the transmission (e.g., the time, date, location of the mobile) and/or one or more internal parameters related to the transmission (e.g., file size, planned transmission rate, expected error rate).

An aspect of some embodiments of the invention relates to a method of transmitting multicast data in a cellular network, in which different cells have different bandwidth allocated for the multicast transmission. The data is optionally provided to each of the base stations of the cells at a substantially same rate, and each base station transmits a portion of the data that it can transmit using its available bandwidth for the multicast transmission and drops data packets which they cannot transmit on their allocated bandwidth. The dropping of the packets is performed in a manner which substantially synchronizes the transmission of the nondropped data packets of different base stations, such that the base stations transmit packets representing the same data content at substantially the same time. The term substantially synchronized refers herein to a gap of at most several packets (e.g., 3-5 packets) between the packets transmitted by different base stations and/or a time gap of at most a few seconds (e.g.,

5-10 seconds) between the transmission of the same packet by different base stations.

Synchronizing the data transmission in the different cells, avoids the possibility of a mobile station moving from one cell to another during a multicast session, receiving the same data packets twice.

In some embodiments of the invention, the data packets are provided in groups and when a first packet of a new group is received, the base stations drop all the data they have of an old group. Optionally, the data source periodically transmits synchronization messages to the base stations, to keep the base stations synchronized. Alternatively or additionally, the base stations are configured to have small buffers and when the buffers are full, packets are dropped. In an exemplary embodiment of the invention, the buffers of the base stations have a small size, for example of between two to five packets, such that synchronization is maintained. Optionally, the buffers of substantially all the base stations have the same size.

In some embodiments of the invention, the data packets transmitted to the base stations are identical. Alternatively, different data packets, representing the same data content, are transmitted to different base stations.

There is therefore provided in accordance with an exemplary embodiment of the invention, a method of multicasting a data file, comprising transmitting a notification on an

ר upcoming multicast transmission to a plurality of receivers designated to receive the multicast transmission, tuning by at least one of the plurality of receivers to a multicast channel, responsive to the notification, transmitting a data file, from a data server, on the multicast channel, without the data server receiving acknowledgements from the receivers on whether they received the notification, determining receivers designated to receive the multicast transmission that did not receive at least a portion of the data file and attempting to deliver the data file to the determined receivers.

Optionally, transmitting the notification comprises transmitting on a multicast or broadcast channel. Optionally, transmitting the notification comprises transmitting a unicast notification to each of the receivers on the designated receivers. Optionally, transmitting the notification comprises transmitting substantially only to designated receivers. Optionally, transmitting the notification comprises transmitting a message open also to non-designated receivers. Optionally, the notification indicates the channel on which the multicast transmission will be provided. Optionally, tuning to the multicast channel by at least one of the receivers comprises determining by each receiver that receives the notification whether to tune onto the multicast channel. Optionally, determining by each receiver that receives the notification whether to tune onto the multicast channel comprises determining, from the notification, a group to which the upcoming multicast transmission belongs and determining whether to tune to the multicast channel according to the determined group.

Optionally, determining by each receiver that receives the notification whether to tune onto the multicast channel comprises determining by consulting a list stored on the receiver.

Optionally, determining by each receiver that receives the notification whether to tune onto the multicast channel comprises determining based on input received from a user responsive to the notification. Optionally, the receivers do not transmit acknowledgements of reception of the notification, at all. Optionally, the receivers cannot transmit uplink messages to the data server, without stopping to listen to the multicast channel. Optionally, attempting to deliver the data file comprises delivering the data file in a unicast transmission to each of the determined receivers. Optionally, attempting to deliver the data file comprises delivering the data file in a multicast transmission to a plurality of the determined receivers.

Optionally, attempting to deliver the data file comprises providing a notification message inviting the receivers to download the transmission on a unicast connection, to the determined receivers. Optionally, at least 80% of the designated receivers establish only a single unicast connection related to receiving the data file. Optionally, substantially all of the designated receivers establish only a single unicast connection related to receiving the data file. Optionally, substantially all of the designated receivers establish up to two single unicast connections related to receiving the data file. Optionally, at least a portion of the data file is encrypted, requiring one or more decryption keys identified in the transmitted data file.

Optionally, the receivers request the one or more keys after receiving the data file. Optionally, the receivers request the one or more keys after determining that they received sufficient data to allow reconstruction of the data file. Optionally, the keys are received on a single unicast connection along with any supplementary data required, not received during the multicast transmission. Optionally, the method includes receiving acknowledgements from receivers that received the notification or at least a portion of the data file, after transmitting the data file, wherein determining receivers designated that did not receive at least a portion of the data file is performed by determining receivers from which acknowledgments were not received.

Optionally, receiving the acknowledgements comprises receiving a request for decryption keys. Optionally, receiving the acknowledgements comprises receiving a request for supplementary data not received during the multicast transmission. Optionally, receiving the acknowledgements comprises receiving over a different network than the network on which the data file was multicast. Optionally, the data file includes a non-encrypted preview portion. Optionally, the non-encrypted preview portion is transmitted on the multicast channel interleaved with the remaining portion of the data file. Optionally, at least one occurrence of the non-encrypted preview portion is transmitted on the multicast channel before transmission of the remaining portion of the data file.

Optionally, tuning onto the multicast channel comprises tuning onto a cellular multicast channel. Optionally, tuning onto the multicast channel comprises tuning onto a digital video broadcast channel. Optionally, attempting to deliver the data file to the determined receivers comprises delivering on a different network than the network on which the data file was multicast. Optionally, the notification indicates a plurality of categories to which the data file relates and the plurality of receivers comprises receivers designated to receive data belonging to different ones of the plurality of categories.

There is further provided in accordance with an exemplary embodiment of the invention, a method of receiving a data file provided in a multicast transmission, comprising tuning, by a mobile station, onto a multicast channel, receiving at least one encrypted packet which can be used in reconstructing the data file, on the multicast channel and receiving at least one key required for decrypting the at least one packet after receiving the packet.

Optionally, receiving the at least one encrypted packet comprises receiving a plurality of encrypted packets. Optionally, the plurality of encrypted packets require at least two different keys for decryption. Optionally, the at least one key is received after receiving a sufficient number of packets for reconstructing the data file. Optionally, the method includes requesting the at least one key after receiving a sufficient number of packets for reconstructing the data file and wherein receiving the at least one key is performed responsive to the requesting.

Optionally, the requesting of the at least one key is performed responsive to a user instruction. Optionally, at least a portion of the data file is not encrypted. Optionally, the user instruction is received after displaying the non-encrypted portion of the file to the user.

Optionally, the non-encrypted portion of the file is received before any encrypted portion of the data file. Optionally, the user instruction is received before receiving any encrypted portion of the data file. Optionally, the user instruction is received after receiving at least some of the encrypted packets. Optionally, the file includes a plurality of different portions requiring different keys for decryption. Optionally, the keys required for at least one portion are received after displaying at least one other portion. Optionally, the keys required for at least one portion are received after displaying at least one other portion which was decrypted.

Optionally, tuning onto the multicast channel is performed responsive to receiving a notification on an upcoming multicast transmission and responsive to a determination that the upcoming multicast transmission matches a subscription profile of the receiver. Optionally, the determination that the upcoming multicast transmission matches a subscription profile of the receiver comprises consulting a multicast subscription profile stored on the receiver. Optionally, the determination that the upcoming multicast transmission matches a subscription profile of the receiver comprises consulting a multicast subscription profile stored on the receiver which is configured automatically by instructions from a remote unit. Optionally, the determination that the upcoming multicast transmission matches a subscription profile of the receiver comprises consulting a multicast subscription profile stored on the receiver which is configured by a user of the receiver. Optionally, the method includes acknowledging receipt of the at least one key, in a manner which allows charging for the data file.

There is further provided in accordance with an exemplary embodiment of the invention, a method of transmitting multicast data, comprising estimating one or more transmission parameter values required to achieve, on the average, a reception rate of the multicast data lower than 100%, by the receivers to which the multicast data is directed, transmitting the multicast data on a multicast channel, using the one or more estimated parameter values, and providing at least supplementary portions of the multicast data to receivers that did not receive the multicast data in its entirety on the multicast channel.

Optionally, the one or more transmission parameters comprise a transmission power level and/or a FEC redundancy level. Optionally, estimating the one or more transmission parameter values comprises estimating based on general network data without relation to specific conditions of a current transmission. Optionally, estimating the one or more transmission parameter values comprises estimating based on specific conditions of a current transmission. Optionally, estimating the one or more transmission parameter values comprises estimating based on the number of receivers. Optionally, the multicast channel comprises a data channel of a cellular network.

There is further provided in accordance with an exemplary embodiment of the invention, a method of receiving multicast data in a cellular network, comprising establishing, by a mobile station, a data channel, through a first network unit of a first mobile network, opening, by the mobile station, a port associated with the data channel, and receiving, by the mobile station, through the port, multicast data from a multicast channel passing through a second network element, belonging to a second mobile network different from the first mobile network.

Optionally, establishing the data channel comprises receiving an IP address for the mobile station and/or establishing a packet data context. Optionally, the first and second network elements comprise GGSNs. Optionally, the method includes receiving a key for decrypting the multicast data through the first network element.

There is further provided in accordance with an exemplary embodiment of the invention, a method of transmitting multicast data in a cellular network, comprising providing data for multicast transmission to a plurality of base stations having different bandwidth amounts allocated for multicast transmission, at a same rate, dropping data by one or more of the base stations, as required, so that the data can be transmitted by each of the base stations on its respective allocated bandwidth for multicast transmission and transmitting the non-dropped data such that the data is transmitted by all the base stations substantially synchronously.

Optionally, the base stations use a small buffer for the provided multicast data.

There is further provided in accordance with an exemplary embodiment of the invention, a method of transmitting multicast data in a cellular network, comprising transmitting a notification on an upcoming transmission of a multicast file, stating a plurality of categories to which the data file relates and tuning on to a multicast channel by a plurality of receivers subscribed to different categories, responsive to the notification.

BRIEF DESCRIPTION OF FIGURES

Particular non-limiting embodiments of the invention will be described with reference to the following description of embodiments in conjunction with the figures. Identical structures, elements or parts which appear in more than one figure are preferably labeled with a same or similar number in all the figures in which they appear, in which:

Fig. 1 is a schematic illustration of a cellular network, in accordance with an exemplary embodiment of the present invention;

Fig. 2 is a flowchart of acts performed by network elements in multicasting a file to mobile stations, in accordance with an exemplary embodiment of the invention;

Fig. 3 is a flowchart of acts performed by a mobile station in receiving a multicast data file, in accordance with an exemplary embodiment of the invention; and

Fig. 4 is a schematic illustration of first and second public land mobile networks (PLMNs), useful in explaining cooperation between networks in providing multicast data, in accordance with an exemplary embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Fig. 1 is a schematic illustration of a cellular network 100, in accordance with an exemplary embodiment of the present invention. Network 100 includes a plurality of base stations (BTS) 50, which transmit signals to mobile stations 20 in a cell in their vicinity. Generally, as is known in the art, each group of several base stations 50 are controlled by a base station controller (BSC) 22. As is known in the art, BSC 22 may be replaced by other units, such as by a radio network controller (RNC). Regular unicast data is transmitted to BSC 22 through a serving GPRS support node (SGSN) 24 and a gateway GPRS support node (GGSN) 26 from an IP core network 28, such as the Internet.

In some embodiments of the invention, in transmission of multicast data to mobile stations 20, a data source 30 generates files which are to be multicast to subscribing mobile stations 20. Optionally, the generated files are provided to a data server 42, which controls the provision of the file in a multicast transmission to mobile stations 20.

In some embodiments of the invention, data server 42 includes a forward error correction (FEC) unit 32, in which a plurality of FEC packets are prepared to represent blocks of the file. The FEC packets are generated using substantially any FEC method known in the art, including one-dimensional, two-dimensional, systematic and non-systematic methods. In an exemplary embodiment of the invention, a FEC method such as described in Israel patent application 154,739, filed March 4, 2003 and/or in Israel patent application 157,885, filed September 11, 2003, titled “Iterative Forward Error Correction”, the disclosures of which are incorporated herein by reference, is used. The FEC packets are optionally transferred to an encryption unit 34, which encrypts the FEC packets, forming respective encrypted packets. The encryption of the data may be performed using any method known in the art, including symmetric and non-symmetric (i.e., public key and private key) methods. In an exemplary embodiment of the invention, the encryption is performed as described in Israel patent application 157,886, filed September 11, 2003, titled “Secure Multicast Transmission”, the disclosure of which is incorporated herein by reference. Optionally, each packet or group of packets is marked with an identification of the key to be used in decoding the packet.

The encrypted packets of each base station 50 are transferred to the base station for transmission in a respective cell covered by the base station. In some embodiments of the invention, for example as shown in Fig. 1, the encrypted packets are provided through a respective point to multipoint unit (PTMU) 40 of the base station. Alternatively, the encrypted packets are provided to the base station along a data channel passing through GGSN 26, SGSN 24 and BSC 22. Optionally, in accordance with this alternative, data server 42 serves as a broadcast multicast service center (BMSC).

In some embodiments of the invention, the multicast data is transmitted by the base stations using the currently available bandwidth not used for other connections. Accordingly, different amounts of bandwidth for multicast may be allocated in different cells. Alternatively or additionally, some or all of the cells allocate a fixed bandwidth for multicast transmission. The fixed bandwidth is optionally determined according to the load in the cell, such that different cells allocate different bandwidth for multicast.

Optionally, the packets are provided to base stations 50 at a same rate in a synchronized manner, so that all the base stations receive the same data at the same time. In some embodiments of the invention, base stations 50 (or the BSCs 22 and/or PTMUs 40 servicing the base stations) whose multicast bandwidth allows a transmission rate lower than the rate at which the data packets are received from data server 42, are configured to drop some of the packets in a manner which keeps close synchronization of the transmitted data between different cells. Thus, a mobile station roaming between cells will not receive a large number of packets twice.

In some embodiments of the invention, the base stations 50 (or any other unit that performs the dropping for the cell) have small buffers (e.g., of the size of 2-5 packets) for the multicast data, so that the time difference between transmitting the same data between different base stations 50 is relatively small. Alternatively or additionally, the data packets are divided into blocks and base stations 50 are configured to drop packets of an old block when a first packet of a new block is received. Further alternatively or additionally, data server 42 transmits periodically an instruction to drop all old packets.

In some embodiments of the invention, identical packets are provided to all the base stations. Alternatively, different packets representing the same data, for example encoded using different keys and/or including different FEC protection segments, are provided to different base stations 50. The transmission of different FEC protection segments in different base stations 50 may be used, in addition to or instead of synchronous transmission, in avoiding reception of duplicate data by a moving mobile station.

Data server 42 optionally includes a key server 36, which provides decryption keys to mobile stations 20. In some embodiments of the invention, mobile stations 20 receiving the file, instructed to display the file, contact key server 36 and request the keys they need for the decryption. In addition, mobile stations 20 that did not receive all the data during the multicast, optionally receive missing data portions from key server 36, acting additionally as a supplementary data server, as described below.

Although data source 30, FEC unit 32, encryption unit 34 and key server 36 are shown as separate units, in some embodiments of the invention, one or more of these units are implemented together. For example, encryption unit 34 and key server 36 may be implemented on a single processor and/or may use a common key database. Alternatively, FEC unit 32, encryption unit 34 and key server 36 may be implemented by a plurality of different units at different locations.

Optionally, key server 36 provides keys for decryption only to mobile stations 20 that have subscribed to the multicast data. Users optionally subscribe for receiving the multicast data with the data content provider. Alternatively or additionally, users register through the cellular service provider. In some embodiments of the invention, data server 42 provides multicast data of a plurality of different categories, for example relating to different themes (e.g., sports, news, music, financial information). Categories may also be based on other attributes, such as profession of the user and/or predefined groups of users. Optionally, key server 36 provides keys for decryption only to mobile stations 20 subscribed to the category to which the transmitted file belongs. Alternatively, for some or all the categories, any user requesting decryption keys is provided the keys and there is no need for prior subscription.

Optionally, some data files may relate to more than one category and are therefore provided to subscribers of all the categories to which they relate. In some embodiments of the invention, different notifications are transmitted for each category to which the data file relates. Alternatively, a single notification stating the categories to which the data file relates is transmitted. For example, each notification may include a list of the category numbers to which it relates. Alternatively, each notification has fields for all the possible categories and a bit is set for each category to which the data file of the notification relates. Each user registering to receive multicast data optionally states the categories the user is interested in.

In some embodiments of the invention, special data files (e.g., an extraordinary news broadcast, a promotion music or video clip) are provided to all subscribers or to all mobile stations, optionally even to those that did not subscribe to any category.

The user is optionally charged a flat price for the subscription to the multicast service and/or for each category the user is subscribed to. Alternatively or additionally, the user is charged for each data file for which decryption keys were requested. In providing the keys, key server 36 optionally marks the identity of the mobile stations 20 requesting keys, for billing purposes. Optionally, data files not delivered within a predetermined time are not billed for, or are provided for a reduced cost. For example, data files provided in a mailbox of the user due to unsuccessful transfer during the multicast, as described below, may be provided at a lower fee. Further alternatively or additionally, the transmission costs of some data files, such as promotion files, are charged to the data provider.

In some embodiments of the invention, data server 42 manages a subscriber list 44 which lists for each of the multicast categories, which mobile stations 20 are subscribed to the data of the group. The subscription information in subscriber list 44 is optionally used in determining whether to provide decryption keys as discussed above. Alternatively or additionally, the information in subscriber list 44 is used in determining that all the subscribed mobile stations 20 received the multicast file, as described hereinbelow. Further alternatively or additionally, the information in subscriber list 44 is used to update mobile stations 20 on the files they should receive, as described hereinbelow.

Fig. 2 is a flowchart of acts performed by network elements in multicasting a file to mobile stations 20, in accordance with an exemplary embodiment of the invention. Data server 42 optionally provides (200) each PTMU 40 with a notification message on an upcoming multicast transmission. Responsive to the notification message, PTMUs 40 generate notification packets which they transmit (202) in their cell. The notification packets optionally include a timing of the transmission and a channel on which the transmission is provided. Alternatively or additionally, the notifications are generated and/or transmitted using any other method known in the art. In an exemplary embodiment of the invention, the notifications are generated automatically responsive to opening a multicast data channel.

At the designated transmission time, optionally without waiting for application layer acknowledgements of the notification messages, the file is transmitted (204) on the multicast channel. After the transmission is completed, and optionally during the transmission, data server 42 waits (230) for unicast connections from MSs 20 receiving the multicast transmission. On the unicast connections, data server 42, for example key server 36 thereof, provides (206) supplementary data and provides (208) decryption keys, as discussed below with reference to Fig. 3. Data server 42 marks (210) mobile stations 20 that requested keys as receiving the data file, for example for billing purposes, as the requesting of the keys serves as an indication that the data file was properly received. That is, mobile stations 20 optionally do not request keys unless they have received sufficient data to reconstruct the file.

After the waiting period, data server 42 optionally determines (232) which mobile stations, subscribed to a multicast group to which the file belongs, did not acknowledge receipt of the data file. These mobile stations 20 may, for example, have been turned off, located in cells not supporting multicast, did not receive the notification message due to data loss and/or did not succeed to establish a unicast connection with key server 36. Optionally, these mobile stations are notified (235) that the data file is waiting for them. The notified mobile stations then optionally establish a unicast connection with key server 36 on which the data file is delivered (237) to the mobile station.

Referring in more detail to transmitting (200) the notification on the upcoming multicast, in some embodiments of the invention the same notification message is provided to each of PTMUs 40 and each PTMU generates a separate notification packet for transmission in its cell. Optionally, the notification message includes a time of beginning of the multicast transmission and/or a duration of the transmission. In an exemplary embodiment of the invention, rather than stating a time for the beginning of the multicast transmission, the multicast transmission is carried out a predetermined time after the notification packet is transmitted. The notification message optionally further includes a file size, information on the type of FEC used and/or the type of encryption used. For each file transmitted, the notification message optionally identifies the multicast category (or categories) to which the file belongs.

The notification packet transmitted by base station 50 is optionally transmitted on a cell broadcast channel. Alternatively or additionally, the notification packet is transmitted as an SMS message to the mobile stations. Further alternatively or additionally, the notification packet is transmitted to the mobile stations using their IP address, for mobile stations having an IP address. In an exemplary embodiment of the invention, in base stations 50 associated with a PTMU 40, the notification packet is generated by the PTMU, while in other base stations the notification packet is provided through a regular cell broadcast service.

In some embodiments of the invention, the notification packet is transmitted to all mobile stations 20 in the network, regardless of whether they are registered to receive the multicast transmission. Optionally, mobile stations 20 not registered to receive the multicast transmission discard the notification in the application layer. Alternatively, the notification is transmitted with a sub-channel identity of the mobile stations registered to the .list, such that the mobile stations 20 not on the list discard the notifications in a low communication layer.

Although in the above description each file that is multicast has a separate notification message, in some embodiments of the invention, a single notification message is used for a plurality of files that are multicast. Alternatively or additionally, a plurality of notification messages are generated for a single file, in order to increase the chances that at least one of the notifications will be received. The notification packets optionally have a high FEC protection level, so as to minimize the loss of the notification packet due to an interfering noise.

Referring in more detail to waiting (230) for unicast connections, in some embodiments of the invention, data server 42 optionally waits a predetermined time for acknowledgements after' the multicast session is completed. The amount of wait time is optionally selected according to the number of receivers on the list of mobile stations 20 to receive the transmission and/or the transmission rates in the network.

Referring in more detail to notifying (235) the non-acknowledging mobile stations 20 that the file is waiting for them, in some embodiments of the invention, the notification is transmitted on a short message (e.g., SMS). Optionally, the notification is transmitted a plurality of times consecutively in order to reduce the chances that the notification is not received. Alternatively or additionally, the notification is transmitted on a low loss channel and/or with a high forward error protection.

Optionally, before downloading the file, the mobile station verifies that it did not yet receive the file. In some embodiments of the invention, when a relatively large number of mobile stations did not receive the file, the short message indicates an interval in which it is best to download the file (different intervals being indicated to different mobile stations), so as to reduce the load on data server 42.

In some embodiments of the invention, data files delivered (237) on a unicast connection are provided in a different, more efficient, format than provided on the multicast connection (e.g., using less or no FEC protection). Alternatively, for simplicity, the same packets are provided on the unicast connection as on the multicast connection.

In some embodiments of the invention, mobile stations 20 are required to acknowledge receipt of the notification, for example by transmitting a return SMS message. Alternatively, mobile stations 20 do not acknowledge receipt of the notifications and notifications are retransmitted to mobile stations that do not collect the file within a predetermined time.

For mobile stations from which an acknowledgement was not received, repeated attempts are optionally made to provide the notification, until the data is properly delivered. Alternatively, or after a predetermined time (e.g., several hours) and/or a predetermined number of attempts, the data file is considered old and no more attempts to deliver the file are made. Optionally, a message is sent to a mailbox of the mobile station notifying that the old file was not delivered. Optionally, the mobile station 20 can then establish a unicast connection with the data server at any time to collect the old file, if desired. Alternatively or additionally, the old file is placed in a mailbox of the mobile station 20 such that it can be collected therefrom by the user. Optionally, a message reporting the placement of the file in the mailbox is transmitted to the mobile station. In some embodiments of the invention, the reporting message is transmitted only a period of time after the placement in the mailbox, only if the receiver did not pick up the file. Thus, the number of messages required is decreased.

Alternatively to transmitting (235) a notification to the non-acknowledging mobile stations 20, the data file is provided to non-acknowledging mobile stations on a unicast data connection established by key server 36 or on an MMS transmission, with each of the mobile stations. Optionally, in accordance with this alternative, before providing the file on the connection, the mobile station is queried as to whether it has already received the file.

Further alternatively or additionally, data server 42 does not manage a subscription list at all or does not provide the file to mobile stations 20 that do not request the file.

Fig. 3 is a flowchart of acts performed by a mobile station in receiving a file in a multicast transmission, in accordance with an exemplary embodiment of the invention. Upon receiving (250) the notification packet, the mobile station determines (252) whether to receive the file, for example, by consulting a subscription profile record on the mobile station, by determining whether the file was received already and/or by querying the user. If the file is to be received, the mobile station tunes (254) onto the multicast channel on which the file is provided, optionally as identified in the notification packet. The mobile station then receives (256) packets of the file on the multicast channel. During the packet reception, the receiver repeatedly checks (258) if a sufficient group of packets for reconstruction, were received. If (258) a sufficient group of packets for reconstructing the file are received during the multicast session, the mobile station leaves (262) the multicast channel, possibly during the multicast session.

In some embodiments of the invention, the mobile station determines (263) whether to request the keys required for decoding the file. If it is determined to request the keys, the mobile station establishes (264) a unicast connection with key server 36. On the unicast connection, the mobile station 20 requests (266) the keys it requires in order to decode the packets it received, and receives (268) the requested keys on the established unicast connection. The file is then displayed (270) to the user.

If (258) a sufficient number of packets were not received during the multicast session, the mobile station establishes (260) a unicast connection with key server 36 and requests (272) supplementary packets. In some embodiments of the invention, if additional multicast sessions for the same data file are scheduled, the mobile station waits for the additional session and does not request supplementary data yet. Key server 36 provides the supplementary packets on the unicast connection. Thereafter, the mobile station optionally determines (267) whether to request the keys required for decoding the file. If it is determined to request the keys, on the same connection, key server 36 optionally provides (268) the keys required for decrypting the packets. In some embodiments of the invention, mobile station 20 requests the keys after receiving the supplementary packets. Alternatively, mobile station 20 requests the keys along with the request for supplementary packets.

Alternatively, the keys and supplementary data are provided on separate unicast connections. For example, the connections may be established with two separate units, one of which provides the keys and the other provides supplementary data. Alternatively or additionally, the receiver may first receive the entire data file and then ask the user whether to request the keys. For example, as described below, the user may first view a preview of the data before requesting the keys. In some embodiments of the invention, between the two unicast connections, the receiver mobile station 20 does not tune onto the multicast channel for additional data, as the required data is supplemented on the first unicast connection.

In some embodiments of the invention, the received data file includes a non-encoded portion which is previewed by the user in order to determine whether to request the keys of the encoded portion. A data supplementing connection is optionally established, if necessary, before the preview is displayed in order to fill in data required for the preview and a key requesting connection is optionally established after the preview, if desired. Acknowledgement of data receipt may be supplied on either connection. Charging, however, is performed only if keys are requested on the second connection.

In some embodiments of the invention, the data file includes a plurality of portions encoded with different keys. Upon receiving the file, the mobile station requests a first set of keys for decrypting a first portion of the file. Thereafter, based on viewing the first portion of the file, the user instructs mobile station 20 whether to request keys for one or more additional portions of the file. Based on viewing the additional portions, the user may determine whether to request keys for further portions of the file. Optionally, the order of requesting keys is predetermined, such that key server 36 will not provide keys for a second portion if keys for the first portion were not requested. Alternatively, the encrypting is performed in a manner which allows decryption only according to the allowed order. In some embodiments of the invention, according to the allowed decryption order of the portions, each portion is encrypted with a function of all the keys of the previous portions in addition to its key. Thus, each portion can only be decrypted after receiving all the keys of the previous portions. Alternatively, the last portion is encrypted first with its key. Thereafter, the last portion and the previous portion is encrypted with the key of the previous portion. This process is optionally continued for all the portions, so that to decrypt a portion its keys and the keys of all the portions before it are required.

In some embodiments of the invention, the user is notified when receiving the first portion on the structure of the file and the number of portions it has. The user can then request the keys for all the portions at once or request one or more keys in a plurality of separate requests. Alternatively, the user is not notified as to the structure of the file in advance, and each time the user requests keys, the user is provided with a set of keys of the next portion. Further alternatively, the user may determine which of the portions to decode, in substantially any order.

Alternatively to mobile station 20 automatically requesting the keys for the first portion, the keys are requested only after receiving an instruction from the user, for example after viewing a free preview. In some embodiments of the invention, the file includes a plurality of free previews for different encoded portions.

Alternatively to the preview portions being non-encoded, the preview portions are encoded with a special key for previews. The preview key is optionally provided to subscribing mobile stations upon subscription, before the file is transmitted on the mobile channel. Alternatively, the key is requested by the mobile station after the receiving of the data and serves as a first indication of the reception of the data.

Referring in more detail to receiving (250) the notification packet, in some embodiments of the invention, the notification packet includes a low level indication (e.g., a multicast group address) of the mobile stations to which it is directed, and the mobile station provides the notification to the application layer only if the notification packet is directed to the mobile station (e.g., the low level indication matches the mobile station).

Referring in more detail to determining (252) whether to receive the file, in some embodiments of the invention, each mobile station 20 manages a subscription profile which lists the categories to which it is subscribed. Upon receiving the notification packet, the mobile station 20 optionally consults its subscription profile to determine whether to receive the file referred to in the notification packet. Alternatively or additionally, mobile station 20 displays or sounds a message to the user, asking whether to receive the file. Optionally, in accordance with this alternative, mobile station 20 is configured with default decisions on the acts to be performed when a response is not received from the user. For example, a mobile station 20 may be configured to receive all files of a first multicast category, to ask the user about files of a second multicast category but to receive the file if no answer is received and to ask the user about files of a third multicast category but not to receive the file unless specific instructions were received from the user. It is noted that the decision on whether to receive the data of the file is separate from the decision on whether to decode the file and pay for it. A user may decide, for example, to receive any file that has a fair chance to be decoded, in order not to lose time until the file is received, although such reception utilizes the battery power of the mobile station.

in some embodiments of the invention, the rules on whether to receive a file, query the user and/or not receive a file may depend on one or more external parameters not related to the transmission (e.g., the time, date, location of the mobile) and/or one or more internal parameters related to the transmission (e.g., file size, planned transmission rate, expected error rate).

In some embodiments of the invention, the subscription profile in mobile station 20 is configured by the user of mobile station 20, through a user interface of the mobile station, according to user preferences. Alternatively, the subscription profile is configured by a control message transmitted from data server 42 (or from any other remote network unit), according to subscription information in subscription list 44. The control messages are optionally transmitted to mobile station 20 periodically and/or whenever there is a change in the subscription information.

Alternatively to mobile station 20 keeping track of the categories of files it is to receive, the notification packets are transmitted only to mobile stations 20 that are to receive the message, for example using directed unicast SMS messages. Alternatively or additionally, upon receiving the notification packet, mobile stations 20 that do not know if they are to receive the file, query data server 42.

In some embodiments of the invention, a mobile station 20 that received the notification but will not be receiving the file, although being subscribed to receive the file according to subscription list 44, notifies data server 42, so that attempts will not be made to deliver the packet to the mobile station on a unicast connection. Alternatively, the. mobile station does not notify data server 42. Optionally, in this alternative, the mobile station ignores the message notifying that the file can be retrieved in unicast or notifies the data server that it is not receiving the file upon receiving the message.

In some embodiments of the invention, the same file is transmitted on the multicast channel a plurality of times in order to make sure that as many as possible receivers receive the file in a multicast transmission. For example, if after a first multicast session of transmitting the file, less than a predetermined number (70-80%) of subscribers acknowledge receipt, instead of providing the file in unicast to all the other subscribers, the file is retransmitted in another unicast session. Alternatively or additionally, a second multicast session is used without relation to the number of acknowledgments received, to make sure that as many as possible receivers use the multicast session to receive the file. The number of multicast sessions is optionally adjusted according to the number of subscribed mobile stations that did not acknowledge reception yet. Optionally, repeated multicast sessions are conducted until the number of non-acknowledging subscribers is below a predetermined percentage.

The multicast sessions may be conducted substantially immediately one after the other, or may be conducted, at different times of the day, e.g., separated by an hour or two. In some embodiments of the invention, each multicast session is preceded by a notification to all the subscribers or to all subscribers that did not acknowledge receipt of the file. Delivery of the file to non-acknowledging mobile stations is optionally performed after all the multicast sessions were completed. Optionally, in these embodiments, in determining (252) whether to receive the file, mobile station 20 verifies that the file was not yet received.

Referring in more detail to tuning (254) to the multicast channel, in some embodiments of the invention, the tuning (254) to the multicast channel is performed passively by mobile station 20, without exchanging link layer packets with the network. Alternatively, before tuning onto the channel, mobile station 20 transmits a link layer message to PTMU 40, notifying that the mobile station is interested in receiving the multicast file. A PTMU 40 that did not receive responses from any mobile stations 20, optionally does not transmit the multicast data. Alternatively or additionally, the link layer responses are used by PTMU 40 to determine the layout of the mobile stations 20 interested in the multicast file in its cell. In some embodiments of the invention, PTMU 40 determines according to the received link layer responses, whether to transmit the data in multicast or in unicast or in a combination thereof. Optionally, a cost function is calculated for multicast transmission and for unicast transmission and the cheaper alternative is used. In some embodiments of the invention, the multicast transmission is given an extra preference score for the possibility that mobile stations currently in other cells will enter the cell of the PTMU 40 during the multicast transmission.

In some embodiments of the invention, the link layer responses and/or the determined mobile station layout of the cell are used in selecting parameters of the transmission, such as the power level of the transmission, the frame error protection and/or any other parameter affecting the average energy per bit of the transmission.

The parameters are optionally selected so as to ensure proper reception of the file by a percentage of the mobile stations lower than 100%, for example between 90-95%. Generally, ensuring proper reception of the file by 100% of mobile stations 20 in the cell requires a relatively large amount of resources, higher than required for achieving reception by 90-95% of the mobile stations and supplementing the rest in unicast.

Alternatively or additionally, one or more transmission parameters are selected by data server 42, so as to achieve a desired percentage of successfully receiving mobile stations 20. Optionally, the transmission parameters are automatically selected according to periodic updates on the state of the network, not received responsive to the current transmission. Alternatively or additionally, the transmission parameters are configured by a network operator according to the general structure of the network and/or the desired service characteristics. The transmission parameters controlled by data server 42 optionally include the level of redundancy of the FEC, the transmission rate and/or the number of retransmissions of the data. The selection of transmission parameters is optionally performed responsive to the average number of receivers, the size of the transmitted file and the network loss rate.

Optionally, before tuning onto the multicast channel, mobile station 20 requests an IP address to be used in receiving the data. The same IP address is optionally used for the unicast connection.

Alternatively or additionally to determining (267) whether to request the keys required for decoding the file after the supplementary data is received, in some embodiments of the invention, the determination is performed before requesting (272) the supplementary data or before establishing (260) the unicast connection, such that the supplementary data is not requested unless the keys will be requested.

Referring in more detail to establishing (260 or 264) the unicast connection, in some embodiments of the invention, mobile stations 20 determine when to request the keys at least partially randomly, so that the load on key server 36 is distributed over the waiting period. Alternatively or additionally, mobile stations 20 receiving all the data during the multicast session may contact key server 36 immediately, while mobile stations 20 requiring supplementary data contact key server 36 at a random interval after the multicast session.

Alternatively or additionally, different base stations 50 instruct the mobile stations they service, for example in the notification packets, on different times at which they are to contact key server 36. Alternatively or additionally, a plurality of key servers are provided and the notification packets instruct the mobile stations 20 as to which key server they are to contact.

In some embodiments of the invention, the multicast data may be received even by mobile stations 20 that do not have an IP address. Optionally, if the mobile station does not already have an IP address, establishing the unicast connection includes requesting an IP address from GGSN 26. In some embodiments of the invention, the unicast connection is established through a wireless application protocol (WAP) gateway. Optionally, in some of these embodiments, the entire provision of the data file, including the requesting of supplementary data and decryption keys is performed without the mobile station having an IP address.

Referring in more detail to determining (263 or 267) whether to request the keys, in some embodiments of the invention, the user decides whether to request the keys. Optionally, the decision is made based on viewing the preview. Alternatively or additionally to the user deciding whether to request the keys, the user and/or a system operator may configure the mobile station with rules on when to request the keys automatically. The rules on when to request the keys automatically may optionally be the same as the rules for receiving the file and/or may be different from the rules for receiving the data. Optionally, the preview portion of the file includes information which can be used in automatically determining whether to request the keys. For example, in providing sport clips, the data may include the teams involved or the time during the game. A user may configure his/her mobile to automatically request keys for games of a certain team and/or occurring at a specific time during the game.

Referring in more detail to providing supplementary packets in response to requesting (272) supplementary data, optionally, the mobile station determines a minimal set of packets required in order to allow reconstruction of the data file and requests these specific packets. Alternatively, the mobile station notifies server 38 which packets it received and the data server determines a minimal set of packets to be provided to the mobile station. Further alternatively, the supplementary packets include original packets, even if requiring transmission of a larger number of packets than optimal. Further alternatively or additionally, during the unicast connection mobile station 20 periodically determines whether it has sufficient packets for reconstruction and accordingly requests more packets.

The supplementary packets and/or data files provided on unicast connections are optionally provided along with the keys required for decoding the data. Alternatively, the supplementary packets and/or the data files provided on unicast connections are provided nonencoded. Further alternatively, as with multicast data, the mobile station must request the keys separately, even if on the same connection, as a verification that the data was properly received.

In some embodiments of the invention, users receiving some of the multicast files are encouraged to transfer the files to their friends using a unicast transmission service, such as

MMS. The cellular service provider receives revenues from such transmission. In addition, such transfer could induce users to subscribe. Alternatively or additionally, some multicast files are prevented from being distributed to non-subscribers, for example using digital right management (DRM) methods to limit distribution.

5. In some networks, in order for a mobile station 20 to transmit data on an application layer uplink, or even a network or transport layer link, the mobile station needs to leave the multicast connection and establish a unicast connection. In order to continue receiving the multicast data, the mobile station would need to retune onto the multicast channel. The changing of channels is generally time consuming and therefore reduces the transmission 10 quality. In the above described embodiments, each mobile station 20 is required to transmit messages to contact data server 42 only a limited number of times, for receiving the multicast file, thus simplifying the network operation in providing multicast data.

In some embodiments of the invention, each mobile station establishes only a single application layer unicast connection in order to receive the multicast data, from the receiving 15 of the notification to the reconstructing of the file. Optionally, beyond the single application layer connection, the mobile stations do not establish any transport or network layer connections in connection with receiving the data file. Alternatively to receiving the data on an application layer connection, the data may be received using a transport layer connection or even a network layer connection without using an application layer.

The uplink transmissions are optionally carried out after the multicast transmission, such that there is no need to re-tune onto the multicast channel.

Uplink application layer transmissions, as well as transport and network layer transmissions, generally differ from link layer transmissions in that link layer transmissions do not require establishing a connection. In addition, the application layer transmissions are 25 generally directed to units out of the public land mobile network (PLMN) servicing the mobile station, while link layer transmissions are directed to elements of the PLMN. The application layer transmissions of substantially all the mobile stations are generally handled by a single server or by a plurality of synchronized servers. Link layer transmissions, on the other hand, are generally handled by respective local network units which are not synchronized regarding 30 the data exchanged with the mobile stations.

In the above exemplary embodiment, the application layer uplink transmissions are for requesting supplementary data, requesting decoding keys and/or reception acknowledgement.

Alternatively to receiving the entire file before previewing and deciding whether to receive the file and/or request the decoding keys, in some embodiments of the invention, the preview may be viewed before receiving all the data. Optionally, during the multicast transmission, the preview can be reconstructed separately from the encoded data, e.g., there are separate FEC blocks for the preview. When a receiver determines that it has a sufficient number of packets for preview, the receiver optionally reconstructs and displays the preview immediately. Thus, the user can decide that the file is not desired even before receiving the entire file, so that battery power can be conserved.

Further alternatively or additionally, the notification packet indicates a series of transmission sessions. In an exemplary embodiment of the invention, the series of transmission sessions includes a preview transmission session and a data file transmission session. Optionally, the preview session is earned out a few minutes before the data transmission, so that the user has sufficient time to decide whether to receive the file before the file multicast session begins. Optionally, acknowledgements are transmitted only after the data transmission sessions. In some embodiments of the invention, users that are sure they want to receive the data file can configure their mobile station to forego receiving the preview.

In some embodiments of the invention, mobile stations 20 that need supplementary packets for the preview contact data server 42 and receive the data packets on a unicast connection. Alternatively, supplementary packets for the preview are transmitted during the file multicast session. In this alternative, mobile stations that did not receive a sufficient number of packets during the preview session, and therefore could not view the preview, begin receiving the file during the file multicast session, in case the user will decide to receive the file when the preview is viewed. If the preview is reconstructed during the file multicast session and the user decides not to receive the file, the mobile station is instructed to stop receiving the file. Optionally, the user configures the mobile station as to whether it waits for viewing the preview until the file multicast session or requests supplementary preview packets on a unicast connection. It is noted that in these embodiments mobile stations that request supplementary preview packets and request the keys for the data file will establish two unicast connections in receiving the multicast data file.

Fig. 4 is a schematic illustration of first and second public land mobile networks (PLMNs), useful in explaining cooperation between networks in providing multicast data, in accordance with an exemplary embodiment of the invention. A mobile station 320 registered for service by a PLMN A 302 is currently in a district not serviced by PLMN A, but is serviced by PLMN B 304, which has a cooperation agreement with PLMN A. PLMN B 304 delivers multicast data to subscribing users, for example using methods described above. The delivered multicast data is optionally encrypted and users pay for the decryption keys.

Generally, as is known in the art, when mobile station 320 enters the area covered by PLMN B 304, the mobile station registers with PLMN B such that it exchanges periodic servicing signals with a BSC 310 of PLMN B or with other control units of PLMN B. PLMN B notifies PLMN A that mobile station 320 is serviced by PLMN B. Unicast data connections initiated by mobile station 320 are generally tunneled to PLMN A 302 which services the data connections. Telephone calls directed to mobile station 320 are received by PLMN A which forwards the calls to PLMN B. Telephone calls generated by mobile station 320 are generally directed through PLMN B.

In some embodiments of the invention, when PLMN B provides a multicast file, mobile station 320 receives the notification packet on the upcoming multicast and determines whether to receive the multicast file. The decision is optionally performed without communicating with PLMN B at all or using only link layer communication with PLMN B. If mobile station 320 is instructed by the user to receive the file, the mobile station tunes onto the multicast channel and receives the packets of the file. The multicast data is provided from a data server 344 of PLMN B through BSC 310. Optionally, PLMN B does not know whether mobile station 320 received the multicast data and therefore cannot, for example, generate a charge data record (CDR) for the mobile station 320.

Thereafter, mobile station 320 contacts a data server 342 of PLMN A to request supplementary data, if necessary, and deciphering keys. The contact with data server 342 is optionally performed through an SGSN 333 of PLMN B and a GGSN 337 of PLMN A. Data server 342 of PLMN A requests the keys and supplementary data from data server 344 of PLMN B and provides the keys back to mobile station 320. If unicast delivery is required, e.g., mobile station 320 is subscribed to receive the file but did not receive the notification, the unicast delivery is performed by data server 342 of PLMN A. Optionally, a data server of PLMN A authorizes and charges mobile station 320 for the data file.

Alternatively to providing the multicast data in a different cellular network, the multicast data may be provided on a totally different type of network, such as on a terrestrial network (e.g., a digital video broadcast terrestrial (DVB-T) network), or a satellite broadcast channel (e.g., a digital video broadcast satellite (DVB-S) network or any other digital broadcast satellite (DBS) network). Further alternatively, the multicast data is provided in a cellular network, while the supplementary data and/or keys are provided in a different type of network, for example on a wireless local area network (WLAN). In some embodiments of the invention, the acknowledgement, keys and/or supplementary data may be provided on a plurality of networks. Optionally, the receiver attempts to respond on the network with the most local coverage, e.g., a wireless LAN network. If the transmission on the most local network is not successful, the receiver attempts to respond on a network with a greater coverage, e.g., a cellular network. If the transmission on the cellular network is not successful, an attempt to respond is made on a terrestrial or satellite network, for example on a satellite uplink ALOHA channel.

In some embodiments of the invention, PLMN A provides the same multicast data at substantially the same time as the data is provided by PLMN B. In this embodiment, PLMN A does not need to contact PLMN B for supplementary data. PLMN A may, however, need to request the encryption keys from PLMN B. Alternatively, PLMN A does not provide the data at the same time as PLMN B, Optionally, PLMN B provides supplementary data upon request from PLMN A. Alternatively, for example when many supplementary data requests are expected, PLMN B provides all the data to PLMN A in parallel to transmitting the multicast data. In some embodiments of the invention, supplementary data received by PLMN A is cached for further use for a predetermined time in which additional requests may be received.

In some embodiments of the invention, contacting data server 342 of PLMN A by mobile station 320 includes establishing a data channel. Establishing the data channel optionally includes receiving an IP address and/or a packet data context. The packet data context optionally includes setting a QoS for the data channel.

In some embodiments of the invention, each PLMN advertises a unique ID of the PLMN in the control signals it transmits. Different PLMNs optionally communicate with each other through gateways that are used for security.

It will be appreciated that the above described methods may be varied in many ways, including, changing the order of steps, and the exact implementation used. The methods of the present invention may be performed in various protocol layers and may be performed for a single transmission system in a plurality of communication protocol layers. It should also be appreciated that the above described methods and apparatus are to be interpreted as including apparatus for carrying out the methods and methods of using the apparatus.

The present invention has been described using non-limiting detailed descriptions of embodiments thereof that are provided by way of example and are not intended to limit the scope of the invention. For example, in some embodiments of the invention, mobile stations are required to acknowledge the notification packet and unicast notifications are transmitted to non-acknowledging mobile stations.

It should be understood that features and/or steps described with respect to one 5 embodiment may be used with other embodiments and that not all embodiments of the invention have all of the features and/or steps shown in a particular figure or described with respect to one of the embodiments. Variations of embodiments described will occur to persons of the art.

It is noted that some of the above described embodiments may describe the best mode 10 contemplated by the inventors and therefore may include structure, acts or details of structures and acts that may not be essential to the invention and which are described as examples. Structure and acts described herein are replaceable by equivalents which perform the same function, even if the structure or acts are different, as known in the art. Therefore, the scope of the invention is limited only by the elements and limitations as used in the claims. When used 15 in the following claims, the terms comprise, include, have and their conjugates mean including but not limited to.