Abstract:
In one embodiment, a hybrid packet repair scheme adaptively switches among unicast retransmission, multicast retransmission, and Forward Error Correction (FEC) depending on the receiver population and the nature of the error prompting the repair operation. The NACK patterns are used to heuristically determine the degree of correlation among packet losses. In an additional embodiment, wasting bandwidth and processing on retransmissions of FEC that will fail to correct the errors is avoided by evaluating the nature of the error and the bandwidth needed to optimally repair it. Unicast retransmission, multicast retransmission, or FEC repair is then dynamically performed according to the loss patterns derived from the NACK arrivals and other network conditions.

Description:
TECHNICAL FIELD 
       [0001]    The present disclosure relates generally to the field of networking. 
       BACKGROUND 
       [0002]    Packet switch networks are now being used to transport streaming media, such as video and audio from a media server to multiple receivers, such as computer terminals and Set Top Boxes (STBs). However, packet switched networks typically use a best effort scheme that may significantly delay or drop some packets. Retransmission schemes have been designed to retransmit the dropped or delayed media packets to receivers. 
         [0003]    Unicast retransmissions of multicast streams is an attractive recovery technique when the errors are uncorrelated, such as errors occurring on the individual accesses branches connected to the receivers. This may include errors on subscriber access lines of a Digital Subscriber Loop (DSL) network. In these cases, the probability is small that the packet loss is due to errors on a shared link upstream of the branching to the individual receivers compared to the errors in the individual access links themselves. Conversely, unicast retransmission is a poor solution for either correlated errors or long burst errors. This is primarily because of Negative ACKnowledgment (NACK) implosion where many receivers request retransmissions of the same packets at the same time. The bandwidth multiplication of sending many unicast copies of the same repair packet may prevent packet repair. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0004]      FIG. 1  is a block diagram of a network that uses a hybrid packet repair scheme. 
           [0005]      FIG. 2  is a more detailed diagram of repair point that operates the hybrid packet repair scheme shown in  FIG. 1 . 
           [0006]      FIG. 3  shows examples of NACK table states used when selecting between different types of repair schemes. 
           [0007]      FIG. 4  is a flow diagram showing on a high level the operations performed by the hybrid packet repair scheme shown in  FIGS. 1 and 2 . 
           [0008]      FIG. 5  is a flow diagram showing different parameters used by the hybrid packet repair scheme. 
           [0009]      FIG. 6  is a flow diagram showing how the hybrid packet repair scheme determines a NACK density. 
           [0010]      FIG. 7  is a flow diagram showing how the hybrid packet repair scheme considers different error correction and network parameters when selecting particular repair schemes. 
           [0011]      FIG. 8  is a flow diagram showing how the hybrid packet repair scheme may operate with a low NACK density. 
           [0012]      FIG. 9  is a flow diagram showing how the hybrid packet repair scheme may operate with a high NACK density. 
       
    
    
     DESCRIPTION OF EXAMPLE EMBODIMENTS 
     Overview 
       [0013]    In one embodiment, a hybrid packet repair scheme adaptively switches among unicast retransmission, multicast retransmission, and Forward Error Correction (FEC) depending on the receiver population and the nature of the error prompting the repair operation. The NACK patterns are used to heuristically determine the degree of correlation among packet losses. In an additional embodiment, wasting bandwidth and processing on retransmissions of FEC that will fail to correct the errors is avoided by evaluating the nature of the error and the bandwidth needed to optimally repair it. Unicast retransmission, multicast retransmission, or FEC repair is then dynamically performed according to the loss patterns derived from the NACK arrivals and other network conditions. 
       DESCRIPTION 
       [0014]      FIG. 1  shows an Internet network  12  that includes a packet switched network  40  that includes multiple different nodes  42 - 48 . The nodes  42 - 48  may be routers, switches, gateways, call accumulators, or any other network processing device that directs packets  24  to different receivers  50 . A media server  14  outputs one or more media streams  22  that each include a sequence of media packets  24 . The media server  14  could store the media locally or receive the media from another server or media source via another network, satellite, cable, or any other communication media. 
         [0015]    The media server  14  may send the media packets  24  to any combination of different receivers  50  via the packet switched network  40 . The receivers  50  can be any device that receives media packets  24 . For example, the receivers  50  could be Personal Computers (PCs), Set-Top Boxes (STBs), Personal Digital Assistants (PDAs), Voice Over Internet Protocol (VoIP) phones, Internet connected television, cellular telephones, etc. Any combination of media packets  24  may be dropped, lost, and/or delayed for any number of different reasons at different points along the network paths from media server  14  to the different receivers  50 . 
         [0016]    A retransmission server is alternatively referred to as a repair point  16  and receives and caches the media packets  22  sent to the receivers  50  by media server  14 . Any of the receivers  50  that do not successfully receive any of the media packets  24 , sends an associated NACK message  26  back to the retransmission server  16 . The retransmission server  16  uses a hybrid packet repair scheme  20  to dynamically send different types of unicast retransmission packets  32 , multicast retransmission packets  34 , and/or FEC packets  36  according the characteristics of the NACKs  26  received back from the receivers  50 . 
       Analyzing Lost Packets 
       [0017]    An error or lost packet refers to any media packet  24  that is not successfully received by one of the intended receivers  50  within an expected time period. A correlated error refers to different packet losses that are related to each other. For example, all of the packet losses identified by receivers  50  connected to node  44  may be due to the same packets being dropped somewhere between node  42  and node  44 . Correlated errors can be due to losses/outages on the backbone/regional network upstream of repair point  16 . Correlated errors can also be due to losses/outages on the shared links/tunnels  54  through the packet network  40  connecting to the access links  56  for receivers  50 . Other correlated errors may relate to common-mode losses on the individual access links  56  due to crosstalk or external impulse events like a lightning strike. 
         [0018]    The FEC packets  36  may be used when the error spread is large (i.e. the error affects a random subset of the packets in a particular time window) and the number of lost packets is within the error correction coverage scope. The coverage scope and window are tuned by varying a constant bandwidth overhead and source block size for the FEC stream. 
         [0019]    The FEC repair scheme described below may use Digital Video Broadcast (DVB) COP3 and/or Raptor-10 codes, which allow the FEC packets  36  to be sent separately from the main media stream  22  as opposed to error correction schemes that re-encode the original media packets  24  to include the FEC. Of course any other type of error correction scheme which puts the error correction data in different packets from the native media could also be used. 
         [0020]    FEC may use more bandwidth than needed when the correlated errors are single packets or short bursts. For example, a single packet or a small group of packets may be identified as lost by multiple receivers  50 . In these conditions, a single multicast retransmission using multicast packets  34  may be more efficient than FEC. For example, multicast repair may only need to multicast one lost packet with a single multicast retransmission (barring further errors) that reaches all the receivers identifying the loss. In contrast, the FEC repair may require sending multiple repair packets. 
         [0021]    For outages or long burst losses (i.e. too large to be covered by FEC) nothing may work particularly well. This is partly because of the persistent NACK implosion effect, but mostly because the network  12  is rarely engineered for the extra traffic required to support a substantially large amount of retransmission or redundant stream transmission. The hybrid packet repair scheme  20  detects and ignores such errors by distinguishing them from situations where unicast retransmission  32 , multicast retransmission  34 , or FEC  36  would be effective. This ensures a stable packet repair scheme that does not collapse under large burst loss or outages. 
         [0022]    The NACK implosion effect, if not carefully moderated, could be a catastrophic failure mode for any error correction scheme attempting error feedback for multicast streams with large receiver populations. This is because the NACKs  26  both consume reverse channel bandwidth, and also can flood the repair point  16  with control packets. The hybrid packet repair scheme  20  addresses these NACK implosions and uses NACK implosion to detect certain loss patterns and hence turns bursts of NACKs  26  on feedback control channel  28  into an advantage rather than a failure mode. 
         [0023]      FIG. 2  shows the retransmission server (repair point)  16  in more detail. The processor  18  operates the hybrid packet repair scheme  20  that in one embodiment are computer executable software instructions. For each media channel  22 , the repair point  16  caches the packet data  24 A necessary for repairing any of the lost packet in media channel  22 . The hybrid packet repair scheme  20  operates in conjunction with a retransmission cache  60  that caches the media packets  24 A transmitted by media server  14 . Retransmission cache  60  is used in conjunction with a NACK table  62  that counts the number of NACKS  26  received for each cached media packet  24 A. For example, the NACKs  26  identify the sequence numbers of a set of lost media packets. Each time a NACK message  26  is received by repair point  16 , a NACK count  64  for the associated lost packets  64  are incremented in table  62 . 
         [0024]    Based on the NACK pattern in NACK table  62 , the hybrid packet repair scheme  20  sends different combinations of unicast retransmission packets  32 , multicast retransmission packets  34  and/or FEC packets  36  to the receivers  50 . The repair packets are used to replace the lost packets identified in the NACK messages  26 . 
         [0025]    The repair point  16  can also gauge the intensity of a NACK implosion even when NACKs might be lost due to congestion or the inability of the repair point to receive and process all the NACKs  26 . The three loss cases of individual loss, correlated loss, and outage on the downstream primary multicast stream  22  can also be analyzed. In the case of correlated loss, the repair point  16  can also determine enough about the loss pattern to choose among unicast packet retransmission, multicast packet retransmission, and FEC repair. 
       Establishing Media Channels 
       [0026]    Still referring to  FIG. 2 , a given media “channel”  22  has a primary multicast Real Time Protocol (RTP) session along with a corresponding Real Time Control Protocol (RTCP) control channel. The media channel  22  may have a unicast repair RTP/RTCP session which can be established on demand according to the scheme described in US. Patent App. entitled: RETRANSMISSION-BASED STREAM REPAIR AND STREAM JOIN, filed: Nov. 17, 2006, Ser. No. 11/561,237 which is herein incorporated by reference. This RTP/RTCP session may be used for unicast retransmission repair when the hybrid packet repair scheme  20  determines that unicast retransmission is the most effective way to repair a particular error. 
         [0027]    A second SSM RTP/RTCP multicast session is added for multicast repair. The multicast retransmissions  34  can be sourced by the same retransmission server  16  at the same source address as the feedback target address for the main multicast RTP session. However, a different destination group address is used. Receivers  50  participating in the repair scheme join or leave this multicast group at the same time they join or leave the main multicast RTP session. This multicast repair session is used for both sending the multicast retransmission packets  34  using the RTP retransmission payload format and for sending FEC repair packets  36  using the native payload type for an in use FEC scheme. The two forms of unicast and multicast retransmission are distinguished by the receivers  50  using standard RTP conventions for payload type multiplexing in a single session. 
         [0028]    Other unicast receiver feedback  58  is sent to the feedback address for the primary media session  22 , and therefore is available to the retransmission server  16 . These RTCP packets  58  in one embodiment are RTCP receiver reports. The retransmission server  16  uses the RTCP reports  58  to estimate the population of receivers  50  that are “homed” on retransmission server  16  for repairs. This receiver population is dynamic and approximate since receivers come and go, RTCP-Receiver Report packets may be lost, and mapping of receivers  50  to repair points can change. 
         [0029]    Based on the identified population of receivers  50  and the pattern of NACKs  26 , either RTP unicast repair packets  32  are sent via unicast retransmission, RTP multicast repair packets  34  are sent via multicast retransmission, or RTP FEC repair packets  36  are sent using a multicast retransmission. 
       Selecting Repair Scheme 
       [0030]      FIG. 3  shows different NACK patterns  70  that may determine the type of repair scheme  32 ,  34 , or  36  used to repair lost packets. It should be understood that the example NACK patterns shown in  FIG. 3  are only for illustrative purposes. The actual number of NACKs associated with lost packets and the number of different lost packets considered by the hybrid packet repair scheme  20  may vary according to the network bandwidth, type of transmitted media, number of receivers  50 , etc. 
         [0031]    In this example, a first NACK pattern  70 A in NACK table state  62 A shows one NACK received for a first media packet and one NACK was received for a seventh media packet. In this example, the hybrid repair scheme  20  may determine that sending two unicast retransmission packets  32  ( FIG. 2 ) is the most efficient scheme for repairing the two lost packets. For example, sending two unicast retransmission packets  32  would use less total network bandwidth than sending two multicast retransmission packets. 
         [0032]    A second example NACK pattern  70 B in NACK table state  62 B shows several hundred NACKs received only for the third media packet. In this state, the hybrid packet repair scheme  20  may determine that sending one multicast retransmission packet  34  for the third lost packet is most efficient. For example, sending one multicast retransmission packet  34  uses less bandwidth than sending 200 separate unicast packets  32  to each individual receiver sending one of the NACKs  26 . 
         [0033]    A third example NACK pattern  70 C in NACK table state  62 C indicates three different packets have been lost by multiple different receivers  50 . In this condition, the hybrid packet repair scheme  20  may determine that sending two FEC packets is the most efficient way to repair the lost packets. For example, two FEC packets may be able to repair all three lost packets  1 ,  2 , and  6 . Thus, multicasting two FEC packets  36  ( FIG. 2 ) would be more efficient than sending 110 individual unicast retransmission packets  32  or sending three separate multicast retransmission packets  34 . 
         [0034]    The FEC packets  36  can work with any number of packet-level FEC schemes, and do not require any particular form of FEC. FEC mapping onto IP protocols is described in a large number of Internet Engineering Task Force (IETF) Request For Comments (RFCs) and drafts, such as RFC3009, RFC3452, RFC3695, and therefore is not described in any further detail. 
         [0035]    A fourth example NACK pattern  70 D in NACK table state  62 D indicates five different packets  1 ,  2 ,  4 ,  5 , and  7  have been lost. In this case a combination of unicast retransmission packets  32  and multicast retransmission packets  34  may be the most efficient repair scheme. For example, unicast retransmission packets  32  may be sent to the relatively small number of individual receivers that lost packets  1 ,  2 ,  5 , ad  7  and a single multicast retransmission packet  34  may be sent to all of the receivers  50  for lost packet  4 . 
         [0036]    A fifth example NACK pattern  70 E in NACK table state  62 E indicates every one of the packets  1 - 7  has been lost by different combinations of receivers. In this condition, the hybrid packet repair scheme  20  may determine that there is insufficient bandwidth to repair any of the lost packets and may abort any attempt to repair lost packets. 
         [0037]      FIG. 4  shows one example of operations performed by the hybrid packet repair scheme  20  in  FIGS. 1 and 2 . In order to repair the media stream, the repair point  16  needs to determine which packets to retransmit using unicast packets  32 , which packets to retransmit using multicast packets  34 , whether to switch to FEC-based repair  36  rather than retransmitting, or whether to give up when there is insufficient aggregate bandwidth to sufficiently repair the media stream  22  and satisfy the receivers  50 . 
         [0038]    In operation  82  the NACK packets  26  ( FIG. 2 ) are monitored. The number and/or pattern of monitored NACKs in combination with limits on network bandwidth may indicate in operation  82  that no repair should be performed. Accordingly, the identified lost media packets  24  are not repaired in operation  84 . Otherwise, operation  86  determines if error correction is available for repairing the lost packets. For example, when a limited number of different packets are indicated as lost, error correction packets  36  may be sent to the receivers  50 . The receivers then locally recreate the data from the lost packets using the FEC packets  36 . 
         [0039]    In operation  88 , the NACK pattern in table  62  ( FIG. 2 ) may indicate that unicast repair is the most efficient scheme for repairing lost packets. Accordingly, the identified lost packets are sent using unicast retransmissions in operation  90  to the specific receivers identifying the lost packets. 
         [0040]    In operation  92 , the NACK pattern in table  62  may indicate that multicast retransmission is the most efficient scheme for repairing lost packets. Accordingly, multicast retransmissions of the identified lost packets are sent in operation  94  to all of the receivers in the multicast group. In operation  96 , and as described above in  FIG. 3 , the NACK pattern in table  62  may indicate that both unicast retransmission and multicast retransmission should be used. Accordingly in operation  98  unicast retransmissions of certain lost packets are sent to specific receivers  50  and multicast retransmissions of other lost packets are sent to all of the receivers  50  in the multicast group. In operation  99 , forward error correction may be used whenever applicable to improve repair efficiency. 
       Network Timing Considerations 
       [0041]    Referring to  FIGS. 2 and 5 , the repair point  16  in operation  100  caches the media packets  24 A received from the media server  14 . For each cached packet  24 A that might be used to construct a unicast retransmission  32  or multicast retransmission  34 , the repair point  16  in operation  102  counts the number of NACKs  26  received for the cached packet  24 A. 
         [0042]    The NACK count  66  is initialized to zero when the packet  24 A is initially cached. When a NACK  26  is received, the cached packets  24 A being NACKed are ascertained from a sequence number and bit map in the NACK  26 . Accordingly, the NACK count  66  for an associated lost packet  64  is incremented by one for each received NACK. 
         [0043]    In operation  104 , an earliest unicast retransmission time is identified for each cached packet  24 A based on a cache delay and a configured estimate of the playout point the receivers  50  use for the media channel  22 . There may be some time period between when a receiver  50  identifies a lost media packet  24  and when that lost media packet needs to be played out by the receiver  50 . For instance, a jitter buffer in the receiver  50  may provide a predetermined delay period from when a packet  24  is received to when the packet is played out. The repair point  16  may use some of this delay period to further analyze the NACK patterns in table  62  prior retransmitting a lost packet. 
         [0044]    The idea is to avoid unicast retransmissions  32  when multicast retransmissions  34  or FEC  36  would be more effective. Accordingly, the repair point  16  monitors the NACKs  26  for some time window to provide an opportunity for multiple NACKs  26  to arrive. The time period in operation  104  is selected to be short enough so that retransmission repair completes before the NACKing receiver  50  needs to playout the repair packet. This time period also accounts for network transmission delay and any delay in receiving the packet in retransmission cache  60 . 
         [0045]    Similarly, a latest unicast retransmission time for the lost packet is identified in operation  106  based on the same network parameters mentioned. The latest retransmission time indicates whether the deadline has passed for usefully repairing a media stream with the cached packet  24 A. In other words, if the repair point  16  cannot send the cached packet  24 A to the receiver  50  in time to be played out at the proper moment, then there is no utility in sending the retransmission packet. Accordingly, the hybrid packet repair scheme  20  may make repair decisions prior to expiration of the time period in operation  106 . 
       Receiver Density 
       [0046]    Referring to  FIGS. 2 and 6 , the repair point  16  may need to know the upper bound for NACKs  26  received on channel  28 . The repair point  16  is configured with information for the feedback control channel  28  such as the available IP bandwidth inbound from the receivers  50 . The repair point in operation  110  also identifies the number of receivers  50  actively receiving the media packets  22  (receiver population) through the RTCP receiver reports  58 . The repair point can thereby ascertain if the bandwidth of feedback channel  28  could be exceeded if a large fraction of the receivers  50  sent NACKs  26  at the same time. 
         [0047]    The repair point  16  in operation  114  computes a NACK density which may be the ratio of the available bandwidth of feedback channel  28  to the identified receiver population. There may be a lower bound of 1 to cover the case when more than enough bandwidth is available to handle all the receivers  50 . The NACK density computed in operation  114  is used to scale the impact of the NACKs  26  that are successfully received and processed by the repair point  16 . The NACK density is periodically recomputed in operation  114  using the current receiver population estimate in operation  110 . 
         [0048]    In one embodiment, the NACK density is classified as either high density or low density in operation  116 . For example, a high NACK density is selected when the NACK density is above the range 1-1.5 and the low NACK density is selected when the NACK density is below this range. This high or low classification is used in one embodiment described below when determining which scheme to use for repairing the lost media packets. 
       NACK Density Based Repair Schemes 
       [0049]    The hybrid packet repair scheme  20  may maintain, on a per channel basis, a retransmission bandwidth budget, represented as a fraction of the original stream bandwidth. For example, the repair scheme  20  might be configured to allow each media stream  22  ( FIG. 2 ) to use an additional 20% over its native bandwidth for unicast or multicast retransmissions  32 ,  34 , and/or for FEC  36 . By knowing the bandwidth of native media stream  22 , the repair point  16  can then ascertain an upper bound on the amount of available repair bandwidth. 
         [0050]    Referring to  FIGS. 2 and 7 , the retransmission cache  60  may be scanned every few milliseconds in operation  120 . Packets whose latest retransmission time has expired, which have already been transmitted by multicast, or have been covered by an FEC operation are identified in operation  122  and ignored in operation  123 . 
         [0051]    The hybrid repair scheme in operation  124  determines if FEC would be the most effective technique for repairing the current set of errors. First the number of FEC packets are counted that would be needed to correct all lost packets with a non-zero NACK count. If the total bandwidth for the calculated number of FEC packets exceeds the retransmission bandwidth budget in operation  126 , FEC is eliminated as a current repair mechanism candidate in operation  128 . If FEC does fit within the bandwidth budget, the amount of bandwidth used for FEC is stored in operation  130  and considered later in repair operation  132 . A high NACK density repair scheme is used in operation  134  when a high NACK density was identified in operation  116  of  FIG. 6  and a low NACK density repair scheme is used in operation  136  when a low NACK density was identified in operation  116 . 
       Low NACK Density 
       [0052]    Referring to  FIG. 8 , a low NACK density is identified in operation  140  (see  FIG. 6 ). After the earliest retransmission time has passed (see operation  104  in  FIG. 5 ), all packets identified in NACK table  62  with a NACK count of 1 are added to a unicast bandwidth pool in operation  142 . These packets are added to the unicast pool because it is highly likely based on the low NACK density that only one receiver would be interested in this packet. 
         [0053]    The inverse of the NACK count is used in operation  144  as a probability for using unicast retransmission to repair other lost packets. In other words, as the NACK count increases, there is a lower probably of using unicast retransmission to repair the lost packet. Based on the calculated probabilities, the lost packets are identified as either candidates for unicast or multicast retransmission in operation  146 . 
         [0054]    The total estimated required bandwidth is then calculated in operation  148 . If a packet is selected for unicast retransmission, the estimated transmission bandwidth used is multiplied by the associated NACK count  66 . Otherwise, the packet is selected for multicast retransmission and the transmission bandwidth is estimated at 1 packet. 
         [0055]    If there is insufficient bandwidth to accommodate retransmitting all the lost packets in operation  150 , a fall back scheme assigns all packets with a NACK count&gt;1 to multicast retransmission in operation  152 . The reassigned packets are each counted as using a single packet&#39;s worth of bandwidth. Unicast candidate packets are reassigned as multicast retransmissions in operation  152  until the bandwidth limit is reached. Remaining packets that still do not fit in the budget are considered un-repairable and ignored in operation  154 . 
         [0056]    When sufficient bandwidth exists in operation  150 , or after completing operation  154 , FEC may be applied in operation  156 . If FEC is available and uses less bandwidth than the selected retransmission scheme, then FEC packets  36  may be sent instead of retransmitting packets. Otherwise, the assigned unicast or multicast retransmission scheme is used to send the lost packets to the receives in operation  158 . 
       High NACK Density 
       [0057]    Referring to  FIGS. 2 and 9 , the high density algorithm may have less NACK information to work with and therefore is conservative about using unicast since correlated errors may tend to cause NACK implosions. The high NACK density repair scheme is identified in operation  160  pursuant to the analysis in  FIGS. 5 ,  6 , and  7 . All packets with a NACK count in table  62  greater than one are added to the multicast bandwidth pool in operation  162 . If the bandwidth pool is exhausted before all the identified lost packets are added to the bandwidth pool in operation  164 , then the packet repair is aborted in operation  166 . In this case it is unlikely the repair operations will improve the media stream. For example, so many packets may have been lost by so many receivers that given the limits on repair bandwidth attempting repair probably would not substantially correct the media stream and possibly could cause additional packet loss in the native media stream  22 . 
         [0058]    If the repair bandwidth pool is not exhausted in operation  164 , then packets with a NACK count of one whose earliest retransmission time has passed are then considered for unicast retransmission in operation  168 . The inverse of the NACK density calculated in  FIG. 6  is used in operation  170  as the probability value to determine whether to schedule the single NACK count packets for unicast retransmission. In other words, the higher the NACK density, the less likely that any unicast retransmissions will be used. 
         [0059]    Once the packets are classified, if FEC is an option in operation  180  and uses less bandwidth than multicast retransmission, the error is repaired with FEC in operation  182 . Otherwise the packets are repaired using the designated multicast or unicast repair in operation  184 . 
       Receiver Repair Considerations 
       [0060]    The receivers  50  ( FIG. 2 ) may indicate in the NACKs  26  whether or not they have local FEC repair capability. For example, particular receivers  50  may not have the processing capacity to effectively correct packets using FEC. These receivers  50  would then provide an identifier  27  in any sent NACKs  26 A that indicates lack of FEC capability. The hybrid packet repair scheme  20  described above would then adjust the selected repair scheme according to the FEC indications  27  so that no FEC packets  36  are sent to receivers  50  with no FEC correction capability. For example, in the schemes described above, the FEC option would not be considered for any receivers  50  sending NACKs  27 A and only unicast retransmission  32  or multicast retransmission  34  would be used for associated packet loss correction. 
         [0061]    A popularity (or priority) metric could also be associated with individual multicast streams  22 , and repair precedence could be given to the higher popularity streams. Repair preference would then be based on the order of decreasing priority. Alternatively, a “RED” scheme could skip a few streams randomly. The scheme could be used for any multimedia multicast service including any video or audio information. 
         [0062]    Thus, the hybrid adaptive repair scheme uses unicast retransmission, multicast retransmission, and FEC to repair RTP multicast sessions. The scheme is highly robust; saves bandwidth; is highly adaptable to various access network configurations, receiver densities, and available bandwidth; and deals with upstream losses in a way that avoids control channel overhead or constant downstream bandwidth usage as would be required by a pure FEC solution. 
         [0063]    Several preferred examples of the present application have been described with reference to the accompanying drawings. Various other examples of the invention are also possible and practical. This application may be exemplified in many different forms and should not be construed as being limited to the examples set forth herein. 
         [0064]    The figures listed above illustrate preferred examples of the application and the operation of such examples. In the figures, the size of the boxes is not intended to represent the size of the various physical components. Where the same element appears in multiple figures, the same reference numeral is used to denote the element in all of the figures where it appears. When two elements operate differently, different reference numerals are used regardless of whether the two elements are the same class of network device. 
         [0065]    Only those parts of the various units are shown and described which are necessary to convey an understanding of the examples to those skilled in the art. Those parts and elements not shown are conventional and known in the art. 
         [0066]    The system described above can use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the operations. Some of the operations described above may be implemented in software and other operations may be implemented in hardware. 
         [0067]    For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional blocks and software modules or features of the flexible interface can be implemented by themselves, or in combination with other operations in either hardware or software. 
         [0068]    Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. We claim all modifications and variation coming within the spirit and scope of the following claims.