HK1178352B - Dynamic bandwidth re-allocation - Google Patents

Abstract

The invention provides a method and system for dynamic bandwidth re-allocation. The method includes the steps of monitoring a video streams delivered by a server to a first client and a second client that have a same service level agreement and determining whether the first client is receiving a lower bitrate video stream compared to the second client. The method further includes the step of adjusting a parameter to allow the first client to receive a higher bitrate video stream. In an example, the monitoring, determining and adjusting steps are performed by a cable modem termination system (CMTS). In another example, the monitoring, determining and adjusting steps are performed by an optical line terminal (OLT).

Description

Dynamic bandwidth reallocation

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from U.S. provisional patent application No. 61/526,504 filed on 23/8/2011 and U.S. patent application No. 13/538,037 filed on 29/6/2012, the entire contents of which are incorporated herein by reference.

Technical Field

The present invention generally relates to dynamic bandwidth reallocation.

Background

Online video delivery involves the transmission of a video file in the form of a video stream from a server that stores the video file to a client that requests the online delivery of the video file. Typically, a client determines the bit rate of a connection with a server and requests a video stream at a bit rate that can be sustained by the connection. However, network conditions may arise that cause the first client to receive a lower bit rate than the second client, even though both clients have the same service level agreement with their network services to provide for bandwidth allocation. In response to the lower bit rate condition, the first client will request the server to switch to the lower bit rate video stream. This results in an unfair bandwidth allocation between the first client and the second client for the same service level.

Disclosure of Invention

There is a need for methods and systems that overcome the above-mentioned deficiencies.

Accordingly, the present invention provides a cable modem termination system including a video stream monitoring and marking system and a downstream physical layer modulator. The video stream monitoring and marking system is configured to: monitoring video streams delivered by a server to a first client and a second client, wherein the first client and the second client have the same service level agreement; determining whether the first client is receiving a lower bit rate video stream than the second client; and adjusting the parameters so that the first client receives the higher bit rate video stream. The downstream physical layer modulator is coupled to the video stream monitoring and marking system and is configured to transmit the video stream received from the server to the first client and the second client.

Preferably, the video stream monitoring and marking system is configured to adjust the parameter to reduce the bandwidth allocation to the second client to equalize the bandwidth allocation between the first client and the second client.

Preferably, the video stream monitoring and marking system is configured to determine a bit rate of the video stream delivered to the first client and the second client.

Preferably, the video stream monitoring and marking system is configured to monitor control messages on a control channel between the first client and the server to detect a request by the first client to the server for a video stream of a lower bit rate than the second client.

Preferably, the video stream monitoring and marking system is configured to determine a service level agreement for the first client and the second client.

Preferably, the service level agreement specifies the downstream bandwidth allocated to the client.

Preferably, the video stream monitoring and marking system is configured to adjust parameters in the downstream service stream extension header to give higher priority to the video stream delivered to the first client.

Preferably, the video stream monitoring and marking system is configured to adjust the continuous cell rate parameter in the token bucket to give higher priority to the video stream delivered to the first client.

Preferably, the video stream monitoring and marking system is configured to adjust the latency level parameter so as to give higher priority to the video stream delivered to the first client.

The invention also provides a method comprising: monitoring video streams delivered by a server to a first client and a second client, wherein the first client and the second client have the same service level agreement; determining whether the first client is receiving a lower bit rate video stream than the second client; and adjusting the parameters so that the first client receives the higher bit rate video stream.

Preferably, the adjusting step further comprises adjusting the parameter so as to reduce the bandwidth allocation to the second client to equalize the bandwidth allocation between the first client and the second client.

Preferably, the determining step further comprises monitoring a control message on a control channel between the first client and the server to detect a request by the first client to the server for a lower bit rate video stream than the second client.

Preferably, the step of adjusting further comprises adjusting parameters in a downstream service flow extension header, thereby giving higher priority to the video stream delivered to the first client.

Preferably, the adjusting step comprises adjusting the continuous cell rate parameter in the token bucket to give higher priority to the video stream delivered to the first client.

Preferably, the adjusting step comprises adjusting the latency level parameter so as to give higher priority to the video stream delivered to the first client.

Preferably, wherein the steps are performed by an optical line terminal.

Preferably, the adjusting step further comprises: the color of the data packets is changed to give higher priority to the video stream delivered to the first client.

Preferably, the adjusting step further comprises: the drop threshold of the packets is changed to give higher priority to the video stream delivered to the first client.

The invention also provides an optical line terminal comprising a video stream monitoring and marking system and a downstream physical layer modulator. Wherein the video stream monitoring and marking system is configured to: monitoring video streams delivered by a server to a first client and a second client having the same service level agreement; determining whether the first client is receiving a lower bit rate video stream than the second client; and adjusting the parameters so that the first client receives the higher bit rate video stream. The downstream physical layer modulator is coupled to the video stream monitoring and marking system and is configured to transmit the video stream received from the server to the first client and the second client.

Preferably, wherein the video stream monitoring and marking system is configured to change the color of the data packets so as to give higher priority to the video stream delivered to the first client.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention. In the drawings:

FIG. 1 illustrates an exemplary system according to an embodiment of the present invention.

Fig. 2 illustrates an exemplary video streaming session between a server and a client.

FIG. 3A illustrates an exemplary token bucket, according to an embodiment of the present invention.

Fig. 3B illustrates an exemplary downstream service flow extension header, according to an embodiment of the invention.

Fig. 4 shows an exemplary flowchart of exemplary steps for dynamic bandwidth reallocation, according to an embodiment of the present invention.

FIG. 5 is a block diagram of an exemplary computer system in which the present invention may be implemented.

The present invention will be described below with reference to the accompanying drawings. In the drawings, like reference numbers may indicate identical or functionally similar elements.

Detailed Description

While the present disclosure has been described with reference to illustrative embodiments for particular applications, it should be understood that the disclosure is not limited thereto. Those skilled in the art with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the disclosure would be of significant utility.

FIG. 1 illustrates an exemplary system 100 according to an embodiment of the present invention. The system 100 includes a Cable Modem Termination System (CMTS) 102 coupled to more than one Cable Modem (CM) 104 a-104 n via a network 110. Each cable modem 104 may be coupled to more than one client 112 a-112 n. The network 108 may be any type of network including, but not limited to, the Internet, a Local Area Network (LAN), or a Wide Area Network (WAN). It should be appreciated that the type of network 108 is a design choice and may be arbitrary. In the embodiments given herein, "n" is any positive integer.

CMTS102 may include a Media Access Controller (MAC) 114, a downstream physical layer modulator (DSPHY) 116, and an upstream physical layer demodulator (uspy) 118. The CMTS102 may also include a master clock 120, a video stream monitoring and marking unit 122, one or more downstream queues 124, and a scheduler 130. In an implementation, the CMTS102 may include a processor 126 coupled to a memory 128. The functions described herein as being performed by the CMTS102 or by the video stream monitoring and marking unit 122 may be performed by the processor 126 based on instructions stored in the memory 128. The CMTS102 is also coupled to a network 110 that provides interconnection between the CMTS102 and the cable modem 104. The network 110 supports wired, wireless, or both transmission media, including satellite, terrestrial (e.g., fiber optic, copper, twisted pair, coaxial, etc.), radio, microwave, free-space optical, and/or any other form or method of transmission. In an embodiment, a DOCSIS network is part of network 110.

The USPHY118 forms the physical layer interface between the CMTS102 and the upstream channels of the network 110. The CMTS102 may include a separate USPHY118 for each upstream channel. USPHY118 receives and demodulates all bursts (bursts) from cable modem 104.

DSPHY116 forms a physical layer interface between CMTS102 and downstream channels of network 110. Thus, video, voice, data, and/or control messages targeted to more than one cable modem 104 are aggregated at DSPHY116 and communicated to each cable modem 104. DSPHY116 modulates and/or formats information for downstream transmission.

Suitably, MAC114 receives upstream signals from USPHY118 and provides downstream signals to DSPHY 116. The MAC114 operates as the lower sublayer of the data link layer of the CMTS 102. In an embodiment, MAC114 supports segmented storage, concatenation (concatenation), payload header suppression/extension, and/or error detection of signals transmitted on the physical layer.

Memory 128 may interact with MAC114 to store signals as they are processed by MAC 114. The memory 128 may also store various auxiliary data used to support processing activities. Such assistance data includes security protocols, identifiers, rules, policies, and the like.

In an example, the client 112 may be any wired or wireless computing device including, but not limited to, a personal computer, laptop computer, mobile phone, Personal Digital Assistant (PDA), or media player, such as an iPod^TMOr iPad^TM. In another example, the client 112 may be integrated with the cable modem 104 in a single device (not shown). The client 112 may request delivery of the video stream from the server 106. The request is received by the CMTS102 and relayed to the server 106. In response to a request for a video stream from a client 112, the server 106 sends the requested media stream to the client 112. Fig. 2 illustrates an exemplary video streaming session between server 106 and client 112. The server 106 stores the video file 200 in multiple sizes for transmission at different bit rates. Different bit rates are the result of different levels of compression. Compression involves the extraction (refinement) of some redundant data in the video image. The bit rate reduction system operates by removing redundant information from the video at the video encoder before the decoder transmits and reinserts the redundant information. At its most basic level, compression is performed when the input video stream is analyzed and information that is not visible to the viewer is discarded. Each event is then assigned a code, with frequent events being assigned fewer bits and infrequent events being assigned more bits. For example, a specific duration of video (typically a few seconds long) is stored by the server 106 as segments of different compression levels and thus different sizes. In an example, the server 106 stores 500 kilobits per second (kbps) slices at different compression levelsSegments 202, 1 megabit per second (Mbps) segments 204, and 2Mbps segments 206. Each segment 202, 204, and 206 corresponds to the same duration of video, but has a different level of compression and thus a different size and a different level of quality.

Thus, the server 106 stores the same video file 200 in different sized segments, allowing the video streams to be delivered at different bit rates and different quality levels. The quality of the video stream depends on the bit rate of the video stream delivered by the server 106 to the client 112. The bit rate of the video stream, in turn, depends on the size of the delivered video file segment. For example, segment 206 results in a higher bit rate and therefore higher quality video stream than segment 204, and segment 204 results in a higher quality video stream than segment 202. Thus, storing the same video file 200 in different sizes allows the server 106 to support different bit rates requested by the client 112. The quality (and hence bit rate) of the video stream to be used is selected by the client 112 based on its knowledge of the network conditions. However, the client 112 has virtually no overall information about the network. The client 112 does not know what other clients 112 are doing, nor does it know the total network capacity or how that capacity would be ideally allocated. The individual client 112 estimates network conditions based on the latency and rate of the video segments it receives from the server 106. If the latency is long (i.e., the time between requesting a fragment from the server 106 and the beginning of the fragment arriving) or the rate is low for the client 112 (i.e., the packet arrives slowly once the fragment begins to arrive), the client 112 may determine that the network conditions are poor and require a lower bit rate stream from the server 106. In response to the lower bit rate stream, the server 106 switches to the lower bit rate segment. Conversely, if the segment is received faster (i.e., low latency and/or high rate) for the client 112, it requires a higher bit rate stream from the server 106. The server 106 switches the client 112 to the higher bit rate segment in response to the higher bit rate stream. However, because the client does not have general information about the network, it may make an incorrect estimate of the network conditions.

In the example, assume that there are two clients behind two different cable modems-client 112a behind cable modem 104a and client 112b behind cable modem 104 b-all of which have the same Service Level Agreement (SLA). In another example, clients 112a and 112b may be behind the same cable modem 104. A service level agreement as referred to herein refers to a service contract between a network provider and a client that guarantees a certain level of service for the client, such as a certain amount of upstream and/or downstream bandwidth. In the current example, clients 112a and 112b request video at substantially the same time. Of the available high, medium and low rate streams, a medium rate stream is selected and provided with a medium rate segment, such as segment 204. Now assume that some temporary network congestion event occurs. Coincidentally, the event causes a delayed or lost packet to client 112a, but not client 112 b. This coincidence occurs, for example, because the clients 112a and 112b are communicating with different video servers 106, and a temporary network congestion event occurs on a link in the path that server 106 provides content to client 112a, rather than on a link in the path that server 106 provides content to client 112 b. Alternatively, the coincidence occurs because the client 112a is blocking at the time the segment is requested, but not at a different time (perhaps one or two seconds before or after) when the client 112b requests the segment from the same or a different server 106.

A temporary network congestion event may cause client 112a to determine that the network conditions are poor and request a low rate (lower quality) flow. Meanwhile, client 112b is not affected by the temporary event, so it does not require a lower bit rate stream. In fact, when the client 112a switches to a lower bit rate, the client 112b may perceive that the network conditions are improved (potentially resulting in less delay for packets targeted to the client 112b because the client 112a consumes less bandwidth), and the client 112b may attempt to switch to a high-rate stream. If this happens, once the client 112b is consuming the high-rate flow, the client 112a may still not be able to estimate that the network conditions are improving enough to switch back to the medium-rate flow even if the temporary network congestion event ends. This is because the additional packets delivered to the client may slightly delay the packet corresponding to the client 112 a. Alternatively, the client 112a may only estimate that the network conditions improved after a long period of time. Because the previous medium rate stream failed, the client 112a may not immediately attempt to switch back to the medium rate stream because if the attempt failed, it may cause the picture quality seen by the user using the client 112a to deteriorate. The client 112a will wait to determine that the network conditions are improving before attempting to switch back to the medium rate stream.

Thus, the result of the temporary network congestion event is that even if two users have the same service level agreement and should therefore receive the same quality video, client 112a ends with a lower bit rate (and therefore lower quality) stream than the starting bit rate, while client 112b ends with a higher bit rate (and therefore higher quality) stream than the starting bit rate. This condition may last long because the client 112a does not immediately attempt to reacquire the higher bit rate stream and, if it does, there is still a problem due to the bandwidth consumed by the client 112 b. The CMTS102 and CM104 are not typically members of the negotiation between the client 112 and server 106. Therefore, the CMTS102 cannot simply command the clients 112a and 112b to switch back to the medium rate stream.

To overcome these problems, according to embodiments of the present disclosure, CMTS102 (or OLT in the case of a PON system) attempts to indirectly influence the decision of clients 112 by adjusting various parameters as described below to cause clients 112b to perceive a slightly lower network performance as in the example above and/or to cause clients 112a to perceive a slightly higher network performance. This may speed up the client 112a from perceiving an improvement in network conditions to switch it back to the medium rate stream and/or cause the client 112b to see a slightly reduced network condition to switch it back to the medium rate stream. For example, the parameters may be adjusted such that the client 112a has a larger bandwidth and may be promoted from the low-quality segment 202 to the medium-quality segment 204, and the parameters may be adjusted such that the client 112b has a smaller bandwidth and has to be reduced from the highest-quality segment 206 to the medium-quality segment 204.

In another example, the parameters may be adjusted to enable the client 112a to receive a higher bit rate video stream from the server 106 while maintaining the bit rate received by the client 112 b. For example, the parameters may be adjusted such that both client 112a and client 112b may receive the high quality segment 206.

Referring again to fig. 1, the video stream monitoring and marking system 122 monitors the video stream delivered by the server 106 to the client 112 to determine the bit rate of the video stream. The video stream monitoring and marking system 122 determines whether the client 112a is receiving a lower bit rate than other clients 112 having the same service level agreement. In another example, the video stream monitoring and marking system 122 detects a request by the client 112a to reduce the bit rate of the video stream while other clients 112 having the same service level protocol are receiving higher bit rate video streams. For example, the video stream monitoring and marking system 122 detects a request by the client 112a for a video stream at a lower bit rate than the client 112 b. In another example, the video stream monitoring and marking system 122 detects a request by the client 112a for a lower bit rate video stream than the video stream originally requested by the client 112a at the beginning of the video session while another client 112b continues to request a higher bit rate video stream for the same service level agreement. In yet another example, rather than monitoring the bit rate, the video stream monitoring and marking system 122 may monitor control messages on a control channel (not shown) between the client 112 and the server 106, thereby detecting a request by the client 112a for the server 106 for a video stream at a lower bit rate than the client 112 b. In another example, the video stream monitoring and marking system 122 may monitor the bit rate of the video stream and control messages between the client 112a and the server 106 to determine whether the client 112a is receiving a lower bit rate stream than the client 112 b.

Upon detecting unequal bandwidth distribution between the client 112a and the client 112b, the CMTS102 adjusts parameters so that the client 112a receives a higher bit rate video stream. In an embodiment, the parameter adjusted by the video stream monitoring and marking system 122 is a token bucket (token bucket) parameter. Fig. 3A illustrates an example token bucket, according to an embodiment of the present disclosure. Token bucket 300 represents a policing function (policing function) that controls the rate at which packets are delivered to client 112. The incoming packet flow 302 represents packets entering the token bucket 300 for delivery to the client 112. The outgoing flow 304 represents the data packets transmitted by the token bucket 300 to the client 112. The dropped packet flow 306 represents non-conformant packets dropped by the token bucket 300. Token bucket 300 may be part of scheduler 130. In another example, token bucket 300 may be a software construct running on processor 126 based on instructions stored in memory 128.

Token bucket 300 is defined by parameters "r" and "b". The parameter r represents the rate at which tokens 301 are added to token bucket 300. Tokens 301 are added to the token bucket every 1/r second. Token bucket 300 may hold a maximum of "b" tokens. When token bucket 300 is full, if token 301 arrives, token 301 is discarded. When an n-byte incoming packet is received by token bucket 300, n tokens are removed from the bucket and the packet is sent to the network in an outgoing packet stream 304. If fewer than n tokens are available, no tokens are removed from token bucket 300 and the packet is considered non-conformant. Non-conformant packets may be buffered for subsequent transmission or dropped by the dropped packet flow 306.

In a DOCSIS network, the maximum sustained rate is equal to r and the maximum traffic burst is equal to b. According to an embodiment of the present disclosure, the video stream monitoring and marking system 122 may add the token r by increasing the maximum holding rate of the video data packets corresponding to the client 112a that is to receive the higher bit rate video stream, thereby preventing loss of its data packets. The video stream monitoring and marking system 122 may equalize the bandwidth distribution between the clients 112a and 112b by reducing the maximum sustained rate of video data packets corresponding to the client 112b while removing the token r for the client 112b that is receiving the higher bit rate. In an example, the maximum traffic burst parameter may also be adjusted to equalize bandwidth allocation between clients 112a and 112 b.

In another embodiment, the video stream monitoring and marking system 122 may adjust the drop level threshold of the downstream queue 124 such that video data packets of the client 112a that are to receive the higher bit rate video stream are not dropped or are dropped less frequently than the client 112 b.

In another embodiment, the parameter adjusted by the video stream monitoring and marking system 122 is a bit in a Downstream Service Extension Header (DSEHDR) 308 as shown in fig. 3B. The downstream service extension header 308 includes a 3-bit traffic priority field 310. Changing the value of the traffic priority field 310 causes the CM104 to give different levels of priority to a first packet having a first value in the traffic priority field 310 relative to a second packet arriving at the same CM104 having a second value different from the first value in each traffic priority field 310. By adjusting these bits in the downstream direction, the video stream monitoring and marking system 122 causes the client 112a to receive a higher bit rate video stream from the server 106 than the client 112 b.

In yet another example, video stream monitoring and marking system 122 sends signal 131 to adjust a maximum downstream latency parameter associated with scheduler 130 to give higher priority to the video stream delivered to client 112 a. Scheduler 130 takes into account the maximum downstream latency when making scheduling decisions. For example, video stream monitoring and marking system 122 adjusts the maximum downstream latency parameter such that packets in downstream queues 126 a-126 n targeted for a particular client 112a are given a higher priority by scheduler 130 than packets of other clients (e.g., client 112 b). A data flow with a lower maximum downstream latency will tend to have packets waiting less in the downstream queue 124 than a data flow with a higher maximum downstream latency.

In other instances, the video stream monitoring and marking system 122 may adjust other quality of service (QoS) parameters, such as a traffic priority parameter, so that the client 112a receives a higher bit rate video stream than the client 112 b. The traffic priority parameter is similar to the traffic priority field 310, but it affects the priority within the scheduler 130, whereas the traffic priority field in the downstream service extension header 308 affects the priority within the cable modem 104 that processes the downstream service extension header 310. In an example, the video stream monitoring and marking system 122 sends a signal 131 to the scheduler 130 to adjust the traffic priority parameter such that packets associated with the client 112a are given a higher priority and lower priorities are given to packets associated with the client group 112 b.

In yet another embodiment, the video stream monitoring and marking system 122 may adjust the parameters 131 in the scheduler 130 to schedule video packets for the client 112a that is to receive the higher bit rate video stream before packets corresponding to the client 112 b.

In an embodiment, the video stream monitoring and marking system 122 may have more than one parameter, thereby enabling the client 112a to receive a higher bit rate video stream. For example, video stream monitoring and marking system 122 may adjust DOCSIS extension stream headers, token bucket parameters, latency level parameters, QoS parameters, and drop level thresholds to allow client 112a to receive higher bit rate video streams from server 106.

Minimum reserved rate (minireserved), downstream peak rate, or vendor specific QoS parameters may also be used to implement other algorithms. It should be appreciated that the type of parameters adjusted or the method used to provide higher priority to packets belonging to a client 112 may vary without departing from the scope of the present disclosure.

In an embodiment, the video stream monitoring and marking system 122 may be in an Optical Line Terminal (OLT) located between the server 106 and the client 112. In this embodiment, video stream monitoring and marking system 122 performs similar steps as described above, thereby enabling client 112 to obtain a higher bit rate video stream. For example, the video stream monitoring and marking system 122 adjusts the "color" assigned to packets of the video stream delivered to the client 112a that is to receive the higher bit rate video stream. The color may be indicated by a particular number of bit fields. For example, a red color may be indicated by the numeral 5 and correspond to high priority packets that are not dropped, while a green color may be indicated by the numeral 3 and indicate medium priority packets that may be dropped if there is congestion. According to embodiments of the present disclosure, the color may be adjusted such that packets given to the client 112a whose bit rate is being adjusted get a higher priority than other clients 112 having the same service level agreement. It should be understood that the type of color or number or bit used to indicate color is a design choice and may be arbitrary. In another example, the video stream monitoring and marking system 122 may adjust r, a latency level parameter, or a drop level threshold of the token bucket, thereby giving higher priority to the video stream delivered to the client 112 a.

In an example, the video stream monitoring and marking system 122 can be external to the CMTS102 or OLT. It should be understood that the video stream monitoring and tagging function 122 may be implemented in hardware only, such as logic gates and/or circuitry. In another embodiment, the video stream monitoring and tagging function 122 may be implemented solely in software running on the processor 126. In yet another embodiment, the video stream monitoring and tagging function 122 may be implemented as a combination of hardware and software.

Fig. 4 illustrates an exemplary flow diagram 400 for dynamic bandwidth reallocation in accordance with an embodiment of the present disclosure. Flowchart 400 is described with continued reference to the exemplary operating environment shown in fig. 1-3. However, the flowchart is not limited to this embodiment. It should be noted that certain steps shown in flowchart 400 need not occur in the order shown. In an example, this step is performed by video stream monitoring and marking system 122.

In step 402, a video stream and/or a control channel between a client and a server is monitored. For example, the video stream monitoring and marking system 122 monitors video and/or control channels between the client 112 and the server 106.

In step 404, the bandwidth is detected as being unevenly distributed. For example, the video stream monitoring and marking system 122 detects that the client 112a is receiving or requesting a lower bit rate video stream than the client 112b having the same service level protocol.

In step 406, it is determined whether to adjust the parameters to allow for a higher bit rate video stream. For example, video stream monitoring and marking system 122 determines whether client 112a and client 112b have the same service level agreement. If it is determined that they have the same service level agreement, the parameters of the client 112a are adjusted and the process proceeds to step 408. If it is determined that client 112b has a higher service level agreement than client 112b, then the parameters are not adjusted and processing proceeds to step 410.

In step 408, the parameters are adjusted to allow for higher bit rate video streams. For example, video stream monitoring system 122 may adjust parameters such as latency control, bits in a DOCSIS extension header, QOS parameters, drop level thresholds, or token bucket parameters, allowing client 112a to receive higher bit rate video streams.

In step 410, the current bit rate of the client 112a is maintained.

Embodiments presented herein or portions thereof may be implemented in hardware, firmware, software, and/or combinations thereof.

The embodiments presented herein apply to any communication system between more than two devices or within a sub-assembly of a device. The representative functions described herein (e.g., the steps in fig. 4) may be implemented in hardware, software, or some combination thereof. For example, as will be appreciated by one skilled in the art, based on the discussion presented herein above, the steps in fig. 4 may be implemented with a computer processor, such as processor 126, computer logic, an application specific circuit (ASIC), a digital signal processor, and so forth. Accordingly, any processor that performs the functions described above is within the scope and spirit of the embodiments presented herein.

The following describes a general-purpose computer system that may be used to implement embodiments of the present disclosure as set forth herein. The present disclosure may be realized in hardware, or a combination of software and hardware. Thus, the present disclosure may be implemented in the context of a computer system or other processing system. An example of such a computer system 500 is shown in FIG. 5. Computer system 500 includes more than one processor, such as processor 504. Processor 504 may be a special purpose or general purpose digital signal processor. The processor 504 is connected to a communication facility 506 (e.g., a bus or network). Different software implementations are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the art how to implement the disclosure in other computer systems and/or computer architectures.

Computer system 500 also includes a main memory 505, preferably Random Access Memory (RAM), and may also include a secondary memory 510. The secondary memory 510 may include, for example: hard disk drive 512, and/or RAID array 516, and/or removable storage drive 514, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 514 may read from and/or write to a removable storage unit 518 in a known manner. Removable storage unit 518 represents a floppy disk, magnetic tape, optical disk, or the like. As will be appreciated, the removable storage unit 518 includes a computer usable storage medium having stored therein computer software and/or data.

In alternative embodiments, secondary memory 510 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 500. Such apparatus may include: a removable storage unit 522 and an interface 520. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 522 and interfaces 520 which allow software and data to be transferred from the removable storage unit 522 to computer system 500.

Computer system 500 may also include a communications interface 524. Communications interface 524 allows software and data to be transferred between computer system 500 and external devices. Examples of communications interface 524 may include a modem, a network interface (such as an ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 524 are in the form of signals 528 which can be electronic, electromagnetic, optical or other signals capable of being received by communications interface 524. These signals 528 are provided to communications interface 524 via a communications path 526. Communications path 526 carries signals 528 and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and other communications channels.

The terms "computer program medium" and "computer usable medium" as used herein generally refer to media such as removable storage drive 514, a hard disk installed in hard disk drive 512, and signals 518. These computer program products are means for providing software to computer system 500.

Computer programs (also called computer control logic) are stored in main memory 505 and/or secondary memory 510. Computer programs may also be received via communications interface 524. Such computer programs, when executed, enable the computer system 500 to implement the present disclosure as discussed herein. In particular, the computer programs, when executed, enable the processor 504 to implement the processes of the present disclosure. For example, the computer program, when executed, enables processor 504 to perform some or all of the steps described above with reference to fig. 4. The present disclosure is implemented in software that may be stored in a computer program product and loaded into computer system 500 using a redundant array of disks (raid) 516, a removable storage drive 514, a hard disk drive 512, or a communications interface 524.

In other embodiments, the features of the present disclosure are implemented primarily in hardware, for example, using hardware components such as Application Specific Integrated Circuits (ASICs) and programmable or static gate arrays. It will be apparent to those skilled in the art that the hardware states are standardized to perform the functions described herein.

Conclusion

While various embodiments have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art that various changes in form and detail can be made therein without departing from the spirit and scope of the embodiments set forth herein.

The embodiments presented herein have been described above with the aid of functional building blocks and method steps illustrating specific functions and relationships. The boundaries of these functional building blocks and method steps have been arbitrarily defined herein for the purpose of description. Other boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed. Any such other boundaries are within the scope and spirit of the claimed embodiments. Those skilled in the art will recognize that these functional building blocks may be implemented by individual components, application specific integrated circuits, processors executing appropriate software, etc., or a combination thereof. Thus, the breadth and scope of the present embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims (10)

1. A cable modem termination system comprising:

a video stream monitoring and marking system configured to:

monitoring a video stream delivered by a server to a first client and a second client, wherein the first client and the second client have a same service level agreement;

determining whether the first client is receiving a lower bitrate video stream than the second client; and

adjusting a first parameter so that the first client receives a higher bit rate video stream; and

a downstream physical layer modulator coupled to the video stream monitoring and labeling system and configured to transmit video streams received from the server to the first client and the second client,

wherein the video stream monitoring and marking system is further configured to adjust parameters in a downstream service stream extension header to give higher priority to the video stream delivered to the first client.

2. A cable modem termination system according to claim 1, wherein the video stream monitoring and tagging system is further configured to:

adjusting the first parameter to reduce bandwidth allocation to the second client to equalize bandwidth allocation between the first client and the second client, or

Determining the bit rate of the video stream delivered to the first client and the second client, or

Monitoring control messages on a control channel between the first client and the server to detect a request by the first client to the server for a lower bit rate video stream than the second client, or

Determining a service level agreement for the first client and the second client.

3. A cable modem termination system according to claim 1, wherein the video stream monitoring and tagging system is further configured to adjust a continuous cell rate parameter in a token bucket, or adjust a latency level parameter, giving higher priority to video streams delivered to the first client.

4. A method of dynamic bandwidth reallocation, comprising:

monitoring video streams delivered by a server to a first client and a second client, wherein the first client and the second client have the same service level agreement;

determining whether the first client is receiving a lower bitrate video stream than the second client; and

and adjusting the waiting time level parameter, giving higher priority to the video stream delivered to the first client, and enabling the first client to receive the video stream with higher bit rate.

5. The method of claim 4, the adjusting further comprising adjusting the latency level parameter to reduce bandwidth allocation to the second client to equalize bandwidth allocation between the first client and the second client.

6. The method of claim 4, the determining further comprising monitoring control messages on a control channel between the first client and the server to detect a request by the first client for the server for a lower bit rate video stream than the second client.

7. The method of claim 4, the adjusting further comprising adjusting a parameter in a downstream service flow extension header or adjusting a continuous cell rate parameter in a token bucket to give higher priority to a video stream delivered to the first client.

8. The method of claim 4, wherein the monitoring step, the determining step and the adjusting step are performed by an optical line terminal.

9. The method of claim 8, the step of adjusting further comprising: changing the color of the packets, or changing the drop threshold of the packets, assigns a higher priority to the video stream delivered to the first client.

10. An optical line terminal comprising:

a video stream monitoring and tagging system, wherein the video stream monitoring and tagging system is configured to:

monitoring video streams delivered by a server to a first client and a second client having the same service level agreement;

determining whether the first client is receiving a lower bitrate video stream than the second client; and

adjusting parameters so that the first client receives a higher bit rate video stream; and

a downstream physical layer modulator coupled to the video stream monitoring and labeling system and configured to transmit video streams received from the server to the first client and the second client,

wherein the video stream monitoring and marking system is further configured to adjust a latency level parameter to give higher priority to the video stream delivered to the first client, causing the first client to receive the higher bit rate video stream.