WO2007052233A1

WO2007052233A1 - Streaming multicast communications over radio lans

Info

Publication number: WO2007052233A1
Application number: PCT/IB2006/054105
Authority: WO
Inventors: Salvador Boleko; Wolfgang O. Budde
Original assignee: Koninklijke Philips Electronics, N.V.; U.S. Philips Corporation
Priority date: 2005-11-04
Filing date: 2006-11-03
Publication date: 2007-05-10

Abstract

A system of method for multicasting streaming media content over a radio local area network involves initially determining (214) a link quality of the link between each of the plurality of multicast receivers and an access point of the radio local area network. Each of the links between the plurality (220) of multicast receivers and the access point are divided into a plurality of groups wherein each of the plurality of groups includes links having a similar link quality. A single representative of each of the plurality of groups is selected (223), and an analysis is performed on the selected representative for each of the groups to determine transmission settings for each of the groups. The packets of the streaming media content are then transmitted (210) from the access point to each of the plurality of multicast receivers a plurality of times. Each of the plurality of times is associated with one of the determined transmission settings for the plurality of groups.

Description

STREAMING MULTICAST COMMUNICATIONS OVER RADIO LANS

Bandwidth efficiency is an especially relevant issue to radio communications as an air interface provides an error-prone medium, and the available bandwidth on an air interface is generally scanty.

Any form of network communication that transmits information to multiple recipients, which have been configured as members of a so-called multicast group, can take advantage of the bandwidth efficiency provided by multicasting. Thus, the use of multicast can be relevant to One-to-many communications, i.e., simultaneous distribution of contents, or; Many-to-many communications, i.e., distributed applications. In home environments, examples of the former can be found in form of (live) streaming media, synchronization or download to multiple clients, or protocol control messages distribution. Examples of many- to-many communications are groupware multimedia applications like audio and videoconferencing, IP-based telephones and videophones, multimedia chat or on-line multiple player gaming.

Streaming multimedia over IEEE 802.11 radio local area networks operate in an infrastructure mode. IEEE 802.11 radio devices must communicate with each other by first going through an access point. In addition, radio devices can communicate with each other by first going through an access point. Radio devices may also communicate with each other or can communicate with a wired network. When one AP is connected to a wired network and a set of radio stations it is referred to as a basic service set (BSS). An extended service set (ESS) is a set of two or more BSSs that form a single sub-network.

Radio channels can offer limited and time- varying quality of service (QoS) for the streaming of multimedia traffic. The channels become stressed because of the large amount of bandwidth required by multimedia streaming traffic and its error rate and usually stringent timeliness requirements, e.g., the maximum allowed delay ranges from 200 ms to few seconds depending on the level of interaction.

This multicast streaming multimedia traffic over radio packet networks in general demands adaptability to the bandwidth fluctuations, robustness to partial data loss and support for heterogeneous clients regarding bandwidth, processing capabilities, buffer availability and power limitations.

The last-hop scenario, between the access point and the radio stations, is likely to be the bottleneck of the whole streaming path for IEEE 802.11 radio networks while in infrastructure mode operation. As such, the ideas of multicast trees or those of reliable and resilient multicast techniques may not directly apply to the present case, since there is just one hop between the root and the recipients. Although, it should be noted that the streaming source might well be not co-located with the AP, and not even be a radio station belonging to the same BSS as the receivers.

Multimedia data is normally compressed before being transmitted or stored. Traditional source-coding methods referred to as fixed-rate or single-resolution coding compress the data to a target bandwidth or a target storage size. Many such techniques exploit data dependency to achieve high compression ratios. However, this also introduces interdependency of data in the compressed form. Consequently, errors in this compressed data due to unreliable transmission may render as significant artifacts after the compressed data is decoded. Single-layer coding works well for application domains where a certain media storage size is targeted or whenever low data rates and dedicated bandwidths are available to each data channels.

However, such methods cannot be adapted to error-prone and fluctuating bandwidth transmission media like the one observed in radio packet networks. For radio packet networks, progressive (also scalable) coding is better suited. In scalable coding, multimedia data are divided into coding units e.g. frames, and within those units, the data are arranged such that the most important part are placed in the beginning followed by the parts with successively lower importance. The decoding of the data within a coding unit can be partial, and the more data that can be decoded, the better the quality of the decoded multimedia data. Additionally, this can be different coding schemes can be applied to different parts.

When besides multicast communications is considered, coding must be accommodated as well to the expected heterogeneity in link conditions, but also capabilities and requirements, for different receivers, Thus, there are many approaches including Replicated Stream approach, Non-cumulative layering approach, and Cumulative layering approach.

In the replicated stream approach, the source multicasts several streams with identical contents but are monolithically encoded at different data rates, applying different source or channel coding schemes, and perhaps transmission parameters. Each stream is multicast over its own multicast group. Receivers subscribe to that stream, which instantaneously better suits to their capabilities, available bandwidth and perceived link condition. Besides they may switch among streams, as their capacity changes, by leaving and joining multicast groups.

As a drawback it requires on the one hand a high amount of processing power at the transmitter side, especially when handling live contents, in order to generate in a timely manner, i.e., real time, the differently encoded streams to be multicast. On the other hand, the bandwidth requirements can be quite high for the same case, as streams should be simultaneously distributed across multiple groups.

In the non-cumulative layering approach, the stream is encoded in two or more independent layers. Each layer is independently decodable and provides improvements to the reception quality. Each layer is multicast on its own multicast group by a source. Each receiver can receive any subset of layers, but it does not need to specifically join a particular multicast group. For instance, the so-called multiple description coding can be used for that purpose.

In the cumulative layering approach, the stream is encoded in a base layer and one or more enhancement layers (several RTP simultaneous sessions can be used to this purpose). The base layer can be independently decoded along with the layers. The enhancement layers contribute to the quality improvement that leads to the progressive refinement. Each layer is multicast on its own multicast group by a source. Receivers join at least the layer multicast group and either add on spare capacity, or drop, on congestion, other layers according to their reception capacity and link condition.

When IEEE 802.11 multicast communication and the DCF medium access mechanism is in use, no error detection mechanism is made available by the standard. Thus, link conditions' assessment can be only performed through long-time scale RTCP reports, whose periodicity decreases as the number of receivers increases. The course granularity yielded by this mechanism severely reduces the effectiveness and speed of response of any link-adaption mechanism available, particularly those highly-effective, available at the lower layers of the OSI protocol stack, which are auxiliary to those coding- based solutions presented in the last paragraph, which are available at the application layer. Instances of the former ones are the exploitation of the different transmission modes (modulation and channel coding presets defined by the standard) and the control of the transmit power. Additionally, the lack of any virtual handshake mechanism together, yields very low reliability because of the increased risk of collisions. On the other hand, the stringent timeliness requirements of multimedia streaming render the usual reliable multicast solutions at the transport layer useless and prejudicial. Even if short-time scale feedback could be provided to the transmitting source, permitting the adoption of an ARQ scheme, it would trim bandwidth, which is rather a scantly resource in the case of study and, at the same time, would jeopardize the fulfillment of the timeliness requirements of multimedia streaming traffic.

Finally, in any case, the likely contradicting link conditions reported to the sender, corresponding to different receivers, require being mapped into single and consistent link adaptation decisions.

The present invention disclosed in claim herein, in one aspect thereof, comprises a system and method for multi-casting streaming media content over a radio local area network. An access point within the radio local area network is configured to determine a link quality of a link between each of a plurality of multicast receivers and the access point of the radio local area network. The access point divides each of the links between the plurality of multicast receivers and the access point into a plurality of groups. Each group includes links having similar link quality. The access point selects a single representative from each of the plurality of groups and performs analysis on the selected representatives to determine transmission settings for an associated group. Finally, the access point transmit packets of the streaming media content from the access point to each of the plurality of multicast receivers a plurality of times. Each of the plurality of times is associated with one of the determined transmission settings for one of the plurality of groups. The above summary of the invention is not intended to represent each embodiment or every aspect of the present invention.

A more complete understanding of the method and apparatus of the present invention may be obtained by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein:

FIGURE 1 illustrates the operating environment of the present disclosure;

FIGURE 2 is a flow diagram illustrating the multicasting method with a radio local area network ;

FIGURE 3 is a flow diagram illustrating the method for using the method described in Figure 2 if a packet loss rate is acceptable; and

FIGURE 4 is a flow diagram illustrating a transmission of packets according to established transmission settings. Referring now to the drawings, and more particularly to Figure 1, there is illustrated the operating environment of the present disclosure. A multi-media source 102 provides streaming multimedia content to an access point 104. The access point 104 is responsible for multi-casting the provided streaming media content to the plurality of multi-task receivers 106 within a single multicast group. The access point 104 and multi-cast receivers 106 each include individual communication links 108 between the access point 104 and receiver 106. While the multi-cast group illustrated in Figure 1 includes only three multicast receivers 106, a multicast group may include any number of multicast receivers 106. Furthermore, the access point 104 may have connections with multiple multicast groups and not just a single multicast group.

An enhanced AP 104 that incorporates an IEEE 802.1D/Q-compliant bridge is needed. The reason for such requisite is three-fold. First, it allows prioritized network traffic to preserve its priorities while conveyed over the network. Second, 802.1D/Q devices apply the so-called GARP Multicast Registration Protocol (GMRP) protocol, which allows end stations and MAC bridges to dynamically exchange group membership information, and distribute it across a bridged LAN capable of taking over some routing tasks and yielding efficient management at the data link layer of multicast traffic all over the LAN. Finally, it becomes assured that the AP 104 can straightforwardly associate the individual MAC addresses of the receivers corresponding with those of the different multicast groups they are subscribed to.

Referring now to Figure 2, there is illustrated the process for streaming multicast communications over a radio local area network. Initially, the AP 104 must collect information on link quality from each of the receivers subscribed to the multicast group. Many different approaches can be followed in order to gather the afore-mentioned information. The collection of link quality information is initiated at step 202. Initially at step 204, a reset and start timer is reset to 0. The reset and start timer measures the period between clusterings as will be described more fully herein below. The timer is incremented by one at step 206 and inquiry step 208 determines if any packets have been received, at the access point 104 from the multimedia source 102. If any packets have been received, the packets are transmitted at step 210 to the multicast receivers 106 within a multicast group according to the previously established transmission settings. Once the packets have been transmitted or if no packets are to be sent at inquiry step 208, inquiry step 212 determines if link quality information should be fed back to the access point 104. If so, the feedback information is provided to the access point at step 214. This will be more fully described herein below.

If there is no need to obtain feedback from the access point 104 or once the feedback has been obtained at step 214, inquiry step 216 determines if the end of the minimum period between the clustering of communications links between the access point 104 and multicast receivers 106 has been reached. If not, control passes back to inquiry step 208. If the end of the minimum clustering period has been reached, the link quality estimates for the communication links 108 between the access point 104 and receivers 106 may need to be updated at step 218. After the update, inquiry step 220 determines if clustering of the communication links 108 is needed. If not, control passes back to step 206 and the timer is again incremented by one. If clustering is needed the clustering estimates are performed at step 220 as will be more fully discussed herein below. A determination of whether a clustering is needed may be based upon latency, jitter and PLR readings within the communication links 108 between the access point 104 and receivers 106 or a determination that the maximum number of periods during which a previous clustering has remained unchanged has been reached.

One example for collecting link quality information involves monitoring RTCP control packets. Useful information can be extracted from received RTCP control packets that are regularly sent from receiving terminals to a streaming source. If the multimedia- streaming source is not co-located with the AP 104, the enhanced AP 104 should have the ability to snoop the packets sent by the receiving terminals in a multicast group to the source, so as to obtain the RTCP report. Such operation, should not generate too high a processing overhead within the AP 104 since the number of receivers associated with multicast group, in for example an in-the-home streaming scenario, is expected to be low or moderate, and the issue frequency of RTCP reports is relatively low (as the commended value for a fixed minimum interval is 5 seconds, per receiver).

RTCP can only provide a long-time-scale feedback on link quality for every multicast receiver. For that reason, a supplementary mechanism meant to provide short- time-scale feedback to the AP 104, for example the mechanism disclosure in selective Acknowledgement for Multicast Communications European Patent Application Number 04106594.7 filed on 15 December 2004 (Attorney Docket No. PHNL041404EPP) which is incorporated herein by reference. Parameters like RSS, SINR or similar measurements, which depict link quality, are collected and, under the assumption that the link is symmetrical, are used by the enhanced AP 104 to estimate the channel condition at the receiver side.

In spite of its long periodicity, the long-time-scale feedback, still plays a relevant role as it determines the need for the herein described solution to be sparked, as in case that with the ordinary multicast transmission procedure, the delay and reliability QoS constraints of the conveyed traffic (i.e., jitter and error rate) are met for every terminal member of the multicast group, then the present solution should not be activated.

Provided that radio terminals make up the addressed multicast group, then each receiver can be associated at a time interval one measurement that aggregates the previously introduced magnitudes.

In accordance with the scheduling of RTCP reports, and a short-time-scale feedback collection mechanism, the readings on link quality available at the AP 104 are gathered asynchronously at step 214 for each terminal. Consequently, the feedback data might not be up-to-date at the evaluation time. Thence, some sort of estimate of the updated values have to be computed at step 218. To that purpose a prediction scheme should be incorporated to create the estimates of the link quality values (e.g., linear prediction, Kalman filter, etc).

Once the set of available readings has been substituted by the set of estimated values, the readings go through a cluster analysis stage. As a result of it, the (multivariate) readings are classified into a number of sets at step 220, determined according to the similarity of the link quality between the various readings.

Some cluster analysis techniques are known to determine the most suited value for the number of clusters to be selected. Notwithstanding that possibility, the selection of the number of clusters to be evaluated should in any case trade-off the statistical criteria, the delay budget and packet loss rate of the on-going transmission as well, in order to take into account the error rate and timeliness constraints imposed to the streaming traffic.

Thus, as illustrated in Figure 3, if for any reason a packet loss rate that is much lower than the threshold value beyond which it should be deemed as unacceptable, as determined at inquiry step 302, is observed throughout the multicast group members, there is no reason to trigger the herein described retransmission scheme at step 304, as it would only add processing and power overhead providing no extra benefit. Thus, the scheme is not triggered at step 305 and the transmission should proceed as it was, until the next evaluation time at step 306. Since cluster analysis methods can yield many different locally optimal solutions, i.e., there is not a single exact solution, this fact explains the flexibility to consider the timely delivery constraints, as well as to adopt one of the many available algorithms and approaches to address the cluster analysis problem. Examples include:

Non-hierarchical: Lloyd's algorithm (also known as k-means), latent class, expectation maximization and alike and alike

Hierarchical

Agglomerate

Divisive

Once the data, and thus the receivers subscribed to the multicast group, have been grouped into clusters, one of the available readings in each cluster is chosen (computed) at step 222 as representative of the whole cluster. A comprehensive and sensible choice may be electing the worst-case reading as a representative, although other alternatives may be used. As soon as a representative reading has been selected for every cluster, the link- adaptation scheme available at the enhanced AP 104 is to be run at step 224 on the values of each selected representative, in order to evaluate the transmission mode, i.e., modulation scheme and channel coding scheme, and transmit power level, which are best suited to the observed link quality for the members of the cluster. Any repeated settings are removed at step 226.

Then, the AP 104 has to deliver the packet to the members of the multicast group. To that purpose the enhanced AP 104, must send the same packet as many times as clusters have been built for the multicast groups. Each time the AP 104 applies to the same packet the settings that have been calculated in the previous step for each cluster's representative. Moreover, the packet should be beamed using progressively more robust transmission settings, that is, using the least robust transmission mode and transmit power level first. However, alternative orders of use of the settings may be selected.

Referring now to Figure 4, there is more fully illustrated a flow diagram of the packet transmission process. Initially, at step 402 the transmission order of the transmission settings for each cluster is established. In a preferred embodiment, the transmission settings are used from their least robust transmission mode and transmit power level to progressively more robust settings for transmission mode and power level. However, it should be realized that any particular transmission setting order may be established according to the needs of the particular multicast operation. Next, a packet is received at step 404 by the access point 104 for transmission to the receivers 106 over the communication links 108. The access point 104 is initially tuned to the first established transmission settings at step 406. In the manner described herein above for the preferred embodiment, these settings would be the least robust transmission road and transmit power level. The packet is then transmitted from the access point at step 408 to each of the members of the multi-cast group using the established transmission settings. Inquiry step 410 determines if additional transmission settings have been established for other clusters within the multicast group. If so, control passes back to step 406, and the transmission settings for the next cluster are then established within the access point 104. It is important to note that the transmission settings used for transmission to the multicast receivers 106 are used to transmit to each of the multicast receivers 106, not just the members within the cluster for which the transmission settings were established. Once inquiry step 410 determines that additional transmission settings do not exist, inquiry step 412 determines if additional packets for transmission from the access point exist. If so, control passes back to step 404 and the additional packets are received. If no additional packets are available, the process ends at step 412.

At this point it must be carefully observed, that irrespective of which the members of the cluster the transmission settings have been computed for, the duplicates of the frame are transmitted to the whole multicast group, for each group of settings, i.e., they have as destination MAC address that of the original multicast group. In other words, no reconfiguration of the multicast group is initiated or actuated by the AP 104. The addressed multicast group remains the same at every duplicate sending with the new transmission settings.

In observance of the current IEEE 802.11 protocol standards, provided that the resulting number of clusters is greater than one, the subsequent sending instances of the same frame shall be sent with the Retry field set, in order to help those receivers in the multicast group which might have already successfully received the frame, to filter out this duplicate frame at the MAC sub layer, thereby saving any extra processing overhead. Receiving terminals must also keep a cache of the previously received tables holding the destination address, the so-called sequence number and the number of fragment in order to be able to reject duplicate frames similar to when unicast mode is in use. A correct performance of the duplicate filtering mechanism is especially relevant to avoiding receivers getting more than one copy of an RTP packet, which would corrupt the RTCP statistics.

In order for the proposed re-transmission scheme to succeed, the duplicates of the packet should not collide with ongoing upstream traffic that is sent from receivers to the AP, in the BSS associated with the enhanced AP. To that purpose, and assuming that either DCF or EDCA transmission modes are in use, the AP should adopt as a length of the interval between any two duplicates of the same packet values ranging from a SIFS (Short Inter-Frame Spacing) to a DIFS (Distribute Inter-Frame Spacing) so as not to collide with any pending unicast ACK nor to let the medium be sensed as free by any other node.

Finally, the issue of how often should the clustering take place should be addressed. As mentioned earlier with respect to Figure 2, the algorithm to be effective has to count the timeliness constraints and actual status of the on-going transmission. Thereof, it is suggested that a minimum value for the period between clustering is specified as the CLUSTERING PERIOD. Similarly, a maximum value of consecutive periods during which the clustering is allowed to remain unchanged without re-evaluation should be fixed. So, at the end of every CLUSTERING PERIOD at step 216, if the boundary of periods without reclustering has been reached (step 200) the enhanced AP carries out a clustering at step 220 on the stored link quality information. Otherwise, the AP resolves, according to the delay budget and packet loss rate of the on-going transmission, the convenience of undergoing a new clustering state. Whichever the case, it is suggested that due to plausible correlation, the last computed outcome of the clustering state be used as initialization to the algorithms in the current one, where necessary.

Pseudo-code describing the solution is illustrated as follows:

Wait : DO

Wait ( ) :

/* In parallel the AP 104 sends data and collects link-quality info */ waiting_ρeriods := waiting_periods +1;

WHILE period_ends (CLUSTERΪNG_PERIOD) estimates : = update_available_readings (readings) ;

IF (waiting_periods , , MAX_NO_SUCCESSIVE_PERIODS) AND

(NOT clustering_needed (delay_budget, packet_loss_rate) ) THEN

GOTO wait;

Clusters := carry out taxonomy (estimates); Representatives := choose_representatives (clusters, estimates) ; settingsO := link_adaptation (representatives) ; no_clusters := size (clusters) ; no_replicates :=1;

FOR i = 1 TO no_clusters

Repeated_settings [i] := FALSE;

END

FOR i = 1 TO no_clusters

IF (repeated_settings [i]== FALSE) THEN repeated_settings [i]:= YES; Settings [no_reρlicates] :=settingsθ [i] No_replicates := no_replicates +1; FOR j=l TO no_clusters

IF (settingsO [i] == settingsO [J]) THEN repeated_settings [j]:=TRUE; END END

AP 104_sends_ρackets (no_replicates, settings) ; GOTO wait

The main features of the described disclosure can be summarized as follows:

Compatibility with any IEEE 802.11 compliant devices associated to the enhanced AP while at the same time, each associated IEEE 802.11 radio receiver takes advantage of the improved performance and streaming experience.

Feedback on the link quality is available on two time scales:

On the one hand short-time scale (in the order of tenths of milliseconds) feedback is collected at the link layer, which enables adaptation to the fast dynamics of the channel.

On the other hand, auxiliary long(er)-time scale (in the order of seconds) feedback can be compiled at the transport layer, as far as the assumption of a moderately large number of devices holds true, which allows for a more stable response from the underlying adaptation scheme.

Handling of the inherent heterogeneity of the link quality associated with radio multicast communication, through a fast and robust retransmission scheme.

To that purpose, the AP regularly performs taxonomy on the link-quality measurements fed back to it. As a result, multicast group members showing similar link condition are bunched together and different transmission settings are computed for each cluster. Then, differently adapted copies of the same packet, which provides multicast- aware link adaptation, are transmitted to the multicast group one after the other, so that on the one hand the heterogeneity within the group can be addressed, and on the other hand a re-transmission-based error recovery scheme is introduced.

Besides, as an enhanced AP is the node that has been chosen to locally act as a replicating source on the last-hop of the transmission path, all of this is accomplished without any significant extra cost regarding neither increased network congestion nor latency due to the feedback scheme whereas, contrary to any multiple parallel unicast approach, the synchronization among receivers inherent to multicast communication is kept. Increased robustness of multicast streaming to either:

Channel impairments experienced by the receivers or;

Risk of collisions with up-streamed traffic, i.e., sent to the AP, during its transmission, which is by definition augmented for the multicast communication due to the lack of any virtual carrier sense mechanism or;

Risk of collisions due to not all the receivers in the multicast group being ready to receive the transmitted frame; e.g., due to an occurrence of the so-called hidden node problem, where two wide apart nodes on the network may be unable to communicate with each other and still interfere with transmissions to an intermediate node.

Through sound re-transmission, a resilient soft-real time scheme is achieved for the case of study, which should not in any case be mistaken for a hard real-time reliable multicast one, as full reception of every frame by every receiver in the multicast group is not intended. The adopted feedback scheme operates at the data link layer, guarantees a minimum spent in form of extra bandwidth required for feedback, adjusted to the status of the real-time transmission at the same time that it allows for prompt retransmission.

Many variations and embodiments of the above-described invention and method are possible. Although only certain embodiments of the invention and method have been illustrated in the accompanying drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of additional rearrangements, modifications and substitutions without departing from the invention as set forth and defined by the following claims.

Claims

CLAIMSWhat is claimed is:

1. A method for multicasting streaming media content over a radio local area network, comprising the steps of: determining (214) a link quality of a link between each of a plurality of multicast receivers and an access point of the radio local area network; dividing (220) each of the links between the plurality of multicast receivers and the access point into a plurality of groups, wherein each group includes links having a similar link quality; selecting (222) a single representative from each of the plurality of groups; performing (224) analysis on the selected representative for each of the groups to determine transmission settings for each of the groups; and transmitting (408) each packet of the streaming media content from the access point to each of the plurality of multicast receivers a plurality of times, each of the plurality of times associated with one of the determined transmission settings for the plurality of groups.

2. The method of Claim 1, wherein the step of determining further comprises the steps of: determining (214) feedback on the link quality of the links between each of the plurality of multicast receivers and the access point at a link layer; and determining (214) the feedback on the link quality of the links between each of the plurality of multicast receivers and the access point at a transport layer, wherein the feedback determined at the transport layer occurs on a longer time scale than the feedback determined at the link layer.

3. The method of Claim 1, wherein the step of determining further comprises monitoring RTCP control packets from the plurality of multicast receivers to a source of the streaming media content to determine feedback at a first time scale.

4. The method of Claim 3, wherein the step of determining further comprises the steps of: collecting (214) link quality measurements at the access point (104); estimating (218) the link quality at the plurality of multicast receivers based upon the link quality measurements collected at the access point; and wherein the estimated link quality measurements are made at a second time scale shorter than the first time scale.

5. The method of Claim 1 , further including the step of estimating (218) updated values of the link quality for at least one of the selected single representatives from each of the plurality of groups using a prediction scheme.

6. The method of Claim 1 , wherein the step of selecting further comprises the step of selecting (222) a worst-case readings member of the group as the single representative of the group.

7. The method of Claim 1, wherein the step of determining further includes the steps of: determining (302) if a packet loss rate exceeds a predetermined threshold value; and determining (304) a link quality of a link between each of a plurality of multicast receivers and an access point of the radio local area network, if the packet loss rate exceeds the predetermined threshold value.

8. The method of Claim 1, wherein the transmissions for each of the plurality of times proceeds from a least robust transmissions setting for a group to a most robust transmission setting.

9. A system for multicasting streaming media content over a radio local area network, comprising: an access point (104) for communicating with a plurality of multicast receivers, the access point configured to: determine (214) a link quality of a link between each of the plurality of multicast receivers and the access point of the radio local area network; divide (220) each of the links between the plurality of multicast receivers and the access point into a plurality of groups, wherein each group includes links having a similar link quality; select (222) a single representative from each of the plurality of groups; perform analysis on the selected representative for each of the groups to determine transmission settings for each of the groups; and transmit (408) each packet of the streaming media content from the access point to each of the plurality of multicast receivers a plurality of times, each of the plurality of times associated with one of the determined transmission settings for the plurality of groups.

10. The system of Claim 9, wherein the access point (104) is further configured to: determine (214) feedback on the link quality of the links between each of the plurality of multicast receivers and the access point at a link layer; and determine (214) the feedback on the link quality of the links between each of the plurality of multicast receivers and the access point at a transport layer, wherein the feedback determined at the transport layer occurs on a longer time scale than the feedback determined at the link layer and be aware of the degree of fulfillment of the timeliness requirements of the on-going transmission.

11. The system of Claim 9, wherein the access point (104) is further configured to monitor RTCP control packets from the plurality of multicast receivers to a source of the streaming media content to determine feedback at a first time scale. he system of Claim 11, wherein the access point (104) is further configured to: collect (214) link quality measurements at the access point; estimate (218) the link quality at the plurality of multicast receivers based upon the link quality measurements collected at the access point; and wherein the estimated link quality measurements are made at a second time scale shorter than the first time scale.

12. The system of Claim 9, wherein the access point (104) is further configured to estimate (218) updated values of the link quality for at least one of the selected single representatives from each of the plurality of groups using a prediction scheme.

13. The system of Claim 9, wherein the access point (104) is further configured to select (222) a worst-case readings member of the group as the single representative of the group.

14. The system of Claim 9, wherein the access point (104) is further configured to: determine (302) if a packet lose rate exceeds a predetermined value; and determine (304) a link quality of a link between each of a plurality of multicast receivers and an access point of the radio local area network, if the packet lose rate exceeds the predetermined value.

15. The system of Claim 9, wherein the transmissions for each of the plurality of times proceeds from a least robust transmissions setting for a group to a most robust transmission.

16. The system of Claim 9, wherein the access point (104) while transmitting takes into account an availability of a delay budget of an on-going streaming transmission to repeatedly beam the packet to the multicast group as many times as different computed transmission settings.