US 20070201365 A1
A IP video delivery system (10) includes a multiplexer (30) for transmitting multiple data streams of packets over link (31) to a site having one or more receivers (22). During times of congestion, the multiplexer will discard packets from its internal queues. Packets are intelligently chosen to minimize the effects on the output from the receivers (22) by taking into account timing information related to the packets and priority.
1. A multiplexer for broadband subscriber access, comprising:
a memory queue for storing packets of video information;
traffic management circuitry for selectively discarding one or more packets from the memory queue responsive to a detection of congestion in the memory queue based on parameters associated with existing packets currently in the queue.
2. The multiplexer of
3. The multiplexer of
4. The multiplexer of
5. The multiplexer of
6. The multiplexer of
7. The multiplexer of
8. The multiplexer of
9. The multiplexer of
10. The multiplexer of
11. A method of multiplexing packets for broadband subscriber access, comprising the steps of:
storing packets of video information in a memory queue;
detecting congestion situations;
selectively discarding one or more packets from the memory queue responsive to a detection of congestion in the memory queue based on parameters associated with existing packets currently in the queue.
12. The method of
13. The method of
14. The method of
15. The method of
16. The method of
17. The method of
18. The method of
19. The method of
20. The method of
The U.S. Government has a paid-up license in this invention and the right in limited circumstances to require the patent owner to license others on reasonable terms as provided for by the terms of Award No. 70NANB3H3053 awarded by National Institute of Standards and Technology.
1. Technical Field
This invention relates in general to network communications and, more particularly, to a method and apparatus for discarding packets.
2. Description of the Related Art
In a digital information delivery network, between a source device and a destination device, packets of data may be lost for a variety of reasons. Some packets are randomly lost due to uncontrollable errors - for example, errors caused by noise on a transmission line, synchronization-issues, etc.-Some-packets are lost due to congestion, i.e., it is not possible for a network element to transmit all received packets in a timely manner. Current discard mechanisms for IP QoS (quality of service) algorithms implement random selection schemes to determine which packets to discard without regard to the relative effect on the eventual output.
For some data transfer protocols, missing packets cause the destination device to request a retransmission of the missing information. This is not very feasible, however, in a network that has multicasting of real-time streams such as audio or video. Normally, there will not be enough time available for requesting and receiving the retransmitted packets, unless buffers at the destination device are very large.
When an expected packet in a packet stream is not received at the destination device, the destination device waits for a certain amount of time before declaring a packet as lost. Once a packet is declared as lost, some decoders may request retransmission, other decoders may correct the problem to the extent possible by error concealment techniques. Error concealment techniques will in most cases result in degradation of output quality and are incapable of correcting some errors; further, the degree of the output error will be different depending upon the type of data in the lost packet, some of which will be more difficult to conceal than others. Thus, if packets must be discarded, some types of packets will be better candidates for discarding than others.
Accordingly, there is a need for a method and apparatus for identifying and discarding packets to minimize output errors.
In the present invention, a multiplexer for broadband subscriber access comprises a memory queue for storing packets of video information and traffic management circuitry for selectively discarding one or more packets from the memory queue responsive to a detection of congestion in the memory queue based on parameters associated with existing packets currently in the queue.
The present invention provides significant advantages over the prior art. By selectively discarding packets from the queue, the degradation of the resulting video during times of congestion is greatly improved.
For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
The present invention is best understood in relation to
In operation, the VHE sources 20 stream video information to the IP video receivers 22. For live video broadcasts, such as a live television signal, the video data is typically sent as a multicast transmission. For on-demand video, unicast transmission may be used. At the receiver side, on-demand video generally has a longer buffer, since the delay from source 20 to viewing is not important as broadcast video servers and, thus, on-demand video has a lower priority than live broadcast video services. The site 12 may have several IP video receivers 22 each receiving multiple streams of programming. For example, each IP video receiver 22 could receive two video data streams. If there were three IP video receivers 22 in the site 12, and each receiver 22 was receiving two video streams, then the link 31 between the multiplexer 30 and the modem 32 would be carrying video packets for six different data streams.
Modern day video protocols compress the video stream by periodically sending a full frame (compressed) of video data, followed by differential frames which indicate the changes between frames, rather than the frame itself. Accordingly, a scene which has a rapidly changing image will require a higher bandwidth than a frame that is relatively still. The total available bandwidth between the video heads 20 and the IP receivers 22 for a site 12 is generally fixed by the bandwidth of link 31, in view of the technology used by the multiplexer 30 and modem 32.
With a fixed bandwidth in which to transfer all packets for all data streams for a site 12, the number of data streams supported by the link 31 is determined by an average bandwidth for each received channel (link 31 can be carrying other data traffic such as Internet traffic, which has a lower priority than the live video data streams (lowest priority) and voice (VOIP—voice over Internet protocol, which generally has the highest priority). However, the data rates for the separate N data flows are not constant. At times, multiple channels may be simultaneously using more than their average bandwidth, resulting in congestion on link 31.
The congestion problem is illustrated in
In operation, the multiplexer 30 is designed to minimize the effect of dropping packets. A critical aspect of the problem is that all packets are time-critical. For each data stream all packets are generated on a single server (VHE 20). Once generated, each packet has a strict “use by” time. A packet that becomes stale in transit to the end user becomes unusable. To conserve shared link bandwidth, stale packets must be discarded without being transmitted over the link 31.
In operation, multiplexer 30 conforms to a policy that requires the minimum degradation of service to the end user when packets are discarded. This goal is accomplished in two basic ways: (1) the multiplexer 30 discards the minimum amount of data necessary to avoid congestion and (2) the multiplexer 30 makes use of a priority scheme to ensure the least useful packets are preferentially discarded.
To accomplish these goals, four mechanisms may be used. First, in the absence of explicit time schedule information associated with the packets, the multiplexer 30 can use a self-clocking mechanism that uses packet arrival times to determine packet use-by times. The multiplexer 30 can use priority codes associated with each packet to determine which packets to drop first. The priority scheme can also identify packet interdependencies, so that when a superior packet is dropped, packets that depend on that packet can be identified and also be dropped.
A look-ahead feature can identify the nature of future traffic and allow the multiplexer 30 to make better decisions about which packets to drop. For example, when knowledge of future traffic indicates that a high priority packet will arrive, the multiplexer 30 can drop packets currently in its queues to eliminate congestion in advance. Further, a traffic analysis function 30 can examine all queued traffic plus all known future traffic and determine the optimum set of packets to drop.
To enable the multiplexer 30 to discern the end-to-end schedule, the source 20 cooperates by generating (and transmitting) packets 60 according to a predictable schedule. The simplest such schedule involves transmitting packets at equal time intervals, which may be agreeable with a video service that sends one packet for each video frame. However, other transmission timing schemes will work as well. What is necessary is that the multiplexer 30 can detect the timing pattern and “lock onto” it. In this way, the packets are “self clocking.” They provide the timing signal the multiplexer 30 uses to determine the appropriate time schedule for each packet.
The operation of the timing recognition function 50 is illustrated in
A refinement to the time synchronizer function allows it to accommodate a varying time period. A varying time period would be symptomatic of clock drift between the multiplexer 30 and the packet source 20. In the top part of
To accommodate a varying packet rate, the synchronizing function computes a running average of the packet delay over a fixed number of the most recent delay times. The packet schedule will be adjusted using the following formula:
In this formula pi is the projected period for computing the schedule for the next packet. Δ is the measured time between the two most recent packets, and 0<α<1. When α is small (close to zero) the period will be adjusted to accommodate a slowly varying packet rate.
Even when the packet spacing is not uniform, the multiplexer 30 will synchronize with the packet stream, provided the packet spacing is cyclic or otherwise predictable. When the packet spacing is cyclic and known in advance, synchronization can be accomplished by pattern matching, as shown in
Since the incoming packets are subject to delay jitter, there will not be a perfect match between the expected pattern and the actual pattern. The multiplexer will need to assess the match (correlation) between the expected pattern and the actual pattern and determine the point of best correlation. The correlation between the expected pattern and the actual pattern is computed by the following formula:
This is the sum of the absolute values of the differences between the actual (A) and expected (E) values over the region α. The region for which the sum is minimum is the best match. When the spacing pattern is not known in advance, the multiplexer 30 will detect it. The method for detecting the traffic pattern involves comparing inter-packet spacings. In the simplest method, the current inter-packet spacing is recorded and compared with subsequent inter-packet spacings. This operation is performed with differing offsets between the spacings used in the comparison and is illustrated in
A possible implementation scheme for determining δ is shown in
In the formula 0<α<1. This causes each δ to converge to the average of the most recent values of Δ. When the length of a circular buffer equals the length of the cyclic packet sequence, the values of the δs will converge to the Δs in the packet spacing sequence. If the jitter function is well-behaved, the averages of the Δs will be the specified packet spacing values, and the δs will be an accurate representation of the spacing pattern. When the length of a buffer does not match the length of the packet sequence, the value of the δs will tend to converge to the average packet spacing over the whole sequence.
This scheme has been tested by simulation. The simulation compared predicted values of the packet spacing with actual values and plotted the correlation (absolute value of the difference). The plots in
To compensate for clock drift with cyclic traffic patterns, the previous formula for adjusting the expected spacing is modified. Instead of a single spacing p the formula now uses a set of spacings pj, where 2≦j≦P, and P is the period of the cycle. The formula becomes the following:
The discard control function 54 of the traffic management system 46 of multiplexer 30 uses priority information associated with the packets to assist in determining which packets to drop. This information is obtained from the priority detection function 52. In a first embodiment of the priority detection function, the packet source provides a priority indicator to communicate dropping preferences to the multiplexer. Making use of several priority levels, the dropping priorities could be coded according to the following scheme:
The discard control function 54 bases its packet dropping decisions on information about packets in its queues 42. It is desired to minimize the number of packets queued at the multiplexer for several reasons:
Some of these difficulties can be alleviated by queuing information about packets without actually queuing the packets.
The use of header packets 60 h does not alleviate the problem of time delay. Since the header packets 60 h must be sent in advance of the data packets, the data packets are effectively delayed at the source past the time they could have been transmitted.
The packet discard function 54 will minimize data loss by observing priorities related to image dependence and packet age. A primary rule is that shared link bandwidth will not be wasted by transmitting stale data. The secondary rule is that when packets are dropped in accordance with the primary rule, impact on video quality will be minimized.
The first rule is enforced by identifying packets with stale data and dropping those packets. In
The discard control function 54 may implement the packet dropping policy through the use of a packet database 70, as illustrated in
Packet priority can be obtained directly from packet header information, or it can be inferred by the size of the packet and/or by the position of the packet in a cyclic traffic pattern. The packet delivery schedule is the time when the last data from the packet must be transmitted through the shared link. The delivery schedule is inferred from the packet arrival time and its position within a cyclic traffic pattern. When the decision is made to drop a packet it is identified in the database.
The discard control function 54 determines whether a packet 60 will become stale by computing the transmission times for the data in the packet 60 and for the data ahead of the packet in its queue 42. To the first approximation the queue time of a packet uses the assumption the queue will be apportioned a certain amount of shared link bandwidth and that the queue will be served on an equitable basis. A preferred embodiment for discarding packets is:
The invention described in connection with
In step 74, a total transit time is determined for packet n, taking in consideration the non-discarded packets ahead of packet n (i.e., older packets across all queues 42) is computed; this time is denoted TTT(n). In step 76, if the condition TTT(n)>TTL(n) is not met, i.e., if there will be time to transmit packet n after transmitting all preceding packets, then n is incremented for evaluation of the next packet in step 78. Otherwise, steps are taken to discard lower priority packets ahead of packet n. In step 80, the total transit time of packets which precede packet n but have a lower priority is determined. This value is denoted TTTlp(n). If the condition TTT(n)−TTTlp(n)>TTL(n) is not met in step 82, i.e., if packet n will not be transmitted in time even if all lower priority packets are discarded, then packet n is marked for discard and index n is incremented in step 84.
If the condition TTT(n)−TTTlp(n)>TTL(n) is met in step 82, i.e., packet n can be transmitted in time by discarding one or more of the preceding lower priority packets, then a minimum set of packets is chosen in step 86 by discarding packets in order of increasing size starting at the smallest. This could be done as shown in 17 by discarding the smallest preceding non-discarded packet, and recomputing in step 80, or by determining the minimum time needed for transmitting packet n on time, and summing the transmit times for the preceding packets in order of size, starting at the smallest packet, until the minimum time is reached.
Discarded packets are simply not transmitted by the output stage 44 once they reach the front of the queue 42. For selecting from the various queues 42, the output stage 44 examines each queue 42 in turn in cyclic order using a pointer to determine which queue has the oldest (non-discarded) packet a the head of the queue. If two or more packets have the “oldest” time, then the output stage 44 serves the first queue encountered with the oldest packet. The pointer is advanced one position past the queue served, and the cycle is repeated. The output stage 44, in essence, uses all the FIFOs 42 to create a much larger FIFO.
This embodiment of the invention works to maximize video quality or other packet service to an end user with a number of advantages. First, it ensures that useless packets (packets that cannot be transmitted prior to their “use by” time) are not transmitted through the shared link 31. Second, it minimizes the loss of video quality by preferentially dropping low priority packets and the smallest of the low priority packets. Third, it ensures that a high priority packet is not dropped due to being behind low priority packets in the queue. Fourth, it ensures that the oldest packet in all the queues 42 is preferentially transmitted. Fifth, it ensures all queues 42 are served fairly by providing serving the least recently served queue when all other factors are equal.
During periods of congestion, i.e., when the traffic management system determines that a critical priority packet will not be transmitted in time, discard control function 54 would first select low priority packets to be dropped to achieve sufficient bandwidth requirement reduction to ensure that higher priority packets would have bandwidth to be transmitted toward the subscriber. Low priority packets associated with all video streams being multiplexed for a single access subscriber line would be candidates for the discardable packet selection process in step 90. The idea is that it would be better to discard a low priority frame from-another queue within the multiplex group than to discard a higher priority packet from the video stream that was causing the overload condition. The smallest number of low priority packets could be selected similar to step 86 of
An example is given in
This method for discarding packets delivers a high level of video display quality to the video viewer, with minimum processing.
Although the Detailed Description of the invention has been directed to certain exemplary embodiments, various modifications of these embodiments, as well as alternative embodiments, will be suggested to those skilled in the art. The invention encompasses any modifications or alternative embodiments that fall within the scope of the Claims.