Data rate controller

FIELD OF THE INVENTION

0001The present invention provides a system to control the data rate used by an end device in order to manage available resources and provide sufficiently high voice quality. In particular, the device might exist on a network with other such devices, and the data rates of each will be managed.

BACKGROUND OF THE INVENTION

0002Internet protocol (IP) networks, and the like, for providing data communication among a plurality of computers are well-known. Such networks facilitate the transfer of data files, audio information and video information, as well as any other information that may be represented in binary form among the plurality of computers.

0003Networks can be conveniently divided into two broad categories, based upon their size. A local area network (LAN) is a group of computers which is connected so as to facilitate the sharing of applications, data and peripherals. Local area networks are generally confined to a single building or a small group of buildings.

0004A wide area network (WAN) is made up of a plurality of LANs which is connected together so as to facilitate communication therebetween. A WAN may cover a city, a state, a country or even be international in scope. The Internet is an example of a WAN that includes more than 2,000 separate packet-switched networks that are located all over the world.

0005The popularity of networks, such as the Internet, has increased the desire for additional network services, such as network telephony. The vast, high bandwidth network provides an ideal medium for audio communications. The nature of such telephone devices is to process voice signals that might come in over the network, typically as digital packets of information, or the like. To process such signals, various computing and processing devices are used, typically in the form of integrated circuit configurations. These devices are often capable of handling multiple channels of information. Alternatively, multiple channels might be processed using multiple devices distributed across a network.

0006For telephony and voice applications, packet-based networks are becoming more widely used. In the past, it was often difficult to guarantee sufficient bandwidth or a certain "quality of service" that might be needed to accommodate real-time voice signals (that are broken into packets). However, known solutions have been developed which address various problems associated with transmitting voice over packet networks, including, for instance, voice over IP (Internet Protocol), voice over ATM (asynchronous transfer mode), and voice over frame relay.

0007Prior art solutions include voice coders (i.e., particularized hardware and software devices) that can be applied to packet-based voice systems. Voice coders are configured to process and encode incoming voice signals at certain data rates. In general, if a higher data rate is used (i.e., more voice samples are taken), then the voice coder does not need to be as complex. In other words, fewer hardware components might be employed, or the software associated with the device might be less complex. Conversely, if a lower data rate is used, the voice coder is generally more complex since more compression needs to be performed on the signal.

0008This data rate can be varied, depending upon the input signal or source being supplied to the device. For such devices, the term variable bit rate (VBR) has been defined as follows: A VBR encoder outputs a bit stream which may have a variable number of bits in successive frames. That is, each frame may contain a different number of bits relative to the last frame. Bit-rates may vary, for example, in large predefined increments/decrements, or the bit-rates may vary by as little as one-bit resolution. The variability in bit rate may be either network controlled or source controlled according to the input audio signal.

0009Source controlled rate (SCR) devices use the source to vary the bit rate. For instance, during a normal telephone conversation, the participants alternate speaking so that, on average, each direction of transmission is occupied 50% of the time. SCR is a mode of operation where the speech encoder encodes speech frames containing only background noise with a lower speech rate than might be used for encoding speech. A network may also vary its transmission scheme to take advantage of the varying bit rate. Benefits provided therein include: (a) increases battery life and/or reduces power consumption of the associated processing system, and (b) the average required bit-rate is reduced, thereby leading to a more efficient transmission with decreased load and hence increased capacity.

0010Encoders conform to various standards proposed through the International Telecommunication Union (ITU) and European Telecommunications Standards Institute (ETSI). The ITU Telecommunication Standardization Sector (ITU-T) is one of the three Sectors of the ITU. The ETSI focuses moreso on European standards. The mission of the ITU and the ETSI is to ensure efficient production of high quality standards covering certain fields of telecommunications. Table 1 (ITU) and Table 2 (ETSI) show certain representative encoding standards: <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1</title><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col3" align="center">ITU-T Standard Encoders</entry></row><row><entry namest="col1" nameend="col1" align="left">Name</entry><entry namest="col2" nameend="col2" align="left">Annex (if appropriate)</entry><entry namest="col3" nameend="col3" align="left">Approximate data rate(s)</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">G.728</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">16 Kbps/12.8 Kbps</entry></row><row><entry namest="col1" nameend="col1" align="left">G.729</entry><entry namest="col2" nameend="col2" align="left">A</entry><entry namest="col3" nameend="col3" align="left">8 Kbps</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">B</entry><entry namest="col3" nameend="col3" align="left">VAD</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">D</entry><entry namest="col3" nameend="col3" align="left">6.4 Kbps</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">E</entry><entry namest="col3" nameend="col3" align="left">12.8 Kbps</entry></row><row><entry namest="col1" nameend="col1" align="left">G.711</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">64 Kbps</entry></row><row><entry namest="col1" nameend="col1" align="left">G.726</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">16/24/32/40 Kbps</entry></row><row><entry namest="col1" nameend="col1" align="left">G.723.1</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">6.3 Kbps</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">5.3 Kbps</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="left">A</entry><entry namest="col3" nameend="col3" align="left">VAD (voice activated device)</entry></row></tbody></tgroup></table></tables><tables id="tabl0002" num="0002"><table frame="all"><title>Table 2</title><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col3" align="center">ETSI - Standard encoders</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">GSM-AMR</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">4-12 Kbps</entry></row><row><entry namest="col1" nameend="col1" align="left">GSM-FR/EFR</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">13 Kbps</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">GSM-HR</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">6.4 Kbps</entry></row></tbody></tgroup></table></tables>

0011These representative encoders are part of a growing list of standards, with each different device being used according to its specification of abilities for a given situation. For instance, G.728 is an international voice compression standard from ITU and has rapidly gained acceptance for many applications including: satellite, cellular, and video-conferencing systems. G.728 is specified as part of the H.320 international video-conferencing standard. One reason for its rapid acceptance is that G.728 delivers the same toll-quality voice as 32 Kbps ADPCM (adaptive differential pulse-code modulation), but in only half the bandwidth. Note that ADPCM is a technique for converting sound or analog information to binary information (a string of 0's and 1's) by taking frequent samples of the sound and expressing the value of the sampled sound modulation in binary terms.

0012Referring to Figure 6 of the above references entitled "Voice and Data Exchange over a Packet Based Network with Resource Management," and "Voice and Data Exchange over a Packet Based Network," respectively, the encoders would be located within the voice encoder block 82. The encoders would be implemented via either hardware and/or software, depending upon the configuration that was implemented.

0013Certain members of this group of representative encoders are known to incorporate various aspects of SCR. For instance, the ETSI GSM-AMR encoder is source controlled, as well as Qualcom's QCELP encoder, and certain VAD-Speech encoder combinations. Network management systems in current use will normally manage network bandwidth by downspeeding endpoints during congestion. However, the various members of this overall collection of encoders are not believed to use a collection (or combination) of statistical information -- that might be derived from the network (i.e., the devices in the network and the associated connections) and the source -- in order to arrive at a data rate decision. It is one important aspect to collectively consider the data rate needs of all of the devices in the network. It is also an important aspect to have a system that can adjust the rates of each device to thereby create a more efficient throughput of data across the entire system.

0014EP-A-1 024 638 describes a system and method for dynamic codec alteration. A bandwidth adjustment server is provided which monitors system bandwidth usage, sends requests to terminals, to identify their coding capabilities, and directs each of the terminals to adjust their coding algorithms based on system bandwidth usage. If system bandwidth usage is high, the BWAS requires the terminals to employ a less bandwidth intensive coding algorithm; similarly, when system bandwidth usage is low, the BWAS will allow the terminals to employ higher bandwidth use coding algorithms. Codec renegotiation may be initiated if there is a disparity between the bandwidth allocated to new connections versus ongoing connections or an increase in data traffic. Paksoy E. et al.: "Variable rate speech coding for multiple access wireless networks" in Electrotechnical conference, 1994. Proceedings, 7^th Mediterranean Antalya, Turkey 12 - 14 April 1994, New York, NY, USA, IEEE, 12 April 1994 deals with variable rate speech coding for multiple access wireless networks. A source-controlled variable-rate speech coding algorithm, named Variable Rate Phonetic Segmentation (VRPS) is described. In VRPS the rate and coding strategy are based on phonetic classification of speech segments. There, the bit rate of the coder is made to vary in response to an external control signal. This signal may be a request generated by the network, instructing some or all coders to temporarily reduce their output rate in order to accommodate an increase in the network traffic or the transmission of signaling information. The average quality of the received speech signal can be improved if the network controller directs some or all users to reduce their bit-rate from the peak value to an intermediate level when traffic exceeds a certain level. Thus, dynamic control of user bit rate based on changes in traffic levels can be achieved. EP-A-1 079 573 describes a method and a system of managing calls over a data network, including determining an available bandwidth of the data network. After a call request is received for establishing a call between at least two network terminals, one or more of a plurality of resource elements are selected in response to the call request based on the bandwidth of the data network. The resource elements which can include codecs, packet sizes and others, are used in the requested call between the at least two network terminals. One or more usage threshold values are assigned to a link or links between communities, and a call request is processed based on the one ore more usage threshold values. The processing includes at least one of determining whether to admit the call request and selecting resource elements to be used during a call between terminals over the link.

0015Accordingly, what is needed in the field is central controller coupled with a network of devices which can monitor statistical information (or the like) associated with each network device. The information might be considered alone or in combination with other information and thereby adjust the data rate of each device based upon such statistical information.

SUMMARY OF THE INVENTION

0016It is the object of the present invention to provide a data rate controller system of high quality out low costs. This object is solved by the data rate controller having the features according to claim 1. Preferred embodiments are defined in the dependent claims.

0017The present invention provides a system for adjusting the data rates of various channels within a network of devices. Each channel within a device runs an encoder that conforms to certain standards, depending upon what particular encoding functions the channel is supposed to perform (i.e., voice, data, FAX, etc.). Moreover, certain encoders perform better under different adverse conditions, such as noise, jitter, lost packets, etc. Among other things, the different encoders can operate at different data rates. Selection of the appropriate encoder for the situation provides for selection of an appropriate data rate.

0018According to an embodiment a call/resource manager (or central controller) is included that receives statistical information from a plurality of channels associated with the manager. The channels provide statistical information to the manager about the inbound/outbound signal, the channel resources, and/or the network resources. This information might involve certain factors in order to make an encoder (i.e., data rate) decision. These factors include, but are not limited to, estimated lost packet rate, estimated jitter in the network, estimated background noise level, estimated network utilization, and estimated process utilization. The corresponding information would be provided by devices such as a lost frame rate estimator or a jitter estimator in a voice synchronizer, a jitter estimator in a voice synchronizer, a call discriminator, and/or resource information (from the network or from the channel processors). These information-providing devices might be sub-components of an overall system, such as a network telephony device or the like.

0019The manager thereby monitors statistics and events from each channel and thereafter generates control instructions to be sent to a portion (or all) of the channels. For instance, if a high lost frame rate is indicated, a switch can be made on some or all of the channels to a lower rate encoder. In an illustrative embodiment, if a high lost frame rate is indicated, the packetization interval is reduced. This should reduce network congestion, as well as the high frame loss condition. A lower-frame lost condition will improve voice quality. If a high jitter rate is detected, then instructions can be given to downspeed all or some of the channels. This should relieve congestion on the network, which should improve jitter performance. If a call discriminator detects a certain type of call, then the manager might also consider network utilization and/or system resource utilization in order to switch from one mode to another mode (i.e., voiceband data mode to FAX relay mode). Background noise might also be used by a channel to derive an upspeed request, which will be considered by the manager/controller in light of network utilization and resource utilization.

0020Still another embodiment might utilize channels that can autonomously switch to any of a number of encoders that comprise a set for that channel. The network will thereby have profiles that must be satisfied for each network path. Based upon background noise (or the like), the channel will switch to a preferred encoder. After each encoder is selected, the network requirements will be satisfied according to the determined profiles that were used to determine the set of encoders for each channel.

0021Accordingly, one aspect of the present invention provides for a data rate controller system for providing control instructions to a plurality of channels on corresponding channel devices operating on a network. The system includes at least one channel that provides statistical information about the associated channel signal. The system also includes at least one encoder and a central controller. Each encoder provides for running at a certain data rate on each channel device. The central controller interacts with the plurality of channels. Statistical information about each channel signal is used by the central controller to determine the type of encoder that should be run on each channel device. The central controller sends a control instruction to each channel to facilitate implementation of the encoder.

0022Another aspect of the present invention provides for a data rate controller system for providing control instructions to a plurality of channels on corresponding channel devices operating on a network. At least one channel has means for detecting background noise conditions, and means for providing channel resource utilization and associated network utilization information for each channel. At least one encoder runs at a certain data rate on each channel device. A central controller interacts with the plurality of channels. The noise conditions and the resource and network utilization information, from each channel, are used by the central controller to determine the type of encoder that should be run on each channel device. The central controller sends a control instruction to each channel to facilitate implementation of the encoder.

0023Still another aspect of the present invention provides for a data rate controller system for allowing a plurality of channels on a network to each select a channel encoder that fits an associated network profile. The system includes a network of channels having a plurality of connections. The network forms a profile of allowed data rates that might flow across the connections. A set of encoders is associated with each channel on the network. A device is associated with each channel for detecting source information. The source information is used by each channel to select an appropriate encoder from each set of encoders, with each channel thereafter satisfying the profile.

0024It is understood that other embodiments of the present invention will become readily apparent to those skilled in the art from the following detailed description, wherein shown and described are only example embodiments of the invention by way of illustration. As will be realized, the invention is capable of other and different embodiments and its several details are capable of modification in various other respects, all without departing from the scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

0025Certain aspects and advantages of the present invention will be apparent upon reference to the accompanying description when taken in conjunction with the following drawings, which are exemplary, wherein: <ul id="ul0001" list-style="none"><li>Figure 1 is a representative block diagram, according to at least one aspect of the present invention, of the call/resource manager (or central controller) receiving statistical information from a plurality of channels and providing data rate instructions based upon this information.</li><li>Figure 2 is a block diagram, according to one aspect of the present invention, of a voice synchronizer/jitter buffer that might be contained in an overall system, having a lost packet rate estimator and a jitter estimator.</li><li>Figure 3 is a block diagram, according to one aspect of the present invention, of a plurality of channels providing lost frame rate information to the call/resource manager, with control instructions returned based on this information.</li><li>Figure 4 is a block diagram, according to one aspect of the present invention, of a plurality of channels providing jitter information to the call/resource manager, with control instructions returned based on this information.</li><li>Figure 5 is a block diagram, according to one aspect of the present invention, of a plurality of channels providing call discriminator event information and/or system resource utilization information to the call/resource manager, with control instructions returned based on this information.</li><li>Figure 6 is a block diagram, according to one aspect of the present invention, of a plurality of channels sending a request to the call/resource manager for upspeed of the data rate, the request being derived from noise information, with control instructions returned based on this information.</li><li>Figure 7 is a block diagram, according to one aspect of the present invention, of standards being invoked for each of a plurality of channels, according to profiles that satisfy certain network requirements and constraints.</li></ul>

DESCRIPTION OF THE PREFERRED EMBODIMENTS

0026The present invention is described below in terms of certain preferred embodiments and representative applications. The examples provided are intended to be used with any communication system that would benefit from having a controller that can control the data rates used by various devices in a network or system. The controller will be used to monitor and interpret various statistical information pertaining to the network and its interconnected devices. While a certain set of examples is presented in terms of what statistical information to use, any of a variety of other statistical information might also be considered and used to adjust the data rates of the various networked devices.

0027The present invention is also intended to apply to voice over packet networks, including, but not limited to, Voice over IP (VoIP), Voice over ATM (VoATM), voice over frame relay and cellular/wireless/PCS networks. The present invention describes certain methods involved in performing the switch. Certain representative factors are also described, which can be used in making the data rate decision. These factors include, but are not limited to, the following: (1) estimated lost packet rate, (2) estimated jitter in the network, (3) estimated background noise level (i.e., source statistics), (4) estimated network utilization, and/or (5) estimated processor utilization (either committed or observed).

0028According to such statistics, a system is provided to control the rate of an end device in order to manage resources available and thereby obtain a high voice quality across each device in the network. These statistics can be broken down into source statistics and network statistics. Source statistics (i.e., background noise level and the like) are derived directly from the incoming signal and do not require any information from/about the other devices in a system. Network statistics, however, require the system to have a central manager, which manages all of the channels being aggregated onto a network. The central manager might similarly include a host, call manager, call agent, or the like. The manager will serve to monitor statistics and events from each channel and thereafter make rate (i.e., bandwidth) decisions based on a multitude of factors (including, for instance the factors 1-5 shown above).

0029Figure 1 next shows an example data rate controller system 100. Note that each channel may reside on the same physical device or on multiple devices. The Call/Resource Manager (or central controller) 102 is shown receiving various signal information from a plurality of channels. Channel 1 (104) is shown to provide certain statistical information to the manager 102, including source rate request 106, call discriminator request 108, jitter 110, lost frame rate 112, and system resource utilization 114. The statistical information is not strictly limited to the elements shown and might include other information as indicated by the continuation indicator 115. The manager 102 uses this information to thereafter send control instructions 116 back to channel 1 (104). A second channel 120 is shown sending a similar set of information 122 to the manager 102 and then receiving control instructions 124 back from the manager 102. Any number of other channels might be included, up to and including channel N (130). Channel N also sends a similar set of information 132 back to the manager 102 and receives control instructions 134.

0030Representative examples are next described for utilizing each statistical piece of information listed above, namely Lost Frame Rate, Jitter, Call Discriminator Request, Estimated Background Noise, and Network Profile Support. The present invention is not intended to be strictly limited to these statistical pieces of information, as other forms of statistical information might also be used.

0031Lost Frame Rate (see Figure 1, 112) - In a packet based system, frames of data are processed in a sequential fashion. Occasionally, frames are lost or dropped during the process. A lost frame can result in temporary loss of the voice and/or data signal over a transmission line. Generally, the lost frame rate is a measure (or estimate) of the amount of frames that might be dropped by a system and is often calculated as a percentage of the total amount of incoming frames.

0032Referring again to Figure 6 of the references entitled "Voice and Data Exchange over a Packet Based Network with Resource Management," and "Voice and Data Exchange over a Packet Based Network," respectively, the lost packet estimator will generally be included in the Voice Synchronizer block 90. Figure 2 shows this device 200 configured as both a voice synchronizer and jitter buffer. The arriving packets 202 enter the device and are processed by both the lost packet rate estimator 204, as well as the jitter estimator 206. The result 205 from the lost packet rate estimator 204 will be used by the central controller (Figure 1, 102) as a standard piece of statistical information. A jitter estimator 206 is also shown, with the result 207 also being used by the central controller 102. The respective results 208, 209 of each sub-part (204, 206) of the voice synchronizer/jitter buffer 200 are sent to the voice decoder (see Figure 6, element 96 of the cited reference).

0033According to one aspect of the present invention, if all of the channels are using a voice compression algorithm with low complexity (i.e., ITU-T standard G.711), and the lost frame rate is high on all channels (for instance > 2 %), then a switch should be made to a lower data rate encoder. Figure 3 serves to illustrate such circumstances. The Call/Resource manager 302 is shown receiving lost frame rate information 303, 305, and 307 from each respective channel 304, 306, and 308. If each channel has a lower rate encoder available - particularly an encoder with better lost frame characteristics (i.e., G.729 Annex E at 11.8 kbps), then the resource manager 302 will send some form of control instructions (i.e., 310, 312, or 314, respectively) back to each appropriate channel. The instructions will dictate whether the encoder rate should be switched on a portion of the channels, or on all channels, which are under the control of the manager 102.

0034By switching to a lower rate encoder, overall congestion on the network should be reduced. This is because the lower rate encoder pushes fewer bits out onto the transmission path (or network paths) for an equivalent amount of incoming voice/data signal. In turn, the lower rate should help to reduce the high frame loss condition. By lowering the frame loss rate, the voice quality will thereby be improved (despite using the lower rate encoder). In an illustrative embodiment of the present invention, if a switch is made to a lower rate encoder as a result of a high lost frame rate, a lower packetization interval is used, and this will minimize the temporal effect of a single lost frame.

0035In this example, the high-loss frame rate is detected on inbound channels. Note that each channel is shown to function as either an inbound 320 or outbound 322 signal. However, there may or may not be congestion on outbound channels. Accordingly, this system should also signal the call resource managers to send instructions to decrease the bandwidth used by the end devices (i.e., the devices employing the channel on the network).

0036Alternatively, the end devices might be configured to switch to a different voice encoder when a change in the egress rate is detected. For instance, if the egress rate increases, then a higher rate encoder might be used. Conversely, if a lower egress rate is detected, then a lower rate encoder might be used. This would provide for maximum performance of voice quality in the system while accounting for bandwidth capabilities of the network and devices within the network.

0037Jitter (see Figure 1, 110) - Jitter might be defined as the deviation in, or displacement of, timing of a digital signal. For instance, if a signal packet is expected at a certain time, and the packet comes in at a later time, then the jitter might be expressed as this time delay.

0038Causes of jitter include (among other things) processing delay, queueing of packets in network equipment, and different delays due to the possibly different paths packet take while traversing the network. In audio signals, jitter can introduce phase distortion or other undesired effects in the signal and loss of transmitted data between network devices. The amount of allowable jitter depends greatly on the application at hand.

0039Figure 4 next shows the system configuration 400 where the Call/Resource manager 402 receives jitter information from each channel. Channel 1 (404) is shown sending information to the manager 402, thereby indicating whether the jitter 406 is above a set limit or not. For instance, the set limit might test if the jitter is greater than 50 msec on some or all of the channels considered. Similarly, channel 2 (408) is shown sending jitter information 410 to the manager 402, and channel N (412) is shown sending jitter information 414 to the manager 402. Based upon the information gathered from all channels, the manager (or controller) 402 makes a decision to downspeed all or some channels to a lower data rate. This is shown as certain control instructions (i.e., 420, 422, and 424) being sent to facilitate lowering the encoder rate. One encoder that might be used to satisfy the downspeed instructions includes the ITU-T standard G.726 running at 32 kbps. Using an enconder at this data rate should serve to relieve congestion on the network. Less congestion will, in turn, subsequently improve the jitter performance.

0040Generally, the high jitter is detected on inbound packets 430. The rate change thereafter affects outbound packets 432. Similar to the end device described above, the system should also signal the call resource manager(s) 402 to decrease the bandwidth used by the end devices. Alternatively, the end devices could switch voice coders when an egress rate change is detected.

0041Call Discriminator Request (see Figure 1, 108), and System Resource Utilization (see Figure 1, 114) - Elements 108 and 114 in Figure 1 further show that information derived from a call discriminator, and system resource utilization, might also be used to adjust the data rate of the channels. A representative call discriminator is shown as element 68 in Figure 6 of references entitled "Voice and Data Exchange over a Packet Based Network with Resource Management," and "Voice and Data Exchange over a Packet Based Network," respectively. Figure 5 of the present invention shows a representative system configuration 500 (as per the model of the previous examples). For example purposes only, channel 1(504) might be assumed to be configured with a voice encoder (i.e., G.729, or the like), and the call discriminator might thereafter detect a FAX call. The voice system running on channel 1 provides call discriminator events 506 to the controller/resource manager 502. Each channel also provides system resource utilization information 505 to the manager 502. Channels 2 (508) through N (512) also provide call discriminator events (510 and 514, respectively) and system resource utilizations (509 and 513, respectively) to the resource manager 502.

0042Based on network utilization and/or system resource utilization (505, 509, 513) (i.e., MIPs, memory, or the like), certain control instructions (or commands, 520, 522, and 524, respectively) are sent from the manager 502 to each channel 504, 508, and 512. The control instruction facilitates the channel switching from one mode to another. For this particular example, the mode might switch from a voice mode to a voiceband data mode. Such switching might include running a G.711 voice coder, and setting the jitter buffer to a non-adaptive mode. The channel switching might additionally facilitate switching to FAX relay.

0043As described above, a lower complexity encoder produces more bits and requires more bandwidth in order to send data. A high complexity encoder produces fewer bits because the compression algorithm is more complicated. The needs of each device need to be weighed against the capabilities of the system. For instance, a voice encoder like G.711 has a relatively low complexity and therefore requires a relatively higher amount of bandwidth to send data. FAX relay is higher complexity than a G.711 encoder and therefore requires more system resources.

0044Accordingly, each of the channels on the network is analyzed to determine the overall capabilities of the system. If it is determined that the network congestion is high, and the system resource utilization is low, then FAX relay might be used. If the network congestion is low, but the system resource utilization is high, then the voiceband data mode might be used.

0045Still another case might find both the network being congested, and the processor being overworked. In such a case, the FAX call might simply be dropped. Note that high network utilization implies that bandwidth is not available to carry the FAX call via G.711. Conversely, high resource utilization means that there may not be enough resources to run the complex FAX relay. Accordingly, the entire call might need to be dropped in order to satisfy the system capabilities.

0046The above example is meant to be illustrative only. Other call events might also be considered, in light of system resource utilization, in order to determine control instructions to send to a portion of the channels or all of the channels.

0047As before, generally the call event type is detected on inbound signals 530. Any rate change will affect outbound packets, and the system should signal the call resource managers to decrease the bandwidth used by the end devices. Again as before, the end devices might switch voice encoders when an egress rate change is detected.

0048Estimated background noise (derived from source) - The background noise of an inbound signal can be derived from the source without each channel needing to communicate with the central controller. This background noise (alone) can be used to determine whether a channel (in an associated device) should switch from one data rate to another. However, certain advantages might also be derived by considering the system resource utilization of each device on the network.

0049Figure 6 shows an example of certain representative elements 600. An inbound signal 640 (from a source or the like) comes into channel 1 (604). Channel 1 might be running G723.1 at 5.3 kbps and thereafter detect high background noise conditions (i.e., > -45 dBm). The channel will send a request to upspeed 606 to be considered by the Call/Resource manager 602. The request to upspeed might include a request to switch to G.728 at 16 kbps, or similar data rate, which is higher than the present data rate. The call/resource manager 602 will also consider the system resource utilization 608. This might include processor utilization and/or network utilization. Note that the higher data rate standard will require more bandwidth. If the network utilization is low, then there is bandwidth available for G.728 or the like. If the processor utilization is low, then there is processor bandwidth available for running G.728 or the like. If these representative utilization conditions are satisfied, then the controller grants the request via the control instruction(s) 610. A similar situation is shown for channel 2 (620), with a respective request to upspeed 622 and system resource utilization 624 being sent to the call/resource manager 602. The granting of the request (or not) by the manager 602 is shown, respectively, as 626 and 636.

0050Support for Network Profiles - Still another example might utilize a profile of possible encoders that would be supported by a particular network configuration. Figure 7 shows certain representative elements 700 to illustrate the usage of such profiles. A plurality of channels is shown having at least one channel encoder associated with each channel. Generally each channel will have a set of encoders standards. Channel 1 (702) is shown to have at least G.711, G.729, and so forth. Channels 2 (704) through N (706) also have these representative encoders (while others could be used).

0051Each path 710, 712, and 714 in the network 708 will have a certain profile of capabilities that have been derived from various factors, including, for instance, the network capability (i.e., each path in the network or the overall network), and the processor resource capabilities of the various devices using the channels. The profiles should be designed so that if each channel chooses to run a certain standard, the network and processor resources will be within the capabilities of the system.

0052For instance, channel 1 might be running the G.711 standard at 64 kbps. The channel might thereafter detect very low background noise conditions and autonomously switch to a lower rate standard within channel set, such as the G.729 standard, in order to conserve processor/MIPs resources. Channel 2 (704) through channel N (706) might perform similar switching from one standard to another, based upon the background noise associated with each of these channels. The profiles available for each of these encoders will provide a workable system configuration for any selected encoder, even though the encoders are autonomously selected by each separate channel.

0053By implementing any of these example representations, a higher quality system might be maintained at a lower cost. By sharing resources and trading off network bandwidth, a higher system utilization might be achieved, which in turn can increase quality of the voice/data transmission over a channel.

0054Although certain exemplary embodiments of the present invention have been described, it should not be construed to limit the scope of the appended claims. For example, the present invention can be implemented by both a software embodiment or a hardware embodiment. Those skilled in the art will understand that various modifications may be made to the described embodiment. Moreover, to those skilled in the various arts, the invention itself herein will suggest solutions to other tasks and adaptations for other applications. It is therefore desired that the present embodiments be considered in all respects as illustrative and not restrictive. It is therefore intended that the following claims be interpreted as covering all such alterations and modifications as fall within the true scope of the invention.