US6715007B1 - Method of regulating a flow of data in a communication system and apparatus therefor - Google Patents

Abstract

A flow of data (26) is regulated in a communication system (20). A data rate is established in each of a data source (24) and a data sink (28). The data (26) is transmitted by the data source (24) and written into a buffer (32) at the source data rate, then read from the buffer (32) and received by the data sink (28) at the sink data rate. The level (62) of data (26) in the buffer (32) is monitored, and a rate-control signal (74) is dispatched to either the data source (24) or sink (28) when it is determined the buffer data level (62) is decreasing or increasing while at a lower or upper data-level threshold (66, 68), respectively. One of the data rates is adjusted in response to a rate-control signal (74).

Description

TECHNICAL FIELD OF THE INVENTION

The present invention relates to the field of communication systems. More specifically, the present invention relates to the field of data-flow regulation in communication systems.

BACKGROUND OF THE INVENTION

Certain difficulties are encountered in the transmission and reception of data in a communication system. With synchronous serial data, these difficulties encompass mismatches between data source and data sink clocks, variations in data arrival times within the system, and a low tolerance to overrun and underrun conditions.

Under ideal conditions, serial data is transmitted and received at identical data rates. That is, a data-rate clock in a data source would be identical to a data-rate clock in a data sink, e.g., 9600.{overscore (0000)} baud. To do so, however, would require perfectly matched oscillators in both the data source and sink. This is not practical in a real-world system. Crystal tolerances alone would prohibit such exactitude.

Utilizing high-accuracy oscillators, data source and data sink oscillators can become very close in frequency. Close, however, is not exact, and this inexactitude causes problems, especially with substantially continuous data. For example, it may be seen that continuous-data rates of 9600.0001 baud and 9599.9999 baud for the source and sink, respectively, will eventually produce a data overrun. Similarly, continuous-data rates of 9599.9999 baud and 9600.0001 baud for the source and sink, respectively, will eventually produce a data underrun. Both overrun and underrun conditions produce errors in the data stream, and are therefore highly undesirable.

Variations in data arrival rates in multi-source and/or multi-sink systems pose similar problems in that they may lead to overrun and/or underrun conditions. Where either a data source or a data sink (or both) is in motion, the doppler effect may contribute to variations in data arrival rates.

In conventional communication systems, these problems are typically partially or wholly corrected in hardware. Such hardware corrections increase significantly the complexity of the system, with an associated increase in cost. A typical hardware correction utilizes clock lines to synchronize the data rate clocks in both the data source and the data sink.

Data flow proceeds through such a system in lock step with this common synchronizing clock. In this manner, overrun and underrun conditions are eliminated at the expense of system complexity and cost.

In some cases, it is impractical or impossible to synchronize the data rate clocks in hardware. For example, with a software-defined radio, it is generally undesirable to utilize a hardware synchronization scheme in an otherwise software environment because it promotes the dependence of software on hardware in particular architectures. Software then becomes more complex to develop and is more difficult to port to other hardware platforms.

In such cases, elaborate schemes have been developed to synchronize the clocks by transmission. Such schemes typically suffer errors due to transmission delays and doppler shifts, as well as the expense and complexity of implementation.

Conventionally, a FIFO buffer is used to synchronize input and output data rates. This is typically done by interrupting the input data flow (when the input data rate is greater than the output data rate) or the output data flow (when the output data rate is greater than the input data rate) to compensate for rate differences. This produces discontinuous data, which itself may produce overrun or underrun conditions. Such discontinuous data also inhibits proper operation of the data source and/or data sink when continuous data is produced or expected.

What is needed, therefore, is a simple and straightforward method of implementing data-rate regulation in software. Such a method should be capable of compensating for mismatches between the source data rate and the sink data rate. Also, such a method should be capable of easily compensating for variations in data arrival times. Additionally, such a method should prevent data overrun and underrun conditions when the data is continuous over long periods of time.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the present invention may be derived by referring to the detailed description and claims when considered in connection with the Figures, wherein like reference numbers refer to similar items throughout the Figures, and:

FIG. 1 shows a block diagram depicting a communication system incorporating a data-rate regulator in accordance with a preferred embodiment of the present invention;

FIG. 2 shows a schematic view depicting a data-rate regulation buffer with a diagram of buffer level over time in accordance with a preferred embodiment of the present invention;

FIG. 3 shows a flow chart depicting a process to regulate a flow of data in the system depicted in FIG. 1 in accordance with a preferred embodiment of the present invention;

FIG. 4 shows a flow chart depicting a subprocess to control a buffer fill rate for the process of FIG. 3 in accordance with a preferred embodiment of the present invention;

FIG. 5 shows a flow chart depicting a subprocess to establish a source data rate for the process of FIG. 3 in accordance with a preferred embodiment of the present invention; and

FIG. 6 shows a flow chart depicting a subprocess to establish a sink data rate for the process of FIG. 3 in accordance with a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 shows a block diagram depicting a software-defined communication system20 incorporating a data-rate regulator22 in accordance with a p referred embodiment of the present invention.

In the exemplary embodiment of FIG. 1,system20 has adata source24 configured to transmitdata26 at a source data rate (not shown). Likewise,system20 has adata sink28 configured to receivedata26 at a sink data rate (not shown). Due to the use of real-world components, the source data rate and the sink data rate are not precisely identical, e.g., 9600.{overscore (0000)} baud. Consequently, data-rate regulation and/or synchronization are performed to prevent overrun and underrun conditions.

It should be noted that, for the purposes of this discussion, exemplary data rates of 9600 baud are utilized. Those skilled in the art will appreciate, however, that these are exemplary data rates only, and that data rates of any baud may be used without departing from the spirit of the present invention.

In practise, source and sink data rates are derived from data-rate generators withindata source24 anddata sink28. A typical data-rate generator utilizes a crystal and a divider to obtain the desired data rate. Because of tolerances in crystals, it is not normally possible to obtain a data-source crystal and a data-sink crystal that are perfectly matched in frequency, as well as thermal, pressure, and other characteristics. Therefore, for the sake of discussion, if the source data rate ofsystem20 were to be exactly 9600 baud at a given instant, then the sink data rate at that instant, while within a tolerance of the data-sink crystal, is virtually guaranteed to not be exactly 9600 baud.

In the preferred embodiment, data-rate regulator22 is inserted intosystem20 betweendata source24 anddata sink28.Data26 is transmitted bydata source24, received in data-rate regulator22 by aninput function30, and written into abuffer32 at the source data rate.

Similarly,data26 is read frombuffer32, transmitted from data-rate regulator22 by anoutput function34, and received bydata sink28 at the sink data rate.Data26 is therefore written intobuffer32 at the source data rate and read frombuffer32 at the sink data rate. In the preferred embodiment,buffer32 is realized within aportion36 of controller-readable memory.Input function30,output function34, and buffer memory portion36 (i.e., buffer32) are coupled to and under the control of acontroller38.Controller38 is coupled to and under the control of acontrol program40 realized within another portion42 of controller-readable memory. It iscontrol program40, acting throughcontroller38, that controls and regulates the flow ofdata26 betweendata source24 anddata sink28, i.e., through data-flow regulator22.

FIG. 1 depictsbuffer memory portion36 and/or control-program memory portion42 as coupled to and/or a portion of amemory44 withindata sink28. This depiction represents a preferred embodiment where data-rate regulator22, while logically separate, is physically incorporated into data sink28, i.e., is located within a radio receiver ofsystem20. In such a case,buffer memory portion36 and/or control-program memory portion42 may be portions of and share a common memory address space (not shown) with data sinkmemory44.

Similarly, FIG. 1 depictscontroller38 as coupled to and a portion of acontroller46 within data sink28. This depiction represents a preferred embodiment where data-rate regulator22 is physically incorporated into data sink28. In this embodiment,regulator controller38 and data-sink controller46 may be the same controller or processor, with control-program40 serving as a routine within a greater control program (not shown) contained within data-sink memory44.

Those skilled in the art will appreciate that the embodiment depicted in FIG. 1 is exemplary only. It is not a requirement of the present invention that data-rate regulator22 be physically incorporated into data sink28. Under some circumstances, it may be more desirable to physically incorporate data-rate regulator22 intodata source24, or to physically have data-rate regulator22 realized as an independent device.

Were data-rate regulator22 to be physically incorporated intodata source24,buffer memory portion36 and/or control-program memory portion42 may be coupled to and/or a portion of amemory48 withindata source24.Buffer memory portion36 and/or control-program memory portion42 may therefore be portions of and share a common memory address space (not shown) with data-source memory48.

Similarly,controller38 may be coupled to and a portion of acontroller50 withindata source24.Regulator controller38 and data-source controller50 may therefore be the same controller or processor, with control-program40 serving as a routine within a greater control program (not shown) contained within data-source memory48.

Were data-rate regulator22 to be realized as an independent device,buffer memory portion36 and/or control-program memory portion42 are portions of an independent memory52 within data-rate regulator22.Buffer memory portion36 and/or control-program memory portion42 share a common memory address space (not shown) addressable bycontroller38.Controller38 is an independent controller or processor within data-rate regulator22. FIG. 2 shows a schematicview depicting buffer32 with a data-flow diagram therefor in accordance with a preferred embodiment of the present invention. FIG. 3 shows a flow chart depicting a process100 to regulate a flow ofdata26 insystem20 in accordance with a preferred embodiment of the present invention. The following discussion refers to FIGS. 1 through 3.

In data-flow regulation process100 (FIG.3), atask102 establishes an initial value for the source data rate indata source24. Similarly, atask104 establishes an initial value for the sink data rate.Tasks102 and104 establish the source and sink data rates to a value greater than zero (the data rates always exist) and substantially equal to a predetermined data rate (not shown). For example, if the predetermined data rate is to be a theoretically perfect 9600 baud, then the source and sink data rates are set as close to this value as possible given the tolerances of the components involved. A transmitter (XMTR)56 (FIG. 1) indata source24 is now set to transmitdata26 at the source data rate of substantially 9600 baud, and a receiver (RCVR)58 (FIG. 1) in data sink28 is now set to receivedata26 at the sink data rate of substantially 9600 baud. It will be appreciated that, in all probability, neither the source data rate nor the sink data rate will be exactly 9600 baud.

Those skilled in the art will appreciate thattasks102 and104 are independent of each other and may be performed in either order. Likewise, it will be appreciated that, oncetasks102 and104 establish the source and sink data rates, those data rates continue to be as established until altered by another task.

Data26 is continuous. In a task106 (FIG.3), data source24 (FIG. 1) transmitsdata26 at the source data rate. In a followingtask108,input function30 of data-rate regulator22 receivesdata26 and writesdata26 to buffer32, also at the source data rate. Sincedata26 is continuous (after inception thereof),tasks106 and108 continuously transferdata26 fromdata source24 to buffer32 at the source data rate without interruption. That is, even though the source data rate may inadvertently change due to variations in temperature, pressure, and other factors, or may intentionally be changed as discussed hereinafter, the source data rate is always substantially equal to the predetermined data rate and never nears zero.

Those skilled in the art will appreciate thatdata26 may be packetized, i.e., as bursts of data interleaved with spaces. By being packetized, multiplexing may be applied to allow the use of a plurality of data termini60 (data sources24 or data sinks28), each having a terminus (source or sink) data rate (not shown). Within each data packet (not shown), the data rate is typically much higher than the terminus data rate as defined herein. For the purposes of this discussion, however, such packetized data may be considered to be continuous if the average terminus data rate of each data packet and its accompanying space is substantially equal to the terminus data rate and does not near zero. That is, when each packet is expanded to fill the following space, the resultant terminus data rate is reduced to the original terminus data rate, i.e., the data becomes continuous at the terminus data rate. It will be appreciated that either the source or the sink data (or both) may be packetized without departing from the spirit of the present invention. For purposes of this discussion, however,continuous data26 will be assumed for bothdata source24 and data sink28.

Following task108 asubprocess116 controls abuffer fill rate54. The operation ofsubprocess116 is discussed in detail hereinafter.

In a task110 (FIG.3), output function34 (FIG. 1) of data-rate regulator22 readsdata26 frombuffer32 and transmitsdata26 to data sink28 at the sink data rate. In a followingtask112, data sink28 receivesdata26, also at the sink data rate. Since, after inception,data26 is continuous,tasks110 and112 continuously transferdata26 frombuffer32 to data sink28 at the sink data rate without interruption. That is, even though the sink data rate may inadvertently change due to variations in temperature, pressure, and other factors, or may intentionally be changed as discussed hereinafter, the sink data rate is always substantially equal to the predetermined data rate and never nears zero.

Since even continuous data may be subject to termination (the data is continuous from beginning to end), aquery task114 determines if an end ofdata26 has been reached. Iftask114 determines that a data termination condition exists, thencontroller38 informscontrol program40 so thenext data26 may be treated as initialization of data.

Iftask114 determines thatdata26 is continuous, i.e. a data termination condition does not exist, then process100 continues withtasks106,108,116,110, and112. Those skilled in the art will appreciate thattasks106,108,116,110, and112 are performed substantially simultaneously as long asdata26 is continuous and in a steady-state condition, i.e., between initialization and termination.

FIG. 4 shows a flowchart depicting subprocess116 to controlbuffer fill rate54 for process100 in accordance with a preferred embodiment of the present invention. The following discussion refers to FIGS. 1 through 4.

Between writingtask108 and readingtask110, process100 executes subprocess116 (FIGS. 3 and 4) to controlbuffer fill rate54. In a task118 (FIG.4),controller38 continuously monitors abuffer data level62, i.e., the amount ofdata26 inbuffer32 from moment to moment, and buffer fillrate54, i.e., the rate at whichdata26 is fillingbuffer32. Since buffer fillrate54 is a rate of fill, buffer fillrate54 is positive (i.e., the slope ofbuffer data level62 in FIG. 2 extends from lower left to upper right) whenbuffer32 is being filled. Likewise, buffer fillrate54 is negative (i.e., the slope ofbuffer data level62 in FIG. 2 extends from upper left to lower right) whenbuffer32 is being emptied. It will be appreciated that since, in all probability, the source data rate and the sink data rate will not be exactly equal, buffer fillrate54 will, in all probability, never be zero. Those skilled in the art will appreciate that there are several ways in whichcontroller38 may monitor buffer fillrate54. For example,controller38 may monitorbuffer data level62 by sampling, in which decreasingbuffer data levels62 indicate a negativebuffer fill rate54. Likewise,controller38 may monitor the source data rate and the sink data rate. Throughout this discussion, buffer fillrate54 is taken to be equal to the difference of the source data rate less the sink data rate, i.e., R_Fill=R_Source−R_Sink. In the preferred embodiment, buffer fillrate54 is changed as a consequence of changing the source data rate or the sink data rate. The change in buffer fill rate may not be instantaneous. Those skilled in the art will appreciate that other calculations to obtainbuffer fill rate54 may be used if appropriate care is taken to determine fill-rate polarity. The use of these or other methods of determiningbuffer fill rate54 and the sign thereof does not depart from the spirit of the present invention.

Aquery task120 determines if data initialization is taking place, i.e., iftask108 is writing the beginning of a stream ofdata26 intobuffer32. If initialization is taking place, then aquery task122 determines if buffer data level62 (FIG. 2) has reached an initial data-level threshold64 (FIG.2). Ifbuffer data level62 has not reached initial data-level threshold64, then atask124 delays or inhibits the execution ofreading task110.

Those skilled in the art will appreciate thattasks120,122, and124 serve to delay or inhibit the reading ofdata26 frombuffer32 during initialization untilbuffer data level62 has reached initial data-level threshold64. Initial data-level threshold64 lies between a lower limiting data-level threshold66 (FIG. 2) and an upper limiting data-level threshold68 (FIG.2). Writingtask108 increasesbuffer data level62 while readingtask110 decreasesbuffer data level62. Since, for purposes of the present discussion, buffer fillrate54 is the difference of the source data rate less the sink data rate inhibitingreading task110 allowsbuffer32 to fill at the source data rate, i.e., at a maximum ofbuffer fill rate54, untilbuffer data level62 reaches initial data-level threshold64.

Those skilled in the art will appreciate that there are several ways to perform the data initialization and set an initial threshold. For example, the initial threshold reachedquery task122 may check for a set time delay rather than a buffer level. The use of these or other methods of determining that the data initialization is complete does not depart from the spirit of the present invention.

If the initial source data rate is greater than the initial sink data rate, then bufferfill rate62 will be positive immediately after initialization. This is depicted in FIG. 2 by thesolid line62 representing the buffer fill rate. Conversely, if the initial source data rate is less than the initial sink data rate, then bufferfill rate62 will be negative immediately after initialization. This is depicted in FIG. 2 by the dot-dash line62′ representing the buffer fill rate. By positioning initial data-level threshold64 between upper and lower limiting data-level thresholds66 and68, potential threshold-crossing errors forbuffer fill rate62 or62′ are eliminated. During steady-state operation, i.e., between initialization and termination, buffer fillrates62 and62′ are treated identically. Only bufferfill rate62 will be utilized in the remainder of this discussion.

Whenbuffer data level62 has reached initial data-level threshold64,task110 readsdata26 frombuffer32 and buffer fillrate54 is either positive (i.e., the source data rate is greater than the sink data rate) or negative (i.e., the sink data rate is greater than the source data rate). The transfer ofdata26 throughbuffer32 is now continuous, and will continue so until data termination.

By positioning initial data-level threshold between lower and upper limiting data-level thresholds66 and68,buffer32 is prevented from becoming either empty or full (i.e.,buffer data level62 is therefore maintained between lower and upper limiting data-level thresholds66 and68) as discussed hereinafter, thus preventing either data underrun or overrun conditions from occurring.

In association withtasks126,128,130, and132 (FIG.4), buffer32 (FIGS. 1 and 2) has two limiting data-level thresholds66 and68 (FIG.2). In response to controlprogram40,controller38 maintainsbuffer data level62 between lower and upper limiting data-level thresholds66 and68 by causing variations in the source or sink data rate as required. Lower limiting data-level threshold66 represents a lower limit forbuffer data level62, i.e., the minimum valuebuffer data level62 may attain between data initialization and data termination. When buffer fillrate54 is negative (i.e.,buffer data level62 is decreasing) andbuffer data level62 reaches lower limiting data-level threshold66, thencontroller38 causesbuffer fill rate54 to become positive.

Similarly, upper limiting data-level threshold68 represents an upper limit forbuffer data level62, i.e., the maximum valuebuffer data level62 may attain between data initialization and data termination. When buffer fillrate54 is positive (i.e.,buffer data level62 is increasing) andbuffer data level62 reaches upper limiting data-level threshold68, thencontroller38 causesbuffer fill rate54 to become negative.

In association withtasks134,136,138, and140 (FIG.4),buffer32 has two additional data-level thresholds70 and72. Five data-level thresholds (64,66,68,70, and72) are depicted in the preferred embodiment of FIG.2. Those skilled in the art will appreciate that additional data-level thresholds beyond the initial and limiting data-level thresholds64,66, and68 are not a requirement for the present invention. The use of five, seven, nine, or any number of data-level thresholds does not depart from the spirit of the present invention.

Lower inner data-level threshold70 is located between lower and upper limiting data-level thresholds66 and68, preferably below initial data-level threshold64. Upper inner data-level threshold72 is located between lower inner data-level threshold70 and upper limiting data-level threshold68, preferably above initial data-level threshold64.

Lower inner data-level threshold70 represents an intermediate lower limit forbuffer data level62. When buffer fillrate54 is negative andbuffer data level62 reaches lower limiting data-level threshold70, thencontroller38 causesbuffer fill rate54 to become less negative. Bufferfill rate54 may or may not become positive.

Similarly, upper inner data-level threshold72 represents an intermediate upper limit forbuffer data level62. When buffer fillrate54 is positive andbuffer data level62 reaches upper inner data-level threshold72, thencontroller38 causesbuffer fill rate54 to become less positive. Bufferfill rate54 may or may not become negative.

When the flow ofdata26 betweendata source24 and data sink28 is continuous, i.e., whentask120 has determined that initialization is not taking place ortask122 has determined that initialization has been completed, then subprocess116 proceeds withquery tasks126 and128 (FIG.4).Tasks126 and128 form a logical AND decision pair, as dotasks130 and132,134 and136, and138 and140 discussed hereinafter.

Iftask126 determines that buffer data level62 (FIG. 2) crosses the lower limiting data-level threshold66 (FIG. 2) ANDtask128 determines that buffer fill rate54 (FIG. 2) is negative, then subprocess116 proceeds totask142.

Iftask126 determines thatbuffer data level62 has not crossed the lower limiting data-level threshold66, OR iftask128 determines that buffer fillrate54 is not negative, then subprocess116 proceeds withquery tasks130 and132 (FIG.4).

Iftask130 determines thatbuffer data level62 has crossed the upper limiting data-level threshold68 ANDtask132 determines that buffer fillrate54 is positive, then subprocess116 proceeds totask142.

Iftask130 determines thatbuffer data level62 has not crossed the upper limiting data-level threshold68, OR iftask132 determines that buffer fillrate54 is not positive, then subprocess116 proceeds withquery tasks134 and136 (FIG.4).

Iftask134 determines thatbuffer data level62 has crossed the lower inner data-level threshold70 (FIG. 2) ANDtask136 determines that buffer fill rate54 (FIG. 2) is negative, then subprocess116 proceeds totask142.

Iftask134 determines thatbuffer data level62 has not crossed the lower inner data-level threshold70, OR iftask136 determines that buffer fillrate54 is not negative, then subprocess116 proceeds withquery tasks138 and140 (FIG.4).

Iftask138 determines thatbuffer data level62 has crossed the upper inner data-level threshold72 ANDtask140 determines that buffer fillrate54 is positive, then subprocess116 proceeds totask142.

Iftask138 determines thatbuffer data level62 has not crossed the upper inner data-level threshold72, OR iftask140 determines that buffer fillrate54 is not positive, then subprocess116 is complete and control returns to process100 (FIG.3).

If the AND logic of task pairs126 and128,130 and132,134 and136, or138 and140 is true, then subprocess116 proceeds totask142. Conversely, if the AND logic of all of the task pairs is false, then subprocess116 is done for the current iteration of process100 (FIG.3).

Intask142,subprocess116 generates a rate-control signal74 (FIGS.1 and3). Iftask142 immediately followstask128 ortask132, then rate-control signal74 contains a first-order rate-change request (not shown). In response to a first-order rate-change request, thedata terminus60 that is the target of rate-control signal74 (i.e.,data source24 or data sink28) (FIG. 1) will alter the terminus (source or sink) data rate so as to change the polarity ofbuffer fill rate54.

Iftask142 immediately followstask136 ortask140, then rate-control signal74 contains a second-order rate-change request (not shown). In response to a second-order rate-change request,data terminus60 will alter the terminus data rate so as to decrease the amount ofbuffer fill rate54 in the current polarity, even if that amount of decrease causes a change in the polarity ofbuffer fill rate54.

Followingtask142, aquery task144 determines ifdata terminus60 isdata source24 or data sink28. Ifdata terminus60 isdata source24, atask146 dispatches rate-control signal74 todata source24. Ifdata terminus60 isdata sink28, atask148 dispatches rate-control signal74 to data sink28. Followingtasks146 or148,subprocess116 is complete and control returns to process100 (FIG.3).

If, as a result ofsubprocess116, rate-control signal74 is dispatched to data terminus60 (FIG.1), a query task150 (FIG. 3) determines ifdata terminus60 isdata source24 or data sink28. Ifdata terminus60 isdata source24, asubprocess152 adjusts the source data rate. Ifdata terminus60 isdata sink28, asubprocess168 adjusts the sink data rate.

Those skilled in the art will appreciate thatdata terminus60 may be eitherdata source24, data sink28, or both. Whendata terminus60 is alwaysdata source24, then rate-control signal74 is always dispatched todata source24 by task146 (FIG.4), and only the data source rate is adjusted by subprocess152 (FIGS.3 and5). In this case, task144 (FIG.4), task148 (FIG.4), task150 (FIG.3), and subprocess168 (FIGS. 3 and 6) are superfluous and may be eliminated. Similarly, whendata terminus60 is always data sink28, then rate-control signal74 is always dispatched to data sink28 bytask146, and only the data sink rate is adjusted by subprocess168 (FIGS.3 and6). In this case, task144 (FIG.4), task146 (FIG.4), task150 (FIG.3), and subprocess152 (FIGS. 3 and 5) are superfluous and may be eliminated. The elimination of eitherdata source24 or data sink28 asdata terminus60 does not depart from the spirit of the present invention.

FIG. 5 shows a flowchart depicting subprocess152 to establish the source data rate for process100 in accordance with a preferred embodiment of the present invention. Ifdata terminus60 is data source24 (FIG.1), then subprocess152 (FIGS. 3 and 5) adjusts the source data rate. Withinsubprocess152, a query task154 (FIG. 5) determines if buffer fill rate54 (FIG. 2) is positive or negative.

Iftask154 determines that buffer fillrate54 is positive, i.e., the source data rate is greater than the sink data rate, then atask156 decreases the source data rate by one increment (discussed in detail hereinbelow). This adds a negative component to bufferfill rate54. Aquery task158 then determines if rate-control signal74 (FIGS. 1 and 3) contains the first-order rate-change request (discussed hereinbefore). If so, aquery task160 determines if buffer fillrate54 has changed signs (i.e., is negative). If no,tasks156 and158 are repeated until buffer fillrate54 changes signs.

Iftask154 determines that buffer fillrate54 is negative, i.e., that the source data rate is less than the sink data rate, then atask162 increases the source data rate by one increment. This adds a positive component to bufferfill rate54.

Aquery task164 then determines if rate-control signal74 contains a first-order rate-change request. If so, aquery task166 determines if buffer fillrate54 has changed signs (i.e., is negative). If no,tasks162 and164 are repeated until buffer fillrate54 changes signs.

Iftask158 or164 determines that rate-control signal74 contains a second-order rate-change request (discussed hereinbefore), or iftask160 or166 determines that buffer fillrate54 has changed signs, then subprocess152 is complete and control returns to process100 (FIG.3).

FIG. 6 shows a flowchart depicting subprocess168 to establish the sink data rate for process100 in accordance with a preferred embodiment of the present invention. The following discussion refers to FIGS. 1 through 4 and6.

Ifdata terminus60 is data sink28 (FIG.1), then subprocess168 (FIGS. 3 and 6) adjusts the sink data rate. Withinsubprocess168, a query task170 (FIG. 6) determines if buffer fill rate54 (FIG. 2) is negative or positive. Iftask170 determines that buffer fillrate54 is negative, i.e., that the sink data rate is greater than the source data rate, then atask172 decreases the sink data rate by one increment (discussed hereinafter). This adds a negative component to bufferfill rate54.

Aquery task174 then determines if rate-control signal74 (FIGS. 1 and 3) contains the first-order rate-change request (discussed hereinabove). If so, aquery task176 determines if buffer fillrate54 has changed signs (i.e., is positive). If no,tasks172 and174 are repeated until buffer fillrate54 changes signs.

Iftask170 determines that buffer fillrate54 is positive, i.e., the sink data rate is less than the source data rate, then atask178 increases the source data rate by one increment. This adds a positive component to bufferfill rate54.

Aquery task180 then determines if rate-control signal74 contains a first-order rate-change request. If so, aquery task182 determines if buffer fillrate54 has changed signs (i.e., is negative). If no,tasks178 and180 are repeated until buffer fillrate54 changes signs.

Iftask174 or180 determines that rate-control signal74 contains a second-order rate-change request, or iftask176 or182 determines that buffer fillrate54 has changed signs, then subprocess168 is complete and control returns to process100 (FIG.3).

It will be appreciated by those skilled in the art that the adjustment increments discussed hereinabove in association withtasks156,162,172, and178 (FIGS. 5 and 6) are arbitrary. That is, any increment convenient to the specific application may be used as long as that increment does not cause the terminus data rate to near zero. Preferably, the increment is less than fifty percent of the predetermined baud rate. In the desired embodiment, for example, if the source or sink data rate is produced by a crystal oscillator and a digital divider, the increment may well be one step of the divider. The use of increments of any given size is within the spirit of the present invention.

Furthermore, those skilled in the art will appreciate that the purpose of the first order request processing associated withtasks158,160,164,166,174,176,180 and182 is to prevent buffer underun and overflow conditions and may be accomplished by other means, e.g. sending a single large adjustment. The use of other methodologies does not depart from the spirit of the present invention.

Those skilled in the art will also appreciate that the methods of detecting a need for a terminus data rate adjustment and the methods for effecting that adjustment described herein are exemplary of a preferred embodiment of the present invention. The use of other methodologies does not depart from the spirit of the present invention.

In summary, the present invention teaches a method of regulating a flow of data in a communication system and an apparatus therefor. The method is simple and straightforward process of implementing such a data-rate regulation in software. This process is suitable for use with conventional software-determined radios and other programmable devices. The process is capable of compensating for mismatches between the source data rate and the sink data rate, as well as variations in data arrival times. The process prevents of data overrun and underrun conditions when used to control the flow of continuous data over long periods of time.

Although the preferred embodiments of the invention have been illustrated and described in detail, it will be readily apparent to those skilled in the art that various modifications may be made therein without departing from the spirit of the invention or from the scope of the appended claims.

Claims (21)

What is claimed is:

1. A method of regulating a flow of data in a communication system, said method comprising:

a) establishing a source data rate greater than zero in a data source;

b) establishing a sink data rate greater than zero in a data sink;

c) transmitting said data at said source data rate by said data source;

d) writing said data into a buffer at said source data rate, wherein said writing activity

d) increases a level of said data within said buffer;

e) reading said data from said buffer at said sink data rate, wherein said reading activity e) decreases said buffer data level;

f) receiving said data at said sink data rate by said data sink;

g) monitoring a fill rate of said buffer and said buffer data level, wherein said fill rate is a difference of said source data rate less said sink data rate; and

h) dispatching a rate-control signal to adjust said source data rate when said monitoring determines one of said fill rate is negative and said buffer data level is less than or equal to a lower data-level threshold and said fill rate is positive and said buffer data level is greater than or equal to an upper data-level threshold.

2. A data-flow regulation method as claimed inclaim 1, further comprising

dispatching said rate control signal to adjust said sink data rate, when said monitoring determines one of said said fill rate is negative and said buffer data level is less than or equal to said lower data-level threshold and said buffer fill rate is positive and said buffer data level is greater than or equal to an upper data level threshold.

3. A data-flow regulation method as claimed inclaim 2 wherein:

said establishing activity a) initially establishes said source data rate substantially equal to a predetermined data rate; and

said establishing activity b) initially establishes said sink data rate substantially equal to said predetermined data rate.

4. A data-flow regulation method as claimed inclaim 3 wherein:

said dispatching said rate control signal to adjust said source data rate is configured to adjust said source data rate to within fifty percent of said predetermined data rate.

5. A data-flow regulation method as claimed inclaim 2, wherein, when said monitoring determines said fill rate is negative and said buffer data level is less than or equal to said lower data-level threshold, one of said dispatching said rate control signal to adjust said source data rate and dispatching said rate control signal to adjust said sink data rate adjusts one of said source and sink data rates so that said source data rate is greater tan said sink data rate.

6. A data-flow regulation method as claimed inclaim 2, wherein, when said monitoring determines said fill rate is positive and said buffer data level is greater than or equal to said upper data-level threshold, one of said dispatching said rate control signal to adjust said source data rate and dispatching said rate control signal to adjust said sink data rate adjusts said one of source and sink data rates so that said sink data rate is greater than said source data rate.

7. A data-flow regulation method as claimed inclaim 2 wherein:

said lower data-level threshold is a first lower data-level threshold;

said upper data-level threshold is a first upper data-level threshold;

said buffer has a second lower data-level threshold between said first lower data-level threshold and said first upper data-level threshold;

said buffer has a second upper data-level threshold between said second lower data-level threshold and said first upper data-level threshold;

said rate-control signal containing a first rate-change request when said monitoring determines that said fill rate is negative and said buffer data level is less than or equal to said second lower data-level threshold and said fill rate is positive and said buffer data level is greater than or equal to said second upper data-level thresholds;

said rate-control signal containing a second rate-control change request when said monitoring determines that said fill rate is negative and said buffer data level is less than or equal to said first lower data-level threshold and said fill rate is positive and said buffer data level is greater than or equal to said second upper data-level thresholds;

said source and sink data rates configured for adjustment by a first amount when said rate-control signal contains said first rate-change request and by a second amount when said rate-control signal contains said second rate-change request wherein said second amount is greater than said first amount.

8. A data-flow regulation method as claimed inclaim 1 wherein:

said transmitting activity c) substantially continuously transmits said data; and

said receiving activity f) substantially continuously receives said data.

9. A data-flow regulation method as claimed inclaim 8 wherein:

said writing activity d) substantially continuously writes said data into said buffer; and

said reading activity e) substantially continuously reads said data from said buffer.

10. A data-flow regulation method as claimed inclaim 1 wherein said reading activity e) is delayed until said buffer data level reaches an initial data-level threshold, said initial data-level threshold lying between said lower and upper data-level thresholds.

11. A data-flow regulation method as claimed inclaim 1 wherein:

said transmitting activity c) transmits said data as discrete packets of said data having an average source data rate substantially equal to said source data rate; and

said receiving activity f) receives said data as a substantially continuous stream of said data at said sink data rate.

12. A data-flow regulation method as claimed inclaim 1 wherein:

said transmitting activity c) transmits said data as a substantially continuous stream of said data at said source data rate; and

said receiving activity f) receives said data as discrete packets of said data having an average sink data rate substantially equal to said sink data rate.

13. A data-flow regulation method as claimed inclaim 1 wherein said reading activity e) is delayed a timed amount such that said buffer data level reaches an initial data-level threshold, said initial data-level threshold lying between said lower and upper data-level thresholds.

14. An apparatus for regulating a flow of data between portions of a communication system, said apparatus comprising:

a first controller-readable portion configured as a buffer;

a second controller-readable memory portion configured to contain a control program;

a data source configured to transmit said data at a source data rate greater than zero;

an input function coupled between said data source and said first memory portion, configured to receive said data from said data source at said source data rate, and configured to add to a level of said data within said buff by writing said data to said buffer at said source data rate;

an output function coupled between said first memory portion and said data sink, configured to subtract from said buffer data level by reading said data from said buffer at a sink data rate greater than zero, and configured to transmit said data to said data sink;

a data sink configured to receive said data at said sink data rate; and

a controller coupled to said first and second memory portions, coupled to said input and output functions, and configured to:

monitor a fill rate of said buffer and said buffer data level in response to said control program, said fill rate being a difference of said source data rate less said sink data rate; and

dispatch a rate-control signal to adjust said source data rate when said monitoring determines one of said fill rate is negative and said buffer data level is less than or equal to a lower data-level threshold and said fill rate is positive and said buffer data level is greater than or equal to an upper data-level threshold.

15. A data-flow regulation apparatus as claim inclaim 14,

said controller is further configured to dispatche said rate-control signal to adjust said sink data rate when one of said fill rate is negative and said buffer data level is less than or equal to a lower data-level threshold and said fill rate is positive and said buffer data level is greater than or equal to an upper data-level threshold.

16. A data-flow regulation apparatus as claimed inclaim 15 wherein:

when said controller determines said fill rate is negative and said buffer data level is less than or equal to said lower data-level threshold, said controller is configured to dispatch said rate-control signal to adjusts said source data rate so that said source data rate is greater than said sink data rate;

when said controller determines said fill rate is positive and said buffer data level is greater than or equal to said upper data-level threshold, said controller is configured to dispatch said rate-control signal to adjusts said source data rate so that said source data rate is less than said sink data rate.

17. A data-flow regulation apparatus as claimed inclaim 16 wherein:

when said controller determines said fill rate is negative and said buffer data level is less than or equal to a lower inner data-level threshold between said lower data-level threshold and said upper data-level threshold, said controller is configured to dispatch said rate-control signal to adjusts source data rate so as to add a positive component to said fill rate;

when said controller determines said buffer fill rate is positive and said buffer data level is greater than or equal to an upper inner data-level threshold between said lower inner data-level threshold and said upper data-level threshold, said controller is configured to dispatch said rate-control signal to adjusts said source data rate so that a negative component is added to said fill rate.

18. A data-flow regulation apparatus as claimed inclaim 14 wherein:

said data-source initially establishes said source data rate substantially equal to a predetermined data rate; and

said data-sink initially establishes said sin data rate substantially equal to said predetermined data rate.

19. A data-flow regulation apparatus as claimed inclaim 14 wherein:

said data source substantially continuously transmits said data;

said input function substantially continuously receives said data from said data source and substantially continuously writes said data to said buffer;

said output function substantially continuously reads said data from said buffer and substantially continuously receives said data; and

one of said data source and said data sink repetitively adjusts one of said source data rate and said sink data rate, respectively, in response to said controller so as to substantially maintain said buffer data level between said lower and, upper data-level thresholds.

20. A data-flow regulation apparatus as claimed inclaim 14 wherein one of said first and second memory portions shares a common address space with one of said data source and said data sink.

21. A method of regulating flow of data in a communication system, said method comprising:

establishing, in a data source, a source data rate substantially equal to a predetermined data rate greater than zero;

establishing, in a data sink, a sink data rate substantially equal to said predetermined data rate;

adjusting said source data rate in response to a rate-control signal, wherein, when said source data rate is less than said sink data rate and a level of said data within a buffer is less than or equal to a lower data-level threshold of said buffer, said adjusting activity adjusts said source data rate to be greater than said sink data rate, and wherein, when said source data rate is greater than said sink data rate and said buffer data level is greater than or equal to an upper data-level threshold of said buffer, said adjusting activity adjusts said source data rate to be less than said sink data rate;

transmitting said data at said source data rate by said data source;

writing said data into said buffer at said source data rate, wherein said writing activity increases said buffer data level;

reading said data from said buffer at said sink data rate, wherein said reading activity decreases said buffer data level;

receiving said data at said sink data rate by said data sink; monitoring said buffer data level; and

dispatching, when said monitoring activity determines that said buffer data level is one of decreasing and increasing while at less than or equal to said lower data-level threshold and greater than or equal to said upper data-level thresholds, respectively, said rate-control signal to said data source.

Images